[PD] question about audio I/O with Pd for live WFS system

Pierre-Olivier Boulant po.boulant at free.fr
Tue Jan 3 12:43:23 CET 2017


Hello everyone,


I am in the process of building a wave field synthesis (WFS) system for 
live sound. I hate hearing wireless microphones come out of a wall of 
sound and to have bad seats as soon you're off the PA's center when the 
speakers are too far apart. These are things that were limited by the 
available processing at the time of analogue consoles. Now with 
off-the-shelf computing power it's possible to consider real time delay 
matrices to address this.
So far I was doing this on the digital consoles with low track counts, 
but I would like to expand to more I/O.
I'm happy to discuss this with anybody interested in this.

I've started prototyping in Pd with the interface running on Lemur to 
have multitouch control over several sources at a time.
Depending on the whole latency and stability it may stay as it is in Pd 
or I may look into a more dedicated hardware. I would love to have it 
running on some FPGA but the coding tools are quite expensive and the 
licensing is *very* closed source and I would like to avoid this. ;)
I'll post stuff when I have something I'm happy with. Currently There 
are quite a few things left on my to do list.


I'm trying to minimize latency as much as possible since I'm aiming for 
a live setup. I'm planning on getting some hardware to move from testing 
with recorded material to live sources. 6 to 8ms round trip would be 
great with 32 > 16~20 channels.
Since I don't have access to the different options to test, I would have 
to get myself one. So I'd like to get it right in the first place! ;)
There are things I can try and measure on the hardware I have at hand, 
but I would gladly hear how all this works and if you have any 
experience with large I/O counts.

I have MADI I/O (coax) on my sound desk. I'm thinking of getting a MADI 
sound card, probably RME. Now I have to figure which sort is best for my 
application.


My first question is not directly related to Pd: USB vs PCIe?
It seems like the USB bus adds some latency. I've read somewhere you 
have 6ms each way on top of the driver and program latency. Is this 
correct? Is this something that proprietary drivers solve, or is it 
something impossible to shrink so they don't mention it?
I'll try and measure this on my Babyface USB sound card.
If so, this would mean building a rack mount computer, the added benefit 
is that there are much faster CPUs on this sort of rig.
then I have to figure out whether a fast quad core with 2 memory 
channels is better than a slightly slower 6/8 core with 4 memory 
channels is favourable to work with this number of delay lines (max 32 x 
20 [delread4~] ).


Where I'm a bit uncertain is with the different settings in Pd.
There is the block size; I understand the concept and "realtime" is 
limited firstly by this value. No problem there.
Then there is "latency". I understand it's the time it takes to process.
My question is how are the two related? Do they add to each other? Or 
does the latency setting cover the filling up of the input block?
In numbers: if block: 96samples @96kHz (ie. 1ms) and latency: 5ms
then the total latency for Pd is 5 / 6 / 7 ms?


An other thing, as I understand [pd~] adds some latency. How much? 1 or 
2 blocks, an other "latency"'s worth?


A different approach I was considering for large systems where I would 
have more inputs than outputs, would be to breakdown the inputs into 
bunches of 8 or 10. Send each lot to be processed in a separate instance 
of Pd and come out on different outputs that would be grouped back 
together on the mixer of the sound card (ie. RME's Totalmix) which has 
very low processing time. In other words I would have inputs 1 to 10  
and outputs 1 to 16 on instance A and inputs 11 to 20 and outputs 17 to 
32 on instance B. Then adding on the sound card output 1 to 17, 2 to 18 
and so forth. The sound desk would only see 16 outputs coming back.
In instance B, would I need to have [adc~ 11 12 ... 20] and 20 inputs in 
the audio settings ; [dac~ 17 18 ... 32] and 32 outputs in the audio 
settings or is there a way to specify in the audio prefs in Pd what 
channels you want to use and have less I/O in the audio settings?
The real question would be: does setting up in the audio preferences 
more channels than actually used in the instance affect performance?


Thanks a lot for your time.
Cheers
Pierre-Olivier




More information about the Pd-list mailing list