[music-dsp] AMDF shortcuts for SOLA time stretching?

[alexander lerch]

Right, you won't avoid spikes as you need an FFT size longer than 64 
samples. In a few of our interfaces, we offer to split one process-call 
into several to smooth out those peaks.

But it's hard for me to imagine a decent time-stretching with constant 
workload at low buffer sizes - and probably low latency as well? Good 
luck...

Cheers,
Alexander

Ross Bencina wrote:
> Hi Alexander
>> Well, who would compute an ACF in the time domain anyway? ;)
> 
> Well.. if your synthesis buffer size (ie hardware buffer size) is on the 
> order of 64 samples, may not be a multiple of your FFT frame rate, and 
> may vary (eg if you're a plugin) then doing longish FFTs without CPU 
> spikes/irregularities is obviously a non-trivial matter. Either I'm 
> ignorant of something you can tell me, or you have a nice FFT 
> implementation that gives constant CPU load ;-)
> 
> Best wishes
> 
> Ross.
> 
>>> I'm wondering though, when you talk about "workload" are you 
>>> including both the analysis and resynthesis workloads? I notice your 
>>> web pages talk about optionally pre-computing the analysis step..
>>
>> For the PSOLA-type stretching, you can separate the pitch mark 
>> computation from the synthesis and run the synthesis alone with very 
>> insignificant workload. But for a phase-vocoder, we don't separate 
>> analysis and synthesis - it's only one processing step. When I 
>> compared workload, I was referring to both algorithms doing analysis 
>> and synthesis at "the same time".
>>
>> Best,
>> Alexander
>>
>>> ----- Original Message ----- From: "alexander lerch" <lerch at zplane.de>
>>> To: "A discussion list for music-related DSP" 
>>> <music-dsp at music.columbia.edu>
>>> Sent: Tuesday, April 22, 2008 12:44 AM
>>> Subject: Re: [music-dsp] AMDF shortcuts for SOLA time stretching?
>>>
>>>
>>>> Hi Ross,
>>>>
>>>> Ross Bencina wrote:
>>>>> My extremely vague impression is that a good 
>>>>> spectral-peak-processing time stretcher (such as the one published 
>>>>> by Jordi Bonada in 2001 I think) consumes about 50% of a current 
>>>>> generation IA32 CPU -- that's extrapolating from how it was 
>>>>> performing in 2001.
>>>>
>>>> That's not necessarily true I would say, but heavily depends on how 
>>>> you optimize it (algorithmically and CPU-wise). As for our 
>>>> time-stretching engines, our PSOLA based approach (élastique 
>>>> SOLOIST) roughly takes as much workload as our phase vocoder based 
>>>> engine (élastique efficient) in a "real-time" situation, and you can 
>>>> run far more than two instances at once for both of them.
>>>>
>>>> Cheers,
>>>> Alexander
>>
>> -- 
>> dipl. ing.
>> alexander lerch
>>
>> zplane.development
>> :www.zplane.de
>> katzbachstr.21
>> d-10965 berlin
>>
>> fon: +49.30.854 09 15.0
>> fax: +49.30.854 09 15.5
>> -- 
>> dupswapdrop -- the music-dsp mailing list and website: subscription 
>> info, FAQ, source code archive, list archive, book reviews, dsp links 
>> http://music.columbia.edu/cmc/music-dsp 
>> http://music.columbia.edu/mailman/listinfo/music-dsp
>>
> -- 
> dupswapdrop -- the music-dsp mailing list and website: subscription 
> info, FAQ, source code archive, list archive, book reviews, dsp links 
> http://music.columbia.edu/cmc/music-dsp 
> http://music.columbia.edu/mailman/listinfo/music-dsp
> 

-- 
dipl. ing.
alexander lerch

zplane.development
:www.zplane.de
katzbachstr.21
d-10965 berlin

fon: +49.30.854 09 15.0
fax: +49.30.854 09 15.5