On 03/08/2012 09:58 AM, thijs van severen wrote:
2012/3/8 thijs van severen <thijsvanseveren(a)gmail.com
<mailto:thijsvanseveren@gmail.com>>
2012/3/8 Rui Nuno Capela <rncbc(a)rncbc.org <mailto:rncbc@rncbc.org>>
On 03/07/2012 09:42 PM, Fons Adriaensen wrote:
To the facts now: almost every day when I use it, and for
the last years, Qjackctl get into some cramp in which it
either
- refuses to make some connections,
- or refuses to show them,
- or makes them and then disconnects them immediately.
I don't know what triggers this, but it could be related to apps
making lots of ports connections in a short time and Qjackctl's
idea of current connections getting out of sync with reality.
Given Jack's APi for this that is no big surprise, but what
really
messes up things is that Qjackctl apparently has no means to
recover
and refresh its connections database from scratch. The only
option
is to terminate it (which takes Jack and all apps with it,
unless
Jack was started separately).
[...]
important remark : i'm running 0.3.7 (havent tested 0.3.8 yet)
I can confirm this behaviour (also qjackctl 0.3.7), I think I have this
problem only with jack1 (which might be related to the fact that jack2
takes ages to complete a port connection, here it takes 18 times as
long, see below).
- Giso
jack 1.9.7
giso@helios:~$ time (for k in system:playback_{1..26}; do jack_connect
system:capture_1 "$k"; done)
real 0m3.729s
user 0m0.056s
sys 0m1.645s
jack 0.121.2
giso@helios:~$ time (for k in system:playback_{1..26}; do jack_connect
system:capture_1 "$k"; done)
real 0m0.198s
user 0m0.031s
sys 0m0.107s