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

From: David Robillard <dave@email-addr-hidden>
Date: Thu Aug 13 2009 - 20:12:54 EEST

On Thu, 2009-08-13 at 11:03 +0100, Steve Harris wrote:
> 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...

You can't allocate things and precompute tables and such in the process
thread. It must be split like this if the replication is to change
while the plugin rolls.

(Actually it's tempting to go a tiny bit further and replace count with
features and just have a generic mechanism for this. It crops up all
over the place. That's getting ahead of ourselves though)

-dr

_______________________________________________
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 20:15:02 2009

This archive was generated by hypermail 2.1.8 : Thu Aug 13 2009 - 20:15:02 EEST