> It's better to use write(2) for this purpose. Often, yes, but not, I think, always.
> [...], mmap'ing audio device does not lead to improve any performance > or latency. Then something is wrong. (a) It's the rare port on which copying to mmap()ped memory is no faster than a user/kernel crossing plus a copyin. (b) Once bytes are write()ten, userland cannot change them. If the kernel does a lot of buffering, userland has to know the data it wants played a significant time in advance; if the kernel does little buffering, userland has a relatively hard real-time constraint in that it has to write() on a tight schedule or output audio drops out. Writing into an mmap()ped ring buffer takes advantage of the speed differential and fixes the latency issue without requiring real-time behaviour out of userland. (The API would need fixing, though; having to do a syscall to find out where the audio is playing defeats at least some of the performance advantage. Those numbers should appear in the mmap()ped buffer, or perhaps a different mmap()ped buffer.) Of course, if you're just playing a canned audio data stream and doing nothing else, the latency issue doesn't matter; you can have the kernel do lots of buffering and you're happy. But things such as games that want to play audio but also want to be able make that audio react very fast (for human values of "very fast") to unpredictable events may be willing to accept the inconvenience of an mmap()ped ring buffer for the sake of getting both lots of buffering and low latency. Also, if you have a repeating audio track, then at least in principle you can just copy it into the ring buffer and forget it, rather than having to constantly write() - though, of course, this depends on your repeat length dividing the ring buffer size. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B