Re: POSIX clocks and ALSA

[Heikki Lindholm <holindho@cs.helsinki.fi>]

Jaroslav Kysela kirjoitti:
> On Mon, 26 Nov 2007, Heikki Lindholm wrote:
> 
>> Takashi Iwai kirjoitti:
>>> At Mon, 26 Nov 2007 09:59:29 +0200,
>>> Heikki Lindholm wrote:
>>>> Jaroslav Kysela kirjoitti:
>>>>> On Mon, 26 Nov 2007, Heikki Lindholm wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Some years ago there was some talk about UST support in
>>>>>> Linux, but the support never happened. With the hrtimers
>>>>>> patch (and I'm not quite sure if even earlier?)
>>>>>> CLOCK_MONOTONIC would seem like a fairly good UST time
>>>>>> source. What I'd like to see, is a selectable clock for ALSA
>>>>>> timestamping, e.g. something like snd_sw_params_clock(...,
>>>>>> clockid_t clk). Would this seem plausible? I don't know that
>>>>>> much about ALSA internals, so, no idea whether different
>>>>>> clocks on different pcms/whatever would quickly turn into an
>>>>>> unmanageable mess.
>>>>> We are aware about this extension and I already proposed an
>>>>> implementation. I hope to implement it soon. Timestamps are not
>>>>> used in driver internally.
>>>> I can't seem to google up the proposal. I'd like to read it; was it
>>>> on the alsa ml?
>>> Yes, it was on alsa-devel ML.  At that time I didn't like the proposal
>>> much because currently there was no real user of timestamps.
>>>
>>> The addition of monolithc clock isn't hard, but it's an API change
>>> that involves with the kernel-side change.  So let's do it carefully.
>>>
>>> But, honestly, I'm still concerned what to be done first.  Shouldn't
>>> we discuss about the usefulness of the timestamp at first?  That is,
>>> whether the current form (API, implementation) is the best or not,
>>> what kind of user would be, and how it's used.  So far, this feature
>>> is "simply there"...
>> IMHO the current API definitely isn't the best possible, but nothing 
>> better has been available on Linux, so it's a make-do situation. My 
>> ideal would be something resembling or even 1:1 copying SGI's media 
>> libraries where every media fragment is timestamped with the UST, and 
>> the timestamps are the starting time of the media chunk in question 
>> instead of ending/sometime after time. The problem with implementing the 
>> SGI API on Linux is that AFAICT no Linux supported/available hardware 
>> supports such timestamping.
> 
> Unfortunately, we are not using audio "packets" at the moment, but 
> basically, it shouldn't be difficult to implement - think one period == 
> one packet.

Exactly what I was thinking. Maybe extend the mmap interface so that 
timestamps for every period are saved and can be queried. Then create 
(swipe from v4l2) a packet interface on top of the mmap code. Having the 
timestamp telling the buffer start time instead of end would be nice, 
too, and shouldn't be too problematic - periods are small enough, so 
that a constant offset can be used without causing much theoretical drift.
One nice thing about the SGI API is that it works for playback, too. 
When you send a packet for playback, on return, it fills in the actual 
playback time. This can/could be much more accurate than the usual 
get_delay / gettimeofday pair that's used in applications now.

>> Additionally, it might be nice to be able to add audio clocks as system 
>> wide clocks, so, that for example I could tell v4l to use timestamps 
>> from an audio clock instead of the system clock.
> 
> It's something I don't like. If you have multiple soundcards, it might be 
> problematic to select a proper audio device for sync.

Not to speak of trying to invade outside of sound/ with new clocks.. But 
that's just an idea.

-- Heikki Lindholm