Julian Gronau wrote:
> --- Weitergeleitete Nachricht / Forwarded Message ---
> Date: Sun, 21 Dec 2003 21:22:33 +0100 (MET)
> From: "Julian Gronau" <juliangronau <at> gmx.net>
> To: gabor <gabor <at> z10n.net>
> Subject: Re: Fw: [xine-devel] adding alsa dmix support where to start?
> 
> 
>>On Fri, 2003-12-19 at 08:59, James Courtier-Dutton wrote:
>>
>>>xine will not work with the dmix device due to lack of proper buffer 
>>>status feedback accuracy.
>>
>>so you are saying that dmix is broken in alsa?
>>should someone send a bugreport to the alsa guys?
>>
> 
> THIS IS NOT A BUG!!!
> DMIX doesn't SUPPORT, that applications are able to change the
> buffer-settings. This is not a problem for XMMS for example. The point is
> that xine is
> using very strang buffer sizes, which are not producing proper sound on most
> soundcards, when using DMIX. My problem is that I don't exactly know why the
> sound is choppy. Xines Bug (not realizing to be able to change the
> buffer-settings) is not the real problem. There are ways to fit the buffer
> sizes. The
> sound is much better after this operation, but still a little bit choppy.
> And it
> is now a little bit choppy in XMMS, too. (Because XMMS has now to use this
> strang buffer_settings, too) But the buffer_settings, Xine makes, are less
> or
> more the same as on hardware-devices. But on hardwaredevices the sound is
> performing well.
> 
>  

It has NOTHING to do with buffer and period sizes. It is the values 
returned from the "snd_pcm_delay()" function that are problematic.

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click