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/
I had already considered splitting the operations across multiple ticks, but I hadn’t thought about adding a delay after each operation using [metro]. It’s amazing how Pd manages logical time through these objects. Now, by using [metro 0.08], I achieve the same task with an overall logical time "latency" of about 28 milliseconds (just for this specific operation), while the audio latency in Pd remains set at 5 ms. Depending on the number of operations I’ll need in the future, I can adjust the [metro] accordingly. Thank you very much, Christof! And thanks to everyone!
Increasing the FIFO latency (even dramatically) did not solve the issue. In what typical scenarios would you recommend using [pd~] for subprocess management? It would be interesting to have a practical idea of when it is most useful.
Pier
Il giorno lun 24 mar 2025 alle ore 14:43 Christof Ressi < info@christofressi.com> ha scritto:
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/
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/PL5X5Y7ERR...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
On 24.03.2025 17:42, Pier Bar wrote:
I had already considered splitting the operations across multiple ticks, but I hadn’t thought about adding a delay after each operation using [metro]. It’s amazing how Pd manages logical time through these objects. Now, by using [metro 0.08], I achieve the same task with an overall logical time "latency" of about 28 milliseconds (just for this specific operation), while the audio latency in Pd remains set at 5 ms. Depending on the number of operations I’ll need in the future, I can adjust the [metro] accordingly. Thank you very much, Christof! And thanks to everyone!
Cool!
Increasing the FIFO latency (even dramatically) did not solve the issue. In what typical scenarios would you recommend using [pd~] for subprocess management? It would be interesting to have a practical idea of when it is most useful.
You would typically use it for offloading audio processing to another CPU core, in particular if a single CPU cannot handle the full workload.
Pier
Il giorno lun 24 mar 2025 alle ore 14:43 Christof Ressi info@christofressi.com ha scritto:
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/YCPSAOIGTIXVEWA2MBRFYMP5ZAH4V77P/ > > To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://lists.iem.at/ > --- pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/PL5X5Y7ERRPYFU2JFCCAJE5ML5YFKSW3/ To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
You would typically use it for offloading audio processing to another CPU core, in particular if a single CPU cannot handle the full workload.
So it seems intended for audio rather than control signal operations...
Pier
Il giorno lun 24 mar 2025 alle ore 17:57 Christof Ressi < info@christofressi.com> ha scritto:
On 24.03.2025 17:42, Pier Bar wrote:
I had already considered splitting the operations across multiple ticks, but I hadn’t thought about adding a delay after each operation using [metro]. It’s amazing how Pd manages logical time through these objects. Now, by using [metro 0.08], I achieve the same task with an overall logical time "latency" of about 28 milliseconds (just for this specific operation), while the audio latency in Pd remains set at 5 ms. Depending on the number of operations I’ll need in the future, I can adjust the [metro] accordingly. Thank you very much, Christof! And thanks to everyone!
Cool!
Increasing the FIFO latency (even dramatically) did not solve the issue. In what typical scenarios would you recommend using [pd~] for subprocess management? It would be interesting to have a practical idea of when it is most useful.
You would typically use it for offloading audio processing to another CPU core, in particular if a single CPU cannot handle the full workload.
Pier
Il giorno lun 24 mar 2025 alle ore 14:43 Christof Ressi < info@christofressi.com> ha scritto:
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/
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/PL5X5Y7ERR...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
On 3/24/25 18:23, Pier Bar wrote:
You would typically use it for offloading audio processing to another CPU core, in particular if a single CPU cannot handle the full workload.
So it seems intended for audio rather than control signal operations...
i see how you come to this conclusion by christof's wording.
however, i wouldn't say that this is necessarily true.
the important fact to understand is, that the output of [pd~] is still fully deterministic (by keeping the operations *synchronous* with the parent Pd).
therefore, it is ill-suited for asynchronous offline processing (like training a neural network for 10 minutes at "full speed").
instead i would say that it is a good tool if you can formulate the problem like this: "I have a cool patch X that works great with the desired latency. I have another cool patch Y that also works nicely. But if I use them together, things start to fall apart." then you could run e.g. patch Y in a separate [pd~] instance.
fgdam IOhannes
On 27.03.2025 16:39, IOhannes m zmoelnig wrote:
On 3/24/25 18:23, Pier Bar wrote:
You would typically use it for offloading audio processing to another CPU core, in particular if a single CPU cannot handle the full workload.
So it seems intended for audio rather than control signal operations...
i see how you come to this conclusion by christof's wording.
however, i wouldn't say that this is necessarily true.
Sorry for giving the wrong impression that [pd~] is only for audio processing. Of course, you can (also) do control operations!
the important fact to understand is, that the output of [pd~] is still fully deterministic (by keeping the operations *synchronous* with the parent Pd).
therefore, it is ill-suited for asynchronous offline processing (like training a neural network for 10 minutes at "full speed").
instead i would say that it is a good tool if you can formulate the problem like this: "I have a cool patch X that works great with the desired latency. I have another cool patch Y that also works nicely. But if I use them together, things start to fall apart." then you could run e.g. patch Y in a separate [pd~] instance.
That's actually a pretty good explanation. And that's exactly how I've been using [pd~] myself.
fgdam IOhannes
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/KXKGQC63R7...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Btw this has already been discussed a few years ago, including the possibility of making an "asynchronous" pd~, which would be definitely useful:
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/thread/35ERXCVVPVE...
Antoine
Le ven. 28 mars 2025 à 10:19, Christof Ressi info@christofressi.com a écrit :
On 27.03.2025 16:39, IOhannes m zmoelnig wrote:
On 3/24/25 18:23, Pier Bar wrote:
You would typically use it for offloading audio processing to another CPU core, in particular if a single CPU cannot handle the full workload.
So it seems intended for audio rather than control signal operations...
i see how you come to this conclusion by christof's wording.
however, i wouldn't say that this is necessarily true.
Sorry for giving the wrong impression that [pd~] is only for audio processing. Of course, you can (also) do control operations!
the important fact to understand is, that the output of [pd~] is still fully deterministic (by keeping the operations *synchronous* with the parent Pd).
therefore, it is ill-suited for asynchronous offline processing (like training a neural network for 10 minutes at "full speed").
instead i would say that it is a good tool if you can formulate the problem like this: "I have a cool patch X that works great with the desired latency. I have another cool patch Y that also works nicely. But if I use them together, things start to fall apart." then you could run e.g. patch Y in a separate [pd~] instance.
That's actually a pretty good explanation. And that's exactly how I've been using [pd~] myself.
fgdam IOhannes
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/KXKGQC63R7...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/5D3Q2AYZ6Y...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Hi all,
I've been out of the loop a bit, but maybe I'll get back to some projects soon. This is one of my interests as well: how to handle asynchronous processing of expensive things that are dangerous to real-time
The basic conclusion I have: start a 2nd fully independent pd process with -noaudio and read/write data with Cyrille's shmem tools. That 2nd process can also make use of the fast forward mode, as long as it returns to the regular scheduler when it needs to communicate synchronously.
shmem is *the* tool for writing control of asynchronous processes. One process, no matter what clock it's using, can poll a shmem location and get an instruction. I'll try to catch up and see what the list has been talking about, and if the topic has been visited lately.
Best, Chuck
On Fri, Mar 28, 2025, 5:18 AM Antoine Rousseau antoine@metalu.net wrote:
Btw this has already been discussed a few years ago, including the possibility of making an "asynchronous" pd~, which would be definitely useful:
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/thread/35ERXCVVPVE...
Antoine
Le ven. 28 mars 2025 à 10:19, Christof Ressi info@christofressi.com a écrit :
On 27.03.2025 16:39, IOhannes m zmoelnig wrote:
On 3/24/25 18:23, Pier Bar wrote:
You would typically use it for offloading audio processing to another CPU core, in particular if a single CPU cannot handle the full workload.
So it seems intended for audio rather than control signal operations...
i see how you come to this conclusion by christof's wording.
however, i wouldn't say that this is necessarily true.
Sorry for giving the wrong impression that [pd~] is only for audio processing. Of course, you can (also) do control operations!
the important fact to understand is, that the output of [pd~] is still fully deterministic (by keeping the operations *synchronous* with the parent Pd).
therefore, it is ill-suited for asynchronous offline processing (like training a neural network for 10 minutes at "full speed").
instead i would say that it is a good tool if you can formulate the problem like this: "I have a cool patch X that works great with the desired latency. I have another cool patch Y that also works nicely. But if I use them together, things start to fall apart." then you could run e.g. patch Y in a separate [pd~] instance.
That's actually a pretty good explanation. And that's exactly how I've been using [pd~] myself.
fgdam IOhannes
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/KXKGQC63R7...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/5D3Q2AYZ6Y...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/BVUCVEVWRP...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
instead i would say that it is a good tool if you can formulate the problem like this: "I have a cool patch X that works great with the desired latency. I have another cool patch Y that also works nicely. But if I use them together, things start to fall apart." then you could run e.g. patch Y in a separate [pd~] instance.
Hi, List !
I stumbled over one question recently, regarding [pd~].
PD (with Audio operations) and PD with video (GEM) are best run in 2 seperate instances of PD, right ? (As video operations can cause audio dropouts)
So, given these informations about [pd~], running a GEM patch inside an audio PD patch using [pd~) is not going to be better than having audio and video in the same patch, right ? (because [pd~] is synchronous to its parent)
So, for an "asynchronous" situation, i still need to start two seperate instances of PD to keep audio and video truly seperated ?
Thanks for clarifications !
Best
Oliver
There are two possible sources of dropouts because of gem: first, gem might run at less that 100% CPU usage but since itits calculations happen only once per frame, the computation time is irregular and can be smoothed out by using pd~ with a long-ish fifo size. This allows the sub-process to get behind on computation and later catch up as the fifos run out and refill.
Second, it could be that the gem patch sometimes runs at greater than 100%. In this case you can either allow it to get behind (I think this will not just slow down the frame rate but also slow down pd's clock so that sequences might also slow down) -- or else you can slow gem's frame rate down until the computations fit -- and then you can go back to case 1.
cheers Miller
Hi, List !
I stumbled over one question recently, regarding [pd~].
PD (with Audio operations) and PD with video (GEM) are best run in 2 seperate instances of PD, right ? (As video operations can cause audio dropouts)
So, given these informations about [pd~], running a GEM patch inside an audio PD patch using [pd~) is not going to be better than having audio and video in the same patch, right ? (because [pd~] is synchronous to its parent)
So, for an "asynchronous" situation, i still need to start two seperate instances of PD to keep audio and video truly seperated ?
Thanks for clarifications !
Best
Oliver
pd-list@lists.iem.at - the Pure Data mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-list@lis...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.iem.at/__;!!Mih3wA!GipjXBw7z7iOasC...
I am grateful for this kind community
Pier
Il giorno sab 29 mar 2025 alle ore 12:13 Miller Puckette via Pd-list < pd-list@lists.iem.at> ha scritto:
There are two possible sources of dropouts because of gem: first, gem might run at less that 100% CPU usage but since itits calculations happen only once per frame, the computation time is irregular and can be smoothed out by using pd~ with a long-ish fifo size. This allows the sub-process to get behind on computation and later catch up as the fifos run out and refill.
Second, it could be that the gem patch sometimes runs at greater than 100%. In this case you can either allow it to get behind (I think this will not just slow down the frame rate but also slow down pd's clock so that sequences might also slow down) -- or else you can slow gem's frame rate down until the computations fit -- and then you can go back to case 1.
cheers Miller
Hi, List !
I stumbled over one question recently, regarding [pd~].
PD (with Audio operations) and PD with video (GEM) are best run in 2 seperate instances of PD, right ? (As video operations can cause audio dropouts)
So, given these informations about [pd~], running a GEM patch inside an audio PD patch using [pd~) is not going to be better than having audio and video in the same patch, right ? (because [pd~] is synchronous to its parent)
So, for an "asynchronous" situation, i still need to start two seperate instances of PD to keep audio and video truly seperated ?
Thanks for clarifications !
Best
Oliver
pd-list@lists.iem.at - the Pure Data mailinglist
https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-list@lis...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://urldefense.com/v3/__https://lists.iem.at/__;!!Mih3wA!GipjXBw7z7iOasC...
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/X2TCPPHHPK...
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/