[gmpi] Re: Topic 7.3: Unconnected inputs/outputs
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 10 Jun 2003 21:48:12 -0700 (PDT)
> First of all, it can be very inefficient. It requires the plugin to
> always create all of the resources that it would need for maximum number
> of channels that it might process. Take for example a super long delay.
> If it can provide up to 10 seconds of delay, and you're dealing with 96
> kHz, and it can handle up to 8 channels, you're talking about allocating
> 30 MB just for the delay lines. And that's regardless of whether the
> plugin will be processing 1 channel or 8.
nah, too complex. I'd say one of two things for this case:
Plugins should have loadable sub-units, with the I/O. The plugin in this
case would have 1 I/O or 1 pair of I/O per unit. When you load a unit, you
get a new I/O to connect.
Not mutually exclusive to that, the plugin knows if an I/O is connected or
not. If it is not connected, don't allocate. When it is connected, use a
background thread to do the allocation.
> And beyond that, what if you want to process 9 channels? Well, you're out
> of luck because of this stupid limitation imposed by the plugin API that a
> plugin must maintain a fixed number of i/o and must always have all
> resources for them created.
This is really jumping the gun :)
> But probably most important is the fact that changing i/o configurations
> can't be realtime-safe in some contexts. Depending on the plugin, it may
> have to reconfigure things dramatically for one i/o config vs. another,
> and the assumption that such a reconfiguration will always be
> realtime-safe is just going to make things a lot harder (or impossible)
> for some plugin authors.
Background threads? Obviously some things just AREN'T realtime safe, or the
cost of making them so (like your 30 MB of mem) is too high.
----------------------------------------------------------------------
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:
