Subject: Re: [linux-audio-dev] questions to be resolved
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon May 21 2001 - 14:22:29 EEST
>> when something wants to write data so that it is "visible" at an
>> output port, it has to have a region of memory to write it to. is this
>> memory region owned by the output port itself, or with the input port(s) tha
>t
>> the output port is connected with? "owned" means that if the
>> connection between the ports is removed, the location of the memory
>> region remains unchanged. obviously, for at least one of the ports,
>> the location memory region must change when the connection is broken.
>
>Ok, I think we need to discuss what you call "connection" and that in my
>model is still not present (because it's on the internal side of
>soundboxes).
>
>Is this a dynamic thing (i.e. may be changed when soundbox is *not*
>relaxed)? Add, move and remove are the expected action?
Requests to change connections between ports can be made at any time.
Add and remove are the only operations. If gain is made to be a part
of the connection model, then "change gain" is also possible, but its
not so clear that this has the same consequences as add/remove.
How the request is handled is an implementation detail. In my view,
its an implementation detail of the engine. My own preferred way of
handling this is to allow asynchronous alterations in the port
connections (i.e. altering the signal graph), but to wrap it in a
mutex. During the engine's cycle, it would use the semantics of
pthread_mutex_trylock() to discover that it was not possible to run
the graph at that time, and would fallback to whatever it would do if
it had no graph at all (probably nothing at all).
I don't understand the appeal (or the mechanics) or making interport
connections be "internal" to a soundbox. The connections fundamentally
alter the order in which a series of soundboxes must be "executed", so
the engine must be able to fully determine the signal graph in order
to accomplish correct execution of the graph. "correct" means "no
cycle-duration delays between soundboxes unless there are feedback
loops between them". So some aspect of the connections must be
visible, at least to the engine.
More on how I think the port/buffer thing should work later.
--p
This archive was generated by hypermail 2b28 : Mon May 21 2001 - 14:34:28 EEST