iOS Safari Compatibility

[W3AXL]

It's me again, with another interesting issue.

I have the IcecastReadableStream object working flawlessly on every desktop browser I can test with. I'm compiling the javascript using webpack for Node, as opposed to the recently-created standalone JS player, because I'm lazy and don't want to port over all my code.

Anyway, I'm now trying to get my stream player working on mobile devices, and iOS safari is the first browser I'm hitting (since I own apple devices).

Safari on iOS doesn't support MSE, but I believe I have a workaround using the web audio API. That remains to be seen, but I'm getting hung up with getting stream data at all.

I instantiate the reader in what I believe is a normal way:

// fetch the stream
    fetch(streamUrl, {
        method: "GET",
        headers: {
            "Icy-MetaData": "1",
        },
        signal: signal
    })
    // create the icecast metadata reader
    .then(async (response) => {
        console.log("creating icecast readable stream");
        const icecast = new IcecastReadableStream(
            response,
            {
                onStream: pushStream,
                onMetadata: pushMetadata,
                metadataTypes: ["icy"]
            }
        );
        await icecast.startReading();
    });

However, iOS gives me the following console error (I'm using the remotedebug-ios-webkit-adapter npm package for remote debugging) when I call icecast.startReading():

[native code]:1 Unhandled Promise Rejection: TypeError: icecast.startReading is not a function. (In 'icecast.startReading()', 'icecast.startReading' is undefined)

Again, this same code works flawlessly in desktop browsers. I'm guessing something inside the library doesn't play nice with iOS safari.

This is definitely a "nice to have" but it would be useful for my application to be able to display metadata in mobile browsers.

[eshaz]

I don't own any Apple devices, and I've never tested the library in iOS Safari. I'm definitely interested in getting it to work though, if possible, but you might have to direct users to install Chrome if they are in an iPhone, especially if Safari doesn't have MSE support.

Which version of Safari / iOS are you running? Do you have a stack trace, or any more information on the error? It looks like the IcecastReadableStream failed to instantiate due to some other issue, and this error is because the icecast variable was never assigned an instance. It's probably some syntax in the library that's not supported yet in Safari. Could you try using the IcecastMetadataReader class and see if that instantiates properly? Also, one final thing, could you try running this code in Safari: console.log(typeof Symbol.asyncIterator) and see if it outputs symbol. Looking at MDN, the asyncIterator symbol isn't supported in Safari but it's used in IcecastReadableStream.

If you are able to get the WebAudio API working to play back the MP3 in the stream, I would be very interested in seeing how you accomplish it. I tried a while back to use BaseAudioContext.decodeAudioData() with the MP3 data, but this didn't work, and actually can't work from what I understand because MP3 uses a bit reservoir that can span multiple frames and has to be decoded as a continuous stream.

[W3AXL]

Wilco on all of the above. Debugging on Safari is annoying, especially since I don't have an apple desktop device of any kind. I have to run through the iOS webkit adapter and it's less than stellar when it comes to javascript console output. I'll see what I can piece together.

Interestingly I can't get the stream to load in Chrome for iOS either. No errors in the (less than stellar mobile) console, although it does indicate that it doesn't support MSE either, just like Safari.

[W3AXL]

Running typeof Symbol.asyncIterator via the remote console yields the following:

> typeof Symbol.asyncIterator
> "symbol"

[eshaz]

Running typeof Symbol.asyncIterator via the remote console yields the following:

> typeof Symbol.asyncIterator
> "symbol"

Ok, that's probably not the issue then. Probably the next step would be to see the stack trace so we can see where the error originates from.

For MSE, support can be a little spotty if you are piping in the audio/mpeg data in directly to the SourceBuffer. I have another library, https://github.com/eshaz/isobmff-audio/, that I wrote for better MSE compatibility. It wraps the MP3 data in a MP4 container, which is more widely supported than just audio/mpeg data. The icecast-metadata-player uses this library, and you can look at that for an example.

You can check out this website to see if MP3 is supported in a MP4 container on your platform. https://cconcolato.github.io/media-mime-support/#audio/mp4;%20codecs=%22mp3%22

You can also run MediaSource.isTypeSupported('audio/mp4;codecs="mp3"') and see if that returns true.

[W3AXL]

I'm actually already using ISOBMFF for Firefox support and it works great - I credit your demo example for figuring that out with minimal hassle.

I created a basic Safari test page that creates a new IcecastMetadataReader instance, and it seems to instantiate just fine. I don't do anything with it yet, but that's a good sign at least. No errors in the console so far.

As far as a stack trace goes, I'll see what I can do. This remote debugging setup is a bit of a hack in the first place, and it leaves a bit to be desired in terms of verbosity.

[W3AXL]

It doesn't appear that it's possible to get full stack traces via the ios-webkit-adapter, so it may be necessary to add some additional debug prints inside the icecast-metadata-js code to figure out what's going on.

[eshaz]

You can clone down the repo and then replace the dependency line in your package.json with "icecast-metadata-js": "file:../path/to/icecast-metadata-js". Then you can add debug code anywhere in the repo and those changes will be reflected in your bundle. Let me know what you find, or if you want to submit a PR that fixes this, that would be much appreciated!

[zanarduz]

This would save my life, developed nearly all my home project for my streaming radios to find out that doesn't work on iOS (first target platform, didn't try it sooner because I assumed 2021 code would work).

Keep up the great work and let us know if you find a solution!

[eshaz]

An update on this:

I just released icecast-metadata-js/0.5.0 that adds support for Safari 13 desktop. I don't have an iOS device to test on, but I think it's likely that this release will fix the original issue in IcecastReadableStream.

I also released icecast-metadata-player/0.3.0 to support MP3 and AAC streams in Safari desktop. Safari desktop doesn't support playback for FLAC, Opus, or Vorbis. Unfortunately, all the information that I can find about iOS and MediaSource api support indicates there is no support at all for the MediaSource api in iOS, with the only exception being Safari 13 on the iPad.

The demos are up to date and I am curious to know if it works for you! I also added better logging and an events framework for any errors that should help with debugging.

[W3AXL]

I'm finally circling back around to this and I'll be trying out the new library tonight. Hopefully it'll be relatively easy to get everything up and working on iOS.

[W3AXL]

Evening update:

The original issue with IcecastReadableStream failing to instantiate seems to be fixed. The stream object plays and fetches metadata without any issues.

Now I'm just fighting a lack of audio output. I had to do a little adjusting of my audio processing code to get Safari to decode the mp3 chunks properly. While I'm no longer getting any decoding errors, I can't get any actual audio out of the phone's speakers. Will be doing some more investigation, but unfortunately this isn't exactly a super common thing to be trying to do.

We can probably close this issue, as the IcecastReadableStream object does indeed work in safari. Getting the audio chunks from the stream to actually play, however, will likely be another story entirely. We could keep this ticket open to track that if desired.

[eshaz]

That's great to hear the original issue is fixed.

Are you are using decodeAudioData() to decode the results of the stream? Decoding independent chunks of MP3 is unlikely to work. MP3 uses a "bit reservoir" that encodes audio across frame boundaries. MP3 has to be decoded as a continuous stream of data so that the bit reservoir can be properly decoded. See "4. Why cant MP3 files be seamlessly spliced together?".

Fortunately, the Media Source Extensions API solves this problem by allowing audio data to be appended to a source buffer as it comes in, and the browser can decode it as a stream, which is how icecast-metadata-player works.

Unfortunately, iOS / webkit is one of the only modern browsers that doesn't support Media Source Extensions. MSE has been widely supported in browsers for over 5 years now, except in iOS webkit.

I'll close this issue, but also open a new one for iOS support for metadata / playback. There may be a few ways to accomplish synced metadata without using MSE.