linuxaudio.org

On Fri, Feb 19, 2010 at 03:51:22AM +0100, torbenh wrote:
> On Thu, Feb 18, 2010 at 06:09:42PM +0100, fons@kokkinizita.net wrote:

quoted text
>

> > We may not be talking of the same thing. This is not about

> > 'generic events' but about reduced-bandwidth continuous

> > signals, represented as floating point samples. So I'd say

> > that all it takes is a shorter version of the standard

> > _audio_ buffer.

>

> could you define _shorter_

> is that app specific. or would that be a single factor for the whole

> jack graph ?

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

quoted text
> of a period, we basically need some phase association.

> so that apps can sort of know that CV sample 0 has the same time

> as audio_sample[phase]

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

quoted text
> some arbitrary resampling.

>

> i am thinking of:

> x[0] = 0;

> x[1] = 0.75;

> x[N] = 1.0  | N>1

> to encode an event to switch from 0 to 1 at t=0.666666

>

> (this representation is not causal, so it would need to be shifted...

> but this is what i have in mind)

You're close, see below. 
> i am a bit wary because this still seems a lot more expensive than

quoted text
> having timestamped float events. and i am not sure the ease of recording

> this kind of data weighs it up again.

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

position. 
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

information. 
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.
Ciao,
--

FA
O tu, che porte, correndo si ?

E guerra e morte !

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

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