linuxaudio.org

>

quoted text
>> 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 ...
>

quoted text
>> 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@lists.linuxaudio.org

http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev