Subject: Re: [linux-audio-dev] XAP and Event Outputs
From: David Olofson (david_AT_olofson.net)
Date: Tue Dec 10 2002 - 21:13:25 EET
On Tuesday 10 December 2002 08.56, Tim Hockin wrote:
[...timestamps...]
> > 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?
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.
> 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.
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.)
> > 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.
*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 ---
This archive was generated by hypermail 2b28 : Tue Dec 10 2002 - 21:18:32 EET