I spent quite a bit of time yesterday and today looking at how to get audio between machines on a network in PD, so I wanted to share what I found in the hopes that it saves someone else some time.
For reference i'm on OSX 10.9.4, using PD-extended 0.43.4
There are several objects that claim to be able to do this. It wasn't clear to me which (if any) of them are maintained, and most of them don't seem to be currently working on my system.
*udpsend~ / udpreceive~* I didn't at first think they were installed in my PD-extended install because I needed to add an [import mrpeach]. After doing all this looking around though it seems like this is the best and most supported option right now. I was hoping to be able to use one of the compressed options (mp3 or ogg) because latency isn't a huge deal for my application and I don't want to have to worry too much about bandwidth when running multiple channels (I need 5). Apparently these are the next generation of netsend~ / netreceive~.
*netsend~ / netreceive~* These seem to be newer (and derived from) the streamin~/streamout~ and streamin13~/streamout13 objects. They don't come with pd-extended but there are binaries (and source) available at http://www.nullmedium.de/dev/netsend~/. Unfortunately the OSX binaries are PPC and in a .sit archive, which belies their age. Building also required a couple tweaks to the makefile. Seemed to work well within my local machine, but I didn't get around to trying it across machines.
*streamout~ / streamin~* These seemed to work pretty well to send data, but when DSP is on the streamin~ patch window was totally frozen and unresponsive.
*streamout13~ / streamin13~* PD crashed when I tried to instantiate a [streamout13~] object.
*mp3streamout~ / mp3streamin~* PD crashes if DSP is on while [mp3streamin~] is connected. Incidentally the backtrace indicates that the receiving side is segfaulting in liblame trying to decode the header:
- frame #0: 0x080cf660 libmp3lame.0.dylib
decode_header + 304 frame #1: 0x081fbeea mp3streamin~.pd_darwinmp3streamin_recv + 242
*ogglive~* This doesn't seem to be supported for a long while. I tracked down the source and built it, but couldn't get it to work. After sending the connect message to one of the [ogglive~] instances to connect it to the other, the server object still reported no clients connected. It also often crashed PD when deleting one of the instances.
*pd-iemrtp* I didn't get around to trying this one. It seems more recent than the others but is also more complex to use
peace, s
Have you also tried using netjack2 ?
On 10/12/2014 06:03 AM, Spencer Russell wrote:
I spent quite a bit of time yesterday and today looking at how to get audio between machines on a network in PD, so I wanted to share what I found in the hopes that it saves someone else some time.
For reference i'm on OSX 10.9.4, using PD-extended 0.43.4
There are several objects that claim to be able to do this. It wasn't clear to me which (if any) of them are maintained, and most of them don't seem to be currently working on my system.
*udpsend~ / udpreceive~* I didn't at first think they were installed in my PD-extended install because I needed to add an [import mrpeach]. After doing all this looking around though it seems like this is the best and most supported option right now. I was hoping to be able to use one of the compressed options (mp3 or ogg) because latency isn't a huge deal for my application and I don't want to have to worry too much about bandwidth when running multiple channels (I need 5). Apparently these are the next generation of netsend~ / netreceive~.
*netsend~ / netreceive~* These seem to be newer (and derived from) the streamin~/streamout~ and streamin13~/streamout13 objects. They don't come with pd-extended but there are binaries (and source) available at http://www.nullmedium.de/dev/netsend~/. Unfortunately the OSX binaries are PPC and in a .sit archive, which belies their age. Building also required a couple tweaks to the makefile. Seemed to work well within my local machine, but I didn't get around to trying it across machines.
*streamout~ / streamin~* These seemed to work pretty well to send data, but when DSP is on the streamin~ patch window was totally frozen and unresponsive.
*streamout13~ / streamin13~* PD crashed when I tried to instantiate a [streamout13~] object.
*mp3streamout~ / mp3streamin~* PD crashes if DSP is on while [mp3streamin~] is connected. Incidentally the backtrace indicates that the receiving side is segfaulting in liblame trying to decode the header:
- frame #0: 0x080cf660 libmp3lame.0.dylib
decode_header + 304 frame #1: 0x081fbeea mp3streamin~.pd_darwinmp3streamin_recv + 242*ogglive~* This doesn't seem to be supported for a long while. I tracked down the source and built it, but couldn't get it to work. After sending the connect message to one of the [ogglive~] instances to connect it to the other, the server object still reported no clients connected. It also often crashed PD when deleting one of the instances.
*pd-iemrtp* I didn't get around to trying this one. It seems more recent than the others but is also more complex to use
peace, s
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
haha
just ran this from server with broken pd
"ssh -fX bl@10.0.0.10 puredata"
this ran the puredata and output audio on the laptop with ip 10.0.0.10 but displayed the graphics on the server, probably not what you were looking for , but pretty neat still. was slow for me due to being connected through a wireless (across the street)range extender via eth0 on server and going directly to the neighbors wifi router on the laptop, fun fun.
-
Billy Stiltner -
Jan Baumgart -
Spencer Russell