this might be a stupid question, but if i want to use jack, which version of jack+pd should i be using?
pix.
Hallo, pix hat gesagt: // pix wrote:
this might be a stupid question, but if i want to use jack, which version of jack+pd should i be using?
I still use jack 0.44, Pd-cvs in Debian depends on 0.50 and if someone would try to use 0.6x it would be nice as well ;)
ciao
Frank Barknecht _ ______footils.org__
On Thu, 27 Mar 2003, Frank Barknecht wrote:
Hallo, pix hat gesagt: // pix wrote:
this might be a stupid question, but if i want to use jack, which version of jack+pd should i be using?
I still use jack 0.44, Pd-cvs in Debian depends on 0.50 and if someone would try to use 0.6x it would be nice as well ;)
I have tried the latest versions of jack and it works well. There is one obstacle with the new jack, which is the thing with having to mount a shm module on /dev/shm, otherwise jack won't run.
Greetings,
Guenter
ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
I use jack 0.51 and I haven't checked pd from cvs in a while (2 months or so). I does like to crash on random occasions.
./MiS
On Wed, 26 Mar 2003 21:51:24 +0100 pix wrote:
this might be a stupid question, but if i want to use jack, which version of jack+pd should i be using?
pix.
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
On Thu, 27 Mar 2003, Michal Seta wrote:
I use jack 0.51 and I haven't checked pd from cvs in a while (2 months or so). I does like to crash on random occasions.
Does this happen with the -rt flag set ?
Greetings,
Guenter
./MiS
On Wed, 26 Mar 2003 21:51:24 +0100 pix wrote:
this might be a stupid question, but if i want to use jack, which version of jack+pd should i be using?
pix.
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
-- _ __ __ (_)___ Michal Seta / / \ _/^ _| / V |_ \ @creazone.32k.org (___/V___|_|___/ http://www.%5Bcreazone%5D%7C%5Bnoonereceiving%5D.32k.org
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
On Thu, 27 Mar 2003 11:34:52 +0100 (CET) guenter wrote:
On Thu, 27 Mar 2003, Michal Seta wrote:
I use jack 0.51 and I haven't checked pd from cvs in a while (2 months or so). I does like to crash on random occasions.
Does this happen with the -rt flag set ?
Yes! How did you know? :)
Actually, if I remember well, it happens when there are spikes in the cpu processing (i.e. loading large patch, updating a large array, etc... whenever I see 'pd-watchdog: signaling pd', or something like that, I'm quite positive it will exit but it doesn't always). Knowing that the CVS version could be broken at any given time I've been reluctant to update and just stuck with the version that sorta worked for me...
Sorry for being so vague.
./MiS
I read:
Does this happen with the -rt flag set ?
Yes! How did you know? :)
hmmmm ... are you on 2.4.20 and using ext3 ?
I had really bad lockups due to an ext3 bug in 2.4.20 went back to ext2 and now the lockups are gone
regards,
x
On Thu, 27 Mar 2003, CK wrote:
I read:
Does this happen with the -rt flag set ?
Yes! How did you know? :)
hmmmm ... are you on 2.4.20 and using ext3 ?
I had really bad lockups due to an ext3 bug in 2.4.20 went back to ext2 and now the lockups are gone
Yes, but this is another (jack specific) problem. I think in this case you get a total system lockup, what Michael experienced is just a "crash" of pd.
Hopefully I have fixed this in CVS now.
Guenter
On Wed, 26 Mar 2003, pix wrote:
this might be a stupid question, but if i want to use jack, which version of jack+pd should i be using?
Use the latest pd from CVS devel_0_36 branch
The jack version is not critical, as long as you use the same version with which it was compiled.
Greetings,
Guenter
pix.
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
finally success, using the latest devel_0_36 checkout, and the jack 0.50 from debian ...
actually what was making me think that it wasn't working was that i needed to set "-n 3" to avoid getting staticy noise with my emi2|6.
i can now use all 6 channels of my emi2|6 (athough you have to hook them up manually with jack_connect).
i get 92ms latency, it looks like that would be about 32ms if i used alsa directly (but i get terrible "continuity"). just mentioning that incase anyone is interested. i personally don't do anything that requires low latency.
i also noticed that using a realtime jack and a realtime pd, i could do pretty much anything on the machine without interrupting audio. but if i tried to draw on a graph in pd, i still get audio dropouts (well, crackles and A/D/A sync errors). if you ask me, that seems very wrong.
pix.
On Thu, 27 Mar 2003 10:51:29 +0100 (CET) guenter geiger geiger@xdv.org wrote:
On Wed, 26 Mar 2003, pix wrote:
this might be a stupid question, but if i want to use jack, which version of jack+pd should i be using?
Use the latest pd from CVS devel_0_36 branch
The jack version is not critical, as long as you use the same version with which it was compiled.
Greetings,
Guenter
pix.
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
On Thu, 27 Mar 2003, pix wrote:
finally success, using the latest devel_0_36 checkout, and the jack 0.50 from debian ...
actually what was making me think that it wasn't working was that i needed to set "-n 3" to avoid getting staticy noise with my emi2|6.
yes, you have to get your settings right with jack ...
i can now use all 6 channels of my emi2|6 (athough you have to hook them up manually with jack_connect).
oops. thats a bug. fixed in CVS.
i get 92ms latency, it looks like that would be about 32ms if i used alsa directly (but i get terrible "continuity"). just mentioning that incase anyone is interested. i personally don't do anything that requires low latency.
i also noticed that using a realtime jack and a realtime pd, i could do pretty much anything on the machine without interrupting audio. but if i tried to draw on a graph in pd, i still get audio dropouts (well, crackles and A/D/A sync errors). if you ask me, that seems very wrong.
yes, drawing in arrays is the worst thing you can do together with selecting several objects and moving them around.
This is a problem of the pd<->GUI connection and how array drawing and updating is handled in pd ATM.
Guenter
pix.
On Thu, 27 Mar 2003 10:51:29 +0100 (CET) guenter geiger geiger@xdv.org wrote:
On Wed, 26 Mar 2003, pix wrote:
this might be a stupid question, but if i want to use jack, which version of jack+pd should i be using?
Use the latest pd from CVS devel_0_36 branch
The jack version is not critical, as long as you use the same version with which it was compiled.
Greetings,
Guenter
pix.
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
On Thu, 27 Mar 2003 19:43:13 +0100 (CET) guenter geiger geiger@xdv.org wrote:
On Thu, 27 Mar 2003, pix wrote:
finally success, using the latest devel_0_36 checkout, and the jack 0.50 from debian ...
actually what was making me think that it wasn't working was that i needed to set "-n 3" to avoid getting staticy noise with my emi2|6.
yes, you have to get your settings right with jack ...
yeah.. i just saw a note on an alsa page, that you should set the -p(eriod) to a multiple of 48 when using the emi2|6 (to fit the native sample rate). but setting -p to anything other than a power of 2 gets pd to spew out "partialread" error messages. i also remember the original jack patch saying that you need to change the DACBLKSIZE in m_imp.h, but changing it to anything other than a power of 2 also causes a consistency check error.
not so important, would probably just help with latency. by the way, anyone reading who cares, i got it down to 46ms with -n 3 -p 512.
i can now use all 6 channels of my emi2|6 (athough you have to hook them up manually with jack_connect).
oops. thats a bug. fixed in CVS.
ah cool.
i also noticed that if you set -outchannels >2 and only open a normal stereo dac~ object, you get noise on the rest of the channels.
i get 92ms latency, it looks like that would be about 32ms if i used alsa directly (but i get terrible "continuity"). just mentioning that incase anyone is interested. i personally don't do anything that requires low latency.
i also noticed that using a realtime jack and a realtime pd, i could do pretty much anything on the machine without interrupting audio. but if i tried to draw on a graph in pd, i still get audio dropouts (well, crackles and A/D/A sync errors). if you ask me, that seems very wrong.
yes, drawing in arrays is the worst thing you can do together with selecting several objects and moving them around.
This is a problem of the pd<->GUI connection and how array drawing and updating is handled in pd ATM.
should i avoid reading too much into "ATM"? ;)
the idea of skimping on the interface reminds me far too much of doing purely midi controlled csound/sfront patches.
pix.
Hallo, pix hat gesagt: // pix wrote:
yeah.. i just saw a note on an alsa page, that you should set the -p(eriod) to a multiple of 48 when using the emi2|6 (to fit the native sample rate).
More exactly, the reason is, that USB-audio gets delivered in chunks of a fixed time (every 1000 or 100 msecs, I think), whereas standard soundcards have a buffer, that is sized in samples. So if you are running the interface at 48kHz, your period should be a multiple of 48, so that it can match the usb-buffer with integer multiples.
I'm not sure, if what I say above is fully correct, it's just what I remember from talk with Takashi Iwai and I might be wrong...
And actually I can run Pd just fine on my Quattro without using the multiple of 48.
should i avoid reading too much into "ATM"? ;)
the idea of skimping on the interface reminds me far too much of doing purely midi controlled csound/sfront patches.
GUI and DSP are still tightly coupled in Pd, so it's not really skimping, but a hard task, to de-couple both again.
ciao
Frank Barknecht _ ______footils.org__
On Wednesday 26 March 2003 20:51, pix wrote:
this might be a stupid question, but if i want to use jack, which version of jack+pd should i be using?
I use latest CVS from both JACK and pd devel_0_36. The work quite ok. but if you plan to use other jack apps you might want to wait a bit until you install latest jack cvs. Many things changed recently. Jack clients have to be recompiled and some of them do not work for me yet (even adding the -lrt flag)
Btw does anybody gets the pd to crash when selecting a part of the canvas with a group of boxes in it and move it around in the screen? And from a sort test I did right now before I sent the email, it only happens with pd -jack not pd -alsa. zombified - calling shutdown handler pd_gui: pd process exited
-- regards anton
On Thu, 27 Mar 2003, Antonis Galanopoulos wrote:
Btw does anybody gets the pd to crash when selecting a part of the canvas with a group of boxes in it and move it around in the screen? And from a sort test I did right now before I sent the email, it only happens with pd -jack not pd -alsa. zombified - calling shutdown handler pd_gui: pd process exited
This is because pd had higher priority than jack, so jack got angry and killed pd .... :)
I have lowered pd's priority in CVS right now, please check out and test if it works.
Greetings,
Guenter
Hi Guenter, i got the latest cvs and it works fine. the problem with the moving objects is gone although I didnt test that much. It hasn't crashed yet and it is running for quite a while now . I noticed however that the CPU usage has gone up. It was 2-3 % before and it is 9-10 now with the same patch. I guess that has to do with the less priority pd now has. Thats not a problem though, I'm just letting you know. Thanks very much. -- regards anton
On Thursday 27 March 2003 20:42, Antonis Galanopoulos wrote:
Hi Guenter, i got the latest cvs and it works fine. the problem with the moving objects is gone although I didnt test that much. It hasn't crashed yet and it is running for quite a while now . I noticed however that the CPU usage has gone up. It was 2-3 % before and it is 9-10 now with the same patch. I guess that has to do with the less priority pd now has. Thats not a problem though, I'm just letting you know. Thanks very much.
A question for Guenter, or whoever else: how is the CPU usage measured? Is it the time at the start of a DSP cycle to the time at the end of the cycle, or is it really only the CPU time that the PD process actually uses, taking into account that PD could be pre-empted in the middle of the processing (I think that before jack, this was probably not an issue before)?
If the latter (true CPU usage is measured), I don't understand it. Why would PD's CPU usage increase by that much?
If the former (only the time between the start and end of the processing is measured) I suppose it means that PD is being pre-empted, presumably by jack. But why would this be happening, if PD is fast enough to complete its processing in time (and hence not get pre-empted by jack due to timeout)?
Larry Troxler
On Sat, 29 Mar 2003, Larry Troxler wrote:
On Thursday 27 March 2003 20:42, Antonis Galanopoulos wrote:
Hi Guenter, i got the latest cvs and it works fine. the problem with the moving objects is gone although I didnt test that much. It hasn't crashed yet and it is running for quite a while now . I noticed however that the CPU usage has gone up. It was 2-3 % before and it is 9-10 now with the same patch. I guess that has to do with the less priority pd now has. Thats not a problem though, I'm just letting you know. Thanks very much.
A question for Guenter, or whoever else: how is the CPU usage measured? Is it the time at the start of a DSP cycle to the time at the end of the cycle, or is it really only the CPU time that the PD process actually uses, taking into account that PD could be pre-empted in the middle of the processing (I think that before jack, this was probably not an issue before)?
Hi,
On UNIX pd meaasures performance with the times() function. This should give back the exact times the process needed. I do not know why the latest changs should influence CPU usage. I haven't noticed something similar until now.
Could be that connecting all theports by default makes a difference on Antonis system. (Before only stereo output was connected)
Guenter
If the latter (true CPU usage is measured), I don't understand it. Why would PD's CPU usage increase by that much?
If the former (only the time between the start and end of the processing is measured) I suppose it means that PD is being pre-empted, presumably by jack. But why would this be happening, if PD is fast enough to complete its processing in time (and hence not get pre-empted by jack due to timeout)?
Larry Troxler
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Hi Guenter, hi all,
Just wanted to report that I have checked out the CVS last Saturday and haven't yet managed to crash PD. It was running for about 18 hours stright but I haven't yet done anything very intensive with it. I was even able to run other apps, even using jacklaunch (what a nice tool! - but it needs an upddate to the newer jack API :) ) and others and PD behaved fine despite of occasional xruns and such (xruns caused by other apps used to occasionally kick pd out of the jack chain - no idea if this is a jack or pd issue). Using jack0.51
cheers
./MiS
_
__ __ (_)___ Michal Seta
/ \/ \ _/^ _|
/ V |_ \ @creazone.32k.org
(___/V___|_|___/ http://www.%5Bcreazone%5D%7C%5Bnoonereceiving%5D.32k.org
On Mon, 31 Mar 2003, Michal Seta wrote:
Hi Guenter, hi all,
Just wanted to report that I have checked out the CVS last Saturday and haven't yet managed to crash PD. It was running for about 18 hours stright but I haven't yet done anything very intensive with it. I was even able to run other apps, even using jacklaunch (what a nice tool! - but it needs an upddate to the newer jack API :) )
Thanks :) What do you mean with newer jack API ? Did I forget something ? I am running it with the CVS version of jack.
and others and PD behaved fine despite of occasional xruns and such (xruns caused by other apps used to occasionally kick pd out of the jack chain - no idea if this is a jack or pd issue). Using jack0.51
No idea either. I hope that the way PD integrates into jack is pretty robust now in devel_0_36. ... But there are always these "minor" details that only time will tell :)
Guenter
cheers
./MiS
_ __ __ (_)___ Michal Seta / \/ \ _/^ _| / V |_ \ @creazone.32k.org(___/V___|_|___/ http://www.%5Bcreazone%5D%7C%5Bnoonereceiving%5D.32k.org
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
On Tue, 1 Apr 2003 07:31:18 +0200 (CEST) guenter wrote:
What do you mean with newer jack API ? Did I forget something ? I am running it with the CVS version of jack.
I get this usually when running jacklaunch (maybe I'm using an old version?)
*** libjack: WARNING! Use of function jack_set_buffer_size_callback() is deprecated! ***
./MiS
Hallo, Michal Seta hat gesagt: // Michal Seta wrote:
I get this usually when running jacklaunch (maybe I'm using an old version?)
*** libjack: WARNING! Use of function jack_set_buffer_size_callback() is deprecated! ***
That's Pd using a deprecated function.
ciao
Frank Barknecht _ ______footils.org__
Actually, I probably should have sent my last message directly to Guenter as it does not relate to pd... I _really_ meant jacklaunch. PD seems to be fine and not complaining.
Sorry for confusing...
./MiS
On Tue, 1 Apr 2003 23:36:58 +0200 Frank wrote:
Hallo, Michal Seta hat gesagt: // Michal Seta wrote:
I get this usually when running jacklaunch (maybe I'm using an old version?)
*** libjack: WARNING! Use of function jack_set_buffer_size_callback() is deprecated! ***
That's Pd using a deprecated function.
ciao
-
Antonis Galanopoulos -
CK -
Frank Barknecht -
guenter geiger -
Larry Troxler -
Michal Seta -
pix