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 <is...@pastel-flower.jp / is...@netbsd.org>
Thank you.
