30 Sep
2009
30 Sep
'09
4:54 p.m.
A classic needs no introduction.
QjackCtl 0.3.5 slipped away!
Website:
http://qjackctl.sourceforge.net
Project page:
http://sourceforge.net/projects/qjackctl
Downloads:
- source tarball:
http://downloads.sourceforge.net/qjackctl/qjackctl-0.3.5.tar.gz
- source package (openSUSE 11.1):
http://downloads.sourceforge.net/qjackctl/qjackctl-0.3.5-1.rncbc.suse111.sr…
- binary packages (openSUSE 11.1):
http://downloads.sourceforge.net/qjackctl/qjackctl-0.3.5-1.rncbc.suse111.i5…
http://downloads.sourceforge.net/qjackctl/qjackctl-0.3.5-1.rncbc.suse111.x8…
- binary packages (Ubuntu 8.04 LTS):
http://downloads.sourceforge.net/qjackctl/qjackctl_0.3.5-1.rncbc.ubuntu804_…
http://downloads.sourceforge.net/qjackctl/qjackctl_0.3.5-1.rncbc.ubuntu804_…
- binary packages (Ubuntu 9.04):
http://downloads.sourceforge.net/qjackctl/qjackctl_0.3.5-1.rncbc.ubuntu904_…
http://downloads.sourceforge.net/qjackctl/qjackctl_0.3.5-1.rncbc.ubuntu904_…
Weblog (upstream support):
http://www.rncbc.org
License:
QjackCtl is free, open-source software, distributed under the terms of
the GNU General Public License (GPL) version 2 or later.
Change-log:
- Late support for UTF-8 encoded client/port names.
- Allow only one single patchbay connection to or from an exclusive
socket (mitigating bug #2859119).
- Automatic crash-dump reports, debugger stack-traces (gdb),
back-traces, whatever, are being introduced as a brand new configure
option (--enable-stacktrace) and default enabled on debug build targets
(--enable-debug).
- Probable fix on the audio connections with regard to client/port
(re)name changes (an ancient bug reported by Fons Adriaensen).
- Portaudio device selector is now available (after a patch handed by
Torben Hohn and Stephane Letz).
- A couple of primitive D-Bus interface slots have been introduced,
giving the option to start/stop the jackd server from the system bus eg.
via dbus-send --system / org.rncbc.qjackctl.start (.stop), (a nice
addition supplied by Robin Gareus, thanks).
- New command line option (-a, --active-patchbay=[path]) to specify and
activate a given patchbay definition file (a simple patch sent by John
Schneiderman, thanks).
- Added one significant digit to DSP Load percentage status display.
- Tentative support for netjack (slave) by adding the "net" driver to
the existing backend driver options on the Setup/Settings section.
- Converted obsolete QMessageBox forms to standard buttons.
- New patchbay snapshot now raises the dirty flag and allows for the
immediate salvage of patchbay definition profile.
- Conditional build for JACK port aliases support (JACK >= 0.109.2).
- Alternate icon sizes other than default 16x16, are now effective to
the Connections widget (Setup/Dislay/Connections Window/Icon size).
Enjoy,
--
rncbc aka Rui Nuno Capela
rncbc at rncbc dot org
http://www.rncbc.org
2 Oct
2 Oct
5:03 p.m.
On Wed, 2009-09-30 at 19:58 +0100, Rui Nuno Capela wrote:
- A couple of primitive D-Bus interface slots have
been introduced ...
Can somebody give a pointer to why D-Bus is desireable in an
RT-envoronment? What is the magic we do not wan't to live without?
I am asking this because I am experiencing that the 'Kit'-family is
doing nameserver lookups before allowing to open a window with my
current soundcard mixer levels.
That it at times takes more than five seconds to open a window
displaying only a handful of bytes (locally available), tells me that
something is not working excactly as intended.
Oh! BTW: Why am I revealing this kind of information about local
activity to my ISP in the first place?
5:47 p.m.
On Fri, Oct 02, 2009 at 09:02:09PM +0200, Jens M Andreasen wrote:
(1)
I am asking this because I am experiencing that the
'Kit'-family is
doing nameserver lookups before allowing to open a window with my
current soundcard mixer levels.
(2)
That it at times takes more than five seconds to open
a window
displaying only a handful of bytes (locally available), tells me that
something is not working excactly as intended.
Or exactly as expected.
If either (1) or (2) is true that illustrates how completely sick
this whole Kit stuff is. BTW also gdm seems to do DNS lookups - at
least you can make it hang for some minutes if you have a working
net connection but no DNS.
I'd advise the Machiavellian approach
<http://en.wikipedia.org/wiki/Niccol%C3%B2_Machiavelli>
which basically means to exterminate the whole family.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
7:25 p.m.
On Fri, 2009-10-02 at 21:45 +0200, Fons Adriaensen wrote:
I'd advise the Machiavellian approach
<http://en.wikipedia.org/wiki/Niccol%C3%B2_Machiavelli>
which basically means to exterminate the whole family.
I am present (as in 'been there, done that') with Chinese workers in
Neapels as well were the Napolitans intended to to dump thir garbage
(Sardinia.) Been there too.
Me and my significant other at the time made an synopsis for a short
movie including an insane amount of garbage as well as black bags
containainig ... We discussed what kind of person the grandmother
occasionally visible from the main characters balcony, who she might be?
It is suspected in the script that she (the garandmother) takes part in
the killings.
On the monday just after that discussion. Sophia Loren [she is from
Neapels] protested publically in every newspaper known to man against
shippin Neapels problems to Sardinia ...
YES! ... That's my grandma :)
Berlusconi is a nice guy, but there is a line somewhere in between Italy
and Sicily where he has to accept that he is just not in power anymore.
Ciao,
/jma
6:04 p.m.
On Friday 02 October 2009 21:02:09 Jens M Andreasen wrote:
On Wed, 2009-09-30 at 19:58 +0100, Rui Nuno Capela
wrote:
dbus has nothing to do with dns-lookups. In principle dbus is network-
transparent. But in practice only with complicated authentication (that only
works on the same computer) or with a special patch to allow anonymous
connections. So the default mode of the servers don't activate network
support.
The magic it provides:
De-coupling functionality from the gui. And allowing several guis to represent
the same at the same time. And IPC in general.
- A couple of primitive D-Bus interface slots
have been introduced ...
Can somebody give a pointer to why D-Bus is desireable in
an
RT-envoronment? What is the magic we do not wan't to live without? I am asking this because I am experiencing that the
'Kit'-family is
doing nameserver lookups before allowing to open a window with my
current soundcard mixer levels.
Unless I missed a dbus-kit, one has nothing to do with another.
But I concur that the *kit crap is taking much to much space and time.
Someone should write drop-in packages that satisfy dependencies but don't run
the stuff.
Arnold
6:49 p.m.
Arnold Krille wrote:
At least on opensuse all *Kits seem to depend libdbus...
The magic it provides:
De-coupling functionality from the gui. And allowing several guis to represent
the same at the same time. And IPC in general.
That's nothing new and has been done way before dbus existed. And there
are more efficient ways to handle it. Even CORBA is faster in most
cases, because many implementations know how to use shared memory as a
message transport instead of sockets.
In general, dbus is very slow way to do IPC and does unnecessary context
switches to a bottleneck called dbus-daemon. But on the otoh, "buy a
faster CPU" seems to be the standard solution to any performance
problems these days.
I am asking
this because I am experiencing that the 'Kit'-family is
doing nameserver lookups before allowing to open a window with my
current soundcard mixer levels.
Unless I missed a dbus-kit, one has nothing to do with another. 
8:29 p.m.
On 10/03/2009 05:02 AM, Jens M Andreasen wrote:
On Wed, 2009-09-30 at 19:58 +0100, Rui Nuno Capela
wrote:
Surely this particular issue can be disabled?
Dbus support is critical to making sure jack2 and pulse audio work
together ootb without having to use a workaround loader script.
I thought, I also read that it's a compile time option too so if you
don't particularly want it then you can disable dbus support in qjackctl
before starting.
Patrick Shirkey
Boost Hardware Ltd
- A couple of primitive D-Bus interface slots
have been introduced ...
Can somebody give a pointer to why D-Bus is desireable in an
RT-envoronment? What is the magic we do not wan't to live without?
I am asking this because I am experiencing that the 'Kit'-family is
doing nameserver lookups before allowing to open a window with my
current soundcard mixer levels.
That it at times takes more than five seconds to open a window
displaying only a handful of bytes (locally available), tells me that
something is not working excactly as intended.
Oh! BTW: Why am I revealing this kind of information about local
activity to my ISP in the first place?
3 Oct
3 Oct
9:03 a.m.
Patrick Shirkey wrote:
On 10/03/2009 05:02 AM, Jens M Andreasen wrote:
fyi:
this new dbus thing in qjackctl is NOT related what-so-ever with
jackdbus or any intrinsic jackd/pulseaudio dbus ipc facility.
the new qjackctl dbus thing is just about controlling qjackctl itself,
i'll repeat, qjackctl and NOT jackd. although it controls the later
indirectly as the former was devised to get access to the qjackctl
"start" and "stop" service functions from outsiders, eg. from an
external script or user process--in fact, it was primarily suggested to
make it easy for integration with suspend/resume scripts.
thus, you can start the qjackctl controlled service by issuing the
following command:
dbus-send --system / org.rncbc.qjackctl.start
and stopping with:
dbus-send --system / org.rncbc.qjackctl.stop
sure enough, you can disable it at build/configure time:
./configure --disable-dbus
hth
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On Wed, 2009-09-30 at 19:58 +0100, Rui Nuno
Capela wrote:
Surely this particular issue can be disabled?
Dbus support is critical to making sure jack2 and pulse audio work
together ootb without having to use a workaround loader script.
I thought, I also read that it's a compile time option too so if you
don't particularly want it then you can disable dbus support in qjackctl
before starting.
- A couple of primitive D-Bus interface slots
have been introduced ...
Can somebody give a pointer to why D-Bus is desireable in an
RT-envoronment? What is the magic we do not wan't to live without?
I am asking this because I am experiencing that the 'Kit'-family is
doing nameserver lookups before allowing to open a window with my
current soundcard mixer levels.
That it at times takes more than five seconds to open a window
displaying only a handful of bytes (locally available), tells me that
something is not working excactly as intended.
Oh! BTW: Why am I revealing this kind of information about local
activity to my ISP in the first place?
7:02 p.m.
On Sat, Oct 03, 2009 at 11:58:42AM +0100, Rui Nuno Capela wrote:
the new qjackctl dbus thing is just about controlling
qjackctl itself,
i'll repeat, qjackctl and NOT jackd. although it controls the later
indirectly as the former was devised to get access to the qjackctl
"start" and "stop" service functions from outsiders, eg. from an
external script or user process--in fact, it was primarily suggested to
make it easy for integration with suspend/resume scripts.
With the new release is it still possible to
- start qjackctl while you have an already running jackd,
and have it connect to that jackd,
- and later terminate qjackctl and leave the jackd rumning,
- repeat this as many times as necessary ?
This is sort of essential to the way I use qjackctl today.
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
8:16 p.m.
Fons Adriaensen wrote:
On Sat, Oct 03, 2009 at 11:58:42AM +0100, Rui Nuno
Capela wrote:
all positive but "terminate qjackctl and leave the jackd rumning"...
iif jackd was started from under qjackctl, it will get killed upon
qjackctl destruction--this is one side-effect since qjackctl has
migrated to qt4 (qjackctl >= 0.3.0) so it's not kind of a mis-feature of
this particular release. it's been there for quite a couple of years now
(shrug:)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
the new qjackctl dbus thing is just about
controlling qjackctl itself,
i'll repeat, qjackctl and NOT jackd. although it controls the later
indirectly as the former was devised to get access to the qjackctl
"start" and "stop" service functions from outsiders, eg. from an
external script or user process--in fact, it was primarily suggested to
make it easy for integration with suspend/resume scripts.
With the new release is it still possible to
- start qjackctl while you have an already running jackd,
and have it connect to that jackd,
- and later terminate qjackctl and leave the jackd rumning,
- repeat this as many times as necessary ?
This is sort of essential to the way I use qjackctl today.
8:47 p.m.
On Sat, Oct 03, 2009 at 11:11:09PM +0100, Rui Nuno Capela wrote:
Fons Adriaensen wrote:
The use case is about a jackd that was *not* started
by qjackctl. Release 0.3.4 does the right thing, I
just hope 0.3.5 does the same.
The other case, starting a jackd from qjackctl and
leave it running when qjackctl exits would be useful
as well, and earlier versions could do this. But I
remember your comment about qt4's subprocess class
making this impossible. Damn qt4.
BTW a non-qt version of qjackctl would be welcome.
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
With the new release is it still possible to
- start qjackctl while you have an already running jackd,
and have it connect to that jackd,
- and later terminate qjackctl and leave the jackd rumning,
- repeat this as many times as necessary ?
This is sort of essential to the way I use qjackctl today.
all positive but "terminate qjackctl and leave the jackd rumning"...
iif jackd was started from under qjackctl, it will get killed upon
qjackctl destruction--this is one side-effect since qjackctl has
migrated to qt4 (qjackctl >= 0.3.0) so it's not kind of a mis-feature of
this particular release. it's been there for quite a couple of years now
(shrug:) 
9:17 p.m.
On Sun, 4 Oct 2009 00:45:27 +0200
Fons Adriaensen <fons(a)kokkinizita.net> wrote:
On Sat, Oct 03, 2009 at 11:11:09PM +0100, Rui Nuno
Capela wrote:
This works if you send it a SIGTERM or SIGKILL, I think killall does
exactly that.
Not the way it's intended to work and both seems to cause an xruns,
but it works.
Regards,
Philipp
Fons Adriaensen wrote:
The use case is about a jackd that was *not* started
by qjackctl. Release 0.3.4 does the right thing, I
just hope 0.3.5 does the same.
The other case, starting a jackd from qjackctl and
leave it running when qjackctl exits would be useful
as well, and earlier versions could do this. But I
remember your comment about qt4's subprocess class
making this impossible. Damn qt4.
BTW a non-qt version of qjackctl would be welcome. With the new release is it still possible to
- start qjackctl while you have an already running jackd,
and have it connect to that jackd,
- and later terminate qjackctl and leave the jackd rumning,
- repeat this as many times as necessary ?
This is sort of essential to the way I use qjackctl today.
all positive but "terminate qjackctl and leave the jackd rumning"...
iif jackd was started from under qjackctl, it will get killed upon
qjackctl destruction--this is one side-effect since qjackctl has
migrated to qt4 (qjackctl >= 0.3.0) so it's not kind of a
mis-feature of this particular release. it's been there for quite a
couple of years now (shrug:) 
4 Oct
4 Oct
2:15 a.m.
BTW a non-qt version of qjackctl would be welcome.
You might want to spur this one on:
http://www.marcochapeau.org/software/pyjackctl
7:37 a.m.
Fons Adriaensen wrote:
On Sat, Oct 03, 2009 at 11:11:09PM +0100, Rui Nuno
Capela wrote:
when jackd was not started by qjackctl, then showing the "Active" status
indication as opposed to the "Started" one, you can perfectly leave it
without terminating jackd. however, please take care to check if your
post-shutdown script (Setup.../Options/Scripting) is not the once
suggested default, `killall jackd`, in which case it will do the "wrong"
thing ;)
Fons Adriaensen wrote:
The use case is about a jackd that was *not* started
by qjackctl. Release 0.3.4 does the right thing, I
just hope 0.3.5 does the same.
With the new release is it still possible to
- start qjackctl while you have an already running jackd,
and have it connect to that jackd,
- and later terminate qjackctl and leave the jackd rumning,
- repeat this as many times as necessary ?
This is sort of essential to the way I use qjackctl today.
all positive but "terminate qjackctl and leave the jackd rumning"...
iif jackd was started from under qjackctl, it will get killed upon
qjackctl destruction--this is one side-effect since qjackctl has
migrated to qt4 (qjackctl >= 0.3.0) so it's not kind of a mis-feature of
this particular release. it's been there for quite a couple of years now
(shrug:) The other case, starting a jackd from qjackctl and
leave it running when qjackctl exits would be useful
as well, and earlier versions could do this. But I
remember your comment about qt4's subprocess class
making this impossible. Damn qt4.
yes, well, one could hack and port the Qt4 class implementation and get
rid of the implied kill() on QProcess::dtor(), something i've pondered a
long time ago, but never materialized ... the uber-procrastinator always
strikes whenever you expect it to, again and over again :)
BTW a non-qt version of qjackctl would be welcome.
probably not, from yours trully ;)
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
5557
days inactive
5561
days old
linux-audio-dev@lists.linuxaudio.org
13 comments
8 participants
participants (8)
-
Arnold Krille -
Fons Adriaensen -
hollunder＠gmx.at -
Jens M Andreasen -
Jussi Laako -
Patrick Shirkey -
Ray Rashif -
Rui Nuno Capela