Linux Live

Been playing with the newer Jack, jack2.  It’s available in Debian Experimental repos, complete with firewire drivers.  The default install gave me slight real advantage, although the CPU behavior under htop (like ‘top’, but reports individual CPUs) was intriguing.  Then Joakim Hernberg, on the Linux Audio Users‘ list, posted the following link:

http://www.grame.fr/~letz/Timing.pdf

I read it about five times, trying to ponder what my first step might be given its info. It discusses two major modes of jack2: the default, which is asynchronous, and another, which is synchronous. Under asynch, my stress-test yields zero xruns (or close) at 5.3 ms (as reported in Qjackctl); but under synch, I have found very good stability at a setting for 1.33 ms!  *grin* Quite shocking. That synch makes a whole lot of difference. I can just imagine jack2 jockeying all four CPUs to make that happen  I praise the Lord, and I thank everyone for the help!

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:

1. The ALSA Jack plugin.  Don’t try to use it.  It is bad.  I saw this one happen.
2. ACPI engaged in the kernel.  I turned off ACPI in the kernel, my latency dived, performance rose, and ALSA confusion vanished.  This appears to occur with many motherboards.
3. Sharing an IRQ between the motherboard sound and one or more other data-heavy systems, e.g., video.  This can be tricky to solve, it can require BIOS changes and/or PCI card position changes, and is not always possible for motherboard hardware.  Happily, a very good quality PCI implementation of recent version — 2.3 I believe — should not exhibit this problem at all, if both card(s) and motherboard are compliant.  I didn’t see this one happen (my motherboard and card are new), but read about it a lot in trying to solve my problems.
4. Attempts to write to the same ALSA device by two different apps simultaneously.  ALSA docs say the problem doesn’t exist because the ‘dmix’ plugin is automatically engaged at need, but it’s simply not factual, it just does not happen in a great many cases, and my new very-low-noise pro audio sound card is one of them.  I solved this one by permitting only Jackd to output directly to the ALSA device; everything else outputs either to ALSA’s Pulse driver (thus far working very well indeed) or to Pulse (itself designed to handle multiple streams), which then hands the data to Jackd, which is tremendously good at handling multiple streams, at the very low latencies which we need.  My methods for this are described here.
5. Device ID confusion.  I found that ALSA sometimes gets very confused about its hardware when one is using USB devices (e.g., a USB MIDI cable) which it knows about.  I’m pretty sure I saw it try to output sound to the MIDI device as well as the sound system, simultaneously, until after I rebooted twice, one very scary five-minutes-to-go moment; prayer was involved.  I solved this one by use of alphanumeric names (see this page) instead of either “default” or “hw:0″ etcetera in qjackctl, Jackd, and sometimes asound.conf / .asoundrc.

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.

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.