16 Jan
2003
16 Jan
'03
12:48 p.m.
On Thu, 16 Jan 2003 10:58:40 -0500
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
Yes, but then, if you are also having input from realtime-type interface the buffer must
be of fixed size.
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
On Wed, 15 Jan
2003 18:13:35 +0000
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote:
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. 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. 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.