RFC: Radio Streaming strategy

[drewvolz]

Premise

Our current radio streaming capabilities do not start up reliably or quickly. It appears to take several starts and stops to enable a stream, sometimes taking more than a minute or two to begin playing audio. The current implementation involves webviews and web browsers.

What are the radio streams?

We tap into both St. Olaf's KSTO and Carleton's KRLX internet radio broadcasts. The main ways of reaching these streams are via:

• KRLX (MP3/M3U stream)

  • web and stream

• KSTO (HLS/M3U8 stream)

  • web and stream

Current radio streaming strategy

• iOS implements a hidden <WebView /> and listens for events fired by an internal <audio /> player and the front-end buttons to start/stop the stream.

• Android loads the streams in a visible web browser.

Proposal

I propose the following changes to the radio streaming strategy for this app.

• We should build a native bridge for streaming. This would be responsible for listening to bridged events such as start, stop, pause coming from JS over to native land.

  • We should start a streaming service natively.

    • iOS: we have an example of starting a native stream for KSTO in the native KSTO app. It is a good baseline to be able to adjust into a bridged library.
    • Android: we will probably require a bit more legwork to make a bridged library as I have not written an example app for KSTO in android.

  • We should listen / fetch track metadata.

    • Incoming timed HLS ID3 tags that KSTO emits when the audio changes tracks. The tag should be serialized and returned to the JS across the bridge. It can then be rendered in the view.
    • KRLX maintains an API for fetching these and we shall write a fetching interface to present track data to the user in the view. This is not necessary to implement as a bridged method.

• As part of this change, we adjust the functionality of sending analytics to broadcast media.

  • As far as KSTO, there should be a POST request to handle the various bits of metadata that BMS cares about collecting according to their analytics scripts. This shall live as part of react native rather than be written as part of the bridge.
  • I am unaware of analytics collected on KRLX.

• We replace the current streaming mechanisms with their native counterparts.

---

Questions? Comments?

Originally posted by @drewvolz in #2747 (comment)

[rye]

I wholeheartedly support the investigation, if nothing less, of a native streaming client. HLS and M3U can be difficult beasts to tame, but if there is some way of doing the native stream, I'd prefer that to using a web browser.

Any native streaming client should use the appropriate UA for any HTTP traffic, which partly solves the upstream analytics story. If the analytics API (i) is stable, and (ii) is documented publicly or shared with us, then there is no concern about sending a bit of information about the stream to the third party from whence the stream is coming.

It's worth noting that I'd also prefer to try react-native-video over reinventing HLS streaming, especially natively. If there are legitimate blockages to preventing us from using react-native-video, then we can do something else.

[drewvolz]

Investigative work now lives at https://github.com/frog-pond/react-native-audio-stream