linuxaudio.org

--001636c5a85e54cdcc0498e4018d

Content-Type: text/plain; charset=ISO-8859-1
I would strongly suggest looking at Rubberband:

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 wrote:
> Hey all,

quoted text
>

> 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@lists.linuxaudio.org

> http://lists.linuxaudio.org/listinfo/linux-audio-dev

>

>

--001636c5a85e54cdcc0498e4018d

Content-Type: text/html; charset=ISO-8859-1

Content-Transfer-Encoding: quoted-printable
I would strongly suggest looking at Rubberband:=A0http://breakfastquay.com/rubberband/why.html<=

/a>

However, it is unclear what you want: audio time-stretching, or audio resa=

mpling. =A0Resampling will get you the "slowed down record" or &q=

uot;sped up record" effect, where the pitch is affected along with the=

 time. =A0However, if you want to manipulate the pitch and time=A0separatel=

y, then you need time-stretching. =A0If you're not sure what you want, =

I would still suggest librubberband, because it can do all of the above, pl=

us allow you to manipulate the parameters in real time.
JeremyOn Sun, Jan 2,=

 2011 at 2:51 PM, Harry Van Haaren <harryhaaren@gmail.com> wrote:
Hey all,I'm looking for an open-source time-stretch=

ing library, suitable for RT work.I've googled and come up w=

ith the following list, which I can't choose from:
-Soundtouch :=A0http://www.surina.net/soundtouch/index.html-ClearScale / DspDimension:=A0http://www.clearscale.org/
-SecretRabbitCode / libsamplerate :=A0http://www.mega-nerd.com/SRC/-Li=

bResample :=A0https://ccrma.stanford.edu/~jos/resample/
-MFFM timescale:=A0http://mffmtimescale.sourceforge.net/-LibZi=

ta-Resampler:=A0http://www.kokkinizita.net/linuxaudi=

o/zita-resampler/resampler.html
I'm attepmting to write a sample player, that will =

time-stretch long loops to stay in syncwith 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 sampl=

es.- 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 who=

le buffer, and then playback from that buffer?this approach migh=

t cause a lot of CPU strain once the rate changes, as the *whole* buffer wo=

uld
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.=A0
The other problem I'm faced with is that some libra=

ries 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...=A0I'm aware that Ardour uses SoundTouch, bu=

t 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 g=

oing with it...Choices, Advice, Laughter, Help, e=

tc all welcome! :-)Cheers, -Harry

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lis=

ts.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev
--001636c5a85e54cdcc0498e4018d--