Re: [linux-audio-dev] App intercomunication issues, some views.

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] App intercomunication issues, some views.
From: Paul Davis (pbd_AT_op.net)
Date: Wed Jul 24 2002 - 02:06:45 EEST


>> UST = Unadjusted System Time
>>
>> I haven\'t seen any implementations of UST where you could specify a
>> different source of the clock tick than the system clock/cycle timer.
>
>Well, no. Is this needed. The UST should just be an accurate unadjusted
>clock that can be used for timestamping/scheduling events.

UST can be used for timestamping, but thats sort of useless, since the
timestamps need to reflect audio time (see below). UST cannot (on my
understanding) be used for scheduling.

>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. 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.

>
>> >Using UST would also enable syncing to video or some other media
>> >stream without it all residing in the same API.
>>
>> Something has to connect the UST to the applications, and I have not
>> seen anything in the definition of UST that would put UST in user
>> space.
>
>I don\'t really understand. For a POSIX system, UST is CLOCK_MONOTONIC. Now
>I know Linux does not yet support this, but it will eventually. Apparently
>adding CLOCK_MONOTONIC to libc will change its ABI.
>If CLOCK_MONOTONIC is accurate enough, then it can be used to sync
>audio/midi/video by associating the performance time (e.g. with audio as
>the master, MSC) with the UST.

CLOCK_MONOTONIC doesn't change the scheduling resolution of the
kernel. its not useful, therefore, in helping with this problem. 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).

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.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Jul 24 2002 - 02:16:41 EEST