Subject: Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2
From: Paul Davis (pbd_AT_Op.Net)
Date: Thu May 10 2001 - 18:06:21 EEST
>Basically, my heart is sinking. You're very confident that everything
>is fine with your approach, but I know very well that it will cause
>problems down the line. But if you can't see that, what can I do ?
>Either vanish quietly or enter into heated discussions, but either way
>nothing much changes if neither one of us budges.
Well, I am not sure what to do about this. I understand the concern,
but I also don't see how to avoid that when I don't agree with some of
what you've said. To me, the discussion is still fruitful at this time.
>You're comparing your method to a patchbay, and you keep on claiming
>that these channel allocations are not `connections'. But they are -
>if two applications are using the same channel they are connected.
The difference is that they are "connected" via a *bus*. They are not
sharing data directly, but they share access to a common
resource. This is very different than the patch bay model, in which
connector A is connected to connector B via the bay, which provides
only "direct" wiring. Its much more like connector A is connected to
mixer line-in 1, which feeds bus #1, and connector B is connected to
bus #1 output. Other things can be writing to that bus besides
connector A. And in fact, the bus #1 output first feeds a N-way
splitter, allowing any number of things to read form bus #1. This is
why I agreed with Kai when he said "there's connected and there's
"connected""
Does this difference have any meaning in your view?
I'm not really totally against the patchbay idea (the pulsar does this
stuff very nicely, for example), but the suggestion needs a lot more
work. The most important ommission, and incidentally, the one thing
that explains why LADSPA can't be used, is the number of inputs and
outputs used by a plugin is not constant. Ardour can vary the number
of channels it uses and the number of internal objects writing to
those channels at any time. So there would need to be a "route
publication" aspect to the API. This is also a bit of a problem for
the current ALSA model, BTW, which is built around the idea of a PCM
stream having a fixed number of channels within it. This is not true
for Ardour, or Quasimodo, and I see no reason why it would be true of
many interesting applications.
This leads to what I consider to a tail-wagging-the-dog situation. If
I create a new Route object inside ardour, it needs an input and an
output. I want to select these from the mixer strip GUI that
represents a Route. In the model you're proposing, as I understand it,
we'd have to switch windows to a connection management interface that
has noticed the emergence of a new (potential) input and output, and
go hook them up. Thats what I mean about the need for connection
management to fit the design of the individual applications.
Does that example make my point of view any clearer?
--p
This archive was generated by hypermail 2b28 : Thu May 10 2001 - 18:26:07 EEST