This has nothing to do with callback mode, as such. it is a general
performance note included to illustrate the various things that I
discovered, often with much debugging of PD itself, which affect
performance.
Ok, I see. Note that *receiving* messages is more or less fine because
the I/O happens with select() and therefore essentially non-blocking.
The problem is *sending* messages. The proper solution is to move
network I/O to a dedicated thread
(https://github.com/pure-data/pure-data/pull/1261), but I guess one
could mitigate the problem by increasing the socket send buffer size, so
that send() is less likely to block.
--
yet you tell me that the main remedy is to increase lag?
The main remedy is to get a better computer :) Most importantly, a CPU
with strong single-thread performance and good ventilation to prevent
throttling. Also, make sure to set the energy manager to highest
performance.
Many users (including myself) manage to run Pd with latencies below 10ms
- which I would consider suitable for live performance. I was mainly
questioning your claim that you cannot get a clean output with the
polling mode *at all*.
That being said, the current polling mode implementation *does* have a
few problems - which I am trying to address with
https://github.com/pure-data/pure-data/pull/1756.
--
The most effective single change was the change to [pd~]
Again, this just adds another layer of buffering. I am not surprised
that you see more stable performance, but you should get the same effect
with the polling scheduler. Please try my scheduler-fix branch above!
--
Running the audio DSP in an execution context separate from UI
messaging seems to me to be a crucial performance improvement for PD.
My experience with [pd~] certainly shows that. I would hope that a
separately threaded DSP engine would do the same.
Multi-threaded DSP only lets you distribute the *DSP* CPU load over
several cores. It does not affect CPU spikes caused by messaging or I/O
operations. While the latter *can* be moved to dedicated threads, Pd
messages always execute in the same thread as DSP by design;
multi-threaded DSP does not change that. The idea of the polling
scheduler is that you add some additional buffering to "absorb" CPU
spikes caused by the messaging system. The required delay really depends
on the patch in question and the system in general.
Now, you *can* also use the callback scheduler with a large enough
"block size" (= hardware buffer size) instead, but you are limited to
power-of-two values. For example, if 512 samples just does not cut it,
you are forced to move to 1024; there is no room in between. With the
polling scheduler, however, you can set the delay at a much finer
granularity. Typically, you would set the "block size" to the lowest
possible value (with a good machine and audio interface, 64 samples
should be possible), and then adjust the "delay" as necessary.
Christof
On 24.08.2023 16:48, Day Rush wrote:
On Thu, 24 Aug 2023 at 14:12, Christof Ressi <i...@christofressi.com>
wrote:
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"
I don't recall seeing that on the console, but I may have seen it on
stdout once or twice.
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!
This has nothing to do with callback mode, as such. it is a general
performance note included to illustrate the various things that I
discovered, often with much debugging of PD itself, which affect
performance.
2 - because of 1, plan to run the sound gen in [pd~]
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.
This is a very disappointing answer. I really keep hoping to get away
from static composition and move towards live performance, and yet you
tell me that the main remedy is to increase lag? Is PD really just
CSound with a better sound design workflow?
It may very well be an issue with your computer/OS. Did you try
other machines?
As I said earlier, it was quite an old laptop, and the composition had
a lot of physically modelled voices. My Win laptop was unilaterally
upgraded to Win11 by u$oft and ceased to perform well at anything
other than playing video, so I kind of left it behind. The list I
provided gave me nice clean sound. The most effective single change
was the change to [pd~]. I will freely grant the possibility that the
re-architecture of my program necessary to run in that environment may
have improved performance, but that still points to UI (and the
attendant clunky communication) issues as being a primary performance
problem. Running the audio DSP in an execution context separate from
UI messaging seems to me to be a crucial performance improvement for
PD. My experience with [pd~] certainly shows that. I would hope that a
separately threaded DSP engine would do the same.
_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
