9 Dec
2002
9 Dec
'02
12:52 p.m.
On Monday 09 December 2002 17.30, Steve Harris wrote:
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.
*hehe*
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.
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 ---
On Mon, Dec 09, 2002 at 04:52:48PM +0100, David
Olofson wrote:
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. :-)
[...]
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 ;) 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. 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"