Subject: Re: [linux-audio-dev] Additional LADSPA hints
From: janne halttunen (jhalttun_AT_pp.htv.fi)
Date: Thu Jan 16 2003 - 18:38:39 EET
On Thu, 16 Jan 2003 10:58:40 -0500
Paul Davis <paul_AT_linuxaudiosystems.com> wrote:
> >On Wed, 15 Jan 2003 18:13:35 +0000
> >Steve Harris <S.W.Harris_AT_ecs.soton.ac.uk> wrote:
> >
> >> AUDIO_RATE_CONTROL. Hints than an audio control should/could be controlled
> >> by a high time res. slider or control data, but shouldn't be connected to
> >> the next audio signal by default. I can't think of any simple examples off
> >> hand, but combined with MOMENTARY it could be used for sample accurate
> >> tempo tapping.
> >>
> >
> >Not to mention that AUDIO_RATE_CONTROL would completely useless in JACK?
> >You'd have a buffer-full of samples and apply frequency shift to them, which w
> >ould change the length of that buffer, which you couldn't give to JACK unless
> >you do some rebuffering.
>
> this is true of *any* output paradigm. the audio interface only
> accepts N frames per second. if you had N frames to deliver in one
> second, then stretched them to N*2 frames, it will necessarily take
> you twice as long to deliver them - the interface isn't going to speed
> up for you.
Yes, but then, if you are also having input from realtime-type interface the buffer must be of fixed size.
> >Correct me if I'm wrong. We have similar issue with ecasound's Pitch Shifter
> >operator in connection with JACK.
>
> steve has written LADSPA pitch shifters and they work just fine with
> the fixed-sized buffer paradigm.
Yep, I was just intrigued with the tempo tapping, which cannot be achieved when in and out are realtime. (like jack-rack) Or then I maybe misunderstood the term.
janne
This archive was generated by hypermail 2b28 : Thu Jan 16 2003 - 18:42:05 EET