Subject: Re: [linux-audio-dev] App intercomunication issues, some views.
From: Paul Davis (pbd_AT_op.net)
Date: Wed Jul 24 2002 - 15:00:12 EEST
>[...]
>> UST can be used for timestamping, but thats sort of useless, since the
>> timestamps need to reflect audio time (see below).
>
>I\'d like to have both a frame count (MSC) and a corresponding system time
>(UST) for each buffer (the first frame). That way I can predict when (UST)
>a certain performance time (MSC) will occur and use this to schedule MIDI,
>i.e. through a MIDI API also supporting UST.
but you also need "transport time". frame count time is generally
irrelevant. transport time is non-monotonic.
>> UST cannot (on my
>> understanding) be used for scheduling.
>
>That\'s correct. The application doesn\'t need to. But in the case of a MIDI
>API that accepts UST stamped messages and transmits them at the correct time,
>the implementation might use scheduling on UST directly or it might create
>a mapping between UST and the system clock used for scheduling. With UST
>implemented as CLOCK_MONOTONIC the implementation can actually schedule on
>that.
agreed.
>> >But JACK doesn\\\'t provide timestamps, or does it?
>>
>> it doesn\'t timestamp buffers, because i firmly believe that to be an
>> incorrect design for streamed data.
>
>Why is this an incorrect design? I don\'t understand.
because its based on prequeuing data at the driver level, which (1)
destroys latency and (2) puts more complexity into the driver.
its my belief that if you have an essentially real-time streaming
hardware interface, then the abstraction exported to the application
should reflect this reality, even if it hides the complexity of
controlling the hardware. creating an API that lets you queue up
things to be rendered at arbitrary times certainly seems useful for
certain classes of application, but to me, its clearly a high level
API and should live "above" an API that forces the programmer to deal
with the reality of the hardware model.
your mileage may vary.
>> however, it does provide (if a
>> client volunteers to do this) a time base. see jack/transport.h. the
>> API is not in the main header because we don\'t want to frighten
>> users. most applications don\'t need this stuff at all.
>
>I see it is possible to get the current frame position? Is it not possible
>to get the position of the first frame on every callback?
that's what the frame position information describes, or at least,
thats the current best-favored proposition. its actually tricky to do
precisely what we want, because it really requires running the client
that controls the time twice over (once to define the time for this
iteration, once to do its work at the correct place in the graph),
which is inefficient. so we're playing with defining the semantics of
the timestamp in a way that makes this unnecessary.
>[...]
>> CLOCK_MONOTONIC doesn\'t change the scheduling resolution of the
>> kernel. its not useful, therefore, in helping with this problem.
>
>Not useful right now. CLOCK_MONOTONIC scheduling resolution will get
>better I hope.
How can it? UST cannot be the clock that is used for scheduling ...
> For MIDI output this resolution is of importance whether
>you use a UST/MSC approach or not.
>Is the clock resolution for Linux in clock_gettime() also 10ms right now?
I don't know anybody who uses this call to do timing. clock_gettime()
could have much better resolution, since it can use the same timebase
as gettimeofday(), which is based (these days) on the cycle counter.
>What is the correct clock to use for timestamping if not CLOCK_MONOTONIC?
there isn't one. thats why i agree with you that UST will be a
valuable addition to linux. i just don't agree on the scope of its
contribution.
>> what
>> you need is an API that says \"do this at time T\", and have some
>> good expectation that the jitter on \"T\" is very very small (right now,
>> its generally huge).
>
>I agree. But the question is, in what timebase should time T be given if
>not UST?
>
>> the \"firm timers\" patch helps with this immensely (and before it, the
>> KURT patches did the same thing). they don\'t involve a change to libc.
>
>No, and I\'ve tried firm timers patch and it performs great. But it doesn\'t
>add CLOCK_MONOTONIC IIRC, and thus using CLOCK_REALTIME you still run the
>risk of having the clock adjusted.
don't use either. sigitimer, or nanosleep, use the kernel jiffies
value, and when i last looked, this is monotonic. i could be wrong
about that, however.
--p
This archive was generated by hypermail 2b28 : Wed Jul 24 2002 - 15:14:14 EEST