Subject: Re: [linux-audio-dev] App intercomunication issues, some views.
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Wed Jul 24 2002 - 21:40:47 EEST
> >If I use an absolute sleep there is basically no difference. The drift
> >will be the same, but instead of scheduling events from \'now\' I can
> >spcify the exact time. So a callback would then be like:
> >
> >- get the UST and MSC for the first frame of the current buffer for input
>
> MSC implies timestamped buffers.
MSC would be useful even without timestamped buffers I think. It enables the
application to know the input->output frame latency and if overflow/underflow
occured.
> as i\'ve indicated, i think this is a
> bad design. Defining the semantics of MSC in a processing graph is
> hard (for some of the same reasons that jack_port_get_total_latency()
> is hard to implement).
Why? On a audio card interrupt buffers traverse the entire graph right? i.e.
for every \'node\' its process() function is called for accepting audio data
from that interrupt and producing audio data for the buffer available for
writing on that interrupt, right?
> in a system supporting low latency well, the buffer you are working
> should be considered to be related to \"now\" as closely as
> possible. the only gap between \"now\" and when it was actually
> collected or will be delivered to the connectors on the interface is
> defined by the latency of the input or output path. either way, the
> application should consider itself to be working against the \"now\"
> deadline.
With two applcations doing audio output (40ms buffer, 2 periods) using on
average 50% cpu time the delay between the hardware interrupt and the callback
will be about 5ms for one of those applications.
> but anyway, this is irrelevant, because MSC is not the timebase to use
> for this - you need to use transport time.
Transport time is in frames, right? And there is a transport time available
for input buffers and output buffers?
> >- get the MSC for the first frame of the current buffer for output and
> > estimate the UST for that frame.
> >- calculate the UST values for the MIDI events that are to occur during the
> > output buffer.
> >- schedule the MIDI events (the API uses UST)
>
> i see no particular difference between what you\'ve outlined and what i
> described, with the exception that the current \"MSC\" is a global
> property, and doesn\'t belong to buffers. its the transport time of the
> system.
The current MSC isn\'t global. The MSC is different for input and output
buffers.
> >This has two advantages:
> >
> >- since you get UST for the input buffer you have a better estimation of
> > when the output buffer will be performed.
>
> you\'re making assumptions that the output path from
> the node matches the input path. this isn\'t true in a general
> system. the output latency can be totally different from the input
> latency.
I did not make that assumption I think.
> imagine an FX processor taking input from an ALSA PCM source
> but delivering it another FX processor running a delay line or similar
> effect before it goes back to an ALSA PCM sink.
That latency is intended in the effect and has nothing to do with the MSC.
> >- the MIDI messages will be queued and thus will need an absolute
timestamp.
>
> they don\'t need an absolute timestamp to be applied in user-space:
> they just need a non-adjustable tag that indicates when they should be
> delivered. obviously, at some point, this has be to converted to an
> absolute time, but that doesn\'t need to be part of the API. \"deliver
> this in 1msec\" versus \"deliver this at time T\" - the latter requires
> UST, the former just requires something with the semantics of nanosleep.
So, instead of using UST throughout you use a relative time in the API,
which then has to be immediately converted to some absolute time to still
make any sense later. Also using UST is more accurate.
const struct timespec PERIOD;
for (;;) {
nanosleep(PERIOD);
}
is less accurate (will drift) then
struct timespec t;
clock_gettime(CLOCK_MONOTONIC, &t);
for (;;) {
t += PERIOD; // i know you can\'t actually do this with struct timespec...
clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &t, NULL);
}
A MIDI scheduler thread would look somewhat like this and would be better of
using absolute times. If the UST is accurate and messages aren\'t scheduled
too
far ahead, then this will IMHO be the best approach.
A common \'wall clock\' is needed to compare the times of events from
different
media. UST provides this.
> >Using MSC for every buffer, the latency is the difference between output
> >MSC and input MSC.
>
> as indicated above, this isn\'t generally true.
I do not understand this. JACK should be able to know the latency.
> >> now, the truth is that you can do this either way: you can use an
> >> absolute current time, and schedule based on that plus the delta, or
> >> you can just schedule based on the delta.
> >
> >But how can this be done in another thread at a later time?
>
> thats an implementation issue, mostly for something like the ALSA midi
> layer.
If I tag a MIDI message with a absolute time then the MIDI implementation
can at a later time still determine when the message is to be performed.
How can this be done without an absolute stamp?
> i\'ve said before that i\'d to see snd_rawmidi_write_with_delay()
> or something equivalent. it would be down to the driver to figure out
> how to ensure that the data delivery happens on time, and how it would
> work would probably vary between different hardware.
I really don\'t think it is as easy as adding a write_with_delay(). Should
the driver accept only time-ordered messages? How about MIDI through for
a sequencer application?
--martijn
Powered by ASHosting
This archive was generated by hypermail 2b28 : Wed Jul 24 2002 - 21:36:24 EEST