On Fri, Feb 19, 2010 at 03:51:22AM +0100, torbenh wrote:
> On Thu, Feb 18, 2010 at 06:09:42PM +0100, email@example.com wrote:
Apps using this may have a preference, but I see no difficulty
in defining the a fixed control/audio ratio of 1/16.
The intended use is to patch control signals, e.g. source
positions in a spatialisation system, or more classical
automation data such as gains and filter paramaters.
1/16 would provide a bandwidth of 1500 Hz (for a sample
rate of 48000) which is some overkill in many cases, but
otherwise good to have.
> if we dont mandate that a jack period is always an integer multiple
With a ratio of 1/16 you can just define the first sample
of control buffer to coincide with the first sample of
the current audio period.
> hmm... its not completely obvious to me how it could survive
You're close, see below.
> i am a bit wary because this still seems a lot more expensive than
It's not meant as a replacedment for generic timestamped events.
I just mentioned it to make the point that a lower sampling rate
does not limit timing precision.
If your 'perfect' control signal would be a digital one
using -1,+1 at e.g. audio rate, and the transitions
always have a minimal distance, then downsampling it
preserves all information. You can later upsample it
again, and the zero-crossings will be at the original
Exactly the same thing can be done if the original
signal consists of singe-sample triggers (Dirac
impulses). In that case, the peaks of the resulting
waveform will be at the original positions.
Now suppose you have audio tracks at 48 kHz and
control tracks at 3 Khz, and you need to resample
the audio to 44.1 kHz. Resampling the control
tracks to the same ratio will again preserve all
Using full-quality resampling algos for this is of
course just a wast of resources. You could just use
cubic interpolation. In that case each impulse or
transition would required four 'samples', and they
could even overlap a bit. So at 44.1 or 48kHz / 16
you could roughly have one transition or impulse
each millisecond, with 'infinite' resolution.
O tu, che porte, correndo si ?
E guerra e morte !
Linux-audio-dev mailing list