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 smallerblocksizes.
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 Porreswrote:
>> > 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