[MPlayer-dev-eng] Patch: Low latency audio enhancements

[Ed Wildgoose]

>>It shouldn't touch any of the sound code at all.  All it does is change 
>>the sleep code in the main loop.  At the moment mplayer knows not to 
>>wait more than 60% of the total buffer time.  However, this means you 
>>might have 1 buffer + 1 sample, which is less than 60% of two buffers - 
>>oh and my card has a driver which only shows free space in terms of 
>>whole buffers.... So occasionally (once a second), we wait too long...
>>
>>I changed the wait to 25%, which means that we will spin around up to 
>>twice for each buffer, should be plenty enough.  In practice cards with 
>>more than two buffers will likely never reach the 25% mark. 
>>    
>>
>
>Hm. If I understand this correctly, mplayer will just refill the buffers more
>often with your patch?
>  
>

Exactly.  Nothing further.


>>Can you describe what you are seeing and I will look into the code.  So 
>>far the alsa stuff looks pretty standard though - I can't see anything 
>>there which might cause any problems.  The A/V sync looks a little 
>>crazy, but seems to work ok in practice.
>>    
>>
>
>I get 'xrun' messages from alsa-lib, and the sound stutters. Strangely enough
>I'm unable to trigger this at all regardless of what system activity I start in
>the background while viewing a movie with mplayer -ao oss. I suspect it's 
>PEBKAC problem with my alsa setup though :-)
>  
>

Can you please run mplayer with "-v" and report what number of sound 
buffers and size you are using?  If necessary (can't remember) add some 
debug lines to the libao2/ao_alsa.c code to spit these numbers out 
directly.  If you find that "NumBuffers * BufferSize" is less than about 
8192 then you will likely be having the same problems as me.  4096 is 
marginal, and at 2048 you are in trouble

If so then you should find that my patch fixes this for you...?


>>... in conclusion though...
>>
>>Is this code suitable for commit?  If there is any other audio stuff 
>>that you want me to look at while I am in here, then happy to do so.  
>>I'm otherwise going to look at fixing up the Jack stuff because I need 
>>it to hook in Brutefir for some digital filtering that I want to do.
>>    
>>
>
>Sorry, I'm not qualified to comment on suitability.
>
>While video blitting doesnt seem to care one way or another if it gets
>executed before its time, i'm now a bit worried about teh event reading.
>What was your reasoning for skipping going through that? As far as I
>can tell, in plain mplayer, it would get executed every frame, or every
>time audio buffers were filled, whichever was more often. The latter
>much more likely on low fps video. Does this cause problems? What
>about after patch, would the delayed handling, in case of low fps video,
>cause problems?
>I wonder how key presses are handled, are they buffered somewhere
>so that low-fps video with sound get nice and quick response to
>lower/increase volume keys? Sigh, main[} is a bit too complex,
>  
>

To answer your question, what should happen for most people is that the 
main loop spins once for each frame. 

For each loop you load up the audio buffer, then *wait* until the frame 
is scheduled to be displayed, then you show the frame, then check for 
keypresses, then back to the top.

So the latency of key presses is the same as the framerate.

There is an exception to the above.  If the "wait" code notices that the 
audio buffer would underrun while we are waiting for the frame to become 
due, then it cuts the wait time.  However, this leads us to read the key 
presses earlier than we would do otherwise.  Nothing particularly wrong 
with this, but it means that if you are holding down FF, then the frame 
never gets scheduled for display because each time around the loop we 
cut the wait time, don't show the frame, read the key press, FF a big, 
and go around the loop again

What my patch did was when we cut the wait time it goes straight back to 
the top of the loop and refills the audio buffers.  In this way the flow 
of code should be the same for normal users and also those with small 
audio buffers.

Seem fair enough?

I would propose that multiple threads are considered to simplify 
main().  This would remove a fair bit of junk and make the code patch 
visible.  On the other hand multiple threads create their own issues.

>I guess I wouldn't expect the mplayer developers to be able to review
>the patch very quickly and apply/reject.
>  
>

Shame.  It's only a 5 liner or so.

If some people could at least apply it and confirm that it doesn't break 
anything then this would be helpful and might make it possible to 
commit?  Please give me some more feedback on your XRun problems and 
whether this patch helps

Thanks

Ed W