Tag Archives: reference

What’s In a Bradley?

Let’s take a look at what’s in a Bradley, courtesy of Hunnicut’s excellent work on the vehicle. Some of the information below is a little old (it’s from back when the M60 was the US Army’s squad support weapon), so I’ll make estimates for more modern systems as appropriate.

–Equipment for Vehicle Subsystems–

  • Fuel: 175 gal.
  • Engine oil: 26 qt.
  • Ready 25mm rounds: 300
  • Stowed 25mm rounds: 600
  • Ready 7.62mm rounds: 800
  • Stowed 7.62mm rounds: 1,4001
  • Ready TOW missiles: 2 missiles
  • Stowed TOW missiles: 5 missiles (Or 3 TOW missiles + 2 Javelin missiles, see below)

–Equipment for Dismounts–

  • Stowed 7.62mm rounds: 2,2002
  • Stowed 5.56mm rounds: 5,3203
  • Stowed AT4 Rockets: 3 rockets
  • Stowed ATGMs: 0 or 2 Javelin missiles

Curiously, in the tables in Hunnicutt’s book, both AT4 and M72 LAWs are listed as carried. In the text he mentions that AT4s were carried instead of LAWs and stowage was altered accordingly. I’ve gone with the latter here. We can also see that the Bradley is absolutely loaded with ammo.


  1. In Hunnicut’s table, ammo for the coax M240C is noted separately from the ammo for the M60 that’s to be deployed with the squad. I have preserved the distinction here (See also note 2) 
  2. These might also be used in the coax gun, since they’re still linked 7.62x51mm. Alternatively, this space should hold about 3,300 rounds of 5.56mm belted ammo for M249s, which is the current squad automatic weapon of the US Army. 
  3. Originally these were separated out for the M239 Firing port weapon and the infantry’s M16s, but the M239s didn’t work very well, and later versions of the Bradley plated over the firing ports. In any case, the M16 and M239 use the same magazines, so I haven’t split the ammo out here like Hunicutt does. 

What Does a Puma Carry?

Here’s a list of stuff that a Puma carries, at least according to Tankograd’s wonderfully photo-laden book on the vehicle.

–Equipment for Vehicle Subsystems–

  • Fuel: 900 L
  • Ready 30mm ammo: 200 rounds
  • Stowed 30mm ammo: 161 rounds (in seven-round boxes)
  • Ready 5.56mm ammo: 1,000 rounds
  • Stowed 5.56mm ammo: 1,000 rounds
  • Ready ATGM: 2 missiles
  • Stowed ATGM: 0 missiles
  • Grenade Launcher, Ready Rounds: 12 76mm Grenades -OR- 24 40mm grenades

–Equipment for Dismounts–

  • Stowed 5.56mm ammo for dismounts: 1,500 rounds
  • Stowed 40mm grenades: 36 rounds
  • Stowed frag grenades: 30 grenades
  • Stowed smoke grenades: 7 grenades
  • Stowed signal rounds: 20 rounds
  • Stowed rockets: 4 Panzerfaust 3 rockets and 2 launchers
  • Stowed Water, 1.5 L bottles: 32 bottles

The Tankograd volume doesn’t make mention of how much of the 5.56mm ammo stowed for the dismounts is in magazines and how much is linked for the dismounts’ MG4. 1,500 rounds doesn’t seem like all that much for six men, but perhaps the Germans trust their supply. It’s nice that Tankograd notes how much water the Puma usually carries.

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

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. 

Armored Vehicle Fuel Capacities

I’ve found these to be quite hard to find on the net. All do not include supplementary drop tank options. Except where specified, variants have the same capacity of the original.

VehicleFuel (US Gal)Fuel (L)
M15051,907.6
M1 with UAAPU4501,703.4
Leopard 2317.01,200
Challenger 2420.61,592
Leclerc343.41,300
K2342.41,296
Namer369.81,400
Merkava IV369.81,400
T-72264.21,000
T-80B486.11,840
T-80U467.61,770
T-90317.01,200
T-14426.61,615
M2197745.7
CV9030/CV9035221.9840
SPz Puma237.8900
Boxer MRAV145.3550
BMP-1122.0462
BMP-2122.0460
BMP-3184.9700
M11380302.8
M113A195359.6
Stryker52.8200
BTR-8079.3300
BTR-9079.3300
M270163617.0
M109135511
2S1145.3550
Panzerhaubitze 2000264.21,000
K9 Thunder224.5850
Centauro137.4520

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

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. 

IFV Autocannon Ready Ammo Capacities

I mentioned this already in Bradley Planned Improvements, but it’s easier to find if it’s separated into a nice reference post. Also added information for the Stryker with Kongsberg MCT-30 unmanned turret.

IFVReady CapacityCaliber (mm)
M2A3 Bradley30025×137
M2 – 30 mm conversion18030×173
Stryker with MCT-3015030×173
CV90402440x364R
CV903016030×173
CV90357035×228
Puma20030×173
K2122440x364R
BMP-250030×165
BMP-350030×165
T-15/Epoch turret50030×165

Some notes on the above:

  1. I’m defining “Ready rounds” as “rounds from which you can fire without manual loading”, since these are autocannons. So the CV9040 gets the quick-access rounds counted as ‘stowage’, because someone has to grab them and refill the 24-round ready feed system (three eight-round racks).
  2. The K21 gets credit for 224 rounds because the 200 rounds it has under the turret basket are connected to the gun via an automatic resupply system. No manual top-off required.
  3. Russian IFVs do not have any additional autocannon rounds stored separately in a non-ready condition. I.e. ready capacity is all you get.
  4. The “Bradley 30 mm Conversion” listed uses the existing 2-man turret suitably modified to accept the new gun and ammo. There’s also images of a Bradley with the turret crew moved to the hull and what appears to be an MCT-30 unmanned turret mounted in place of the original turret. It will match the Stryker/MCT-30 for ready ammo capacity.

T-14 Armata fluid capacities

Kind of a short, oddball post here, but I thought it might be of use/interest to someone. Also, it’s probably easier for me to find it if it’s here. I stumbled upon a translated excerpt of the T-14’s manual, and here are the capacities for the fuel/oil/cooling systems:

Fuel System
Internal (under the armor) tanks: 860 L
External (outside armor): 755 L
Total nominal fuel capacity: 1,615 L

Like most Russian tanks, the Armata can mount a pair of 200 L drums on brackets aft. Therefore:
Fuel capacity with supplemental tanks: 2,015 L

Engine oil tank capacity: 80 L

Cooling system capacity: 125 L
(including heat exchangers)

Transmission hydraulic fluid capacity: 90 L

Gearbox hydraulic capacity: 20 L