Subject: Re: [linux-audio-dev] App intercomunication issues, some views.
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Wed Jul 24 2002 - 12:51:17 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.
> 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.
> >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.
> 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?
[...]
> 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. 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?
What is the correct clock to use for timestamping if not CLOCK_MONOTONIC?
> 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.
--martijn
Powered by ASHosting
This archive was generated by hypermail 2b28 : Wed Jul 24 2002 - 12:48:14 EEST