Hi, Here are the patches against xawtv-3.35. Be aware that this bit of hackery is far from perfect: it causes the capture rate to be visibly jerky at times, since the video capture thread is trying to sync to a time line that advances in rather large steps, and is at the mercy of the system's scheduler. The audio time line is just inherently jittery. In fact, the more I think about it, the more I'm convinced that a multithreaded capture architecture is simply a bad idea, and can't be made to work reliably. A two thread design, with a realtime priority thread doing video and audio capture, and a low priority thread doing the encoding, should work much better. In my opinion, ffmpeg's capture code would be a good starting point to get a decent video capture app up and running with minimum hacking. Anyway, there are two patches - for some reason, the only way I could get the source to patch correctly was to use: $ cd xawtv-3.35 $ patch -p 1 -l -u < capture.diff $ patch -p 1 -l -u < grab.diff I'm not sure why I need the -p 1, since the patches refer to the xawtv-3.35 directory. Oh, well. Here goes: --- xawtv-3.35/src/capture.c Wed Feb 7 17:21:53 2001 +++ xawtv-3.35-patched/src/capture.c Thu Feb 22 14:08:01 2001 @@ -172,6 +172,19 @@ return NULL; } +long long audio_msecs=0; + +long long au_getmsecs() +{ + return audio_msecs; +} + +void au_setmsecs(long long n) +{ + audio_msecs=n; +} + + static void* record_audio_thread(void *arg) { @@ -199,6 +212,7 @@ fifo_put(&h->afifo,buf); h->bytes += size; h->ausec = (long long)h->bytes * 1000000 / h->bytes_per_sec; + au_setmsecs(h->ausec/1000); } fifo_put(&h->afifo,NULL); if (debug) --- xawtv-3.35/src/grab.c Wed Feb 7 16:52:24 2001 +++ xawtv-3.35-patched/src/grab.c Thu Feb 22 13:45:16 2001 @@ -227,6 +227,8 @@ jpeg_list, }; +extern long long au_getmsecs(); + int grabber_sw_rate(struct timeval *start, int fps, int count) { @@ -237,9 +239,8 @@ if (-1 == fps) return 1; - gettimeofday(&now,NULL); - msecs = now.tv_usec/1000 - start->tv_usec/1000; - msecs += now.tv_sec*1000 - start->tv_sec*1000; + msecs=au_getmsecs(); + frames = msecs * fps / 1000; if (debug > 1) fprintf(stderr,"rate: msecs=%d fps=%d -> frames=%d |" @@ -417,4 +418,5 @@ } return buf; } > Subject: Re: Audio/video sync in xawtv > Date: Thu, 1 Mar 2001 16:53:20 -0500 > From: Thomas Hargrove <ciagon@xxxxxxxxxxxxxxx> > Reply-To: video4linux-list@xxxxxxxxxx > To: video4linux-list@xxxxxxxxxx > > I spent a good few days trying to get xawtv to produce good a/v sync > with no > success. I know for a fact that my computer was fast enough because it > was > a dual pIII w/ 512 mb and a 10k ultra160 drive. I had pretty much given > up > on xawtv. > > Where can I get your modified source? > > BTW: I tried a SB16 pci and a SBLive. > > --Tom > Subject: Re: Audio/video sync in xawtv > Date: Thu, 1 Mar 2001 22:12:14 -0500 > From: Benedict Bridgwater <bennyb@xxxxxxxxx> > Reply-To: video4linux-list@xxxxxxxxxx > To: video4linux-list@xxxxxxxxxx > > > I'd have thought that since AVI files don't store timestamps, there's no > other way to tie the video/audio streams together than to sync one to > the other (and assume that the capturing process did the same). If you > rely on the video/audio samples/sec rates being exact and therefore > being able to sync to absolute time, you're bound to drift, because > nothing ever is perfect. It's not so much a matter of having a crappy > sound card, as having a crappy a/v file format (AVI) that doesn't store > timestamps or any other sync information. > > Could you post your patch? > > Ben