[MPlayer-dev-eng] Re: [Alsa-devel] Problem with RME 9632 and Plug
Ed Wildgoose
lists at wildgooses.com
Thu Aug 5 08:50:33 CEST 2004
> 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
More information about the MPlayer-dev-eng
mailing list