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

PrevNext  Index
DateFri, 19 Jun 2009 15:59:11 +0200
From Stéphane Letz <[hidden] at grame dot fr>
ToLennart Poettering <[hidden] at 0pointer dot de>
CcJack devel <[hidden] at lists dot jackaudio dot org>, Linux Audio Developers <[hidden] at lists dot linuxaudio dot org>
>
>> 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 
PrevNext  Index

1245420203.11776_0.ltw:2,a <0E81784A-F11A-4ED6-82B9-563EF2F610C9 at grame dot fr>