Re: CVS commit: src/sys

[Tetsuya Isaki <isaki%pastel-flower.jp@localhost>]

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 <isaki%pastel-flower.jp@localhost / isaki%NetBSD.org@localhost>