On a Banana Pi Pro (spinoff of an older Raspberry Pi, with an Allwinner A20 SoC and tons of on-chip peripherals), I used arecord to capture each mic individually during a live sound gig:



# When the hard drive is mounted correctly, it blocks this locally-stored file
if [ -e "$REC_PATH/No Hard Drive Attached.txt" ]    # -e for file exists
    echo No Hard Drive. Not recording.
    exit 1

# Figure out where to record to
while [ -d "$REC_PATH/$COUNT" ]    # -d for directory exists
mkdir "$REC_PATH"

# Start recording
echo Recording to "$REC_PATH"
arecord --device=hw:CARD=X18XR18,DEV=0 --channels=18 --file-type=wav --format=S32_LE --rate=48000 --buffer-time=20000000 --max-file-time 300 "$REC_PATH/all_tracks.wav" &

# Force a filesystem sync every 1 second to keep the buffer small enough to write without missing samples
while true
    sleep 1
    echo sync $COUNT

This works, but it gives me an 18-track WAV file that has to be split at regular intervals to keep the file size within spec. (every 5 minutes per above, resulting in ~1GB per file...for a 4-hour show)

Thanks to this answer, I can post-process the mass of short 18-track files into the 18 full-length single-track files that I really want, but it leaves a slight pop at each splice. I'm guessing that since I'm working entirely with uncompressed data (no compression artifacts to mess up the first and last few milliseconds), the pop comes from arecord dropping samples while it closes one file and opens another.

Is there a tool that can record all 18 tracks seamlessly and continuously until killed (probably by shutdown now from an unrelated script), and end up with 18 full-length single-track WAV's on a second machine?

There are several ways that this could happen:

  1. Record the 18 WAV's directly and simultaneously, each receiving a mono stream from a different input channel of the same sound card. Then transfer the files directly to the other machine.

  2. Record to an intermediate, convertible format of any kind, then transfer to the other machine for conversion, or convert in-transit.

  3. Like #2, but completely take over the recording drive so as to use a specialized filesystem (if you can even call it that). A different sound system that I work with has a dedicated rack-mounted hard drive recorder that uses this method and converts in-transit via FTP. Unfortunately, the portable system that I'm building can't afford something that big, hence the Pi and this software request.

A few requirements:

  • If it requires a format conversion, allow that conversion to be on the destination machine or in-transit. Most of the time, the transfer will be overnight after a full day's worth of recording, and my priority in the moment is to free up some drive space for the next day. I'll have plenty of time later to do any conversions, but right now I just need to dump the drive.

  • Either the software itself or the script that calls it needs to figure out automatically how to make a new recording without clobbering any old ones. (there's no real-time clock and no internet on the recording machine, so the system date/time is useless) Let them pile up for a while, then transfer all or at least a bunch of them in one sitting. You can see above how I did it with arecord, but I'm not married to that method.

  • It needs to get along with mpd, which uses the playback channels of the same card.

  • It needs to choose the correct card, not the other one that's used by a live streaming daemon. This would probably require a command-line flag like arecord does.

  • It would also be nice to avoid the forever loop of explicit 1-second syncs at the end of my script.

I hope I'm not looking for a purple squirrel here.

  • If you have not yet looked at sox, the swiss-army knife of audio, then check it out. I don't know it well enough to advise you but it can split files, channels, change encoding, etc.
    – meuh
    Nov 22, 2016 at 14:16
  • @meuh Okay, I'm back to this now. Just had a few other things to catch up on. Anyway, according to this (sourceforge.net/p/sox/mailman/message/33233868), sox is also limited to a single output file with multiple tracks in it. (and after 11 months from that post, the manual is still not very good) I briefly thought about invoking something -X & 18 times, where X is a sequential channel number, but then I thought about synchronizing 18 independent tracks, assuming of course that having 18 independent recorders would even work at all.
    – AaronD
    Dec 4, 2016 at 5:11
  • As I read my previous comment a few days later, I think I need to clarify that my hesitance (and in fact the need) to sync the independent tracks in that scenario comes from the independent recorders starting at slightly different times, and so T=0 in each file would correspond to a slightly different time on the wall clock. There would need to be a clapboard or something something else that's known to be exactly simultaneous in all files so as to line them up again. A single instance that records all 18 simultaneously would (theoretically) not have this problem.
    – AaronD
    Dec 9, 2016 at 17:55
  • Another software solution you could look at is jack but, although very professional, it looks daunting to understand. There are many applications for it, some of which seem made for recording.
    – meuh
    Dec 9, 2016 at 18:39
  • @meuh I'm not entirely opposed to jack, but it seems like an unnecessary level of complexity for what I'm doing. (fixed-configuration, entirely automated recording) Also, everything in the apps list seems to be graphical with few exceptions. If I were running a DAW, I can see its usefulness, but I need this to be entirely automated, and thus command-line. meterec is one of those few CL programs for jack, and I might get to it in a few days. Lots of other stuff in the meantime to keep track of.
    – AaronD
    Dec 9, 2016 at 18:51


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.