On Fri, Feb 19, 2010 at 01:48:24PM +0100, Fons Adriaensen wrote: > On Fri, Feb 19, 2010 at 03:51:22AM +0100, torbenh wrote: > > > On Thu, Feb 18, 2010 at 06:09:42PM +0100, f...@kokkinizita.net 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.
good point. ok. so this still leaves us with the problem of the phase relation in case of non-power of 2 period sizes. (i am not sure if this patch slipped into jack1 accidentally or on purpose, but the alsa driver doesnt enforce power of 2 anymore) but that kind of thing can be fixed easily. jack_nframes_t jack_cv_get_phase( jack_client_t *client ); i am basically more in favour of timestamped events. but your argumentation in this thread is pretty convincing. and timestamped events come with a galore of other problems, which i think are harder to tackle in a jack context. - multiple interpolation schemes - how to get the current value when port is connected, and didnt see an event yet. so what do people think ? shall we just add CV port type ? (this would sort of rule out timestamped control events, since there should be only one control port type) > > > 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. not if the period is not a power of 2 :( but maybe we should just go back to enforcing that again. > > > 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. thanks for explanation :) -- torben Hohn _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
