virtual sound device ? was[Feature Wish] GGI in Linux 2.3

Caolan McNamara (
Mon, 19 Jan 1998 14:39:52 -0000 (GMT)

>Re: [Feature Wish] GGI in Linux 2.3
>linux kernel account (
>Fri, 16 Jan 1998 08:37:37 -0500 (EST)
>What would probably be more useful would be a userspace daemon that
>controls sound access amoung multiple programs, facilitates network sound,
>hopefully it would also allow software mixing so that multiple programs
>could do wav output at once, and have dynamicly pluggable codecs (so that
>it would simplify programmers lives, and make network sound work without
>crushing the network)..
This is something that id be interested in, a userspace daemon that
mixes sound from incoming apps and forwards it on to either
soundcard or network. I signed up to the mailing list only a day or
two ago to see if i could track down any work in this area.

>I think this would be a very important development, and it's something
>that would tie well with GGI.. It would not really need any kernel changes
>though, just app changes..
I had visualized a "virtual device" /dev/audio that was controlled
by a userspace daemon that passed on the preprocesssed audio
to the existing /dev/audio1 belonging to the current soundcard code. Well
to be exact i wondered about a kernel side device driver stub that
offloaded the work to a daemon like kerneld. Is anyone explicitly working on
anything of this nature ?, preferably something better :-). If not ill go
ahead and fart about with it for a while. My future masters work would
benefit from such a beast so i have a good motivation for wanting a dev
audio that i can use simultaneously from various apps. As a virtual
/dev/audio it shouldnt need any changes to existing apps. i havent
looked too deeply into the practicality of all this, just looking at
possibilities and various options, anyone got any useful pointers or
ideas ?

>On 16 Jan 1998 wrote:
>> Hmm...I was thinking along the lines of the old GGI argument of "sound
>> drivers get into the kernel, so why not graphics?" (approximated and
>> condensed for your convenience)
>> Now, thinking about the GGI issues of: a KGI, which defines access to
>> the hardware, and libGGI, which contains routines for using that access
>> (correct me if I'm wrong on this). Shouldn't sound behave similarly?
>> That is, a KSI which opens for accessing the audio hardware, and a
>> libGSI (or whatever). I admit to not knowing about how the sound
>> driver(s) is implemented in the kernel, but couldn't this allow stuff
>> like multiple sound cards (``multi-mouthed'' systems)? Wouldn't it
>> simplify the kernel, and move stuff into userspace?
>> Am I totally lost at sea here?
>> ~kzm
>> --
>> If I haven't seen further, it is by standing in the footprints of giants


Real Life: Caolan McNamara * Doing: MSc in HCI
Work: * Phone: +353-61-202699
URL: * Sig: randomly chosen oblique strategy
Is it finished?