> > I don't think that this would be useful, I believe the main aim is to
> > reduce the kernel/user data transfer.
>
> An mmap'ed audio driver sounds pretty weird to me.  Yes, you can
> make use of it to reduce the kernel/user data transfer, but you
> can do that the other way around.  I usually mmap the file to play
> and then do a write of the whole file.

This is fine when you're interested in just "playing" a sound file off of 
disk.  In that case you wouldn't want to use a mmap of the audio driver's 
DMA buffer.  But, games like Doom & Quake need to respond to events in 
real-time with sound, and mmap is a big win in this situation.

The traditional way of handling this is to fork off a soundserver.  The 
soundserver is responsible for sitting in loop outputting very small 
chunks of audio (say 128 bytes).  Assume you are you're playing 8khz sound, 
and someone in doom shoots at you.  The Doom game engine signals the 
soundserver that you were shot at, and the soundserver will send the data 
out to the audio device.  You will hear the sound in about 128/8 = 16 ms 
which is acceptable, but unfortuantely to perform this well the 
soundserver needs to wakeup send data out every 16ms (which takes 
generally takes about 5-15% of your CPU cycles).

With an mmap-ed audio device, [I imagine] you would have the actual audio 
DMA buffer in your user space.  This allows the Doom game engine to just 
place the audio that needs to be played directly into the buffer, thus 
saving the fork-ed soundserver process.


> 	-- Lennart

Sujal