On 7-Apr-08, at 2:06 AM, D'Arcy J.M. Cain wrote:
On Sun, 6 Apr 2008 16:20:18 +0100 (BST) Iain Hibbert <plunky%rya-online.net@localhost> wrote:On Sun, 6 Apr 2008, D'Arcy J.M. Cain wrote:options DEBUG # expensive debugging checks/supportthis one really is expensive and would be my first guess.Isn't that for compile time checks? I am going to start by removing DIAGNOSTIC since that one specifies kernel checking.
I haven't played audio on a netbsd-based machine in a few months (my NAS-capable X station is not set up since my move), and I've never played audio on a netbsd machine with a built-in audio device, but I can assure you that neither DEBUG nor DIAGNOSTICS are causes of any major slowdowns, and neither has ever affected normal audio playback via NAS over the network.
Perhaps one or the other turns on some periodic cleanup/check code in the particular audio driver you are using. This kind of code should be fairly easy to find though as it apparently isn't occurring in the regular I/O operations, but rather on some kind of periodic timer or some other such milestone event.
In fact I'd say that unless your system is truly starved for CPU then you should _always_ enable both "options DEBUG" and "options DIAGNOSTIC". DEBUG should always be the first to go when system performance appears to be adversely affected. "options DIAGNOSTIC" should probably always be enabled by default and only turned off by users who have completely validated particular configurations for something where space is critical such as embedded/appliance systems.
I'd also hope that kernel developers should continue to use these compile-time options as appropriate to enable code that can help detect runtime problems wherever and however possible so long as there are no major impacts on system performance or usability. Really intrusive checks should also continue to be enabled with #ifdef BLAH_DEBUG where "BLAH" refers to the code/data being checked.
--
Greg A. Woods; Planix, Inc.
<woods%planix.ca@localhost>