Yep - I know the problem... I searched long and hard for a way around
it, and this code is the best I could find ;-(. I have looked at ALSA,
and it does seem to have good, atomic timestamping, but I have never
gotten around to porting yet.
For most purposes the current code works fine. I use it for
timestamping in nvrec. I have viewed timeshifted recordings longer than
4 hours already without any noticeable synch problems at any time.
-justin
Michel Bardiaux wrote:
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...
