The Fugue

So I've been reading up on what makes organ pipes tick (ok, so they don't tick). It's very fascinating and yet very simple. It has surprised even me that it has made me think about making my own.

Now, I'm not crazy enough to build a large organ, at least not without gobs of time and money and the proper tools. I'm still nurturing the dream of building just a MIDI pedalboard, remember.

Still, there is a project that I can see myself taking on someday. I could build a positive organ. ("Positive" rhymes with "beef.") It's a little one-manual organ that has just a couple of stops. It's portable like a dresser with wheels is.

But not just any positive organ. A crazy simple positive organ. I'm thinking PVC pipe, because working with metal and wood intimidates me (and I don't have the tools). That may change before I actually build it. Who needs a case? If I'm going to build a pipe organ it's going to be naked so that people can see how an organ works. So build it onto/into a simple push cart or something. As for wind, what good is a portable organ if you have a loud motor that needs electricity? If I had cash for a nice quiet blower that would be one thing, but since I don't maybe I'll go with a simple bellows like they did in the olde days. Keyboard? Tracker's the only way to go on something like this, which means I'll have to break my anti-woodworking pact. But on a positive organ where the pipes are right there, the action should be simple.

This is very early stages of the dream, but I'm imagining 8', 4', 2', and 2 2/3'. 8' and 4' for sure. Probably 49 notes (4 octaves) on the manual. So that's 100–200 pipes. I hope my attention span is that large. Of course I can always start with one stop and go from there.

You may wonder how I'm going to fit an 8' stop in an organ I pretend will be portable. You can take a 4' pipe and cover the end and it will resonate like an 8' pipe (and though it's not made of wood will hopefully sound not entirely unlike a Gedackt).

If none of that made any sense, just click on this link and say "that'd be cool!"

From time to time I think about evidence-based genealogy. All good genealogy is evidence-based, i.e. you have evidence to support all of your conclusions, and a complete stranger would agree with your conclusions because of your evidence. But most amateur genealogists, and computer software, treat evidence as a secondary concern at best. To them, it's the conclusions that are important, and documenting the evidence is an afterthought and a bother and usually is not done at all. After all, it's obvious at the moment that you're recording the marriage of Fred and Wilma that it's true. Of course later we find that Fred and Wilma never even knew each other, and we've forgotten why we thought they got married. Oops.

The problem is exacerbated by the fact that most amateur genealogists (including genealogy software developers) start out by recording the family history stored in their heads. This is information that they are as sure about as they are of gravity. Recording evidence of these "givens" is tedious and ridiculous. And there's enough of it that by the time you've entered it all into the computer (or onto family group sheets) you have developed a solid bad habit of not entering sources.

This is compounded even further by genealogical databases. Go to a family history center or genealogy website and download a few thousand or tens of thousands of names. Who would turn down such a tremendous head start? Who would meticulously verify and document the evidence of every one of those names and the dozen or more conclusions associated with each one?

But I'm getting sidetracked. The question of the day is whether genealogy is an inductive or deductive sport. Let's review the definitions.

induction |inˈdək sh ən|, noun. The inference of a general law from particular instances.

deduction |diˈdək sh ən|, noun. The inference of particular instances by reference to a general law or principle.

So induction is going from specific to general, i.e. making conculsions based on evidence. Sounds like genealogy, right? But if we replace "general law or principle" with the word "premise," then it also looks a lot like genealogy. The problem is, neither evidence nor genealogical conclusions look an awful lot like "general laws."

Let me take another crack at defining the terms. Induction is when you take a bunch of observations and induce a probable generality from them. Deduction is when you take premises and deduce an absolute generality from them, given that the premises are true.

If I have a birth certificate for one Fred Flintstone, then I can deduce that some Fred Flintstone was born on such and such date. The only way to question that conclusion is to question the veracity of the birth certificate. Note that I said some Fred Flintstone. A common pitfall in genealogy is the leap from evidence for someone of the same name to evidence for the particular person being researched.

If I have the birth certificate, and a bunch of other documents, and they all support the notion that there was one Fred Flintstone in Bedrock during this period of time, and all the evidence fits together well, I can construct a probable picture of the person Fred Flintstone. This seems to be induction. Even though my premises are true, I may be taking a leap of faith to conclude that the Fred Flintstone from the birth certificate is the Fred Flintstone that married Wilma (and therefore my ancestor). It's not deduction because it doesn't follow directly from the premises.

Well, so it seems like genealogy is both inductive and deductive, and that's before you even consider the fallability of evidence. No wonder it can be such a mess. This underlines the need for tools that help us dwell in the realm of evidence which is relatively stable compared to the realm of conclusions. Very rarely indeed will a primary source be completely false (though it is more common to find inaccurate sources—bad spelling or slightly-off dates). More often, our conclusions based on the primary sources are completely false. Yet, in the end, it's the conclusions that we care about. So the software needs to allow us to dwell in the evidence world while providing the context of our current set of conclusions.

Software developers would be tempted to treat evidence-based genealogical software as deductive reasoning. They'd program in all kinds of ways for the computer to do the thinking for you. Fuzzy probable conclusions have no place in this vision. I think that's the point of this post. We mustn't fall into that trap or we'll have another dark age like the conclusion-based age we're still struggling to get out of. Except this one will be worse because it doesn't even match the amateur genealogist's first way of thinking of things.

While I believe there is room for computers to automatically infer things based on evidence, and direct researchers to areas of the family tree that may be influenced by this new bit of information, I think it is vital that we not lose sight of the fact that this is a human enterprise. In the end, a person must interpret the evidence, and she must be able to easily change her mind later. As such, the software must first and foremost be an organizational tool. It must help us make sense of the mass of evidence and conclusions. It must free us from the shackles of disorganization without binding us with the shackles of inflexible deductive logic. And yet, at best it will encourage the infallibility of deductive reasoning where appropriate.

So what do you think? I'm a computer scientist, not a logician and I have been known to confuse inductive and deductive reasoning. Is genealogy inductive, deductive, or both?

I can never remember this, and I use it frequently, so I thought I'd put it here where I can find it faster.

all: $(patsubst %.txt,%.html,$(wildcard *.txt))
%.html: %.txt header.html footer.html
    cat header.html > $@
    markdown $< >> $@
    cat footer.html >> $@

This week's forecast is highs between 104°F and 106°F. The special weather statement says it's expected to be the hottest week of the year. Ugh.

Expect a post, if I survive, on keeping butter at "room temperature" without it melting completely. I have an experiment in mind and these are just the conditions in which to execute it.

So I went to the dentist the other day and he recommended I stop using that awful baking soda toothpaste. Oh how he wishes it wasn't even on the market. It's the worst thing to happen to dental health since dulce de leche!

Whatever. Whenever I heard superlative statements, even when calmly uttered by specialists and authority figures, warning bells go off. On the other hand, the possibility that I might stop suffering from sensitive teeth is enough to warrant some research.

His claim against baking soda is that it's too abrasive. When I came home and started googling, I found that the Arm & Hammer people are saying that baking soda is less abrasive than the silica abrasives most toothpastes use. Somebody's wrong. Both are trying to sell me stuff (the dentist wanted to give me prescription Prevident toothpaste, which of course they sell). Neither can be trusted (ok, maybe the dentist can be more trusted to have my best interest at heart, but in my experience health care professionals for all their heart can't always be trusted to get all the facts straight. Ask them for supporting evidence. If they can't back it up with science, they might be mistaken!). I need facts.

After a bit of googling, I found an interesting report by some students (undergradutes, by the look of it) at the University of Waterloo. They rigged up a dremel to brush teeth for the equivalent of 82 years and compared straight baking soda, Arm & Hammer toothpaste, and Topol (a fairly abrasive smoker's toothpaste). They found Arm & Hammer didn't noticeably abrade the teeth, Topol did mildly, and baking soda did severely. Unfortunately, there wasn't a comparison between a baking soda toothpaste and a regular (silica) toothpaste.

Finally I found some information about the Relative Dentin Abrasivity (RDA) index. Armed with this new keyword I started finding more substantial information on the abrasiveness of various toothpastes. This article at Satyen.com has an excellent description of the methods and a nice table of results for many toothpastes, including sources. In addition, it is reported (complete with hyperbole) that toothpaste companies will usually give you the RDA values of their toothpastes if you call and ask (but apparently Crest doesn't).

So looking at the Sayten.com chart, which is corroborated by various bits and pieces scattered across the web, baking soda toothpaste is neither automatically better nor worse than other brands. They are all in it together. One thing that you do notice is that whitening formulas have higher abrasion than non-whitening, and sensitive formulas tend to lower abrasion, but there are toothpastes that aren't labeled sensitive that are just as low or lower.

Most interestingly, baking soda alone has a very low RDA of 7. This doesn't jive with the report by the students at the University of Waterloo, but could be explained by a difference in methods. One possible explanation is that baking soda in toothpaste (and presumably that used in the RDA tests) is ground finer than the stuff in the box and/or has more liquid added which allows it to dissolve into finer particles.

Based on the lower RDA numbers that Arm & Hammer toothpastes tend to get when they're not whitening, it would seem that baking soda is indeed possibly a gentler cleaning agent than silica, but other factors come into play.

To be fair to my dentist, he did mention that whitening toothpastes were bad for sensitive teeth, and I have indeed been using a whitening variety. He also disparaged tartar control as useless and perhaps bad for sensitive teeth. I didn't research that in depth.

It should also be mentioned that RDA isn't the whole story. There's also Pellicle Cleaning Ratio (PCR). You want a high PCR and low RDA, i.e. more cleaning power with less abrasion. Obviously it's a balancing act. Water alone has a nice low RDA of 4, but obviously water alone doesn't clean as well as a toothpaste. And we're not talking just get the dulce de leche off, we're talking about removing more stubborn bits and pieces (like tartar).

So let's look at the various things toothpastes claim to do.

Flouride: This is supposed to help strengthen/build enamel. The consensus seems to be whatever you do, get a toothpaste with flouride. The primary difference in prescription Prevident appears to be a higher dosage of flouride (1% instead of 0.25%).

Whitening: This is essentially a sandpaper process. You're literally grinding away the stains. No thanks for me. If you have sensitive teeth and/or don't have severe staining problems, stay away.

Sensitive: Toothpastes containing potassium nitrate (saltpetre) are "clinically proven to sooth exposed dentin". Apparently bacon is good for your teeth! (Actually, bacon is usually cured with sodium nitrite these days.) From my googling, it seems this is primarily good for sensitivity at the base, along the gumline, only. I have noticed sensitivity there of late, but I'm much more sensitive (and have been for years) on the actual chewing surface of my teeth. I might give this a try.

Sodium Lauryl Sulfate: Most commercial toothpaste have this foaming agent. It is claimed to aggravate canker sores, so if you tend to get them you might look for a toothpaste without SLS (probably at a health food store).

RDA: see chart linked to above. A lower RDA means less enamel worn away. Ideally you find a good PCR:RDA ratio, but I haven't been able to find a good source of PCR information.

Triclosan: Colgate Total has this antibacterial stuff that adheres to your teeth. It's supposed to be really keen. It's patented, but I hear the patent is running out this year, so maybe we'll see other brands using it (or maybe I'm misinformed).

ADA seal of approval: look for this, it means dentists think it's keen. Oh, and it also means that the toothpaste manufacturer jumped through the hoops and paid the money to get the testing done. So the lack of seal alone cannot be taken to imply a lack of quality, but the presence of seal implies quality (or that the ADA is corrupt).

Toothbrush: the stiffness of the bristles is a factor in the abrasion as well. If your teeth are sensitive it seems you probably want soft bristles.

In summary, I plan to find a toothpaste with flouride, a low RDA value, and an ADA seal. Maybe I'll try something with saltpetre and/or triclosan. I'll probably continue to use an Arm & Hammer brand because I like the taste and the orange tube is handsome.

Disclaimer: I am not a dentist, doctor, oral hygenist, dental assistant, or drug dealer. I sometimes forget to brush my teeth at night. In no way do I claim know what's better for your teeth than you do, let alone dentists and drug dealers. Feel free to learn from this post but don't come whining to me when your teeth fall out. That goes for any other random blogger on the internet, for that matter. For all you know, I could be a baking soda shill, supported entirely by the deep pockets of Messieurs Sodium and Bicarbonate.

Well, I've spent two days doing actual work in my studio and I can now confidently report my settings for the benefit of Linux-running MacBook users (and other related hoodlums).

I won't go into the detail that I did in the previous posts, most of which is still relevant.

I pass the option position_fix=3 to the module snd-hda-intel. I did this by creating /etc/modprobe.d/local, containing: options snd-hda-intel position_fix=3

then running sudo update-initramfs -uk all.

I set up my Gnome session to run QJackCtl, which is in turn configured to start JACK on startup. My JACK settings (from ~/.jackdrc) are: /usr/bin/jackd -R -t2000 -dalsa -dhw:0 -r48000 -p1024 -n2 -s

JACK is extremely stable. I've had 2, maybe 3 xruns through two days of work, and those were when starting up applications, not when actually using them.

Now, since we have only one audio device and JACK has monopolized it, and we want to hear other than JACK, we need more configuration. Here is my ~/.asoundrc:

# Set the default device to PulseAudio for all well-behaved ALSA applications
pcm.!default {
        type plug
        slave.pcm "pulse"
}
ctl.!default {
        type plug
        slave.pcm "pulse"
}

# This device can come in handy, but I mostly don't use it.
pcm.jack {
        type plug
        slave {
                pcm {
                        type jack
                        playback_ports {
                                0 alsa_pcm:playback_1
                                1 alsa_pcm:playback_2
                        }
                        capture_ports {
                                0 alsa_pcm:capture_1
                                1 alsa_pcm:capture_2
                        }
                }
                rate 48000
        }
}
ctl.jack {
        type hw
        card 0
}

# The acutal PulseAudio device
pcm.pulse {
        type pulse
}
ctl.pulse {
        type pulse
}

Now all well-behaved ALSA programs will use the default ALSA device, i.e. PulseAudio. PulseAudio needs to be configured now to use JACK. You'll need to get the pulseaudio-module-jack package, which probably means you'll need to build it yourself. I show you how to do that and how to configure PulseAudio in a previous post. Incidentally you need to do the same for libasound2-plugins if you want to use the JACK plugin for ALSA as in my asoundrc above.

Now we have a bit of a chicken and egg problem. PulseAudio starts when you log in, and so does JACK (by way of QJackCtl in your Gnome session). But PulseAudio will fail to start if JACK isn't already running. What's more, if you decided you wanted to restart JACK for whatever reason, you'd have to restart PulseAudio too. So here's how I solved it. I leave ESD enabled in the Gnome sound settings, knowing that it will fail to start (and I won't get the really cool Ubuntu Studio startup ditty, but oh well). It needs to be checked if you want Gnome to make nifty system sounds. Now, in QJackCtl setup, on the options tab, check the box for "Execute script after Startup" and put "pulseaudio -D" in the box. Now PulseAudio will start whenever JACK starts, and it will stop/crash/whatever whenever JACK stops.

Now, you need to install libflashsupport to get Flash working with PulseAudio. Even so you might find occasional sites that crash it.

That about covers it. If you do much work with audio applications using complicated JACK graphs, don't overlook the power of QJackCtl's patchbay, which will automatically hook things up. I have a patch that will connect Aeolus to system output 3&4 (headphones/external speakers), and hook my MIDI keyboard to Aeolus. So all I have to do is start Aeolus and pull some stops and I'm ready to play.

Which reminds me, there's still the annoying thing about JACK having 8 outputs (for surround sound) and the internal speakers are on outputs 1&2, and the headphone jack is outputs 3&4. If you're not getting sound from a JACK app and you think you should be, that's the first thing to check. Someday I plan to figure out the .asoundrc magic needed to set up JACK so that it's a regular stereo device sending sound to both the internal speakers and headphones. If you know how, please enlighten us in the comments. I know it can be done, I just haven't put in the time to figure it out and test it.

My wife is out of town and I'm fending for myself in the kitchen. This is of course the best part of playing bachelor, since I get to try all the weird things and seafood that my wife balks at. Still, I decided to be rather boring tonight and have salad. I like a salad with nice dark leafy greens (no iceberg thanks), cheese (feta and cheddar in this case), boiled egg, and ranch dressing. There is no substitute for ranch dressing. I don't smother my salad in ranch, but I do need ranch or maybe bleu cheese in a pinch. Caesar can be ok, and I've been known to eat other dressings to be polite (or none at all—a spinach, mozarella, and mandarin orange salad can stand on its own, for example), but for the purposes of this blog post, there is nothing but ranch. And I was out.

Now actually, though ranch is by far my favorite dressing, I am not well pleased by the ranch dressings on the shelf. My mom used to make it by hand (and I used to help). I don't remember much about it (I was pretty small), but I do remember buttermilk, some kind of mix, and lots of shaking. It was good stuff. Until a short time ago, I never found a ranch dressing that I liked in the store. Hidden Valley was as close as I could get, but it wasn't quite right. Some of the others were simply hideous. And most have MSG which I halfheartedly try to avoid.

A short while back, I came across a Kraft ranch I had never seen. Actually a whole line of them. Maybe I had just missed them before they changed the bottle, maybe they weren't stocked, maybe they sprung into existence overnight. I didn't know, but I checked and it didn't have MSG so I bought it. It was better than Hidden Valley, and it doesn't have MSG. So, my new commercial favorite. It was this bottle that had just run out.

So I jumped on ye olde internet in a quest to find out what makes ranch ranch. Near the top was a chowhound.com link, and I find that the chowhounds generally get things right, or are at least a good jumping-off place, so I beelined.

Some people on the thread believe that MSG is the flavor of ranch. Well, sorry, but my bottle of Kraft preemptively debunked that theory. My wife recently tried making ranch (I'm not sure what her motivations were exactly, but probably something to do with health and preservatives and MSG), and I don't know what recipe she used but it flopped. It lacked something we couldn't put our fingers on but we called "body", and for a moment as I read I feared that something was MSG. But I kept reading and let my senses return, and several people on the chowhound thread said it was nonsense and they had been making perfectly good ranch without MSG for years. I decided to try this one. I didn't have quite a full cup of mayo, and I was lazy about measuring the herbiage and it ended up a bit too biting (too much parsley probably), and I forgot the vinegar. But it turned out great. In fact, I tasted it when it was just mayo and buttermilk and it was instantly recognizable as containing the essence of ranch.

So, my recipe based off of MollyGee's is:

Ranch Dressing

1 cup mayonaise
1/2 cup buttermilk
1/2 t salt
freshly and coarsley ground pepper
1 t vinegar

garlic
dill
chives
green onions

Naturally, this is tailorable to your tastes. One thing I might try next time is replacing 1/2 cup mayo with 1/2 cup sour cream. Thickness isn't a big issue with me, but keeping it at least thin enough to shake well seems like a good idea, based on her observation that it gets "weepy". I seriously doubt it goes bad after 3 days. Mayo and buttermilk aren't prone to spoiling quickly. But I can see it needing remixing (hence the good shake).

Now go forth and eat salad.

I spoke too soon about not being able to get PulseAudio working as a JACK client. I found this post that tells you how to do it.

The key I think is chmod -s `which pulseaudio`. I didn't have to start the JACK transport rolling, so that may be antiquated information. I did have to build some packages from source, though:

sudo apt-get build-dep pulseaudio
sudo apt-get install libjack-dev
fakeroot apt-get source -b pulseaudio

This creates a bunch of .debs, including pulseaudio-module-jack*.deb. I just installed them all, but you can probably just install the jack module deb. Make the changes permanent by putting them in ~/.pulse/default.pa or in /etc/pulse/default.pa and you're in business.

I spent the better part of two days fine tuning my linux audio setup on my MacBook, so maybe I can save anothe MacBook user some time with this post.

The sound card in this thing is an Intel HDA Controller, driven by the kernel module snd-hda-intel. Intel HDA cards (usually onboard cards) are looked down upon and generally derided, and I can testify with good reason. Like all sorry excuses for an audio card, it has only one subdevice which means only one application can use the card at a time. (If you want to know if your audio card is cheap, this is a good indicator—just look in /proc/asound/card0/pcm0p/info for subdevices_count)

Luckily in these modern times, the default ALSA device does software mixing (dmix), so even on a cheap card you can usually hear more than one application just fine. No, no, you do not need PulseAudio for this. In fact, PulseAudio steals the audio card in its default configuration (at least on Ubuntu 8.04). So if PulseAudio is running, applications that aren't PulseAudio aware (or ESD aware) will simply not be able to make sound. There are other misbehaved kids on the block, but they're fairly rare. The difference is that a well-behaved application will grab the default ALSA device, instead of the first audio card in the system explicitly, hw:0. PulseAudio in fact advises the use of this trick, to set PulseAudio as the default ALSA device, which I suppose explains why PulseAudio grabs hw:0 by default. Unfortunately Ubuntu is only halfhearted here—it enables PulseAudio but does not set up the default ALSA device to point to it. So in Ubuntu you need to either set up the default ALSA device with an ~/.asoundrc that looks like this

pcm.!default {
    type pulse
}
ctl.!default {
    type pulse
}

or you need to configure PulseAudio to use the default device instead of hw:0. If you are going to be using JACK too (and you want to hear other applications outside the JACK pipeline when JACK is running), I recommend the latter, though if you're twisted enough you might try JACK as a PulseAudio client.

JACK also by default grabs hw:0, because JACK is all about low latency and high performance and going through dmix adds a layer of overhead. If you're using JACK, you may be enough of a snob that you're ok with leaving those non-JACK applications out in the cold while JACK is running. In fact you may not want to hear Pidgin sounds (for example) at all while you're doing audio work. Semisnobs like myself, though, might want a compromise. Setting up my studio just the way I want is enough of a pain, I really don't want to quit all my JACK applications just so I can listen to Last.fm or watch sb_email.

Now at this point I would be remiss if I didn't mention the very cool JACK plugin for ALSA. It allows you to make well-behaved ALSA applications (the ones that use the default device or allow you to configure which device is used) go through JACK. I modified my .asoundrc in a manner slightly different from the example given:

pcm.jack {
        type plug
        slave {
                pcm {
                        type jack
                        playback_ports {
                                0 alsa_pcm:playback_1
                                1 alsa_pcm:playback_2
                        }
                        capture_ports {
                                0 alsa_pcm:capture_1
                                1 alsa_pcm:capture_2
                        }
                }
                rate 48000
        }
}

Then if you want to make the JACK plugin the default, you add

pcm.!default {
    type plug
    slave.pcm "jack"
}

I tried configuring PulseAudio to use the JACK plugin, but it would crash on startup. Last.fm's client also had issues—it will play fine for one song and then crash jackd when the second song starts. So unfortunately it doesn't look like the JACK plugin for ALSA is quite ready for prime time, but you can certainly use it from time to time in applications that let you choose the ALSA device.

Unfortunately, the JACK plugin isn't found in Ubuntu's libasound2-plugins package where it belongs. It's an easy remedy, however, just install libjack-dev and fakeroot, then build the package from source (you don't even have to patch it):

apt-get install libjack-dev fakeroot
apt-get build-dep libasound2-plugins
fakeroot apt-get source -b libasound2-plugins
sudo dpkg -i libasound2-plugins*.deb

Getting Ubuntu to not annoy you constantly about "upgrading" that package is another story.

Ok, so now to the meat of this post. JACK does not work well on this sound card with its default settings. It either has an insane number of xruns, or it sounds terrible. For quite some time I chased the red herring of the position_fix parameter to the snd-hda-intel module, and I can report with confidence that on this hardware you don't want to change it from the default (0, which is auto). However, if you are only concerned with JACK, you will want to change it to position_fix=3, which gives rock-solid JACK with the default settings on hw:0. However, although JACK or other direct-to-hw:0 applications sound fine, dmix sounds crackly using position_fix=3. So it's probably not a good all-around solution if you're interested in more than just JACK.

The first order of business in good JACK performance (on any system) is to enable realtime. Edit /etc/security/limits.conf and add something like this:

@audio - memlock unlimited
@audio - nice -10
@audio - rtprio 99

Now (after logging out and back in) you should be able to pass the -R option to jackd and get realtime.

If you do jackd -R -d alsa (unless you use position_fix=3) you will get lots of xruns. The best I have been able to do is jackd -R -d alsa -p 512 -n 4, as it seems that the trick is getting at least 3 periods (and to do that with hw:0 you have to reduce the period size). This works well but qjackctl reports lots of xruns still. Actually, they're mysterious messages like this

delay of 5152.000 usecs exceeds estimated spare time of 4071.000; restart ...

which don't actually cause an audio blip (but you will get an occasional real xrun). I still need to try the realtime kernel (linux-image-rt package) to see if that might help here. In my early tests (mostly playing with position_fix) the realtime kernel was actually doing worse than the generic kernel, but that was before I learned the number of periods should be at least 3, so I need to test again.

If you run jackd -R -d alsa -d default you will theoretically be able to use JACK and other applications at the same time via dmix/dsnoop. JACK will complain

You appear to be using the ALSA software "plug" layer, probably a result of using the "default" ALSA device. This is less efficient than it could be. Consider using a hardware device instead rather than using the plug layer. Usually the name of the hardware device that corresponds to the first soun

[sic] but pay it no heed, we're doing this on purpose, and actually are able to get better performance than the hw:0 route (with position_fix=0). That command will not actually work, though. It will crash within a minute even without any clients. Again the fix seems to be the number of periods, but this time we can avoid the excess delay by leaving the period size at 1024 (at the cost of some latency, of course). So, jackd -R -d alsa -d default -n 4. This is rock solid. It went all night without a single xrun. (But it wasn't doing much, though Ardour, Aeolus, and Hexter were "running". I was able to play around with them for a half hour or so with no xruns before I went to bed.) However, sometime down the road it will miss a deadline and it will crash. This crashing seems to be specific to using dmix, usually you'll just get an xrun. The workaround is to use softmode with the -s switch. Now you can run JACK 24/7 with excellent performance and without locking other applications out of the soundcard.

So in summary, if you don't care about dmix but only JACK (or any other application using hw:0, which can be all of them if you change your .asoundrc, but only one at a time), set position_fix=3 for snd-hda-intel e.g. in a file in /etc/modprobe.d/ with a line like this: options snd-hda-intel position_fix=3, and do update-initramfs -uk all. If you want a more balanced setup, where you can have JACK running and other well-behaved ALSA applications can use the sound card, leave the module parameters alone and set up realtime and use the following command to start JACK (or equivalent settings in QJackCtl):

/usr/bin/jackd -R -dalsa -ddefault -r48000 -p1024 -n4 -s

If you want to use PulseAudio in this situation, configure it to use the default ALSA device instead of hw:0.

If you like PulseAudio and JACK both, the ideal situation would be PulseAudio using JACK as a backend, JACK using hw:0 with position_fix=3, and the PulseAudio plugin as the default ALSA device. Unfortunately this is just a theoretical ideal, and doesn't work (yet) because of bugs.

And finally, if you have no or limited use for JACK, but want to use PulseAudio, just change your .asoundrc as above to make PulseAudio the default ALSA device, so that all applications, ESD aware or not, use PulseAudio.

Oh, and I almost forgot to mention the mixer. There's Master, PCM, Front, Surround, Center, LFE, Side, and various toggles. AFAICT the Front controls the internal speakers, and Surround controls the headphone volume. JACK on hw:0 has 8 system ports. The first two correspond to the front speakers and the second two to the headphone jack. When you run JACK on default, it's simply stereo output, and goes to the speakers or the headphones if they're plugged in.

Finally, I regret to report that JACK on default will crash on resume (on hw:0 it won't, at least with position_fix=3).

My Radium 61 MIDI controller (read: MIDI keyboard that doesn't make any sound of its own accord) has worked great in Linux from day one, but it was always a bit of a pain to get set up.

When the keyboard is plugged in (USB), it needs firmware uploaded to it before it will show up as a USB MIDI device. In the past the way this is done has changed several times. In the devfs days you did one thing. Then someone wrote a package that made it even simpler. Then udev came along and messed everything up. Then udev changed and messed everything up. Then it happened again (stupid udev). Then I brought my keyboard to school and only used it with OS X for a year or so, and now here we are.

Now Ubuntu 8.04 has a package midisport-firmware which installs the firmware and the udev rules. Awesome! Except, it doesn't work. It turns out that the midisport-firmware package (which obviously must be coming from Debian unstable, or it would probably work) depends on usbfs, and apparently Ubuntu has disabled it. Or broken it. Or something. The fix is quite easy: uncomment the four lines under the comment "Magic to make /proc/bus/usb work" in /etc/init.d/mountdevsubfs.sh, then issue /etc/init.d/mountdevsubfs.sh start. It should Just Work™ in the future after reboots.