1

Has anyone else found this? I'm using AudioSource.uri to get the remote audio source, then just using await player.play(); to play the remote audio file, on Android these audio files buffer and start playing a lot faster than on iOS where it takes up to 10 seconds to load and start playing (versus just 2-3 seconds on Android)

Apperfect
  • 11
  • 1

1 Answers1

0

This happens because by default, iOS tries to prevent the player from having to stutter during playback when the network is slow. In effect, it waits longer for more data to be downloaded up front before allowing the audio to start.

How to override the iOS default: The AudioPlayer constructor in just_audio takes a parameter called audioLoadConfiguration where you can pass in platform specific parameters that control loading behaviour. One parameter that is relevant here is automaticallyWaitsToMinimizeStalling which you'll want to set to false. e.g.:

final player = AudioPlayer(
  audioLoadConfiguration: AudioLoadConfiguration(
    darwinLoadControl: DarwinLoadControl(
      automaticallyWaitsToMinimizeStalling: false)));
Ryan Heise
  • 2,273
  • 5
  • 14
  • Thanks Ryan - I tried this and it doesn't seem to load the files any faster, the only change it makes is that there's no longer a loading state when I press play instead it just shows as 'playing' but it's silent for the same amount of time as before when it used to show a loading state. Any chance I could schedule a video call to go over this? Happy to pay for your time, we're using your wonderful package in an app that's very likely to take off big time we hope so it's key we get it right! (https://ammersive.app) Thanks again buddy :) – Apperfect Aug 04 '22 at 16:20
  • There are some other factors that may come into play such as your server headers and the file encoding. In particular, if the encoding puts certain metadata at the end of the file, such as the "duration", then the player will stay in the loading state until it has read that metadata. In this case, you need to ensure your server supports range requests (via the HTTP header configuration) so that it can instantly jump to the end of the file to fetch what it needs without having to wait for the entire file to download. – Ryan Heise Aug 05 '22 at 07:51
  • But wouldn't that affect loading times on Android as well? – Apperfect Aug 05 '22 at 08:16
  • iOS and Android have different loading behaviours, and there are some scenarios where iOS will wait for the entire file to download while Android will start playing immediately. – Ryan Heise Aug 05 '22 at 08:29
  • Ok i'll try to figure it out - presumably you aren't able to offer any offline support on a paid basis then? – Apperfect Aug 05 '22 at 08:32
  • Not presently, but I'll do my best to answer here. A simple experiment you could do is test whether this parameter has the desired effect for different audio files hosted on different servers (e.g. you could try it out on the official example). You could also test putting your own file on a different server or re-encoding your file. Or if you know how to check, you can take a look at your server's HTTP response headers to see whether it includes what iOS needs: a correct Content-Length and support for range requests (something you could test with `curl -D`). – Ryan Heise Aug 05 '22 at 12:17
  • I can confirm that the response headers include content-length and others such as: 'accept-ranges: bytes' and 'content-type: audio/wav' - i don't think the entire file is being downloaded before it starts playing audio, as I can see it buffering on my slider and when I skip forward it triggers the loading state so it's clearly using byte-ranges. The bit of code which is taking the most time is: 'player.setAudioSource(ProgressiveAudioSource(Uri.parse(url.wav)),preload: false);' after which I use player.play(); – Apperfect Aug 06 '22 at 19:06
  • if i put await infront of player.setAudioSource and time the execution of this it's taking up to 10 seconds before the player.play() method is reached - yet on android it only takes 2-3 seconds. – Apperfect Aug 06 '22 at 19:07
  • I should just add that it's only the first load of the audio file which takes a long time - subsequent plays of the same file are almost instant which I presume is thanks to caching – Apperfect Aug 06 '22 at 19:11
  • You can also try lowering the `preferredForwardBufferDuration` parameter. – Ryan Heise Aug 07 '22 at 02:39
  • Can you add playImmediatelyAtRate? I believe this is available for AVPlayer and might solve this for me – Apperfect Aug 16 '22 at 16:11
  • If you submit a feature request on GitHub. – Ryan Heise Aug 17 '22 at 16:09