Streaming input/output on the Raspberry Pi using Pure Data by urbanSTEW
Posted Nov. 21st, 2012
For a few months there has been a clear issue in executing simultaneous I/O using the Raspberry Pi and Pure Data. The basic problem was that you could get either input (using a USB interface) or output but not at the same time, nor in the same session. This is of course a major problem for anyone wanting use the low cost Pi for any substantial signal processing, especially using Pure Data. But here is a potential solution: use two Pies (sp?), one for input and one for output.
How do you do this?
1) You will need to install Pure Data Extended on both Pies. You can go to (http://puredata.info/downloads/pd-extended-rpi) for more information. On this distribution there are a pair of objects called [streamin~] and [streamout~]. Use these to stream the audio from the first pi to the second pi over a network.
2) Create a network between your two machines. To do this we had to create static IP addresses on each. Here is one way to do this (http://www.inforsom.com/www/2012/09/static-ip-raspberry-pi/). It involves changing the /etc/network/interfaces file.
3) Using the [streamout~] object, connect using the [streamin~] Pi’s IP address that you set earlier, set the port to any number (I used 3000). The [streamin~] Pi should have an argument of the port number on the other machine, e.g [streamin~ 3000]. The [streamin~] machine will just sit there and listen until the other sends it some data.
4) On the [streamout~] machine I used the following command line to properly load my USB audio device for input:
pd-extended -nogui -audiodev 3 -inchannels 2 -nodac -open /home/pi/file.pd
This is opening Pd extended without the GUI (runs much faster this way), so you need to make sure you use a [loadbang] with a [delay 150] and the message [; pd dsp 1(.
This waits a few milliseconds to make sure that the audio socket was connected before you turn it on. A very simple hack that I believe has been fixed in the most recent version of Pd-vanilla. The above statement also loads the USB device (-audiodev 3) as the input audio driver. If for some reason nothing is coming through the input or it is very quiet, you can try running the command line: alsamixer, this will open a simple driver program to check to see if the input is muted or very low.
5) We have also in the past had to use the command:
sudo amixer cset numid=3 1
to set the USB device as the default input. But I am not sure if you have to do this once, or at all. I can boot into the pi and just load the above pd-extended statement just fine without ever using this command.
6) If you are still having problems try to record some audio on the USB device without Pd, see (http://mutsuda.com/2012/09/07/raspberry-pi-into-an-audio-spying-device/). It uses arecord instead of pd.
7) Assuming you are connecting your two Pies with an ethernet cable then you should have streaming audio with little to no latency. I have included the Pd-extended patches here (pi2pi) if you want a quick template. NOTE: there is a 15s delay on the [streamout~] Pi so that I have time to disconnect it from my development computer and to the [streamin~] Pi. This is because I use a Mac with ssh to talk to both of my machines. You can change this how you like.
Some thoughts
You can also try the objects [netsend~] and [netreceive~] by Olaf Matthes, (http://www.nullmedium.de/dev/netsend~/). It was a bit of a challenge to get them to compile both on my Mac and on the Pi. We have tested these only once on the Pi and it seemed to work just fine and it gives you the option of multiple audio channels. Though my Mac would not talk to the Pi using [netsend~] for some reason. There are the GPIOs on the Pi which theoretically could be used for a line or mic input. I have not yet seen anyone developing for this, but if you have please send us a link.
The audio quality on the Pi seems decent but not spectacular. There are occasional clicks and crackles which seems to be universal at this point. The Pi is clearly not meant yet for high fidelity audio, but if you are in the business of building things that need robust audio capabilities then the Pi may be for you. We have also used Arduino and the BeagleBoard for audio. As you probably know the Arduino is limited in what it can do with audio, especially audio input. The BeagleBoard was a project that one of our members worked on and can only say that it was difficult and time-consuming. I have not personally used the BeagleBoard as of yet for anything, so I’m curious as to their capabilities.
Finally, the Pi has limited processing power (700MHZ, I think) so that means that what you program on a Mac or PC may not work exactly the same on the Pi. I have had to limit a few of my Pd patches in order for things to not crash. However, running in the -nogui mode seems much faster and more stable. The Pi is about as powerful as a Mac G3 was way back when so keep that in mind when developing.
Contact urbanSTEW: comments (_at_) urbanstew (_dot_) org
Contributors to this project:
Stjepan Rajko
Jessica Rajko
Lisa Tolentino
Casey Farina