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

[Jan Knutar]

On Tuesday 24 August 2004 01:06, Ed Wildgoose wrote:

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

> 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 :-)

> cards have quite large audio buffers these days actually.  What is your 
> card anyway?

Oh, an old creative pci card. goes by name of ens1371 in alsa.

> ... 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,
I guess I wouldn't expect the mplayer developers to be able to review
the patch very quickly and apply/reject.