Weird issue: need to increase Pd latency in FFT patches, otherwise Pd sound output glitches and clocks are slowing down!!!
Hi,
I have the following issue with Pd 0.47.1 on Win 7 (onboard soundcard + ASIO4ALL and also Focusrite Scarlett 6i6 + Focusrite ASIO Driver):
When I use more than just a few FFTs anywhere in my patch, I get a staggering sound output + clicks from Pd unless I increase the Pd latency... Apparently, it's only the playback because I couldn't hear it in a recording I made with [writesf~]. Therefore I made a recording in Reaper to show you what I'm hearing.
The more FFTs and the larger the FFT blocksize, the larger I have to set the latency. This even happens if the CPU load is as little as 5% (where 25% would be the maximum for one hardware thread on my laptop).
In my test patch, I put a couple of FFT subpatches and a single sine wave with a volume control to check the sound output. Usually, I can play a sine wave without artifacts as long as the CPU load is not peeking. But here, the FFTs seem to magically disturb the audio output of the whole patch...
I think there's something going wrong with the scheduler because also objects like [metro] and [line] start to go slower - sometimes up to 50%!
What is going on!?
Christof
OK, some updates:
obviously it doesn't have to be FFTs, in block-glitch1.pd I replaced the FFTs with square roots. But it's neither related to the number of block~ objects or subpatches. In block-glitch2.pd, I have a single blocked subpatch with lots of square roots and I get the same result. Again, the CPU load is not the problem. It seems the problem is merely related to reblocking, overlap and upsampling.
Gesendet: Montag, 31. Oktober 2016 um 14:38 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: pd-list pd-list@iem.at Betreff: [PD] Weird issue: need to increase Pd latency in FFT patches, otherwise Pd sound output glitches and clocks are slowing down!!!
Hi,
I have the following issue with Pd 0.47.1 on Win 7 (onboard soundcard + ASIO4ALL and also Focusrite Scarlett 6i6 + Focusrite ASIO Driver):
When I use more than just a few FFTs anywhere in my patch, I get a staggering sound output + clicks from Pd unless I increase the Pd latency... Apparently, it's only the playback because I couldn't hear it in a recording I made with [writesf~]. Therefore I made a recording in Reaper to show you what I'm hearing.
The more FFTs and the larger the FFT blocksize, the larger I have to set the latency. This even happens if the CPU load is as little as 5% (where 25% would be the maximum for one hardware thread on my laptop).
In my test patch, I put a couple of FFT subpatches and a single sine wave with a volume control to check the sound output. Usually, I can play a sine wave without artifacts as long as the CPU load is not peeking. But here, the FFTs seem to magically disturb the audio output of the whole patch...
I think there's something going wrong with the scheduler because also objects like [metro] and [line] start to go slower - sometimes up to 50%!
What is going on!?
Christof_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
It sounds like a design feature. The computation of re-blocked subpatches is not spread evenly over time, but it is carried out as fast as possible whenever the "clock ticks". The CPU usage is low on average, but there are spikes (on those sample blocks when all the ffts are computed) that prevent you from meeting some of the deadlines. Changing Pd's latency provides more buffering against those spikes. I guess [pd~] may help towards alleviating those problems: http://www.pdpatchrepo.info/hurleur/multiprocessing.pdf%C2%A0 I started a discussion on the topic here https://lists.puredata.info/pipermail/pd-list/2016-09/116315.html
From: Christof Ressi <christof.ressi@gmx.at>
To: Christof Ressi christof.ressi@gmx.at; pd-list pd-list@iem.at Sent: Monday, 31 October 2016, 14:19 Subject: Re: [PD] Weird issue: need to increase Pd latency in FFT patches, otherwise Pd sound output glitches and clocks are slowing down!!!
OK, some updates:
obviously it doesn't have to be FFTs, in block-glitch1.pd I replaced the FFTs with square roots. But it's neither related to the number of block~ objects or subpatches. In block-glitch2.pd, I have a single blocked subpatch with lots of square roots and I get the same result. Again, the CPU load is not the problem. It seems the problem is merely related to reblocking, overlap and upsampling.
Gesendet: Montag, 31. Oktober 2016 um 14:38 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: pd-list pd-list@iem.at Betreff: [PD] Weird issue: need to increase Pd latency in FFT patches, otherwise Pd sound output glitches and clocks are slowing down!!!
Hi,
I have the following issue with Pd 0.47.1 on Win 7 (onboard soundcard + ASIO4ALL and also Focusrite Scarlett 6i6 + Focusrite ASIO Driver):
When I use more than just a few FFTs anywhere in my patch, I get a staggering sound output + clicks from Pd unless I increase the Pd latency... Apparently, it's only the playback because I couldn't hear it in a recording I made with [writesf~]. Therefore I made a recording in Reaper to show you what I'm hearing.
The more FFTs and the larger the FFT blocksize, the larger I have to set the latency. This even happens if the CPU load is as little as 5% (where 25% would be the maximum for one hardware thread on my laptop).
In my test patch, I put a couple of FFT subpatches and a single sine wave with a volume control to check the sound output. Usually, I can play a sine wave without artifacts as long as the CPU load is not peeking. But here, the FFTs seem to magically disturb the audio output of the whole patch...
I think there's something going wrong with the scheduler because also objects like [metro] and [line] start to go slower - sometimes up to 50%!
What is going on!?
Christof_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Thanks Giulio, this totally makes sense! I got completely fooled by the very low average CPU load. Actually, I followed your discussion. I thought it was interesting, but now I've experienced myself that it's really relevant :-).
I was wondering about this:
Within a reblocked subpatch (e.g. with [block~ 16384 4 1]) you can have another subpatch that is reblocked back to lower blocksize (e.g. [block~ 64 1 1]). This works only insofar as the DSP block is indeed smaller, but the tick interval isn't! (you can check with [bang~]. So in this case, the subpatch actually computes 256 blocks of 64 samples within a single DSP tick - no performance gain.
If, however, the tick rate could somehow become faster again, one could circumvent the problem of CPU spikes by putting all heavy calculations inside subpatches with lower blocksize and only leave those objects which really need the large blocksize (like FFTs, [tabsend~], [tabreceive~] etc.).
Does that make sense?
Gesendet: Montag, 31. Oktober 2016 um 17:36 Uhr Von: "Giulio Moro" giuliomoro@yahoo.it An: "Christof Ressi" christof.ressi@gmx.at, pd-list pd-list@iem.at Betreff: Re: [PD] Weird issue: need to increase Pd latency in FFT patches, otherwise Pd sound output glitches and clocks are slowing down!!!
It sounds like a design feature. The computation of re-blocked subpatches is not spread evenly over time, but it is carried out as fast as possible whenever the "clock ticks". The CPU usage is low on average, but there are spikes (on those sample blocks when all the ffts are computed) that prevent you from meeting some of the deadlines. Changing Pd's latency provides more buffering against those spikes. I guess [pd~] may help towards alleviating those problems: http://www.pdpatchrepo.info/hurleur/multiprocessing.pdf%C2%A0 I started a discussion on the topic here https://lists.puredata.info/pipermail/pd-list/2016-09/116315.html%5Bhttps://...]
From: Christof Ressi christof.ressi@gmx.at To: Christof Ressi christof.ressi@gmx.at; pd-list pd-list@iem.at Sent: Monday, 31 October 2016, 14:19 Subject: Re: [PD] Weird issue: need to increase Pd latency in FFT patches, otherwise Pd sound output glitches and clocks are slowing down!!! OK, some updates:
obviously it doesn't have to be FFTs, in block-glitch1.pd I replaced the FFTs with square roots. But it's neither related to the number of block~ objects or subpatches. In block-glitch2.pd, I have a single blocked subpatch with lots of square roots and I get the same result. Again, the CPU load is not the problem. It seems the problem is merely related to reblocking, overlap and upsampling.
Gesendet: Montag, 31. Oktober 2016 um 14:38 Uhr Von: "Christof Ressi" <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]> An: pd-list <pd-list@iem.at[mailto:pd-list@iem.at]> Betreff: [PD] Weird issue: need to increase Pd latency in FFT patches, otherwise Pd sound output glitches and clocks are slowing down!!!
Hi,
I have the following issue with Pd 0.47.1 on Win 7 (onboard soundcard + ASIO4ALL and also Focusrite Scarlett 6i6 + Focusrite ASIO Driver):
When I use more than just a few FFTs anywhere in my patch, I get a staggering sound output + clicks from Pd unless I increase the Pd latency... Apparently, it's only the playback because I couldn't hear it in a recording I made with [writesf~]. Therefore I made a recording in Reaper to show you what I'm hearing.
The more FFTs and the larger the FFT blocksize, the larger I have to set the latency. This even happens if the CPU load is as little as 5% (where 25% would be the maximum for one hardware thread on my laptop).
In my test patch, I put a couple of FFT subpatches and a single sine wave with a volume control to check the sound output. Usually, I can play a sine wave without artifacts as long as the CPU load is not peeking. But here, the FFTs seem to magically disturb the audio output of the whole patch...
I think there's something going wrong with the scheduler because also objects like [metro] and [line] start to go slower - sometimes up to 50%!
What is going on!?
Christof_______________________________________________ Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
On our system we need to "prepare" (de-interleave/resample) the input/output channels that are passed to libpd.The user may not be using all the I/Os available in their patch.Is there a way to get from libpd the number of adc~/dac~ channels actually in use by the current Pd patch? This way we could save some CPU and memory for those channels that are not in use in the currently loaded patch. Thanks,Giulio
-
Christof Ressi -
Giulio Moro