16 Jan
2003
16 Jan
'03
12:02 p.m.
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.
My comments: I really like MOMENTARY and RANDOMISABLE. AUDIO_RATE_CONTROL
could be useful, but might be painful for hosts to implement. I dont have
any particular use for it right now.
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.
--p