Subject: Re: [linux-audio-dev] App intercomunication issues, some views.
From: Paul Davis (pbd_AT_op.net)
Date: Wed Jul 24 2002 - 16:26:52 EEST
>> >[...]
>> >> 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 ...
>
>Why not?
well, i sort of take that back. what i meant was that UST (almost by
definition) has a finer resolution than the scheduler, and that in
addition, the scheduler is subject to clock adjustment. however, on
reflection i think that the scheduler's clock is *not* subject to
adjustment, since its based on jiffies and is monotonic.
>> >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.
>
>Then what is the difference between an accurate CLOCK_MONOTONIC and UST?
>I know a UST isn\'t CLOCK_MONOTONIC, but CLOCK_MONOTONIC can be the UST,
>given it is accurate enough, rihgt?
yep.
>[...]
>> >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.
>
>I would rather use an absolute sleep using CLOCK_MONOTONIC and clock_nanosleep
>than a relative nanosleep. I\'m not sure how nanosleep is supposed to behave
>when the system clock is adjusted.
nanosleep isn't based on time-of-day, which is what is subject to
adjustment. nanosleep uses the schedule_timeout, which is based on
jiffies, which i believe are monotonic.
i believe that relative nanosleep is better than absolute sleep for
the simple reason that its how you would avoid drift in
practice. consider a JACK callback:
process (jack_nframes_t nframes)
{
jack_transport_info_t now;
/* find out the transport time of the first audio frame
we are going to deal with
*/
jack_get_transport_info (client, &now);
/* get the set of MIDI events that need to be
delivered during the period now.position to
now.position + nframes
*/
event_list = get_pending_midi_events
(now.position, now.position + nframes);
foreach event in event_list {
queue_midi_event (event);
}
... anything else ...
}
now, what is queue_midi_event() going to do? if you schedule the MIDI
data for delivery based on an absolute time, you're suddenly dealing
with long term drift again. instead, you just schedule it for an
offset from "now", typically within the next couple of msecs. this
way, the drift is then limited to whatever variance there is between
the rate of the clock used to deliver the MIDI data and the audio
clock, which over that time period (as you noted) will be very, very,
very small.
of course, the above simple example doesn't take audio latency into
account, but thats left as an an exercise for the reader :)
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. either way will work, but
the second one works right now without any extra POSIX clock support.
--p
This archive was generated by hypermail 2b28 : Wed Jul 24 2002 - 16:33:49 EEST