[linux-audio-dev] XAP and Event Outputs

[David Olofson]

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