Tag Archives: technology

The Crossbox Studio: multiple mic podcast recording for $60 per person

Posted by

If you’re a Crossbox Podcast listener, you may have noticed that we sound pretty good. Now, granted, our1 diction is poor, and we’re still figuring out the whole hosting thing. Our voices, however, come through loud and clear, with minimal noise. While we’re recording, we monitor our audio in real time. Some people will tell you quality podcast recording with features like that takes a big investment.

They’re wrong.

The Crossbox Studio is proof. We connect two USB microphones to one computer, then mix them together in post production for maximum quality and control.

In this article, I’ll show you how you can build our recording setup, starting with microphones and accessories, and moving on to software. Let’s dive in.

Hardware

We’ll start with microphones. For high-quality recording, each host has to have a separate microphone. This is a huge help both during recording and editing; being able to edit each speaker individually provides a great deal more flexibility to whoever gets stuck with the task of editing2.

For The Crossbox Podcast, we use one Blue Snowball—too pricey to hit our goal—and one CAD Audio U37. As studio-style condenser microphones go, the U37 is extremely cheap. It comes in at a hair over $39, and the sound quality and sensitivity are superb. I recommend it wholeheartedly.

Next, we need to mount the microphones in such a way as to minimize the transmission of vibrations to the microphone. This means that the microphone won’t capture the sounds typing on a laptop keyboard or touching the table. First off, we’ll need a microphone boom. This one clamps to the table. You don’t need anything fancier3. To hold the microphone, you’ll want a shock mount. Shock mounts suspend the microphone in a web of elastic cord, which isolates it from vibration.

If your environment is poorly acoustically controlled (that is, if you get other sounds leaking in, or if you have a noisy furnace, say), you ought to look into dynamic microphones. (The Crossbox may switch in the future.) These Behringer units are well-reviewed. If you get XLR microphones like these, you’ll also need XLR-to-USB converters.

Lastly, you’ll need a pop filter. Clamping onto the spring arm, the pop filter prevents your plosives and sibilants4 from coming through overly loud.

Let’s put it all together. Clamp the boom arm to the table. Attach the shock mount to the threaded end. Expand the shock mount by squeezing the arms together, and put the microphone in the middle. Clamp the pop filter onto the boom arm, and move it so that it’s between you and the microphone.

Congratulations! You’ve completed the hardware setup. Now, let’s talk recording.

Software

Moving on, we’re going to follow a procedure I laid out in an earlier article. Using two USB microphones at once brings some added complexity to the table. If you want to read about why this is so, hit the link above for a deeper discussion. Here, we’re going to keep it simple and just talk about the solution.

First off, you’re going to need a decently quick laptop5. Memory isn’t important. What we want is raw processing power. The amount of processing power you have on tap determines how many individual microphones you can record from.

Next, you’re going to want a specialized operating system6. Go get the appropriately-named AV Linux. This article is written targeting AV Linux 2016.8.30. Later versions change the default audio setup, which may cause problems. Create a bootable USB stick containing the image—here’s a good how-to. Boot it and install it. If you don’t plan on using AV Linux for everyday tasks (I don’t), install it in a small partition. (As little as 20 gigabytes will do, with room to spare.) Later on, when recording, you can choose a directory for temporary files, which can be in your everyday partition7.

Let’s move on. Now we’re to the point where we can talk about recording tools. The Crossbox Podcast uses two separate tools in our process. First, we route our microphone inputs through Ardour. Ardour, a digital audio workstation program, is powerful enough to do the entire process on its own. That said, we only use it for plugins, and as a convenient way to adjust our microphone levels relative to one another. We then route the audio from Ardour to Audacity, which we use to record, make final adjustments, and add sound effects.

Setting up audio routing: JACK

Time for a quick refresher on audio in AV Linux. It starts with ALSA, the Linux hardware audio driver. AV Linux, along with many other audio-focused Linux distributions, uses JACK as its sound server. JACK focuses on low latency above all else, and AV Linux ships with a real-time kernel8 to help it along. The upshot is that two ALSA devices, like our USB microphones, can be connected to our computer, using JACK plugins to resample their input using the same clock to guarantee that they don’t go out of sync.

We’ll touch on how to set up and manage JACK later. For now, let’s briefly discuss the overall audio routing setup, in terms of the path the audio takes from the microphone to your hard drive.

First, we’re going to use some JACK utilities to set up JACK devices for each of our microphones. We’ll run audio from those JACK devices through Ardour for mixing, plugins, and volume control. Next, we’ll make a dummy JACK device which takes audio from Ardour and sends it through the ALSA loopback device on the input side. Finally, we’ll use Audacity to record audio from the ALSA loopback device output.

Setting up audio routing: microphone in

We’ll need a few scripts. (Or at least, we’ll want them to make our setup much more convenient.) Before that, we’ll need some information. First off, run the arecord -l command. You should see output sort of like this:

**** List of CAPTURE Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC295 Analog [ALC295 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

This tells me that my laptop currently has one recording device plugged in: card 0, device 0, the built-in microphone. With your USB microphones plugged in, you should see more lines starting with card and a number. For the example above, the address is hw:0,0; the first number is the card number, and the second is the device number.

For each microphone, create a file on your desktop and call it microphone<#>.sh, filling in some number for <#>9. In this file, paste the following script.

#!/bin/bash
alsa_in -j name -d hw:1 -c 1 -p 512 &
echo $! > ~/.name.pid

The first line tells Linux to execute the script with the bash shell.

The second line starts a JACK client based on an ALSA device. -j name gives the JACK device a human-readable name. (Use something memorable.) -d hw:1 tells JACK to create the JACK device based on the ALSA device hw:1. Fill in the appropriate device number. -c 1 tells JACK this is a mono device. Use -c 2 for stereo, if you have a stereo mic10. -p 512 controls buffer size for the microphone. 512 is a safe option. Don’t mess with it unless you know what you’re doing. The ampersand tells Linux to run the above program in the background.

The third line records the process ID for the microphone, so we can kill it later if need be. Change name.pid to use the name you used for -j name.

Setting up audio routing: final mix

Onward to the mix. If you look at the output to the aplay -l or arecord -l commands, you should see the ALSA Loopback devices.

card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 0: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7

Audio played out to a subdevice of playback device hw:Loopback,1 will be available as audio input on the corresponding subdevice of recording device hw:Loopback,0. That is, playing to hw:Loopback,1,0 will result in recordable input on hw:Loopback,0,0. We take advantage of this to record our final mix to Audacity. Make a script called loopback.sh.

#!/bin/bash
alsa_out -j loop -c 3 -d hw:Loopback,1,0 &
echo $! > ~/.loop.pid

The -c 3 option in the second line determines how many channels the loopback device will have. You need one loopback channel for each microphone channel you wish to record separately. Lastly, we’ll want a script to stop all of our audio devices. Make a new script called stopdevices.sh.

kill `cat ~/.name.pid`
kill `cat ~/.name.pid`
kill `cat ~/.loop.pid`

Replace .name.pid with the filenames from your microphone scripts. Running this script will stop the JACK ALSA clients, removing your devices.

Managing JACK with QJackCtl

By default, AVLinux starts QJackCtl at startup. It’s a little applet which will show up with the title ‘JACK Audio Connection Kit’. What you want to do is hit the Setup button to open the settings dialog, then change Frames/Period and Periods/Buffer to 256 and 2, respectively. That yields an audio latency of 10.7 milliseconds, which is close enough to real-time for podcasting work.

That’s all you need to do with QJackCtl. You should also, however, pay attention to the numbers listed, at system start, as 0 (0). Those numbers will increase if you experience buffer overruns, sometimes called xruns. These occur when JACK is unable to process audio quickly enough to keep up in real time. Try using 256/3 or even 512/2, increasing the values until you get no xruns. (A very small number may be acceptable, but note that xruns will generally be audible in audio output as skips or crackles.)

Ensure QJackCtl is running before starting Ardour. Also, connect your microphones and run your microphone scripts.

Mixing with Ardour

Ardour is a free, open-source digital audio workstation application. It is ridiculously full-featured, and could easily do everything needed for a podcast and more. Since we have an established workflow with Audacity as our final editing tool, we use Ardour as a mixing board. In the Crossbox studio, Ardour takes input from two (or more) microphones whose input arrives through JACK, evens out recording levels, and runs output to a single JACK device corresponding to the ALSA loopback device. We then record the ALSA loopback device, which has a separate channel for each microphone we’re recording11.

How do we set Ardour to do this? It turns out that it’s complicated. Start Ardour and make a new session. (Since we’re using Ardour as a mixing board rather than a recording tool, we’ll reuse this session every time we want to record something.) For each microphone, make a new track. (That’s Shift+Ctrl+N, or Tracks->Add a new track or bus.)

Once you’ve done that, select the ‘Mixer’ button on the top bar. You should see a column for each of your tracks. You can use these to adjust volumes individually; you can also apply plugins or filters to each one.

Open up the Audio Connections window (under the Window menu, or by hitting Alt-P). We’ll want to do three things here.

Connect microphones to tracks

On the left side of the Audio Connections window, select Other as the source. (All devices which use the alsa_in and alsa_out JACK devices show up in the Other tab.) On the bottom of the Audio Connections window, select Ardour Tracks as the destination.

Connect each microphone to its track by clicking on the cell where its row and column intersect. You’ll see a green dot show up. Now the microphones are connected to Ardour tracks, and we don’t need to worry about microphone hardware anymore.

Connect microphone tracks to loopback device

Select Ardour Tracks as the source and Other as the destination. Connect each microphone track to one channel of the loopback device. (If recording in stereo, each microphone track channel needs its own loopback channel. If recording in mono, connect the left and right channels from one microphone to one loopback channel.)

Audio from the microphone tracks will now be routed to the ALSA loopback device, where we can record it with Audacity.

Connect microphone tracks to Ardour monitor bus

Select Ardour Tracks as the source and Ardour Busses as the destination. Connect each microphone to the Master bus. (Whether recording in stereo or mono, connect the left channel of each track to the Master left channel, and the right channel of each track to the Master right channel.)

By default, Ardour connects the Master bus to the system audio output. When you connect your microphone tracks to the Master bus, you should be able to hear yourself in headphones attached to your headphone jack. If you’re connecting more than two sets of headphones, you may need to get yourself an amplifier. This one seems nice enough. If you don’t have 1/4-inch headphones, you can use these converters.

Recording with Audacity

One more piece to the puzzle. Open Audacity. Select ALSA as the sound framework. Select the Loopback: PCM(hw:0,0) device. When recording, audio from one microphone should show up in each Audacity channel.

Adjusting hardware volumes

In AVLinux, you can use the applications Volti or Audio Mixer to provide a GUI to adjust hardware volumes. Volti is a tray volume control; right-click on it to get a view of the mixer. In either tool, to adjust the input volume of a microphone, select it (either in the dropdown or the tab bar) and adjust its mic level. To adjust the monitor output volume, adjust the output volume for your built-in soundcard. To adjust the recording output volume, adjust the volumes for the Loopback device.

Podcast recording shopping list

And that’s that. You now have all the information you need to replicate our studio setup. Please feel free to leave questions in the comments; I’m not much good at this sort of thing, but I may be able to point you to someone who can help you out. Below, I’ve included a shopping list for your perusal.

Buy one

Per person (non-microphone)

Per person (condensers)

Per person (XLR dynamic mics)

XLR connections are the industry standard for microphones. If you’re planning to expand to a true mixing board, you’re probably best off getting XLR mics so you don’t have to buy new ones when you make the switch. On the other hand, you’ll need an XLR-to-USB interface for each microphone to connect it to your computer, which pushes the price up somewhat.

Per person (USB dynamic mics)

If, like the Crossbox, you’re unlikely ever to proceed past two hosts with USB microphones, you should look into USB dynamic microphones. Like the USB condenser microphones above, they plug directly into a computer, doing the digitization internally. They are, however, less future-proof.

Cost breakdown

  • USB dynamic microphone: $30
  • Shock mount: $10
  • Mic boom: $9
  • Pop filter: $8
  • Total: $57
  1. Okay, my. ↩
  2. That’s me. ↩
  3. We, however, clamp our mic booms to spare chairs at our broadcast table. This means we can bump the table without jostling the mount, which makes for much cleaner recordings given our typical amount of movement. ↩
  4. P, B, T, S, Z, etc. ↩
  5. I realize this pushes the price well above $70 per person, but I figure it’s reasonable to assume you probably have a laptop of acceptable specifications. ↩
  6. Yes, it’s possible to do low-latency monitoring and USB microphone resampling/synchronization with Windows and ASIO, or your Linux distribution of choice with a low-latency kernel, but (at least in the latter case) why on earth would you want to? ↩
  7. If this paragraph made no sense to you, try this how-to guide. In the partitioning step, you may have to choose your current partition and select ‘resize’, shrinking it to make a little bit of room for AV Linux. ↩
  8. For the uninitiated, it means that JACK is always able to take CPU time whenever it needs it with no waiting. ↩
  9. Or, if you like, call it something else. Makes no difference to me. ↩
  10. The recommended CAD U37 is a mono mic, but has stereo output. We run it with mono input. ↩
  11. The astute reader will note that this may impose a limit on the number of simultaneous channels you can record. That reader, being more astute than me, could probably tell you how many channels that is. I figure it’s at least eight, since ALSA supports 7.1 output. If you need more than eight, you should probably look into recording directly in Ardour. ↩

Tesla Motors: Ignoring Facts of Human-Machine Interaction Since 2014

Posted by

Okay, I’ve had about enough of Tesla’s zombie legion of brainwashed fans reflexively and ignorantly defending them on autopilot grounds, so it’s time for a good old fashioned rant. I have two targets.

First: autopilot itself. Tesla’s autopilot is a nifty technological achievement. In its current state, though, it’s dangerous, and it disregards seventy years of research into how humans interact with machines. This book, on the specific topic of human reliability in transit systems, cites just over two hundred sources. In the world of trains, locomotive cabs usually feature a device called an alerter. If the driver doesn’t flip a switch or press a button every so often, the locomotive automatically stops.

The locomotive, actually, is a good analogue for the specific sort of cognitive load imposed by driving with an assisted cruise control system. If you read my Train Simulator review, you have some idea what I mean. For the benefit of you who did not read it, let me sum up.

Driving a car manually is a task with relatively evenly-distributed (low) difficulty. It takes constant attention to keep from hitting something or driving off the road. It may take more attention at times, but there’s a certain minimum cognitive load below which you can no longer drive a car. Sure, it’s no helicopter, but you do have to be paying at least a little bit of attention. This is materially different from driving a train or a semi-automatic car.

Piloting those two forms of transit requires so nearly zero input from the driver as to be indistinguishable therefrom. In both cases, the vehicle handles the moment-to-moment input required to keep itself from crashing into things1. The driver has no ongoing task to keep his mind focused. A quick sampling of Wikipedia articles on train crashes shows, broadly speaking, two sorts of accident which capture almost every incident: equipment failures causing derailment, and driver inattentiveness causing a train to run into another train2. In fact, the trend with trains is increasing computerization and automation, because—shocker—it turns out that humans are very bad at watching nothing happen with boring predictability for dozens or hundreds of hours, then leaping into action the moment something begins to go wrong. This article, by a self-proclaimed UI expert3 goes into great detail on the problem, using Google’s experience with testing self-driving cars as an example. The train industry knows it’s a problem, too, hence the use of the alerter system I mentioned earlier.

“Well then, you ought to love what Tesla is doing!” I hear you say. Don’t get me wrong, I think they’re making intriguing products4, and the technology which goes into even the limited autopilot available to Tesla drivers is amazing stuff. That said, there’s a twofold problem.

First, no self-driving system—not even Google’s more advanced fleet of research vehicles—is perfect. Nor will they ever be. Computerizing a train is trivial in comparison. There’s very little control to be done, and even less at the train itself. (Mostly, it happens at the switching and signaling level, and nowadays that’s done from a centralized control room.) There are very few instances driving a train where you can see an obstacle soon enough to stop before hitting it, and very few instances where it’s worth stopping to avoid hitting the thing you might hit. Again, though, hitting a deer with a train is materially different than hitting a deer with a luxury sedan. More generally, there’s a lot more to hit with a car, a lot more of it is dangerous, and it’s a lot more difficult to tell into which category—dangerous or no—a certain piece of stuff falls.

Second, there’s a problem with both driver alertness systems and marketing. To the first point, requiring that you have your hands on the wheel is not enough. There’s a reason a locomotive alerter system requires a conscious action every minute or so. Without that constant requirement for cognition, the system turns into another thing you just forget about. To the second, calling something which clearly does not drive the car automatically an ‘autopilot’ is the height of stupidity5. Which brings me to the second rant I mentioned at the start of the article.

Tesla fans.

You see, whenever anyone says, “Maybe Tesla shouldn’t call their assisted driving system Autopilot, because that means something which pilots automatically,” an enormous gaggle of geeks push their glasses up their noses and say, “Actually…”6

I’m going to stop you right there, strawman7 in a Tesla polo. If your argument starts with “Actually” and hinges on quibbling over the definition of words, it’s a bad argument. Tesla Autopilot is not an autopilot. “What about airplane autopilots?” you may ask. “Those are pilot assistance devices. They don’t fly the airplane from start to finish.” Precisely. The pilot still has lots to do8, even to the point of changing speeds and headings by hand at times. More to the point, it’s almost impossible to hit another plane with a plane unless you’re actively trying9. Not so with cars. Cars exist in an environment where the obstacles are thick and ever-present. A dozing pilot is usually a recipe for egg on his face and a stiff reprimand. A dozing driver is a recipe for someone dying.

I also sometimes hear Tesla fans (and owners) saying, in effect, “Just pay attention like I do.” The hubris there is incredible. No, you are not unlike the rest of the human race. You suffer from the same attention deficit when monitoring a process which mostly works but sometimes fails catastrophically as does the remainder of the human race. It is overwhelmingly more likely that you overestimate your own capability than that you’re some specially talented attention-payer.

To quote Lenin, “What is to be done?” Fortunately, we have seventy years of research on this sort of thing to dip into. If your system is going to require occasional human intervention by design, it has to require conscious action on the same time scale on which intervention will be required. Trains can get away with a button to push every minute because things happen so slowly. Planes have very little to hit and lots to do even when the plane is flying itself. Cars have neither luxury. To safely drive an Autopilot-equipped car, you have to be paying attention all the time. Therefore, you have to be doing something all the time.

I say that thing ought to be steering. I’m fine with adaptive speed, and I’m also fine with all kinds of driver aids. Lane-keeping assist? Shake the wheel and display a warning if I’m doing something wrong. Automatic emergency braking? By all means. These are things computers are good at, and which humans can’t do: seeing a specific set of circumstances and reacting faster than humans. Until the day when a car can drive me from my house to my office with no input from me—a day further away than most people think—the only safe way for me, or anyone, to drive is to be forced to pay attention.

Update 04/21/17
I’m not usually one to revisit already-posted articles, but this is just too much. In this Ars Technica comment, a Tesla owner describes “multiple uncommanded braking events” since the last software update. In the very same post, he calls his Tesla “the best car I’ve ever owned”.

If you needed further proof of the Tesla fan’s mindset, there it is.

  1. Whether by advanced computer systems and machine vision, or by the way flanged steel wheels on top of steel rails stay coupled in ordinary circumstances. ↩
  2. Sometimes, driver inattentiveness causes derailments, too, as when a driver fails to slow to the appropriate speed for a certain stretch of track. ↩
  3. I like his use of a topical top-level domain. We over here at .press salute you, sir! ↩
  4. Electric cars weren’t cool five years ago. Now they’re kind of cool10. ↩
  5. In a stroke of genius, Cadillac called a similar system ‘Super Cruise’. I’ll be frank with you: when a salesman is going down the list of options for your new Caddy, and he says, “Do you want to add Super Cruise?” your answer is definitely going to be, “Heck yes. What’s Super Cruise?” It just sounds that cool. Also, it has a better, though not quite ideal, solution to the driver attentiveness problem. There’s a little IR camera on the steering column which tracks your gaze and requires you to look at the road. ↩
  6. Yes, I realize that also describes me and this article. I also just fixed my glasses. ↩
  7. Never let it be said that our qualities do not include self-awareness and self-deprecation! ↩
  8. The occasional embarrassed dozing pilot story notwithstanding. ↩
  9. That’s why it’s always news on the exceedingly rare occasions when it happens, and frequently news when it doesn’t, but merely almost happens. ↩
  10. If poorly built, but Tesla say they’re working on that. ↩

How-To: Two USB Mics, One Computer, JACK, and Audacity

Posted by

This post is largely superseded by a new post on the same topic. The new post includes more step-by-step setup instructions for an audio-focused Linux distribution, tips for how to use digital audio workstation tools to manage multiple microphones, and hardware recommendations for podcasting use.

The Crossbox Podcast is going upmarket: I now have two USB microphones, and for the March episode, parvusimperator and I will each have one directly in front of us. This is a wonderful advance for audio quality, but it does pose some problems:

  1. Audacity, our usual recording tool of choice (and probably yours, if you ended up here), only supports recording from one source at once.
  2. Though other tools support recording from multiple sources, the minor variations in internal clocks between two USB microphones mean that each microphone has a sample rate which varies in a slightly different fashion, and that longer recordings will therefore be out of sync.

Modern Linux, fortunately, can help us out here. We have need of several components. First, obviously, we need two microphones. I have a Blue Snowball and a CAD Audio U37, with which I’ve tested this procedure1. Second, we need a computer with at least two USB ports. Third, we need the snd-aloop kernel module. (If your Linux has ALSA, you probably already have this.) Fourth, we need JACK, the Linux low-latency audio server. Fifth, we need the QJackCtl program.

Before I describe what we’re going to do, I ought to provide a quick refresher in Linux audio infrastructure. If you use Ubuntu or Mint, or most other common distributions, there are two layers to your system’s audio. Closest to the hardware is ALSA, the kernel-level Advanced Linux Sound Architecture. It handles interacting with your sound card, and provides an API to user-level applications. The most common user-level application is the PulseAudio server, which provides many of the capabilities you think of as part of your sound system, such as volume per application and the ‘sound’ control panel in your Linux flavor of choice. (Unless you don’t use Pulse.)

JACK is a low-latency audio server; that is, a user-level application in the same vein as Pulse. It has fewer easily accessible features, but allows us to do some fancy footwork in how we connect inputs to outputs.

Now that you have the background, here’s what we’re going to do to connect two mono USB microphones to one computer, then send them to one two-channel ALSA device, then record in Audacity. These instructions should work for any modern Linux flavor. Depending on the particulars of your system, you may even be able to set up real-time monitoring.

  1. Create an ALSA loopback device using the snd-aloop kernel module.
  2. Install JACK.
  3. Build QJackCtl, a little application used to control JACK. (This step is optional, but makes things much easier; I won’t be providing the how-to for using the command line.)
  4. Use JACK’s alsa_in and alsa_out clients to give JACK access to the microphones and the loopback device.
  5. Use QJackCtl to connect the devices so that we can record both microphones at once.

We’ll also look at some extended and improved uses, including some potential fixes for real-time monitoring.

Create an ALSA loopback device
The ALSA loopback device is a feature of the kernel module snd-aloop. All you need to do is # modprobe snd-aloop and you’re good to go. Verify that the loopback device is present by checking for it in the output of aplay -l.

The loopback device is very straightforward: any input to a certain loopback device will be available as output on a different loopback device. ALSA devices are named by a type string (such as ‘hw’), followed by a colon, then a name or number identifying the audio card, a comma, and the device number inside the card. Optionally, there may be another comma and a subdevice number. Let’s take a look at some examples.

  • hw:1,0: a hardware device, card ID 1, device ID 0.
  • hw:Loopback,1,3: a hardware device, card name Loopback, device ID 1, sub-device ID 3.

For the loopback device, anything input to device ID 1 and a given sub-device ID n (that is, hw:Loopback,1,n) will be available as output on hw:Loopback,0,n, and vice versa. This will be important later.

Install JACK
You should be able to find JACK in your package manager2, along with Jack Rack. In Ubuntu and derivatives, the package names are ‘jackd’ and ‘jack-rack’.

Build QJackCtl
QJackCtl is a Qt5 application. To build it, you’ll need qt5 and some assorted libraries and header packages. I run Linux Mint; this is the set I had to install.

  • qt5-qmake
  • qt5-default
  • qtbase5-dev
  • libjack-jack2-dev
  • libqt5x11extras5-dev
  • qttools5-dev-tools

Once you’ve installed those, unpack the QJackCtl archive in its own directory, and run ./configure and make in that directory. The output to configure will tell you if you can’t continue, and should offer some guidance on what you’re missing. Once you’ve successfully built the application, run make install as root.

Run QJackCtl
Run qjackctl from a terminal. We should take note of one feature in particular in the status window. With JACK stopped, you’ll notice a green zero, followed by another zero in parentheses, beneath the ‘Stopped’ label. This is the XRUN counter, which counts up whenever JACK doesn’t have time to finish a task inside its latency settings.

Speaking of, open the settings window. Front and center, you’ll see three settings: sample rate, frames per period, and periods per buffer. Taken together, these settings control latency. You’ll probably want to set the sample rate to 48000, 48 kHz; that’s the standard for USB microphones, and saves some CPU time. For the moment, set frames per period to 4096 and periods per buffer to 2. These are safe settings, in my experience. We’ll start there and (maybe) reduce latency later.

Close the settings window and press the ‘Start’ button in QJackCtl. After a moment or two, JACK will start. Verify that it’s running without generating any XRUN notifications. If it is generating XRUNs, skip down to here and try some of the latency-reduction tips, then come back when you’re done.

Use JACK’s alsa_in and alsa_out clients to let JACK access devices
Now we begin to put everything together. As you’ll recall, our goal is to take our two (mono) microphones and link them together into one ALSA device. We’ll first use the alsa_in client to create JACK devices for our two microphones. The alsa_in client solves problem #2 for us: its whole raison d’être is to allow us to use several ALSA devices at once which may differ in sample rate or clock drift.

Now, it’s time to plug in your microphones. Do so, and run arecord -l. You’ll see output something like this.

$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC295 Analog [ALC295 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Audio [CAD Audio], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: Snowball [Blue Snowball], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

This lists all the currently available capture hardware devices plugged into your system. Besides the first entry, the integrated microphone on my laptop, I have hw:1 or hw:Audio, the CAD Audio U37, and hw:2 or hw:Snowball, the Blue Snowball.

Next, set up alsa_in clients so JACK can access the microphones.

$ alsa_in -j snow -d hw:Snowball -c 1 -p 4096 -n 2 &
$ alsa_in -j cad -d hw:Audio -c 1 -p 4096 -n 2 &

Let’s go through the options. -j defines the label JACK will use for the microphone; make it something descriptive. -d declares which ALSA device JACK will open. -c declares the number of channels JACK will attempt to open.

On to the last two options: like the JACK settings above, -p defines the number of frames per period, and -n defines the number of periods per buffer. The documentation for alsa_in suggests that the total frames per buffer (frames per period multiplied by period) should be greater than or equal to JACK’s total frames per buffer.

Next, set up an alsa_out client for the ALSA loopback device.

$ alsa_out -j loop -d hw:Loopback,1,0 -p 4096 -n 2 &

The arguments here are the same as the arguments above.

Use QJackCtl to hook everything up
Now, we’re almost done. Go back to QJackCtl and open the Connect window. You should see a list of inputs on the left and a list of outputs on the right. Your inputs should include your two microphones, with the names you provided in your -j arguments. Your outputs should include system, which is linked to your system’s audio output, and an output named ‘loop’, the ALSA loopback device.

Assuming you have mono microphones, what you want to do is this: expand a microphone and highlight its input channel. Then, highlight the system output and hit ‘connect’ at the bottom of the window. This will connect the input channel to the left and right channels of your system audio output. At this point, you should be able to hear the microphone input through your system audio output. (I would recommend headphones.) The latency will be very high, but we’ll see about correcting that later.

If the audio output contains unexpected buzzing or clicking, your computer can’t keep up with the latency settings you have selected3. Skip ahead to the latency reduction settings. That said, your system should be able to keep up with the 4096/2 settings; they’re something of a worst-case scenario.

If the audio output is good, disconnect the microphones from the system output. Then, connect one microphone’s input to loop’s left channel, and one microphone input to loop’s right channel. Open Audacity, set the recording input to Loopback,04, and start recording. You should see audio from your microphones coming in on the left and right channel. Once you’re finished recording, you can split the stereo track into two mono tracks for individual editing, and there you have it: two USB microphones plugged directly into your computer, recording as one.

Recording more than two channels
Using Jack Rack, you can record as many channels as your hardware allows. Open Jack Rack, and using the ‘Channels’ menu item under the ‘Rack’ menu, set the number of channels you would like to record. In QJackCtl’s connections window, there will be a jackrack device with the appropriate number of I/O channels.

In Audacity, you can change the recording mode from ALSA to JACK, then select the jackrack device, setting the channel count to the correct number. When you record, you will record that many channels.

Jack Rack is, as the name suggests, an effects rack. You can download LADSPA plugins to apply various effects to your inputs and outputs. An amplifier, for instance, would give you volume control per input, which is useful in multi-microphone situations.

Reduce frames per period
If you’re satisfied with recording-only, or if you have some other means of monitoring, you can stop reading here. If, like me, you want to monitoring through your new Linux digital audio workstation, read on.

The first step is to start reducing the frames per period setting in JACK, and correspondingly in the alsa_in and alsa_out devices. If you can get down to 512 frames/2 periods without JACK xruns, you can probably call it a day. Note that Linux is a little casual with IRQ assignments and other latency-impacting decisions; what works one day may not work the next.

You can also try using lower frames per period settings, and higher periods per buffer settings, like 256/3 or 512/3. This may work for you, but didn’t work for me.

If you come to an acceptable monitoring latency, congratulations! You’re finished. If not, read on.


Fixing latency problems
Below, I provide three potential latency-reducing tactics, in increasing order of difficulty. At the bottom of the article, just above the footnotes, is an all-in-one solution which sacrifices a bit of convenience for a great deal of ease of use. My recommendation, if you’ve made it this far, is that you skip the three potential tactics and go to the one which definitely will work.

Further latency reduction: run JACK in realtime mode
If JACK is installed, run sudo dpkg-reconfigure -p high jackd (or dpkg-reconfigure as root).

Verify that this created or updated the /etc/security/limits.d/audio.conf file. It should have lines granting the audio group (@audio) permission to run programs at real-time priorities up to 95, and lock an unlimited amount of memory. Reboot, set JACK to use realtime mode in QJackCtl’s setup panel, and start JACK. Try reducing your latency settings again, and see what happens.

Further latency reduction: enable threaded IRQs
Threaded IRQs are a Linux kernel feature which help deliver interrupt requests5 more quickly. This may help reduce latency. Open /etc/default/grub. Inside the quotation marks at the end of the line which starts with GRUB_CMDLINE_LINUX_DEFAULT, add threadirqs, and reboot.

Further latency reduction: run a low-latency or real-time kernel
If none of these help, you might try running a low-latency kernel. You can attempt to compile and use low-latency or real-time kernels; the Ubuntu Studio project provides them, and there are packages available for Debian. If you’ve come this far, though, I’d recommend the…

All-of-the-above solution: run an audio-focused Linux distribution
AV Linux is a Linux distribution focused on audio and video production. As such, it already employs the three tactics given above. It also includes a large amount of preinstalled, free, open-source AV software. It isn’t a daily driver distribution; rather, its foremost purpose is to be an audio or video workstation. It worked perfectly for me out of the box, and met my real-time monitoring and audio playback requirements for The Crossbox Podcast6. I recommend it wholeheartedly.

Given that my laptop is not primarily a podcast production device, I decided to carve a little 32gb partition out of the space at the end of my Windows partition, and installed AV Linux there. It records to my main Linux data partition instead of to the partition to which it is installed, and seems perfectly happy with this arrangement.

So am I. Anyway, thanks for reading. I hope it helped!

  1. Two identical microphones actually makes it slightly (though not insurmountably) harder, since they end up with the same ALSA name. ↩
  2. If you don’t have a package manager, you ought to be smart enough to know where to look. ↩
  3. This is most likely not because of your CPU, but rather because your Linux kernel does not have sufficient low-latency features to manage moving audio at the speeds we need it to move. ↩
  4. Remember, since we’re outputting to Loopback,1, that audio will be available for recording on Loopback,0. ↩
  5. Interrupt requests, or IRQs, are mechanisms by which hardware can interrupt a running program to run a special program known as an interrupt handler. Hardware sends interrupt requests to indicate that something has happened. Running them on independent threads improves the throughput, since more than one can happen at once, and, since they can be run on CPU cores not currently occupied, they interrupt other programs (like JACK) less frequently. ↩
  6. Expect us to hit our news countdown time cues a little more exactly, going forward. ↩

Rampant speculation: why did the Falcon 9 blow up?

Posted by

I am not a rocket scientist, but I do like to think about engineering problems.

Here are the facts as we know them:

  • A Falcon 9 rocket blew up on the pad on September 1, 2016.
  • The rocket was undergoing a pre-launch static test, when it exploded.
  • According to SpaceX, the explosion originated in the second-stage liquid oxygen tank.
  • SpaceX uses a fancy super-cooled LOX mix, which allows more fuel in a given tank volume, which allows better performance.
  • Last summer, SpaceX had another rocket fail. The CRS-7 mission disintegrated in flight after the upper stage LOX tank burst. The internal helium tank (to maintain tank pressure) failed because of a faulty strut.

Now, for a rocket to fail during fueling, before engine firing—as the most recent Falcon failed—is very unusual. To my engineer’s mind, it suggests a materials problem in the LOX or liquid helium tanks, something failing in an unexpected way when deep-chilled. Crucially, the Falcon 9’s LOX tank experiences the coldest temperature (for a LOX tank) in the history of rocketry. Take that in combination with the failure on the CRS-7 mission: after their investigation, SpaceX switched to a new strut, which means new failure modes.

Mark my words (and feed them to me along with a heaping helping of crow, when I turn out to be wrong): this is another strut issue, be it faulty or just unsuited for the deep-cryo fuel in some other way.