Re: [linux-audio-dev] MCS: 64 bit timestamps?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps?
From: Eli Brandt (eli_AT_v.gp.cs.cmu.edu)
Date: ti loka   12 1999 - 23:41:47 EDT


As to Kai's question, I ain't no active list member right now -- what
I'm working on is a thesis proposal. :-) Just lurking. Thanks for
pushing forward, folks (notably Paul and David O.).

David Olofson wrote:
> On Mon, 11 Oct 1999, Paul Barton-Davis wrote:
> > if you believe that TSC/audio card drift will be minimal, then you
> > don't need to worry.
>
> That's not the case for most users. It's pretty close for high quality
> cards, but some "consumer quality" cards even use ultra cheap ceramic
> resonators or something for CODEC time base... Heard figures like
> 44100 +/- 300 Hz *flutter*!

Recently I did a little poking around about timebase stability --
might be of interest. For pro gear, AES defines two classes, +/-1ppm
and (I think it was) 10ppm. So even with the high-class gear, that's
a few samples per minute of drift, which can't be considered minimal
assuming we want sample-precise timing.

Your basic uncompensated quartz crystal is speced at about 100ppm over
its operating range. This is what most sound cards have. I looked at
a few cheap cards and found crystals on them, but I too have heard
that some use ceramic resonators, which are rate 1000ppm and worse.

I don't know much about the time course of clock drift/flutter. I did
some measurements of a sound card relative to CPU clock (didn't have a
really good timebase), and didn't see a lot of fast activity. They
had an offset, and then drifted back and forth about 80 ppm overnight.
I think power-supply stability is going to be a factor.

> > ... set cycle_counter_at_last_sync_point in the normal way ...
> > cycle_counter_at_last_sync_point +=3D (xxx - yyy) * cycles_per_sampl=
> e.
> >=20
> > and we're done. whats so unclear ?
>
> Nothing, really... Just not sexy enough for me, I guess. ;-)

And if I understand how this is used, doesn't this mean time can go
backwards at update boundaries? If so, just fudge it so it stays flat
for a bit instead. I really like monotonicity in my timebase --
preserve ordering.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST