On Fri, Feb 19, 2010 at 03:51:22AM +0100, torbenh wrote: > On Thu, Feb 18, 2010 at 06:09:42PM +0100, [email protected] wrote: > > > 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 > 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 > 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 > 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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
