If you listen back to our very first few shows and compare those with shows in the very 20s… you’ll know that we changed the way we record shows.
Early on, the show was recorded through separate Sony Playstation 4 gaming consoles using the chat/party feature and I would capture the combined audio of those in the party through my gaming headset.
Overall, the recordings weren’t bad. But there was a timing issue that you normally don’t notice when you’re playing a game in comparison to having comedic timing with your fellow podcast hosts.
The hunt for a better solution landed us at using Zencastr (zencastr.com). The VoIP delay is minimal in comparison to a PSN Chat/Party set up and using better mics than gaming headsets have proven to provide better sound quality. The overall sound quality at that point is what noises might happen in the background of each location that each host is recording from.
The Loot Box Podcast is recorded (at the time of writing this) by 3 co-hosts from 3 different locations. We span a fairly small distance of about 25 miles in southern Oregon. Each of us have different environmental sounds that add to the possible noise on the recording themselves. One of us is in a house with hardwood floors and two dogs that, if the inopportune time to need to go outside arises, will add the sound of nail clicking on hardwood floors and barking sounds during the recording. That same host has teenagers in the house who, as soon as the record button is clicked, will start yelling at each other about something silly. Otherwise, prior to clicking the record button, they sit in their bedrooms quietly working on homework. Another may have an occasional train go through town nearby and the other may have an occasional sound of gunfire echo in the background (not to worry, they are probably pretty safe. it’s been noted that it’s not really close, just really loud and far off in the the distance).
Anyway, the description of the host with the dogs and teenagers is me and that got me thinking I needed to find a quiet location to record which also means my recording set up needs to be portable.
Well, easy enough, I load up my MacBook Air, USB mic, mic stand and headphones and have a remote “studio” that I can record in and eliminate the dog nail clicking, barking and teenagers in the background.
In the pursuit to make my portable recording set up even more portable… enter the Raspberry Pi 3.
If you aren’t familiar with the Raspberry Pi or, like me for the passed 5 years, heard about “Raspberry Pi” but thinking it was too techie or too specialized in its use or application, it is a “credit card-sized computer originally designed for education. The original creator’s goal was to create a low-cost device that would improve programming skills and hardware understanding at the pre-university level. But thanks to its small size and accessible price, it was quickly adopted by tinkerers, makers, and electronics enthusiasts for projects that require more than a basic micro-controller. It is slower than a modern laptop or desktop but is still a complete Linux computer and can provide all the expected abilities that implies, at a low-power consumption level. *”
The Raspberry Pi 3 uses a Broadcom BCM2837 SoC with a 1.2 GHz 64-bit quad-core ARM Cortex-A53 processor, with 512 KB shared L2 cache. **
So… in other words, it’s a very small form factor computer that packs quite a punch in comparison to it’s size.
Without getting to deep into all things Raspberry Pi, I figured it must be able to work with Zencastr and my USB microphone, right? I am happy to say the answer is… YES! As a test, it was just my connection to Zencastr and it recorded as expected and worked just fine. I ran into a bit of trouble when the other co-hosts connected. Via the built-in VoIP, I couldn’t hear them, but they could hear me. There is also a “Local Browser Cache” that Chromium needs so that 2GB (or 10%) of that cache (20GB). On a 32GB mini-SD card, that shouldn’t be a problem. However, because of the way the “disk” is partitioned, Chromium “sees” a smaller bit of the 32GB, so Chromium alerts that there is low disk space available.
A simple redirect within the way Chromium is started allows an extra parameter to have that data file at a new location. Problem is, 28GB or so of the “disk” is set up and owned by root. I felt it was a big-time security risk logging in as root to access that space for Chromium while I was recording.
So instead, I created a location at /dev/root and changed the ownership of that location to the default user account. Then as the default user, I redirected Chromium to set the data file location to “/dev/root/newdirectory” and now, there’s no low-disk space alert.
This diagram shows a little about the set up. There is a small TFT display available for the Raspberry Pi that is also a touchscreen. This eliminates the need for a separate keyboard, mouse and monitor (although the text is really small on this small display… so I opted for a small bluetooth handheld keyboard instead). The Raspberry Pi 3 has built-in WiFi and my recording rig just became, simply, a USB microphone, pair of headphones and a Raspberry Pi 3.
I’ll add photos of the set up soon so you can see what it all looks like put together. I’ll also add an audio sample of a recording made with this set up.
It’s the silliest things that gets this nerd excited. 🙂