Hi,
in a rather demanding setup I'm currently working on, I use two Pd instances: one for visuals with Gem, the other running with "-rt" for audio stuff. Both are connected through netsend/netreceive in UDP mode, all is happening on Linux.
I have to send quite a lot of data over this net connection (control data for audio generated from physical models and msd). Generally however this is no problem: If I run Pd using my laptop's internal soundcard all is fine. However I would like to use my USB soundcard instead, which is a Terratec Phase 26 with 2 channels in and 6 channels out.
Pd seems to be unable to handle this channel combination, so I started to use Jack. However now my troubles really begin: Somehow I'm not able to get this combination running stable. I run Jack realtime with -R and tried various values of -P to set jackd's priority: -P70 up to -P89. However with all of these, after some time the audio-Pd starts to run into a fight with the watchdog: signalling Pd to stop. The audio-Pd keeps running, however I get regular clicks in the audio stream. I *suspect* that this has something to do with the network data, like Pd is not keeping up with receiving the network stuff in time. Running the audio-Pd with "-noadc" helps a bit, but not for long.
So: Does anyone have any tips or tricks how to get a stable Pd in this situation? And should jackd run at a higher or at a lower priority than Pd?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
hi frank,
i really don't know if it will help you...
you need to be sure to use the last version of jack 0.100.0. also, i really recommand you to use the patched pam stuff to have realtime audio going on in linux. if you are using debian, you can follow the howto here it works on testing (etch):
http://www.ubuntustudio.com/wiki/index.php/Breezy:Rlimits-Aware_PAM
also, a good kernel with Ingo Molnar's realtime-preemption patch will help a lots.
http://www.ubuntustudio.com/wiki/index.php/Breezy:Vanilla_Kernel_With_Realti...
pat
Hallo, patrick hat gesagt: // patrick wrote:
i really don't know if it will help you...
you need to be sure to use the last version of jack 0.100.0. also, i really recommand you to use the patched pam stuff to have realtime audio going on in linux. if you are using debian, you can follow the howto here it works on testing (etch):
http://www.ubuntustudio.com/wiki/index.php/Breezy:Rlimits-Aware_PAM
Thanks for these hints. I checked my jack-version: I'm using 0.100 already. I also use the rlimits stuff. I'm not using the realtime preempttion patches, however I may add, that "normal" Pd patches that don't use the network-connection are running very stable and without xruns.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
"normal" Pd patches that don't use the network-connection are running very stable and without xruns.
-Without knowing what OS you're running, but have you looked at the amount of swap-space. Realtime needs a lot I/O space to be executed properly. For Unixes swap-space/virtual memory is quite important.
If you've taken this in consideration, forget about my mail.
AvS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
` |Schreck Ensemble . . . . . . . . . . . . . . . . . . . . +
` |# -laboratory for live electro-acoustic music- # |
| http://www.schreck.nl/ |
| http://www.xs4all.nl/~schreck/ |
` *===========================================================++
` |Compositions http://www.xs4all.nl/~schreck/html/compo.html |
` |Samples http://www.xs4all.nl/~schreck/html/samp.html |
` |Patches http://www.xs4all.nl/~schreck/html/pat.html |
` |Videos http://www.xs4all.nl/~schreck/html/video.html |
` |Scores http://www.xs4all.nl/~schreck/html/scores.html |
*===========================================================++
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
Hallo Frank, list!
preempttion patches, however I may add, that "normal" Pd patches that don't use the network-connection are running very stable and without xruns.
I only want to add, that I experienced a similar problem one month ago: I also made a gui-patch and a audio-patch and wanted to play them with 2 instances of pd, but it was not useable at all ... then I integrated them in one instance and it was no problem ... but I didn't figure out the problem unfortunately ...
LG Georg
hi frank
"Frank Barknecht" fbar@footils.org wrote:
however I may add, that "normal" Pd patches that don't use the network-connection are running very stable and without xruns.
i often noticed myself, that - when using audio and network stuff - the network stuff is the bottleneck, especially when sending a huge amount of data. i use more often [netclient]/[netreceive], which have a buffer of 4kB iirc, than [netsend]/[netreceive], but maybe it is the same issue with [netsend]. as far as i can tell, audio stucks as soon as the buffer is full. i assume the following is happening then: when the buffer of [netsend] is full and another object tries to send it a message, [netsend] won't accept the message, the object cannot execute its task and dsp-processing stops until the buffer of [netsend] gets free space. i didn't do any testing, but you could try to [drip] the datastream, so that you get a stream with a more constant bandwidth. i don't have an idea, how difficult this could be, but maybe compiling pd with a bigger buffer in [netsend] helps a bit also. all the above are only assumptions, but i would be very interested, if my suggestions will help, since i didn't do any serious testing myself.
good luck
roman
another issue came into my mind, that is somehow related to that and that supports my theory: i once experimented with [textfile] and using it to write into a fifo (is that the right name? i mean the one you create with 'mknod p filename'). as soon as i tried to write something with [textfile] into the fifo without opening the fifo first with 'cat fifo' for example, pd completely freezed until i executed the command 'cat fifo'.
roman
"Roman Haefeli" reduzierer@yahoo.de wrote:
hi frank
"Frank Barknecht" fbar@footils.org wrote:
however I may add, that "normal" Pd patches that don't use the network-connection are running very stable and without xruns.
i often noticed myself, that - when using audio and network stuff - the network stuff is the bottleneck, especially when sending a huge amount of data. i use more often [netclient]/[netreceive], which have a buffer of 4kB iirc, than [netsend]/[netreceive], but maybe it is the same issue with [netsend]. as far as i can tell, audio stucks as soon as the buffer is full. i assume the following is happening then: when the buffer of [netsend] is full and another object tries to send it a message, [netsend] won't accept the message, the object cannot execute its task and dsp-processing stops until the buffer of [netsend] gets free space. i didn't do any testing, but you could try to [drip] the datastream, so that you get a stream with a more constant bandwidth. i don't have an idea, how difficult this could be, but maybe compiling pd with a bigger buffer in [netsend] helps a bit also. all the above are only assumptions, but i would be very interested, if my suggestions will help, since i didn't do any serious testing myself.
good luck
roman
i often noticed myself, that - when using audio and network stuff - the network stuff is the bottleneck, especially when sending a huge amount of data. i use more often [netclient]/[netreceive], which have a buffer of 4kB iirc, than [netsend]/[netreceive]
would using OSC in a case like this make any difference?? I used to use [netsend/recieve] but now use OSC because of I find it scales better and its routing scheme. But in terms of bottlenecks and network load, has anyone tested OSC with enough data to begin to find its limits?
//Brad.
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
"Frank Barknecht" fbar@footils.org wrote:
however I may add, that "normal" Pd patches that don't use the network-connection are running very stable and without xruns.
i often noticed myself, that - when using audio and network stuff - the network stuff is the bottleneck, especially when sending a huge amount of data. i use more often [netclient]/[netreceive], which have a buffer of 4kB iirc, than [netsend]/[netreceive], but maybe it is the same issue with [netsend]. as far as i can tell, audio stucks as soon as the buffer is full.
I did an experiment now and replaced netsend with sendOSC/dumpOSC. They seem to perform much better. I still need to run some more tests, but it seems I'll use OSC for the performance tomorrow and I won't use jackd. With some fiddling I managed to get Pd to talk to the USB card directly ("-noadc" helped a lot) and without jack, the audio-Pd runs much smoother anyways.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Arie van Schutterhoef -
Brad Kligerman -
Frank Barknecht -
Georg Holzmann -
patrick -
Roman Haefeli