[PD] vanilla partitioned convolution abstraction

Alexandre Torres Porres porres at gmail.com
Fri Jan 11 22:25:55 CET 2019


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 at 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 at 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 at 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 at 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 at uni-weimar.de
>> >> <mailto:philipp.schmalfuss at 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 at gmail.com
>> >>     <mailto:porres at 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 at gmail.com <mailto:reduzent at 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 at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing
>> list
>> >>      >> UNSUBSCRIBE and account-management ->
>> >>      >> https://lists.puredata.info/listinfo/pd-list
>> >>      >>
>> >>      >
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Pd-list at lists.iem.at mailing list
>> >> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>> >>
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Pd-list at lists.iem.at mailing list
>> > UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>> >
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20190111/0d44c043/attachment-0001.html>


More information about the Pd-list mailing list