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: David Olofson (audiality_AT_swipnet.se)
Date: su loka   10 1999 - 23:26:34 EDT


On Mon, 11 Oct 1999, Paul Barton-Davis wrote:
> >So, 64 bit time and timestamps?
>
> yes. even more significant given that the pentium cycle counter uses
> such values, though many cycle counter users only read the low order
> 32 bits.
>
> gcc is not to bad at dealing with "long long" arithmetic, either.
>
> another word about timestamps though. you suggested that in order to
> call engine->timestamp(), a sensor thread would have to preempt the
> engine. Not true.

So, how do you find out when the event that woke you up actually
occurred, if the engine blocks you out for a few ms? If that was
possible, there would be *no need* for sensor threads. (And there
isn't, if the drivers can timestamp data - which is currently not the
case with most of them.)

> more importantly, if every plugin/thread uses local
> time, and that thread has no sample time base to clock from, how can
> the engine ever convert events from that plugin/thread to its own time
> base ?

local_time = sample_count / current_cycle;

It's just a matter of convenience for plug-ins, and I doubt it makes
any sense to threads/MCS nodes. It does inside plug-ins, however,
especially in big nets with intense event activity, as it means that
plug-ins don't have to keep track of time as anything but offsets
from the first sample in the current cycle.

> this is where we need to go back to your suggestion of using the cycle
> counter to determine the current sample number. its easy to do, and
> provides very, very lightweight timing for any and everyone in the
> system.
>
> yes, it won't work on, say, a MIPS chip, but the alpha and all intel
> chips have a cycle counter. don't know about the ultrasparc.

A good time source - with a known relation to the sample time base -
is needed for *real time* events. As soon as you have events stamped
with sample time, it becomes irrelevant. So as long as we don't have
drivers that provide timestamping, TSC or some other timer + sensor
threads will be needed...

//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


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:13 EST