On 3 Jun 2008, at 19:39, Stefano D'Angelo wrote:
>> #4. Support for time stretching when using non real-time audio
>> sources.
>
> I came to this conclusion about it: if combining together pitch
> shifting and time stretching you can get better results than doing
> things separately, it is the case to support it at a plugin level;
> otherwise time stretching can be done by the host and pitch shifting
> by the plugin.
>
> Now, I'm looking at phase vocoders on wikipedia
> (http://en.wikipedia.org/wiki/Phase_vocoder) and that thing states:
>
> "The time scale of the resynthesis does not have to be the same as the
> time scale of the analysis, allowing for high-quality time-scale
> modification of the original sound file."
>
> I'm no expert in this stuff, does anyone know how if that is true?
It's true, but it's really, really hard to get right.
You don't have to use timestretching to resample audio for a music
player, infact you would avoid that at all costs, you just need to
resample.
> In such case support should be added and, IMHO, that could be done
> modifying the run() to return buffer length and give the host an hint
> on maximum buffer sizes.
>
> I think it shouldn't be done inside an extension since it's really
> core level stuff.
No, I disagree very strongly. Time stretching is one of a very small
number of applications for the feature, the user is not going to want
to insert it into a chain of effects, so just use SRC, and feed the
plugins with the resampled material.
Having plugins being capable of outputting an arbitrary number of
samples is a really horrible thing to deal with in a realtime
environment, I'd want to avoid it al all costs.
Everything else you said makes sense.
- Steve
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed Jun 4 16:15:02 2008
This archive was generated by hypermail 2.1.8 : Wed Jun 04 2008 - 16:15:02 EEST