9 Mar
2012
9 Mar
'12
9:15 a.m.
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:
[...]
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
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.