Re: Audio device mmap and kevents

[yarl-baudig%mailoo.org@localhost]

> At first, mmap'ing audio device does not lead to improve any
> performance or latency.
From audio(4):
     For audio applications that mmap(2) the audio device for play back 
the
     resultant latency is a third (1/3) of the value of the 
hw.driverN.latency
     variable.

This is for the latency, but maybe the manual is outdated?
For the performance, while I'm not experienced, I think that mmap is 
faster, less copies, no?

> And I think that write(2) already has
> the optimal synchronization mechanism especially for stream-type
> data like audio.  You don't have to monitor the kernel event.
> You don't have to calculate the circular buffer's offset.
mmap is harder to use than write, this is usually the case but you get 
better performances.

> And it has to store the number of bytes writeable to kn->kn_data,
> not offset.
That's too bad but why not.

> It is already implemented as "audioctl encodings" command.
Ok, I didn't know.
> # Although I don't know whether it's the optimal way or not.
> And emulated flag has no meaning after 8.0.
From audio(4):
     Only encodings that are not emulated (i.e. where
     AUDIO_ENCODINGFLAG_EMULATED is not set) work properly for a mapped
     device.
> Merging play() and play_fd() makes it harder to read.

I do not agree.. It was necessary for me to add mmap support. Less 
redundancies and better structure,
I think.