Re: [LAD] Multi-Channel channel order

On Fri, 2009-08-14 at 23:14 +0200, Fons Adriaensen wrote:
> On Fri, Aug 14, 2009 at 04:54:57PM -0400, David Robillard wrote:
>
> > The only thing I can think of that would make it hairier is if, say, the
> > plugin could only support multiples of some number of channels. Is this
> > necessary where the upper limit is infinity? Are there any more complex
> > requirements that are reasonable? I can't think of any, this seems way
> > beyond reasonable to me.
>
> I don't see ATM any reason to put restrictions on N (apart from some
> reasonable maximum). One thing I can imagine is that the internal
> processing would be in groups of 4 channels to exploit SSE. But even
> in that case the interface could be 1,2, or 3 less.

Sounds reasonable. I think it should be straightforward to model it in
such a way that new kinds of advanced restrictions can be added later if
it's necessary anyway, so if there's no need for this kind of stuff now,
no sense trying to define it.

> On the other hand, this makes a case for using an interleaved format,
> and for rounding up the number of _physical_ channels if the number
> of _logical_ channels is not a multiple of four. In other words the
> host would just provide some dummy channels allowing the plugin to
> use groups of four without having to copy on input an output.

Hm. True. Well, if it works out that this stuff can be spec'd such
that more complex restrictions like this can be added, we can ignore
this for now. So, we'll see. Tempting case though, if the plugin did
know there's multiple of 4 buffers always, it could use a literal 4 in
the loop, and recent GCC would probably successfully vectorize it...

I guess interleaving coming up eventually was inevitable :/

One major disadvantage to using interleaving anywhere in the plugin
interface is that it makes redistributing the data to/from LADSPA (and
LADSPA style LV2) plugins significantly more expensive, difficult, and
impossible to do in place. Ditto for JACK buffers.

Given that, I think avoiding interleaving at the plugin API level is
probably very desirable unless there's a really compelling reason to do
otherwise.

(GStreamer uses interleaved internally, if that's worth anything)

-dr

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sat Aug 15 04:15:09 2009