7 Mar
2012
7 Mar
'12
10:42 p.m.
Hello all,
I wonder if I'm the only one experiencing this problem with
Qjackctl. Anyway I haven't seen any other reports of it.
The problem is so obvious that I myself never bothered to
report it - it's the thing you exect fixed in the next
release. But apprently it never gets fixed.
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).
Ciao,
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
7 Mar
7 Mar
10:59 p.m.
On 03/07/2012 10:42 PM, Fons Adriaensen wrote:
Hello all,
I wonder if I'm the only one experiencing this problem with
Qjackctl. Anyway I haven't seen any other reports of it.
The problem is so obvious that I myself never bothered to
report it - it's the thing you exect fixed in the next
release. But apprently it never gets fixed.
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).
Ciao,
Hello Fons,
I recognize the symptoms, I even recall having talked about it with Rui
on his blog/forum (or maybe on a SourceForge tracker of one of his
projects, probably Qtractor) but can't find anything back about it
anymore. And yes, it's such an obvious issue that likewise I didn't
bother either to report it.
Best,
Jeremy
8 Mar
8 Mar
9:06 a.m.
On 03/07/2012 11:59 AM, Jeremy Jongepier wrote:
On 03/07/2012 10:42 PM, Fons Adriaensen wrote:
Hmm, have never encountered it. Using whatever version of the software
is in Debian Sid. But probably the software I use doesn't rapidly fire
off a bunch of connections. I do wonder why you'd want to do that, but
whatever ...
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
Hello all,
I wonder if I'm the only one experiencing this problem with
Qjackctl. Anyway I haven't seen any other reports of it.
The problem is so obvious that I myself never bothered to
report it - it's the thing you exect fixed in the next
release. But apprently it never gets fixed.
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).
Ciao,
Hello Fons,
I recognize the symptoms, I even recall having talked about it with Rui
on his blog/forum (or maybe on a SourceForge tracker of one of his
projects, probably Qtractor) but can't find anything back about it
anymore. And yes, it's such an obvious issue that likewise I didn't
bother either to report it.
Best,
Jeremy 
9 p.m.
On Wednesday 07 March 2012 22:06:41 david wrote:
Hmm, have never encountered it. Using whatever version
of the software
is in Debian Sid. But probably the software I use doesn't rapidly fire
off a bunch of connections. I do wonder why you'd want to do that, but
whatever ...
Because you start a rather big ardour(1|2) session? Or you start a small to
normal sized ambisonics project (lets not even talk about bigger stuff there)?
Remember: There are jack-users out there who use jack for more then just
piping your players output through jack-rack and then to a stereo-output...
Have fun,
Arnold
9 Mar
9 Mar
7:46 p.m.
On 03/08/2012 09:59 AM, Arnold Krille wrote:
On Wednesday 07 March 2012 22:06:41 david wrote:
Yah, I saw that on one of the other replies.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
Hmm, have never encountered it. Using whatever
version of the software
is in Debian Sid. But probably the software I use doesn't rapidly fire
off a bunch of connections. I do wonder why you'd want to do that, but
whatever ...
Because you start a rather big ardour(1|2) session? Or you start a small to
normal sized ambisonics project (lets not even talk about bigger stuff there)? 
8 Mar
8 Mar
9:09 a.m.
2012/3/7 Jeremy Jongepier <jeremy(a)autostatic.com>
On 03/07/2012 10:42 PM, Fons Adriaensen wrote:
yesterday i was running some tests on hydrogen for some Jack-connection
improvements that Sebastian made and i noticed the same thing (and indeed i
had also seen this before)
but what might be interesting is that i did my tests with both Qjack and
Patchage open and Patchage seems to do a lot better when it comes to
updating connections or displaying updates
so it's quite clear to me that there is indeed a problem with QjackCtl
grtz
Thijs
Hello all,
I wonder if I'm the only one experiencing this problem with
Qjackctl. Anyway I haven't seen any other reports of it.
The problem is so obvious that I myself never bothered to
report it - it's the thing you exect fixed in the next
release. But apprently it never gets fixed.
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).
Ciao,
Hello Fons,
I recognize the symptoms, I even recall having talked about it with Rui on
his blog/forum (or maybe on a SourceForge tracker of one of his projects,
probably Qtractor) but can't find anything back about it anymore. And yes,
it's such an obvious issue that likewise I didn't bother either to report
it.
Best,
Jeremy 
9:48 a.m.
On 03/07/2012 09:42 PM, Fons Adriaensen wrote:
Hello all,
I wonder if I'm the only one experiencing this problem with
Qjackctl. Anyway I haven't seen any other reports of it.
The problem is so obvious that I myself never bothered to
report it - it's the thing you exect fixed in the next
release. But apprently it never gets fixed.
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).
i had never seen this kind of trouble, but again i seldom run hundreds
of port (dis|re)connections in probably short time
don't the "connections "refresh" button is of any help here, perhaps? i
mean, instead of a proverbial stop/start?
since last qjackctl released version (>= 0.3.8) the "refresh" button
does a complete rebuild of all connection listings instead of using some
or any previously cached items which i think is the culprit of potential
race conditions, specially if you're disconnecting and/or reconnecting
(a lot of) ports with same literal names on so short notice
byee
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
9:57 a.m.
2012/3/8 Rui Nuno Capela <rncbc(a)rncbc.org>
On 03/07/2012 09:42 PM, Fons Adriaensen wrote:
in my case the number of connections is very limited, and the refresh
button is not enough, it needs a restart Qjack to update the connections
correctly (that is only Qjack, not jackd)
i'll see if i can find a simple way to reproduce
grtz
Thijs
Hello all,
I wonder if I'm the only one experiencing this problem with
Qjackctl. Anyway I haven't seen any other reports of it.
The problem is so obvious that I myself never bothered to
report it - it's the thing you exect fixed in the next
release. But apprently it never gets fixed.
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).
i had never seen this kind of trouble, but again i seldom run hundreds of
port (dis|re)connections in probably short time
don't the "connections "refresh" button is of any help here, perhaps?
i
mean, instead of a proverbial stop/start?
since last qjackctl released version (>= 0.3.8) the "refresh" button does
a complete rebuild of all connection listings instead of using some or any
previously cached items which i think is the culprit of potential race
conditions, specially if you're disconnecting and/or reconnecting (a lot
of) ports with same literal names on so short notice
byee
--
9:59 a.m.
2012/3/8 thijs van severen <thijsvanseveren(a)gmail.com>
2012/3/8 Rui Nuno Capela <rncbc(a)rncbc.org>
important remark : i'm running 0.3.7 (havent tested 0.3.8 yet)
On 03/07/2012 09:42 PM, Fons Adriaensen wrote:
in my case the number of connections is very limited, and the refresh
button is not enough, it needs a restart Qjack to update the connections
correctly (that is only Qjack, not jackd)
i'll see if i can find a simple way to reproduce
grtz
Thijs
Hello all,
I wonder if I'm the only one experiencing this problem with
Qjackctl. Anyway I haven't seen any other reports of it.
The problem is so obvious that I myself never bothered to
report it - it's the thing you exect fixed in the next
release. But apprently it never gets fixed.
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).
i had never seen this kind of trouble, but again i seldom run hundreds of
port (dis|re)connections in probably short time
don't the "connections "refresh" button is of any help here, perhaps?
i
mean, instead of a proverbial stop/start?
since last qjackctl released version (>= 0.3.8) the "refresh" button does
a complete rebuild of all connection listings instead of using some or any
previously cached items which i think is the culprit of potential race
conditions, specially if you're disconnecting and/or reconnecting (a lot
of) ports with same literal names on so short notice
byee
-- 
11:59 a.m.
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
2:25 p.m.
On 03/08/2012 11:59 AM, Giso Grimm wrote:
[..]
Hi Giso,
Getting off topic, but I'm curious: Earlier jack1 aka jack-0.X versions
can produce clicks or even x-runs when connecting ports. Is that still
an issue with 0.121.2 ?
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
..and how many audible clicks, xruns?
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
..and how many audible clicks, xruns?
3:37 p.m.
On Thu, Mar 8, 2012 at 8:25 AM, Robin Gareus <robin(a)linuxaudio.org> wrote:
On 03/08/2012 11:59 AM, Giso Grimm wrote:
[..]
Hi Giso,
Getting off topic, but I'm curious: Earlier jack1 aka jack-0.X versions
can produce clicks or even x-runs when connecting ports. Is that still
an issue with 0.121.2 ?
jack1 will cease to be jack1 if this ever stops. its really the most
significant difference between jack1 and jack2 (the parallelism in
jack2 isn't frequently of use).
connecting ports never causes an xrun, only a click (if anything). we
take a write lock on the graph; if the process cycle fails to acquire
its own write lock, it will just send silence to output ports.
11:55 a.m.
On Thu, Mar 08, 2012 at 08:49:09AM +0000, Rui Nuno Capela wrote:
don't the "connections "refresh"
button is of any help here, perhaps? i
mean, instead of a proverbial stop/start?
since last qjackctl released version (>= 0.3.8) the "refresh" button
does a complete rebuild of all connection listings instead of using some
or any previously cached items which i think is the culprit of potential
race conditions, specially if you're disconnecting and/or reconnecting
(a lot of) ports with same literal names on so short notice
I tried 'Refresh' many times and stopped doing so because
it didn't help. Will try again with 0.3.8.
Ciao,
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
4644
days inactive
4646
days old
linux-audio-user@lists.linuxaudio.org
12 comments
9 participants
participants (9)
-
Arnold Krille -
david -
Fons Adriaensen -
Giso Grimm -
Jeremy Jongepier -
Paul Davis -
Robin Gareus -
Rui Nuno Capela -
thijs van severen