Hey all,
I'm with a group building an interactive sound sculpture that we are going to be taking to burning man. the premise is essentially interactively sending sampled and live sound sources through different pipes that we have arranged around a central "conductors" podium. I'll post a web page once we have this thing up and running.
Since we needed it to be cheap enough to justify sticking in the middle of a really dusty dessert where we will let drugged up strangers tinker with it unsupervised, we went the multiple cards approach instead of the multichannel pro-audio card. A friend of mine has setup the linux box and has the 4 sound cards working simultaneously. I just wanted to get a little pre-emptive advice from you guys so that once he drops the machine by i can have a test patch ready. :)
So my quesion is this: how do send audio to different sound devices from pd? I see in the "Test Audio and Midi" patch that you can send audio to different channels with [dac~ 2] or [dac~ 3] , so is this all i need to do in order to get it to work?
i did some archive searching and came up with this:
from IOhannes m zmoelnig about "pd-patch for (better) multidevice support"
http://iem.kug.ac.at/mailinglists/pd-list/2001-11/0316.html
Unfortunately right this moment i dont have a linux box to test on (until he drops it back here) so I wanted to ask what the status of using multiple devices in 0.35 test 24 ? I would rather use 0.35 since it is so much cooler that 0.34, have the issues that this patch was made for been addressed in mainline pd since then?
thanks for the help!
Josh .. Yoshi .. Joschi .. xiphoidprocess.com .. eds.org/~joschi
Hi, Josh Steiner hat gesagt: // Josh Steiner wrote:
So my quesion is this: how do send audio to different sound devices from pd? I see in the "Test Audio and Midi" patch that you can send audio to different channels with [dac~ 2] or [dac~ 3] , so is this all i need to do in order to get it to work?
This, and you have to start pd with a list of the soundout devices you want to use like
$ pd -soundoutdev 0,1
starting from 0 as usual.
i did some archive searching and came up with this:
from IOhannes m zmoelnig about "pd-patch for (better) multidevice support"
This is already included in PD 0.35 since at least test17.
I see another problem with your setup, and that is the hardware side. If you use several consumer soundcards without synchronization instead of a decent multichannel card, it might or probably will happen, that your audio will run out of sync. This means: the samples you send synchronized from the PD DSP-chain will come out of the four soundcards at different times, because each of the soundcards has a different understanding of absolute time because of slight differences in their clock chips.
Depending on the things you do, this might be nasty, *especially* if your installation is running for a long time, because your audio data will differ more the longer it can run out of sync. Maybe stopping audio in PD from time to time could help.
ciao,
Frank Barknecht _ ______footils.org__
This, and you have to start pd with a list of the soundout devices you want to use like
$ pd -soundoutdev 0,1
starting from 0 as usual.
i did some archive searching and came up with this:
from IOhannes m zmoelnig about "pd-patch for (better) multidevice support"
This is already included in PD 0.35 since at least test17.
cool, thanks.
I see another problem with your setup, and that is the hardware side. If you use several consumer soundcards without synchronization instead of a decent multichannel card, it might or probably will happen, that your audio will run out of sync. This means: the samples you send synchronized from the PD DSP-chain will come out of the four soundcards at different times, because each of the soundcards has a different understanding of absolute time because of slight differences in their clock chips.
i've read this in the archives. I'm not overly concerned since the sound design i've been working on has been of the ambient sound scape variety, so a little bit of drift will be fine. i am going to setup some test patches and let them run for long periods of time (eventually over a week) ... i'll keep you guys posted on how it goes.
Depending on the things you do, this might be nasty, *especially* if your installation is running for a long time, because your audio data will differ more the longer it can run out of sync. Maybe stopping audio in PD from time to time could help.
thats a good idea... if turning the dsp on and off occastionally manages to resync the cards, that could be worked into the piece ;-P
-Josh
Josh .. Yoshi .. Joschi .. xiphoidprocess.com .. eds.org/~joschi
I see another problem with your setup, and that is the hardware side. If you use several consumer soundcards without synchronization instead of a decent multichannel card, it might or probably will happen, that your audio will run out of sync. This means: the samples you send synchronized from the PD DSP-chain will come out of the four soundcards at different times, because each of the soundcards has a different understanding of absolute time because of slight differences in their clock chips.
i've read this in the archives. I'm not overly concerned since the sound design i've been working on has been of the ambient sound scape variety, so a little bit of drift will be fine. i am going to setup some test patches and let them run for long periods of time (eventually over a week) ... i'll keep you guys posted on how it goes.
Hmmm, i guess the problem will be that pd can't deal with the clocks running apart. I guess you will get clicks due to the fact that the 4 cards always get the signal vector at the same time.
greetings, Thomas
On Wed, 29 May 2002, Josh Steiner wrote:
Depending on the things you do, this might be nasty, *especially* if your installation is running for a long time, because your audio data will differ more the longer it can run out of sync. Maybe stopping audio in PD from time to time could help.
thats a good idea... if turning the dsp on and off occastionally manages to resync the cards, that could be worked into the piece ;-P
I think that the sound will never drift away more than a blocksize, so the nasty things that you will encounter are some clicks (the resyncing) when a deadline of one of the cards is missed.
That is your system will sync to the slowest card, the other ones will drop a buffer from time to time. Stopping and starting audio won't help, because you will never now when an underrun will happen, and anyhow it only mutes the output and doesn't do more.
The only solution for that is probably to make the clicks part of the installation :)
Guenter
That is your system will sync to the slowest card, the other ones will drop a buffer from time to time. Stopping and starting audio won't help, because you will never now when an underrun will happen, and anyhow it only mutes the output and doesn't do more.
The only solution for that is probably to make the clicks part of the installation :)
would using a separate pd instance for each card solve this problem?
-j
(btw, jon is working on this with us)
jon and i were talking about maybe having a separate instance of pd for each sound device synced up at the control level with netsend's ... it would be a lot more complex to design the patches, but if the clicking from sync errors is bad enough, is this even a route we can take?
-Josh
On Thu, 30 May 2002, Jonathan Nelson wrote:
That is your system will sync to the slowest card, the other ones will drop a buffer from time to time. Stopping and starting audio won't help, because you will never now when an underrun will happen, and anyhow it only mutes the output and doesn't do more.
The only solution for that is probably to make the clicks part of the installation :)
would using a separate pd instance for each card solve this problem?
-j
Josh .. Yoshi .. Joschi .. xiphoidprocess.com .. eds.org/~joschi
On Thu, 30 May 2002, Josh Steiner wrote:
(btw, jon is working on this with us)
jon and i were talking about maybe having a separate instance of pd for each sound device synced up at the control level with netsend's ... it would be a lot more complex to design the patches, but if the clicking from sync errors is bad enough, is this even a route we can take?
at least its worth a try ... and if you don't need tight timing , eg. spatialisation, then you might be ok with this approach.
Guenter
-
Frank Barknecht -
g�nter geiger -
Jonathan Nelson -
Josh Steiner -
Thomas Grill