On Mon, 26 Nov 2007, Takashi Iwai wrote:
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.
I'm not sure, if it's a real problem. Applications may handle this internally. The accurate system time might be computed from last sample position (or two last positions or last position and start timestamp) and assigned timestamp from master system clock and sample rate (linear relationship). Of course, it's question, if it will be accurate enough. But it's rather problem with lack of hardware doing timestamping itself than the audio driver subsystem which can only get time as fast as stream position is updated from hardware.
That's the reason I suggested to consider the API again. We should check the use case at first...
Yes, it's good to define goals.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project