Archive for the 'Starting' Category

08 DecFull-function Repo Set for Debian Testing

When one uses Debian Testing for high-test multimedia purposes, one must add repos.  Here is my current /etc/apt/sources.list :

deb http://ftp.gtlib.gatech.edu/debian/ squeeze main contrib
deb-src http://ftp.gtlib.gatech.edu/debian/ squeeze main contrib

deb http://security.debian.org/ squeeze/updates main contrib non-free
deb-src http://security.debian.org/ squeeze/updates main contrib non-free

deb http://ftp.gtlib.gatech.edu/debian/ sid main contrib
deb-src http://ftp.gtlib.gatech.edu/debian/ sid main contrib

deb http://ftp.gtlib.gatech.edu/debian/ experimental main contrib
deb-src http://ftp.gtlib.gatech.edu/debian/ experimental main contrib

#DEBIAN MULTIMEDIA
deb http://www.debian-multimedia.org/ squeeze main
deb-src http://www.debian-multimedia.org/ squeeze main
deb http://www.debian-multimedia.org/ sid main
deb-src ftp://ftp.debian-multimedia.org/ sid main
deb ftp://ftp.debian-multimedia.org/ experimental main

# Google
deb http://dl.google.com/linux/deb/ testing non-free main

# sidux sources added by smxi
deb http://ftp-mirror.internap.com/pub/sidux/debian/ sid main contrib non-free firmware fix.contrib fix.non-free
deb http://sidux.com/debian/ sid main contrib non-free firmware fix.contrib fix.non-free
deb-src http://sidux.com/debian/ sid main fix.main contrib non-free firmware fix.contrib fix.non-free

# Rivendell.  Some good and interesting code here.
deb http://debian.tryphon.org/ testing main contrib
deb-src http://debian.tryphon.org/ testing main contrib
deb http://debian.tryphon.org/ unstable main contrib
deb-src http://debian.tryphon.org/ unstable main contrib

# the Ubuntu Mozilla PPA.  Great for the current Thunderbird.
# Haven't tried it for Firefox yet, icebird is working just fine
# for me.
deb http://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu/ karmic main

02 NovCauses of ALSA Confusion

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.

29 OctALSA and Jack Cooperate using PulseAudio

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.

26 OctKernel command-line overrides

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

26 OctDaemon (service) control

For RedHat, use /sbin/chkconfig .  For Debian, best is probably to install something called ‘rcconf’.

Debian has the usual runlevels, but doesn’t exactly use them; at full-blast-boot it seems to run at something called runlevel S, which is enough to drive people up the wall if they aren’t ready for it :-)   This does mean that non-Debian runlevel editors should not be installed onto Debian, even if packages exist, because badly munged boot will often result :-)

I’d love to have a way to quickly daemonize a binary, but haven’t found it yet :-)

26 OctStarting point for setup of a solid system

A good first way to check the basics of your setup for high-test audio, is discussed here:

http://wiki.linuxmusicians.com/doku.php?id=system_configuration

However, at this writing, there appears to be some confusion.  The way I do it at present, is to get to a superuser shell, then:

yum install mercurial
hg clone https://realtimeconfigquickscan.googlecode.com/hg/ realtimeconfigquickscan
cd realtimeconfigquickscan
./realTimeConfigQuickScan.pl