Sharing sound hardware

Colin Walters walters at redhat.com
Mon Feb 7 16:01:47 UTC 2005


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.





More information about the fedora-devel-list mailing list