On Sat, Jan 26, 2019 at 12:38:09PM +0900, Tetsuya Isaki wrote:
> At Wed, 23 Jan 2019 16:32:01 +,
> co...@sdf.org 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 WCPUCPU COMMAND
> > 4908 fly 250 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
I can confirm that pulse+mplayer still works with 1.33 reverted, and
that the 100% cpu usage is gone.
Thanks!
