Re: [linux-audio-dev] laaga, round 2

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] laaga, round 2
From: Jim Peters (jim_AT_aguazul.demon.co.uk)
Date: Thu May 10 2001 - 20:20:37 EEST


Paul Davis wrote:
> 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.

Okay, I've had a think, and to me it is more important that we go
ahead with this than that I hold things up by arguing with you. What
we are hoping to achieve has enormous potential, and it would be a
great shame to lose that.

I can see how your bus model does actually leave room for a
connection-based model as well. If applications make sure that they
read and write to unused busses, another application can hook all of
those up independently, perhaps with some copy-reduction support from
the server. So we do get a connection-based model for free, really,
if we want it.

If the server also makes these channels and busses `virtual' in that
it internally optimises these down to a smaller set of buffers and a
flow-graph, then maybe it *is* feasible to allocate permanent channel
numbers for applications, so for instance my MP3 player always comes
up at channels 190-191. Maybe we could even use PID * 100 as a base,
and use that to pick up the application name in a connection manager.

In other words, I think we can work around it later if necessary.

> >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?

Yes, I understand what you're saying. The confusing part is that you
can't point to any place in the bus or channel system and say "This is
where the MP3 player signal is", because chances are it has already
been mixed with something else by then. So if you wanted to monitor
the pure MP3 player signal, you'd have to redirect the MP3 player to a
free channel, and then read off that for one feed, and put some kind
of a link plugin in to get the audio also going to the original
destination. A bit confusing, that's all.

> 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.

You're right. So long as this bus method gives us room to grow in the
future, and is simple enough to code to start with, this may be better
than trying to do anything more fancy from the beginning.

> 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.

Absolutely agreed here.

> 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.

Well, actually I was thinking of allowing any app to manage
connections if it wanted to, although as you say this would
necessitate some kind of notification system so that the others also
get to hear about it.

> Does that example make my point of view any clearer?

Let's go for it. Worst case I reckon we can pack an arbitrary
6-character string of [0-9A-Z] into a 32-bit channel_id. It would
look a bit like a radio call-sign, but I'm sure we can manage ! No
need to worry about text-wrapping in the connection manager !!
(Forgive me if I'm getting more than a little subversive here ;)
Suppressed creativity -> fountain of ideas. )

I'm serious though when I say that I'm pretty well ready to go ahead
with your bus model. Anyone else like to comment on this situation ?

Jim

-- 
 Jim Peters         /             __   |  \              Aguazul
                   /   /| /| )| /| / )||   \
 jim_AT_aguazul.      \  (_|(_|(_|(_| )(_|I   /        www.aguazul.
  demon.co.uk       \    ._)     _/       /          demon.co.uk


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu May 10 2001 - 21:02:11 EEST