-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When is sound actually heard/outputted? #7577
Comments
I think your assumptions about what is happening are correct - @andrewlewis may be able to verify in more detail. It's a known issue that the playback time (as dictated by the actual There is one way you can determine the actual start position of playback, but it can be only be determined after playback already started. If you wait for short duration after
They are (by this definition) not correct in absolute terms, but note that the part you are not measuring is also not within your or our control and will have the same additional offset in all cases. if you are worried about measuring improvements and seeing trends, then |
Closing because the question was answered above. Feel free to reopen if not. |
Currently the audio renderer can become ready before the AudioTrack actually has enough data to play something, which means that the player may transition to the ready state before audio starts playing. This makes the player's current state transition not very useful for detecting when audio actually starts playing. This change adds a new event to notify apps when the audio position is increasing after a pause or seek/flush/reset event, and includes an estimate of the system time at which audio playout started. Issue: #7577 PiperOrigin-RevId: 327810040
[REQUIRED] Searched documentation and issues
[REQUIRED] Question
I did some testing in the sample app, to figure out when sound was actually heard/outputted. It seems to me that
onPlayerStateChanged()
withSTATE_READY
and/orisPlaying()
callbacks are received before sound can actually be heard. This is especially noticeable when we increase theAudioTrack
buffer, where the aforementioned callbacks can be received up to 500 ms before actual sound can be heard(depending on the buffer size). While this is easiest seen with a bigger buffer, it is also happening with the default settings, making our metrics for startup time incorrect.My experience is that sound is actually heard when the
AudioTrack
fills up its buffer(for the first time).Is my assumption correct?
If so, does it make sense to create some kind of callback
isSoundOutputted()
to better give us the true startup time of an asset?Note: If this is true, then the information in https://exoplayer.dev/listening-to-player-events.html#player-state-changes is ambiguous, depending on what "immediately play" means in this context: "Player.STATE_READY: The player is able to immediately play from its current position."
A full bug report captured from the device
N/A
Link to test content
Play whatever content you want.
The text was updated successfully, but these errors were encountered: