>The current (Paul's) LAAGA proposal does not timestamp buffers. Is
>this a design problem or something that could be extended..? I'm
>looking through the OSX documentation. It's "process" callback for
>AudioUnits looks like this, page 48 in the PDF:
the engine always makes the frame time available. thats the only sort
of time we can establish, but even that relies on having a client that
can tell the engine. in order:
>struct AudioTimeStamp
>{
> Float64 mSampleTime; // the absolute sample time
This cannot be determined in a free running system. it only has
meaning when something is around to say "we are N frames past what I
consider zero", and that something cannot be the engine without
greatly complicating the API (and i also think its fundamentally
incorrect).
> UInt64 mHostTime; // the host's root timebase's
> // time
the client can get this using other means that don't involve this API.
> Float64 mRateScalar; // the system rate scalar
no clue what this is.
> UInt64 mWordClockTime; // the word clock time
there is no such concept, i don't know what they mean. word clock is a
fixed interval oscillator. its free running and doesn't have a timestamp.
> SMPTETime mSMPTETime; // the SMPTE time
you can't establish SMPTE time without providing the SMPTE frames per
second, which gets into an area i don't want to touch. you can convert
the frame time into SMTPE time very easily once you know the fps.
--p
