At Sat, 28 Mar 2020 09:34:11 +0000, nia wrote: > > - 4msec is (probably no problem for most modern real hardware but) > > too aggressive to be default. > > - 10msec is too severe for antique machines but it's hard to draw a line. > > <5ms blk_ms is required by real world applications; see emulators/mednafen.
If you found such problem, you should have reported it, rather than changing amd64/conf/GENERIC. I look emulators/mednafen later. By the way, blk_ms is fixed at 50msec in netbsd-7 or prior, and is 50msec default (but uncertain) in netbsd-8. How was it able to run in those days? > I would prefer if blk_ms were kept below 5ms on amd64 and aarch64. > We don't have to worry about the CPU load of playing audio on these platforms. CPU load or performance is not subject. I know that my implementation will work on the most modern real hardware. But I feel that at least 4msec is too rush to be default. A default should not be for one game application. > We also released 9 with blk_ms=4 on these platforms and nobody complained. If you want to say so, you should have discussed before commit. 9.0-RELEASE/amd64 (blk_ms=4) on VirtualBox6 on OSX plays too bad sound. With blk_ms=8, it's almost good but a bit strange. With blk_ms=10, it's fine. At least in my environment. In result, there are two problems. - You claimed that emulators/mednafen requires blk_ms <= 5msec - I reported that VirtualBox6 on OSX requires blk_ms >= 10msec > > - It's not good idea to set such parameter in individual GENERICs. > > It's not a good idea to punish the majority of NetBSD users because m68k > is incredibly slow. As martin pointed out, you seem to misunderstand. I just dropped m68k from majority. Thanks, --- Tetsuya Isaki <is...@pastel-flower.jp / is...@netbsd.org>