Hey Michel, At 01:46 PM 5/27/03 +0200, Michel Bardiaux wrote: >This is *exactly* why I need accurate timestamps. Our application is for >24/7 auditing, so has to be both accurate and robust. Hence I have to >merge the video and audio streams with a sequence of beats from the >*system* clock (which is tightly coupled to a DCF77 radio-clock >receiver). So, I need true stamps, i.e. the value of the system clock >(which is the trusted one) on every frame, both video and audio. >Certainly *not* timestamps generated by the sound card! I think Alan's main point is that ALSA won't solve your problem, it will (at best) narrow it down a bit. And the fact that timestamps aren't 100% accurate doesn't mean that you can't build a 24/7 video/audio archiving system. The company I work for does exactly the same thing and we use v4l1 (!) and oss (!), both of which are (according to your reasoning) absolutely worthless. However, since our software isn't completely clueless, this doesn't matter at all. It "just works"(tm). A/V sync is perfect, too. I don't see how length of a recording would have anything to do with accuracy of the timestamps, that is totally irrelevant. Inaccuracy per timing only has bad effects on the *current* A/V synchronization, nothing more (unless your software *is* clueless, in which case using ALSA won't make any difference). Duration of the recording doesn't matter at all here. Of course ALSA and v4l2's internal timestamps will provide slightly more accurate timestamps than v4l1 and OSS, but they won't be 100% accurate either, not even close, and its effect on the recording will be minimal. Don't praise it any more than it deserves. Ronald
