On Wed, 2009-08-12 at 23:24 +0100, Steve Harris wrote: > On 12 Aug 2009, at 23:20, David Robillard wrote: > > > > Allow one group of ports to have either no replication, or the same > > replication count as another group of ports. Obvious example being, > > controls tend to stick to 1, audio tends to get replicated, but we may > > want to replicate the controls to match audio. So, a single plugin > > could do all of the above cases in a single instance, if the author > > wants to do it that way. > > That makes sense to me. > > The real trick is making it back compatible in a clean way.
That, and letting it change while the plugin rolls without dropouts... What immediately comes to mind is (simplified to ignore groups etc, all functions on the plugin): An instantiation class function: void* prepare_replication(uint32_t count) Which returns some opaque data structure. Non-realtime things like allocation can be done here. An audio class(*) function: void apply_replication(uint32_t count, void* data) Where the host must pass whatever the plugin passed it in prepare_replication. This way the plugin can allocate whatever auxiliary data structures or compute tables or whatever non-realtime stuff needs to be done, then apply it in realtime, without having to bother the plugin with a bunch of threading junk that should be the host's problem anyway. (Apply NULL to taste for plugins that need no data etc) On backwards compatibility, something like "if apply_replication has never been called, the port buffer is a single, normal buffer of the given data type" seems to be all that would work. Not too bad, I think. If this is a problem for some reason it can always be made a mandatory feature for the plugin. -dr (* We should change this to "process class") _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
