Subject: Re: [linux-audio-dev] LAAGA proposal, part ??
From: Paul Davis (pbd_AT_Op.Net)
Date: Fri Jun 08 2001 - 03:45:07 EEST
>> Ardour has already been ported to something very close to this
>> model. I have not yet added metering, and input monitoring is deeply
>> problematic but everything else works.
>
>If you read my recent message about this you will see that with "flow"
>concept this can be solved elegantly.
1) metering is a problem because in ardour there are several objects
that read the meter, and thus it should really be computed only once.
there are several problems here.
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.
second, peak meters need to be reset periodically. in ardour,
the meters are reset whenever they are read, which provides the
correct behaviour. if you implement metering via a separate client,
this is not possible to do, since many other clients may want
to read the current peak value. so, defining the reset interval
(which is quite different than the hold interval used by a display)
is tricky to do.
finally, because for input metering you need to be able to connect
an "input" to an "input", there is an inherent problem with any
system that ensures proper port polarity when connections are made.
output metering is obviously easy to do.
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.
--p
This archive was generated by hypermail 2b28 : Fri Jun 08 2001 - 05:45:40 EEST