Subject: Re: [linux-audio-dev] LAAGA proposal, part ??
From: Paul Davis (pbd_AT_Op.Net)
Date: Sat Jun 09 2001 - 06:10:55 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?
>> 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.
Something to think about here, I think.
--p
This archive was generated by hypermail 2b28 : Sat Jun 09 2001 - 07:46:53 EEST