[MPlayer-dev-eng] Alsa output issue with rme9632 (small buffers)

Zsolt Barat barat at medien.uni-weimar.de
Wed Aug 4 17:30:55 CEST 2004


Ed Wildgoose wrote:

> I have an RME 9632 card that I would like to use with mplayer.  The 
> problem is constant underruns, and the cause seems to be as a result 
> of the 9632 only supporting a two period buffer which defaults to 1024 
> samples long (ie very low latency).
>
> The two period restriction is a hardware limit, and so I have worked 
> around this by changing the defaults for the code which sets fragment 
> sizes.  I adjusted the fragment_size to 4096 and compensated a little 
> by dropping the number of buffers down to 8 (from 16).  I should 
> imagine that this will still be quite satisfactory for most people, 
> and might help other people with restrictions on the number of period 
> buffers.  I didn't drop it below 8 because there are at least a couple 
> of cards like the RME96/8 PAD which can only do 8 periods as their 
> restriction...
>
> Secondly there are still a few remaining dropouts, and this seems to 
> be down to the code which sleeps as part of the main video output 
> loop.  It's correctly checking to see if the sleep might cause the 
> audio to underflow, but it checks for "time_frame>delay*0.6" - clearly 
> in the case of a 2 period buffer we will occasionally have less than 
> 0.1 of the second buffer in use..  So I have changed the test to keep 
> the audio buffers at least 40% full.
>
> Diff is below.  I would be grateful if people could test this and 
> commit if appropriate.  There is one bug remaining/introduced - when I 
> fast forward with the 9632 card the code is skipping forward OK, but 
> the screen stays frozen until I release a key - however, with other 
> cards that have longer buffers, then the code skips forward and draws 
> a fames at high speed like it did before.  I imagine this is something 
> to do with the way the sleep code interacts with the frame drawing 
> code, but it shouldn't affect anyone else I don't think?  Perhaps 
> someone else could point out what I did wrong and fix that remaining 
> issue?
>
hi,
setting different periods and periodsizes is still possible in current 
ao_alsa/mplayer. see my mail to the alsa-devel-list. your changes should 
be put there. what to do about the delay changes? i currently don't now. 
this whole delay thing looks hackish to me. probably another supopt 
should be added cause im afraid that this hw-setup wont work with other 
(consumer) cards.

regards

Zsolt




More information about the MPlayer-dev-eng mailing list