NetBSD Problem Report #54243

From dholland@macaran.eecs.harvard.edu  Wed May 29 00:02:38 2019
Return-Path: <dholland@macaran.eecs.harvard.edu>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 053BC7A188
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 29 May 2019 00:02:37 +0000 (UTC)
Message-Id: <20190529000235.6C8446E2C3@macaran.eecs.harvard.edu>
Date: Tue, 28 May 2019 20:02:35 -0400 (EDT)
From: dholland@eecs.harvard.edu
Reply-To: dholland@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: beeping woes with -current
X-Send-Pr-Version: 3.95

>Number:         54243
>Category:       kern
>Synopsis:       beeping woes with -current
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    isaki
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed May 29 00:05:00 +0000 2019
>Closed-Date:    
>Last-Modified:  Sun Nov 24 09:10:01 +0000 2019
>Originator:     David Holland
>Release:        NetBSD 8.99.41 (20190528)
>Organization:
>Environment:
System: NetBSD macaran 8.99.41 NetBSD 8.99.41 (MACARAN) #54: Tue May 28 18:10:56 EDT 2019 dholland@macaran:/usr/src/sys/arch/amd64/compile/MACARAN amd64
Architecture: x86_64
Machine: amd64
>Description:

I updated the kernel today and beeps in X, which have been loud and
obnoxious since nat-audio was merged, are now even worse -- they are
very loud by default, and also they're now staticky/not rendered
right, which is quite abrasive.

>How-To-Repeat:

startx; echo ^G.

I'm not sure to what extent beeps on the console share the problem.
Ability to experiment is somewhat limited when people are around.

I have "wsbell* at spkr?" in my kernel config because otherwise beeps
don't work at all (a comment says "module by default", against the
modules policy, which I assume is why), and get these attachments:

pcppi1 at acpi0 (SPKR, PNP0800): io 0x61
spkr0 at pcppi1: PC Speaker
wsbell0 at spkr0 mux 1

hdaudio0 at pci0 dev 27 function 0: HD Audio Controller
hdaudio0: interrupting at msi1 vec 0
hdafg1 at hdaudio0: vendor 10ec product 0662
hdafg1: DAC00 2ch: Speaker [Jack], HP Out [Jack]
hdafg1: DIG01 2ch: SPDIF Out [Jack]
hdafg1: ADC02 2ch: Line In [Jack], Mic In [Jack]
hdafg1: 2ch/2ch 44100Hz 48000Hz 96000Hz PCM16 PCM20 PCM24 AC3
audio0 at hdafg1: full duplex, playback, capture, mmap, independent
audio0: slinear_le:16 2ch 48000Hz, blk 40ms for playback
audio0: slinear_le:16 2ch 48000Hz, blk 40ms for recording
spkr1 at audio0: PC Speaker (synthesized)
wsbell1 at spkr1 mux 1

The overt problem is spkr1; I can hear that the PC speaker is also
beeping but can't hear it clearly over the other, so I can't tell if
it's also messed up.

>Fix:

No idea.

>Release-Note:

>Audit-Trail:
From: coypu@sdf.org
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/54243: beeping woes with -current
Date: Wed, 29 May 2019 00:08:59 +0000

 heh
 I use `xset -b`

Responsible-Changed-From-To: kern-bug-people->isaki
Responsible-Changed-By: isaki@NetBSD.org
Responsible-Changed-When: Thu, 06 Jun 2019 12:50:35 +0000
Responsible-Changed-Why:
I will take it.


From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/54243: beeping woes with -current
Date: Sun, 9 Jun 2019 23:05:40 +0000

 On Wed, May 29, 2019 at 12:05:00AM +0000, dholland@eecs.harvard.edu wrote:
  > I updated the kernel today and beeps in X, which have been loud and
  > obnoxious since nat-audio was merged, are now even worse -- they are
  > very loud by default, and also they're now staticky/not rendered
  > right, which is quite abrasive.

 As of about three days ago, after about 8-9 days uptime (not sure
 exactly when it happened) beeps through the audio system stopped
 happening, for no obvious reason and with no obvious trigger. I think
 the PC speaker is still beeping, but with the adjustments I made to
 avoid being deafened by the other it's barely noticeable so I'm not
 absolutely certain.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Tetsuya Isaki <isaki@pastel-flower.jp>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org,
	gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/54243: beeping woes with -current
Date: Wed, 26 Jun 2019 16:21:09 +0900

 At Wed, 29 May 2019 00:05:00 +0000 (UTC),
 dholland@eecs.harvard.edu wrote:
 > >Description:
 > I updated the kernel today and beeps in X, which have been loud and
 > obnoxious since nat-audio was merged, are now even worse -- they are
 > very loud by default, and also they're now staticky/not rendered
 > right, which is quite abrasive.

 Please try this commit.

 | Committed By:	isaki
 | Date:		Wed Jun 26 06:57:45 UTC 2019
 | 
 | Modified Files:
 | 	src/sys/dev/audio: audio.c audiobell.c audiodef.h audiovar.h
 | 
 | Log Message:
 | Improve audiobell (and interfaces with audio).
 | - Generate pseudo sine wave if possible.  It may improve timbre.
 |   If it cannot represent a sine wave, it falls back to a triangular
 |   wave or a rectangular wave.
 | - Volume adjustment.
 | - Calculate playback frequency based on mixer frequency.
 |   Now audiobellopen() initializes playback parameters other than
 |   sample_rate, and new audiobellsetrate() sets sample_rate.
 | 
 | To generate a diff of this commit:
 | cvs rdiff -u -r1.20 -r1.21 src/sys/dev/audio/audio.c
 | cvs rdiff -u -r1.2 -r1.3 src/sys/dev/audio/audiobell.c
 | cvs rdiff -u -r1.5 -r1.6 src/sys/dev/audio/audiodef.h
 | cvs rdiff -u -r1.3 -r1.4 src/sys/dev/audio/audiovar.h

 > The overt problem is spkr1; I can hear that the PC speaker is also
 > beeping but can't hear it clearly over the other, so I can't tell if
 > it's also messed up.

 Use the following temprary patch to separate the problem.
 It adds sysctl hw.wsbell<N>.mute knob.
 # I don't have solution about the problem that all spkr* beep
 # simultatenously..

 --- a/sys/dev/wscons/wsbell.c
 +++ b/sys/dev/wscons/wsbell.c
 @@ -128,6 +128,7 @@ __KERNEL_RCSID(0, "$NetBSD: wsbell.c,v 1.11 2019/04/18 14:01:28 isaki Exp $");
  #include <sys/systm.h>
  #include <sys/tty.h>
  #include <sys/signalvar.h>
 +#include <sys/sysctl.h>
  #include <sys/device.h>
  #include <sys/vnode.h>
  #include <sys/callout.h>
 @@ -213,6 +214,7 @@ wsbell_attach(device_t parent, device_t self, void *aux)
  {
  	struct wsbell_softc *sc = device_private(self);
  	struct wsbelldev_attach_args *ap = aux;
 +	const struct sysctlnode *node;
  #if NWSMUX > 0
  	int mux, error;
  #endif
 @@ -247,6 +249,25 @@ wsbell_attach(device_t parent, device_t self, void *aux)
  	mutex_init(&sc->sc_bellock, MUTEX_DEFAULT, IPL_SCHED);
  	cv_init(&sc->sc_bellcv, "bellcv");

 +	sc->sc_mute = 0;
 +	sysctl_createv(&sc->sc_log, 0, NULL, &node,
 +	    0,
 +	    CTLTYPE_NODE, device_xname(self),
 +	    SYSCTL_DESCR("mute test"),
 +	    NULL, 0,
 +	    NULL, 0,
 +	    CTL_HW,
 +	    CTL_CREATE, CTL_EOL);
 +
 +	if (node != NULL) {
 +		sysctl_createv(&sc->sc_log, 0, NULL, NULL,
 +		    CTLFLAG_READWRITE,
 +		    CTLTYPE_INT, "mute",
 +		    SYSCTL_DESCR("mute test"),
 +		    NULL, 0, &sc->sc_mute, sizeof(sc->sc_mute),
 +		    CTL_HW, node->sysctl_num, CTL_CREATE, CTL_EOL);
 +	}
 +
  	kthread_create(PRI_BIO, KTHREAD_MPSAFE | KTHREAD_MUSTJOIN, NULL,
  	    bell_thread, sc, &sc->sc_bellthread, "%s", device_xname(self));
  }
 @@ -315,6 +336,8 @@ wsbell_detach(device_t self, int flags)
  	cv_destroy(&sc->sc_bellcv);
  	mutex_destroy(&sc->sc_bellock);

 +	sysctl_teardown(&sc->sc_log);
 +
  	return (0);
  }

 @@ -423,6 +446,11 @@ bell_thread(void *arg)
  			kthread_exit(0);
  		}

 +		if (sc->sc_mute) {
 +			mutex_exit(&sc->sc_bellock);
 +			continue;
 +		}
 +
  		tone.frequency = vb->pitch;
  		/*
  		 * period (derived from wskbd) is in msec.
 --- a/sys/dev/wscons/wsbellvar.h
 +++ b/sys/dev/wscons/wsbellvar.h
 @@ -46,6 +46,8 @@ struct wsbell_softc {

  	int		sc_refcnt;
  	bool		sc_dying;	/* device is being detached */
 +	struct sysctllog *sc_log;
 +	int		sc_mute;

  	lwp_t		*sc_bellthread;
  	kmutex_t	sc_bellock;

 ---
 Tetsuya Isaki <isaki@pastel-flower.jp / isaki@NetBSD.org>

From: Tetsuya Isaki <isaki@pastel-flower.jp>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org,
	dholland@NetBSD.org
Subject: Re: kern/54243: beeping woes with -current
Date: Wed, 26 Jun 2019 16:42:14 +0900

 At Sun,  9 Jun 2019 23:10:01 +0000 (UTC),
 David Holland wrote:
 >  As of about three days ago, after about 8-9 days uptime (not sure
 >  exactly when it happened) beeps through the audio system stopped
 >  happening, for no obvious reason and with no obvious trigger. I think
 >  the PC speaker is still beeping, but with the adjustments I made to
 >  avoid being deafened by the other it's barely noticeable so I'm not
 >  absolutely certain.

 # I'm sorry for delayed response.

 I'd like to know whether you could play normal audio (audioplay or
 mpg321 or whatever you like) at that time (if possible).
 I'm not sure but dev/audio/audio.c,v 1.20 may be related.
 Can you reproduce it?

 And would you separate this into new PR?

 Thanks,
 ---
 Tetsuya Isaki <isaki@pastel-flower.jp / isaki@NetBSD.org>

State-Changed-From-To: open->feedback
State-Changed-By: isaki@NetBSD.org
State-Changed-When: Sat, 05 Oct 2019 02:55:13 +0000
State-Changed-Why:
Is this still a problem?


State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 16 Nov 2019 11:40:13 +0000
State-Changed-Why:
Yes. As of yesterday's tree the default beeps are still very loud and grating.
The beep I get after my countermeasures is somewhat different so maybe
something changed, but it wasn't enough.


From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: isaki@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
	dholland@NetBSD.org
Subject: Re: kern/54243: beeping woes with -current
Date: Sat, 16 Nov 2019 11:43:41 +0000

 On Wed, Jun 26, 2019 at 07:45:02AM +0000, Tetsuya Isaki wrote:
  >  At Sun,  9 Jun 2019 23:10:01 +0000 (UTC),
  >  David Holland wrote:
  >  >  As of about three days ago, after about 8-9 days uptime (not sure
  >  >  exactly when it happened) beeps through the audio system stopped
  >  >  happening, for no obvious reason and with no obvious trigger. I think
  >  >  the PC speaker is still beeping, but with the adjustments I made to
  >  >  avoid being deafened by the other it's barely noticeable so I'm not
  >  >  absolutely certain.
  >  
  >  # I'm sorry for delayed response.

 no worries, I haven't exactly been prompt either.

  >  I'd like to know whether you could play normal audio (audioplay or
  >  mpg321 or whatever you like) at that time (if possible).
  >  I'm not sure but dev/audio/audio.c,v 1.20 may be related.
  >  Can you reproduce it?

 I can't. It seems to happen randomly after sufficient (considerable)
 uptime. Other audio stuff all still works. It's happened on another
 machine as well since.

  >  And would you separate this into new PR?

 Sure.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Tetsuya Isaki <isaki@pastel-flower.jp>
To: gnats-bugs@netbsd.org
Cc: netbsd-bugs@netbsd.org,
	gnats-admin@netbsd.org,
	dholland@NetBSD.org
Subject: Re: kern/54243 (beeping woes with -current)
Date: Sun, 24 Nov 2019 18:07:54 +0900

 At Sat, 16 Nov 2019 11:40:14 +0000 (UTC),
 dholland@NetBSD.org wrote:
 > Yes. As of yesterday's tree the default beeps are still very loud and grating.
 > The beep I get after my countermeasures is somewhat different so maybe
 > something changed, but it wasn't enough.

 I improved waveforms and volume(amplitude) by your comment.
 The audio beep which I imported first was full-range rectangular wave
 (the code was small but was uncomfortable as you say), and it is now
 pseudo sine wave with 60% amplitude.

 For audio beep volume, I chose the default not too small intentionally.
 If you feel the beep is too loud, you can turn it down by setting, but
 if the default beep is too silent, you may not be noticed or you may
 not be able to turn it up by setting.
 The best default value for every person is difficult, but I also think
 a reasonable default is worth.

 1. Please let me confirm the problem again.
  Which is(are) your problem(s)?
  A) pitch (frequency) of audio beep.
  B) length of audio beep.
  C) volume (amplitude) of audio beep.
  D) timbre(depending on waveforms) of audio beep.
  E) two or more beep devices sound simultaneously (like spkr@pcppi and
    spkr@audio).

 2. Please show me
  - xset q | grep bell
  - wsconsctl -a | grep bell
  - mixerctl -a

 3. Is your machine a real hardware? or some emulators?
 4. Does your machine have separate speakers for sysbeep and audio?

  (I mean, in some hardware (or environment), it shares one speaker with
  sysbeep and audio.  And these two were not synthesized, seemed to be
  toggled each other.  In result, two beeps that sounded simultaneously
  made unclear.  Although it's my experience.)

 5. Do you feel the same problem on console too?
  (In other words, Is the probelm specific to X?)

 6. If you feel the same problem on console and if your problem includes
  any of above A, B, or C.  What parameters do you think comfortable
  default (when measuring using wsconsctl)?
  - wsconsctl -w bell.pitch
  - wsconsctl -w bell.period
  - wsconsctl -w bell.volume

  Beeps on X applies xset's parameters, and in addition applies
  wsconsctl's parameters.  It's too complicated to use to verify.

 Thanks,
 ---
 Tetsuya Isaki <isaki@pastel-flower.jp / isaki@NetBSD.org>

>Unformatted:

Home	PR Database Search