So you're in a band that wants to put out a recording of a live concert, but you don't want to settle for what your old, secondhand analog 4 track recorder will give you. Like any other small-time band, you want to get the biggest bang for the buck and you don't have a lot of money to put people in the sound booth. Quite the opposite, the guy in the sound booth is a close personal friend and does it for free.
This situation is surprisingly common when you stop to consider that a band could realistically produce a new CD every three months if they record their concerts. The existence of numerous on-demand CD burning and merchandising providers gives bands a way to actually sell the CDs they've produced. While a studio recording takes a great deal of time, capturing the live sound of the band is a different enough animal that it's very much an achievable goal for the group of starving musicians, and only takes as much time as the concert played and the mastering stage. Unlike many such solutions, this isn't a case of "Find a problem to solve with Linux", this is a case of "Linux provides the best tools for the job".
Let's do this by the Bonsai Method. That is, I'll describe what the tree looks like, and then we'll cut, snip, and shape until it looks as I've described. First, imagine a small box with a handle on the top, easy to carry, sturdy, and contains all the hard drive space and processing power needed to record 8 tracks of sound simultaneously. This small, sturdy box is built out of commodity pieces and was surprisingly affordable. A small LCD display, 14-17 inches, requires a quick connect to become usable. A wireless keyboard and mouse provide user input to the box. I'll plug in a simple cable to the box that will provide the 8 input tracks of sound.
Do you have it in your mind's eye, now? It's pretty clear that I'll be getting the cheapest, sturdiest wireless mouse + keyboard combination. I'll be checking out bluetooth support and peripherals, hopefully I can get the monitor to hook up with a bluetooth interface. If not, I'll settle with having to plug in the LCD monitor at each show. What's another plug in a forest of plugs and cables, right? I'll go with a small form factor case that will likely only have one PCI slot for expansion. There are a whole plethora of small form factor barebones systems ranging in price from about $150 USD and up, with the more impressive systems coming in at about $500 USD worth of damage to your checkbook. I don't need big and bad. In fact, what I need is a pretty quick processor, fast memory and a lot of it, and blazing fast hard drives. I don't really need a CD-ROM, I can do my mastering on another machine. I just need to be able to get 8 tracks of audio about an hour's worth at a time, without losing any samples in the recording. And I'd like to grab those tracks at a sampling rate of 98khz and catch them as 32-bit floating point samples, if possible. I'll settle with the industry-standard 24-bit integer samples if I have to.
So what I'm going to be using looks something like this. The CPU is a premium processor, such as an Athlon or a Pentium. So I've picked up a pretty quick front bus. I'll try to max out the memory, but if not I'll place a minimum of half a gig, or 512MB of RAM. I'm willing to drop that to 256 if my budget requires, but no lower. I want at least two hard drives. I'll put each on a different IDE controller, which will keep the number of tracks I can have up and reduce the IDE bottleneck. More than likely it'll be a low-dollar box that I drilled my own holes to screw in the handle. Network, video, what I'll call playback audio (onboard sound), and pretty much everything else needed to run the machine will be on the motherboard. Remember, it's a small form factor. And that's fine, it's not like I need to play any fancy 3d games or anything. This box's purpose is to record 8 tracks at once, and that's it.
At this point, I haven't had any trouble dealing with kernel support for any of my hardware. It all uses standard interfaces and everything just works when installed. Multitrack sound capturing devices are a different story, however. Some of them are hit and miss with Linux, some just plain don't work. Many do work, thanks to the hard work of the ALSA boys and various contributors.
So you have a few choices with your sound hardware. You can get a PCI card with ADAT connectors that accepts input from a digital mixer. You'll have to acquire a digital mixer if you don't have one already. You can get a PCI card that comes with a huge box that typically takes analog input and then connects to the PCI card through a proprietary connector. Or you can explore some of the more esoteric options which include boxes that plug in to your USB port, and boxes that just work through a FireWire connection. I'll briefly discuss each of these below.
Separate mixer with ADAT connectors to PCI sound card
This is my preferred hardware setup because of it's modularity. When, not if, a piece breaks, I can replace it using any replacement part I can afford that has the interfaces needed. It's comparable in price to the other solutions, and going with used equipment brings it to a very affordable option. The digital mixer, if you don't have one already, will likely seamlessly replace an existing mixer in your rig, requiring no changes to your existing rig, only the edition of the computer.
There are two main manufacturers of multi-track PCI cards that use ADAT interfaces to get their input: RME and Terratec. Of the two, most cards each one of them makes are well-supported by ALSA, and therefore the kernel. Some models are not. For RME, you should be safe to get any card with the "Hammerfall" badge on it. For Terratec, the EWS88 and above should suffice. Always make sure to check the ALSA compatibility page! Furthermore, Terratec no longer makes new multi-track PCI cards that would serve the purpose, so if you're looking for brand new cards, Terratec isn't even an option.
If you go this route you'll be looking to put a mic for each instrument, two audience mics, and two stage mics. Naturally you'll need to combine as needed to make it fit 8 tracks, depending on the size of the band itself. You could later expand to 16 tracks and possibly pick up better drum coverage (mic the kick drum, then put two mics on the top of the set), better vocal coverage (how many backup vocalists do you have?), and more audience mics.
PCI Card + rack unit
The PCI Card + rack unit combination is a surprisingly affordable option. Again, if you go used you might be able to get away with paying a small amount of money. The rack unit fits into a rack, so if you have such a beast in your live rig it'll fit right in. The only limitation I have with this setup is that frequently the accompanying rack unit will only accept analog signals, preferring to replace a mixer in your rig. This is likely to require some additional work on your part to integrate it into your rig. Still, as a solution it can be surprisingly affordable, and portable.
If you go this route, it's probably better to try using a regular stage mic system to record the band rather than capturing each instrument on a track. With such a system you'd still grab the bass and vocals on their own track, but you could get away with only four tracks here.
There are a few manufacturers in this area that are particularly of note. Midiman makes the Delta series of sound cards. The Delta cards give you a box to plug in analog 1/4" phono connectors, ranging from 4 to 8 tracks, depending on the card. At the high end of the line you'll find the Delta 1010, which is a rack-mounted system capable of expansion to 32 tracks. Sonorous offers the Studi/o system claiming Linux support, but the ALSA's hardware compatibility page disagrees.
If you go this route, you'll be looking to mic the bass and the lead singer directly. Then you'll want to place two stage mics to capture the left- and right-hand portions of the stage. Two opposite-facing audience mics should fit in there as well, for a total of 6 tracks. Additional tracks should go on instruments that will need boosting in the mastering stage, such as additional vocalists, flute, and so forth.
Others (USB, FireWire, etc)
I generally reject anything that doesn't go on the PCI bus because of the latency issues. Also, the PCI bus is still the fastest and most reliable bus available for the amount of data we're moving. Nevertheless, some one or more of you readers are going to note that I didn't spend any time talking about USB or FireWire options and you'll be quick to point out your pet USB device that solves this problem for you. And you'll follow it up with the wonderful kernel support for these devices we have. That's wonderful. In fact, for just capturing sound, latency isn't that big of a deal. If you find a USB or other solution that's more affordable than a PCI-based solution and will enjoy the same level of reliability, more power to you. They are out there, and it may very well be worth your time to look deeper into the subject.
You'll use your preferred distribution, of course. I recommend running in a terminal with no fancy desktop environment, X Windows, or any of that unnecessary stuff. You're not doing WYSIWYG digital audio processing here, you're just doing sound capture. You need all the memory you can get, 8 tracks at 98k 32 bit samples each second is going to need a lot of RAM, and a lot of throughput in the entire system. For sound capture, only ecasound will satisfy for this job. Now, if you went and built a $3,000 computer with four processors, 6 hard drives, and 20GB of RAM, then yeah, you can go ahead and run KDE or whatever you'd like, and run Ardour or Audacity to record the show. The rest of us that don't have rich parents are going to use ecasound in a console and like it.
The way ecasound works you're probably going to want to build a custom bash script to run the show. Like I mentioned previously, I'd put two hard drives in this box on separate IDE controllers. That'll give me better performance for each hard drive, and I'll put half of my tracks on a partition on one, and the other half on a partition on the other. After the show I want each track backed up immediately, compressing with FLAC if space on the hard drive is a premium. Then I want the tracks moved and compressed to a temporary location where they'll be transferred to my mastering machine. If I were going to do the mastering with the recording computer, I would still move the tracks to a working location specified at invocation, so that immediately after every show the computer makes itself ready to record another show automatically. To achieve this level of automation, you might do something like this:
# start ecasound interactively
ecasound -s:~/show.cs -c
# now move the tracks to a work directory
mv /show/lefttracks/* work/
mv /show/righttracks/* work/
So what we're left to do is write the show.cs file. The show.cs file is an ecasound chainsetup file. In this file we'll describe the audio chains we want to setup. In the future we'll use this file to make any changes needed so we don't have to deal with correcting the bash script that powers the recording.
-a:1 -i:alsa,plughw:1 -o:/show/lefttracks/audience1.wav
-a:2 -i:alsa,plughw:2 -o:/show/lefttracks/wholeband1.wav
-a:3 -i:alsa,plughw:3 -o:/show/lefttracks/bass.wav
-a:4 -i:alsa,plughw:4 -o:/show/lefttracks/kick.wav
-a:5 -i:alsa,plughw:5 -o:/show/righttracks/audience2.wav
-a:6 -i:alsa,plughw:6 -o:/show/righttracks/singer.wav
-a:7 -i:alsa,plughw:7 -o:/show/righttracks/wholeband2.wav
-a:8 -i:alsa,plughw:8 -o:/show/righttracks/backingvocals.wav
The first line sets up the number of bits for each sample, number of tracks, and sampling rate. Then each line afterwards specifies where each input shall go. As you can see I placed each track in a top-level directory called "show" and split it into two subdirectories, "lefttracks" and "righttracks". The fstab for these two entries might look like:
/dev/hda5 /show/lefttracks ext3 defaults 1 2
/dev/hdc1 /show/righttracks ext3 defaults 1 2
As you can see, each hard drive is the master on its own IDE controller. If you get a motherboard with two PCI slots, you might consider sliding in an IDE card and throwing a couple of extra hard drives in there.
After it's all said and done, you still have to master your recording, right? As a great friend once told me, the reason you mic'd the whole band and then also mic'd the bass, the singer, and the kick drum was because those are the three signals usually lost. In a perfect world, you wouldn't have a chainsetup terminating in "wholeband2.wav". Instead, you'd have each individual instrument and each individual singer mic'd and a couple of audience mics. You might still mic the wholeband, if you have enough tracks to do so, and then you'd mix them in as filler tracks.
So you master it by tweaking each level, possibly applying effects (the listener won't be in the concert hall in which it was recorded), possibly overdubbing some corrections or even restoring the backing vocals by overdubbing them in the studio. When you've finished mastering, you grab a photo of the band on stage that night, a photo of the audience, toss a logo onto both, and start shipping.