Re: kern/56059: speaker(4): system hangs if tone < 100 Hz (_SC_CLK_TCK) is played

[RVP <rvp%SDF.ORG@localhost>]

The following reply was made to PR kern/56059; it has been noted by GNATS.

From: RVP <rvp%SDF.ORG@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/56059: speaker(4): system hangs if tone < 100 Hz (_SC_CLK_TCK)
 is played
Date: Thu, 18 Mar 2021 08:07:39 +0000 (UTC)

 What I forgot to mention in the bug report was that this speaker
 is a synthesized device--ie. this is not an old-fashioned PPI PC
 speaker. (As far as I can figure it out, my system--an Asus X202E
 laptop--doesn't have a physical PC speaker at all):
 
 $ fgrep audio /var/run/dmesg.boot 
 hdaudio0 at pci0 dev 27 function 0: HD Audio Controller
 hdaudio0: interrupting at msi1 vec 0
 hdafg0 at hdaudio0: vendor 1106 product 8446
 audio0 at hdafg0: playback, capture, full duplex, independent
 audio0: slinear_le:16 2ch 48000Hz, blk 1920 bytes (10ms) for playback
 audio0: slinear_le:16 2ch 48000Hz, blk 1920 bytes (10ms) for recording
 spkr0 at audio0: PC Speaker (synthesized)
 hdafg1 at hdaudio0: vendor 8086 product 2806
 $
 
 So, the sound is being synthesized in sys/dev/audio/audiobell.c
 and this is really an audio(4) bug.
 
 Poking around in the sources a bit led me to wonder if generating
 (small) samples for tones < 100Hz was leading to a buffer underrun
 somewhere. And, it seems this is so: raising the hw.audio0.blk_ms
 value "fixes" the kernel hang for me. A value of 15 ms suffices,
 but, then the generated tones seemed "off tune", so I've raised it to
 the max. it will go to on my HW (8KB -- ~42 secs):
 
 # sudo sysctl -w hw.audio0.blk_ms=50
 
 Maybe this will help narrow down what needs to be fixed in the
 code.
 
 -RVP