Paul Davis wrote:
>
>
> 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've a better solution here in my panels (congruent read transactions).
> 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.
The engine knows everything about connections between its soundboxes,
but knows anything about connections internal to soundboxes.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org
It sounds good!
