[gmpi] Re: Reqs Discuss: 1-11
- From: "Angus F. Hewlett" <amulet@xxxxxxxxxxxxx>
- To: GMPI list <gmpi@xxxxxxxxxxxxx>
- Date: Wed, 19 Nov 2003 09:22:00 -0500 (EST)
On Wed, 19 Nov 2003, Steve Harris wrote:
> On Wed, Nov 19, 2003 at 07:30:32 -0500, Angus F. Hewlett wrote:
> > Req 11... why instantiation time? Certainly sample rate must be provided
> > before streaming start, but it seems to me that it should be possible to
> > change it between streaming sessions without tearing down and
> > reinstantiating the whole plugin. Also, why would a plugin not support a
> > requested sample rate? (sorry if I've missed a discussion on this)
>
> I disagree, I wouldn't like to have to support changing sample rate
> on-the-fly as a special
We're not talking about changing sample rate during streaming, just
between streaming sessions.
> - obviously plugins will have to support restoring
> from state at a different sample rate, but at least on linux changing
> sample rate is not a realtime safe operation, so it seams to me that the
> few extra cycles eaten by hte plugin is fine, to sve having two code paths
> that achience the same thing.
It's not just a few extra cycles, though... the plugin shouldn't need to
know the sample rate until PrepareForStreaming() or whatever is called
[i.e. the post-instantiation call to ready the plugin for streaming and
have it allocate any buffers it needs]. Restoring the entire state is
potentially quite an expensive operation... if we de-instantiate and
re-instantiate, we also potentially force the plugin to unload and reload
its graphics and wave resources.
Yes, I know sample rate change is too expensive to be realtime-safe, but
savestate-teardown-reinstantiate-restorestate is an order of magnitude
more expensive again, in many cases.
Regards,
Angus.
----------------------------------------------------------------------
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:
