Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps? [simplified]
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ma loka 11 1999 - 22:14:53 EDT
>Suggestion:
> Treat the tsc as a sample-driven-unit by itself (started at cycle 0),
> but scale it to wrap in a week or so... for debug purposes
> SCALE should be a power of 2, 1 is ok!
>
>#define SCALE 1
>msc_time_t
>Engine::timestamp ()
>{
> /* greatly un-inlined to make function clear ... */
> return read_tsc() / SCALE;
>}
[ ... other code elided ... ]
yes, this is simple and convenient, but it defers and multiples the
number of floating point computation that has to be done
elsewhere. why ? because we want events timestamped with sample
accuracy, and passing around the time in units that are not samples
forces each user of the timestamp to scale it to samples.
that is, your example:
msc_time_t
Plugin::convert (unsigned sample)
{
return Engine::convert( sample / this->samples_per_second ) -
this->start_timestamp;
}
is actually the opposite of what most plugins would need to do:
sample_count_t
Plugin::convert (event_timestamp_t foo)
{
... convert event timestamp to samples ...
}
because most of them will be using event timestamps.
right ?
--p
ps. i haven't seen any reports on cycle counters running at different
speeds - i thought that the Intel SMP spec didn't allow processors to
run at different speeds. i did see some reports on counters that are
skewed wrt each other. i believe someone figured out a way to resync
them.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST