[linux-audio-dev] XAP: Plugin: "But I'm not ready!"

David Olofson david at olofson.net
Wed Dec 18 14:05:01 UTC 2002


On Wednesday 18 December 2002 18.09, Steve Harris wrote:
> On Wed, Dec 18, 2002 at 05:25:18PM +0100, David Olofson wrote:
> > But then you have to stop the whole net along with the sequencer,
> > as soon as you have one of those "non-instant" plugins in the
> > net. The very point is to avoid that.
>
> Effectivly you have to anyway.

I can't see why. You don't even have to stop the plugins that aren't 
ready. They *could* actually be capable of doing real processing 
while doing background work.

For example, you don't have to kill the whole sampler just because 
it's loading a new sound for one of it's Channels. (This applies to 
Audiality, BTW. It *never* stops the RT engine, not even when loading 
and rendering sounds.)


> Realigning all the plugins will take a non finite time, so you have
> to do something while the're busy.

So, why not just keep processing audio, so you don't kill the monitor 
mix and whatever might be going on in the net?

I'd *really* like XAP hosts to be able to behave like *real 
hardware*, now that we have an OS to provide the lowlatency 
scheduling, and real audio interfaces for quality audio.


> > Besides, this doesn't just happen when you activate a plugin, but
> > could happen as soon as you move the transport, or change a
> > control. Sure, it can be handled with control hints, saying these
> > controls are not RT safe, but I think that's a bit restrictive.
>
> Are you expecting that the graph will continue to execute while
> you're waiting for the realignment? That seems a bit optomistic and
> not particularly useful.

(See above.)


> OTOH I'm not sure that a delay line (for example) can handle this
> usefully at all, it can't prefill its buffers with the previous n
> seconds of audio (which is what it would like to do), so all it can
> do is reset back to its inital state (unhelpful and slow) or ignore
> it (even more unhelpful).

Ignore what? A delay plugin is never expected to prebuffer anything 
at all. It's just expected to delay whatever it receives.

If you really want a song that you start in the middle to sound 
*exactly* as if you were doing the same thing with a prerendered 
audio file, it's getting really rather hairy.

The idea with the READY thing is just to be able to let the sequencer 
know when a plugin is ready to start playing. The alternatives are:

	1. Ignore the problem and have the host freeze, lose
	   sync and whatnot while some plugin needs to prebuffer.

	2. Just ignore the plugins that aren't ready, and play.
	   They'll chime in eventually. Expect the user to wait a
	   little longer before hitting "play" after moving the
	   play cursor, if he/she finds this random delay, missed
	   or delayed first notes etc annoying.

	3. Allow the sequencer/host/transport control wait until
	   plugins say they're ready for instant playback.


1 is obviously out, because it makes some sound cards freak out in 
various ways, which in turn may upset external sync'ed devices etc.

That leaves 2 and 3, which are identical to plugins, except that in 
3, they have a standardized control through which they indicate their 
status.


> Its basicly just sequencers (ie. plugins with internal, temporal
> data) that can do something useful with this, right?

No, it would work for samplers, hard disk recorders and the like as 
well. I've suggested a way to tell HDRs about the play cursor before 
starting the transport. The READY control would be a logical 
complement to that, for hosts that care.

It may not be a vital feature, but it's a real problem, and I think 
this is a simple solution for it.

Don't mix it up with managing background threads and stuff - that's a 
different problem, really. (For which I think I have a simple 
solution for simple cases, BTW. Linuxsampler will just have to use 
pthreads until XAP 2.0. ;-)


//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 -'
   --- http://olofson.net --- http://www.reologica.se ---



More information about the Linux-audio-dev mailing list