Delayed startup of audio stream

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Delayed startup of audio stream

triathlon
Hi all, I'm streaming audio from a live source and both in Java and JNI the start of playback is delayed unnecessarily, it's a low bitrate stream and it appears there is a threshold baked into the player that needs to be fulfilled before any playback starts see here: 
http://code.google.com/p/android/issues/detail?id=29870
and here
http://stackoverflow.com/questions/10060165/android-mediaplayer-buffer-size-in-ics-4-0

In api level 16 we get MediaCodec in Java which I assume would resolve this (using AudioTrack for playback) but OpenSL ES seems to have supported decoding audio to PCM since level 14. 

Just wondering, before I go down this route, whether the baked in threshold of the SL player also applies when you are only using the player for decoding or is this a way to bypass that threshold?

Atli.

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/3p-XhTUoTPkJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: Delayed startup of audio stream

triathlon
To clarify, this only occurs with AAC streams. I am demuxing an FLV stream and trying to use native playback on the output instead of FFMPEG->AudioTrack which is what we had pre 4.0.

The demuxing is done by an onboard http proxy so the Mediaplayer connects to a localhost url.

This works well for MP3 streams and playback starts within 3 seconds but AAC (with ADTS headers) takes between 8-12 seconds to get started and that's only if we omit the Content-Length header of the response. If we provide a huge Content-Length (as seems to be the norm for http streaming) then AAC doesn't start up for 1-2 minutes. The same occurs if we are streaming low bitrate AAC, it takes 1-2 minutes to get started instead of 8-10 seconds. This leads me to believe that there is some hardcoded size threshold.

Anyways, I was hoping that we might bypass this logic if we used the ndk audioplayer as a decoder only, I was hoping someone would know the answer to that but I guess I'll just have to test it myself.

Atli.

On Saturday, December 1, 2012 12:26:29 PM UTC, triathlon wrote:
Hi all, I'm streaming audio from a live source and both in Java and JNI the start of playback is delayed unnecessarily, it's a low bitrate stream and it appears there is a threshold baked into the player that needs to be fulfilled before any playback starts see here: 
and here

In api level 16 we get MediaCodec in Java which I assume would resolve this (using AudioTrack for playback) but OpenSL ES seems to have supported decoding audio to PCM since level 14. 

Just wondering, before I go down this route, whether the baked in threshold of the SL player also applies when you are only using the player for decoding or is this a way to bypass that threshold?

Atli.

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/aoDqqJlZG7wJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.