10 Dec
2002
10 Dec
'02
3:18 p.m.
On Tuesday 10 December 2002 08.56, Tim Hockin wrote:
[...timestamps...]
In Audiality, there is a host variable that holds the "current event
time". That is in fact the count of the first sample in the buffer to
process.
Yes. Here are some more reasons:
* The event struct won't fit in 16 bytes anyway.
* We might want to support "extended events" within
the system, without screwing old hosts or adding
a parallel event system. So, 32 byte events are nice.
* There is no point in making the event struct smaller
than one cache line. In fact, that could even cause
severe performance issues on SMP systems. (Cache line
ping-pong.)
*hehehe* I like that! >:-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
.- M A I A -------------------------------------------------.
| The Multimedia Application Integration Architecture |
`----------------------------> http://www.linuxdj.com/maia -'
--- http://olofson.net --- http://www.reologica.se ---
Wrapping is
not a problem, so why avoid it? :-)
So time starts at some point decided by the host. Does the host
pass the current timestamp to process(), so plugins know what time
it is? I assume that if the host loops, or the user jumps
back in
song-position, time does not jump with it, it just keeps on
ticking?
Yes. You can't rewind *time*, can you? ;-)
Seriously though, the reason to do it this way is that timestamp time
is directly related to "audio time" (ie sample count) - and in a real
time system, it just keeps running all the time. I don't see a reason
to stop time, kill the audio, stop all plugins etc etc, just because
you stop the *sequencer*!
I guess my only question is how do plugins know what
time it is
now?
Check that host variable. (No call needed, since in a host with
multiple threads and/or multiple sample rates, you'd have one host
struct for each "context" anyway.)
Seriously,
though, 32 bit is probably sensible, since you'd
really rather not end up in a situation where you have to
consider timestamp wrap intervals when you decide what buffer
size to use. (Use larger buffers than 32768 frames in Audiality,
and you're in trouble.)
Anything smaller than 32 bits doesn't save you any cycles, saves a
WHOPPING 2 bytes of memory, and cause potential alignment issues to
nix your 2 byte savings. 32 bit is an obvious answer, I think. worry about
wrapping *at all* - which is not true. Use 32 bit
timestamps internally in a sequencer, and you'll get a bug report
from the first person who happens to get more than 2 or 4 Gframes
between two events in the database.
So start the timer at 0xffff0000 and force anyone testing to deal
with a wrap early on.