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
I've been investigating more throughly about how latency works in reblocked audios. This is because I just took the example from Philipp and copied the scheme, but I wasn't sure or convinced it was correct.
The idea is that we start with a minimum window size (say 64, which should be the minimum size) and have pairs of the same size that increase by a factor of two. So, we get something like: 64 / 64 / 128 /128 / 256 / 256 and so on... until we reach a maximum window size.
So, if the first window is a block of 64, then it has no latency whatsoever. Now there's a second 64 window size with a delay of 32 samples, why? I'd first expect it to be delayed by 64 samples. But, as it turns out, it seems we can just have a window size of 128 next, cause that will in fact already promote a latency of 64 samples! I thought the delay would always be the block size, but it's actually the block size -64!!!
So it seems this delay scheme needs to be revised, and maybe that's why the minimum window size of 64 gives us some weird artifacts!
Anyway, moving on, the third and fourth window size are then 128, but the first one gets no delay and the second one is delayed 64 samples - the delay is always half the block size and only for the latter window of a same size pair... it just doesn't seem right.
cheers
Em sex, 11 de jan de 2019 às 14:16, Alexandre Torres Porres < porres@gmail.com> escreveu:
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 witha
>> 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> mailinglist
>> 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
Em sex, 11 de jan de 2019 às 19:25, Alexandre Torres Porres < porres@gmail.com> escreveu:
So it seems this delay scheme needs to be revised, and maybe that's why the minimum window size of 64 gives us some weird artifacts!
Actually, based on another thread I opened here on the list, it seems the minimum hop size for an overlap needs to be 64, so [block~ 64 2] wouldn't really work... this means that starting with a window of 64 samples could raise issues, hence it might be the actual culprit!
On Sat, 2019-01-12 at 22:56 -0200, Alexandre Torres Porres wrote:
Em sex, 11 de jan de 2019 às 19:25, Alexandre Torres Porres < porres@gmail.com> escreveu:
So it seems this delay scheme needs to be revised, and maybe that's why the minimum window size of 64 gives us some weird artifacts!
Actually, based on another thread I opened here on the list, it seems the minimum hop size for an overlap needs to be 64, so [block~ 64 2] wouldn't really work... this means that starting with a window of 64 samples could raise issues, hence it might be the actual culprit!
I haven't fully grasped your patch illustrating the issue yet, but you seem to have identified the problem. Well done! I'm already totally happy with the partitioned convolutions presented here and with the current minimum delay of 128 samples. I'm curious, though, whether it's possible to maintain correct results with smaller delays by treating smaller block sizes differently.
Roman
-
Alexandre Torres Porres -
Roman Haefeli