Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps?
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ma loka 11 1999 - 13:50:50 EDT
>> 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 ?
>The engine's cycle time should be locked to a master time base -
>usually the "master" audio card - and everything else should adapt to
>that. (Slave audio cards will need sample skip/insert or something
>similar in the interface thread/plug-in/<whatever>.)
>
>That is, some other thread wanting a timestamp need only worry about
>the *master* time base - the one that's determined by the current
>sample count of the engine's timing master.
>
>Change all timestamps *outside* plug-ins to absolute time (as I
>suggested somewhere...), and:
>
> 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 ?
> now = (msc_time_t) (samples_per_cycle * (float) cycle_diff));
>+ now += sample_count_at_last_sync_point;
heh. this is what i wrote on my first attempt, and then i said to
myself (quoting you):
>NOTE: As the code looks right now, it needs a lock! Pointer to struct?
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.
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 ?
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST