AndroidLoadControl has no effect on buffering behavior

[paul-blum]

Which API doesn't behave as documented, and how does it misbehave? Name here the specific methods or fields that are not behaving as documented, and explain clearly what is happening. The parameters for the AndroidLoadControl within the AudioLoadConfiguration when creating a new AudioPlayer seem to have no effect on the buffering behavior. When setting minBufferDuration and maxBufferDuration to Duration(seconds: 6) for example, the audio will still buffer up to around 30 seconds in advance.

Minimal reproduction project Provide a link here: https://github.com/paul-blum/just_audio/tree/bug_report

To Reproduce (i.e. user steps, not code) Steps to reproduce the behavior:

1. Go to main.dart in just_audio/example/lib/main.dart and run it on an android emulator.
2. See how the song buffers to around 30 seconds and not to 6 seconds as specified in the AudioPlayer.

Expected behavior I want that the audio only buffers to the specified duration in advance.

Screenshots Why does it buffer to around 30 seconds when I specified 6?

Smartphone (please complete the following information):

• Device: Pixel 6 Pro API 33 emulator

Flutter SDK version

[✓] Flutter (Channel stable, 3.7.3, on macOS 13.2 22D49 darwin-arm64)
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.2)
[✓] VS Code (version 1.75.1)

Additional context My goal is not to use an URL as my audio source but a custom stream. So the buffering options should work for a StreamAudioSource too.

[ryanheise]

According to this comment ExoPlayer doesn't download exactly the amount of data to match your desired duration (it can't really do that since you never know how many bytes corresponds to what duration with compression involved). Instead, it downloads in 1MB chunks at a time, each time it decodes it and then looks at how much duration that was, and if it's greater than your max parameter, then it stops fetching more chunks. I assume that at your particular compression rate, 1MB corresponds to around 30 seconds of audio.

[paul-blum]

Thank you for your answer. Then why is the StreamAudioSource's request method called with start = null and end = null i.e. the entire audio? Shoulnd't it be called with end being only up to the amount of buffering?

[ryanheise]

No, the player does not make a separate range request each time it fills a buffer, it makes one request and while leaving that connection open, reads more from it as needed. Keep in mind also that the way that the player even knows whether the server is capable of range requests is from the response headers of that first request. If that first request indicates that range requests are supported, the next thing the player does is make a range request to fetch the metadata if it was not at the beginning of the file. Then if there is a seek to an unbuffered region, that first request might be cancelled and a new range request might be made to the new seek point. But it certainly does not make lots of little range requests for 200 kilobytes as playback progresses, it just continues reading from the same stream of bytes from the same connection until you seek elsewhere.

These would be two separate and unrelated issues, but since neither are bugs, I'll close this issue. If you need advice on how to implement your StreamAudioSource, you can lean on the community support on StackOverflow.

[paul-blum]

I am implementing my own StreamAudioSource and the request method is called when I seek like you mentioned. However, the other stream is not closed. The old stream will effectively fetch the entire audio. This is inefficient so how do I make sure the old stream is closed?

[ryanheise]

See #804 for a similar discussion - ExoPlayer in particular may leave the connection open in this scenario but just block its flow.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs, or use StackOverflow if you need help with just_audio.