Subject: RE: [linux-audio-dev] LADSPA Specs ?
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: Tue May 14 2002 - 00:22:24 EEST
> -----Original Message-----
> From: linux-audio-dev-admin_AT_music.columbia.edu
> [mailto:linux-audio-dev-admin_AT_music.columbia.edu]On Behalf Of Paul Davis
> Sent: 11 May 2002 22:54
> To: linux-audio-dev_AT_music.columbia.edu
> Subject: Re: [linux-audio-dev] LADSPA Specs ?
>
>
> >you mentioned that you have never seen any plugin that outputs a
> >different number of samples than inputs. I think the time-stretching
> >plugin is a very legitimate example, and I certainly don't understand
> >your rationale that a time-stretching plugin should output the same
> >number of samples under the same frequency sample rate. You see, my dear
> >friend, this wouldn't be time-stretching.
>
> I'm afraid it would. You need to think about this some more. In any
> given unit of time, a certain number of samples are transformed into a
> varying air pressure wave. What matters is the relation between those
> samples and the original source material. The number of them remains
> the same per unit of time whether the signal is altered or not.
There are two ways to interpret timeshift:
(1) As a reinterpretation of the timestamps on the samples (i.e.
resampling), or
(2) As an actual stretching of the audio (e.g. it was supposed to last 1s,
afterwards it lasts 2s).
Neither of these are compatible with LADSPA because:
(1) LADSPA always assumes that samples are spaced according to the sample
rate.
(2) LADSPA can do this when stretching although you'll need linearly
increasing memory to make it work. Compacting is impossible as the plugin
has to look ahead into the input stream (unless you're intending some ugly
buffering). The LADSPA non-causal extensions I suggested a while back get
around this, however they are non-trivial and consensus was not to introduce
them (I agree).
> However, what you may be thinking of is a different (though clearly
> related) problem. Many "time stretching" algorithms (the ones that do
> not operate independently on pitch and duration) cannot be used in
> real-time, because if the speed is supposed to increase, they run out
> of samples to process.
Absolutely.
> This is why LADSPA has flags to indicate that a plugin is not suitable for
> real-time (i.e. streaming) use.
[...]
LADSPA always assumes it is streaming (i.e. logical time of audio = sample
number / sample rate). Running a stretch algorithm as in (2) above would
certainly not qualify as a realtime LADSPA plugin because the definition of
realtime for LADSPA purposes is that the plugin satisfies certain
constraints on how much CPU time it will use when it runs - and the stretch
algorithm above won't manage this (unless you have an AWFUL lot of memory in
your PC!).
Fundamentally, time shifting plugins (stretch, reverse etc) aren't really
compatible with the streaming paradigm (which has a basic assumption of
causality). And they are few enough to be handled separately - I don't
really see them as LADSPA's domain.
--Richard
This archive was generated by hypermail 2b28 : Tue May 14 2002 - 00:24:20 EEST