Hi all,
It's taken me a bit to narrow this down, and I haven't seen much in the archive related to this specifically, but I wondered if someone could shed some light on this GUI weirdness.
While running Pd with Jack, the GUI redraw when using the mouse is highly erratic. Typically, it will start out fine and I can move a slider or numberbox smoothly, but if I hold onto it for more than a few seconds, the redraw will start to pause and hang behind by increasing intervals. Meanwhile, there aren't any audio dropouts or xruns, just the slow GUI. No CPU spikes, either.
I have found that if I constantly run a metro and a flashing button, the problem goes away since the GUI is forced to redraw at least as often as the metro beats, but I'd like to avoid doing this.
I initially noticed this problem with the planetCCRMA pd and jack rpms (which are older versions, I think). But I have since recompiled Pd, Jack, and tcl/tk from source and the problem persists.
I'm using: 2.6.16-1.2080.13.rdt.rhfc4.ccrmasmp (FC4 jackd -R -d alsa -dhw:0 -r44100 -p2048 -n2 (doesn't seem to matter what jack params are used, RT or not) pd 0.39-2 compiled with alsa and jack support.
I'd be thankful if anyone has an ideas before I try upgrading the kernel as a last resort.
Best, Michael Berkowski
Well, don't upgrade your kernel unless you want to do it anyway... I think this is Pd and Jack misunderstanding each other.
Whenever it can, Pd delays graphics updates until it gets caught up with all "real-time" operations, which are clocked off the audio system. Pd knows it's caught up when the audio system reports that its output buffer is full (and its input buffer empty). For some reason, Pd never seems to notice when Jack is happy - I don't know enough about Jack that I could guess why.
The reason flashing buttons "fix" the problem is that that particular graphic update isn't queue-able, and since graphics updates cannot be done out of order, this forces a flush of all graphics updates, whether this would cause a click or not. Of course, eventually I hope to have all the graphics queue-able, which would mean the flashing button would no longer help you. But don't hold your breath.
Meanwhile, I'll stick it on my list to try to figure out why Pd never believes it's idle when talking to Jack... I never use jack myself so would never have been aware of this if you hadn't written!
cheers Miller
On Fri, Aug 11, 2006 at 08:51:10PM -0500, Michael Berkowski wrote:
Hi all,
It's taken me a bit to narrow this down, and I haven't seen much in the archive related to this specifically, but I wondered if someone could shed some light on this GUI weirdness.
While running Pd with Jack, the GUI redraw when using the mouse is highly erratic. Typically, it will start out fine and I can move a slider or numberbox smoothly, but if I hold onto it for more than a few seconds, the redraw will start to pause and hang behind by increasing intervals. Meanwhile, there aren't any audio dropouts or xruns, just the slow GUI. No CPU spikes, either.
I have found that if I constantly run a metro and a flashing button, the problem goes away since the GUI is forced to redraw at least as often as the metro beats, but I'd like to avoid doing this.
I initially noticed this problem with the planetCCRMA pd and jack rpms (which are older versions, I think). But I have since recompiled Pd, Jack, and tcl/tk from source and the problem persists.
I'm using: 2.6.16-1.2080.13.rdt.rhfc4.ccrmasmp (FC4 jackd -R -d alsa -dhw:0 -r44100 -p2048 -n2 (doesn't seem to matter what jack params are used, RT or not) pd 0.39-2 compiled with alsa and jack support.
I'd be thankful if anyone has an ideas before I try upgrading the kernel as a last resort.
Best, Michael Berkowski
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Miller,
Thanks for responding so quickly with this. As suggested on the list, switching my window manager from Gnome's Metacity to something lighter (FVWM) seems to stop or hide the behavior. The other Gnome components are still running -- only the wm has changed.
Thanks for your help, Michael Berkowski
Miller Puckette wrote:
Well, don't upgrade your kernel unless you want to do it anyway... I think this is Pd and Jack misunderstanding each other.
Whenever it can, Pd delays graphics updates until it gets caught up with all "real-time" operations, which are clocked off the audio system. Pd knows it's caught up when the audio system reports that its output buffer is full (and its input buffer empty). For some reason, Pd never seems to notice when Jack is happy - I don't know enough about Jack that I could guess why.
The reason flashing buttons "fix" the problem is that that particular graphic update isn't queue-able, and since graphics updates cannot be done out of order, this forces a flush of all graphics updates, whether this would cause a click or not. Of course, eventually I hope to have all the graphics queue-able, which would mean the flashing button would no longer help you. But don't hold your breath.
Meanwhile, I'll stick it on my list to try to figure out why Pd never believes it's idle when talking to Jack... I never use jack myself so would never have been aware of this if you hadn't written!
cheers Miller
On Fri, Aug 11, 2006 at 08:51:10PM -0500, Michael Berkowski wrote:
Hi all,
It's taken me a bit to narrow this down, and I haven't seen much in the archive related to this specifically, but I wondered if someone could shed some light on this GUI weirdness.
While running Pd with Jack, the GUI redraw when using the mouse is highly erratic. Typically, it will start out fine and I can move a slider or numberbox smoothly, but if I hold onto it for more than a few seconds, the redraw will start to pause and hang behind by increasing intervals. Meanwhile, there aren't any audio dropouts or xruns, just the slow GUI. No CPU spikes, either.
I have found that if I constantly run a metro and a flashing button, the problem goes away since the GUI is forced to redraw at least as often as the metro beats, but I'd like to avoid doing this.
I initially noticed this problem with the planetCCRMA pd and jack rpms (which are older versions, I think). But I have since recompiled Pd, Jack, and tcl/tk from source and the problem persists.
I'm using: 2.6.16-1.2080.13.rdt.rhfc4.ccrmasmp (FC4 jackd -R -d alsa -dhw:0 -r44100 -p2048 -n2 (doesn't seem to matter what jack params are used, RT or not) pd 0.39-2 compiled with alsa and jack support.
I'd be thankful if anyone has an ideas before I try upgrading the kernel as a last resort.
Best, Michael Berkowski
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
since we are talking about pd and jack, there is another issue i have: when passing the flag '-jack' to start pd, pd won't connect automatically to jack. when i try it manually then, i have to choose another driver first (alsa or oss), before i can set audio to jack. i found a workaround for this by sending a message like [pd audiodialog <some numbers( on startup. this works, but then i always have to quit the audio-dialog manually after starting pd. when i start pd with '-alsa' or '-oss', there is no need to switch the driver twice, i can switch directly to jack.
this is with: pd-0.40.0test1, jack 0.100.0, ubuntu dapper pd-0.39.2, jack 0.99.54, debian sarge
i wonder, if other people have similar issue.
roman
On Fri, 2006-08-11 at 21:03 -0700, Miller Puckette wrote:
Well, don't upgrade your kernel unless you want to do it anyway... I think this is Pd and Jack misunderstanding each other.
Whenever it can, Pd delays graphics updates until it gets caught up with all "real-time" operations, which are clocked off the audio system. Pd knows it's caught up when the audio system reports that its output buffer is full (and its input buffer empty). For some reason, Pd never seems to notice when Jack is happy - I don't know enough about Jack that I could guess why.
The reason flashing buttons "fix" the problem is that that particular graphic update isn't queue-able, and since graphics updates cannot be done out of order, this forces a flush of all graphics updates, whether this would cause a click or not. Of course, eventually I hope to have all the graphics queue-able, which would mean the flashing button would no longer help you. But don't hold your breath.
Meanwhile, I'll stick it on my list to try to figure out why Pd never believes it's idle when talking to Jack... I never use jack myself so would never have been aware of this if you hadn't written!
cheers Miller
On Fri, Aug 11, 2006 at 08:51:10PM -0500, Michael Berkowski wrote:
Hi all,
It's taken me a bit to narrow this down, and I haven't seen much in the archive related to this specifically, but I wondered if someone could shed some light on this GUI weirdness.
While running Pd with Jack, the GUI redraw when using the mouse is highly erratic. Typically, it will start out fine and I can move a slider or numberbox smoothly, but if I hold onto it for more than a few seconds, the redraw will start to pause and hang behind by increasing intervals. Meanwhile, there aren't any audio dropouts or xruns, just the slow GUI. No CPU spikes, either.
I have found that if I constantly run a metro and a flashing button, the problem goes away since the GUI is forced to redraw at least as often as the metro beats, but I'd like to avoid doing this.
I initially noticed this problem with the planetCCRMA pd and jack rpms (which are older versions, I think). But I have since recompiled Pd, Jack, and tcl/tk from source and the problem persists.
I'm using: 2.6.16-1.2080.13.rdt.rhfc4.ccrmasmp (FC4 jackd -R -d alsa -dhw:0 -r44100 -p2048 -n2 (doesn't seem to matter what jack params are used, RT or not) pd 0.39-2 compiled with alsa and jack support.
I'd be thankful if anyone has an ideas before I try upgrading the kernel as a last resort.
Best, Michael Berkowski
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Interesting. I was going to just write this off, but maybe someone can explain it to me: I compiled a real-time kernel, according to http://demudi.agnula.org/wiki/Low-latencyKernelBuildingHowto I run Jack with realtime enabled, and run Pd with realtime enabled, and bring up Pd's test tone. I then click and drag the bar on the Pd test tone window, and move it in circles, and immediately start getting clicks and xruns. It doesn't handle my sequencer too well, either. Every time I ask what needs to be done, I get one step, which takes me a day to complete, and then find out I have to do another step. Is it really possible to have Linux set up so that all audio always gets done before anything else, without exception? It's frustrating that it works better for me in Windows after all these unproductive days.
-Chuckk
On 8/11/06, Michael Berkowski michael@berkowski.net wrote:
Hi all,
It's taken me a bit to narrow this down, and I haven't seen much in the archive related to this specifically, but I wondered if someone could shed some light on this GUI weirdness.
While running Pd with Jack, the GUI redraw when using the mouse is highly erratic. Typically, it will start out fine and I can move a slider or numberbox smoothly, but if I hold onto it for more than a few seconds, the redraw will start to pause and hang behind by increasing intervals. Meanwhile, there aren't any audio dropouts or xruns, just the slow GUI. No CPU spikes, either.
I have found that if I constantly run a metro and a flashing button, the problem goes away since the GUI is forced to redraw at least as often as the metro beats, but I'd like to avoid doing this.
I initially noticed this problem with the planetCCRMA pd and jack rpms (which are older versions, I think). But I have since recompiled Pd, Jack, and tcl/tk from source and the problem persists.
I'm using: 2.6.16-1.2080.13.rdt.rhfc4.ccrmasmp (FC4 jackd -R -d alsa -dhw:0 -r44100 -p2048 -n2 (doesn't seem to matter what jack params are used, RT or not) pd 0.39-2 compiled with alsa and jack support.
I'd be thankful if anyone has an ideas before I try upgrading the kernel as a last resort.
Best, Michael Berkowski
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Good old fashioned userland priority is what so many people seem to forget. nice -10 sorted out many problems with dropouts when moving windows etc. I'm not 100% sure about all systems but for me if you start nice -10 pd <your normal rgs> the pd-gui and watchdog inherit the priority. That's not what you really want. So then doing renice -10 PID on just the running pd is best. But that means looking for the PID after launch. Basicaly - give pd engine and Jack plenty of priority but less tp the GUI.
On Sat, 12 Aug 2006 13:10:47 -0400 "Chuckk Hubbard" badmuthahubbard@gmail.com wrote:
Interesting. I was going to just write this off, but maybe someone can explain it to me: I compiled a real-time kernel, according to http://demudi.agnula.org/wiki/Low-latencyKernelBuildingHowto I run Jack with realtime enabled, and run Pd with realtime enabled, and bring up Pd's test tone. I then click and drag the bar on the Pd test tone window, and move it in circles, and immediately start getting clicks and xruns. It doesn't handle my sequencer too well, either. Every time I ask what needs to be done, I get one step, which takes me a day to complete, and then find out I have to do another step. Is it really possible to have Linux set up so that all audio always gets done before anything else, without exception? It's frustrating that it works better for me in Windows after all these unproductive days.
-Chuckk
On 8/11/06, Michael Berkowski michael@berkowski.net wrote:
Hi all,
It's taken me a bit to narrow this down, and I haven't seen much in the archive related to this specifically, but I wondered if someone could shed some light on this GUI weirdness.
While running Pd with Jack, the GUI redraw when using the mouse is highly erratic. Typically, it will start out fine and I can move a slider or numberbox smoothly, but if I hold onto it for more than a few seconds, the redraw will start to pause and hang behind by increasing intervals. Meanwhile, there aren't any audio dropouts or xruns, just the slow GUI. No CPU spikes, either.
I have found that if I constantly run a metro and a flashing button, the problem goes away since the GUI is forced to redraw at least as often as the metro beats, but I'd like to avoid doing this.
I initially noticed this problem with the planetCCRMA pd and jack rpms (which are older versions, I think). But I have since recompiled Pd, Jack, and tcl/tk from source and the problem persists.
I'm using: 2.6.16-1.2080.13.rdt.rhfc4.ccrmasmp (FC4 jackd -R -d alsa -dhw:0 -r44100 -p2048 -n2 (doesn't seem to matter what jack params are used, RT or not) pd 0.39-2 compiled with alsa and jack support.
I'd be thankful if anyone has an ideas before I try upgrading the kernel as a last resort.
Best, Michael Berkowski
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- "Far and away the best prize that life has to offer is the chance to work hard at work worth doing." -Theodore Roosevelt
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ah. "Forget" isn't exactly the word, heh. Thanks for the tip, this seems to work. Grand idea, too.
One thing that is still happening, and I take it this isn't changeable: If I mouse over my score while it's playing, I get a string of skips, and "DIO errors" lights up. I guess this is just because I have pointers scanning a subpatch which has some sort of activity going on (i.e., mouse messages, even without any objects checking for mouse movement). I tried sending [tox score] a "capture 0" message whenever playback starts, but that wasn't it. It happens in both Windows and Linux. Is this just a fact of Pd life?
-Chuckk
On 8/13/06, padawan12 padawan12@obiwannabe.co.uk wrote:
Good old fashioned userland priority is what so many people seem to forget. nice -10 sorted out many problems with dropouts when moving windows etc. I'm not 100% sure about all systems but for me if you start nice -10 pd <your normal rgs> the pd-gui and watchdog inherit the priority. That's not what you really want. So then doing renice -10 PID on just the running pd is best. But that means looking for the PID after launch. Basicaly - give pd engine and Jack plenty of priority but less tp the GUI.
On Sat, 12 Aug 2006 13:10:47 -0400 "Chuckk Hubbard" badmuthahubbard@gmail.com wrote:
Interesting. I was going to just write this off, but maybe someone can explain it to me: I compiled a real-time kernel, according to http://demudi.agnula.org/wiki/Low-latencyKernelBuildingHowto I run Jack with realtime enabled, and run Pd with realtime enabled, and bring up Pd's test tone. I then click and drag the bar on the Pd test tone window, and move it in circles, and immediately start getting clicks and xruns. It doesn't handle my sequencer too well, either. Every time I ask what needs to be done, I get one step, which takes me a day to complete, and then find out I have to do another step. Is it really possible to have Linux set up so that all audio always gets done before anything else, without exception? It's frustrating that it works better for me in Windows after all these unproductive days.
-Chuckk
On 8/11/06, Michael Berkowski michael@berkowski.net wrote:
Hi all,
It's taken me a bit to narrow this down, and I haven't seen much in the archive related to this specifically, but I wondered if someone could shed some light on this GUI weirdness.
While running Pd with Jack, the GUI redraw when using the mouse is highly erratic. Typically, it will start out fine and I can move a slider or numberbox smoothly, but if I hold onto it for more than a few seconds, the redraw will start to pause and hang behind by increasing intervals. Meanwhile, there aren't any audio dropouts or xruns, just the slow GUI. No CPU spikes, either.
I have found that if I constantly run a metro and a flashing button, the problem goes away since the GUI is forced to redraw at least as often as the metro beats, but I'd like to avoid doing this.
I initially noticed this problem with the planetCCRMA pd and jack rpms (which are older versions, I think). But I have since recompiled Pd, Jack, and tcl/tk from source and the problem persists.
I'm using: 2.6.16-1.2080.13.rdt.rhfc4.ccrmasmp (FC4 jackd -R -d alsa -dhw:0 -r44100 -p2048 -n2 (doesn't seem to matter what jack params are used, RT or not) pd 0.39-2 compiled with alsa and jack support.
I'd be thankful if anyone has an ideas before I try upgrading the kernel as a last resort.
Best, Michael Berkowski
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- "Far and away the best prize that life has to offer is the chance to work hard at work worth doing." -Theodore Roosevelt
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Any idea why this would cause jack to refuse to connect Pd's audio output? I had the same issue I mentioned before, where quitting Pd left some ghost Pds in qjackctl's connection window. I ran ps -aux and killed all the Pd processes (after closing all the windows). They disappeared from qjackctl as I killed them. Now, starting Pd again and running #renice -10 [pd process], the output from alsa is routed automatically to Pd, but Pd's output isn't allowed to connect to ALSA; I tried from both Pd's Media menu and qjackctl. The wire appears for a second and disappears. jack's message window only says "Audio connection change" over and over from my trying to connect. ZynAddSubFx connects immediately. Ah- restarting jack corrected it. Hard to tell just where the bug is...
Sometimes it's the little flaws that keep a guy interested. -Chuckk
On 8/13/06, padawan12 padawan12@obiwannabe.co.uk wrote:
Good old fashioned userland priority is what so many people seem to forget. nice -10 sorted out many problems with dropouts when moving windows etc. I'm not 100% sure about all systems but for me if you start nice -10 pd <your normal rgs> the pd-gui and watchdog inherit the priority. That's not what you really want. So then doing renice -10 PID on just the running pd is best. But that means looking for the PID after launch. Basicaly - give pd engine and Jack plenty of priority but less tp the GUI.
On Sat, 12 Aug 2006 13:10:47 -0400 "Chuckk Hubbard" badmuthahubbard@gmail.com wrote:
Interesting. I was going to just write this off, but maybe someone can explain it to me: I compiled a real-time kernel, according to http://demudi.agnula.org/wiki/Low-latencyKernelBuildingHowto I run Jack with realtime enabled, and run Pd with realtime enabled, and bring up Pd's test tone. I then click and drag the bar on the Pd test tone window, and move it in circles, and immediately start getting clicks and xruns. It doesn't handle my sequencer too well, either. Every time I ask what needs to be done, I get one step, which takes me a day to complete, and then find out I have to do another step. Is it really possible to have Linux set up so that all audio always gets done before anything else, without exception? It's frustrating that it works better for me in Windows after all these unproductive days.
-Chuckk
On 8/11/06, Michael Berkowski michael@berkowski.net wrote:
Hi all,
It's taken me a bit to narrow this down, and I haven't seen much in the archive related to this specifically, but I wondered if someone could shed some light on this GUI weirdness.
While running Pd with Jack, the GUI redraw when using the mouse is highly erratic. Typically, it will start out fine and I can move a slider or numberbox smoothly, but if I hold onto it for more than a few seconds, the redraw will start to pause and hang behind by increasing intervals. Meanwhile, there aren't any audio dropouts or xruns, just the slow GUI. No CPU spikes, either.
I have found that if I constantly run a metro and a flashing button, the problem goes away since the GUI is forced to redraw at least as often as the metro beats, but I'd like to avoid doing this.
I initially noticed this problem with the planetCCRMA pd and jack rpms (which are older versions, I think). But I have since recompiled Pd, Jack, and tcl/tk from source and the problem persists.
I'm using: 2.6.16-1.2080.13.rdt.rhfc4.ccrmasmp (FC4 jackd -R -d alsa -dhw:0 -r44100 -p2048 -n2 (doesn't seem to matter what jack params are used, RT or not) pd 0.39-2 compiled with alsa and jack support.
I'd be thankful if anyone has an ideas before I try upgrading the kernel as a last resort.
Best, Michael Berkowski
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- "Far and away the best prize that life has to offer is the chance to work hard at work worth doing." -Theodore Roosevelt
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Chuckk Hubbard -
Michael Berkowski -
Miller Puckette -
padawan12 -
Roman Haefeli