[music-dsp] AMDF shortcuts for SOLA time stretching?
lerch at zplane.de
Tue Apr 22 05:16:19 EDT 2008
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
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
>>> 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".
>>> ----- 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.
>> dipl. ing.
>> alexander lerch
>> 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
> dupswapdrop -- the music-dsp mailing list and website: subscription
> info, FAQ, source code archive, list archive, book reviews, dsp links
fon: +49.30.854 09 15.0
fax: +49.30.854 09 15.5
More information about the music-dsp