Re: slow operation of jack_connect (was Re: connect ports with jack1 vs jack2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Hi Joel et al.,

On 03/08/2012 09:25 PM, Joel Roth wrote:
> On Thu, Mar 08, 2012 at 03:25:46PM +0100, Giso Grimm wrote:
>> jack sessions with several hundred
>> ports/connections make jack2 nearly unusable in terms of connection time
>> :-( It looks as if it would take four cycles to complete a port
>> connection. I think here is some space for improvement (e.g. allow
>> asynchronous connections and return immediately from jack_connect), but
>> maybe this will come with all the session management solutions...
>> (actually both versions have their pros and cons, which is the reason
>> for me to switch often between them, depending on my actual needs).
> 
> Hi Giso,
> 
> The slowness of jack_connect came up earlier on this
> list.[1] 
> 
> It becomes an issue in Nama when a track gets its input from
> twenty or thirty JACK clients, especially since Ecasound
> needs to re-connect JACK clients every time the audio engine
> is reconfigured (which Nama does frequently).
> 
> Paul Davis suggested I use jack.plumbing instead. 
> 
[...]
> 
> 1.  http://thread.gmane.org/gmane.linux.audio.users/68307/focus=68318
> 
> 

I think what Paul suggested there is more related to the client create
time (which might also be an issue also with jack1), but my timing
problem does not depend on the client creation, actually it takes about
the same time if I load ardour sessions with many connected ports, or if
I create my own application and connect ports; it is the jack2 library
which takes so long. What I did not try is to connect many ports in
parallel (e.g., create 100 threads, let each of them make a port
connection, and wait until all of them finished). But I will try...

Actually I did not want to complain about jack :-) I know that jack2
needs the time (or at least parts of it) to create a glitch-free
connection while jack1 does not care about glitches. Just that the jack2
behaviour may explain some problems, observed also by others, especially
with large ardour sessions.

Giso
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user


[ALSA Users]     [ALSA Devel]     [Linux Media]     [Kernel]     [Online Dating]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Video 4 Linux]

Add to Google Powered by Linux