Subject: Re: [linux-audio-dev] LAAGA proposal, part ??
From: Tom Pincince (stillone_AT_snowcrest.net)
Date: Sat Jun 09 2001 - 21:17:05 EEST
> >Can you describe a situation where a client would want to meter
> >something other than its own input? If all input metering can be
> >handled by the owner of the input port, then there is no need for the
> >server to make this data available to non-owners.
>
>
> The problem is that there may be more than one object interested in
> the meter value from a single output port. A case in point in ardour
> (for example): a diskstream input port is connected to the output port
> of a physical audio interface "driver". a routing is using this
> diskstream for input. there are two GUI objects that want to display
> the current input peaks on a meter. where do they get the data from?
Yes, I understand the problem. I was actually referring to this
statement.
> > first of all, the actual value(s) computed by the meter are not
> > audio data, but a different type. the API under discussion does
> > not include a builtin method for transferring such data around.
In the example that you provide, the problem is contained within
ardour. This suggests that a solution can also be contained within
ardour. The API under discussion addresses the transferring of data
between applications. If *all* instances of this problem are contained
within a single application, then there is no need for LAAGA to address
the problem. I can think of no situation where the signal entering an
application needs to be metered by a different application. I can think
of no situation where an application needs to meter a signal that is not
being sent to it. If there actually are situations where this kind of
data sharing is necessary, then it makes sense to solve the problem in
LAAGA. If not, then it is an ardour problem that should be solved in
ardour. So before addressing a particular solution to your specific
example, one question must be answered. Is this a LAAGA problem?
> >> 2) input monitoring is deeply problematic because first of all you
> >> have to do the same kind of "connect an input to an input", and
> >> then secondarily, the concept simply makes no sense for the
> >> majority of ports that would exist in a running system. the idea
> >> of "turn on input monitoring" for a port that is the output of a
> >> particular object is generally nonsensical - it to make sense only
> >> if the port corresponds to a physical connection.
> >
> >The Solo-as-probe that we (Paul and I) discussed does have this
> >ability.
>
>
> Yes, Solo-as-probe works like this, but thats not the same as "monitor
> input on <this>". The semantics of the two are a little different. If
> I monitor the input on a physical audio connection, i expect to hear
> the output on the same physical channel. If I monitor a software-only
> port, its completely undefined where the output should appear if the
> interface is a multichannel device. Furthermore, soloing and input
> monitoring are really quite different operations, though its fair to
> point out that they have similar uses in the studio.
Solo and input monitoring are close enough to being identical that the
solution to one probably reveals much regarding the solution to the
other. Also, you noted that input monitoring for anything other than a
physical input simply makes no sense in general. I agree. My first
response implied, and this response will state explicitly, that solo'ing
is the only situation where input monitoring of a non-physical input
makes any sense to me. This will require an expansion of the Solo
function to work beyond ardour, and may result in Solo/Control Room
Monitoring becoming a separate client app in itself. So, as always,
here is a question. Are there any situations other than Solo where one
would want to monitor a software-only input port?
Tom
This archive was generated by hypermail 2b28 : Sat Jun 09 2001 - 22:38:14 EEST