Linux Audio-Quality-HOWTO



Version 0.0.9g by Paul M. Winkler, Sept. 12, 2000.
You should always be able to find the latest version of this document at

What's New in This Version

In version 0.0.9g: A link to a low-latency 2.2.16 kernel RPM, some notes about CD audio ripping, and commentary on the SoundBlaster Live. Version 0.0.9f: Updates about SoX, and a link to my mini-howto on the 2.4.0-test series with Andrew Morton's low-latency patches.


This is a document for musicians and others who need to get good-quality sound out of a Linux box. The intention is to make it easier for those migrating to Linux to get their system to sound good. The Linux Documentation Project's Sound-HOWTO and Sound-Playing-HOWTO serve their purpose well, but the focus there is (quite appropriately) on functionality, not quality.

The Audio-Quality-HOWTO was first released on May 16, 1999.

Please Contribute!

If you have any tips or recommendations that would be appropriate here, please send them to me at Please note that this page is copyrighted by me (Paul Winkler) under the Linux Documentation Project (LDP) license. By sending me information for this document, you are consenting to have your information included under the terms of the LDP license. I will give credit for all information I add to the HOWTO and add your name & email address (unless you request otherwise) to the credits at the end.

Future Plans for This Document
I know I keep saying this... The current version will probably be the last before considerable re-organization of this page. Keep tips coming... but don't be surprised if it takes a while for me to post them.
The Linux Audio-Quality-HOWTO will remain a website, rather than becoming a "proper" HOWTO. I intend to turn it into a searchable, semi-automated system where readers can post updates, corrections, and new topics without my intervention. At that point the site will be re-named as well. My current favorite name is LILAQ, which stands for "LILAQ: Information on Linux Audio Quality."

Hopefully this will make it easier to keep the site up-to-date. Right now I have to decide where every little bit goes, and reorganizing is always a pain in the butt, and readers have no way to find the most recently updated information, etc etc...



Information in this document should be regarded as hearsay. No advice in this document is guaranteed to be correct, complete, or even safe. Don't blame me if you mangle your soundfiles, trash your filesystem, fry your CPU, burn your house down, or lose your hair. See the copyright notice at the bottom for details on licensing and warranty. In short, there is no warranty.

As an aside to the above warning, note that I have received contradictory information more than once, and I am not often knowledgeable enough to know who is correct. In these cases I tend to include all contributed information, so the reader can exercise his / her own judgment. As an example, see the additions to the section on latency.

Please note that, in spite of the HOWTO in the title and the LDP license note at the bottom, this document is in no way affiliated with the Linux Documentation Project which coordinates most Linux HOWTOs. People should be aware that any errors, omissions, stupid ideas, etc. are not the responsibility of the LDP.

Note also that most hardware tips in this document are aimed at those running linux on Intel platforms. Those on PPC, SGI, Alpha, etc. may find things of value here, but as I have no experience with those platforms, there's not much I can do. Contributions from users of those platforms would be most welcome.

"Wait! I can't get my soundcard to work at all!"

If you haven't got any sound from your system yet, you are better off starting here: The Linux Sound HOWTO. It describes setting up the sound drivers that come with the linux kernel.

Or you might try ALSA, or Advanced Linux Sound Architecture, which is intended to replace the kernel drivers. It is still in heavy development but is already quite useable. See the Alsa Sound Mini-HOWTO for information on getting started with alsa.

Or if you're really frustrated and/or in a hurry, and you have $20, take a look at the OSS-Linux commercial drivers. This may be the quickest way to get things working.

Once your soundcard works, and you want to start actually listening to various kinds of sounds, you may want to read The Linux Sound Playing HOWTO.

The rest of this document assumes that you have your hardware more or less working.


Many affordable ($50 to $200 US) soundcards now offer pretty good digital audio (PCM) performance at a very low price, but the inside of a computer case was never intended to be a place for audio signals. There's so much interference in there it's a wonder any soundcards are any good at all. If you're plagued by noise, there may be measures you can take to reduce the problem, if not eliminate it. This document lists all the remedies I know of.

Software tips

  1. Mute all mixer channels. Does noise go away? If so, you're a lucky bastard. Unmute channels until you figure out where the noise is coming from. If not, keep reading...

  2. Here's a tip from the Sound-HOWTO. Does the noise seem to correspond with system activity? (mouse movements, disk activity, etc.) Try booting the kernel with the no-hlt option. The "hlt" instruction tells the CPU to go into a low-power mode when it doesn't have anything to do (which is normally pretty often). Usually this is a good thing-- it saves a bit of power and keeps the CPU cooler (over-clockers beware!). For picky sound people, the no-hlt feature can be a disaster: the CPU going in and out of hlt mode all the time dirties up the power supply very badly, and this gets into the soundcard.

    To disable hlt, add this to your /etc/lilo.conf file (either at the beginning, or under each image section):


    My previously-quiet soundcard got VERY noisy when I put it in a new system. I was able to drastically reduce the noise by using no-hlt.

  3. A related tip from Michael Brown, for users of cyrix 686 CPU's:

    "I have set6x86 (part of the f6x86 program) set up usually to power down the Cyrix on HALT (keeps the system cooler!). I tried append=nohlt, that was good. I also tried using set6x86 to put the processor back into full power mode, that did it too! (Even using halt as usual, it seems)."
  4. Make sure you're not sharing a DMA between the soundcard and anything else. I've heard that this can cause noise problems. Do cat /proc/dma to find out.

  5. Does your soundcard have a Surround Sound or "3D" feature? If so, is it turned on all the time? If yes, it is probably adding a lot of hiss. You can find out if it's on by playing a stereo soundfile that is silent in one channel. The surround will probably put some weirdly-phased signal in the channel that's supposed to be silent.
    For example, my card has "SRS 3D" processing which adds an awful lot of hiss and gunk, not to mention ruining any panning effects I try to create. If your card is supported by ALSA, you should be able to turn 3D off with amixer or alsamixer. If you use OSS/Linux, you can use ossmixer. If you use OSS/free, you may be stuck. If you have a CS-4237B -based card such as the Turtle Beach Malibu (mine), you can try dspctrl , a little utility that lets you control the SRS and the digital output. If you have another card and you're a hacker, maybe you can use dspctrl as a guide for how to work with your soundcard (assuming the technical docs are publically available, which they're often not). If you do so, consider contributing your efforts to ALSA (if applicable).

  6. If your noise seems to be related to video movement, read the section on video cards.

  7. Michael Brown reports,

    "I figured it might be down to IRQ activity. It turned out to be xosview, which is a program to monitor system parameters, including IRQ. kill -STOPping it makes the noise reduce."
  8. Yet another tip from Michael Brown:

    "(this)... may apply to other cards too. My Audiotrix Pro when faced with "silence" records an icky digital hash noise at about -66db according to CoolEdit Pro (Windows). A small amount of signal makes it go away (not covers it, actually makes it stop!). I've found that this only happens at 44.1Khz. At 32Khz and 48Khz, the background noise drops to -76db and it is a broadband hiss, which is far less intrusive, and easier to noise-reduce out. Test out alternative sampling rates, you may find that another rate gives better quality. You will need to possibly employ a sample-rate convertor...."

Hardware tips

  1. Having problems with AC line hum? See the separate section on that below.

  2. Make sure any free inputs/outputs are plugged into something (not just an unterminated cable!). Michael Brown reports, "'Something' may include a jack plug with a short circuit across it. Better designers would have thought of this, and made the jack *socket* do the work when disconnected, shorting the input to ground." Or try using a small resistor instead of plain wire to short the jack... possibly some cards would prefer a load to a short. I've seen weird behavior like, even if the mic channel is muted, plugging in a mic changes the amount of background noise.

  3. Try heavier, better shielded cables.

    1. If the noise is just on the CD drive, replace the cheap, poorly- (or un-) shielded cable connecting the drive to the soundcard with one that has a decent shield.
    2. If the noise is on all channels, it's possible (though not probable) that the noise is not originating inside your computer at all. Try using better cable for your inputs and outputs.
  4. Still got noise? Open up your case and move your cards around. Try to put the soundcard as far away from everything else as possible (especially the video card and drive controllers). If it already is as far as it can get from everything, try putting it somewhere else. You never know.

  5. Try to keep drive cables as far from the soundcard as possible. This may not be an option.

  6. As a last resort, make an electrostatic shield for your soundcard. This is a slipcover shaped like an inverted "U". Usually people make it out of tin foil sandwiched between two thin layers of a non-conductive material like cardboard. The whole thing then gets covered with electrical tape. Make absolutely sure that no tinfoil is left exposed, or you could cause a short that would seriously damage your hardware. Now slip this cover over the soundcard and its slot. I have not tried this.

    Note that the shield MUST be connected to earth (ground) to take effect. The easiest way to do this is probably to connect the foil to the computer case (chassis) with a wire.

    Michael Brown reports, "Beware of hotspots in the computer, and of restricting the airflow to the card you have just wrapped :) I've tried this one, and it made no measurable difference, I guess the hash in my case is on the power lines."

Video Cards from Hell

Several years ago the manufacturers of PCI video cards discovered a way to increase their performance by playing unfairly with the PCI bus. This can put a lot of awful "zipper" noise into the audio output when you move windows around the screen.

A Possible Solution

Check your XF86Config file and see if there is a line like this:

Option "pci_retry"

It would be under the "Device" section. Try commenting it out and see if that helps. Or try adding this line, if it's not there. I'm not sure which is the "right way". It didn't make a difference for me, but then I don't have a PCI soundcard.

Another Possible Solution

Try an AGP video card instead of PCI. Pix writes,

"After looking around, it seemed that AGP was the way to go to stop getting audio dropouts whenever some video event occurred. This guess was based on the common explanation that the pops are caused when the PCI video card steals the whole bus to do some operations. Since AGP is a different bus altogether, it seemed like a good step.

"And I can say, at least at first glance, that it seems to be the way to go. At home, I had a Trio64, which recieved many pops and clicks (even when doing somet hing reasonably low on CPU usage). At work, I have a PIC Riva128 card, which also gets pops and clicks during focus changes etc. Just recently I purchased an AGP RivaTNT2 card, and I haven't been able to generate an audible dropout yet. PureData still occasionally reports DIO errors, but I haven't heard any of them yet.

"Since it's quite hard to get a non-AGP card nowadays, this has to be good news for linux audio :) "

What Causes the Video Card Problem

As mentioned above, a PCI video card tries to hog the PCI bus to increase its own performance. This interferes with other devices on the bus, including soundcards.

There is a good description of the problem at

Note that their list of solutions are all for Windows device driver settings. The only thing there that seems to have a clear analogy for Linux is the "pci_retry" option in your XF86Config file.

Note:I have also seen some anecdotes on that some VIA chipset-based motherboards, especially those with the VIA MVP3, are especially prone to this problem, and may also have problems with using UDMA mode for hard drives. I don't have much real information about this except that some people seem to like Asus motherboards better. Note that all these reports were from people running Windows 95 or 98... maybe that's their problem.

A partial list of cards that MAY have PCI-bus noise problems

(culled from* newsgroups)

Note that apparently most video cards now have this problem. But since it depends on the X-server you use, none (or all) of these cards may actually exhibit the problem. The trouble reports I read all had to do with running under windows 9x / NT. I would appreciate hearing from anyone with experience with these cards under linux.


You may be SOL ("s*** out of luck").


This section is mostly not Linux-specific; in fact it's not even computer-specific, but pertains to getting good quality audio in general.

Garbage in, garbage out!

First, it's important that the soundcard gets the highest quality incoming signal you can feed it.

Gain Structure

Jorn Nettingsmeier has a lot to say about this important topic. You can find more about these issues in, among other places.

"poor audio quality, both in terms of distortion and noise, often occurs due to improper gain handling. first, bear in mind that every amplifier has a range in which s/n ratio is optimal. this is usually not all-the-way-up! also, remember some amplifiers sound better than others.

when connecting a mixer (or any other device) to your soundcard, there is a mixer output amp and the soundcard input amp. it is safe to assume the soundcard amp is generally the worst in the studio. :) so in order to obtain maximum quality, let the mixer do the work and keep the soundcard input (often termed record gain) down. with my card, i can set it to zero, meaning that the amplifier will not amplify at all, but let the signal through as it is. watch out, though: other cards will mute the input at zero. anyway, keep it as low as possible and crank up the mixer output as much as soundcard can handle.

this has another advantage: the signal that flows through the cable will be louder than with low mixer out and high soundcard in. thus, the noise from random electro-magnetic garbage that creeps into the cable will be (relatively) lower.

generally, try to find those parts of the signal chain that are likely to pick up noise, usually long cable runs or everything inside the computer :( , and keep the signal as loud as possible there. watch for distortion, though. YMMV.

try to provide as high a level to the card's converters as it can stand, i.e. without the slightest distortion. remember: a shiny 20bit adc fed with too weak a signal will sound like an old 8bit. "hello, my name is linus torvalds, and i pronouce linux as lee-nucks". we certainly don't want that type of sound. no sacrilege intended.

same rules apply to the output. afaik, most soundcard mixers work in the digital domain. if you turn it down to 1/3 maximum level, you will again cripple your 20bit dac to 8 bits. so leave the output way up and control the volume at your monitor amplifier. you will gain considerably more detail at low level."

AC Hum

AC hum is the dreaded buzzing noise from the AC power supply that always seems to find a way into your audio signal. This buzz has a fixed frequency: 60 Hz in the USA, 50 Hz in most of Europe; I'm not sure what it is elsewhere.

If you have low-pitched hum problems, the good news is that the source is most likely not inside your computer at all. The bad news is it may be hard to find and fix.

First of all, it's possible that some part of your audio chain may have a poorly filtered power supply. Try removing one thing at a time from the audio path to see if you can spot a culprit. If so, try to see figure out if the hum is caused by this device's power supply; if so, get a better power supply.

If none of your devices seem to hum on their own, you probably have a problem with the grounding (also known as earth) of your electrical and / or audio wiring. If this is the case, you should proceed with caution, because messing with 120 or 220 volts without understanding what you are doing CAN KILL YOU. So please note that I am NOT an electrical engineer, and please read more sources before you fiddle with your AC wiring, because I may make mistakes and I cannot be held responsible for you getting killed by my mistakes. If you don't know what you are doing, please take precautions and please learn more before you give yourself a nice big electrical shock. As Jorn Nettingsmeier wrote,

"...absolutely-never-to-tamper-with-earth-connectors on high voltage devices such as computers. sure, i did myself. cures every hum loop. cured a fellow vocalist from eating the microphone. a voltmeter showed more than 100 volts on the metal gaze. (he lives.) must've slipped in somewhere. don't. i mean, just don't."

One good source I recommend for understanding hum problems is the FAQ. The section on audio interconnections explains ground loops and various strategies for fixing them.

There are two basic strategies recommended by the pros:

There are other techniques suggested by readers; here are some.

  1. Chris Green wrote to remind us that ground problems may start with your house wiring! There are plenty of houses with bad wiring out there.

    "One thing I had fun diagnosing ( and I'm glad that I did ) was my machine wasn't properly grounded. The outlet I was using [had the] ground prong ... improperly wired so I got [a] nice loud hum when I'd hook my computer into the stereo mix. Making sure to use an outlet with proper grounding and all was good."

    One way you might test this is with a voltmeter: first see if there is any AC voltage between the ground pin of two different outlets (there should not be), and then see if there is any resistance between them (there should not be).

  2. Another solution to hum problems is to route all your analog audio through transformers. Ralf Schlatterbeck writes,

    "I solved this problem by audio transformers that are connected between the audio card and the external equipment. You need four transformers, two for (stereo) playback, two for recording. You must make sure that you do not connect the ground through, otherwise the ground loop persists, so either do not use a metal chassis or use connectors that are isolated from the chassis (thats what I did) the isolating connectors are the gold-plated ones with the higher price :-) Make sure they really isolate ground from the chassis...
    This is the circuit diagram used (you need this four times):"
                       ---X X---
     from Comp.           X X       to external equipment
                       ---X X---

    But note that there are some disadvantages with transformers:

    Jorn Nettingsmeier writes:

    "the transformer solution that ralf suggests certainly works, but it has two major drawbacks:
    1. transformers, however good, reduce signal strength, possibly impairing sound quality. they may also introduce linear distortion, i.e. alter the sound like an EQ, and even non-linear distortion (fuzz) when saturated, i.e. when the signal current gets higher than the maximum magnetic flux.
    2. good transformers sell for no less than 80 deutsche mark per channel. since you need at least two for half-duplex stereo, that's more than most soundcards cost."
  3. Fortunately, Jorn has more to say about hum...

    "...there is another option: reduce the size of the hum loop. A hum loop is the same as a coil in a dynamic microphone, although it has only one turn. Any variable magnetic field will induce a signal voltage in it. And there's plenty of magnetic garbage flowing around electrical devices...

    btw, i've looked up the formula for induction:

      U = - n A B'
    where U  is the induced voltage in volts that giveth us such
    great grief;
          n  is the number of turns (usually one);
          A  is the size of the loop in square metres;
          B' is the amount of change in the magnetic flux
    density in tesla per second.

    the minus sign is cosmetics. it can normally be ignored, but is necessary to ensure the law of conservation of energy works :) .

    What does this mean ? To reduce U, reduce any of the factors on the other side of the equation. n and B' are difficult to handle, A is the easiest to go for. it's still worth the effort to keep electromagnetic garbage out of the way, but this may not always be possible.

    a) large hum loop, high hum voltage.
        |                          .
        | <- power cord            . <- audio cable
        |                          .             
        |                          .
        |                          .
        |                          .
        | ___________COMPUTER.......
        | |
        O O <- wall socket
    b) small hum loop, low hum voltage.
        | ___________COMPUTER.
        | |
        O O <- wall socket

    keep in mind that the hum current flows both through audio cable shields and power cable ground wires ! moreover, different earthing points will always have slightly different potentials, so there will always be a little current flowing to and fro, again causing hum. (don't believe anyone who claims to have the definite 0 volts. they lie.) so keep the audio lines close to the power cables, and use a single mains socket for the entire studio (if not, your hum loop may easily be as big as the entire house. great for searching alien signals from outer space, very bad for sound recording :).

    this will greatly reduce most hum problems at no extra cost, while avoiding the sound impairment that usually comes with cheap trafos. on the other hand, there will be a little amount of capacitive and inductive coupling between the cables that might again introduce hum. should be a lot less, anyway. works for me."

    PW interjects: The inductive-coupling hum caused by running the power & audio cables close together is known to cause problems with long cables. Live sound engineers keep their cables well away from power lines whenever possible, but then they are running cables 100 meters or longer. They avoid big ground-loop problems by using only balanced cables and leaving one end of each shield (usually pin3) wire disconnected so there's no loop.

    generally, the moment an audio circuit is earthed twice, you'll have hum. with asymmetrical wiring in home studios, there are two options: separate the circuits with transformers, or move the earthing points close together and keep power and signal cables together."

    Another solution is the big-ground-wire-between-everything strategy mentioned above. And as Hans ? points out, sometimes the induced noise from having audio and power connectors so close together might be a real problem:

    "(In theatre), The power cables often include lighting and in a theatre the lighting is regulated through pulse width modulation ... This causes huge spikes on your power, which is disastrous on any audio cable running along them.

    I also wouldn't advice running your audio and power cables next to each other in a home setup. A halogen lamp which can be trimmed down often causes spikes on your power too."

So, there is no single, perfect, easy solution; it may take some work to kill the hum.

Garbled Playback

James Helferty wrote in to say that he was having a problem with garbled sounds:

I'm using a SB128 (ensoniq 1370) and a MVP3-based motherboard...

Quickly, the problem I was experiencing was an audio... rotation of the audio buffer, as part of the audio is played, and then replaced in mid-play, which causes the audio to sound all distorted and messed. The problem gets worse as you continue playing a long file.

Why this happens is a simple matter of bad BIOS design; the BIOSes on these boards, by default, give the CPU a higher priority on the ??memory?? bus, which means that the other devices (ie; PCI devices) are essentially starved of their share of time. Normally this isn't a problem with other PCI cards, but whenever you're using a sound card, it's really obvious. The reason the BIOSes were designed this way was because it gave a 0.04% speed increase in an obscure benchmark under Windows...

(Btw, I should point out that this non-technical explanation is actually third-hand information; I heard it from someone who replied to a post on Slashdot, who says he read it from a mailing list for the kernel. So I can't guarantee that it's an accurate explanation. :)

Anyways, the solution is actually quite simple; just go into your BIOS and disable something called "PCI Delay Transaction." Everything's fixed, problem goes away, everyone's happy. I still have a little static, but I can live with it...


The Multiple Soundcard Myth

Many people attempt to get more than two simultaneous inputs or outputs by putting more than one cheap soundcard in their system. I suppose this can be made to work, but I've yet to hear from anyone who's really pulled it off without big problems. The trouble is that each soundcard derives its sampling rate from a crystal oscillator clock. The clocks in the two soundcards will inevitably not be synchronized. You might think that 44,100 Hz is always exactly 44,100 Hz, but sadly, it's not. Your software doesn't know this - it thinks 44,100 samples from one card represents the same amount of time as 44,100 samples from the other. As a result, the sound from one soundcard will gradually lag farther and farther behind the sound from the other soundcard. If there's any sound common to both cards, you may even get weird phasing effects.

There are only three possible remedies:

  1. Use a true multichannel soundcard. See below for information on cards that work with Linux.

  2. Use cards that can be sync'ed to an external clock, and drive one card with the other card's clock. I do not know what (if any) cards that support synchronization work with any of the linux drivers. There is an interesting card in development that has this feature. It has a website here.

  3. Compensate for the discrepancy in software. I don't know of any existing linux software that does this, nor do I know how it could be done. The topic does occasionally come up on the linux-audio-dev mailing list.

If anyone has successfully implemented either of these last two strategies on a linux box, please write me at

System Lockups

If you ever experience a full system lockup while attempting to do full-duplex recording, it is likely that you have a buggy mainboard. Some Intel boards lock up if they receive a certain pair of instructions very close together, and apparently this only happens if you record and play at the same time. This bug can be worked around in the soundcard driver. The OSS-Linux driver has implemented a workaround for some Intel mainboards; download a demo of the driver and see if it fixes your lockups. (Worked for me.) I do not know whether this workaround has been or will be implemented in ALSA or in the OSS-Free drivers.


You will want to make sure that your system doesn't screw up the data once it comes in from the soundcard.... or on the way back out to the soundcard!

We've all experienced these dropouts: the sound is going along fine, then suddenly there's an instant of silence, then it comes back. The sound cuts on and off... yuck.


The good news:

Linux is now (with a patched 2.2 kernel) capable of totally reliable, rock-solid audio performance with NO dropouts and VERY low latency, even better than BeOS which was specifically designed for multimedia!

The bad news:

The patches were once hoped to become part of the linux-2.4 source tree, but that now seems very unlikely. So at least until 2.5 / 2.6, you must patch and recompile your kernel. And there are a few other things you need to pay attention to.

Benno Senoner is heavily involved in this project and has written a Low-latency Mini HOWTO which is useful for application authors.

Here's Benno's summary:

  • Run a low-latency enabled kernel. [Editor's note: Formerly the only way to do this was to get the sources for kernel 2.2.10 and apply the N6B patch and compile it yourself. Benno and Udo Jocher have now prepared an RPM of a patched 2.2.16 kernel which should install cleanly on RedHat systems. I have also written a mini-howto on using Andrew Morton's patches to the 2.4.0-test kernel series. Andrew's patches are less effective than Ingo's, but also much cleaner.]

    (meanwhile see my audio page for infos and read the latencytest README carefully)

  • If you have IDE disks they MUST run with DMA enabled
    (editor's note: the Linux UDMA Mini-HOWTO may help with setting dma mode for drives... worked for me!)

  • Your realtime app must be designed in a such way that the audio thread does ONLY audio I/O ... any other syscall is FORBIDDEN ! , no disk I/O inside the audio thread, no GTK / X11 calls etc. you may use msgsnd() / msgget() in order to exchange data with the GUI thread. I would avoid the use of FIFOs pipe() , because the GUI thread could stall and if the fifo gets full, the audio thread could block = dropout assured.

  • ONLY the audio I/O thread and if you do MIDI , the MIDI thread too, MUST run SCHED_FIFO... without SCHED_FIFO you will not get reliable low-latency.

  • all other threads should run with normal scheduling policy so that if the audio/midi thread needs the CPU, it will get the processing power even if you do heavy disk I/O or heavy CPU work in the background.

  • disable apm (boot your kernel with apm=off) , on some of my machines APM ruins the latencies, during apm polling.

  • take care when working with mutexes, design the audio realtime thread in a such way that it will never "wait" on events, use shared memory and poll flags/messages at each iteration within the audio-loop. (or alternatively use non-blocking message queues msgsnd(), msgrvc() )

If you meet ALL these conditions, you will get a rock-solid realtime behavior, where a Windoze user can only dream of.

...hope this helps,


OK. IF you can do all that, the rest of this section is mostly obsolete. Note that there are probably very few, if any, current-generation audio apps for linux that can meet these criteria. But this has been a hot topic on linux-audio-dev, so many applications now in development should soon be low-latency-compatible.

For currently existing and legacy applications, there may be some other useful tips below. These can help but will never be as reliable as using low-latency-enabled applications and linux kernel.

While recording, you can reduce the likelihood of dropouts or other glitches by reducing system activity. If you're having problems with dropouts, especially when recording for several minutes or more, here's some things you can try. Many thanks to Ralf Schlatterbeck, Michael Stutz, Michael Brown, and Jim Jackson for contributing heavily to this section.


Anytime you're doing realtime interactive work (e.g. software synthesis or realtime processing), you need to have quick response to your actions. "Latency" is a term for the time between when you do something and when you get the result. In digital audio, it often refers to the delay between when you feed a signal into your soundcard and when you get the (presumably modified) signal out again.

PLEASE NOTE: The best thing you can do to reduce latency is follow the guidelines given above in the section on dropouts. If you can set your system up that way, you should have very good performance. Otherwise, keep reading; some of these "obsolete" tips may help.

I can't say this strongly enough: your best bet is to follow the new guidelines in the dropouts section above. Eric S. Teidemann explained the importance of this on the Linux Audio Developers mailing list:

Erik de Castro Lopo discourseth:
> Has anybody made a comparision of the performance of a standard process
> vs a realtime process (ie using sched_setscheduler) vs rt-linux vs
> linux kernel with patches?

I've done all of that..with various kernel versions and patches except rtlinux. You can pretty much count on occasional dropouts > 50ms on stock linux. pre-2.2.8 is even worse. Using linux 2.2.10 and the latest (non-public) patches this comes down to 3ms..and at that point it starts to become processor rather than disk dependent so I should say that that's on my amd k6-2/350.

rtlinux apparently can provide sample-level latency even while a stock linux is doing wacky things (I have no reason to doubt David Olofson on this). However, rtlinux has a completely different development architecutre than POSIX (some commonality is emerging due to David's efforts, but differences will remain)*. Also, as soon as a single element of control goes through standard linux then control latency is at the mercy of standard linux even if data latency is maintained by rtlinux.

--Eric S. Teidemann

David Olofson jumped in and commented on the preceding paragraph:

"Just two notes on RTLinux and POSIX:

1) The new API is based on the "Minimal Realtime System Profile", which means it has the open/read/write/... calls, but just basic device I/O rather than full file system support. That's not "completely different from posix", as stated by Eric S. Teidemann. (See example below from my DPI package. Note that the kernel module specific stuff could be replaced with some nice stdio style wrapper if desired.)

2) The Driver Programming Interface I'm working on ... is using the same API as the standard RTLinux distro. It affects only drivers - not applications. The POSIX I/O layer is already there..."

David also provided "Some RTLinux 'application' code: (Beta, of course, and not very well tested... It runs rock solid with 'buffer=32 prewrite=4 fragshift=5' here. :-)", which I've placed here.

OK. So if you've read the above and you have a low-latency-patched kernel and some realtime-enabled applications, you're all set. You can stop reading this section now. Still here? OK, the rest of this section assumes you're still stuck fiddling around trying to find ad-hoc, workable compromises. You need to know that some of the "obsolete" strategies for preventing dropouts given in the dropout section above will actually increase latency, making your system feel more sluggish, so you need to find a workable compromise.

Jim Jackson provided some tips on reducing latency, and Benno Senoner then provided some counter-arguments and commentary. It all seems to depend what kernel version you're running - Benno heavily advocates using the low-latency patches described above, while Jim's comments are mostly helpful for older kernels. On with the dialogue...


Recording Audio CDs

This is (currently) beyond the scope of this document, mainly because I just got my CD burner and haven't made any audio CDs yet. :)

For information on cd recording, read The CD-Writing HOWTO from the Linux Documentation Project.

"Ripping" and Playing Audio

You may notice that playing audio CDs doesn't sound as good on your PC CD-ROM drive as on a high-quality CD player, even if you use the same amp, speakers, etc. The reason is simple: Most soundcards only have an analog input for CD audio. This means that the digital data from the CD is converted to analog by the CD drive's DAC, then runs through a tiny, cheap wire inside your computer case (a great place to send analog signals...), to your soundcard, where one of two things happen. Either the signal runs through your soundcard's analog mixer (which probably sucks) and is sent directly to the output jack, or if you're REALLY unlucky (for instance the SoundBlaster Live does this), the analog signal actually gets converted back to digital by the soundcard, then goes through the card's digital mixer, then out through the soundcard's DAC. That's two completely unnecessary conversions between analog and digital, and that spells "yuck".

It would be preferable if we could avoid all that. We can, by "ripping" the audio data off the CD and sending it to the soundcard's digital-to-analog converters. In many cases this is a big improvement. Techniques for doing this are described below, but first, David Balazic warns:

"There are big problems with [ripping the audio data off the CD]. Because CD-DA have less error correction data and very basic positioning data, the reading by computer is very error prone. Sometimes the drive doesn't return exactly the sector requested ( they say this happens sometimes even with very good drives , like Plextor ). And sometimes when there is a read error the drive just returns some random ( or zeroed ) data , without bothering to say 'hey, I couldn't read this sector', it just report as everything OK."

Sanjay Rao writes of one solution: Use cdparanoia.

"The point: One can copy an audio CD to a hard disk or data CD then play it back through an SPDIF output to a DAC and get cheap high quality CD audio (or at least relatively high) for cheap. It takes minimal CPU. The quality of cdparanoia's copy is significantly higher than a mass market cd transport, and given that one already has the hardware, at least $300 cheaper."

Even if you don't have digital outs, you can still use the same procedure to play through your soundcard's line outs, which eliminates the first DAC and ADC from the signal chain. That should be a big improvement.

Andy Lo A Foe has a more convenient solution: his AlsaPlayer, among other things,

"...supports CDDA playback of an audio CD through the DAC of the soundcard. It works very well on CD... Of course it does this in real-time with very little CPU overhead and without the need of copying the data to disk first. There is an added benefit of being able to visualize and/or modify the data before it's send off to the soundcard..."

Benno Senoner points out that the low-latency patches described in the section on latency can also make CD ripping more reliable:

After running the cdda2wav as a regular user , so that it could not acquire SCHED_FIFO (realtime priority) privileges, running low-latency software (for example a realtime FX processor) while ripping CDs at 24x speed worked perfectly. Again I was able to get 2.1ms latency.

That means we would be able to run our DJ mixing software with RT effects etc, while in background we rip CDs at maximum speed. (and maybe even compressing them using an mp3 encoder). Try to perform all this tasks simultaneously on windoze. :-)


Changing a soundfile to a different sample rate or bit depth while maintaining maximum quality is not necessarily easy.

The general principles have nothing to do with Linux specifically, and can be found elsewhere on the 'net, so I'll summarize:

  1. Keep the bit depth as high as possible for as long as possible in your processing chain. If you're going to end up with the usual 16-bit integers, use more resolution than that for everything up to the very end; long ints, floats, doubles, whatever. This strategy will reduce re-quantization noise.

  2. When you do eventually go to a lower bit depth (e.g. converting 16-bit to 8-bit), consider adding dither. Dither is a very small amount of random noise that masks uglier quantization noise and, oddly enough, improves the perceived resolution (so you can actually hear stuff happening below the lowest bit, like reverb tails). Doing (Sox can now do some kind of dithering with its mask effect; please note that I have not really tested it and have no idea how good it is. Anyone?)

  3. Stick to sampling rates that are integer multiples of the rate you want to end up with. For example, don't sample at 48 kHz of 96 kHz if you're going to end up at 44.1 kHz; just work at 44.1 or consider going up to 88.2 kHz ... unless you trust the tool you use for sample rate conversion to do a really really good job. While the higher sample rate gives you more treble to work, and gives you some headroom against aliasing if you're doing digital synthesis, the problem is that if you have to downsample to your final product by a non-integer amount, there will be lots of interpolation and filtering of some kind going on, and some people say that's worse than just starting with the final sample rate. Your mileage may vary.

    Another situation in which people like using 48 kHz is when the signal will go through some analog processing (such as mastering with expensive tweaked-out vintage compressors or some such) before the final 44.1 kHz product, in which case digital resampling is not an issue and some people think that initially working at 48 kHz is a bit better than 44.1.

  4. To avoid aliasing, filter out everything above the Nyquist frequency before downsampling (or make sure your resampling tool does this for you). The Nyquist frequency is 1/2 the sampling rate you want to end up with. For instance, before converting 44.1k to 22.05k, filter out everything above 11.025k.

  5. Don't normalize all the time! If you need a normalized signal, normalize once AFTER you've done everything else, just before converting to the final output bit depth. (That's assuming your signal is floating-point up until the very end; if your signal must become an integer at some point, you may need to tweak levels to get the most resolution from the integer samples.) This strategy will help reduce unnecessary re-quantization noise.

One place to get more information is the FAQ at
Another great source of information on digital audio, with articles on many topics including normalization and dithering, is the Digital Domain site at Most of the information in this section was cribbed from those sources.

The ubiquitous tool for these jobs on Unix systems is SoX.

SoX is at: SoX works, but you need a recent version. Early versions of SoX had a reputation for poor sample-rate conversion. This has been addressed. Also, there are now alternatives to SoX - see Joachim Thiemann's note about AFsp below.

As of now (September 2000), SoX version 12.17 supports three methods of sample rate conversion. It's important to use the right one.

Synopsis (as of SoX 12.16 - I haven't checked out 12.17 yet):
linear is fastest, and worst sounding (lots of aliasing).
resample is probably best-sounding. Old bugs in resample seem to have been removed in version 12.16 and further improvements were made in 12.17.
polyphase is slowest, and not generally as accurate as resample, but has been improved in version 12.17.

Sox now also provides simple 1/2 bit dithering via the mask effect. Noise-shaped dithering is not currently an option. (To learn more than you ever wanted to know about dither, do a dejanews search for dither in

Joachim Thiemann <> wrote to complain that SoX did not handle some soundcard sampling rates well because the soundcard gives a sampling rate that is several percent off from the requested rate and SoX would resample it poorly. Chris Bagwell, maintainer of SoX, reports that this has been fixed in SoX 12.17 (September 2000) so all SoX users should upgrade!

Anyway, here's Joachim's original complaint (from 1999) and his own solution:

"...The solution to the problem is to either resample the file to a "nice" division of 44.1kHz, like 22050Hz or 11025Hz, or to simply play the 8kHz file at 8018Hz rate - the <0.225% difference in playback speed is not perceptible. For the latter solution I had to write my own replacement for "play" (<100 lines of C)."

" --- The following is a blatant plug for our own software :-)
We here at the McGill signal processing lab have our own Audio processing code - see - which allowed me to write the above replacement for "play" in so little code. Also, the ResampAudio utility (part of the AFsp package) does a _much_ better job at resampling than Sox does (and we can prove it, too! ;-)"


Brian ?? wrote to point out some tools useful for cleaning up noisy soundfiles. Generally speaking, this will never produce results as good as starting with a clean soundfile, but sometimes you have no choice.

denoi and dnr may be found at: Says Brian, "These routines ... take a sample of noise from the beginning of the recording and filter it out from the rest of the recording." I've found them both useful, though it takes some playing with parameters. Also of interest is gramofile, available at Brian writes that "Gramofile is a program to remove clicks and pops from LP recordings. It can handle huge files and split them up into separate tracks. It doesn't do denoising, but it does have some other filters."


Jim Jackson writes,
"I'd recommend that people always check the output of their soundcards by at least digitally generating clean signals and playing them into an oscilloscope or signal analyser. The siggen suite contains tools for generating various waveforms for test purposes."

siggen is at:

"Check mono, each stereo channel seperately (i.e. other channel playing silence) and each channel playing different waveforms and freqencies. You may be surprized at the amount of variation in performance signal cleanliness. You may be stuck with the card but at least you will be aware of its limitations!"

Note that, in theory, you could generate some signals internally with siggen, output them, connect the output to the input and re-record it, then analyze the results (or do it in realtime). At least that's the theory. I don't know what tools exist for meaningful analysis in Linux; there are various scopes and things but I haven't tried them. Also note that with this method, you'll be seeing the combined effects of your ADCs and DACs.


Try a dejanews search of linux newsgroups for the card you're thinking of buying. Check if it's supported by the kernel drivers (free), ALSA (free), or OSS/Linux (not free).


What Cards Sound Good?

See if there's a performance test for the cards you're considering at this site:

You'll notice that some cards have the potential to get as much as 10 or 20 dB better noise performance than others, and for not much more (or even for less). For instance, the Ensoniq AudioPCI, aka SoudBlaster PCI has great specs and retails for $50 or so, and is now supported by ALSA and OSS/Linux. Disclaimer: I have not used the Audio PCI, I've just heard many reports that it's good. For instance, Brian ?? writes that it " very well with the ALSA drivers. However, the drivers that came with RH5.2 were not so good (by the author's own account)..."

Brian also points out that there is some confusion about what, exactly, IS an Ensoniq Audio PCI, in the wake of Creative Labs purchasing Ensoniq. Specifically,

"...note that there is a difference between the original Ensoniq AudioPCI (1370) and the Soundblaster Ensoniq AudioPCI (1371). I don't believe that the original Ensoniq is sold retail anymore. It's certainly much less common than the 1371. Yet, a few months ago, I was able to find an OEM Ensoniq AudioPCI 1370 on the web for $20. The results on the PCAVTech site you referenced (see above. --PW) indicate that it's worthwile taking the time to get the 1370 instead of the 1371. In addition, the SB 64 / 128 also seem to have the 1370 chipset, so those might be another option."

Dave Phillips reports on the SoundBlaster AWE64 Value:

"I recently acquired a SoundBlaster AWE64 (Value) and am using the OSS/Linux driver for it. Performance is excellent, with complete activation of the internal EMU8000 synth and the external MIDI port ... after much trial & error I found that this command sequence is necessary to get full-duplex Csound using the AWE64:"

csound -i devaudio -o /dev/dspW -b 64 in_foo.*

"...and the output gain needs to be turned *down*, else the distortion is ear-splitting. Note too the buffer size."

"Regarding audio quality: this card will present an output gain to the mixer, and bringing down that gain will significantly reduce hiss in the output. Other than that, sound quality is quite good, much better than my generic CS4232 card."

Caveat: As far as I can tell from the soundcard test page listed above, the SB64 (both Value and Gold) suffers from poor full-duplex performance; I think the card may, like earlier SoundBlaster cards, only be able to output eight-bit samples when used in full duplex mode, resulting in about a 50 dB signal-to-noise ratio. Blah.

Personally, I am currently using a Turtle Beach Malibu. The line in and out seems pretty good, a vast improvement over my old SoundBlaster 16; also, the Kurzweil wavetable synth, with a pretty decent 2MB patch set, works fine. The card is based on a CS4237B and is well-supported by both OSS/Linux and ALSA. At first I had noise problems due to the built-in SRS "3D audio"; see the section on reducing noise to fix this.


If you really need a super-quiet audio path, you'll have to spend more money and get the A/D-D/A converters out of that damned computer case. Get a card with digital inputs and outputs and connect it to external converters. Or get a card with its converters in a "breakout box". Unfortunately, I do not know of any linux driver support for this class of devices at this time.

This section is far from complete. I do not have the time to stay up-to-date with pro and semipro cards in the market and which ones do or do not have linux drivers of some kind. I rely entirely on information sent to me by other people. If you know of a pro or semi-pro card not listed here that works with linux, please tell me everything you know about it!!

Please note that I have included rough prices for these soundcards, when I have some information. But I make no guarantees as to accuracy!

A Note on USB Sound Devices:

Most Universal Serial Bus sound devices such as those made by Opcode are not supported at this time. BUT there are now a few speakers that plug directly in to the USB port that are now supported by the Linux USB project. That site is probably the best place to watch for new developments in USB audio support. Hopefully more devices will be supported in the near future.
Now for the soundcard categories...


This page is maintained by Paul M. Winkler, <>. I'm 29, a self-taught geek for 3 years, and I play in a band called ARMS. It's a unique blend of punk, pop, soul, and hip-hop. We have two albums out. Check out mp3s of our music at our homepage or at You can read blahblah about me here but I don't recommend it.

Other Contributors:

In an attempt to foil spam-bots, email addresses below have been mangled in a way that should be decipherable to humans.
Benno Senoner <sbenno&gardena:net>
Michael Stutz <stutz&dsl:org>
Jim Jackson <jj&scs:leeds:ac:uk>
Sanjay Rao <srao&uswest:net>
Michael Brown <mjb&pootle:demon:co:uk>
Dave Phillips <dlphilp&bright:net>
Brian <bmeloon1&twcny:rr:com>
Andy Lo A Foe <andy&alsa-project:org>
Forrest Cook <cook&atd:ucar:edu>
Chingson Chen <chingxyz&ms4:hinet:net>
Alex Dolski <nohbdy&seductive:com>
Juergen Kahrs <jkahrs&castor:atlas:de>
Ralf Schlatterbeck <ralf&zoo:priv:at>
Gerd Rausch <Gerd:Rausch&ericsson:com>
Chris Green <sprout&dok:org>
Joachim Thiemann <joachim&tsp:ece:mcgill:ca>
Benjamin GOLINVAUX <golinvaux&benjamin:net>
Thomas Sailer <sailer&ife:ee:ethz:ch>
Jorn Nettingsmeier <nettings&folkwang:uni-essen:de>
Eric S. Teidemann <est&hyperreal:org >
Jaroslav Kysela
Peter Wahl <uzsa69&uni-bonn:de>
Anonymous Tim <address-withheld-on-request>
Pix <pix&camtech:net:au>
James Helferty <jhelfert&chat:carleton:ca>
David Balazic <david:balazic&uni-mb:si>

Copyright (c) 1999 by Paul M. Winkler. This document may be distributed under the terms set forth in the LDP license at

This HOWTO is free documentation; you can redistribute it and/or modify it under the terms of the LDP license. This document is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the LDP license for more details.

Send comments, contributions, corrections to Paul Winkler:

SlinkP's main Linux page
SlinkP's Home Page
Nedstat statistics