Re: Audio device mmap and kevents

[coypu%sdf.org@localhost]

On Sat, Jan 26, 2019 at 12:38:09PM +0900, Tetsuya Isaki wrote:
> 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>

I can confirm that pulse+mplayer still works with 1.33 reverted, and
that the 100% cpu usage is gone.
Thanks!