[vlc-devel] [WIP PATCH] audiotrack: improve perfs, make it asynchronous

[Thomas Guillem]

On Fri, Feb 13, 2015, at 18:25, Rémi Denis-Courmont wrote:
> Le vendredi 13 février 2015, 17:36:10 Thomas Guillem a écrit :
> > Previously, the module waited for the buffer to be fully written, therefore
> > p_aout->play function took too much times.
> 
> There is no such thing as play taking too much time. Decoding audio
> samples 
> before they can be queued to the underlying audio output has no
> advantages, 
> and one disadvantage: it increases the latency of audio filters.

And this latency of audio filters can cause the video frame drop I got ?

> 
> > Now, the module send all buffers in a queue and don't wait for them.
> 
> I believe there is a bug in the ES output buffering code, where slow
> audio 
> interferes with video. That is not an issue with the Android audio
> output.
> 
> > AudioTrack delay is now set by JNIThread when a buffer is written.
> 
> I can play audio on PulseAudio or ALSA with 2 seconds advance with no
> problems 
> quality or stability whatsoever. This is currently the somewhat arbitrary 
> maximum enforced by the decoder thread, and it can easily be triggered by 
> increasing caching above 2000 ms.

Ok, I did a test on my desktop, I have 400ms of delay with PulseAudio.
For me, having 1600ms of delay, on the few devices I tested, is to close
to the 2000ms limit.

> 
> Assuming that the audio output can do it, that is more stable and could
> enable 
> better power efficiency by increasing the audio period duration. The only
> issue 
> is the unbearable latency when live-tuning the audio filters, as
> mentioned 
> above. PulseAudio, and some but not all ALSA drivers, support this. I
> gather 
> that your target does not.

So, maybe there is a right balance between queuing all buffers and just
one. I tried having Play() waiting when there is more than 15 buffers
queued. With that I have around 500ms of latency and no more frame drop
or audio drift.

> 
> > [7a7ec2f4] core audio output: playback too late (60664): up-sampling
> > [7a7ec2f4] core audio output: resampling stopped (drift: -393 us)
> > [7a7ec2f4] core audio output: playback too late (63506): up-sampling
> > [7a7ec2f4] core audio output: resampling stopped (drift: -12040 us)
> > [7a7ec2f4] core audio output: playback too late (67178): up-sampling
> > [7a7ec2f4] core audio output: resampling stopped (drift: -4072 us)
> 
> This rather looks like the audio buffer is too short rather than too
> long.
> 
> Or the computation in TimeGet() is off.

I don't see these warnings anymore with my new patch (with a limit of 15
buffers queued). But you may be right, calculating delay with AudioTrack
is a little hackish (but lyp sync is still better than with opensles). I
just saw that there is a new way to calculate latency since API 19:
http://developer.android.com/reference/android/media/AudioTrack.html#getTimestamp%28android.media.AudioTimestamp%29
.
I'll try that on monday.

> 
> > I think it's caused by a too big delay.
> 
> Don´t do that then. Let play() sleep when it needs to.

And thanks for your comments.

> 
> -- 
> Rémi Denis-Courmont
> http://www.remlab.net/
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel