Re: Audio device mmap and kevents

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> (a) It's the rare port on which copying to mmap()ped memory is no
>> faster than a user/kernel crossing plus a copyin.
> What I wanted to say is that mmap may be faster from such point of
> view but that difference may not make observable impact especially
> for application like audioplay(1).

For audioplay(1), yes, I agree.  That is an example of an application
for which the performance differences are minor enough to be easily
outweighed by the convenience.  I doubt anyone would argue that the
write() interface should go away.

>> 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.
> Please let me confirm.  Current audio mmap no longer points [to] the
> hardware buffer.  Is our understanding the same?

I don't know; it's been years since I looked at more than the
occasional file or two from -current, and I have never looked at the
mmap()ped-audio interfaces in detail in any version.

But whether the mapped buffer is the one the hardware is reading from
or whether it's the source for pseudo-DMA driven off an interrupt or
what is close to irrelevant; getting the bits into the kernel machinery
via mmap rather than write still provides both speed and latency
advantages - just not as much as if it were the hardware's output
buffer being mapped into user VM.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B