I would strongly suggest looking at Rubberband:
http://breakfastquay.com/rubberband/why.html
<http://breakfastquay.com/rubberband/why.html>However, it is unclear what
you want: audio time-stretching, or audio resampling. Resampling will get
you the "slowed down record" or "sped up record" effect, where the
pitch is
affected along with the time. However, if you want to manipulate the pitch
and time separately, then you need time-stretching. If you're not sure what
you want, I would still suggest librubberband, because it can do all of the
above, plus allow you to manipulate the parameters in real time.
Jeremy
On Sun, Jan 2, 2011 at 2:51 PM, Harry Van Haaren <harryhaaren(a)gmail.com>wrote;wrote:
Hey all,
I'm looking for an open-source time-stretching library, suitable for RT
work.
I've googled and come up with the following list, which I can't choose
from:
-Soundtouch :
http://www.surina.net/soundtouch/index.html
-ClearScale / DspDimension:
http://www.clearscale.org/
-SecretRabbitCode / libsamplerate :
http://www.mega-nerd.com/SRC/
-LibResample :
https://ccrma.stanford.edu/~jos/resample/
-MFFM timescale:
http://mffmtimescale.sourceforge.net/
-LibZita-Resampler:
http://www.kokkinizita.net/linuxaudio/zita-resampler/resampler.html
I'm attepmting to write a sample player, that will time-stretch long loops
to stay in sync
with JACK transport.
I've deduced this is what I need to do:
- Calculate the amount of samples I need to change the buffer length by
- Take the buffer, resample it to a larger / smaller amount of samples.
- Playback the samples as I normally would, except that there's more, and
hence the audio will stay in sync.
Design choices:
1. should I re-sample the whole buffer, and then playback from that buffer?
this approach might cause a lot of CPU strain once the rate changes, as the
*whole* buffer would
be re-sampled at the same time. Once done, the CPU has no strain from
resampling.
2. Resample "nframes" amount of samples from the buffer, and play them
back?
Less sudden CPU overhead, more constant CPU usage.
The other problem I'm faced with is that some libraries mention that they
do *not* support "dynamically variable resampling ratios".
Would I need this? I think I do, as to get the beat "on-time" sometimes
I'd
need to add 200 samples, while in other cases 210 samples
might suit better...
I'm aware that Ardour uses SoundTouch, but I'm not sure is that the best
lib for real-time use.
Mixxx is using LibSamplerate AFAIK, and does so quite well, but might not
be as suitable as Soundtouch..
http://www.surina.net/soundtouch/faq.html#sample_processing
These kind of paragraphs are what stop me from just choosing one and going
with it...
Choices, Advice, Laughter, Help, etc all welcome! :-)
Cheers, -Harry
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev