At last we reach the final installment of this series, the question & answer stage in which we'll consider some of the common problems encountered with audio and MIDI on Linux, along with some common and perhaps not-so-common solutions to those problems. We've looked at some indispensable items for your Linux system troubleshooting toolkit, now let's see how they are applied.

We start with a list of some of the most often-heard laments, then we'll proceed to some extra tips and general advice. I'll end the series with some notes regarding the system configuration here at Studio Dave.

If/Then: Ailments & Cures

Linux audio problems can occur at any of these stages :

• Hardware - Physical connections, power status
• Soundcard - ALSA driver and configuration
• Software - Virtual connections, JACK status

Problems at these points will likely cause audio distress.

The following "laments list" is of course incomplete. New problems arise as Linux itself evolves, but the difficulties listed here represent the complaints most commonly encountered on the various mail-lists and forums to which I'm subscribed. I encourage readers to send in their own examples to add to the list.

If: "My soundcard doesn't make any sound."

Then: Make sure your audio hardware is supported by your sound system. Check the ALSA Soundcard Matrix to see if your card or chipset is listed. If it is not, your card may not be supported and you will need to purchase a different device. If you know your hardware is supported, double-check all connections to & from the device. Make sure all cables are integral and all connections are firm. Check power sources and ensure that all amplifiers, speakers, and mixers are powered up and appropriately connected. Make sure the right connections have been made: You'll have little success adjusting everything else if your guitar is plugged into a speaker output jack instead of the line-in.

If the hardware is correctly installed and connected, it's time to check things at the ALSA stage. Use the following command to see what's actually installed on your machine :

	cat /proc/asound/cards

Here's what the output from that command looks like on my JAD box :

dlphilp@The3800:~> cat /proc/asound/cards
 0 [Live           ]: EMU10K1 - SBLive! Value [CT4832]
                      SBLive! Value [CT4832] (rev.8, serial:0x80271102) at 0xa000, irq 22
 1 [VirMIDI        ]: VirMIDI - VirMIDI
                      Virtual MIDI Card 1

If nothing is reported and you're certain your device is supported by ALSA, run the alsaconf utility (as the root user) to configure and install the correct device driver for your card. After installing the driver you will need to adjust the soundcard mixer output levels. Open a terminal window and run alsamixer or any similar mixer utility. Set the main output and PCM channels to about 75% of their full output, then use a program such as ALSA's aplay or the excellent AlsaPlayer to play a WAV, OGG, or MP3 file. If the file plays without problems run the alsactl program (again as root) to permanently store your mixer channel settings :

	alsactl store

Devices that require firmware may need a specific version of that firmware in order to work under Linux. It may happen that your device is supported but its firmware version is not. This information should be available from the ALSA site, but you may also need to inquire on one of the Linux audio mail-lists.

Check software connections too. If you're using JACK, make sure that I/O ports are correctly connected. The last device in your playback or processing chain must be connected to the alsa_pcm outport, else no audio signal will ever reach your speakers. Under typical circumstances you'll use QJackCtl or a similar program to make your JACK I/O connections, but some programs (e.g Csound5) provide an internal mechanism for connectivity to the outside world. Make sure that your application is correctly configured for operation with JACK (i.e., that the correct input/output ports are selected).

If you still have no sound (after double-checking all steps taken so far), then it's time to call for reinforcements. Search the archives of the Linux Audio Users and the Linux Audio Developers mail-lists. You may want to check the ALSA list archives as well (and it would be a good idea to join those lists). Search Google, starting with a string such as "sblive problem linux" and narrowing your search terms as you proceed (e.g. "sblive irq problem 64studio").

If Google and the archives provide no assistance you'll need to ask directly on the lists and any other available comm lines, including relevant forums, wikis, and IRC channels. At this stage you should be prepared to answer some technical questions, so keep the first two parts of this series handy. The gurus of Linux audio are normally quite willing to help even the newest of newbies, but they can help only as far as you can supply relevant useful information. You will be asked for the output from commands such as lspci and lsmod, but don't worry if you have little or no idea what those reports mean. The gurus know, and they'll need that information to help you with your problems. At least make sure you know the name of your soundcard or audio chipset. You should also run the basic diagnostics with the cat command-string shown above.

Above all, be patient and polite. Gurus and wizards are unpredictable life-forms, and we must approach them with humble sincerity. Actually, most of my contacts have been pleasurable and helpful, but they are always most helpful when I've done my preliminary homework. Remember, they are also busy people, and they're often busy improving the very software you may be complaining about, so when you're asking for help, ask nicely.

If: "I get sound but it's chopped up whenever I play a soundfile."

Then: This problem usually occurs with an IRQ conflict. Your sound device requires an otherwise unoccupied IRQ line (a.k.a. an interrupt), else the devices sharing the interrupt will collide when requesting its services. In fact, devices can successfully share an IRQ address, but at no time should the sharing devices operate simultaneously.

You don't have many possible solutions for this problem. Many modern machines include user-programmable IRQ assignments (APIC: assignable programmable interrupt controller), but failing a software solution you may need to remove your card from its current slot and put it into another one (i.e. the IRQ addresses are hard-wired on the motherboard).

Use this command to determine which devices are using what interrupts :

	cat /proc/interrupts

On my JAD box I receive this report :

dlphilp@The3800:~> cat /proc/interrupts 
           CPU0       
  0:     361910   IO-APIC-edge      timer
  1:      24389   IO-APIC-edge      i8042
  7:          0   IO-APIC-edge      parport0
  8:          2   IO-APIC-edge      rtc
  9:          0   IO-APIC-fasteoi   acpi
 12:          4   IO-APIC-edge      i8042
 14:      76035   IO-APIC-edge      ide0
 16:     696033   IO-APIC-fasteoi   libata, eth0
 17:          0   IO-APIC-fasteoi   libata
 18:          2   IO-APIC-fasteoi   ehci_hcd:usb1
 19:       3316   IO-APIC-fasteoi   ohci_hcd:usb2
 20:          3   IO-APIC-fasteoi   ohci1394
 21:     586617   IO-APIC-fasteoi   nvidia
 22:          0   IO-APIC-fasteoi   EMU10K1

As you see, my SBLive is indeed sitting on IRQ 22, which was also reported by the earlier use of the cat command. If two devices were listed at that address I would then have to move or otherwise reassign my device to a new IRQ location.

The optimal interrupt assignment can be a bit tricky to determine, but hyperguru Mark Knecht has prepared some notes describing the analysis and correction of IRQ conflicts. This information is especially helpful :

Here's the order of interrupt priority on a non-APIC machine:

0, 1, 8, 9, 10, 11, 12, 13, 14, 15, 3, 4, 5, 6, 7

0 is the highest priority


7 is the lowest priority

Potentially interrupts 9, 10, 11, 3, 4, 5, 6, 7 are made available to PCI slots on most motherboards. You must look at your specific motherboard to know what's available to you. Many newer boards allow you to change the IRQ settings for the PCI interface in the motherboard's BIOS. This is also useful for USB devices as the USB IRQ generally tags along with one of the PCI slots. So you may be able to change the IRQ for your USB card by adjusting the the BIOS settings for the PCI slots. If you cannot adjust the settings in the BIOS your other option is to open your machine and move the cards around in the available slots.

In my experience all audio cards want to be on IRQ's 9, 10 or 11. It isn't actually that important what IRQ a card is on, but it is important which devices are on the higher IRQs. For instance, if your audio card is on IRQ 11, and nothing is on IRQ 9 or 10, then no problem. But if you insert a PCI graphics adapter on IRQ 9, your audio card could start having trouble because the graphics adapter would have higher performance priority. Assume that any device with a higher priority number gets in the way of devices with lower priorities.

One last thing about non-APIC: Interrupts may be shared. Just because your card is on IRQ 9 doesn't mean that another device isn't sharing IRQ 9. What matters in this case is how many interrupts the other device is going to generate, and how well its driver is written.

Mark's notes apply to both APIC and non-APIC machines. The APIC architecture adds more interrupts to the system, along with programmable assignment. For more information on the subject, see Clement Ladisch's page on Setting Linux Interrupt Priorities.

Stuttering audio may also occur if a system sound daemon such as KDE's artsd or GNOME's esd is installed and running at the same time as the JACK audio server. Remove or disable the daemon to eliminate the problem.

If: "I get sound but it's noisy."

Then: Mute all mixer channels except the main volume output and the PCM channel. If the noise disappears, raise the channel levels one by one to determine which channels are noisy. For example, the CD and mic channels on my SoundBlaster PCI128 must be muted when not in use, else they create an audible and very annoying hiss. For best results, always mute unused mixer channels, especially when recording. Note also that merely bringing levels down to zero may not entirely eliminate channel noise. Mute those unused channels, it's a good rule to follow.

Cable quality can definitely make a difference. Avoid cheap unshielded molded-end plastic cables, and use good-quality connectors. A loose-fitting plug can cause static noise and audio dropout, and the jacks on consumer-grade soundcards are typically not high-quality connectors, so you should ensure that all connections to the card are made firmly, with no "wobble". If necessary, purchase better connectors (I use the gold-plated adapters from Radio Shack).

Alas, computers are inherently noisy devices. Along with the audible sounds from fans and drives, your machine creates RFI (radio frequency interference) noise that can be picked up by sensitive equipment such as your soundcard. Professional audio boards work around the problem by shielding the board hardware and by providing an external break-out box to house the RFI-sensitive ADC/DAC converters. Consumer-grade cards are more prone to noise pollution, and if the problem is serious enough you may need to purchase either a better soundcard or a better motherboard. I considered this issue when I purchased the motherboards for my desktop machines, and I settled on AMD64-based boards from Gigabyte after reading on-line recommendations from other audio enthusiasts.

One further note regarding noise sources: I have a very nice HP Deskjet 6540 printer attached to my 64Studio box, and it is a wonderful device. Alas, when the USB cable is plugged into the printer it causes a thin screeching sound through my speakers that disappears only when the cable is detached from the printer. Even turning off the printer doesn't fully cancel the noise, it just changes its frequency. Fortunately the noise doesn't affect my recordings, it occurs only during playback, and unplugging the cable completely eliminates it.

If: "I'm using JACK, and periodically it creates a crackling noise."

Then: Make sure JACK's sample rate is set to the optimal value for your card and for your purpose. SBLive owners should note that their soundcard is hard-wired to record at 48 kHz, not the CD-standard 44.1 kHz, so JACK's sample rate should be set to 48 kHz. If the problem persists, contact the JACK developers. This problem is well-known, and it is usually the result of a mismatched sample rate.

If: "JACK reports too many xruns."

Then: In JACK-speak, an xrun is a lapse in the audio data stream. Depending on the circumstance and your hardware, an xrun or two may be dismissable, but more than a few usually indicates that something in your system is seriously misconfigured. The two most common solutions for xrun problems are: 1) Your Linux kernel is not optimized for realtime performance, or 2) your JACK settings are incorrect.

Regarding the Linux kernel, I'll cut to the chase: In my opinion, these days the normal user has little or no business mucking about with building and installing a Linux kernel, especially if the kernel is being built for a specific purpose (such as a digital audio workstation). We have so many excellent realtime-optimized distributions available now, in which all (or at least most of) the hard work has been done for you by experienced developers, and it just doesn't make much sense to undertake the task of configuring and installing a specially-tailored kernel. It's not that building a kernel is so difficult, it has simply become unnecessary. Furthermore, a low-latency system is more than just an optimized kernel, it includes many other configuration options that may or may not be obvious to a normal user.

By the way, if you don't know whether your existing kernel is realtime-enabled, you can use the uname command to find out. Here's what it says about my JAD box :

dlphilp@The3800:~> uname -a
Linux The3800 2.6.19-5-rt #1 SMP PREEMPT Sat Nov 25 18:35:39 UTC 2006 i686 athlon i386 GNU/Linux

The important item here is the kernel version number 2.6.19-5-rt. The "rt" indicates that this kernel (version 2.6.19) has been compiled with realtime optimizations. If uname reports a kernel without the rt extension then there's a good chance you're running a kernel that may not be a best fit for JACK. If that's the case, I highly recommend installing one of the multimedia-optimized distros. Otherwise, you must configure and install an optimized kernel yourself (see the Low-latency HOWTO for information on building your own realtime kernel).

JACK itself has a variety of settings that can affect realtime performance, as you can tell from the Parameters panel in the QJackCtl Setup screenshot seen in Figure 1. Obviously the Realtime option should be checked, especially if you're working with a realtime-enabled kernel. These settings also affect realtime performance :

• Frame rate/period size - A lower value decreases latency but may increase xruns.
• Sample rate - Set to optimum value for soundcard and project requirements.
• Period/buffer - Typically set to 2, but may need adjusted for some chipsets.
• Duplex/simplex operation - Duplex (simultaneous input/output) requires more CPU.

If: "The audio during DVD playback is unbalanced."

Then: Check your media audio output configuration. If it's set for 5.1 or other multi-channel output then you must have the appropriate hardware, else some audio channels will not be heard clearly (or at all). Check your player's audio preferences, set them to correspond to your hardware capabilities.

If: "My mixer levels are gone when I reboot my machine."

Then: Set your mixer channels to the desired levels, then run alsactl store. Remember, you must run the command with root privileges, otherwise the settings will not be written. If the problem persists, contact the ALSA developers.

If: "The audio latency in WINE is terrible."

Then: You have at least two possible solutions. You can purchase a faster machine (WINE seems to favor speedy hardware) or/and you can use the wineasio driver. If you choose the wineasio solution, make sure its sample rate matches the value in JACK.

This concludes the Q&A part of Troubleshooting Linux Audio, Part 3. Due to space restrictions I must split this part, so I'll present some MIDI troubleshooting strategies and some final remarks and comments in my next entry.