Shallow Thoughts : tags : audio

Enabling system beeps on Ubuntu Lucid

Update: though the rest of this article is still useful in explaining how to un-blacklist the pcspkr module, unfortunately that module works very erratically. Sometimes you'll get a beep, sometimes not. So this article may be a good start but it still doesn't explain why Ubuntu's kernels have such a flaky pcspkr module.

For years I've used Ubuntu with my own kernels rather than the kernels Ubuntu provides. I have several reasons: home-built kernels boot a lot faster (when I say a lot, I mean like saving 30 seconds off a one-minute boot) and offer more control over options. But a minor reason is that Ubuntu kernels generally don't support the system beep, so for example there's no way to tell in vim when you get out of insert mode. (In the past I've sometimes used the excellent fancy beeper module to play sounds, but I don't always want that.)

On Ubuntu's latest "Lucid Lynx", I'm using their kernel (so far). The Ubuntu kernel team has made huge improvements in boot time and number of modules loaded, so it's much more efficient than past kernels. But it did leave me without a beeper.

modprobe pcspkr failed to do anything except print the enigmatic:

WARNING: All config files need .conf: /etc/modprobe.d/00local, it will be ignored in a future release.

modprobe -v pcspkr (verbose) was no help -- it printed install /bin/true which didn't make anything clearer.

To get my beep back, I had to do two things:

First, edit /etc/modprobe.d/blacklist.conf and comment out the line blacklisting pcspeakr. It looks like this:

# ugly and loud noise, getting on everyone's nerves; this should be done by a
# nice pulseaudio bing (Ubuntu: #77010)
blacklist pcspkr

(They don't seem to be concerned about anyone who doesn't run Pulse, or about the various other bugs involved -- there's quite a laundry list in bug 486154.)

Secomd. pcspkr was blacklisted a second time in a different way, in that file so confusingly alluded to by the warning. /etc/modprobe.d/00local was apparently left over from a previous version of Ubuntu, and never removed by any upgrade script, and consisted of this:

install pcspkr /bin/true

Aha! So that's why modprobe -v pcspkr printed install /bin/true -- because that's all it was doing instead of loading the module like I'd asked.

So rm /etc/modprobe.d/00local was the second step, and once I'd done that, modprobe pcspkr loaded the module and gave me my system beep.

Tags: ubuntu, lucid, audio
[ 13:02 Jun 13, 2010    More linux/kernel | permalink to this entry ]

Silencing speaker hum

Ah, silence is golden!

For my birthday last month, Dave gave me a nice pair of Bose powered speakers to replace the crappy broken set I'd been using. Your basic computer speakers, except I actually use them primarily for a little portable radio I listen to while hacking.

Only one problem: they had a major hum as soon as I turned them on. Even when I turned on the radio, I could hear the hum in the background. It got better if I turned the speakers way down and the radio up -- it wasn't coming from the radio.

After about a month it was starting to irritate me. I mentioned it on #linuxchix to see if anyone had any insights.

Maria and Wolf did, and narrowed it down pretty quickly to some sort of ground problem. The speakers need to get a real ground from somewhere. They don't get it through their AC power plug (a two-prong wall wart). They also don't get it from the radio, which is plugged in to AC via its own 2-prong wall wart, so it doesn't have a ground either.

How could I test this? Wolf suggested an alligator clip going from one of the RCA plugs on the back of the speaker to my computer's case. But it turned out there was an easier way. These speakers have dual inputs: a second set of RCA plugs so I can have another cable going to an MP3 player, radio or whatever, without needing to unplug from the radio first. I ran a spare cable from these second RCA plugs to the sound card output of my spare computer -- bingo! The hum entirely went away.

I suppose most people buy this type of speaker for use with computers, so it isn't a problem. But I was surprised that they'd adapt so poorly to a portable device like a radio or MP3 player. Is that so uncommon?

Tags: tech, audio
[ 20:49 Oct 11, 2009    More tech | permalink to this entry ]

Random beeps

A couple of year ago I figured out how to make custom system beep sounds on Linux, like MacOS has done forever. But then I changed machines and somehow never got around to setting it up on any other machine.

But the Intel dual-Atom board doesn't seem to support a system beep -- there's no obvious place on the motherboard to plug in the connector going to the case speaker. How odd!

With the alternative being no beep at all, I dusted off my old blog post and went to see if Fancy Beeper Daemon kernel module still existed. Happily, it does, and it's up-to-date for current kernels, so all I had to do was download the latest and build it. Easy! Then I added "beep" to the list of automatically loaded modules in /etc/modules, blacklisted the pcspkr module using the /etc/modprobe.d/00local technique, and I was all set.

Except for the really important question: what sound to choose? I did a little web searching for free sounds and downloaded some samples to try out. Then I added a few bird calls from my Stokes Field Guide to Western Bird Songs CD, editing them in audacity to make them shorter and more appropriate for system beeps.

But I still couldn't decide on just one ... and why should I? I've really been enjoying my random wallpaper: every time I log in, I get a different desktop background. It's fun to see a new picture every day. Why not do the same for my system beep?

That's no problem, using the same randomline script I use for wallpaper. I just put this in my .xinitrc:

$HOME/bin/mybeepd `find $HOME/Music/beeps -name "*.wav" | randomline` &

and now I get a different beep sound each day.

Yesterday it was a loon. Today it's a cow mooing.

Tags: linux, audio, desktop
[ 20:11 Jun 17, 2009    More linux | permalink to this entry ]

Bullfrogs in stereo

The Walden West pond is hopping -- literally! This afternoon around 3pm the pond's resident bullfrogs, who normally just float quietly in the scum on the surface, would suddenly hop out of the water for no obvious reason, then settle back down a few feet away. One pair was apparently mating like that, the larger frog hopping onto the back of the smaller frog, then immediately off again. And the pond was full of sound, sometimes with two or more frogs booming at once. Bullfrogs in stereo!

I didn't have the SLR along, but some of the frogs were close enough (and calm enough not to submerge when we got near them) that I was able to get a few decent shots.

But I really wanted to capture that sound. So I put the camera in video mode and shot a series of videos hoping to catch some of the music ... and did. They sound like this: bullfrog (mp3, 24kb).

Despite the title of this entry, the recording doesn't have any interesting stereo effects; the only microphone was the one built in to my Canon A540. It did okay, though! You'll just have to use your imagination to place two frogs as you listen, one 20 feet to the left and the other 15 feet to the right.

How to extract the audio from a camera video

(Non open source people can quit reading here.)

Extracting the audio was a little tricky. I found lots of pages ostensibly telling me how to do it with mencoder, but none of them seemed to work. This did:

mplayer -vc null -af volume=15 -vo null -ao pcm -benchmark mvi_8992.avi

I added that -af volume=15 argument to make the sound louder, since it was a bit quiet as it came from the camera.

That produced a file named audiodump.wav, which I turned into an mp3 like this:

lame audiodump.wav bullfrogs.mp3

Tags: nature, bullfrog, linux, audio
[ 20:42 Jun 03, 2009    More nature | permalink to this entry ]

Bug fixes? Why would we bother to ship bug fixes?

(A culture of regressions, part 2)

I've been running on Ubuntu's latest, "Gutsy gibbon", for maybe a month now. Like any release, it has its problems that I've needed to work around. Like many distros, these problems won't be fixed before the next release. But unlike other distros, it's not just lack of developer time; it turns out Ubuntu's developers point to an official policy as a reason not to fix bugs.

Take the case of the aumix bug. Aumix just plain doesn't work in gutsy. It prints, "aumix: SOUND_MIXER_READ_DEVMASK" and exits.

This turns out to be some error in the way it was compiled. If you apt-get the official ubuntu sources, build the package and install it yourself, it works fine. So somehow they got a glitch during the process of building it, and produced a bad binary.

(Minor digression -- does that make this a GPL violation? Shipping sources that don't match the distributed binary? No telling what sources were used to produce the binary in Gutsy. Not that anyone would actually want the sources for the broken aumix, of course.)

It's an easy fix, right? Just rebuild the binary from the source in the repository, and push it to the servers.

Apparently not. A few days ago, Henrik Nilsen Omma wrote in the bug:

This bug was nominated for Gutsy but does currently not qualify for a 7.10 stable release update (SRU) and the nomination is therefore declined. According the the SRU policy, the fix should already be deployed and tested in the current development version before an update to the stable releases will be considered. [ ... ] See: https://wiki.ubuntu.com/StableReleaseUpdates.

Of course, I clicked on the link to receive enlightenment. Ubuntu's Stable Release page explains

Users of the official release, in contrast, expect a high degree of stability. They use their Ubuntu system for their day-to-day work, and problems they experience with it can be extremely disruptive. Many of them are less experienced with Ubuntu and with Linux, and expect a reliable system which does not require their intervention.

by way of explaining the official Ubuntu policy on updates:

Stable release updates will, in general, only be issued in order to fix high-impact bugs. Examples of such bugs include:

• Bugs which may, under realistic circumstances, directly cause a security vulnerability
• Bugs which represent severe regressions from the previous release of Ubuntu
• Bugs which may, under realistic circumstances, directly cause a loss of user data

Clearly aumix isn't a security vulnerability or a loss of user data. But I could make a good argument that a package that doesn't work ... ever ... for anyone ... constitutes a severe regression from the previous version of that package.

Ubuntu apparently thinks that users get used to packages not working, and grow to like it. I guess that if you actually fixed packages that you broke, that would be disruptive to users of the stable release.

I'm trying to picture these Ubuntu target users, who embrace regressions and get upset when something that doesn't work at all gets fixed so that it works as it did in past releases. I can't say I've ever actually met a user like that myself. But evidently the Ubuntu Updates Team knows better.

Update: I just have to pass along Dave's comment: "When an organization gets to the point where it spends more energy on institutional processes for justifying not fixing something than on just fixing it -- it's over."

Update: Carla Schroder has also written about this.

Tags: linux, ubuntu, audio
[ 10:21 Dec 07, 2007    More linux | permalink to this entry ]

Custom beep sounds

It's always amazed me that Linux doesn't let you customize the system beep. You can call xset b volume pitch duration to make it beep higher or lower, or you can turn it off or switch to "visual bell"; but there's nothing like the way most other OSes let you customize it to any sound you want. (Some desktops let you customize the desktop alerts, but that doesn't do anything about the beeping you get from vim, or emacs, or bash, or a hundred other programs that run in terminals.)

Today someone pointed me toward a Gentoo wiki page that led me to Fancy Beeper Daemon. This is a small kernel module that adds a device, /dev/beep, which outputs a byte every time there's a beep. You can write a very simple daemon (several samples in Python are included with the module) which reads /dev/beep and plays the sound of your choice.

I downloaded beep-2.6.15+.tar.gz, but it needed one tweak to build it under 2.6.23-rc3: I needed to add

#include <linux/sched.h>

among the includes at the beginning of beep.c. After that, it compiled and installed just fine. Since it's a kernel module, it works in consoles as well as under X.

/dev/beep is created with owner and group root, and readable/ writable only by owner and group, so to test it I had to chmod 666 /dev/beep to run the daemon. I fixed that by making a file in /etc/udev/rules.d called 41-beep.rules, containing:

KERNEL=="beep", GROUP="audio"

Finally, based on the nice samples that came with the module, I wrote my own very simple Python daemon, playbeepd, that uses aplay.

Lots of fun! I don't know how much I'll use it, but it's good to have the option of custom beep sounds.

Tags: linux, audio, kernel
[ 20:47 Sep 08, 2007    More linux | permalink to this entry ]

A Quartet of Workarounds

I upgraded my laptop's Ubuntu partition from Edgy to Feisty. Debian Etch works well, but it's just too old and I can't build software like GIMP that insists on depending on cutting-edge libraries.

But Feisty is cutting edge in other ways, so it's been a week of workarounds, in two areas: Firefox and the kernel. I'll start with Firefox.

Firefox crashes playing flash

First, the way Ubuntu's Firefox crashes when running Flash. I run flashblock, fortunately, so I've been able to browse the web just fine as long as I don't click on a flashblock button. But I like being able to view the occasional youtube video, and flash 7 has worked fine for me on every distro except Ubuntu. I first saw the problem on Edgy, and upgrading to Feisty didn't cure the problem.

But it wasn't their Firefox build; my own "kitfox" firefox build crashed as well. And it wasn't their flash installation; I've never had any luck with either their adobe flash installer nor their opensource libswfdec, so I'm running the same old flash 7 plug-in that I've used all along for other distros.

To find out what was really happening, I ran Firefox from the commandline, then went to a flash page. It turned out it was triggering an X error:

The error was: 'BadMatch (invalid parameter attributes)'.
(Details: serial 104 error_code 8 request_code 145 minor_code 3)

That gave me something to search for. It turns out there's a longstanding Ubuntu bug, 14911 filed on this issue, with several workarounds. Setting the environment variable XLIB_SKIP_ARGB_VISUALS to 1 fixed the problem, but, reading farther in the bug, I saw that the real problem was that Ubuntu's installer had, for some strange reason, configured my X to use 16 bit color instead of 24. Apparently this is pretty common, and due to some bug involving X's and Mozilla's or Flash's handling of transparency, this causes flash to crash Mozilla.

So the solution is very simple. Edit /etc/X11/xorg.conf, look for the DefaultDepth line, and if it's 16, that's your problem. Change it to 24, restart X and see if flash works. It worked for me!

Eliminating Firefox's saved session pester dialog

While I was fiddling with Firefox, Dave started swearing. "Why does Firefox always make me go through this dialog about restoring the last session? Is there a way to turn that off?"

Sure enough, there's no exposed preference for this, so I poked around about:config, searched for browser and found browser.sessionstore.resume_from_crash. Doubleclick that line to change it to false and you'll have no more pesky dialog.

For more options related to session store, check the Mozillazine Session Restore page.

Kernel: runaway kacpid

Alas, having upgraded to Feisty expressly so that I could build cutting-edge programs like GIMP, I discovered that I couldn't build anything at all. Anything that uses heavy CPU for more than a minute or two triggers a kernel daemon, kacpid, to grab most of the CPU for itself. Being part of the kernel (even though it has a process ID), kacpi is unkillable, and prevents the machine from shutting down, so once this happens the only solution is to pull the power plug.

This has actually been a longstanding Ubuntu problem (bug 75174) but it used to be that disabling acpid would stop kacpid from running away, and with feisty, that no longer helps. The bug is also kernel.org bug 8274.

The Ubuntu bug suggested that disabling cpufreq solved it for one person. Apparently the only way to do that is to build a new kernel. There followed a long session of attempted kernel building. It was tricky because of course I couldn't build on the target machine (inability to build being the problem I was trying to solve), and even if I built on my desktop machine, a large rsync of the modules directory would trigger a runaway kacpi. In the end, building a standalone kernel with no modules was the only option.

But turning off cpufreq didn't help, nor did any of the other obvious acpi options. The only option which stops kacpid is to disable acpi altogether, and use apm. I'm sorry to lose hibernate, and temperature monitoring, but that appears to be my only option with modern kernels. Sigh.

Kernel: Hangs for 2 minutes at boot time initializing sound card

While Dave and I were madly trying to find a set of config options to build a 2.6.21 that would boot on a Vaio (he was helping out with his SR33 laptop, starting from a different set of config options) we both hit, at about the same time, an odd bug: partway through boot, the kernel would initialize the USB memory stick reader:

sd 0:0:0:0: Attached scsi removable disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0

and then it would hang, for a long time. Two minutes, as it turned out. And the messages after that were pretty random: sometimes related to the sound card, sometimes to the network, sometimes ... GConf?! (What on earth is GConf doing in a kernel boot sequence?) We tried disabling various options to try to pin down the culprit: what was causing that two minute hang?

We eventually narrowed the blame to the sound card (which is a Yamaha, using the ymfpci driver). And that was enough information for google to find this Linux Kernel Mailing List thread. Apparently the sound maintainer decided, for some reason, to make the ymfpci driver depend on an external firmware file ... and then didn't include the firmware file, nor is it included in the alsa-firmware package he references in that message. Lovely. I'm still a little puzzled about the timeout: the post does not explain why, if a firmware file isn't found on the disk, waiting for two minutes is likely to make one magically appear.

Apparently it will be fixed in 2.6.22, which isn't much help for anyone who's trying to run a kernel on any of the 2.6.21.* series in the meantime. (Isn't it a serious enough regression to fix in 2.6.21.*?) And he didn't suggest a workaround, except that alsa-firmware package which doesn't actually contain the firmware for that card. Looks like it's left to the user to make things work.

So here's what to do: it turns out that if you take a 2.6.21 kernel, and substitute the whole sound/pci/ymfpci directory from a 2.6.20 kernel source tree, it builds and boots just fine. And I'm off and running with a standalone apm kernel with no acpi; sound works, and I can finally build GIMP again.

So it's been quite a week of workarounds. You know, I used to argue with all those annoying "Linux is not ready for the desktop" people. But sometimes I feel like Linux usability is moving in the wrong direction. I try to imagine explaining to my mac-using friends why they should have to edit /etc/X11/xorg.conf because their distro set up a configuration that makes Firefox crash, or why they need to build a new kernel because the distributed ones all crash or hang ... I love Linux and don't regret using it, but I seem to need workarounds like this more often now than I did a few years ago. Sometimes it really does seem like the open source world is moving backward, not forward.

Tags: linux, ubuntu, mozilla, firefox, kernel, audio
[ 22:24 Jun 28, 2007    More linux | permalink to this entry ]

How to save ALSA sound volume

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.

Tags: linux, alsa, audio
[ 09:40 Jun 01, 2005    More linux | permalink to this entry ]

midi/Timidity working!

Cool -- moray on #debian-women worked with me a little on midi, and I finally have timidity working!

The trick is that there's a tarball I downloaded a while ago (which means I no longer have the url, but I think it was linked from the main timidity site) which extracts into a timidity.cfg and an "instruments" directory (plus a couple of readmes that don't explain anything, which is why I hadn't unpacked this before). Turns out that if you put that .cf into /etc/timidity.cfg, then add a line that says

dir /usr/local/share/timidity

(or wherever you unpack the tarball, as long as it contains "instruments") then voila, timidity starts working.

That means not only that I can play .midi files (big whoop), but, more important, I can use all those programs like denemo that come in the education-music package, plus all the java music API stuff like the CA music code (for some reason, all these things output only midi!)

So I played with denemo a little (found out how to enter a chord) in brief spurts, between long interludes in the house because it's TOO HOT out here in the office.

Tags: linux, audio
[ 19:00 Jul 05, 2004    More linux | permalink to this entry ]