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.
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.
Allowing clock selection between CLOCK_REALTIME (for backwards compatibility) and CLOCK_MONOTONIC would, however, be a start.
-- Heikki Lindholm