[linux-audio-dev] XAP and Event Outputs

David Olofson david at olofson.net
Mon Dec 9 11:53:00 UTC 2002


On Monday 09 December 2002 17.30, Steve Harris wrote:
> 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.

Well, I can't remember intentionally making such an example, so it's 
probably a mistake. :-)


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

Well, unless there is a use for another 16 bit field, and you're 
right on the limit of the current power-of-2 event size.


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

*hehe*


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

Well, lets consider that:

	* Hosts may chose whatever buffer size they want.

	* You may be running off-line, in which case you
	  could potentially run with "huge" buffers.

It still doesn't matter? I do believe concistency matters in serious 
audio applications, so latency has to be *defined* - even if not 
incredibly low.


> Granted its not
> ideal, but blockless processing /really/ isn't practical on CPUs
> yet c.f. OT discussion.

You won't need blockless. Just enforce that an explicit event delay 
plugin is used on any feedback loop connection, and have the user 
decide. You'll never need smaller buffers that sufficient for 
properly handling the shortest latency in a local "loop" - and that's 
*only* for the plugins that are actually in the loop.


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

Well, one would assume that the host forbids feedback loops without 
delay elements, so at least, the user cannot do this without being 
aware of what's going on, to some extent. If the buffer size goes 
below some sensible number, the host could warn the user about 
potential CPU load increase. ("Read docs for more info".)


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