Re: [PD] pd clicking with jack/linux
Hello list. I am getting the exact same issue mentioned by Atte Jensen. Was there ever a solution? I've already tried all of the typical optimizations: rt-kernel, rt-priorities straight, tinkering with jack settings, etc. I get this even with the built-in test audio/midi patch. Atte-- are you running 64bit ubuntu? Thanks, JP Hi I get clicks and DIO errors at random intervals under linux/ubuntu with jack (no xruns). I have a 17ms latency setup with jack and a realtime patched kernel and the rest of my audio setup works great with jack. I installed pd from Pd-0.40.3-extended-20080628-ubuntu-gutsy-i386.deb Any one else running a similar pd with a similar setup and either have it working or experience the same problems? -- peace, love harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://modlys.dk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: On Tue, 2008-07-01 at 00:32 +0200, Derek Holzer wrote: I run PD as root (not sudo, but real root) for click-free operation. But Ubuntu has this weird thing where you can't be root, you can only sudo. Very strange... anyways, worth a try. of course, you can become 'real' root on ubuntu as well: sudo su Or sudo -i or sudo -s Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
On Tue, 2008-07-01 at 00:32 +0200, Derek Holzer wrote: I run PD as root (not sudo, but real root) for click-free operation. But Ubuntu has this weird thing where you can't be root, you can only sudo. Very strange... anyways, worth a try. of course, you can become 'real' root on ubuntu as well: sudo su pd (which still should be the same as 'sudo pd') or you could give the user 'root' a password so that you simply do: su pd roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
On Mon, 2008-06-30 at 13:48 -0400, patrick wrote: hi, i don't use pd-extended, but i think it's almost the same. the only option missing is: -nosleep (useful for dual-core). so be sure in qjackctl - setup: Realtime Periods/Buffer: 2 Sample Rate: 44100 (or more) Frames/Period: 256 (i am running at 64 without glitches) then for pd: pd -rt -jack -r 44100 -nosleep -audiobuf 256 -channels 16 -alsamidi -mididev 1 etc... from my experience, there is no point in specifying the samplerate, since pd automatically uses the one used by jackd: you cannot force pd to use a different sr. i wonder, if the same goes for -audiobuf roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
Atte André Jensen wrote: patrick wrote: 1) pd -? says -audiobuf is in ms, so 256 wouldn't make sense, or...? why shouldn't it make sense? 256ms is justas valid as 7ms 2) I thought that jack clients automatically got the same buffer size as jack, which means that is doesn't make sense (or any difference) to afaik this is correct. Pd will silently ignore the audiobuf flag when using jack as backend (butthen i don't use jack so often so i might be mistaken here) specify that for the client. Same with -rt, I thought that clients enherited the realtime priority from jack... i don't think so. even if the dsp calculations are callback-driven by jack, you still have all the message stuff going on. additionally, in older versions of Pd (0.41?) the jack-callback will actually not trigger the dsp-processing but rather only read a buffer the contents of which have been calculated with Pd's priority. i think this has changed with 0.41, but haven't had a deeper look at the code yet. mfg.asdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
IOhannes m zmoelnig wrote: Atte André Jensen wrote: patrick wrote: 1) pd -? says -audiobuf is in ms, so 256 wouldn't make sense, or...? why shouldn't it make sense? 256ms is justas valid as 7ms Because he's building a commandline to match a jacksetup of Frames/Period: 256... specify that for the client. Same with -rt, I thought that clients enherited the realtime priority from jack... i don't think so. even if the dsp calculations are callback-driven by jack, you still have all the message stuff going on. I tried with and without -rt and -rt seems to work better, so maybe you're right. -- peace, love harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://modlys.dk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
Atte André Jensen wrote: IOhannes m zmoelnig wrote: Atte André Jensen wrote: patrick wrote: 1) pd -? says -audiobuf is in ms, so 256 wouldn't make sense, or...? why shouldn't it make sense? 256ms is justas valid as 7ms Because he's building a commandline to match a jacksetup of Frames/Period: 256... aye see. since it is ignored anyhow, no harm is done however... fgamsrd IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote: I run PD as root (not sudo, but real root) for click-free operation. But Ubuntu has this weird thing where you can't be root, you can only sudo. Very strange... anyways, worth a try. Ubuntu doesn't enable root logins. If you set up your system as Patrick described there should be no difference at all between running as root or running as an audio user. I never run Pd as root. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
And if waving a dead chicken over the laptop would have been empirically proven before my own eyes to get better performance, I would have done that too. I don't remember how exactly I arrived at my choice of distro, kernel flags, window manager or decision to run all critical audio apps as root. Bad geek that I am. But I can say I spent a year (back when I was a good geek and cared about this stuff) researching how to get the best I could out of PD + Linux on my own hardware and for my own purposes, and these are the things I learned. Laugh if you like. d. ydegoyon wrote: Derek Holzer wrote: I run PD as root (not sudo, but real root) do you think there is a difference? ok we enter mysticism, do you burn some incent too before starting your machine_? well, hey sevy -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 45: Disciplined self-indulgence ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
patrick wrote: hi, Hi. Thanks for the reply! Basically I think my problems came from using array (and not table) to store a sample. Pd gave DIO errors when switching to the window containing the patch. Is this normal, and is there a way to avoid it, for instance running the gui in a separate thread? After switching to table (with very little testing, though) everything seems to work just fine :-) So the rest of this mail is releated to a patch using the problematic array!!! i don't use pd-extended, but i think it's almost the same. the only option missing is: -nosleep (useful for dual-core). I'm on a single core, so I guess -nosleep doesn't matter, right? so be sure in qjackctl - setup: Realtime Periods/Buffer: 2 Sample Rate: 44100 (or more) Frames/Period: 256 (i am running at 64 without glitches) Something like that, although periods/buffer is 3 here (seems to work better in general with my sound card). then for pd: pd -rt -jack -r 44100 -nosleep -audiobuf 256 -channels 16 -alsamidi -mididev 1 etc... Confused! 1) pd -? says -audiobuf is in ms, so 256 wouldn't make sense, or...? 2) I thought that jack clients automatically got the same buffer size as jack, which means that is doesn't make sense (or any difference) to specify that for the client. Same with -rt, I thought that clients enherited the realtime priority from jack... and finally, be sure to edit /etc/security/limits.conf: @audio - rtprio 99 @audio - memlock unlimited @audio - nice-20 and of course, add yourself to audio group (reboot to be sure). let us know. I already had that (or something *very* similar). ah yes, a long time ago i was using icewm, because gnome was causing glitches in pd. but now it seems ok here. I now tried with openbox (lighter than icewm) and the problem is the same. -- peace, love harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://modlys.dk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
Hallo, Atte André Jensen hat gesagt: // Atte André Jensen wrote: Basically I think my problems came from using array (and not table) to store a sample. Pd gave DIO errors when switching to the window containing the patch. Is this normal, and is there a way to avoid it, for instance running the gui in a separate thread? It already runs even in a separate process from the audio engine. But both are tied together very closely and communicate a lot with each other, which leads to dropouts on gfx-intensive operations e.g. moving a lot ob objects or displaying and updating large graphical arrays. Use [table] everyhwere, you don't need to see the data, and avoid graphical objects for debugging in performance situations, only use them to input data. I.e. this is bad: [r something] | [bng] | [s something-else] this is better: [r something] |\ | [bng] | [s something-else] because you can easily make this out of it: [r something] | | | [s something-else] and if you want to be fancy, use something like this: [r DEBUG] | | [spigot] | [bng] to make debugging switchable on the fly. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
Frank Barknecht wrote: It already runs even in a separate process from the audio engine. But both are tied together very closely and communicate a lot with each other, which leads to dropouts on gfx-intensive operations e.g. moving a lot ob objects or displaying and updating large graphical arrays. Ok. Use [table] everyhwere, you don't need to see the data, and avoid graphical objects for debugging in performance situations, only use them to input data. Thanks for the info, very clear, I think I got a better sense of tos and not-tos... -- peace, love harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://modlys.dk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
Date: Tue, 1 Jul 2008 15:46:57 +0200 From: Frank Barknecht [EMAIL PROTECTED] Subject: Re: [PD] pd clicking with jack/linux To: pd-list@iem.at Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-15 Hallo, Atte Andr? Jensen hat gesagt: // Atte Andr? Jensen wrote: Basically I think my problems came from using array (and not table) to store a sample. Pd gave DIO errors when switching to the window containing the patch. Is this normal, and is there a way to avoid it, for instance running the gui in a separate thread? It already runs even in a separate process from the audio engine. But both are tied together very closely and communicate a lot with each other, which leads to dropouts on gfx-intensive operations e.g. moving a lot ob objects or displaying and updating large graphical arrays. Use [table] everyhwere, you don't need to see the data, and avoid graphical objects for debugging in performance situations, only use them to input data. I.e. this is bad: [r something] | [bng] | [s something-else] this is better: [r something] |\ | [bng] | [s something-else] because you can easily make this out of it: [r something] | | | [s something-else] and if you want to be fancy, use something like this: [r DEBUG] | | [spigot] | [bng] to make debugging switchable on the fly. Ciao -- Frank Barknecht _ __footils.org__ Thanks, this is all great advice. Incidentally, I think the cpu usage with graphical objects is even worse on OSX, so if you want your patches to be cross-platform, it's best to optimize them not to include too many (vu meters are the worst, but you can improve them based on arguments you give to [env~], if you're using that to drive them). Depending on what your patch does, you can often put much of the engine of your patch in subpatches, and then make a control surface with sends and receives. Those can be split up, too: for instance if you have the need for a mixer and a reverb module, the surfaces for those things can be put in different subpatches so that they only take up cpu when you decide to have them open to use them. Also, it's a good idea to avoid the sprawling, spider-webby max-msp-like patches you might often see (due, I think in max, to the bendable and hideable patch cables, so you'll be less tempted in Pd)-- you can significantly improve the organization of your patch by using subpatches to group your objects into different modules. And modules that you use more than once or twice in a given patch you can make into abstractions and use more or less like regular objects. Thanks, Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
Matt Barber wrote: Incidentally, I think the cpu usage with graphical objects is even worse on OSX, A minor quibble which does not invalidate your point: dual-core Macs don't suffer from this, as the graphics process gets its own CPU -- at least this is my empirical observation. I have a great deal going on graphically in my patches, including VU meters, and it doesn't affect the CPU usage as measured by Pd, which seems to report either just the audio process CPU, or perhaps the most-loaded CPU (which is also the audio one in my case) in a dual-core situation. so if you want your patches to be cross-platform, it's best to optimize them not to include too many (vu meters are the worst, but you can improve them based on arguments you give to [env~], if you're using that to drive them). Depending on what your patch does, you can often put much of the engine of your patch in subpatches, and then make a control surface with sends and receives. Those can be split up, too: for instance if you have the need for a mixer and a reverb module, the surfaces for those things can be put in different subpatches so that they only take up cpu when you decide to have them open to use them. That's a good design principle. I just wish there were an easy one-click way to open subpatches while performing. There are some hacks, but nothing standard, as far as I know. Also, it's a good idea to avoid the sprawling, spider-webby max-msp-like patches you might often see (due, I think in max, to the bendable and hideable patch cables, so you'll be less tempted in Pd)-- you can significantly improve the organization of your patch by using subpatches to group your objects into different modules. And modules that you use more than once or twice in a given patch you can make into abstractions and use more or less like regular objects. Excellent advice. It's much easier to maintain and optimize patches organized this way as well. Try going back and understanding a spider web you made two years ago! Phil Stone pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
On Tue, Jul 1, 2008 at 12:15 PM, Phil Stone [EMAIL PROTECTED] wrote: Matt Barber wrote: Incidentally, I think the cpu usage with graphical objects is even worse on OSX, A minor quibble which does not invalidate your point: dual-core Macs don't suffer from this, as the graphics process gets its own CPU -- at least this is my empirical observation. I have a great deal going on graphically in my patches, including VU meters, and it doesn't affect the CPU usage as measured by Pd, which seems to report either just the audio process CPU, or perhaps the most-loaded CPU (which is also the audio one in my case) in a dual-core situation. This may be true, but the graphics are still more expensive than other operating systems. At any rate in OSX you can look in the output of top from a terminal; you'll see two processes, and they do seem to be separately allocated as you suggest. so if you want your patches to be cross-platform, it's best to optimize them not to include too many (vu meters are the worst, but you can improve them based on arguments you give to [env~], if you're using that to drive them). Depending on what your patch does, you can often put much of the engine of your patch in subpatches, and then make a control surface with sends and receives. Those can be split up, too: for instance if you have the need for a mixer and a reverb module, the surfaces for those things can be put in different subpatches so that they only take up cpu when you decide to have them open to use them. That's a good design principle. I just wish there were an easy one-click way to open subpatches while performing. There are some hacks, but nothing standard, as far as I know. If you have a subpatch, say [pd GUI-mixer], you can send it a vis 1 message: [vis 1 ( | [send pd-GUI-mixer] vis 0 closes. You can put all of this in this kind of message: ; pd-GUI-mixer vis 1 You can then put a graphical bng or tgl on the main surface and route it to that message somewhere in a subpatch (I often put the GUI control stuff in a separate module). Also, it's a good idea to avoid the sprawling, spider-webby max-msp-like patches you might often see (due, I think in max, to the bendable and hideable patch cables, so you'll be less tempted in Pd)-- you can significantly improve the organization of your patch by using subpatches to group your objects into different modules. And modules that you use more than once or twice in a given patch you can make into abstractions and use more or less like regular objects. Excellent advice. It's much easier to maintain and optimize patches organized this way as well. Try going back and understanding a spider web you made two years ago! Exactly. It also helps you organize hierarchically from global design down to implementation, which is very useful for the optimization as you suggest. It's not always as useful if your design isn't hierarchical, but it still helps remove things from the screen, making things easier to follow. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
Matt Barber wrote: On Tue, Jul 1, 2008 at 12:15 PM, Phil Stone [EMAIL PROTECTED] wrote: Matt Barber wrote: Depending on what your patch does, you can often put much of the engine of your patch in subpatches, and then make a control surface with sends and receives. Those can be split up, too: for instance if you have the need for a mixer and a reverb module, the surfaces for those things can be put in different subpatches so that they only take up cpu when you decide to have them open to use them. That's a good design principle. I just wish there were an easy one-click way to open subpatches while performing. There are some hacks, but nothing standard, as far as I know. If you have a subpatch, say [pd GUI-mixer], you can send it a vis 1 message: [vis 1 ( | [send pd-GUI-mixer] vis 0 closes. You can put all of this in this kind of message: ; pd-GUI-mixer vis 1 You can then put a graphical bng or tgl on the main surface and route it to that message somewhere in a subpatch (I often put the GUI control stuff in a separate module). Thank you for the excellent tip, Matt. I shall try this out. Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
Hallo, Matt Barber hat gesagt: // Matt Barber wrote: Depending on what your patch does, you can often put much of the engine of your patch in subpatches, and then make a control surface with sends and receives. Note that GUI objects even in subpatches can lead to more CPU use. At least I once managed to make a patch perform much better by removing a lot of [bng] objects hidden in abstractions or subpatches. The example is somehwere in the list archive, maybe I can find it again. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
I'm on a single core, so I guess -nosleep doesn't matter, right? exactly then for pd: pd -rt -jack -r 44100 -nosleep -audiobuf 256 -channels 16 -alsamidi -mididev 1 etc... Confused! 1) pd -? says -audiobuf is in ms, so 256 wouldn't make sense, or...? 2) I thought that jack clients automatically got the same buffer size as jack, which means that is doesn't make sense (or any difference) to specify that for the client. Same with -rt, I thought that clients enherited the realtime priority from jack... -audiobuf in ms... hum, so maybe you are right about jack clients getting the same buffer size. anyone? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
Date: Tue, 1 Jul 2008 23:23:44 +0200 From: Frank Barknecht [EMAIL PROTECTED] Subject: Re: [PD] pd clicking with jack/linux To: pd-list@iem.at Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Hallo, Matt Barber hat gesagt: // Matt Barber wrote: Depending on what your patch does, you can often put much of the engine of your patch in subpatches, and then make a control surface with sends and receives. Note that GUI objects even in subpatches can lead to more CPU use. At least I once managed to make a patch perform much better by removing a lot of [bng] objects hidden in abstractions or subpatches. The example is somehwere in the list archive, maybe I can find it again. I don't know the code well enough, but I could imagine the following: What would happen to the CPU usage if you had replaced the [bng] objects with [bang] objects? Or is the architecture such that an object only computes if its outlet is connected to something? If that's the case, I could imagine that another difference between [bang] and [bng] might be that the [bng] always has to compute the bang whether or not its outlet is connected -- maybe it would have more to do with this than just its being graphical. But really I don't know, just speculating late at night. Thanks, Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pd clicking with jack/linux
Hi I get clicks and DIO errors at random intervals under linux/ubuntu with jack (no xruns). I have a 17ms latency setup with jack and a realtime patched kernel and the rest of my audio setup works great with jack. I installed pd from Pd-0.40.3-extended-20080628-ubuntu-gutsy-i386.deb Any one else running a similar pd with a similar setup and either have it working or experience the same problems? -- peace, love harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://modlys.dk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
I run PD as root (not sudo, but real root) for click-free operation. But Ubuntu has this weird thing where you can't be root, you can only sudo. Very strange... anyways, worth a try. I also use fluxbox with very little else going on in the GUI. Spent almost a year tuning Linux to get really optimum performance for live gigs and recording situations, really the idea is that less is more. Ubuntu/Red Hat/SuSE etc just have too many processes (especially graphical ones that cause interruptions) running at once, IMHO. best, D. patrick wrote: hi, i don't use pd-extended, but i think it's almost the same. the only option missing is: -nosleep (useful for dual-core). so be sure in qjackctl - setup: Realtime Periods/Buffer: 2 Sample Rate: 44100 (or more) Frames/Period: 256 (i am running at 64 without glitches) then for pd: pd -rt -jack -r 44100 -nosleep -audiobuf 256 -channels 16 -alsamidi -mididev 1 etc... and finally, be sure to edit /etc/security/limits.conf: @audio - rtprio 99 @audio - memlock unlimited @audio - nice-20 and of course, add yourself to audio group (reboot to be sure). let us know. ah yes, a long time ago i was using icewm, because gnome was causing glitches in pd. but now it seems ok here. pat Atte André Jensen wrote: Hi I get clicks and DIO errors at random intervals under linux/ubuntu with jack (no xruns). I have a 17ms latency setup with jack and a realtime patched kernel and the rest of my audio setup works great with jack. I installed pd from Pd-0.40.3-extended-20080628-ubuntu-gutsy-i386.deb Any one else running a similar pd with a similar setup and either have it working or experience the same problems? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 97: Is the style right? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
I would check which processes are running on the background, Ubuntu has scheduled some processes that interfere with the sound process. In my laptop it was specially problematic updatedb and some wifi related processes. Now I only get problems when i use the realtime kernel. the normal one works fine enough for me. enrike Derek Holzer(e)k dio: I run PD as root (not sudo, but real root) for click-free operation. But Ubuntu has this weird thing where you can't be root, you can only sudo. Very strange... anyways, worth a try. I also use fluxbox with very little else going on in the GUI. Spent almost a year tuning Linux to get really optimum performance for live gigs and recording situations, really the idea is that less is more. Ubuntu/Red Hat/SuSE etc just have too many processes (especially graphical ones that cause interruptions) running at once, IMHO. best, D. patrick wrote: hi, i don't use pd-extended, but i think it's almost the same. the only option missing is: -nosleep (useful for dual-core). so be sure in qjackctl - setup: Realtime Periods/Buffer: 2 Sample Rate: 44100 (or more) Frames/Period: 256 (i am running at 64 without glitches) then for pd: pd -rt -jack -r 44100 -nosleep -audiobuf 256 -channels 16 -alsamidi -mididev 1 etc... and finally, be sure to edit /etc/security/limits.conf: @audio - rtprio 99 @audio - memlock unlimited @audio - nice-20 and of course, add yourself to audio group (reboot to be sure). let us know. ah yes, a long time ago i was using icewm, because gnome was causing glitches in pd. but now it seems ok here. pat Atte André Jensen wrote: Hi I get clicks and DIO errors at random intervals under linux/ubuntu with jack (no xruns). I have a 17ms latency setup with jack and a realtime patched kernel and the rest of my audio setup works great with jack. I installed pd from Pd-0.40.3-extended-20080628-ubuntu-gutsy-i386.deb Any one else running a similar pd with a similar setup and either have it working or experience the same problems? ___ 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
Re: [PD] pd clicking with jack/linux
I don't use ubuntu either, but out of curiosity, what happens if you run: sudo su - ?? Matt Date: Tue, 01 Jul 2008 00:32:12 +0200 From: Derek Holzer [EMAIL PROTECTED] Subject: Re: [PD] pd clicking with jack/linux To: patrick [EMAIL PROTECTED] Cc: pure data pd-list@iem.at Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed I run PD as root (not sudo, but real root) for click-free operation. But Ubuntu has this weird thing where you can't be root, you can only sudo. Very strange... anyways, worth a try. I also use fluxbox with very little else going on in the GUI. Spent almost a year tuning Linux to get really optimum performance for live gigs and recording situations, really the idea is that less is more. Ubuntu/Red Hat/SuSE etc just have too many processes (especially graphical ones that cause interruptions) running at once, IMHO. best, D. patrick wrote: hi, i don't use pd-extended, but i think it's almost the same. the only option missing is: -nosleep (useful for dual-core). so be sure in qjackctl - setup: Realtime Periods/Buffer: 2 Sample Rate: 44100 (or more) Frames/Period: 256 (i am running at 64 without glitches) then for pd: pd -rt -jack -r 44100 -nosleep -audiobuf 256 -channels 16 -alsamidi -mididev 1 etc... and finally, be sure to edit /etc/security/limits.conf: @audio - rtprio 99 @audio - memlock unlimited @audio - nice-20 and of course, add yourself to audio group (reboot to be sure). let us know. ah yes, a long time ago i was using icewm, because gnome was causing glitches in pd. but now it seems ok here. pat Atte Andr? Jensen wrote: Hi I get clicks and DIO errors at random intervals under linux/ubuntu with jack (no xruns). I have a 17ms latency setup with jack and a realtime patched kernel and the rest of my audio setup works great with jack. I installed pd from Pd-0.40.3-extended-20080628-ubuntu-gutsy-i386.deb Any one else running a similar pd with a similar setup and either have it working or experience the same problems? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 97: Is the style right? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
Derek Holzer wrote: I run PD as root (not sudo, but real root) do you think there is a difference? ok we enter mysticism, do you burn some incent too before starting your machine_? well, hey sevy ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
