Raspberry Pi: An Update on Sound

Life has been a bit demanding lately, so it has been a while since I last worked on the Raspberry Pis. I had a notion that I might dragoon the Pis into serving as compute engines for a simulation I wrote in Python, and that got me motivated to get new Raspbian images and set up two Pis as headless units. It did not take long to disabuse me of the notion that the Pis represented a good alternative to workstation compute time: my simulation on the Pi ran at about 1/20th the speed it did on the workstation. So the simulation is running in background on the workstation, and I had two Pis hooked into the network, up and running.

So I spent a part of the weekend working on steps toward using a Pi as an acoustic monitoring platform. I bought two real-time clock (RTC) modules some time ago, so each of the Pis had one of those onboard. The critical piece of information I was missing in getting those running was that the process of establishing the Linux device corresponding to the I2C device had to be accomplished not merely using “sudo” in front of the command, but in a root-owned shell process because of redirection within the command. I found a web page that offered good advice, including putting the following lines into /etc/rc.local:

modprobe i2c-bcm2708

echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-0/new_device

modprobe rtc-ds1307

hwclock -s

When we last visited this topic, I had a USB sound device that could be recognized by the RasPi and that I could take recordings from. There was just one problem: the Pi would not stably reboot with the USB sound device plugged in. Given that my use case is going to be using the system as an instrument that will only be attended maybe every two weeks or so, that problem was a sufficient discouragement to have me doing other things for a few months.

It turns out that time helps. With the most recent Raspbian image, the reboot problem has gone away. Now, everything is not completely rosy. It turns out that I needed to restrict the USB ports to USB 1.1 speed in order to get a clean recording from the mic input. That likely would interfere with using either a USB keyboard or mouse, but I was already aiming at headless operation.

This clears the way for actually getting the system put together and readied for deployment. I need to write some code to handle periodic acoustic samples (cron launching a Python script seems good to me). Having code to connect to a server to upload status updates and/or data would be good; several of the platforms have some sort of Internet service. There’s a chunk to do for hardware. I need to find out exactly what the power supply situation is. I do already have a pair of 4A 5V UBECs. I need to do some testing, though, to make sure that the UBEC does not add a significant amount of noise to acoustic recordings. Since the UBEC is a switched power regulation device, it is quite possible that power-line noise could get into recorded signals. Some sort of housing is needed. And I need to fabricate the hydrophone (a piezo disk soldered to a coax cable with some waterproof potting to cover it) and pair it with an amplifier circuit. Whatever power the amplifier will need I’ll have to figure out, too. Some testing would be good. It would be ideal to find someone with a boat who thinks this sort of thing is cool. I think I have several weekends worth of project to keep me busy.