On Fri, 2005-02-04 at 18:10 -0800, Ryan Gammon wrote: > The alsa api, while pretty complex, gives good access to all the > features a given piece of hardware supports. The fact that alsa has an > awareness of the hardware it's running on gives it the ability to > (eventually) be smarter when it comes to things like mixing in hardware > vs mixing in software. Right; a number of us feel that it makes the most sense to have software mixing below the ALSA API, so that app writers don't have to make a choice between accessing card features and sound mixing. > I did some playing around with dmix last year when I was touching up > helix's alsa support, and found it to be pretty buggy on the alsa side. Yeah. > Some of this may be incorrect, but as I recall: > > 1. libasound forks what is basically a sound server process when the > sound device is first accessed, but it does not exec. This was not > working well with helix -- by the time helix opens the sound device, it > has several threads running and a number of plugins loaded. Alsa's mixer > process was hanging when forked from helix, for reasons I never figured out. Ultimately we may need a real sound server and protocol below ALSA based on something other than shm, so that there can be better access control for multiple users and also for networked sound. > I'm very interested in what others are thinking here for fedora, be it > alsa-related or otherwise. My personal feelings are that we should try it as the default in Fedora rawhide for a while, get a good sense of what bugs there are, and back off near the end of the FC4 cycle if there are too many. And if there aren't, then we've taken a big step forward on fixing one major user-visible pain that I'm sure every Linux user has experienced.
