tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Audio device mmap and kevents



At Sat, 19 Jan 2019 16:08:37 +0100,
yarl-baudig%mailoo.org@localhost wrote:
> > 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?

I don't know about that but I find that hard to believe.

> For the performance, while I'm not experienced, I think that mmap is 
> faster, less copies, no?

mmap(2) may reduce copies between user space and the kernel
compared to write(2).  Generally speaking, yes.
But your patch seems to increase memcpy(3) instead of decreasing
write(2) system call.

You need to consider whether the performance improvement
is really necessary or not.  And then if yes, you need to
measure it before talking.

This article is not for NetBSD but good to read about mmap.
http://manuals.opensound.com/developer/mmap.html

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

See kqueue(4).  audio should follow it even mmap case.

  EVFILT_WRITE   Takes a descriptor as the identifier, and returns whenever
                 it is possible to write to the descriptor.  For sockets,
                 pipes, fifos, and ttys, data will contain the amount of
                 space remaining in the write buffer.

And one more point: what do you do in such case?
 time1: Since kevent() wokes up, you were able to know the potision
   to write next in mmap area.
 time2: Copy next data to this position got in time1.

 time1.5: audio HW intterupt occurred.  It advances the position in
   kernel.
 
> > # 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.

Ah...  The meaning of this flag was changed on 8.0.
So this sentence itself about mmap seems not wrong.
---
Tetsuya Isaki <isaki%pastel-flower.jp@localhost / isaki%NetBSD.org@localhost>


Home | Main Index | Thread Index | Old Index