Skip to content
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

Closed
kgrevehagen opened this issue Jul 2, 2020 · 2 comments
Closed

When is sound actually heard/outputted? #7577

kgrevehagen opened this issue Jul 2, 2020 · 2 comments
Assignees
Labels

Comments

@kgrevehagen
Copy link

kgrevehagen commented Jul 2, 2020

[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() with STATE_READY and/or isPlaying() callbacks are received before sound can actually be heard. This is especially noticeable when we increase the AudioTrack 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.

@tonihei
Copy link
Collaborator

tonihei commented Jul 3, 2020

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 AudioTrack play position) isn't starting to move until shortly after the player state becomes STATE_READY. Unfortunately, there doesn't seem to be a way to know exactly when the AudioTrack starts outputting sound and STATE_READY only means that the audio renderer is ready to play (i.e. we can call AudioTrack.play and have enough buffer to expect playback to start).

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 isPlaying() becomes true (e.g. 1000ms), you can check the current player position (Player.getCurrentPosition, e.g. 800ms) and the subtract it from the current time to know when the audio track actually started playing. In my example, this would be 200ms after isPlaying() became true. This is correct within a few milliseconds, as you can verify by repeatedly using this method. Values we've seen are usually in the range of 100ms. Note that you need to take into account the playback speed, if applicable.

making our metrics for startup time incorrect

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 isPlaying() should still provide a good value because it captures all the parts you can control.

@tonihei
Copy link
Collaborator

tonihei commented Aug 3, 2020

Closing because the question was answered above. Feel free to reopen if not.

@tonihei tonihei closed this as completed Aug 3, 2020
kim-vde pushed a commit that referenced this issue Aug 26, 2020
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
@google google locked and limited conversation to collaborators Oct 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants