Strange behaviour using many csound units with jack and osc
Date | 2017-03-30 14:49 |
From | Anton Kholomiov |
Subject | Strange behaviour using many csound units with jack and osc |
Hi! I'm trying to investigate the realm of moular design.~~~ csound test/units/pad-1.csd & csound test/units/pad-2.csd & csound test/units/pad-3.csd & csound test/units/pad-4.csd & csound ../hs/quad-flow.csd & csound ../haunted/haunt.csd --omacro:PORT=5401 -odac:nil & csound ../mixer/mixer.csd --omacro:PORT=5402 & sleep 1 aj-snapshot -r test/jack-config/flow-test.xml dragon-osc -i test.json --verbose -c quad-flow=5400,haunted=5401,mixer=5402 & ~~~ Cheers Anton |
Date | 2017-03-30 14:50 |
From | Anton Kholomiov |
Subject | Re: Strange behaviour using many csound units with jack and osc |
maybe i need some sleep statments? or how can it be that one csound processes stop the other ones2017-03-30 16:49 GMT+03:00 Anton Kholomiov <anton.kholomiov@gmail.com>:
|
Date | 2017-03-30 15:45 |
From | jpff |
Subject | Re: Strange behaviour using many csound units with jack and osc |
Eight processes -- how many cores do you have? I suspect pocess scheduling is an issue ere On Thu, 30 Mar 2017, Anton Kholomiov wrote: > Hi! > > I'm trying to investigate the realm of moular design. > I create an environment for live performance. I do it on linux. > The environment is composed from many csound units > that are connected with JACK and controlled by OSC. > > Also I use aj-snapshot to store the JACK connections. > This useful program can take a picture of current JACK setup, > store it in the xml file and restore it later. > > I'd like to launch and setup everything with script. > It looks like this: > > ~~~ > > csound test/units/pad-1.csd & > csound test/units/pad-2.csd & > csound test/units/pad-3.csd & > csound test/units/pad-4.csd & > > csound ../hs/quad-flow.csd & > csound ../haunted/haunt.csd --omacro:PORT=5401 -odac:nil & > csound ../mixer/mixer.csd --omacro:PORT=5402 & > sleep 1 > aj-snapshot -r test/jack-config/flow-test.xml > dragon-osc -i test.json --verbose -c quad-flow=5400,haunted=5401,mixer=5402 & > > ~~~ > > The problem is that when I launch it only part of the pad's are started > usually one or none at all. pads are first four lines > > but when I do it line by line by hand everything goes ok. > But when I run the script it fails to launch some of my csound units. > > What can it be? > Have you experienced something like this? > > Cheers > Anton > > > > Csound mailing list Csound@listserv.heanet.ie > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to > https://github.com/csound/csound/issues Discussions of bugs and features can > be posted here > Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here |
Date | 2017-03-30 17:53 |
From | Anton Kholomiov |
Subject | Re: Strange behaviour using many csound units with jack and osc |
I've got 8 2017-03-30 17:45 GMT+03:00 jpff <jpff@codemist.co.uk>: Eight processes -- how many cores do you have? I suspect pocess scheduling is an issue ere |
Date | 2017-03-30 17:56 |
From | Anton Kholomiov |
Subject | Re: Strange behaviour using many csound units with jack and osc |
But it's strange. Why is it working when I do everything manually. But can not work when I launch with the shell script. Also I'm not sure I understand the limits of multi-unit csound usage. How many of them am I allowed to launch at the same time? 2017-03-30 19:53 GMT+03:00 Anton Kholomiov <anton.kholomiov@gmail.com>:
|
Date | 2017-03-30 18:04 |
From | Guillermo Senna |
Subject | Re: Strange behaviour using many csound units with jack and osc |
Hi Anton, Could you attach the real bash script? On 30/03/17 13:56, Anton Kholomiov wrote: > But it's strange. Why is it working when I do everything manually. But can > not work when I launch with the shell script. Also I'm not sure I > understand the limits of multi-unit csound usage. How many of them am I > allowed to launch at the same time? > > 2017-03-30 19:53 GMT+03:00 Anton Kholomiov |
Date | 2017-03-30 18:38 |
From | Anton Kholomiov |
Subject | Re: Strange behaviour using many csound units with jack and osc |
Hi Guillermo! It's a real scrip quoted within mardkdown triple ~~~ 2017-03-30 20:04 GMT+03:00 Guillermo Senna <gsenna@gmail.com>: Hi Anton, |
Date | 2017-03-30 18:38 |
From | Anton Kholomiov |
Subject | Re: Strange behaviour using many csound units with jack and osc |
At the first message 2017-03-30 20:38 GMT+03:00 Anton Kholomiov <anton.kholomiov@gmail.com>:
|
Date | 2017-03-30 18:44 |
From | Steven Yi |
Subject | Re: Strange behaviour using many csound units with jack and osc |
Hi Anton, Are you using Csound's auto-connection for JACK? I wonder if that might cause a time-related problem with the various Csound processes trying to connect with the same name somehow. (This is just a guess though.) steven On Thu, Mar 30, 2017 at 1:38 PM, Anton Kholomiov |
Date | 2017-03-30 18:48 |
From | Anton Kholomiov |
Subject | Re: Strange behaviour using many csound units with jack and osc |
@Guillermo It features 7 csounds, aj-snapshot call (momentary) and long process dragon-osc it creates UI interface for controlling csound units by OSC. It's something like TouchOSC only for desktop
Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here
@Steven I'm calling all csound processes with -odac:nil -iadc:nil to avoid auto connection 2017-03-30 20:38 GMT+03:00 Anton Kholomiov <anton.kholomiov@gmail.com>:
|
Date | 2017-03-30 18:51 |
From | Anton Kholomiov |
Subject | Re: Strange behaviour using many csound units with jack and osc |
I've got four pads. If it's closer then the samples corresponding to that corner are more likely to play.One quadrant mixer for pads. It has the XY-pad on it and it crossfades between four sound sources. Also I have XY-pad controlled thing that schedules FX-samples from four sources with probability. 2017-03-30 20:48 GMT+03:00 Anton Kholomiov <anton.kholomiov@gmail.com>:
|
Date | 2017-03-30 19:17 |
From | Guillermo Senna |
Subject | Re: Strange behaviour using many csound units with jack and osc |
The file quad-flow.csd is not in that repository, but for a short time I think I was able to reproduce the issue you were seeing. Unfortunately, now it's working without problems, so I don't know. I couldn't copy the debug of the segfault but it was something to do with Jack and 'invalid next size'. I guess a quick solution would be to put a bunch of "sleep 1" commands between the pads' csd. On 30/03/17 14:51, Anton Kholomiov wrote: > I've got four pads. > One quadrant mixer for pads. It has the XY-pad on it and it crossfades > between four sound sources. Also I have XY-pad controlled thing that > schedules FX-samples from four sources with probability. > If it's closer then the samples corresponding to that corner are more > likely to play. > Also there is a grand mixer that mixes sounds from all sources (it's like > usual mixer) > > I'm trying to create environment for slow motion ambient concerts.. > > > 2017-03-30 20:48 GMT+03:00 Anton Kholomiov |
Date | 2017-03-31 09:44 |
From | Anton Kholomiov |
Subject | Re: Strange behaviour using many csound units with jack and osc |
Thanks Guillermo! Putting `sleep 0.1` after each pad invocation resolves the issueAnton 2017-03-30 21:17 GMT+03:00 Guillermo Senna <gsenna@gmail.com>: The file quad-flow.csd is not in that repository, but for a short time I |
Date | 2017-03-31 20:50 |
From | Guillermo Senna |
Subject | Re: Strange behaviour using many csound units with jack and osc |
Great! I've been trying to see what's going on. It's difficult to debug because it only happens when multiple instances of csound/jack are started. I think it's something like a race condition because the list of available devices changes between it's requested, but before it's freed. Or something like that. This is Csound's debug info: Jack output ports: 0: dac0 (dac:system:playback_1) 1: dac1 (dac:system:playback_2) 2: dac2 (dac:system:playback_3) 3: dac3 (dac:system:playback_4) 4: dac4 (dac:PulseAudio JACK Source:front-left) 5: dac5 (dac:PulseAudio JACK Source:front-right) *** Error in `/usr/local/bin/csound': double free or corruption (!prev): 0x000055555594ba50 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x790cb)[0x7ffff72ed0cb] /lib/x86_64-linux-gnu/libc.so.6(+0x8275a)[0x7ffff72f675a] /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7ffff72fa18c] /usr/local/lib/libcsound64.so.6.0(+0x6787a)[0x7ffff78c087a] /usr/local/lib/csound/plugins64-6.0/librtjack.so(+0x20f9)[0x7fffe4bfa0f9] /usr/local/lib/csound/plugins64-6.0/librtjack.so(+0x2e9a)[0x7fffe4bfae9a] /usr/local/lib/csound/plugins64-6.0/librtjack.so(+0x387e)[0x7fffe4bfb87e] /usr/local/lib/libcsound64.so.6.0(+0x7d5a6)[0x7ffff78d65a6] /usr/local/lib/libcsound64.so.6.0(+0x6aac2)[0x7ffff78c3ac2] /usr/local/lib/libcsound64.so.6.0(csoundStart+0x805)[0x7ffff7a36481] /usr/local/lib/libcsound64.so.6.0(csoundCompile+0x42)[0x7ffff7a364c9] /usr/local/bin/csound(+0x17de)[0x5555555557de] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7ffff72943f1] /usr/local/bin/csound(_start+0x2a)[0x55555555528a] And this is gdb: (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58 #1 0x00007ffff72ab3ea in __GI_abort () at abort.c:89 #2 0x00007ffff72ed0d0 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7ffff7402368 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175 #3 0x00007ffff72f675a in malloc_printerr (ar_ptr= |
Date | 2017-04-01 13:36 |
From | John ff |
Subject | Re: Strange behaviour using many csound units with jack and osc |
Any chance of a valgrind run? Very good at finding memory problems.
Sent from TypeApp
On 31 Mar 2017, at 20:51, Guillermo Senna <gsenna@GMAIL.COM> wrote: Great! |
Date | 2017-04-01 18:30 |
From | Guillermo Senna |
Subject | Re: Strange behaviour using many csound units with jack and osc |
Hi John, I think this is a race condition because the list of audio devices grows differently after all the simultaneous Csound instances are being started. The problem is that valgrind takes way too much time to start running and so I can't trigger the error. I'll keep trying though. I do see an error in Valgrind, but I think it's a "false positive" (https://github.com/jackaudio/jack2/pull/182). There was a PR and a merge 20 days ago, so I hope to see that error going away the next time I get a system update. Cheers. On 01/04/17 09:36, John ff wrote: > Any chance of a valgrind run? Very good at finding memory problems. > > Sent from TypeApp > > On 31 Mar 2017, 20:51, at 20:51, Guillermo Senna |