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