Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps?
From: David Olofson (audiality_AT_swipnet.se)
Date: ma loka 11 1999 - 19:46:38 EDT
On Mon, 11 Oct 1999, Paul Barton-Davis wrote:
> >> this doesn't take sample clock drift into account. the engine would
> >> have to deal with this by adjusting the
> >> cycle_counter_at_start_of_control_loop value at appropriate intervals
> >> to shift everyone's idea of the current time.
> >
> >(I don't think fiddling with the TSC timestamps is a good thing, as it
> >makes the engine code a bit unclear...)
>
> eh ? is this because there are going to be no function calls in the
> engine or something extreme like that ?
No, I just think that "cycle_counter_at_start_of_control_loop"
suggests that it's really a TSC timestamp, and not some manipulated
pseudo-TSC. No big deal, though...
[...]
> > current_cycle_counter = read_tsc ();
> > cycle_diff = current_cycle_counter -
> >- cycle_counter_at_start_of_control_loop;
> >+ cycle_counter_at_last_sync_point;
>
> what is the difference here, other than
> the name ?
"last sync point" can be just any time... Doesn't need to have any
direct relation to engine cycles.
> so i tried to ensure that it didn't need a lock, thus my avoidance of
> the use of two engine-stamped values.
>
> 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*!
> if you do need to worry about it, adjusting the cycle_counter value
> from the engine is pretty simple, as you yourself pointed out a week
> or so ago. if the engine notices:
>
> TSC sample count
> --- ------------
> nnn yyy
>
> but expected:
>
> nnn xxx
>
> it just adds to the cycle_counter_at_last_sync_point (or whatever):
>
> ... set cycle_counter_at_last_sync_point in the normal way ...
> cycle_counter_at_last_sync_point += (xxx - yyy) * cycles_per_sample.
>
> and we're done. whats so unclear ?
Nothing, really... Just not sexy enough for me, I guess. ;-)
But there's one problem: How do you know what engine cycle the
timestamp belongs to? The sensor thread runs asynchronously, just as
you wanted it to... You never know how many cycles have passed since
last time you were awake, and what if you grab a timestamp, and miss
the deadline for the next cycle? (Note: That's OK! The fixed latency
is say, 3 cycles, so there's plenty of time.)
(My previous patch backed out first)
-----8<------------------------------
current_cycle_counter = read_tsc ();
cycle_diff = current_cycle_counter -
- cycle_counter_at_start_of_control_loop;
+ cycle_counter_at_engine_zero_time;
now = (msc_time_t) (samples_per_cycle * (float) cycle_diff));
------------------------------>8-----
Solved.
Engine::timestamp() now returns the time in samples relative to the
engine's idea of global time==0. Adjust
cycle_counter_at_engine_zero_time as you described above, and it's as
accurate as it gets, and we need only one shared variable.
(Well, perhaps cycle_counter_at_engine_zero_time could be something
else in a somewhat nicer unit, but that's a final implementation
detail.)
Unless I missed something, this is more like what I call sexy... :-)
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST