[gmpi] Re: Topic 5: Threading
- From: Martijn Sipkema <m.j.w.sipkema@xxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 11 Apr 2003 00:00:49 +0100
> I'm not sure either, which is why I'm asking. 8-) I was just
> thinking that perhaps there could be a minor efficiency/simplicity
> advantage to the callback approach.
>
> In other words, if gmpi is going to rely on a counter argument for
> underrun checking, then the ::process() method of every gmpi plug
> (that cares about handling underruns) will have to compare the
> argument to an expected value every time it's called, and do the work
> of tracking an expected value. This code will be the essentially
> same for all gmpi plugs, yet every gmpi developer will have to
> provide their own implementation for this functionality.
It really is only if the current process() position is the previous
position + the number of frames in the previous process() and it
only needs to be checked when the plugin uses this information.
> By contrast,
> with a callback approach, all gmpi developers could avoid all that
> code in ::process() -- i.e. you'd write ::process() without that
> check, assuming success -- and move all the error recovery stuff
> inside the if(){...} into the underflow callback handler method.
>
> I mean, yes, essentially the same work would still have to be done on
> the host side, but a) it would simplify plug development, which IIRC
> is one of our goals
One could also argue that having a callback is more complex since
it might want to handle the xrun in the process() function.
> , and b) it would give the host the option of
> either caring or not caring about underflow recovery (i.e.upon
> underflow, either call, or else don't call, the plugs' underflow
> callback handlers).
Providing the position counter shouldn't be a problem for even the
simplest host.
> I wouldn't even have mentioned it, except that
> underflow handling is something that many kinds of
> audio-output-generating plug arguably should gracefully deal with
> anyway (even if 'dealing' means just muting, or bypassing, or
> loop-and-fade, etc.). For example, graceful underflow handling in a
> plug-in used in internet streaming radio applications would be an
> important consideration,
This could be said to be on another level. The host could just
do zero padding or something similar because it _will_ probably
want a contiuous output even if no input data is available.
> whereas in a MIDI/audio pro DAW any
> underflow should usually be regarded as fatal. (Though softening
> their own underflow clicks might be a nice thing for failing plugs to
> do [at the same time they signal failure to the host], just to save
> eardrums.)
In general all xruns are fatal I think and I don't see how the plugin
could provide click prevention.
--ms
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
