Hello Pd community,
I've encountered an interesting behavior regarding CPU management in Pure Data using [pd~], and I'd appreciate your insights or confirmations.
Here's my scenario:
I'm running a computationally "intensive" FFT analysis with sigmund~ (similar to the 17.partialtracer example, but without using data structures), on a 4-second audio array. This analysis is causing "Audio I/O Error" warnings and audible dropouts when executed within the main Pd patch, DSP active, latency ~50ms... Increasing the latency further would solve the problem, but I would like to find another solution.
Initially, I attempted to resolve this by offloading the computation into a subprocess via [pd~]. However, despite what seemed to be a correct configuration (no audio signals shared, only control messages exchanged, -nogui option used), I still observed audio dropouts and "Audio I/O Error" warnings in the main patch.
otherwise when running two completely separate instances of Pd manually, that is two versions of Pd, 0.55-1 and 0.55-2 (one dedicated to real-time audio and another solely for the FFT analysis, without using [pd~]), my system (macOS Apple Silicon M3) handled both processes simultaneously without any audio dropouts or errors.
This behavior suggests to me that perhaps the subprocess initiated by [pd~] might not provide complete isolation at the OS level, potentially causing implicit timing interactions leading to audio dropouts. Conversely, manually running two independent Pd instances seems to solve the problem... would this be the best way (using OSC)?
I'm curious if others have had similar experiences or can offer any clarification or alternative configurations to better achieve isolation within a single Pd instance.
Thanks very much in advance for your thoughts!
Best regards, Pierpaolo Barbiero
Hi,
the subprocess managed by the [pd~] object is "driven" by the parent process (= the main Pd process). If the subprocess blocks, so does the parent process! However, one thing you can do is increase the FIFO size (-fifo) to give the subprocess more "leeway".
Are you doing the FFT on the whole audio file at once? If you are doing large computations that interrupt audio processing, one key technique is to spread the computation over multiple scheduler ticks.
Christof
On 23.03.2025 21:27, Pier Bar wrote:
Hello Pd community,
I've encountered an interesting behavior regarding CPU management in Pure Data using [pd~], and I'd appreciate your insights or confirmations.
Here's my scenario:
I'm running a computationally "intensive" FFT analysis with sigmund~ (similar to the 17.partialtracer example, but without using data structures), on a 4-second audio array. This analysis is causing "Audio I/O Error" warnings and audible dropouts when executed within the main Pd patch, DSP active, latency ~50ms... Increasing the latency further would solve the problem, but I would like to find another solution.
Initially, I attempted to resolve this by offloading the computation into a subprocess via [pd~]. However, despite what seemed to be a correct configuration (no audio signals shared, only control messages exchanged, -nogui option used), I still observed audio dropouts and "Audio I/O Error" warnings in the main patch.
otherwise when running two completely separate instances of Pd manually, that is two versions of Pd, 0.55-1 and 0.55-2 (one dedicated to real-time audio and another solely for the FFT analysis, without using [pd~]), my system (macOS Apple Silicon M3) handled both processes simultaneously without any audio dropouts or errors.
This behavior suggests to me that perhaps the subprocess initiated by [pd~] might not provide complete isolation at the OS level, potentially causing implicit timing interactions leading to audio dropouts. Conversely, manually running two independent Pd instances seems to solve the problem... would this be the best way (using OSC)?
I'm curious if others have had similar experiences or can offer any clarification or alternative configurations to better achieve isolation within a single Pd instance.
Thanks very much in advance for your thoughts!
Best regards, Pierpaolo Barbiero
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/LYWOFX3EA6...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
[...]
Are you doing the FFT on the whole audio file at once? If you are doing large computations that interrupt audio processing, one key technique is to spread the computation over multiple scheduler ticks.
How would you go about to spread it over multiple ticks Christof?
thanks! P
In this case, just analyze the table piece-wise with a [metro]. The list method takes the following arguments:
<table name> <number of points to analyze> <starting point> <sample rate>
You can use <number of points> and <starting point> to analyze a particular section of a table. The help patch of [sigmund~] contains an example.
Christof
On 24.03.2025 14:37, Peter P. wrote:
- Christof Ressi info@christofressi.com [2025-03-24 14:34]:
[...]
Are you doing the FFT on the whole audio file at once? If you are doing large computations that interrupt audio processing, one key technique is to spread the computation over multiple scheduler ticks.
How would you go about to spread it over multiple ticks Christof?
thanks! P
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/YCPSAOIGTI...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Dear Pierpaolo,
not an expert on this issue but...
Hello Pd community,
I've encountered an interesting behavior regarding CPU management in Pure Data using [pd~], and I'd appreciate your insights or confirmations.
Here's my scenario:
I'm running a computationally "intensive" FFT analysis with sigmund~ (similar to the 17.partialtracer example, but without using data structures), on a 4-second audio array. This analysis is causing "Audio I/O Error" warnings and audible dropouts when executed within the main Pd patch, DSP active, latency ~50ms... Increasing the latency further would solve the problem, but I would like to find another solution.
...are you able to track the single Pd instance audio errors down to CPU usage? Does a simpler patch with lower cpu usage not print these errors?
Have you tried to change other audio options?
I am not on OS X so I don't know if -callback or -rt have any effect there.
Initially, I attempted to resolve this by offloading the computation into a subprocess via [pd~]. However, despite what seemed to be a correct configuration (no audio signals shared, only control messages exchanged, -nogui option used), I still observed audio dropouts and "Audio I/O Error" warnings in the main patch.
otherwise when running two completely separate instances of Pd manually, that is two versions of Pd, 0.55-1 and 0.55-2 (one dedicated to real-time audio and another solely for the FFT analysis, without using [pd~]), my system (macOS Apple Silicon M3) handled both processes simultaneously without any audio dropouts or errors.
Out of interest: Do both pd instances in this case access your hardware I/Os?
best, Peter
Audio I/O Error simply means that you got an audio dropout!
Out of interest: Do both pd instances in this case access your hardware I/Os?
The [pd~] subprocess has no access to the audio hardware. [adc~] and [dac~] always communicates with the parent process.
On 24.03.2025 14:35, Peter P. wrote:
Dear Pierpaolo,
not an expert on this issue but...
- Pier Bar pier.ba001@gmail.com [2025-03-24 13:49]:
Hello Pd community,
I've encountered an interesting behavior regarding CPU management in Pure Data using [pd~], and I'd appreciate your insights or confirmations.
Here's my scenario:
I'm running a computationally "intensive" FFT analysis with sigmund~ (similar to the 17.partialtracer example, but without using data structures), on a 4-second audio array. This analysis is causing "Audio I/O Error" warnings and audible dropouts when executed within the main Pd patch, DSP active, latency ~50ms... Increasing the latency further would solve the problem, but I would like to find another solution.
...are you able to track the single Pd instance audio errors down to CPU usage? Does a simpler patch with lower cpu usage not print these errors?
Have you tried to change other audio options?
I am not on OS X so I don't know if -callback or -rt have any effect there.
Initially, I attempted to resolve this by offloading the computation into a subprocess via [pd~]. However, despite what seemed to be a correct configuration (no audio signals shared, only control messages exchanged, -nogui option used), I still observed audio dropouts and "Audio I/O Error" warnings in the main patch.
otherwise when running two completely separate instances of Pd manually, that is two versions of Pd, 0.55-1 and 0.55-2 (one dedicated to real-time audio and another solely for the FFT analysis, without using [pd~]), my system (macOS Apple Silicon M3) handled both processes simultaneously without any audio dropouts or errors.
Out of interest: Do both pd instances in this case access your hardware I/Os?
best, Peter
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/T3ZHM7XKGV...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/