[PD] isn't the GUI supposed to have lower priority than process?

[Stephen Sinclair]

> > - using Jack in RT mode
> > - increasing buffer size
> > - using dual-core computer
> > - using "renice" on the pd process
>
> this suggestions won't solve the mentioned problems for sure (besides
> increasing the buffer to a huge amount). since the problems arise
> withing pd itself, you cannot solve them by giving pd the highest
> priority. these suggestions do help, when switching workspaces cause
> drop outs for example or when any other software is disturbing the
> processing of pd.

but in pd, the audio and the gui are in separate processes:

$ ps -A f
 6358 pts/0    Ss     0:00  \_ bash
 6368 pts/0    S+     0:00  |   \_ pd -alsa -alsamidi
 6369 pts/0    S+     0:00  |       \_ sh -c TCL_LIBRARY="/home/ssteve/.local/li
 6370 pts/0    Sl+    0:00  |           \_ /home/ssteve/.local/lib/pd/bin/pd-gui

using renice on the audio process or running it in RT mode should
indeed make a difference.
(i'm talking specifically about Linux, but it should apply to other
OS's as well.)

you could even try running the audio and gui processes on different computers.

for a performance environment, you could just discard the GUI and
control everything through OSC remotely.


> the problem is, that pd does *everything* in zero logical time, that is
> why reading/files can lead to dropouts: it is just not possible to read
> a 30MB file in no time.

I agree, I was only referring to the GUI-related problems.
File reading could definitely benefit from being in a thread, I think
this could be done in an external without too much difficulty.  Though
another idea is to load the file in chunks, so that only parts of it
are loaded on each cycle, giving a chance for audio to run in between.

I'm not sure if readsf~ does this already.


Steve