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