Obsolete
Status Update
No update yet.
Comments
do...@gmail.com
[Comment deleted]
cp...@gmail.com
Agreed it's embarrassing how long this bug has been open.
I'm not sure if there's any danger of crashing if we close our AudioTrack early (possible), but there certainly is the potential to cut off the sound before it is done playing.
So far I have had good luck with this workaround:
1. create AudioTrack
2. do playback by enqueuing N audio frames (either static or streaming)
3. continue to enqueue silent audio frames indefinitely
4. playback is done when AudioTrack.getPlaybackHeadPosition() returns >= N
Step 3 appears to be required because there is some bug in the implementation of AudioTrack.getPlaybackHeadPosition() such that it will NEVER advance to >= N unless you enqueue more than N audio frames.
Sigh.
I'm not sure if there's any danger of crashing if we close our AudioTrack early (possible), but there certainly is the potential to cut off the sound before it is done playing.
So far I have had good luck with this workaround:
1. create AudioTrack
2. do playback by enqueuing N audio frames (either static or streaming)
3. continue to enqueue silent audio frames indefinitely
4. playback is done when AudioTrack.getPlaybackHeadPosition() returns >= N
Step 3 appears to be required because there is some bug in the implementation of AudioTrack.getPlaybackHeadPosition() such that it will NEVER advance to >= N unless you enqueue more than N audio frames.
Sigh.
iz...@gmail.com
I tried to reproduce bug. Seems all working correctly. Maybe android developers forgot to change status of issue to resolved.
iz...@gmail.com
I take my words back. Audiotrack full of bugs..i can't even normally stop or pause track..
gk...@android.com
sa...@google.com
Thank you for your feedback. We have tried our best to address the issue reported, however our product team has shifted work priority which doesn't include this issue. For now, we will be closing the issue as "Won't Fix (Obsolete)". If this issue still currently exists, we request that you log a new issue along with the latest bug report here: https://goo.gl/TbMiIO and reference this bug for context.
Description
that nothing is being played. This is counterintuitive and makes the whole
state thingy totally useless, since the state seems to be changing only
when you explicitly change it by calling play(), stop() or pause().
I'm not really sure if this is implementation issue, or just sloppy
documentation, but I'd like to have a way to query the real state of sound
playback. This issue, together with
totally useless for any non-trivial usage (actually, the way to reproduce
for all of those bugs is trivial).
Steps to reproduce:
1. create AudioTrack (STREAM_MUSIC, MODE_STATIC)
2. start playback
3. wait until playback finishes and call getPlayState()
Expected results:
getPlayState() should not return PLAYSTATE_PLAYING, since nothing is being
played.
Observed results:
getPlayState() returns PLAYSTATE_PLAYING, despite the fact that nothing is
being played.