[MPlayer-dev-eng] Re: [Alsa-devel] Problem with RME 9632 and Plug

[Ed Wildgoose]

> yes seems to be really a bug. hm..
> i just thought that you add your changes to one of the abs cases, as a 
> special case for your rme-card, cause current defaults seems to work 
> well for the most of cards.
> i don't think that a heuristic aproach to figure out periods and 
> period-size would be the best thing, when we do it it should be pretty 
> fast or another alternative. setting the buffersize very large doesn't 
> seem to hurt the other way around it does.


"-abs" says deprecated so I don't think this is a workaround that we 
should be persuing.  Come on now - be bold - fix the problem don't lets 
add workarounds.  If there was a real risk that these values were 
somehow very carefully chosen, then there is an easy fix which is simply 
to use the ALSA probe functions to examine the capabilities of the 
device first! 

However, in reality the code picks a buffer size of 16 x 1024 samples = 
1/3 sec latency.  This also uses roughly 32Kb of buffer on most 
chipsets.  I would be suprised if this wasn't roughly the largest buffer 
that most chipsets could actually accomodate!  I know for example that 
my RME 96/8PAD can only do 8 x 2048, (and curiously ends up at this 
setting when we ask for 16 x 1024...)

Because we are using the set_near functions there, then trying to set 
even something mad like 16 x 8192 buffer sizes will likely give the same 
practical answers on most cards.  For example on my builtin Intel8x0 I 
move from 16 x 1024 to 4 x 4096 and 2 x 8192 depending on what I ask for. 

> i didn't tried your patch till yet, im curios if your delay settings 
> work for me, i doubt it and guess thats the reason for your seeking 
> problems. at least i have no glue why the delay settings are on the 
> current values. i think thats the best 'experimental' defaults for 
> oss, cause oss was at first the only, and later the most used ao.
> but does audio work for you now with changed settings, apart from the 
> seeking problem?


Why do you doubt those settings would work for you?  I think these 
settings will just slightly increase the max buffer for most people, but 
actually most people would have been maxed out on their soundcard 
buffers already, so I doubt it would have increased any practical buffer 
sizes for anyone.

The alsa output layer uses "snd_pcm_drop" in the reset function which 
should zap the entire buffer when seeking or pausing.  So there should 
be no change in behaviour whether we have 1/3 sec latency or 5 sec 
latency?  Perhaps the OSS doesn't do this (no, actually just checked the 
code, and it looks like it closes and reopens the device to presumably 
zap everything?)

I doubt these were the "best" experimental defaults.  It's likely that 
as per most audio apps, someone started with something that worked for 
them and then gradually bumped them up a bit as people reported 
problems...  Now I am reporting that latency is quite low on a 9632 
(Jaroslav said something similar might happen with the CS46xx), and 
would ask to bump up the buffer size a bit more.  Right now latency for 
me is a mere 4ms.  Changing the buffer size to 2048 would at least give 
me 8ms

HOWEVER, all of the above is a nice to have!  The fix is the change to 
the sleep code.  If I make that change alone then even with 4ms latency 
and 2 x 1024 buffers I can use mplayer happily even with heavy 
background activity (I guess kernel 2.6 is finally getting this latency 
stuff cracked!)

You suggest that my changes could be causing the probs on seeking?  Well 
no doubt you are right, but I only picked up the code yesterday so you 
would know more than me.  However, it seems to me that the main loop 
does this:

Seek
Prime Audio
Wait for video frame to become due
go to top of loop again

Now with cards that have a lot of latency that sleep code will indeed 
wait until the video frame is shown.  However, with my change it has the 
option to do a partial sleep to avoid the buffer underrun, and hence it 
never displays the video frame and tries to go around the loop again, 
which then moves us forward a frame, and we get the same issue next time

Notice that this shouldn't have changed anything for anyone else, it's 
purely a fix for people who would otherwise never have enough latency in 
the audio buffers to be able to sleep for a whole video frame.  ie it 
only affects people with frame buffers smaller than about 4 x 1024 (at 
24fps), or 2 x 2048.

It could be fudged to make the sleep check more aggressive by checking 
audio buffer periods, but I think the answer is actually just to notice 
when we are in fast forward mode and handle appropriately.  Perhaps 
someone could tell me whether there is already a flag set when we are 
jumping around?  The answer then would be just to pop this into the IF 
statement and ignore the resulting audio underrun...

I will work on this last bit, but please consider committing the other 
parts.  It would be most useful to commit the changes to the sleep code, 
but perhaps we can compromise on the audio buffer stuff and shoot for 16 
x 2048 instead?

Thanks

Ed W