OpenSL ES and playback position

[Celina Val]

Hi,

I've been implementing an audio player using Android OpenSL ES API with a
buffer queue, but I'm having trouble keeping track of the playback
position. I've tried the following:

- Use GetPosition() method from SLPlayItf: This approach is not reliable
because the position seems to be reset every time there's a buffer
underrun. See this old question
<https://groups.google.com/forum/#!topic/android-ndk/Ez5_nvAmhE8> for
more details. Is this a bug? The original question is from 2011, so my
guess is that it won't get fixed so soon.
- Register a callback with SLPlayItf: This approach works well for the
first track I play. However, it won't work again after I stop the player
and try to play from a different source. This is what I'm doing:
1. Set audio player to PLAYING state.
2. Wait till the audio is being played and the playback position
starts getting updated.
3. Set audio player to STOPPED state.
4. Clear the buffer queue.
5. Set the state to PLAYING.
6. Audio starts playing again, but the playback position never gets
updated (i.e., the callback function is never called again).


- I've tried to re-register the callback between step #4 and #5, and I
also tried to set the event mask to 0 and back to the initial
value, but no
luck so far, Am I missing something? Do I always need to
recreate the audio
player when I want to restart the audio?

Thanks,
Celina

[Glenn Kasten]

It might be a bug. Can you share a short code fragment that demonstrates
the problem?
Please also say which Android device and platform version you are using.

Another workaround might be for your app to keep track of the number of
buffer queue
callback completions, along with how many audio samples were enqueued for
each.

Post by Celina Val
Hi,
I've been implementing an audio player using Android OpenSL ES API with a
buffer queue, but I'm having trouble keeping track of the playback
- Use GetPosition() method from SLPlayItf: This approach is not
reliable because the position seems to be reset every time there's a buffer
underrun. See this old question
<https://groups.google.com/forum/#!topic/android-ndk/Ez5_nvAmhE8> for
more details. Is this a bug? The original question is from 2011, so my
guess is that it won't get fixed so soon.
- Register a callback with SLPlayItf: This approach works well for the
first track I play. However, it won't work again after I stop the player
1. Set audio player to PLAYING state.
2. Wait till the audio is being played and the playback position
starts getting updated.
3. Set audio player to STOPPED state.
4. Clear the buffer queue.
5. Set the state to PLAYING.
6. Audio starts playing again, but the playback position never gets
updated (i.e., the callback function is never called again).
- I've tried to re-register the callback between step #4 and #5, and
I also tried to set the event mask to 0 and back to the initial value, but
no luck so far, Am I missing something? Do I always need to recreate the
audio player when I want to restart the audio?
Thanks,
Celina

['Phil Burk' via android-ndk]

Hello Celina,

I've been implementing an audio player using Android OpenSL ES API with a

Post by Celina Val
buffer queue, but I'm having trouble keeping track of the playback
position.

You might want to try the new Oboe API. It uses AAudio on newer versions of
Android and OpenSL ES on older versions. In the new AAudio code, the
playback position is tracked as a 64-bit frame counter that is never
reset. For OpenSL ES, we try to emulate AAudio as best as we can. Oboe is
where are actively trying to address these kinds of issues.

https://github.com/google/oboe

Post by Celina Val
- Use GetPosition() method from SLPlayItf: This approach is not
reliable because the position seems to be reset every time there's a buffer
underrun. See this old question
<https://groups.google.com/forum/#!topic/android-ndk/Ez5_nvAmhE8> for
more details. Is this a bug? The original question is from 2011, so my
guess is that it won't get fixed so soon.
That is being tracked internally at b/22628197

It will not get fixed for old versions of Android. For future versions of
Android you can use AAudio through Oboe and avoid the problem.

Phil Burk

3D46NJAoQnzod3EAksKJwCBQXLprXA%40mail.gmail.com
<https://groups.google.com/d/msgid/android-ndk/CAOsb_O%3DAj2qoHC%2BtLW0%3Dz%3D46NJAoQnzod3EAksKJwCBQXLprXA%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Celina Val]

Thanks for the quick responses!

Glenn,

I've tried on android emulator with API level 23 and 27. I'll see if I can
create a small testcase that shows the problem.

Indeed, I can estimate the playback position according to the buffer queue.
I was hoping I could just use one of the methods provided by the OpenSL ES
API.

Phil,

Unfortunately, Oboe is not an option right now.

Thanks,
Celina


On Thu, Jul 12, 2018 at 8:54 AM, 'Phil Burk' via android-ndk <

Post by 'Phil Burk' via android-ndk
Hello Celina,
I've been implementing an audio player using Android OpenSL ES API with a

Post by Celina Val
buffer queue, but I'm having trouble keeping track of the playback
position.

You might want to try the new Oboe API. It uses AAudio on newer versions
of Android and OpenSL ES on older versions. In the new AAudio code, the
playback position is tracked as a 64-bit frame counter that is never
reset. For OpenSL ES, we try to emulate AAudio as best as we can. Oboe is
where are actively trying to address these kinds of issues.
https://github.com/google/oboe

Post by Celina Val
- Use GetPosition() method from SLPlayItf: This approach is not
reliable because the position seems to be reset every time there's a buffer
underrun. See this old question
<https://groups.google.com/forum/#!topic/android-ndk/Ez5_nvAmhE8> for
more details. Is this a bug? The original question is from 2011, so my
guess is that it won't get fixed so soon.
That is being tracked internally at b/22628197

It will not get fixed for old versions of Android. For future versions of
Android you can use AAudio through Oboe and avoid the problem.
Phil Burk
3D46NJAoQnzod3EAksKJwCBQXLprXA%40mail.gmail.com
<https://groups.google.com/d/msgid/android-ndk/CAOsb_O%3DAj2qoHC%2BtLW0%3Dz%3D46NJAoQnzod3EAksKJwCBQXLprXA%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/
msgid/android-ndk/CACL%3DQ7zpy4URSyRcu4h7Ers0PtF%
2BNsu%2B_h0phMou9OaCU%3DhKHA%40mail.gmail.com
<https://groups.google.com/d/msgid/android-ndk/CACL%3DQ7zpy4URSyRcu4h7Ers0PtF%2BNsu%2B_h0phMou9OaCU%3DhKHA%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

--
Celina