On 12 Aug 2009, at 23:36, David Robillard wrote: > 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.
Is the count here some kind of maximum? Or the only legal value? The plugin ought to be able to stash the void * in it's internal struct. > 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. I don't quite see the need for this... > 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. Yep, that seems good. - Steve _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev