Hi all.
I'm running Ubuntu Intrepid 2.6.27-3-rt #1 PREEMPT RT and having some strange things happening when loading libraries like GEM, pdp or pidip together with using real time priority for jack and pd:
starting jack: jackd -R -d alsa starting pd: /usr/bin/pd -jack -rt -channels 2 -noprefs -stderr
then i make a new patch and create [Gem] it takes some time (hard disk working) and then everything's fine.
then i close pd, start pd again like above, again create [Gem] (this time no noticeable harddisk action, files are cached) and pd crashes:
... GEM: using MMX optimization cannot read server event (Connection reset by peer) zombified - calling shutdown handler watchdog: signaling pd... watchdog: signaling pd...
I can avoid this crash by different things:
start with -nogui start with channels 0, then creating [Gem] then set up media, jack start pd without real time priority or start jack without real time priority or with -P (priority setting) which gave too much xruns, at least with firewire audio.
it also crashes when i start pd without audio, then set up audio in the menu and then create [Gem]
I also posted this as bug at the Gem sourceforge page, but then i found out that it's not Gem related. As I mentioned before, it also happens with pdp / pidip, but Interestingly not every time I create pdp (but always together with pidip)
my workaround is now loading all libs at startup and then sending a message to pd to setup audio:
[; pd audio-dialog 0 0 0 0 4 0 0 0 0 0 0 0 4 0 0 0 48000(
anyone having similar things happening? i could reproduce it on an other pc using ubuntu jaunty, but it didn't happen on hardy. also non-realtime kernels give me these problems.
cheers, Martin
Martin Schied wrote:
Hi all.
I'm running Ubuntu Intrepid 2.6.27-3-rt #1 PREEMPT RT and having some strange things happening when loading libraries like GEM, pdp or pidip
good to know that it is not only Gem. bad that it is happening in several circumstances...
with pdp / pidip, but Interestingly not every time I create pdp (but always together with pidip)
so it might be related to a library both Gem and pidip are using. and aeventually pdp; like libquicktime...
my workaround is now loading all libs at startup and then sending a message to pd to setup audio:
[; pd audio-dialog 0 0 0 0 4 0 0 0 0 0 0 0 4 0 0 0 48000(
anyone having similar things happening? i could reproduce it on an other pc using ubuntu jaunty, but it didn't happen on hardy. also non-realtime kernels give me these problems.
just to make sure this isn't a typo: it happens on both RT and non-RT kernels?
fmgas.dr IOhannes
just to make sure this isn't a typo: it happens on both RT and non-RT kernels?
yes.
and it turns out that the problem's sitting again in front of the machine, not inside...
I did some additional experiments with realtime settings of jack. previously I didn't know that I can supply jack with both arguments (-R and -P) together, so maybe there's no actual bug at all:
jackd -R -P <number> where <number> has to be greater than 10 to get no more crashes on my system. maybe there were some changes in jack's default setting or i just "accidently" didn't have these crashes before.
previously I didn't know that I can supply jackd with both arguments
(-R and -P) together, so maybe there's no bug at all.
Nevertheless it's very weird and I don't understand why the order of loading something can be interfering with priorities. It would be nice to have a place to put information like this - i wonder why there are no other people running into these crashes.
cheers, Martin
On Thu, 2009-04-02 at 19:45 +0200, Martin Schied wrote:
Nevertheless it's very weird and I don't understand why the order of loading something can be interfering with priorities. It would be nice to have a place to put information like this - i wonder why there are no other people running into these crashes.
iirc, i did run into crashes in similar situations, though i cannot recall the exact details.
finally, i decided, that i never want any graphics to run in realtime, risking a more likely freeze of the machine without any real gain, whereas i almost always want audio to be realtime and also would like to avoid graphics to interfere with audio whenever possible.
since then i haven't used '-lib [Gem|pdp|gridflow]' and '-rt' in the same instance of pd and could get rid of such nasty issues. in projects, that use both, audio and video, i usually put all tilde and timing objects into the audio (-rt, maybe -nogui) pd instance and the gui stuff, video calculation and displaying into the video (-nrt) pd instance. both talk over a network socket with each other.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hi!
Roman Haefeli schrieb:
On Thu, 2009-04-02 at 19:45 +0200, Martin Schied wrote:
Nevertheless it's very weird and I don't understand why the order of loading something can be interfering with priorities. It would be nice to have a place to put information like this - i wonder why there are no other people running into these crashes.
iirc, i did run into crashes in similar situations, though i cannot recall the exact details.
finally, i decided, that i never want any graphics to run in realtime, risking a more likely freeze of the machine without any real gain, whereas i almost always want audio to be realtime and also would like to avoid graphics to interfere with audio whenever possible.
since then i haven't used '-lib [Gem|pdp|gridflow]' and '-rt' in the same instance of pd and could get rid of such nasty issues. in projects, that use both, audio and video, i usually put all tilde and timing objects into the audio (-rt, maybe -nogui) pd instance and the gui stuff, video calculation and displaying into the video (-nrt) pd instance. both talk over a network socket with each other.
roman
probably that's what's I'm going to do now too. although it would be nice to have the possibility to do a quick visualization of something in gem without having to start a second instance.
i already have a separation of pd for "working" (rt) and one for "reading patches" (nrt, noaudio) to avoid unwanted crashes - so there will be a third one soon...
from there arise some more questions or thoughts:
I'd like to have the possibility to have multiple versions of .pdsettings (so changes can directly be applied in the menu and saved for future use). For a short period of time I was using some start commands copying .pdsettings files around before starting pd but that was (obviously) no good solution. Has there already been a feature request for specifying different .pdsettings files? like a 'pd -prefs .mypdsettingsfile' ? This was the main obstacle for me to use multiple instances of pd with different settings. I know that I have the possibility to specify everything needed in a bash script for startup, but that's always some more clicks and key strokes than just using the menu.
cheers, Martin
On Fri, 3 Apr 2009, Martin Schied wrote:
I'd like to have the possibility to have multiple versions of .pdsettings (so changes can directly be applied in the menu and saved for future use). For a short period of time I was using some start commands copying .pdsettings files around before starting pd but that was (obviously) no good solution.
You can change the value of $HOME in the context of Pd:
HOME=$HOME/realtime-pd pd blah.pd
or
(export HOME=$HOME/realtime-pd pd blah.pd)
which I believe are exactly the same, but with the latter syntax you can do more... but changing HOME means that ~ at the beginning of filenames will change its meaning, for any context that understands ~ to mean $HOME.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Mathieu Bouchard schrieb:
On Fri, 3 Apr 2009, Martin Schied wrote:
I'd like to have the possibility to have multiple versions of .pdsettings (so changes can directly be applied in the menu and saved for future use). For a short period of time I was using some start commands copying .pdsettings files around before starting pd but that was (obviously) no good solution.
You can change the value of $HOME in the context of Pd:
HOME=$HOME/realtime-pd pd blah.pd
or
(export HOME=$HOME/realtime-pd pd blah.pd)
which I believe are exactly the same, but with the latter syntax you can do more... but changing HOME means that ~ at the beginning of filenames will change its meaning, for any context that understands ~ to mean $HOME.
nice solution, I hardly use ~/ in pd anyway...
-
IOhannes m zmoelnig -
Martin Schied -
Mathieu Bouchard -
Roman Haefeli