[linux-audio-dev] XAP and Event Outputs

David Olofson david at olofson.net
Mon Dec 9 10:58:00 UTC 2002


On Monday 09 December 2002 16.06, Steve Harris wrote:
> On Mon, Dec 09, 2002 at 03:00:50PM +0100, David Olofson wrote:
> > That's the feedback loop problem. As long as the host runs
> > plugins in the correct order, you'll never see this unless you
> > *actually* have loops in your network.
>
> Like in your example ;)

Hmm... Which one? (What did I mix up *this* time? ;-)


> > The way VST does it however, that wouldn't be needed, since
> > timestamps are related to buffers. 0 == start of this buffer.
> > Might look nice to plugins, but I forsee minor nightmares in
> > multithreaded hosts, hosts that want to split buffers, hosts that
> > support different buffer sizes in parts of the net, hosts that
> > support multiple sample rates in the system, communication over
> > wire,... (Yet another reason why I think the VST event system is
> > a pretty bad design.)
>
> Hmm.. I can see why this is tempting, it avoids the wrapping
> problem, among other things. Are you sure its not better that way?

Wrapping is not a problem, so why avoid it? :-)

Seriously, in Audiality, timestamps are only 16 bit, and thus wrap 
pretty frequently. The *only* problem with that is when you want to 
queue events a long time ahead. But, since since plugins are only 
supposed to mess with the time frame of the current buffer, that's 
not an issue either.

Even if the wrap happens in the middle of the buffer, you're fine, as 
long as the *delta* between the event before and after the wrap is 
smaller than half the total range of the timestamp data type.


> Speaking of which what is the conventioanl wisdom on timestamp
> sizes, 32 sounds dangerous (all the plugins have to work correctly
> accross the boundary, hard).

Easy. :-) It's wrapped in API macros, so you won't have to see any of 
that (rather trivial) integer arithmetics, unless you're doing weird 
stuff with events.


> and 64 sounds a bit wastefull, though
> its 4M years at 192k, so you dont have to worry about wrapping ;)

16 works for me! ;-)

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

OTOH, is it really *uselful* to support larger buffers than 32768 
frames...?

And, having 32 bits might fool develpers of sequencers and other 
"long time frame aware" devices into believing that you don't have to 
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.

2 Gframes is not *that* long... Especially not if you have a 
sequencer constantly running in the background to catch anything you 
ever play on your master keyboard. (Something I'll *definitely* 
implement!)


> > BTW, feedback loops would be the major reason why a host would
> > want to run parts of the net with smaller buffers. See why I
> > discarded the idea of buffer related timestamps? :-)
>
> Ouch. Changing the buffer size sounds messy and inefficient.

(Still, VST hosts do it all the time, since automation "events" are 
still passed through function calls... *heh*)

Anyway, even with a timestamped event system, this is the *only* way 
you can handle feedback loops.

And what's so messy about it? Less frames/cycle means you can use the 
standard buffers, and timestamps not being buffer relative means you 
don't have to do anything extra at all with events. Just loop over 
the sub-net with the "offending" plugins until you have a full 
buffer, and then go on as usual. It doesn't even screw up event 
ordering, so you don't need extra shadow + sort/merge or anything.


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



More information about the Linux-audio-dev mailing list