[LAU] Fwd: [ANN] QjackCtl 0.3.3 (unstable-qt4) released!
noisesmith at gmail.com
Sun Jun 8 14:26:31 EDT 2008
---------- Forwarded message ----------
From: Justin Smith <noisesmith at gmail.com>
Date: Jun 8, 2008 11:25 AM
Subject: Re: [LAU] [ANN] QjackCtl 0.3.3 (unstable-qt4) released!
To: Rui Nuno Capela <rncbc at rncbc.org>
On many occasions I run more than one qjackctl with different servers.
I wrote a jack client that connects to multiple jack servers as a
"bridge". The trick with multiple qjackctls is to use the command
line, and type "DEFAULT_JACK_SERVER=usb qjackctl&
DEFAULT_JACK_SERVER=builtin qjackctl", and then hand configure each
instance to use the proper settings (auto-start should be off, of
course). Past releases of qjackctl work just fine for this purpose.
The DEFAULT_JACK_SERVER environment variable is used directly in the
jack libraries even if a client does not code in any support (there is
a small chance I have the environment variable wrong, I am pretty sure
it is DEFAULT_JACK_SERVER, I am using a friend's computer at the
I never figured out how to deal with the huge latency and xruns with
the jack bridge program, so it has not seen the light of public
Please do not remove this functionality, I find it useful, even with
the buggyness of bridging between jack servers.
On 6/7/08, Rui Nuno Capela <rncbc at rncbc.org> wrote:
> Fons Adriaensen wrote:
> > On Sat, Jun 07, 2008 at 06:56:15PM +0100, Rui Nuno Capela wrote:
> >> how did you, assuming that you have some solution of your own,
come to have
> >> several qjackctl instances each one running against its own jackd server,
> >> beyond the default that is?
> > I have no solution - qjackctl doesn't accept a server name option.
> > But I'd expect an upgrade to solve this problem rather than confirm
> > it. Would adding the code to accept a server name have been more
> > difficult than whatever was necessary to make it detect another
> > instance and quit ?
> i guess the question is not about whether it's been difficult, but more
> like it has never been thought out in the first place. qjackctl was
> never meant to control more than the "default" server and that's the
> bare truth i'm afraid ;)
> and now that you ask, i admit this is probably the first time i consider
> having multi server support in qjackctl :)
> ah, maybe in a near future, when the current legacy design ashes get
> buried and a new one raises from the emerging jack control interface,
> which is already making strides in the jack2 svn underground, i presume :P
> rncbc aka Rui Nuno Capela
> rncbc at rncbc.org
> Linux-audio-user mailing list
> Linux-audio-user at lists.linuxaudio.org
More information about the Linux-audio-user