Tag Archives: volume

gom: Ten years gone

I joined the Linux crusade well after the advent of ALSA audio, so the old, old days of OSS are mostly lost on me. I think I experimented with OSS with a couple of very old laptops about three or four years ago, but never saw any real advantage to using the old audio subsystem over the new.

That’s vaguely ironic, since now I don’t see any advantage to using JACK or pulse audio over ALSA. 😕

The source files for gom show updates as recent as 2009 though, so it may be that you can still milk the OSS framework and have a viable audio mixer at the terminal.


That’s probably not a fair screenshot of gom, since I’ve really only installed the OSS framework in Arch, then force-built gom and gotten into the interface. It’s not really working the audio on this system.

But it should give you a general idea of what gom does, and how it handles itself. No color, nothing flashy, none of the wild craziness of alsamixer (that was a joke 🙄 ). Just channels and data, and the ability to control the audio at hand.

gom is in both AUR and Debian, but I only built the Arch rendition. Like I mentioned, I needed to build oss out of AUR, which was not a huge challenge. I had alsa-oss installed as well, but I don’t think that was necessary.

Using gom reminded me of both rexima and aumix, in that they all seem to take a back seat to alsamixer. It may be that gom had a finer hour ten years ago, but I’d be surprised if there were still OSS fans out there, and if they would put gom to use. 😦

alsamixer: The interface we all know and love

I’ve had some adventures with the alsa libraries lately that warrant mentioning them here.

More specificially, alsamixer, the console interface for alsa, et. al.


You’ve probably seen alsamixer before, either in screenshots or in your own console adventures.

It works more or less as you might expect any other audio control panel to work — q.v., rexima and aumix.

Left and right sliders for each control, preset jumps at the number keys, mute buttons with M, and so forth. There are also some startup flags that will change the interface, or for example, remove the color.

The reason this becomes interesting, particularly to me, is because of the machine I’m typing on, right now.

Before I came across this Acer V5-122P, every computer I’d ever worked with had a simple enough audio card that alsa and company set themselves up without any intervention on my part.

And I will admit that in Linux Mint, which I showed a long time ago, there was also no problem with sound.

Under Arch however, there were some unusual behaviors.

To start, there were two labeled sound cards — HD-Audio Generic 0 and HD-Audio Generic 1.


By default, at boot, Arch latched on to the first available card, and used it as the default for the sound subsystem.

Where’s the harm in that? Well, as you can seen in the screenshot above, there is no audio control attached to card 0.

That, of course, confused the heck out of most audio players. mocp just refused to run. Others would run, but could generate no sound.

Card 1 was still accessible, by me, and I could control it, but there wasn’t a whole lot to be done in other software.

Before this gets too boring, I’ll cut to the solution.

In short, I had to feed the settings to alsa through the .asoundrc file in my home directory. Here are the settings that worked for me.

defaults.pcm.card 1
defaults.pcm.device 0
defaults.ctl.card 1

I will be honest and say I’m not really sure why each one works there. Linux Mint and other suite distros did this for me automagically.

I just twiddled with the settings until the right card appeared in music players — and in alsamixer when it started up. And so we’re back to alsamixer.

Since then it’s been nothing but happy puppies and sunshine. Isn’t the world a wonderful, musical place? 😀