Yeah, I was suspecting the very very large FFTs were bad. I was considering maxing out to something quite smaller than 2ˆ20, I guess windows no bigger than 2ˆ15 should be allowed - I could try even something like 8192 (2ˆ13) as the maximum.

Em sex, 11 de jan de 2019 às 13:30, Giulio Moro <giuliomoro@yahoo.it> escreveu:
(sent this to the list but didn't get through)
Non-uniform load in the audio callback, due to the larger FFTs happening sporadically, I'd guess. This means that, while on average the CPU load is low, in the worst-case (when a long FFT is performed) your audio callback takes more time to execute than there is time available, thus causing glitches. Increasing Pd's delay (internal buffering) should fix that.

Giulio


On Friday, 11 January 2019, 15:27:40 GMT, Alexandre Torres Porres <porres@gmail.com> wrote:

I'm investigating that as well, I get the same and my CPU is at about 10% only...

cheers

Em sex, 11 de jan de 2019 às 12:20, Max <abonnements@revolwear.com> escreveu:
> Interesting stuff!
> However, I have hickups in the sound (dropouts) even though the CPU load
> is around 20% only. What might cause them?
>
> m.
>
> On 11.01.19 04:14, Alexandre Torres Porres wrote:
>> Hi Philipp, so, I checked in depth and revised your patch. Here's my
>> take on it in a similar design of my last object.
>>
>> I changed a lot of things and rewrote basically everything, so there
>> might be something funny still and things may not match, but the basic
>> stuff seem to be equivalent and the basic parameters like block size and
>> delay seem to match.
>>
>> anyway, this is also fully vanilla and the prototype is called [conv2~].
>>
>> I am precomputing the FFT, so check it out, and also check the rest as
>> I've changed much of your computations for something that's simpler I think.
>>
>> here's the link: https://www.dropbox.com/s/z8l85y7p1knjv2i/conv2~.zip?dl=0
>>
>> cheers
>>
>> Em qua, 9 de jan de 2019 às 20:46, Philipp Schmalfuß
>> <philipp.schmalfuss@uni-weimar.de
>> <mailto:philipp.schmalfuss@uni-weimar.de>> escreveu:
>>
>>     yes, i get the same glitchy tone, even worse with smaller blocksizes.
>>     I wasn't aware of this, thanks for the hint! will try to fix this
>>
>>
>>     Quoting Alexandre Torres Porres <porres@gmail.com
>>     <mailto:porres@gmail.com>>:
>>
>>      > Hi, I tested your patch with the [phasor~ 5] and with [phasor~ 1]
>>     I find
>>      > the issue you're bringing up gets much more evident
>>      >
>>      > Em qua, 9 de jan de 2019 às 14:03, Roman Haefeli
>>     <reduzent@gmail.com <mailto:reduzent@gmail.com>>
>>      > escreveu:
>>      >
>>      >> On Wed, 2019-01-09 at 13:44 -0200, Alexandre Torres Porres wrote:
>>      >> > hmm, weird, I don't seem to find problems...
>>      >>
>>      >> Aha? Even with attached test3.pd patch saved along the original
>>     test.pd
>>      >> patch? You can compare 64 to 128 and I get a glitchy tone with a
>>      >> frequency of 690 Hz (which seems to come from 44100/64).
>>      >>
>>      >> Have you tried other IRs than the church.wav and IR.wav?
>>      >>
>>      >> Roman
>>      >>
>>      >>
>>      >> _______________________________________________
>>      >> Pd-list@lists.iem.at <mailto: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
>>
>
>
>
>
> _______________________________________________
> 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