Subject: Re: [linux-audio-dev] App intercomunication issues, some views.
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Thu Jul 25 2002 - 12:19:11 EEST
> >on every callback. If a node does internal buffering that should not affect
> >the MSCs.
>
> right, because there isn\'t really an MSC anywhere. as you noted, the
> global jack transport time isn\'t really equivalent. nothing in the
> main JACK API says anything about doing anything except handling a
> buffer corresponding to \"now\" (+/- latency). the transport API couples
> \"now\" with a notion of a significant frame position.
I would like to see per buffer (input and output) at least an UST/MSC
pair + transport position. and have node latencies other than 0 handled
seperately from hardware latency.
[...]
> >If you use a hardware compressor with a high delay there is also no way
> >to compensate. It would be nice to have a way to compensate, but JACK is
>
> VST and most DAW\'s compensate. Its not up to JACK to do it, but a
> client that wants to do this needs the right information.
I agree. But this is then a seperate issue from hardware latency.
> >not the right place for this I think. Anyway, if it is in JACK, it still
> >would have to be at a higher level than the basic intput/output latency,
> >i.e. without taking extra node latency into account.
>
> there isn\'t any difference in JACK. each port has its own latency
> figure associated with it (zero by default). it doesn\'t matter whether
> the port represents a physical input/output connector or
> not. jack_port_get_total_latency() traverses the connection graph from
> a given port to a terminal point, collecting latency information along
> the way.
But as you indicated the latency then depends on the route. Should JACK use
internal buffering to make every route have the same (longest) latency? This
will add complexity.
> >There is still the problem of getting an accurate estimate of system
> >time of some audio frame. This is needed to calculate at what time
> >to output a MIDI message.
>
> I still don\'t see why you need this. If I queue an event by saying
> \"play this in 0.56msecs\", how whatever i queued the event with goes
> about doing delivering it on time is an internal implementation
> detail. there are several mechanisms available, some better than others.
The meaning of \"play this in 0.56msecs\" changes with the time of the
request.
This will create jitter that would not exist when using UST timestamped
buffers
and MIDI output using absolute UST timestamps.
> If I say \"play this at time T\", then yes, some kind of UST is
> needed. This is much harder to do than the relative method I described.
But, IMHO, it is the only correct way.
> > I think this approach is better then just
> >counting on being scheduled just after the audio hardware interrupt.
> >This is certainly not the case with somewhat large audio buffers and
> >multiple nodes.
>
> sure, i don\'t think the audio clock is ever going to be suitable for
> MIDI scheduling. you need the firm timers or KURT patches or a Gravis
> Ultrasound interface.
I agree.
> then you just do all scheduling with a relative offset from now. the
> largest times will be on the order a few hundred msecs, and the common
> case will be more like 1-5msecs.
Define now. When is that? At the start of the cycle? No, because since
there are several nodes, \'now\' might be quite some time from the cycle
start when a somewhat larger (say 200ms) audio buffer is used and there
is no way to know this without timestamping the buffers. That is why UST
is needed.
> delta_till_emit = event.time - transport_position +
> jack_port_get_total_latency (relevant_port);
>
Again, we may already be way past the cycle start time here and yet you
calculate the delta time as if we are exactly at the cycle start time.
--martijn
Powered by ASHosting
This archive was generated by hypermail 2b28 : Thu Jul 25 2002 - 12:12:38 EEST