[linux-audio-dev] XAP status : incomplete draft

David Olofson david at olofson.net
Fri Dec 13 17:27:01 UTC 2002


On Friday 13 December 2002 20.28, Tim Hockin wrote:
> > This should not be allowed, if you want to run the instrument at
> > a different rate, reinstantiate it.
>
> This makes the API simpler (one less function call).  Are there any
> drawbacks to it?  Or conversely, are there any drawback to having a
> set_rate() method which is only ever called from the inactive
> state?  It seems that if a host wants to change rate,
> re-instantiating everything is overkill, if it knows it is in a
> safe state..

Yes... Many plugins don't care at all about sample rate, and others 
can deal with it without too expensive partial reinitialization. That 
might be worth considering.

OTOH, how often do you actually change the sample rate? If you run 
plugins to generate data for a synth, you'd have resampling in 
between those plugins and the synth - but even then, you probably 
don't want to tell those plugins what's actually going on... Let them 
think they're working at a constant sample rate.

Synchronization with external machines (*) could be another reason, 
but I don't think you should tell the plugins the whole truth in that 
case either, since the idea is that the *whole system* should be 
locked at the exact same sample rate.

(*) Layla (like many other studio machines) does it by tracking the
    wordclock with it's own sample rate; can vary from 25-50 kHz
    for Layla20 or 50-100kHz for Layla24.


So, this probably only matters to the API and implementations. I 
agree that reinstantiating sounds like overkill, especially since 
many plugins will more or less ignore the change.


> > Agreed. I think tis less confusing to have to indicate that a
> > plugin /is/ deterministic though.
> >
> > Don't do what ladspa did though and mix together RT safe-ness and
> > determinicity (is that a real word?).
>
> Clarify?  Are you suggesting I change RTFL_SLOW to RTFL_NDETERM? 
> Keep in mind these are per-control flags.

Well, that's the point. Whether it's the whole plugin that is 
nondeterministic, or just this single control event handler, it still 
means the same thing: It means there is something you should never do 
from within the RT thread. So, if you want your RT thread to keep 
running at all times, you'll have to rip a plugin with 
nondeterministic controls out and run it in a fake host or something 
to handle a change of one of those controls, and then trow the plugin 
back into the real net.

Or you can try to make the offending plugin use the host's worker 
thread service to perform the actual work related to those controls. 
That's the main reason why I considered something like that. (Very 
easy for simple hosts to fake, BTW - although then they won't be able 
to run Linuxsampler and other plugins that expect *real* worker 
threads.)


> > > ...and the optional "NOTE_PITCH" that no one will ever use, of
> > > course. ;-)
> >
> > And many of us still think doesn't belong in the API... :)
>
> I've completely ignored the pitch thread.  I'll get there.  I just
> have a job during the day (which I already am abusing to read all
> you guys' emails - 30 last night! :)

It's like the old days again! *hehe* Insane bandwidth, but still the 
same extreme SNR. :-)

Lots of things to consider here...


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