IOS / OSX Safari - wait for track to fully buffer/download before audio starts

liamcrean commented 4 years ago

Hello

I think this is more of a bug than a feature request - it's a real barrier for a job I'm working on. When playing a track in OSX Safari (V13) or IOS13 Safari the user needs to wait while the track buffers out fully before listening. Works perfectly in Chrome and Firefox.

Thanks, Liam

gblakeman commented 4 years ago

Has anyone found a work-around for this?

liamcrean commented 4 years ago

No, not yet. @danpastori — is there anything you found?

liamcrean commented 4 years ago

Hello @danpastori - wondered if this might help?

https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canplaythrough_event

Getting Mac users with Safari running faster would be a huge win for Amplitude. I'm happy to help testing if you can look at this?

danpastori commented 4 years ago

Hi @liamcrean and @gblakeman ,

I've been trying to come up with a solution. The canplaythrough event doesn't fire in Safari of course which makes things a little more difficult.

Are either of you using Web Audio API waveform elements? That doesn't initialize unless being used and would require full download of the song before building waveforms. In my tests this evening, I set a link to a podcast that was remote at 113Mb and Safari started playing at 20% load.

I'll continue research to see if we can play right away without buffering. This is definitely an issue that I'd like to solve. Any insight or other ideas would be greatly appreciated!

liamcrean commented 4 years ago

Thanks Dan. Appreciate the effort. I don't think it'll work on IOS safari (limitations from IOS13 on bandwidth ironically). Desktop Safari on OSX is a bigger concern RN.

I'm not using Waverform (AFAIK) — I'm guessing that has to be initalised right?

In my tests this evening, I set a link to a podcast that was remote at 113Mb and Safari started playing at 20% load.

Can you try with an MP3 declared in playlist from server?

danpastori commented 4 years ago

@liamcrean Yup, waveform has to be initialized, so if you don't initialize it, it won't be an issue.

I do have another idea. You have a link to a piece of audio I can try? Sometimes if the server is set up to not send proper byte-headers it will require a full download before playing.

For testing, I grabbed a remote podcast that was 2 hrs long and this is when Safari started playing on OSX:

There's a couple things to notice. First, is that it started playing before the full song was loaded. Second, the libsyn servers provide byte headers and return a 206 Partial Content request.

I can test this if you have a publicly facing audio file to see if the byte headers are exposed. Here is some more information regarding serving partial content: https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests. This is also an issue with navigating. The easiest way to test is if you can skip in the song. If you can skip by adjusting the track location, then your headers are set up correctly.

As of right now, this is only a guess on why it waits for the full audio to download before playing. I'd still like to narrow it down to play even sooner for much longer audio. Any suggestions, I'd love to hear them and we will get to the bottom of this!

mikopogosyan commented 4 years ago

Hello @danpastori

I have exactly this issue with the range. Safari waits everytime to complety the download and then plays the song.

Can you pls help me? How can I set the correct headers?

Thank you very much

danpastori commented 4 years ago

@mikopogosyan This is configured on the server side, so it depends on what you are using for hosting. If you are a PHP dev, here's a Laravel example that helps with smaller songs:

https://laravel.io/forum/09-23-2014-how-to-support-http-byte-serving-in-file-streams

It could be translated to other languages I'm sure. Otherwise you have to configure your server to set it up.

Here's a few links that could help:

Amazon: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RangeGETs.html

IIS: https://docs.microsoft.com/en-us/iis/extensions/configuring-application-request-routing-arr/configure-byte-range-request-segment-size-in-application-request-routing

xerosanyam commented 4 years ago

hey @danpastori! Thanks for the suggestions mentioned above. Any more insights on this?

I'd still like to narrow it down to play even sooner for much longer audio. Any suggestions, I'd love to hear them and we will get to the bottom of this!

mesroporsem commented 4 years ago

hi @danpastori, i am experiencing the exact same issue with a website that i am setting up currently. if you want to test with a publicly available audio file try this one: https://media.mosik.info/audio/singapore-koto/1-solution-found.mp3. the player is implemented on https://media.mosik.info. perhaps this helps to narrow down the cause. every browser starts playing almost immediately with the exception of safari (macos/ios).

liamcrean commented 4 years ago

Hello Dan

Thanks for the most recent replies - I missed those, so apologies for not replying to say thanks. I've sent a RFQ to you via email form. I hope we can work out what's going.

We've checked our server and we do have "byte headers exposed" and checked this track and it allowed us to skip:

[redacted URL]

Output from curl head request:

HTTP/2 200 server: nginx date: Thu, 20 Aug 2020 11:12:35 GMT content-type: audio/mpeg content-length: 4523390 x-accel-version: 0.01 last-modified: Wed, 12 Aug 2020 14:15:58 GMT etag: “45057e-5acaed3a5ec82” accept-ranges: bytes x-powered-by: PleskLin

If you can help us look into this we'd be very happy to support the development work.

Thanks, Liam

danpastori commented 4 years ago

Hi Liam,

I'm in the process of diagnosing this right now. You do have your server set up correctly with the byteheaders and everything in place. This is either a Safari or AmplitudeJS thing, but I'm leaning towards Safari.

I tried even playing a Joe Rogan podcast (http://podcasts.joerogan.net/podcasts/david-blaine) that was 2 hours long and it waited until it loaded 20mb before it started playing (which is a ton). I tried to find settings to cancel the buffering or set how much should be loaded before playing, but I didn't see one.

I'd love to get this resolved and working in Safari. If you have an example of one that works, let me know maybe that can help me diagnose the problem!

jaydrogers commented 4 years ago

Hi all,

So @danpastori asked me about some things on this, so I ran a few tests. I used @liamcrean's site as the example.

Long Story Short

This is a a Safari issue with Safari 13 (iOS 13 and macOS Catalina)
The issue is fixed in Safari 14 (iOS 14 and macOS Big Sur) 🎉

The Details of My Tests

I used consistent bandwidth by utilizing the Network Link Conditioner on my machines
I recorded a video showing the differences in song loading behavior between:
- Safari - iOS 13
- Safari - macOS Catalina (13)
- Safari - iOS 14
- Safari - macOS Big Sur (14)

Video of Test Results

Click image below or click here to play video.

Workarounds Until macOS Big Sur and iOS 14 Become Mainstream

Make sure you are using a CDN to distribute your MP3 files

Unfortunately there isn't anything we can do from the AmplitudeJS side to fix this, but hopefully these tests help! At least there is a fix that should be available from Apple this fall 😁

liamcrean commented 4 years ago

Hi Jay. I did some testing and can confirm - so thanks for the detailed explaination. The video was useful too.

In testing locally I realised that MP4 seemed to be buffering perfectly in Safari - but the video format broke the player controls in Firefox (was expecting worse) but it DID play! So took a look at other Audio file types and .wav suits our target audience (.ogg/webm didn't but .wav works in all modern browsers) and what do you know - it plays while buffering in Safari. It's a drag on bandwidth as it's not a well compressed – but as a makeshift alternative unitil we get widespread adoption of BigSur and IOS14 it'll work.

Ta, Liam

jaydrogers commented 4 years ago

Thanks @liamcrean! I would also highly suggest having the song files behind a CDN as well.

Just an FYI, I have a 200/10 mbps connection and I was having random slowdowns with your site when testing (even before I throttled my own connection). My connection was having issues buffering but then it started working fine about 10-15 minutes later.

liamcrean commented 4 years ago

Worth noting that the .WAV workaround above only appears to work on Catalina / Safari v13+

Tested on Sierra / Safari 12 and it's the same issue.

liamcrean commented 4 years ago

Can confirm that on IOS14 Safari the issue has been resolved.

Safari v14.0 on OSX Catalina does not resolve it sadly (updated today) - but I'm hopeful for a fix, and also what we can expect on Big Sur.

jaydrogers commented 4 years ago

It definitely works in Big Sur. I tested it on the latest beta 👍

liamcrean commented 3 years ago

To close this loop — now that Big Sur has been released from Beta — can also confirm that it works perfectly 💪. Thanks.

jaydrogers commented 3 years ago

Awesome! I will mark this as resolved. 🎉

serversideup / amplitudejs