Re: timestamps on sound?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]




Justin Schoeman wrote:
I missed most of this discussion (wretched network outages - it will probably arrive in bits and pieces over the next day or two). I use the following code for OSS timestamping:

   struct audio_buf_info info;
   long long u, ntime = getntime();
   if (ioctl(fd, SNDCTL_DSP_GETISPACE, &info) < 0) {
       PERROR("Could not determine buffer offset");
       u = 0;
   } else {
       u = info.bytes;
       u *= 1000000000ULL;
       u /= realbps;
   }
   ntime -= u;

It works very well, even under OSS emulation on ALSA. (getntime is a private function that returns time in nanoseconds.)

-justin

I already had something like this, and I wished for something more accurate. The problem of non-atomicity can be somewhat obviated by using a time call before *and* after the ioctl. Still, there remains 1 problem: the frequencies on sound cards are notoriously *not* exact. So, I wished for timestamps on *every* sample, so that I could fake a 'perfect' stream by duplicating or shedding 1 byte from time to time. I probably can do it on the basis of your code, but it is going to be a bit more complicated: if I do read() of 1 sample at a time, performance is going to be awful (I think). But if I read big chunks, the error on the estimated timestamp for the first sample of the buffer will be biggish...


Michel Bardiaux wrote:



Ronald Bultje wrote:

hi Michel,

On Fri, 2003-05-16 at 11:08, Michel Bardiaux wrote:

My grab application works OK with V4L as far as video is concerned, but I have a problem with sound (using OSS): I would like to have exact timestamps on every sample in the sound stream, and I couldnt find anything about that in any OSS documentation I could find on the web. Any recommendations?




OSS doesn't provide timestamps. Simply call gettimeofday() after
receiving a sound buffer.



As is often the case with 'simply...'-stic solutions (in French, we call that a YAKA) it does not work. Because (1) there could well be *another* buffer already available in the kernel (2) the process could be rescheduled between the read and the gettimeofday.


Ronald






--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list


--
Michel Bardiaux
Peaktime Belgium S.A.  Bd. du Souverain, 191  B-1160 Bruxelles
Tel : +32 2 790.29.41




[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux