Re: Audio device mmap and kevents

[Tetsuya Isaki <isaki%pastel-flower.jp@localhost>]

At Wed, 23 Jan 2019 16:32:01 +0000,
coypu%sdf.org@localhost wrote:
> > the latency issue doesn't matter;
> Using an AMD Ryzen 7 2700X (or: this machine isn't weak):
> 
> > mpv --no-video "https://www.youtube.com...";
>   PID USERNAME PRI NICE   SIZE   RES STATE      TIME   WCPU    CPU COMMAND
>  4908 fly       25    0   299M   41M CPU/0      2:32 98.83% 98.78% mpv
> 
> (kern/53028)

Would you split the PR into "hdaudio default latency too high"
and "mpv spins at 100% CPU playing audio" ?  These are completely
different problems.

For first one (latency problem), I was doubtful about displayed
value at boot time.  Anyway, it's too large in either case.  I am
rewriting it now.

For second one (mpv spins at 100% cpu), I could reproduce and
I found src/lib/libossaudio/ossaudio.c rev 1.33 is the cause.
The calculation of GETOSPACE is obviously wrong and rev 1.32
is correct.

I think the scenario where mpv was spinning is as follows:
1) mpv calls ioctl(SNDCTL_DSP_GETOSPACE) to ask how much free
   space on write buffer.
2) Due to this mis-calculation, GETOSPACE may return 0 (means
   no writeable space) even writeable.
3) Then mpv will poll(2) to wait to become writeable.
4) However poll(2) will return immediately because it's writeable.
5) goto 1!

I could run "mpv -ao=oss some.mp3" at 0~1% CPU with rev 1.32
on netbsd-8.

May I commit(revert) it?

According to PR kern/51999, this commit made mplayer work again.
But I doubt it.  Unfortunately I don't have environment to play
mplayer now.  Can someone confirm this?

Thanks.
---
Tetsuya Isaki <isaki%pastel-flower.jp@localhost / isaki%NetBSD.org@localhost>