[Pkg-alsa-devel] Bug#540831: blacklisting pcspkr ruins beep(1), and icewm' mail beep

[Josh Triplett]

On Thu, Sep 03, 2009 at 10:15:49AM +0200, Gerfried Fuchs wrote:
> * Josh Triplett <josh at joshtriplett.org> [2009-09-03 09:21:31 CEST]:
> > OK, for the sake of argument, I just ran a Google search for "pcspkr".
> > First page of ten results:
> 
>  You should be aware that this is extremely biased because it is enabled
> by default and there is an easy way to disable it, most of these threads
> already do directly have the term "blacklist" in them. A pretty weak
> argumentation line, if you ask me ...

Granted.  If it defaulted to disabled, perhaps all the results would
explain how to enable it. :)

Nevertheless, you asked "How regular actually is the question on how to
disable the speaker?", and I attempted to answer.  The results I gave
represent a pretty representative sample of the numerous cases I've seen
of people complaining about the pcspkr, wanting to turn it off, and
getting bad impressions of Linux specifically because of the harsh
beeping.

Note, by the way, that other (non-Linux) operating systems stopped using
the beep a long time ago, hence those bad impressions.

> > And that just came from the first page of Google search results.
> > ~8.5/10 pages wanting pcspkr to go away.  Oh, and the "Searches related
> > to: pcspkr" at the bottom?  "blacklist pcspkr", "rmmod pcspkr", "disable
> > pcspkr"...
> 
>  Some others might want to have other things go away that are enabled by
> default. Blacklisting it though does mean that it gets pretty hard for
> those who would like to find out why something that has been right from
> the start and is thus just expected to be there to find out why it's not
> there anymore and how to get it working again.

I would also point out that it takes a non-trivial amount of effort to
figure out how to disable the beeping, if you don't know what causes it.
I've had more than one person complain to me in person about the
beeping, which they'd put up with for a long time since they didn't know
how to disable it.

>  What I rather wonder than people searching for a way to disable or
> blacklist it is wether other distributions do blacklist it by default,
> too? And for a start a convenient and easy way to tell alsa-base to
> *not* blacklist it. Editing the config file might sound reasonable at
> first sight, but thinking along more deeper it would nag one on every
> upgrade, especially when the list of other modules in the file changes.
> A single file that one could simply "rm" (or, in the first place,
> possibly only add through some debconf question?) that would be much
> more convenient.

Granted.  (Though, adding Yet Another debconf question for a simple
issue like this seems like a bad idea.)

> > Between that and my original bug report, if I haven't yet demonstrated
> > the existence of a problem, I don't know what will.
> 
>  You haven't demonstrated the existence of a problem at all, you
> demonstrated that people are diverse and some doesn't like the pc
> speaker. If you would like to call something a problem then it might pin
> down to having a well documented and convenient way to disable it,
> nothing more. Blacklisting the module is just as much of a problem.

"don't like" is an understatement.  I don't object to the console bell;
I object to implementing it via a loud beep that I can't mute, turn
down, or otherwise control via the normal volume control on my desktop.
To phrase the bug a few other ways:
"Muting sound doesn't disable beeping"
"Loud beep by default; unacceptable for shared work environments (work, school)"

Do those not sound like bugs?

Also consider the perspective of the average user, annoyed by the
computer generating sound despite them specifically telling it to *not*
generate sound.

It doesn't help that numerous programs seem to find it acceptable to
use the console beep rather than some more sensible sound cue.

> > As for why this relates to ALSA: because the sound driver should
> > take over (or otherwise manage) the function of the console beep.  I
> > suppose it could appear in linux-sound-base instead, since it doesn't
> > seem ALSA-specific.
> 
>  That's exactly my point, there is nothing alsa specific about the pc
> speaker at all, so it's a violation of scope, IMNSHO.
> 
> > I sympathize with jidanni's concerns. The console beep not working at
> > all seems like a bug.
> 
>  .. and it's not only Jidanni's, claiming so seems to try to belittle
> the issue at hand to a personal one, which it isn't.

"concerns raised by", if you prefer.  I certainly didn't intend to imply
that others did not share those concerns; I just needed some identifier
with which to refer to them.

> > pcspkr getting loaded at all *also* seems like a bug. (Or, if you
> > prefer, pcspkr getting loaded in the absence of a sound card
> > represents a bug.)
> 
>  I highly like to differ here, it's two different systems and having
> them both working seperately isn't something that I would call a bug,
> never ever, and I am extremely puzzled why you would want to call that
> brokenness. It is *not* broken to have it that way. Never was, never
> will.

I disagree.  Consider that ALSA blacklists the OSS modules.  You could
argue that both subsystems ought to work (modulo both wanting to talk to
the same sound card).  However, ALSA replaces the functionality of OSS,
does so in an (arguably) better way, and provides compatibility with
OSS.  Similarly, ALSA (often, though apparently not always) provides the
functionality of pcspkr, does so in an (arguably) better way, and
(often, though apparently not always) provides compatibility with
pcspkr.

- Josh Triplett