Configuring sound for laptops running Linux can be a very tricky process. Drivers may be difficult to find or install, reference materials may be incomplete or misleading, and even after careful configuration, your system may still emit no more than the beep from its internal speaker. In other words, setting up sound on a Linux laptop can quickly become an unwanted exercise in patience and frustration.
The following article describes my experiences installing and configuring a sound system for an HP Omnibook 4150. I used the standard-issue kernel modules (OSS/Free), the commercial OSS/Linux package, and the ALSA drivers. I must stress that there is no typical configuration for sound on Linux laptops, and you must be prepared to do some research to find the necessary information about your machine's particular audio chipset and its capabilities.
I purchased my Omnibook from an online vendor. It arrived safely with a 366 MHz PII, a 6 GB hard disk, 96 MB of memory, and no operating system. I installed a Debian 2.2 stable system with a 2.2.19 kernel, and then I immediately began configuring my new machine for sound.
The potential for confusion existed at the very start of my adventure. At least two very different versions of the 4150 exist: apparently standard Windows got one version while NT got the other. Fortunately, the Omnibooks are well-documented by Hewlett-Packard, and some adventurous Linux users have placed valuable setup material online, so I had no trouble getting technical and other details for this machine. Be advised: if you are considering a laptop for audio use under Linux, I urge you to first visit the Linux On Laptops site, and then read the Linux Laptop HOWTO. These pages contain information about almost every aspect of whatever machine you are considering, including audio and video capabilities. Google is also an excellent resource for finding manufacturer's documentation, and Google's Deja newsgroup searches can discover more user-mode information.
HP Omnibooks with "4150" after their serial numbers (like mine) contain a NeoMagic NM2200 multimedia chipset (aka NM256 A/V), the sound side of which seems to be a combination of the Analog Devices AD1848, the Crystal Semiconductor CS4232, and/or the Yamaha OPL3SA2 audio chipsets. Omnibooks that have "4150 B" after their serial numbers utilize the ESS Maestro audio chipset. The ESS Maestro has its own set of difficulties, and the information presented here does not apply to the 4150 B.
The reference guide states that the 4150 provides support for 16-bit stereo sound capability equivalent to the SoundBlaster Pro soundcard. It also mentions "3D-enhanced PCI bus audio," but I was unable to verify its availability in current Linux sound drivers (nor was I able to learn exactly what "3D-enhanced PCI bus audio" means). (Note: As this article went to press, I learned that the 3D enhancement is a feature of the OPL3SA2 chipset, but I did not have time to investigate its significance.)
The 4150 comes equipped with an internal microphone, a pair of internal speakers, and jacks for audio line out/headphone out, external microphone in, and audio line in. The output jack is stereo-only, and the manual clearly states that using a mono plug can damage the channel hardware. This is true for many laptop audio input/output jacks, so take care to use the proper connectors.
The sound quality of the Omnibook's internal speaker system is adequate in a quiet environment, but at peak volume their output is not strong. Happily, even inexpensive headphones sound good, and when the line out is run to external speakers, the sound quality is at least as good as the audio output from the original SoundBlaster Pro. The internal microphone works well and is fairly sensitive, but its limited frequency response restricts its utility primarily to relatively low-quality speech input. My machine also has a physical volume control manipulated by the Fn key and the up/down arrow keys (I like this feature a lot).
Following the advice of other 4150 owners, I first set up the OSS/Free sound modules built from the 2.2.19 kernel sources. I configured the audio system by adding these lines to /etc/modules.conf:
alias sound-slot-0 ad1848 options sound dmabuf=1 alias synth0 opl3 options opl3 io=0x388 options ad1848 io=0x530 irq=5 dma=1 dma2=0
This configuration gave me PCM and CD audio, along with the well-known OPL3 FM synthesizer.
Incidentally, I verified these values by looking at the 4150's BIOS before loading Linux. Pressing the F2 function key during boot-up took me to the BIOS settings, where I found a helpful report on the on-board audio chipset, including its on/off status, port addresses, and IRQ values. In the absence of other documentation, your machine's BIOS may be able to provide information critical to setting up audio, video, communications, and other devices, so watch the screen carefully during the initial boot sequence for instructions on accessing the machine's BIOS. Typically, you'll press the Delete key or one of the function keys (F1-F12), but your access procedure may vary.
If for some reason you cannot access your machine's BIOS, or if it does not provide a summary of its audio chipset, you can still use the
lspci command to at least determine the type of chipset used. For instance, on my machine running
lspci returns this information about my the internal audio device:
01:00.1 Multimedia audio controller: Neomagic Corporation [MagicMedia 256AV] (rev 20)
Talk about confusing ... I asked ALSA developer Takashi Iwai about this variance in perceived identity. He said that the chipsets are siblings and described their relationship in this manner:
AD1848 --> CS4231 --> CS4232 --> CS4236 | +--------> OPL3SA2
Apparently many chipsets integrate the CS423x chips (as does the NM256AV), so the lesson learned here is that an audio chipset may be a sort of "amalgamated" device, and you may need to try a variety of drivers to find the one that works best for your machine.
Anyway, now I could record and play back full-duplex audio, and I could access the FM synth via MIDI players such as
playmidi and TiMidity++. All in all, I was satisified with the default audio system for this machine running kernel 2.2.19.
Alas, the kernel sound modules will not resume operation after putting the machine into suspension (
apm suspend). Furthermore, I upgraded the kernel to 2.4.18 and discovered that my configuration for the 2.2 kernel no longer worked. So, on to the next stage ...
I didn't feel like working with the kernel modules any longer, so I thought I'd try the commercially-available OSS/Linux package from 4Front Technologies. The excellent OSS/Linux setup utility (Figure 1) identified the NeoMagic NM2200 chipset as the default sound system, yet no services were available. A quick exchange of messages with 4Front's technical support solved the problem: I deleted the NM2200 driver, replaced it with the NM256 driver, and voila, I had PCM and CD audio along with the OPL3 synth, and I had no trouble with audio resuming after a suspend mode, all on a brand-new 2.4.18 kernel. Audio performance was as good as it gets for this hardware, but the OSS/Linux package includes a very good equalizer and 3D effects for sound shaping and enhancement. I should also note that 4Front's support was very prompt and helpful.
As you can see in the screenshot, OSS/Linux designates the Yamaha OPL3SA/WSS (Windows Sound System) chipset as one of the main ingredients making up the NM256. It also defines an interrupt and base address for the (non-existent) external MIDI port.
OSS/Linux provides otherwise-unavailable support for cards and chipsets the manufacturers of which require an NDA before coughing up their driver specifications, so if you can't find a driver for your chipset in the OSS/Free or ALSA packages, you might be able to find it in OSS/Linux.
Figure 1: The OSS/Linux soundconf utility defines the NM256 audio capabilities
I originally intended to run this machine under a Debian installation with ALSA sound drivers, so I downloaded the ALSA 0.9.0rc2 packages and built/installed them according to the instructions. Alas, I couldn't find the right combination of modules that would give me at least the capabilities of the OSS/Linux and older kernel modules. The NM256 module didn't work: it loaded all right, but I had no audio capabilities from it. I tried using the AD1848 module and got the same results. Fortunately, Takashi Iwai helped configure my machine by using the CS4232 module. First he added this line to my /etc/modules.conf file:
options snd-cs4232 snd_port=0x534 snd_cport=0x538 snd_mpu_port=-1 snd_fm_port=0x388 snd_irq=5 snd_dma1=1 snd_dma2=0
This information defines the card capabilities with values similar or identical to those found in the BIOS. Takashi verified that the correct base address for the audio port in this hardware is indeed 0x534, with the control port at 0x538. There is no MPU MIDI interface hardware (hence a value of -1), but the OPL3 is where it should be. Note that the IRQ and DMA values are also unchanged from those found in the BIOS.
With the chipset's options defined, I could now load the ALSA modules via this small script:
echo "Installing ALSA..." modprobe snd-cs4232 # load CS4232 module modprobe snd-seq # load ALSA sequencer module modprobe snd-pcm-oss # load OSS/Free PCM compatibility module modprobe snd-mixer-oss # load OSS/Free mixer compatibility module modprobe snd-virmidi # load ALSA virtual MIDI module # load 4-operator patches into OPL3 (using ALSA's sbiload utility) sbiload -p 65:0 -4 /etc/std.o3 amixer set PCM 57 unmute # set value for ALSA mixer PCM channel amixer set Aux 28 unmute # set value for ALSA mixer Aux (CD) channel echo "ALSA installed !"
Note that this method is not the way recommended by the ALSA documentation (which suggests using the
alsactrl utility), but I use it because I sometimes need to quickly load and unload the ALSA and OSS/Linux modules while testing Linux audio software packages. Note also that the ALSA mixer is muted by default, so you must set channel I/O values with an initialization script (
alsactrl or something similar to the script above) or by using a software mixer such as
gamix (Figure 2) for X, or ALSA's own
alsamixer at the console.
Figure 2: Using gamix to set mixer channel values (CS4231 here == CS4232)
At this point I again had PCM and CD audio services, along with the OPL3 synthesizer and support for applications requiring the legacy OSS/Free API. I also installed ALSA's virtual MIDI module, giving me access to a virtual second soundcard with four virtual MIDI ports that could be accessed as though they were true MIDI hardware.
But of course I couldn't just stop there and be happy ...
TK-707 is a wonderful software reincarnation of the Roland TR-707 drum machine. Most of the features of the original have been retained, and an excellent Tcl/Tk GUI accurately recreates the TR-707's appearance (Figure 3). As of version 0.6, TK-707 is unmaintained, but Takashi Iwai has supplied three small patches to keep this software alive and useful. One patch prepares the TK-707 sources for compiling with ALSA 0.9.x, while the others correct the behavior of the program's Ports window that defines its MIDI I/O.
Figure 3: The TK-707 software drum machine (Click on the image for a larger view)
Armed with Takashi's patches, I upgraded and rebuilt TK-707. Alas, although the program would load, it would freeze after a few measures of play, locking my machine completely. Takashi informed me that a bug in the ALSA timer was causing this behavior and that it had been repaired in ALSA CVS. Under his careful guidance I compiled and installed the latest ALSA drivers, prayed for some luck, and ran TK-707. Ahh, satisfaction: no freeze, no lockup. (Note: The timing problem in ALSA 0.9.0rc2 has been repaired in the latest publicly-available packages.)
Getting TK-707 and ALSA to play nice together was only the first step in my plan. I could now set up TK-707 to send its output to the OPL3, but I was certainly not pleased with the sounds from that chip. I recalled reading in the TiMidity++ HOWTO (by none other than Takashi Iwai) that mentioned a way to use that program as an ALSA server/sequencer. If I correctly understood the article, I would be able to route the output from TK-707 into TiMidity++ and access the better sounds of the Gravis Ultrasound patches (GUS PAT files) or SF2 soundfonts. However, in order to do so, I would need to apply a patch to TiMidity++ (from Takashi of course) and rebuild that program, too.
Alas, due to a bug in the configure scripts, I could not compile TiMidity++ in versions 2.11.2 or 2.11.3. Takashi suggested I build and install the 2.12.0-pre1 development package that had already integrated his patch into its sources. This suggestion worked, and I built and installed a version of TiMidity++ that could function as an ALSA sequencer client by running it with these command options:
timidity -iA -B2,8 -Os -EFreverb=0 -EFchorus=0 &
-iAdefines the interface as ALSA sequencer
-B2,8sets buffer and fragment sizes
-Osdefines output mode as ALSA PCM
-EFreverb=0turns off the reverb effect
-EFchorus=0turns off the chorus effect
The MIDI-to-WAV rendering engine in TiMidity++ would then be available as an audio sequencer/server for other ALSA-aware applications, such as TK-707. By default, TK-707 would access the GUS patches defined in my /etc/timidity.cfg file; however, I also wrote another TiMidity++ sound configuration file called timidity-sf2.cfg that contains only this line:
-c /etc/timidity-sf2.cfg to the TiMidity++ command options shown above, I would also be able to access the General MIDI drums and percussion available in that soundfont file.
So after all of this effort, did it work? And were the results really worth that amount of effort?
I ran the command sequence shown above, made a few magic passes over the machine, then I fired up TK-707. When it loaded, I opened the Ports window (Figure 4), selected and saved the TiMidity++ port for my output interface, and mirabile dictu, I could now write and play drum patterns and tracks in TK-707 with my favorite sound sets in either PAT or SF2 format. With TK-707's
wav2pat utility and Josh Green's fantastic Swami soundfont editor, I can now use any soundfiles on my hard disk as sounds to play via TK-707.
Figure 4: TK-707's Ports window
As to the worth of this endeavor, I've placed three soundfiles online that demonstrate TK-707's output to GUS PAT files (the Midia set), to soundfont patches (the
8mbgmsfx.sf2 set), and to the OPL3 (the standard
drums.o3 set). Check them out, then feel free to tell me which you prefer (I'll be curious to see how many of you vote for the OPL3). For your listening satisfaction, the files are available in MP3 (encoded with LAME) and OGG (encoded with
oggenc) formats, and you can find them at http://linux-sound.org/sounds.
If you want to work with soundfonts, you'll definitely want to have Josh Green's excellent Swami in your toolkit. Swami is a powerful soundfont editor with a well-designed GUI and a wealth of useful features (Figure 5). You can edit and create composite instruments or individual samples, and you can design your own SF2 banks. Swami also utilizes Peter Hanappe's
iiwusynth, a software synthesizer that uses soundfonts as fuel for its synthesis engine. The program really deserves an article of its own, but I can tell you that using Swami is very easy, so I won't say more about it here. Just get it and have fun ...
Figure 5: Josh Green's Swami in action
If you are truly hardcore and swear by the definitively cheesy sounds of the OPL3, then you must have John Meacham's OplEdit. This handy little program presents the OPL3 FM synthesis parameters in a simple interface for editing existing patches or creating new 2- or 4-operator sounds. No bank editor, sorry, but the program does have a neat patch randomizer. By the way, starting OplEdit with the
-d /dev/midi1 option sets up the editor to listen for any MIDI messages arriving on my first ALSA virtual MIDI device, allowing realtime sound editing. For example, I can route the output from the
pmidi MIDI file player to /dev/midi1 by setting its port flag to the device's port number (determined by running
pmidi -l). I can then create and edit patches in realtime while
pmidi plays the MIDI file of my choice. (Note: The astute reader may wonder what happened to /dev/midi0. ALSA recognizes the CS4232 as the first soundcard in my machine, and /dev/midi0 belongs to that card. The devices themselves are actually ALSA's /dev/snd/midiC0D0 (/dev/midi0) and /dev/snd/midiC1D0 (dev/midi1).)
Figure 6: John Meacham's OplEdit dignifies the OPL3
I recently discovered that the STEEM Atari ST emulator can communicate with Linux's /dev/midi. I have some external MIDI equipment, so I was pleasantly surprised to find that XSteem (STEEM for X) worked with my ALSA MIDI system. STEEM's audio hardware support is emulated only for the SoundBlaster16, but that's enough to give access to the MIDI hardware (/dev/midi) and the PCM device (/dev/dsp) of the basic OSS/Free API. As already noted, my laptop has no MIDI interface hardware, but after working with TiMidity++ as an ALSA server/sequencer I wondered if I could wire the output of an Atari MIDI application from STEEM to TiMidity++. So I fired up TiMidity++ with the options shown above, then I started XSteem and Bob Ham's excellent ALSA MIDI patch bay (a GUI for ALSA's
aconnect utility). I connected ALSA's virtual MIDI port 0 (
== /dev/midi1 in Xsteem) to the TiMidity++ client (Figure 7), and voila, I had the output from an emulated Atari ST MIDI program routed to the GUS patch set via TiMidity++. None of this activity would matter much if it weren't for the fact that the Atari ST/Falcon computers acquired many excellent MIDI sequencers, notation editors, and synthesizer patch editors and librarians. Atari MIDI software also boasts an outstanding collection of algorithmic and experimental composition programs, many of which are now available for free at Tim's Atari MIDI World (see Resources). I've been able to run David Zicarelli's M, Jim Johnson's Tunesmith, and Clarence Barlow's Autobusker on my Omnibook via ALSA's
virmidi module, which to my mind is just very cool.
Figure 7: The ALSA MIDI Patch Bay making its connections
Xsteem's performance is good under normal user conditions, but the quality of the timing is improved greatly by launching TiMidity++ as root. Doing so will ensure that the rendering engine will run
SCHED_FIFO (i.e., the Linux scheduler will give it a high priority).
Figure 8: Xsteem presents Jim Johnson's Tunesmith algorithmically playing away on a GUS piano patch
After going through my own Linux laptop audio setup gauntlet, I decided to poll the members of the Linux Audio Users mail list to see what they are getting from their machines and to ask how they made it happen. The results were quite interesting, and I've prepared a separate page tabulating the LAU responses (Table 1). I would like to keep the table current, so please contact me with your own Linux laptop audio information and I'll add it to the list.
My experiments go on: I have yet to work with any PCMCIA audio cards, and I have not checked out serial port MIDI interfaces or USB audio devices. I'm also eager to test other emulation environments on this machine, particularly DOSemu and UAE (the Universal Amiga Emulator). But I'm out of space now, so you'll either have to wait on my next report or write one yourself. Meanwhile, I hope this article has indicated what you need to know and may have to go through in order to successfully set up sound on your own machine. If you'd like to share your experiences with me, feel free to write to me at firstname.lastname@example.org or via the LAD/LAU mail lists. Now go forth with your Linux laptop and make a joyful noise!
I must give vast thanks to Dev Mazumdar at 4Front Technologies and to Takashi Iwai at ALSA for their assistance while I wrote this article. Thanks also to the crews on the LAD/LAU mail lists for being such creative and informative people: I'll see you all in the bitstream!
Dave Phillips maintains the Linux Music & Sound Applications Web site and has been a performing musician for more than 30 years.
Return to the Linux DevCenter.
Copyright © 2009 O'Reilly Media, Inc.