Re: Audio device mmap and kevents

[yarl-baudig%mailoo.org@localhost]

First of all, I know I should have work best on my proposal but I had to 
post that now
because I probably wouldn't have time for a while.

Remenber that I did not implement mmap in audio.C, it was there!
I just think that it is better in this case for the kernel to "pull" the 
data, Just as it does
when the client uses write, it blocks until it needs data.

> I don't know about that but I find that hard to believe.
Also in audio_system(9):
     With regard to mmapped audio, blocks are played back immediately so 
the
     latency presented to applications is one third of the latency 
sysctl(8)
     value.

Here I trust manuals, I might take the time to understand how..

> 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.
In audioplay, well, if the audio device is mmapped 1 call to write is 
replaced with 1 call to memcpy.
This is perfectly normal. write(2) probably uses memcpy(3)?
As you say, there's less copies between user space and kernel. In user 
space: no more no less.

> You need to consider whether the performance improvement
> is really necessary or not.  And then if yes, you need to
> measure it before talking.
I don't think that I agree on that. I would say:
"You need to consider whether the performance improvement is real."
And you are right, it need to be measured, but I don't know how to do 
that.
However, even if that is only for the latency, that worth the cost.

Of course it need more cooperation from the client but I think this is 
always the case with mmap,
am I wrong? trade performances against ease.

> This article is not for NetBSD but good to read about mmap.
> http://manuals.opensound.com/developer/mmap.html
Even if that is only for specific applications.
I would not have watched this without latency reduction specified in the 
manuals and if mmap
was not already implemented.

> And it has to store the number of bytes writeable to kn->kn_data,
> not offset.
> 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.
I agree, I wanted to try it quick. I think I can return space instead of 
offset (by adding
a 'last_space_returned' and assuming that at every new call to kevent, 
the client filled all
the free space, what do you think?).

> 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.
time3: the next kevent call returns the position (time1.5)
Am I wrong?

> > > # 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>

Thank you.