At Mon, 26 Nov 2007 14:04:47 +0100 (CET), Jaroslav Kysela wrote:
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.
Yes. About the sync accuracy, this should be fine enough.
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.
But, OTOH, the audio-video-sync is more popular demand than multiple card sync. This might be a good working example for timestamping.
I remember I discussed about it a bit with Mauro. Nnow Cc'ed, in case he has more comments on V4L/sound sync issue.
One possible problem is that the current ALSA timestamp API provides only volatile reads, i.e. the timestamp is being constantly updated and not logged/streamed coupled with the data. That's the reason I suggested to consider the API again. We should check the use case at first...
thanks,
Takashi