Re: [LAD] [Jack-Devel] jack2's dbus name

>
>> first of all.... lets assume jack is running with -p64 -n2
>> (~3ms latency)
>>
>> i am not sure if lennart is aware that jack often runs with such
>> latencies. i dont really care for event processing inside the RT
>> loop.
>> however you cant know how many clients are following in the process
>> cycle, so you cant know a sane threshold value.
>
> But that information could be made available, couldn't it? I mean, the
> Jack server has information about the graph, so it could make that
> information available to the clients.

Hum...even if this info would be available, it does not say what
*actual* duration would take the following clients ...

>
>> what i am asking for is that events are either passed into your RT
>> loop
>> via lock-free fifos
>
> As mentioned, this is what happens. that lock-free q is called
> pa_asyncmsgq.
>
> Lennart
>

I think we should go back to the beginning of the discussion: allow PA
based audio desktop application be used in the JACK graph. It don't
think it make sense to over-complexify JACK or JACK/PA interaction
just to avoid a thread context switch.

Better keep the current separated simple solution, until it can be
proven it is a real bottleneck.

Stephane
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Fri Jun 19 20:15:03 2009