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

[Ed Wildgoose]

Jan Knutar wrote:

>On Monday 23 August 2004 19:30, Ed Wildgoose wrote:
>  
>
>>Hi folks,
>>
>>What do I need to do to try and get this code included please?  It's a 
>>pretty trivial patch, but it allows mplayer to work with audio cards 
>>that only have a two period sound buffer.
>>    
>>
>
>What effect does this patch have on previously unbroken cards that
>allows more than two period sound buffer?
>  
>

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. 

The second fix though (and this applies even if you left the code at 
60%) is that *if* it doesn't wait the full time until frame display, 
then it loops through all the rest of the main loop code and listens to 
key presses, etc.  Due to the way the fast forward code works this means 
it never draws a frame on FF/RW.  What I did was get it to go straight 
back to the top of the loop if we are still waiting and feed the audio 
buffer again.  This should mean the code path is now nearly identical 
for cards that don't have buffers long enough to wait a whole frame, and 
those which do.

The other bit of the patch fixes a minor gremlin which might bite 
someone changing the alsa code - a variable is needlessly reset to 
defaults and hence overrides some defaults set elsewhere.

No audio buffer sizes are changes, and there is little reason to thing 
people with large audio buffers will even notice the difference.


>The reason I ask is that for some reason, OSS output (through alsa's
>oss emulation) seems to work better than -ao alsa, even -ao esd works
>better. I suspect this is because -ao alsa uses smaller driver size buffers
>than -ao alsa? Does your patch reduce these even further?
>  
>

Nope, sorry.  I did suggest a patch in the opposite direction earlier 
on, but didn't follow through.

I doubt that smaller buffers are the answer though, unless there is a 
problem with the card showing free space. 

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 haven't found a way to figure out what period size my sound card has,
>infact, I can't seem to find much documentation on alsa at all, apart
>from the mostly empty wiki :)
>  
>

Run mplayer with -v and it tells you when it sets the values.  It will 
default to using 1024 sample buffers unless you use the (hidden) 
options.  Using memory map mode drops it to 512 samples by default.  
This is pretty low.

The Alsa wiki is overflowing with stuff, you haven't looked for a while 
I think.  Alsa docs suddenly got hugely better about 12 months ago.

Most cards have variable period buffers from 512 bytes to 4096 bytes and 
often more than that.  You can usually have quite a few buffers as well 
- only a few cards like my pro audio card have two buffers.  Typically 
cards have quite large audio buffers these days actually.  What is your 
card anyway?


... 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.

Thanks

Ed W