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>