Subject: Re: a mmap'able audio device??
To: Lennart Augustsson <email@example.com>
From: Sujal Patel <firstname.lastname@example.org>
Date: 03/04/1996 09:27:54
> > 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