Subject: Re: [linux-audio-dev] XAP and Event Outputs
From: David Olofson (david_AT_olofson.net)
Date: Mon Dec 09 2002 - 17:52:48 EET
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 ---
This archive was generated by hypermail 2b28 : Mon Dec 09 2002 - 17:58:46 EET