Perhaps. But I was definitely able to manually bump the priority without sudo.I don't doubt that you can manually bump the priority; that doesn't necessarily mean that Pd itself can do it.
BTW, if Pd fails to raise the thread priority to RT, you should get the following error message in the Pd console:
"priority %d scheduling failed; running at normal priority"
1 - the PD UI will absolutely kill performanceThe Pd GUI runs as a separate process with lower priority. If you mean the actual network I/O for core <-> GUI communication, then I don't see how running Pd in callback mode would improve this - on the contrary!
If GUI network I/O really is a problem in your patches, then https://github.com/pure-data/pure-data/pull/1261 would be a proper solution.
2 - because of 1, plan to run the sound gen in [pd~]The parent and child processes communicate via pipes, which is very similar to how the scheduler and audio callback communicate in polling mode. I'm pretty sure that the overall effect is the same.
NB: the default buffersize for [pd~] is 5 blocks (6.6 ms @ 48 kHz).
In general, it doesn't really make sense to run *all* DSP in
[pd~]; instead, just use the standard polling mode and raise
"delay" accordingly.
If you are really unable to get a clean signal in polling mode,
even with high "delay" settings, please file a bug report at
GitHub. It may very well be an issue with your computer/OS. Did
you try other machines?
BTW, you might also try my scheduler updates which, among other things, improves the responsiveness of the scheduler in polling mode: https://github.com/pure-data/pure-data/pull/1756
And now you know why I want multi-threaded pd audio.I definitely appreciate the interest :) but I think that multi-threaded DSP is really orthogonal to the problem you have described in your last e-mail.
Christof
On Wed, 23 Aug 2023 at 23:24, Christof Ressi <info@christofressi.com> wrote:
I actually get fewer xruns in callback mode,This sounds highly unlikely. Maybe your "delay" setting is too low? Or Pd is not actually running with realtime priority?
I spent a lot of time testing this on an ancient laptop running a fairly modern kernel because I was deeply frustrated with general PD performance on that machine. "unlikely" it may have been. True, it most certainly was.
I also bump the sound-generation process up to realtime priority.Pd itself already tries to raise the thread priority; if this fails, you might not have sufficient permissions.
Perhaps. But I was definitely able to manually bump the priority without sudo. I did a *lot* of system optimization trying to squeeze good performance out of various moderately complicated physical models. From thisI learned a few things:
1 - the PD UI will absolutely kill performance
2 - because of 1, plan to run the sound gen in [pd~]
3 - pd patch and file lookup is a nightmare, especially in [pd~]
4 - real-time priority + callbacks usually produces clean sound on a clean system
And now you know why I want multi-threaded pd audio.
- d
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev