Re: [LAD] Lv2 port replication [was Re: the role of lv2 extensions]

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@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Thu Aug 13 16:15:02 2009