[linux-audio-dev] mux concept paper

[Stéphane Letz]

Le 17 févr. 05, à 15:43, Paul Davis a écrit :

>>> you can have absolute minimal latency, but that requires
>>> locking the graph against use when it is reordered.
>>
>> AFAICS, that is not the real reason. If it were, the simple
>> solution would be to let the engine continue using a copy
>> of the current graph while the new one is being computed and
>> the required resources created.
>>
>> Probably if look you into it deep enough you'll find that the
>> necessity to stop processing while new clients are created
>> or when the port connection change can be traced back to the
>> combined effect of:
>>
>> 1. only having one JACK-controlled thread in each client,
>> 2. the synchronous nature of the API calls that modify
>>   the graph.
>
> stephane's new OSX implementation (jackdmp) avoids both of these, and
> ends up with an extra process-cycle worth of latency. he does exactly
> what you suggest above. is it avoidable? i don't know. stephane didn't
> seem to think so when we talked about it briefly on IRC. maybe it can
> be.
>
> --p
>
>

Just one word about the "one extra process-cycle worth of latency":  
this is not exactly related to the fact that the graph is updated 
without stopping the audio thread  : one could perfectly keep the 
current model (where the server waits for the client graph execution 
end  to write the output buffer ) *and* have the "don't stop audio 
thread" property most of the time.

The  "one extra process-cycle worth of latency" is a consequence of 
another  idea to implement a more "robust" system, where robust mean a 
system where *some* audio clients may fail during one cycle without 
stopping  the entire graph.

Stephane