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