Re: [linux-audio-dev] LAAGA proposal, part ??

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

Subject: Re: [linux-audio-dev] LAAGA proposal, part ??
From: Tom Pincince (stillone_AT_snowcrest.net)
Date: Fri Jun 08 2001 - 23:47:45 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.

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.
 
> 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. I understand the idea of a flow and the desirability of being
able to read from any flow, regardless of whether it is an output flow
or an input flow. Traditionally flow implies displacement, data moves
from one place to the next. For this to literally occur, data must be
copied from one buffer to another. Paul's model eliminates as much data
copying as possible by essentially defining each input port as a private
bus accessible only to its owner, so the idea of flow is somewhat
hidden. It is there though. Client A may have access to the data
entering Client B without having access to Client B's buffer. Client A
only needs to have its input port list be identical to Client B's. This
can be accomplished in two ways.

1) Provide the ability for an input port to build its list by copying
the list of another input port.

2) Redefine input ports to include a list of clients that will use it
as their input port, or allowing the number of owners to be greater than
1. Buffer copying will only be necessary if this list count is greater
than 1.

Tom


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

This archive was generated by hypermail 2b28 : Sat Jun 09 2001 - 01:32:28 EEST