[PD-dev] why must one never send a message from a perform routine ?

[Christof Ressi]

> 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 performance
The 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 24.08.2023 14:14, Day Rush wrote:
> On Wed, 23 Aug 2023 at 23:24, Christof Ressi <info at 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 this
> I 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 at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230824/11d6cab6/attachment.htm>