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

Ross Bencina rossb-lists at audiomulch.com
Tue Apr 22 04:53:15 EDT 2008


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
> 


More information about the music-dsp mailing list