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.
If you have any tips or recommendations that would be appropriate here, please send them to me at slinkp@angelfire.com. 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... | |
DisclaimerInformation 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. |
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.
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...
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):
append=no-hlt
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.
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)."
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.
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).
If your noise seems to be related to video movement, read the section on video cards.
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."
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...."
Having problems with AC line hum? See the separate section on that below.
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.
Try heavier, better shielded cables.
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.
Try to keep drive cables as far from the soundcard as possible. This may not be an option.
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."
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.
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.
"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 :) "
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 http://www.zefiro.com/vgakills.txt
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 comp.sys.ibm.pc.soundcard.tech 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.
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").
If you have tried everything above and you still have too much noise, it may be that you have a low-quality soundcard, or you may have an excessively noisy system. It should be emphasized that the exact same soundcard can make very different noise in a different system. In fact, the impetus for starting this HOWTO was the terrible experience of transplanting a previously well-behaved soundcard into a new system and finding a drastically increased noise floor in the soundcard output.
Try to find out if other people report bad noise problems with the same soundcard. See below for a web site that shows extensive test results of various cards. If your card is known to be a noisy one, you will most likely have to get a different soundcard. If you already have a card that has a reputation for low noise, you may be really SOL ... you may have to replace your case, or motherboard, or power supply, or everything.
It may also be that you are just very sensitive to low levels of noise, in which your best bet may be to fork out the big bucks.
This section is mostly not Linux-specific; in fact it's not even computer-specific, but pertains to getting good quality audio in general.
First, it's important that the soundcard gets the highest quality incoming signal you can feed it.
Use good-quality, well-shielded cables.
Keep all jacks and plugs clean. Corrosion and gunk kills some of the high end, and in severe cases causes noticeable intermodulation distortion (which can sound really, really bad). Gold-plated connectors may conduct better and be less prone to corrosion.
It's annoying connecting the rest of your gear to those dumb little stereo 1/8-inch jacks, but try to avoid using lots of adapters. When they're clean and well-seated, there should be no problem. But adapters can work loose, get dirty and corroded, thus degrading your signal before it even gets into the computer. If you know how to solder your own connectors (and it's a good skill to acquire), try buying some shielded cable and plugs and making cables that connect your gear directly without a bunch of adapters.
When recording microphone signals, an external mic preamp (even a cheap one like you find in a consumer tape deck or a cheap 4-track) is likely to sound better (less hiss and distortion, better frequency response) than the mic input on your soundcard. Connect the preamp to the "line" input on your soundcard. Obviously, use the best microphone and the best preamp you can find (probably in that order).
Chingson Chen points out that, if you DO use the soundcard's mic input, make sure to use the correct type of microphone:
"Today, most soundcard support Electret microphones only, because they are small and convenient. But some older or special cards support Dynamic microphones."
Personally I have my doubts about this: you really don't need to do anything special to "support" a dynamic mic. If in doubt, check the documentation that came with your soundcard. Or better yet, use the line inputs and an external preamp.
Jorn Nettingsmeier has a lot to say about this important topic. You can find more about these issues in rec.audio.pro, 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."
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 rec.audio.pro FAQ. The section on audio interconnections explains ground loops and various strategies for fixing them.
There are two basic strategies recommended by the pros:
Use only balanced (3-wire) connections, with all shield wires disconnected at one end to avoid spurious signals travelling through the shield. This will usually give better results but it's expensive and sooner or later you need to connect to some unbalanced device, like your computer soundcard.
Since you will probably end up using some unbalanced (2-wire) connections, try connecting the chassis (metal case) of ALL your equipment together with some big copper braid or other very-low-resistance wire. The theory here is that this provides a path of least resistance for spurious signals travelling through ground wires, so they stay out of the audio signal cables. It may also help, once you've done this, to disconnect each cable's shield at one end.
There are other techniques suggested by readers; here are some.
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).
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):"
transformer
---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."
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.
diagrams: a) large hum loop, high hum voltage. _____________MIXER.......... | . | <- power cord . <- audio cable | . | . | . | . | ___________COMPUTER....... | | O O <- wall socket b) small hum loop, low hum voltage. _____________MIXER. |.................. |. |. |. |. |..................... | ___________COMPUTER. | | O O <- wall socketkeep 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.
"summary:
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.
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...
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:
Use a true multichannel soundcard. See below for information on cards that work with Linux.
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.
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 slinkp@angelfire.com.
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.
MUST READ!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:
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, Benno. |
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.
The driver you're using may have some options that could help. For instance, the OSS-Free kernel driver has a dma buffersize compile-time option. This should be set as high as it can go. If you're still having problems, it's time to look at what else is running on your system. You may be able to trim a lot of fat.
Close unused xterms and other applications.
Don't run X if you can avoid it.
Try using a command-line recorder like ecasound or ALSA's arecord or the Sox rec script, to avoid the overhead of running a graphical sound editor.
Improve the scheduling priority for the command you're running by using nice as root. Set a low, possibly negative, number.
Try (as root) killing unneeded getty's.
Kill off syslogd. Whenever it logs a message it syncs the disks. This "...can be a real pig on a low end machine." Or edit the syslog.conf to omit synchronizing by prefixing the filename(s) with a '-'.
Kill sendmail.
Kill crond.
You could even go so far as to reboot in single-user mode. Yikes.
Don't bother with RT-Linux at http://luz.cs.nmt.edu/~rtlinux. RT-Linux can theoretically provide extremely reliable low-latency performance, but not without a LOT of work: apparently you need special RTLinux-compatible device drivers, which probably don't exist for your soundcard, and there are rigorous restrictions on how the applications can be coded, so this is really only a theoretical solution. But if you're a real wizard and your really need the absolute best possible realtime performance, it might be worth spending some months (years?) of your life going in this direction.
Try the "scheduler bigpatch" by Rik Reil at http://humbolt.geo.uu.nl/~riel/patches/. This is now rather old and I don't know anything about it; I think it may be unnecessary with later 2.2 kernels?
Alex Dolski solved his Vibra 16's dropout problems by reading the...
"readme file called 'VIBRA16' in Documentation/sound of the Linux kernel sources ... which seemed to explain the problem I was having. It says that the card (or the driver for the card) for some reason supports two 8-bit DMAs but no 16-bit DMA, but the second 8-bit DMA must be passed as a 16-bit DMA to make the sb.o module happy. However, I find that with no 16-bit DMA channel, sound becomes very distorted during periods of hard disk activity...."
"The solution I found was to issue the command hdparm -d 0 /dev/hda to turn that hard disk DMA off. Once I did this, everything sounded fine, but there was a definite reduced CPU efficiency of disk transfers."
"I probably wouldn't have brought this up if the VIBRA16 readme didn't say that this problem is experienced by 'almost all soundcards.'"
If you get dropouts while recording on a system with an older CPU (like, say, a 486), Ralf Schlatterbeck suggests that
"...Your recording program does not consume data with the rate it is procuced by the sound card. This results in audible clicks and you will see the following entries in syslog:
Apr 26 14:46:17 cat kernel: Sound: Recording overrun
You can solve these problems (assuming your hardware is capable of a sustained data rate you need) by using software that has a low overhead when recording. I have very good results with gramofile cardit.et.tudelft.nl/~card06/ and bplay (available from sunsite, also included in the debian distribution). The bplay program has the additional advantage that you can set up recording using 'at' or 'cron' to record from radio..."
Another possible problem suggested by Ralf Schlatterbeck:
"You are using several DMA devices (one of them being the soundcard). You will NOT see the overrun message above, but the effect is very similar. I got several very audible clicks every 5 seconds or so.... The clicks turned out to be correlated with the "sync" when Linux writes out the accumulated sound data to disk. Note that due to buffering you might not see this effect until after a minute or so. I solved the problem by experimenting with Linux' buffer settings in /proc/sys/vm/bdflush This is a special file that controls when and how Linux writes accumulated data to disk. The file is writeable by root and you can simply echo the new parameters to this file. The original settings that caused the problems were 60 500 64 256 15 3000 500 1884 2 and the parameters that solve the problems above (for me) are 0 50 40 256 15 3000 500 1884 2
This effectively tells Linux to try to keep the buffered data to zero, but not to write too much data in one blow. So the two DMAs (of disk and audio card) do no harm to each other. Note that this setting tunes Linux just for audio recording and the system will not behave very well when confronted with other tasks!"
Ralf Schlatterbeck writes,
"The sound driver is using dynamically allocated kernel memory and you don't get enough buffer space for the DMA buffers. This problem may result in clicks and other strange sound-effects....
"Typically the sound driver coming with the linux kernel ... has a setting how much buffer space it should allocate. The space, however, is dynamically allocated when opening the sound device.
On a long running system, the kernel tends to allocate all the free memory to buffer space (used for disk I/O buffers), and the in-kernel memory allocation the sound driver uses does not seem to allocate this space.
If no space could be allocated you will get a message from the kernel and the recording program will get an error. If, however, some space could be allocated, but not the full buffer space that was compiled into the driver, most recording program will silently use the low memory for the DMA buffer. Since most sound recording programs do not check how much memory was actually allocated, results of recordings may not be what you expect and the results are often non-reproduceable.
A sound-recording program should have an option to display the amount of memory allocated for DMA buffers, the code is something like:struct audio_buf_info info; if (ioctl(audio, getspace, &info) < 0) { /* error message and/or exit */ } -- pr fprintf ( stderr , "Allocated %d fragments of size %d\n" , info.fragstotal , info.fragsize );A work-around for this bug (probably already fixed in later kernels ?) is to explicitly free the buffer space by allocating a large amount of user-memory, I call the following code before recording audio to reset the buffer cache (This is for my 32MB 486, you may or may not want to increase the amount of allocated memory on a larger machine -- try it out):#include <stdlib.h> main() { char *p = malloc(1024 * 1024 * 32); int i; for (i=0; i<1024 * 32; i++) { p[i*1024] = 0; } }
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: David Olofson jumped in and commented on the preceding paragraph: "Just two notes on RTLinux and POSIX: 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...
NOTE: There was formerly a comment here from Jim Jackson
to the effect of "In the kernel sources, change DEF_PRIORITY..."
Benno replied that this was a bad idea, and Jim later wrote back
and agreed that it was probably not good. So don't do it unless you
really know a lot more than either of them. :)
Jackson: "With IDE disks, make sure you use the hdparm utility to set -u1 which runs the bottom half IDE processing with other interrupts enabled. This processing can be time consuming. ... The manual hands out dire warnings about use of some parameters, but AFAIK the only potential problems are with some very old IDE controllers/chipsets. Alan Cox claims to actually know of a problem (corruption) being caused by the use of hdparm -u1 but this was several years ago and was old hardware then."
(See man hdparm for details on other flags for tuning disk performance.)
Jackson: "Don't run top or similar, which make extensive use of the /proc file system."
Senoner: "true: on regular kernels heavy /proc filesystem access causes up to 20-30ms latencies. on [kernel] 2.2.10-lowlatency-N6, no latency problems."
Jackson: "In linux/include/asm/param.h change HZ up from the #DEFINE HZ 100 line (and then rebuild the kernel)... This can reduce latency, but increases CPU overhead - more scheduling per second... HZ is the 'jiffies' value, the basic interval used by the scheduler. It is 100 on Intel platforms, but... As it is at 1024 by default on Alpha Linux then I suspect there is no serious probs setting it to that on a modern-ish Intel box."
Senoner:"increasing HZ is almost useless, except you need a more finegrained usleep() (down to 2ms), but it doesn't help to lower the latency peaks during heavy disk I/O , /proc etc, since when this happens the kernel doesn't reschedule our audio processes."
Senoner:
"increasing HZ to 1000 drops the overall performance by a few % (not much on a PII), but in some cases there is an advantage: for example the SB AWE64 MIDI out FIFO doesn't have an IRQ, therefore you must use busywaiting or high frequency polling, and in fact with the default HZ=100 you get up to 10ms MIDI-out latency which is bad , (but consider this MIDI hardware is crap, as Jaroslav and Paul Barton-Davis pointed out). Increasing HZ to 1000 you don't get the full MIDI bandwidth but come close to 60-70% ( 2000 bytes/sec vs 3125 bytes/sec from the MIDI port), plus the MIDI out latency will go down to about 2ms when setting HZ=1000.
As Paul Barton-Davis discovered even on a HZ=100 box using decent MIDI interfaces (for example audiopci or trident), you can get close to the HW limits, 1.1ms on his trident."
For information on cd recording, read The CD-Writing HOWTO from the Linux Documentation Project.
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:
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.
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?)
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.
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.
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 rec.audio.pro FAQ at
http://www.cs.ruu.nl/wais/html/na-dir/AudioFAQ/pro-audio-faq.html.
Another great source of information on digital audio, with
articles on many topics including normalization and dithering, is the
Digital Domain site at www.digido.com/. 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: http://home.sprynet.com/~cbagwell/sox.html 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 rec.audio.pro.)
Joachim Thiemann <joachim_AT_tspece.mcgill.ca> 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 http://www.tsp.ece.mcgill.ca/software/index.html - 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: http://www.sci.fi/~mjkoskin/. 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 cardit.et.tudelft.nl/~card06/. 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."
"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: ftp://ftp.scs.leeds.ac.uk/pub/linux/apps/siggen.tgz
"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).
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 "...works 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.
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!
This section lists only two-channel cards which might be used for example to do digital transfers from / to DAT tapes. You may also want to see the section below on multi-channel cards, some of which also have digital ins and outs.
Hoontech Soundtrack has the hardware, and apparently now has fully functional linux drivers! See this page for drivers. Thanks to Gerd Rausch for pointing this out. See also www.anime.net/~goemon/soundtrack128/
Warning: the Hoontech 4Dwave, a.k.a. Trident 4DWave has been moved to the "problematic" section below, for much the same reasons as the SBLive.
Guillemot Home Studio 64 has digital ins and outs. It has some small degree of support from OSS-Linux, but apparently is well-supported by the SAM-9497 drivers mentioned above. Thanks to Gerd Rausch for the tip.
Turtle Beach Pinnacle and Fiji: S/PDIF input and output. A driver is here. (I think this driver comes with the kernel sources?). Prices $200-$300 or so.
Turtle Beach Malibu (and possibly other cards with CS-4237B codec): S/PDIF output only. ALSA supported. Price around $80 US.
Creative SoundBlaster AWE-64 Gold: supported by OSS-Linux, has digital output only. Price around US $150?
Zefiro ZA-2: Aaron Crane reports the following info about the ZA2:
In summary, even though it looks like a fairly impressive card, I (Aaron) can't really recommend anyone thinking about getting into digital audio for Linux to choose the ZA2.
But wait! Peter Wahl writes that
...there now exists a free driver for linux which works (at least for me) fine. It can be downloaded from http://www.uni-bonn.de/~uzsa69/za2.html...
HT 1869, also known as CM 8330, also known as PC Chips "Sound Pro": Has digital input and output. Caused a bit of a flurry of interest in rec.audio.pro, as it has digital input and output and can be had for well under $50 US. Unfortunately, it's too good to be true. This card performs very badly in tests. Also, it's apparently hard to get the input to work at all. See www.pcavtech.com/soundcards/ht1869/index.htm.
Creative Sound Blaster Live:
In many ways this seems like a nice card. Many people like it
and several have written to me to say that its technical
deficiencies are too subtle for most people to hear. However, I'm
still putting the SBLive in the "bad digital cards" section, on the
grounds that people reading this document are
looking for the highest quality sound they can afford;
and if you are reading this section, you are looking for digital
inputs and outputs that do what they're supposed to: pass digital
data un-altered. The SBLive cannot do this, and therefor it is
unsuitable for a professional-quality system.
Now for some more background info. Creative Labs has released
source code for a driver. It can be found at
http://opensource.creative.com. Subsequently, there is both an
ALSA driver released for this card, and, according to Juergen
Kahrs, a driver by Alan Cox that will end up in the mainstream
linux kernel 2.4 release. It features support for hardware mixing,
a very cool feature which means that "...dozens of processes can
open /dev/dsp and emit sound, each with its own sample rate. I
tested this feature and was able to emit 8 sound simultaneously
with 3 different sample rates being involved. The disadvantage
seems to be that there is always a sample rate conversion...."
As for the hardware, the "full" version of the SB Live (priced around US $200) does have digital input and output. There is also a $100 version that does NOT have the digital in/out. Now, about those digital ins / outs... Forrest Cook reports:
"Almost all the reviews focus on their analog and effects capability, and gave it a very good rating. The few that looked at the digital I/O found it pretty bad."
For example, at http://www.pcavtech.com/soundcards/ct4620/index.htm it is stated that
"Tests of the digital input of this card have been pretty disturbing... the digital input still seems to get unneeded DSP processing and corrupts sound quality by adding fairly broad 1 dB high peaks around 4 kHz, 10-12 kHz, and 16-20 Khz, with 44 kHz sampling. The digital output measures 1 dB down at 13.5 KHz, and -3dB at 17 khz, and -15 dB at 20 kHz. This is atypically bad performance for sound card digital I/O...."
And at http://www.maz-sound.com/sblive.html we read that "...the DSP runs fixed at 48 kHz, means every sound runs through the internal 8 point interpolation with 48 kHz ... digital 1:1 copies are impossible (the 48 kHz SPDIF frequency can't be changed to anything else either). [This] means: the SB Live! is no replacement for a digital-only card or an EWS64 L/XL for instance..."
Bryan Levin warns: "in fact, its really just a soundblaster
with a trident chip and their spdif out is NO BETTER than the sblive
value2. ie, it resamples and is NOT a literal unmodified wave ;-(
I bought one assuming it was a cheap spdif card, yet when I
feed 44.1 into it, I get 48k out; even on the spdif port ;-("
As for those expansion brackets: Anonymous Tim forwarded me these messages from good old Jaroslav Kysela on the ALSA mailing list:
> The 4dwave card requires an additional bracket, the
> NX DB I. However, this bracket only allows for digital output (not
> input). To get digital input with the ST Digital NX you need to spend
> approximately $125 (US) (http://www.audiencedp.com) for the NX DB I,
> NX DB II and NX DB III brackets.Yes, it's true.
See also http://www.hoontech.com/product/soundcard/STdigitalNX.htm
...This combination seems to disable digital input and output to the AC'97 codec and routes these signals to ST-DB III through NX-DB II.
You get:
- automatic input conversion (max 96kHz, 24-bit to 48kHz, 16-bit)
- output is probably always at 48kHz, 16-bit
- external digital input, digital input from CD (TTL signal) and digital output from your soundcard are mixed together
- optional 6dB attenuationI can only confirm that conversion algorithm is lossless or nearly to lossless (I can't hear any distortion when I connect through optical cable my external CD deck and through coaxial cable my digital receiver).
Note: If you want also use analog inputs or outputs, you must buy second soundcard. With above components, the soundcard uses only digital I/O paths.
I do not have enough information about these cards to say whether or not they can be used with Linux.
Terratec cards: Some cards from Terratec have S/PDIF capability. At least some features of some of these cards are supported by OSS-Linux. Cards with digital in/out are: xlrate-pro (output only), the Soundsystem DMX (input and output), and EWS 64L and 64XL (in and out). Prices for EWS cards start around $350 US or so.
Sonorus STUDI/O: optical in/out and ADAT lightpipe, support supposedly coming from OSS-Linux at some time in the future. Expensive (like $800 US?).
Ensoniq Audio PCI: No, this card does not come with any digital input/output, but this page has information on how you can add digital input yourself... including codes to send to hex addresses to turn it on and off. For serious D.I.Y. tinkerers and hackers only, this just might work. I don't know if this information applies to the Creative Soundblaster versions of this card, or just the old Ensoniq card.
Even more far out on the DIY tip: here are plans for a complete card you can build yourself, from raw parts! Two optical ins, one optical out, and there even seems to be some sort of linux driver for it! Apparently you could at one time order a pre-built version from elrad, but that doesn't seem to be true anymore.
There is a page with some general information on digital soundcards at www.digitalexperience.com/cards.html
Thanks to Paul Barton-Davis, there is now an ALSA driver for the RME DIGI-9652 (Hammerfall). This card has 3 ADAT interfaces (24 channels) as well as S/PDIF and AES/EBU ins and outs. I don't think there are any built-in analog ins or outs, so you'll need external converters or at least an ADAT or two to connect to it. There is also a "lite" version of the Hammerfall, with 2 ADAT interfaces (16 channels). Thanks to Benjamin Golinvaux for pointing me to this news.
Midiman Delta series: there are several cards in this series, including models with 4-ins / 4-outs, and 8-ins / 8-outs. They can do 24-bit / 96 kHz operation. There is an ALSA driver for these cards. Check the ALSA web site. For more about the cards, see www.midiman.com
Creative SoundBlaster PCI / SB 128 / Ensoniq AudioPCI apparently has 4-channel analog output, according to Thomas Sailer:
"...mine is rather old. The cards have an analog multiplexer on board (4051 I think, or similar), and in 4 channel out mode, the line in jack is switched to become the second line out jack for the other 4 channels.
If you look at the codec datasheet (akm4531, www.akm.com), you'll see that it has 2 2channel DAC's and one 2channel ADC."
Jurgen Kahrs reports that some old versions of this card actually have 2 dedicated stereo output jacks. He also notes, "The SoundBlaster PCI 128 is a real pain. We thought about using it in our products. This turned out to be impossible because the SB PCI 128 is just a name that Creative uses as a synonym for 'our cheapest card'. The hardware behind it changes constantly. On their web site they have photos of two card layouts which show completely different cards. But there must be at least one other card layout because we have a version of the SB PCI 128 here which does not resemble any of the two photos...."
Hoontech (Trident) 4Dwave NX now has ALSA support for multi-channel output, according to Andy Lo A Foe. Also, I found this note from Paul Barton-Davis on the Csound mailing list:
"...They cost $39+shipping from Korea for a card with 4 channel output (though there are some oddities about using the rear 2 channels (*)) plus S/PDIF digital I/O (Note from editor: See the above section on digital cards! You need expansion brackets to do this with the 4Dwave, and it disables the analog audio path too!)
... There is a little bit of spectral peaking and dipping here and there, but its a very nice card...
(*) the specs for the trident chip indicate that the rear channel output gets routed through a reverb unit. they don't indicate how to bypass the reverb unit. however, i imagine that under windows, this is probably solved already. we're still trying to figure it out over on the alsa-devel mailing list...
ps. trident wrote and donated a driver for their chipset to ALSA. if you use Linux, show trident that you appreciate this kind of thing."
Creamware TripleDAT hardware has an unofficial driver that may or may not work, here.
Creamware PULSAR is rumored to get some sort of official linux support at some point in time. Wish I knew more. This is an expensive ($1000?) system, and I don't even know much about the hardware. We've been waiting for more news on this for a looong time now. Smells like vaporware.
See also the Sonorus STUDI/O above, which I think requires external ADATs to get multitracking happening.
any more ideas, anyone???
Juergen Kahrs reports that, contrary to prior versions of this HOWTO, the SGI DA1100 soundcard from SGI will NOT be supported by ALSA. Apparently SGI took their people off the project and nobody else has the documentation to do the job.
None of the Event cards (Darla, Gina, Layla) have any linux support, and the fools will not release documentation, so no one else can write drivers. Too bad for Event.
...the problem is in the MPU-401 hardware specification. This hardware haven't the TX interrupt. Every soundcard with the standard MPU-401 emulation has this problem.> What card would you recommend for responsive MIDI then? Or, should I
> not care, and just make sure I code to be as low-latency as possible?Chipsets with full IRQ based RX & TX:
Trident 4DWave DX or NX
Creative Ensoniq AudioPCI (ES1370,ES1371,ES1373)
Gravis UltraSound
|
This page is maintained by Paul M. Winkler, <slinkp23@yahoo.com>. 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 mp3.com. You can read blahblah about me here but I don't recommend it. |
Copyright (c) 1999 by Paul M. Winkler. This document may be distributed under the terms set forth in the LDP license at sunsite.unc.edu/LDP/COPYRIGHT.html.
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@angelfire.com
