Just a general comment on dmix/dsnoop.
1) It is not bug free yet. I have an application that fails when one tries to use it. (xine.sf.net). I have not had time to establish why yet. E.g. xine using "front" device, output's stereo sounding perfectly. I note down the buffer and period sizes and rate and sample format being used for "front" and set "dmix" to use the same via the alsa.conf file.
But playing with "dmix" causes the sound to stutter, as though only every second period is being played, with zero samples in between.
When I get a moment I will investigate further the exact cause. Initially I thought it was a buffer/period size problem, but I have checked that, and that is not the problem. The next TODO test I will do will be testing the snd_pcm_delay() returned from the dmix device, and compare it's accuracy with "front".
2) For smart dmix/dsnoop to be really user friendly, we will need a version of it that works in full duplex. I.E. Multiple applications able to record the same stream as well as play to it at the same time.
3) If one application wishes to play to "surround51" and a different application wishes to play to "front", dmix will have to be clever enought to mix the two.
4) If one application wishes to play to "front" and a different application wishes to play to "rear", the mixer should be able to mix to get 4 output channels.
5) I think that this sound mixing problem might be better served by sound servers like jack.
6) software mixing is ok, but software resampling is not a good idea to do in alsa-lib, because a) It cannot do good quality resamplings because t is trying to keep latency low. b) A audio/video application could do resampling better because it could do it at the decoding stages, before latency and audio/video sync is a problem.
7) For mixing, each open of the alsa multi-open device should have it's own volume control per open, and not just the hardware backend volume controls. The application could easily control their own volume, without effecting other application's volume.
Summary: -
An application should be able to use device names like "rear", "front", "surround51" and then have a separate control to tell alsa whether it is allowed to do resampling or not. Then at least the more advanced application could decide for itself whether to use alsa-lib's low quality resampler, or implement it's own multi-tap interpolation filter.
For a video/audio application like xine.sf.net, being able to open the alsa device in such a way to ensure we know where the sound will be routed(which speakers sound will come from) is useful.
Cheers James
------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
