[linux-audio-dev] XAP and Event Outputs

Steve Harris S.W.Harris at ecs.soton.ac.uk
Mon Dec 9 11:36:01 UTC 2002


On Mon, Dec 09, 2002 at 04:52:48PM +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? ;-)

You example had (unless I misunderstood) an output from an instrument
feedback into itsself.
 
> > 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? :-)

Well, its is, but...
 
> 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.

OK, that would remove my worries.
 
> OTOH, is it really *uselful* to support larger buffers than 32768 
> frames...?

Probably not, but I dont think its useful to express timestamps in 16bit
chunks. You either throw away another 16bits or your data would loose
32bit alignment.
 
> 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 

Yes, this has happened to me in an oscilator inplementation, which is why
I'm concerned :)

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

Why? You can accept that there will be some extra latency in one section
of the loop and it doesn't usually matter. Granted its not ideal, but
blockless processing /really/ isn't practical on CPUs yet c.f. OT
discussion.
 
> 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 

OK, not messy, just supprising, as in "all I did was place a plugin in
here and suddenly the cpu cost went up three times, your plugin is
broken"

- Steve



More information about the Linux-audio-dev mailing list