Shallow Thoughts : tags : alsa
Akkana's Musings on Open Source Computing and Technology, Science, and Nature.
Tue, 13 Dec 2011
One of the distros I'm trying on my Dell Latitude 2120 laptop is Arch Linux.
I like a lot of things about Arch; I had to stop using it on my previous
laptop because something broke in the wi-fi drivers, but I always regretted
giving it up. And it seems to work quite well on the Dell, with one
exception: the system beep (which other distros don't support at all)
was ear-shatteringly loud, far too loud to consider being able to use
this laptop in a public space. Clearly that needed to be fixed.
The usual approach to system beeps, unloading or blacklisting the
pcspkr module, had no effect.
xset b off turned the beep
off in X; I could also set its pitch and duration to change it to a
nice quiet click, though I wasn't able to change the volume that way.
I actually do like having a system beep, as long as it's fairly quiet
and won't disturb people nearby. Unfortunately, xset b only affects
the bell while in X; it didn't have any effect on the deafening sound
Arch gave upon shutdown or reboot.
It turns out that on some laptops, including this Dell, the system beep
goes not through the old-style pcspkr driver, but through the
normal sound card. And the sound card has a separate channel for the
system beep, so even if you have your volume turned down, the beep
may still be at 100%. All I needed to do was run
and find out what the channel was called: "Beep".
Given that, I could use the amixer program to ensure the beep volume
will be sane when I log in. I added the following to .zlogin
(for zsh; obviously, adjust for your own shell):
amixer -q -c 0 set Beep 5
That gave me a nice quiet beep. If I need to turn it off completely,
amixer can do that too:
amixer -q -c 0 set Beep mute
amixer -q -c 0 set Beep 0 doesn't actually
set the volume to zero, just sets it very low).
That volume setting applies to the shutdown beep, too, fortunately.
Though what I'd really like is to have quiet beeps while I'm running, but no
shutdown beep at all. I don't understand the purpose of the shutdown beep;
obviously I know when I've told my machine to shut down or reboot, so
why do I need an audible reminder? But I've been unable to find anything
explaining what's causing this beep. I tried adding a
amixer -q -c 0 set Beep mute to /etc/rc.local.shutdown,
but it didn't help; apparently the shutdown beep is called before that
file is run. Which strongly suggests it is being run by Arch Linux,
not by something in the BIOS. But nobody I've asked had any suggestions
as to its source, or how to change it. Another enduring Linux mystery ...
Update: I mentioned xset b as a way to adjust beeps inside X -- in
addition to turning beeps totally off, you can also set pitch, duration,
and sometimes volume though the volume part didn't work for me.
But outside X, you can make similar adjustments
with setterm, e.g.
setterm -bfreq 400 -blength 50.
Thanks to Mikachu for the tip!
[ 12:05 Dec 13, 2011
More linux |
permalink to this entry |
Tue, 07 Apr 2009
Today's award concerns clarity of error messages.
My desktop machine has been getting flakier for a week or two.
Strange messages at boot, CDROM drive unable to burn reliably or
verify after burning, and finally it culminated in a morning where
it wouldn't boot at all. Turned out (after much experimentation)
to be not one but two bad IDE cables -- and these were the
snazzy expensive heavy-duty cables, not the cheap ribbon cables,
in a box that hadn't been opened for months. Weird.
Anyway, since I had the system disk out anyway (to recover data from
it) I left it out, migrated my data to the newer, bigger disk and
installed a new Ubuntu Intrepid.
Been meaning to do that anyway -- running two disks just adds to the
noise, heat and power usage and doesn't really add that much speed.
It took a couple of hours to get the system working the way I want it
-- installing things I need, like tcsh, vim, emacs, plucker, vlc, sox
etc. and cleaning up some of the longstanding Ubuntu udev and kernel
configuration bugs that keep various hardware from working.
I thought I had everything ready when I noticed I wasn't getting
any sound alerts, so I tried playing a sample .wav file, and got
a rather unusual error:
(clavius)- play sample.wav
ALSA lib confmisc.c:768:(parse_card) cannot find card '0'
ALSA lib conf.c:3513:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:3513:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
ALSA lib conf.c:3513:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:3985:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2196:(snd_pcm_open_noupdate) Unknown PCM default
play soxio: Can't open output file `default': cannot open audio device
What does that mean?
Well, it turns out what it means is ... my user wasn't in the
"audio" group, so I didn't have write permission on the sound device.
I added myself to "audio" in /etc/groups and sound worked fine in my
Now, I've seen some fairly obscure error messages in my time,
but this one may just win my all-time obscurity award. 9 lines and 744
characters to say "Can't open $device."
And with all that, it still managed
to omit the one piece of information that might have been helpful:
the name of the device it was trying to open (so that an ls -l
would have told me the problem right away).
[ 14:23 Apr 07, 2009
More tech |
permalink to this entry |
Wed, 01 Jun 2005
During Debian upgrades over the last few months, apparently my
system's alsa and aumix scripts had a little private battle for
control of the mixer, and alsa won. The visible symptom was that my
volume was always at 0 when I started up.
I tried re-enabling the aumix script in /etc/init.d, which
had previously controlled my default volume, but it just said
"Saved ALSA mixer settings detected; aumix will not touch mixer."
The solution, in the end, was to remove
/var/lib/alsa/asound.state, set the volume, and
run alsactl store. Someone suggested that I use chattr -i
to make the asound.state file inviolable; it isn't on an ext2/3
filesystem, so that isn't a solution for me, but if my volume goes
wonky again at least I know where to look.
[ 10:40 Jun 01, 2005
More linux |
permalink to this entry |