In current distributions, there is a new nVidia driver, called “Nouveau”. Many nVidia video chipsets, even motherboard chipsets less than a year old, won’t work under Nouveau. For these, a procedure has been identified:
http://linuxsoftwareblog.com/?p=232
Curiously, I found that the video mode setting on the end of the kernel line is very important.
I had major cabling concerns for live Linux audio. I wore out my PC’s front panel 1/8″ stereo jack in six weeks!, and I didn’t want to keep on buying sound cards at that rate. So I did a lot of searching.
I found lots of USB hardware with XLR and 1/4″ jacks; but USB adds latency (MIDI response delay). Similar Firewire devices are often recommended, but they are generally expensive, and the configuration needs are reportedly slightly arcane. Eventually a friend of mine recommended RCA jacks. RCA jacks can take a lot of hookup/remove cycles, and they are very firm, they don’t tend to give static when jiggled. I thought of the hifi-home-stereo-component-PC market, and started to look for PCI and PCI-E sound cards with RCA jacks. It turns out that almost every major make of sound card makes at least one with RCA jacks for output. Sometimes the web-published literature doesn’t even mention it, but they’re there.
So then the problem was, which one? Most of the RCA-jack-laden cards are quite expensive. I searched for and found lots of web-reports, and eventually found that the Audiotrak Prodigy HD2, a PCI card, is often recommended. I was able to buy one for less than US$100, tried it. Definitely recommendable; I have been using it since 10/2009. Its s/n ratio is wonderful, performance excellent, visual manufacturing quality (to this ex-electronics-hobbyist) astonishing, at least this particular one is!
I bought it here.
I’m not yet sure how this works with ATI video, but if you’re running the nVidia-provided video drivers, you’ll need to remove them (sgfxi -n) before switching kernels and then reinstall them afterwards, or else X won’t know what to do.
Sometimes, as many have noticed, sound will work well for a while — several minutes, several hours — and then latency will rise a lot, or static will overlay, or sound will stutter or stop altogether, or all of the above. I have taken to calling this phenomenon “ALSA confusion”, as in “ALSA becoming confused” about what it should be doing and how it should be doing it. I have thus far identified the following causes and cures for ALSA confusion:
One of my principal problems to solve, has been how to get ALSA and Jack to cooperate in both (a) the high-test live audio milieu, where latency has to be low, responsiveness immediate, and bloat minimal, and (b) the general audio milieu, where we have to cooperate with the myriad API needs of general multimedia applications. Some will do ALSA only, some prefer other things. What to do?
And for high-test audio, jackd has to be given total access to its audio hardware, without impediment. Jackd uses ALSA as its driver set — but jackd must not be required to share its channels, or we are defeating our first purpose. So the easiest method, really, is to have two sets of audio hardware, perhaps USB speakers for the general multimedia and a pro-audio sound card with RCA jacks for the high-test work. But let’s say we don’t want to have the extra hardware lying around; we want everything to go to the PA! What then?
Well, general multimedia applications usually do not use Jackd. They usually want to talk either directly to ALSA as jackd does, or more and more often as an alternative, something else called PulseAudio.
But the simplest approach appears to try to configure everything to use ALSA. There was an attempt to solve this problem called an “ALSA Jack plugin”, which focusses on the fact that jackd must not share its ALSA hardware output. When this is implemented, jackd application sound still runs appropriately — still straight out, App–>Jack–>ALSA–>hardware — but general non-jackd ALSA application sound then runs App–>ALSA–>Jack–>ALSA–>hardware. There is no theoretical reason why this shouldn’t work very well; unfortunately the ALSA Jack plug-in has bugs. In my testing, it worked fine for several hours of system uptime, but then lost sync or cohesion or something, and began introducing static into the stream, gradually increasing in latency and xruns and quality decreasing over time. It would return to good behavior after reboot, and then after hours of either use or idleness, begin acting up again.
I would love to see the ALSA jack plug-in fixed — I don’t like adding layers to my systems — but we should use what works best. I could just add a set of USB speakers…but meanwhile, while I am waiting to be healed from my bad cold, perhaps I can get this thing to work 
It appears I need to do what the desktop distros are doing: I need to add PulseAudio.
PulseAudio is a layer, a program which sits quietly and takes up resources as needed. I am surprised and happy to report that it sits most quietly, and has not disturbed any of the many apps I need. It has also served its purpose quite well: it is the “glue” which is permitting many apps to understand how to use the audio on my systems. It would be rather unhelpful to try it on a box with 256M RAM — it seems to be using about that much RAM doing nothing right now — but as I have 4G here, that is OK. If you have 1G RAM or less, or a slow CPU or slower RAM, go buy yourself some USB speakers and call it done
But continuing. This post is written for Debian Testing and its very close relatives. It presumes that you already have a working Jack audio setup, that you have identified the alphanumeric ALSA name of your audio hardware, and that Jack is using that alphanumeric name in its device configuration. Here is a post containing info about alphanumeric names.
Commencing:
First you’ll need to get the PulseAudio packages. pulseaudio, pulseaudio-module-jack, and pulseaudio-utils, plus all dependencies. You’ll also need the ‘sudo’ package.
Now get to root privileges (su or sudo -s), go to /etc/pulse, create directory “originals” and copy everything into there as a backup. Then:
system.pa and default.pa should be made the same, should both contain:
#!/usr/bin/pulseaudio -nF # load-module module-jack-sink load-module module-jack-source
load-module module-native-protocol-unix load-module module-stream-restore load-module module-default-device-restore load-module module-rescue-streams load-module module-suspend-on-idle .ifexists module-gconf.so .nofail load-module module-gconf .fail .endif .ifexists module-x11-publish.so .nofail load-module module-x11-publish .fail .endif
daemon.conf should remain the same, except for one line, originally reading:
; daemonize = no
Change it thusly:
daemonize = yes
The above will attempt run Pulse in an appropriate fashion, at boot. But if you reboot right now, it will try to latch onto a Jack process which isn’t there. So we need to run Jack at boot too. With Jack (perhaps through qjackctl) running and working properly, do this in a command shell:
ps aux | grep jackd
On my machine, I get:
jeb 3777 1.8 0.7 29388 29404 ? S<Lsl 09:58 0:59 /usr/bin/jackd -Z -R -t1000 -dalsa -dhw:HD2 -r96000 -p128 -n2 -s -m -Xseq -H -M
jeb 7139 0.0 0.0 3188 728 pts/1 R+ 10:52 0:00 grep jackd
The info I need is therefore:
/usr/bin/jackd -Z -R -t1000 -dalsa -dhw:HD2 -r96000 -p128 -n2 -s -m -Xseq -H -M
We need to put this into /etc/rc.local. My /etc/rc.local reads:
#!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. sudo -u jeb taskset -c 1 nice --adjustment=-19 /usr/bin/jackd \ -Z -R -t1000 -dalsa -dhw:HD2 -r96000 -p128 -n2 -s -m -Xseq -H -M exit 0
‘sudo’ comes in at this point, because Jack has to be run as the user I log in with, for permissions. I am also using taskset for CPU affinity (I have a quad, -c 1 means really core #2), and nice -19 is near-absolute-max priority (I don’t like -20, the kernel should have some leeway).
The last step is relatively simple. The following is the contents of /home/jeb/.asoundrc:
pcm.!default {
type pulse
}
ctl.!default {
type pulse
}Now reboot. It is working for me rather nicely. Jack apps run well App–>Jack–>ALSA–>hardware, at absolute minimum latency; ALSA-only apps run App–>ALSA–>PulseAudio–>Jack–>ALSA–>hardware; and those apps that can do the PulseAudio API natively — a growing number — run App–>PulseAudio–>Jack–>ALSA–>hardware.
Here are some handy ones.
If your system’s clock runs too fast as a virtual guest, try:
clock=pit
And if your system’s clock is too slow, one or both of these:
pci=noapic pci=nolapic
although if you are running a multicore CPU, I believe that one of them is necessary.
Here is one more useful to turn off the older-style power management:
pci=noapm
The following is reportedly very good if you have a new and well-behaved motherboard with PCI and PCIe, it enables a new protocol for IRQ sharing that actually works:
pci=msi
and some poorly behaved motherboards, or older PCI cards, need it explicitly off:
pci=nomsi
And apparently, for ACPI situations (motherboards after 2000 or so), there is a whole slew:
acpi=force
enable ACPI if default was offoff — disable ACPI if default was on (same as noacpi)
acpi=noirq
do not use ACPI for IRQ routing
acpi=ht
run only enough ACPI to enable Hyper Threading
acpi=strict
be less tolerant of platforms that are not strictly ACPI specification compliant.
All of this and much more, is in kernel-parameters.txt, which is part of kernel source, also installed with a kernel-docs package, and web-searchable. The one at the link below is kept very current:
http://www.mjmwired.net/kernel/Documentation/kernel-parameters.txt
If you have worked on current Linux audio for a while, you have seen that ALSA, by far the most common and compatible audio hardware driver set, likes to give numbers to its hardware. Its numbers usually start with 0, as in ‘hw:0′, ‘hw:1′, et cetera. The problem is that the numbers it gives, often have nothing to do with what the system needs to work well.
For instance, until today, if I booted my PC with my USB MIDI interface removed, my sound card was hw:0. But if I booted my PC with the MIDI in, my sound card was hw:1, the MIDI interface was hw:0, and sound in general didn’t work at all, because the default card was still hw:0. I learned this the hard way, two minutes before the band was to play, and I didn’t have time to reboot. Sigh.
But I just learned a better way. Two new items. First, in addition to numbers, ALSA gives alphanumeric names. And second, we can tell ALSA to choose specific cards, by name, as default for all audio. There is a kludgy way to do this using negative numbers, which I used years ago; but that drove me crazy, and doesn’t always help!
There is another confusion which was recently explained to me. ALSA understands its hardware in three levels: there is the “card”, the “device”, and the “subdevice”. A sound card very often has more than one device; devices often have sub-devices. For instance, one very expensive sound card will have one alphanumeric name (we’ll say “XYZ”); but it may well have a stereo device (“XYZ,1″), a 5.1 surround output device (“XYZ,2″), and two or three input devices (“XYZ,3″ and “XYZ,4″), and each of these devices has subdevices representing each channel.
Here are my steps:
1. First find out the alphanumeric name of the sound card you want to use. Go to a terminal, and do this:
cat /proc/asound/cards
I have exactly one sound card engaged; the motherboard sound is turned off in BIOS (and this BIOS, happily, really does shut it off when told to do so). Thus the command above shows only one card right now:
0 [HD2 ]: Prodigy71HD2 - Audiotrak Prodigy HD2
Audiotrak Prodigy HD2 at 0xef80, irq 10
The string in the brackets is the alphanumeric name of this card: ‘HD2′. In most ALSA configuration locations, one uses it like this: ‘hw:HD2′. If sound still doesn’t work as desired, it is more than possible that devices within the card need to be specified explicitly, e.g., ‘hw:HD2,1′, ‘hw:HD2,2′, et cetera. Some trial and error may be necessary. For large-scale multitrack hardware, there still is one name, but the device numbers can go very high, especially for something like a 24-track USB box. Testing is really the next step:
2. We can set the default sound card for ALSA, for all users, to the above. We do this by creating (or replacing) the text file /etc/asound.conf. On this system, it is:
pcm.!default {
type hw
card HD2
}
ctl.!default {
type hw
card HD2
}
and the following on my hardware does exactly the same thing:
pcm.!default {
type hw
card HD2,0
}
ctl.!default {
type hw
card HD2,0
}
Now we’re probably not done for all sound on your machine. Most audio hardware of which I’m aware requires one or more methods of mixing multiple audio streams for stability, simply because multiple apps will be trying to sound off at the same time once in a while. ALSA docs say this is automatic, but frankly, it’s not, and this is why a configuration involving PulseAudio and ALSA is the emerging desktop standard, and all of PulseAudio, Jack, and ALSA becomes a very good idea if high-test audio with Jack is desired, as it is here.
3. I would get Jack running next, it is an important part of your toolkit. The default setup may or may not work, I wouldn’t worry about it too much. In the ‘Interface:’ field of the setup dialog for qjackctl, you should type in the alphanumeric name into the fields, instead of the menu-presets, a la for me:
hw:HD2
qjackctl also can help identify the devices within a given card. Check out the automatically identified items in the pull-down menus for the output and input devices; it can be quite educational, especially when results are studied in Google.
I find that this step, moving from numeric to alphanumeric ALSA device names, is a very good one in stabilizing a Linux sound system.