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 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 wrote:

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.

so what would you not do, then?

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.

i think (and could be badly mistaken) that the results of your research might be a bit outdated. on the one hand there have been huge improvements to lower latency in the kernel with recent releases, and at the same time there have been improvements on how to make realtime capabilities accessible by the ordinary (non-root) user.

personally i don't think you need any more voodoo on recent systems. if you are still running a debian woody on 2.4.18, you might experience benefits though (some users are extremely conservative when it comes to os upgrading; how many of you w32 people are still running W98?)

fgmadr IOhannes

Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote:

that's entirely possible. This research was done over a year 3-4 years ago. It's good that things have improved since then ;-)

Definitely: The version of PAM, that makes it trivial to allow non-root users to gain realtime priviledges, was introduced in the major distributions about 0.5 or 0.75 years ago. Before that, exotic things like realtime-lsm, jackstart or so had to be used. But that's history now and there's no convincing reason to run Pd as root on current distributions. (There are several reasons to not do so.)

Ciao

Frank Barknecht _ ______footils.org__

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

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.

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...

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

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