Re: [linux-audio-dev] mux concept paper

Le 17 févr. 05, à 16:16, Alfons Adriaensen a écrit :

> On Thu, Feb 17, 2005 at 09:43:16AM -0500, Paul Davis wrote:
>
>> 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.
>
> Strange. The only way you could have an extra cycle of latency is by
> explicitly programming for it, either inserting a buffer somewhere,
> or by changing the sequence
>
> backend wakeup -> read inputs - call graph - write outputs
>
> to
>
> backend wakeup -> write outputs - read inputs - call graph

Yes, this is currently done like that in jackdmp

>
> which amounts to the same thing. How would this help in allowing
> processing to continue during graph changes ?
>
> I'm convinced it should be possible. The price to pay should not
> not be increased audio latency,

I think it depends of what is important: a "more" robust system with
one extra buffer latency or the current model.
I will make both options available in jackdmp.

> but an asynchronous interface
> to the client creation / port creation and connection functions.
> In other words, you will have to request something and the result
> will be known not when your call returns, but by some asynchronous
> event. This makes sense anyway for things that can be modified from
> any number of places at the same time.

Hum.... I'm not sure asynchronous interface is needed. In my
implementation graph state changes are "seen" by the audio thread the
next cycle, but since all calls that change the graph state are
serialized by the server, clients always see a coherent state.

Stephane
Received on Thu Feb 17 20:15:15 2005