Subject: Re: [linux-audio-dev] Problem and Solution: time
From: David Olofson (audiality_AT_swipnet.se)
Date: ti tammi 11 2000 - 19:11:56 EST
On Sun, 09 Jan 2000, Roger Larsson wrote:
> Problem: how to express time, sample frequency and no of samples?
Yes, indeed! :-) I've thought some about this, but haven't messed much
with the low level details yet.
> Possible solution:
> as a fraction of periods and sample frequency!
> periods / Hz
> both in 32 bit unsigned.
>
> s / 1 = s in seconds, range of over 100 years (like current time
> handling in Unixes)
>
> n / f where
> n = no of samples in specified frequency
> f = frequency in HZ handles all sample frequencies up to 4 GHz ( < ns )
Yes, but who is supposed to handle this, or; where does it affect the
API and process time calculations? I don't think plugins should be
expected to deal with variable resolution, but rather tell the host
what they want and/or support.
My original ide for sub sample accuracy timing was fractions of
frames. The logical reasoning is that a frame is the time unit.
Seconds are of no interest, as 1 second is a completely arbitrary
unit around here.
BTW, we have discussed using 64 bit timestamps - they would
practically eliminate the wrap problem. :-) OTOH, they're not very
efficient on 32 bit CPUs... Do we plan for the (already existing!)
64 bit CPUs, or do we aim at getting the best performance out of 32
bit machines?
Oh, here's another one for the new section;
P&S: Is time wrap a problem?
It is, but IMO, it's not a very big one. Most code can be made to
handle it correctly by just making sure the same integer size is
used throughout the calculations. Doing c = (b - a) with 32 bit ints
will always give the correct result, as long as the actual difference
is less than, or equal to MAXINT.
Many embeded systems wray several times a second, so simply saying
"Time does wrap!" in the API spec is hardly a weird solution,
especially not when dealing with performance critical stuff. This way
we can go 64 bit, or even 16 bit, but still, all implementations will
handle time correctly.
> duration:
> (td*f) / f where td is duration in seconds
> with the maximum sample frequency the maximum duration is 1 s - ok
> with 96 kHz the maximum duration is 12 hours - ok
> with the minimum sample frequency (=1) the maximum duration is >100
> years - ok
Yeah, 100 years should do for most recordings! ;-)
Anyway, this restriction is interesting even though wrapping can be
handled! If we use frames or fractions of frames - or fractions of a
specified sample rate for that matter - that means there is a
restriction as to how far away from "now" you can set a timestamp.
However, before rejecting anything but 64 bit timestamps, one must
take into account what timestamps are used for. Now, what I had in
mind was using them for little more than specifying the exact
position of an event within the current buffer during a single plugin
call. That means, perhaps even 16 bit timestamps would do!
Regarding the interprocess comm. API; timestamps with wrapping time
would be relative to the last 0 crossing. With 96 kHz and 8 fraction
bits, that means 87 seconds of buffering between two clients can be
handled correctly. And we're supposed to be dealing with a real time
communication/integration/plugin system... (?)
(Hmm... A new name CIPS. ;-)
NOTE: The notion of time inside a sequencer doesn't have to have to
depend on the timestamp format any more than the fact that MIDI does
not have timestamps dictates the internal data base format of a MIDI
sequencer. It's simply a different concept.
> special:
> 1 / 0 = one constant
I'm not quite following; what would one use this for? :-) (Keep in
mind that div by zero is very bad, so this must be checked, whether
legal or not...)
//David
.- M u C o S -------------------. .- A u d i a l i t y ----------------.
| A Free/Open Multimedia | | Rock Solid, Hard Real Time, |
| Plugin & Integration Standard | | Low Latency Signal Processing |
`------> www.linuxdj.com/mucos -' `--> www.angelfire.com/or/audiality -'
.- D a v i d O l o f s o n ------------------------------------------.
| Audio Hacker, Linux Advocate, Open Source Advocate, Singer/Composer |
`----------------------------------------------> audiality_AT_swipnet.se -'
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST