6 Jun
2010
6 Jun
'10
10:48 p.m.
Qjackctl has the -n option to select a Jack server name,
and recent versions also allow multiple presets.
What would it take to make the server name a element of
a preset rather than a command line option ?
That would finally allow to run multiple jacks on the
same machine (something I've been doing quite a lot
recently) without having to start each qjackctl with
a different command line option (e.g. from a desktop
menu).
And maybe the four start/stop scripts should also be
'per preset'.
While we're here: almost no apps support selecting a
specific Jack server. I've been adding this to some
of my own just because I needed it.
Using -n for this can be problematic if the toolset
used doesn't allow context-sensitive options: -n is
also used as a parameter for an ALSA interface, and
some apps support both Jack and ALSA.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
6 Jun
6 Jun
11:06 p.m.
On 06/06/2010 09:43 PM, fons(a)kokkinizita.net wrote:
Qjackctl has the -n option to select a Jack server
name,
and recent versions also allow multiple presets.
What would it take to make the server name a element of
a preset rather than a command line option ?
That would finally allow to run multiple jacks on the
same machine (something I've been doing quite a lot
recently) without having to start each qjackctl with
a different command line option (e.g. from a desktop
menu).
And maybe the four start/stop scripts should also be
'per preset'.
While we're here: almost no apps support selecting a
specific Jack server. I've been adding this to some
of my own just because I needed it.
Using -n for this can be problematic if the toolset
used doesn't allow context-sensitive options: -n is
also used as a parameter for an ALSA interface, and
some apps support both Jack and ALSA.
JACK_DEFAULT_SERVER environment variable might be your (only) friend here :)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
11:21 p.m.
On Sun, Jun 06, 2010 at 10:12:45PM +0100, Rui Nuno Capela wrote:
On 06/06/2010 09:43 PM, fons(a)kokkinizita.net wrote:
I know. Either that or for qjackctl, -n. But both require
the choice to be made when the app (in casu qjackctl) is
launched, while everything else, including the soundcard
to be used, can be selected later or as part of a preset.
Both JACK_DEFAULT_SERVER or -n also integrate badly with
desktop menus or icons used to start a qjackctl instance.
If the soundcard used is part of a preset, the server
should be as well. Just give it a sensible default, so
'almost all' users will never have to modify it.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
Qjackctl has the -n option to select a Jack
server name,
and recent versions also allow multiple presets.
What would it take to make the server name a element of
a preset rather than a command line option ?
That would finally allow to run multiple jacks on the
same machine (something I've been doing quite a lot
recently) without having to start each qjackctl with
a different command line option (e.g. from a desktop
menu).
And maybe the four start/stop scripts should also be
'per preset'.
While we're here: almost no apps support selecting a
specific Jack server. I've been adding this to some
of my own just because I needed it.
Using -n for this can be problematic if the toolset
used doesn't allow context-sensitive options: -n is
also used as a parameter for an ALSA interface, and
some apps support both Jack and ALSA.
JACK_DEFAULT_SERVER environment variable might be your (only) friend here :)
11:47 p.m.
On 06/06/2010 10:16 PM, fons(a)kokkinizita.net wrote:
On Sun, Jun 06, 2010 at 10:12:45PM +0100, Rui Nuno
Capela wrote:
yep. i'm first to reckon qjackctl was not made/designed for the
multi-jack-server scenario and the previously suggested hack are, yes,
just a hack.
but, as to let any of those client apps connect to the right jack server
(-n), you probably need to lauch them in the right context, ah, unless i
miss the point so badly, that means a precise JACK_DEFAULT_SERVER
contextual (aka shell) setting anyhow
:/
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On 06/06/2010 09:43 PM, fons(a)kokkinizita.net
wrote:
I know. Either that or for qjackctl, -n. But both require
the choice to be made when the app (in casu qjackctl) is
launched, while everything else, including the soundcard
to be used, can be selected later or as part of a preset.
Both JACK_DEFAULT_SERVER or -n also integrate badly with
desktop menus or icons used to start a qjackctl instance.
If the soundcard used is part of a preset, the server
should be as well. Just give it a sensible default, so
'almost all' users will never have to modify it.
Qjackctl has the -n option to select a Jack
server name,
and recent versions also allow multiple presets.
What would it take to make the server name a element of
a preset rather than a command line option ?
That would finally allow to run multiple jacks on the
same machine (something I've been doing quite a lot
recently) without having to start each qjackctl with
a different command line option (e.g. from a desktop
menu).
And maybe the four start/stop scripts should also be
'per preset'.
While we're here: almost no apps support selecting a
specific Jack server. I've been adding this to some
of my own just because I needed it.
Using -n for this can be problematic if the toolset
used doesn't allow context-sensitive options: -n is
also used as a parameter for an ALSA interface, and
some apps support both Jack and ALSA.
JACK_DEFAULT_SERVER environment variable might be your (only) friend here :) 
7 Jun
7 Jun
2:18 p.m.
On Sunday 06 June 2010 17:53:44 Rui Nuno Capela wrote:
On 06/06/2010 10:16 PM, fons(a)kokkinizita.net wrote:
Hold on a second. Let me try walking through this.
We start qjackctl. Does it connect to a jack server at this point? If so,
always or only if jack is currently running.
In cases where it might connect on startup, must it?
Let's say no jack is running and we start qjackctl.
Let's say it doesn't connect to jack at this point.
Could there not be a setup option to indicate what -n indicated now?
Let's say multiple jacks are running and we start qjackctl.
Is it possible to discover that multiple jacks are running?
If so, would it be possible to allow a choice from within the gui as to which
one to connect to?
(I am asking these questions from a position of deep ignorance but having
followed this discussion some and trying to help with any misunderstanding.)
all the best,
drew
On Sun, Jun 06, 2010 at 10:12:45PM +0100, Rui
Nuno Capela wrote:
yep. i'm first to reckon qjackctl was not made/designed for the
multi-jack-server scenario and the previously suggested hack are, yes,
just a hack.
but, as to let any of those client apps connect to the right jack server
(-n), you probably need to lauch them in the right context, ah, unless i
miss the point so badly, that means a precise JACK_DEFAULT_SERVER
contextual (aka shell) setting anyhow
:/ On 06/06/2010 09:43 PM, fons(a)kokkinizita.net
wrote:
I know. Either that or for qjackctl, -n. But both require
the choice to be made when the app (in casu qjackctl) is
launched, while everything else, including the soundcard
to be used, can be selected later or as part of a preset.
Both JACK_DEFAULT_SERVER or -n also integrate badly with
desktop menus or icons used to start a qjackctl instance.
If the soundcard used is part of a preset, the server
should be as well. Just give it a sensible default, so
'almost all' users will never have to modify it. Qjackctl has the -n option to select a Jack
server name,
and recent versions also allow multiple presets.
What would it take to make the server name a element of
a preset rather than a command line option ?
That would finally allow to run multiple jacks on the
same machine (something I've been doing quite a lot
recently) without having to start each qjackctl with
a different command line option (e.g. from a desktop
menu).
And maybe the four start/stop scripts should also be
'per preset'.
While we're here: almost no apps support selecting a
specific Jack server. I've been adding this to some
of my own just because I needed it.
Using -n for this can be problematic if the toolset
used doesn't allow context-sensitive options: -n is
also used as a parameter for an ALSA interface, and
some apps support both Jack and ALSA.
JACK_DEFAULT_SERVER environment variable might be your (only) friend
here :)
2:59 p.m.
On Mon, 7 Jun 2010 08:18:23 -0400, drew Roberts <zotz(a)100jamz.com> wrote:
>>> JACK_DEFAULT_SERVER environment variable
might be your (only) friend
>>> here :)
<snip>
Hold on a second. Let me try walking through this.
We start qjackctl. Does it connect to a jack server at this point? If
so,
always or only if jack is currently running.
it connects only if jackd is currently running.
In cases where it might connect on startup, must it?
no. again it only connects automatically iif a (default) server is found
responsive to open qjackctl as one of its clients.
Let's say no jack is running and we start
qjackctl.
Let's say it doesn't connect to jack at this point.
i does not.
Could there not be a setup option to indicate what -n
indicated now?
qjackctl -n command line option is just convenient for you to start jackd
server with that precise server name and let qjackctl connect immediately
to it as client to that same server.
Let's say multiple jacks are running and we start
qjackctl.
Is it possible to discover that multiple jacks are running?
nope. qjackctl will only "see" the default jack server or the one named by
JACK_DEFAULT_SERVER environment variable at the time qjackctl is launched.
If so, would it be possible to allow a choice from
within the gui as to
which one to connect to?
none atm. each qjackctl instance may only attach to one server at a time.
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
4:16 p.m.
On Mon, Jun 07, 2010 at 01:59:09PM +0100, Rui Nuno Capela wrote:
qjackctl -n command line option is just convenient for
you to start jackd
server with that precise server name and let qjackctl connect immediately
to it as client to that same server.
That is the only case you need it as a command line option.
The thing that is currently rather clumsy is that if
you want to run two qjackctl and jackd, is that each
requires two separate steps that must be coordinated.
You have to 1) start qjackctl with the -n option (command
line), then 2) select the corresponding preset (GUI), and
start it. If the server name were part of each preset this
would be much simpler: start qjackctl, select a preset,
start it.
I see no good reason for not making the server name a
preset item. It is a parameter that defines a jack session
just as all preset elements do, and in case you run two
or more servers, a required one. Provide a sensible default,
as you do for the server path, and most people won't even
notice it.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
5:11 p.m.
On Mon, 7 Jun 2010 16:11:32 +0200, fons(a)kokkinizita.net wrote:
yep, that could be arranged :)
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On Mon, Jun 07, 2010 at 01:59:09PM +0100, Rui Nuno
Capela wrote:
> qjackctl -n command line option is just convenient for you to start
jackd
> server with that precise server name and let
qjackctl connect
immediately
to it as
client to that same server.
That is the only case you need it as a command line option.
The thing that is currently rather clumsy is that if
you want to run two qjackctl and jackd, is that each
requires two separate steps that must be coordinated.
You have to 1) start qjackctl with the -n option (command
line), then 2) select the corresponding preset (GUI), and
start it. If the server name were part of each preset this
would be much simpler: start qjackctl, select a preset,
start it.
I see no good reason for not making the server name a
preset item. It is a parameter that defines a jack session
just as all preset elements do, and in case you run two
or more servers, a required one. Provide a sensible default,
as you do for the server path, and most people won't even
notice it.
9 Jun
9 Jun
12:09 p.m.
On Mon, 07 Jun 2010 16:11:53 +0100, Rui Nuno Capela <rncbc(a)rncbc.org>
wrote:
and arranged it is now, svn trunk (qjackctl 0.3.6.25+):
- server name is finally part of server settings presets.
please, test && tell
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On Mon, 7 Jun 2010 16:11:32 +0200,
fons(a)kokkinizita.net wrote:
only case you need it as a command line option.
The thing that is currently rather clumsy is that if
you want to run two qjackctl and jackd, is that each
requires two separate steps that must be coordinated.
You have to 1) start qjackctl with the -n option (command
line), then 2) select the corresponding preset (GUI), and
start it. If the server name were part of each preset this
would be much simpler: start qjackctl, select a preset,
start it.
I see no good reason for not making the server name a
preset item. It is a parameter that defines a jack session
just as all preset elements do, and in case you run two
or more servers, a required one. Provide a sensible default,
as you do for the server path, and most people won't even
notice it.
yep, that could be arranged :)
15 Jun
15 Jun
5:04 p.m.
On Wed, Jun 09, 2010 at 11:09:30AM +0100, Rui Nuno Capela wrote:
and arranged it is now, svn trunk (qjackctl
0.3.6.25+):
- server name is finally part of server settings presets.
please, test && tell
It 'works' but not in a usable way. Remember that setting
the server name is really required only if you run two
servers, and in that case things fail.
* Start first qjackctl
* Select first preset (MADI, server = 'default')
* Start
-> All OK.
* Start second qjackctl.
-> It connects to the already running server, but can
be 'stopped' without affecting that server. Then
* Select second preset (USB, server = 'USB')
* Start
-> The second qjackctl ignores the selected preset and
still connects to the first server.
The same happens even if the second qjackctl is started
explicitly with -p USB. It still autoconnects to the other
one and nothing will make it change its mind.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
5:50 p.m.
On Tue, 15 Jun 2010 16:59:05 +0200, fons(a)kokkinizita.net wrote:
On Wed, Jun 09, 2010 at 11:09:30AM +0100, Rui Nuno
Capela wrote:
ok. the auto-attachment to a currently running server was botched and
overlooking the preset logic. however, if i am not mistaken, the second
qjackctl should have worked if launched with -n USB, but never mind now...
maybe fixed in qjackctl 0.3.6.27+ (today's svn trunk)
byee
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
and arranged it is now, svn trunk (qjackctl
0.3.6.25+):
- server name is finally part of server settings presets.
please, test && tell
It 'works' but not in a usable way. Remember that setting
the server name is really required only if you run two
servers, and in that case things fail.
* Start first qjackctl
* Select first preset (MADI, server = 'default')
* Start
-> All OK.
* Start second qjackctl.
-> It connects to the already running server, but can
be 'stopped' without affecting that server. Then
* Select second preset (USB, server = 'USB')
* Start
-> The second qjackctl ignores the selected preset and
still connects to the first server.
The same happens even if the second qjackctl is started
explicitly with -p USB. It still autoconnects to the other
one and nothing will make it change its mind.
5:55 p.m.
On Tue, Jun 15, 2010 at 04:50:29PM +0100, Rui Nuno Capela wrote:
ok. the auto-attachment to a currently running server
was botched and
overlooking the preset logic. however, if i am not mistaken, the second
qjackctl should have worked if launched with -n USB, but never mind now...
Probably yes, but having to do that is what we tried to remove...
maybe fixed in qjackctl 0.3.6.27+ (today's svn
trunk)
Thanks, will test later today.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
6:10 p.m.
On Tue, Jun 15, 2010 at 04:50:29PM +0100, Rui Nuno Capela wrote:
maybe fixed in qjackctl 0.3.6.27+ (today's svn
trunk)
Works nicely, many thanks !
There is still the (older but not very old) problem of
qjackctl going into and endless loop when it somehow
fails to start jackd. The only solution in that case is
to terminate it. Which can be a shooting game as windows
keep popping up, and you have to close them all before
a close on the main window is accepted.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
6:17 p.m.
On Tue, 15 Jun 2010 18:05:41 +0200
fons(a)kokkinizita.net wrote:
On Tue, Jun 15, 2010 at 04:50:29PM +0100, Rui Nuno
Capela wrote:
Hasd that own myself :(
Surely the answer is to allow it to only retry a limited number of
times.
... and even then only have one error window!
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
maybe fixed in qjackctl 0.3.6.27+ (today's
svn trunk)
Works nicely, many thanks !
There is still the (older but not very old) problem of
qjackctl going into and endless loop when it somehow
fails to start jackd. The only solution in that case is
to terminate it. Which can be a shooting game as windows
keep popping up, and you have to close them all before
a close on the main window is accepted.
Ciao,
10:22 p.m.
On 06/15/2010 05:05 PM, fons(a)kokkinizita.net wrote:
On Tue, Jun 15, 2010 at 04:50:29PM +0100, Rui Nuno
Capela wrote:
strange. it should just preset one error message box, that waits for
your action before start counting for the next retrial, or you have
system tray icon activated and their messages just pop without blocking,
but in a "normal" desktop environment they should not stack up, the one
just replaces the one before, which stays there for 3 seconds maximum.
may i see a screenshot of that "abnormal" situation ?
seeya
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
maybe fixed in qjackctl 0.3.6.27+ (today's
svn trunk)
Works nicely, many thanks !
There is still the (older but not very old) problem of
qjackctl going into and endless loop when it somehow
fails to start jackd. The only solution in that case is
to terminate it. Which can be a shooting game as windows
keep popping up, and you have to close them all before
a close on the main window is accepted.
10:43 p.m.
On Tue, Jun 15, 2010 at 09:26:16PM +0100, Rui Nuno Capela wrote:
On 06/15/2010 05:05 PM, fons(a)kokkinizita.net wrote:
The message window is opened as well.
On Tue, Jun 15, 2010 at 04:50:29PM +0100, Rui
Nuno Capela wrote:
strange. it should just preset one error message box, that waits for
your action before start counting for the next retrial, maybe fixed in qjackctl 0.3.6.27+ (today's
svn trunk)
Works nicely, many thanks !
There is still the (older but not very old) problem of
qjackctl going into and endless loop when it somehow
fails to start jackd. The only solution in that case is
to terminate it. Which can be a shooting game as windows
keep popping up, and you have to close them all before
a close on the main window is accepted.
or you have system tray icon activated and their
messages
just pop without blocking,
I don't even know what a 'system tray' is...
but in a "normal" desktop environment they
should not stack up, the one
just replaces the one before, which stays there for 3 seconds maximum.
They don't stack up, but even without that the automatic
retrial is just a big nuisance. In 99.99% of all cases it
doesn't help, it just keeps on repeating itself, and there
is no way to stop it. At least, [Retry?] should be an
option, but even that is quite useless as pressing [Start]
again is just as easy.
When starting Jackd fails, two windows pop up. My first reaction
is to click [Setup] to find out what's wrong. So now we have
three windows (plus the main one) open. Editing the setup (if
the error is there) doesn't help, and getting out of all this
is just a big mess as Qjackctl won't accept the main close
button as long as any other of its windows is open (why ?),
and they just keep coming back.
So *please* remove this, it's just a big nuisance and I don't
see in what situation it could ever be useful.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
11:57 p.m.
On 15 June 2010 21:37, <fons(a)kokkinizita.net> wrote:
On Tue, Jun 15, 2010 at 09:26:16PM +0100, Rui Nuno
Capela wrote:
i can confirm this is irritating. the msgs window opens up and a
pop-up from the systray pops up. i close the msgs window. a few
seconds it tries again. definitely we need a "don't retry on fail"
option, or better yet, a "retry on fail" option. and the msgs window
can't be closed when the setup window is open.
james.
On 06/15/2010 05:05 PM, fons(a)kokkinizita.net
wrote:
The message window is opened as well.
On Tue, Jun 15, 2010 at 04:50:29PM +0100, Rui
Nuno Capela wrote:
strange. it should just preset one error message box, that waits for
your action before start counting for the next retrial, maybe fixed in qjackctl 0.3.6.27+ (today's
svn trunk)
Works nicely, many thanks !
There is still the (older but not very old) problem of
qjackctl going into and endless loop when it somehow
fails to start jackd. The only solution in that case is
to terminate it. Which can be a shooting game as windows
keep popping up, and you have to close them all before
a close on the main window is accepted.
or you have system tray icon activated and their
messages
just pop without blocking,
I don't even know what a 'system tray' is...
but in a "normal" desktop environment
they should not stack up, the one
just replaces the one before, which stays there for 3 seconds maximum.
They don't stack up, but even without that the automatic
retrial is just a big nuisance. In 99.99% of all cases it
doesn't help, it just keeps on repeating itself, and there
is no way to stop it. At least, [Retry?] should be an
option, but even that is quite useless as pressing [Start]
again is just as easy.
When starting Jackd fails, two windows pop up. My first reaction
is to click [Setup] to find out what's wrong. So now we have
three windows (plus the main one) open. Editing the setup (if
the error is there) doesn't help, and getting out of all this
is just a big mess as Qjackctl won't accept the main close
button as long as any other of its windows is open (why ?),
and they just keep coming back.
So *please* remove this, it's just a big nuisance and I don't
see in what situation it could ever be useful.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
16 Jun
16 Jun
12:54 a.m.
On 06/15/2010 09:37 PM, fons(a)kokkinizita.net wrote:
On Tue, Jun 15, 2010 at 09:26:16PM +0100, Rui Nuno
Capela wrote:
ok, will make it retry just once then.
bbl
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On 06/15/2010 05:05 PM, fons(a)kokkinizita.net
wrote:
The message window is opened as well.
On Tue, Jun 15, 2010 at 04:50:29PM +0100, Rui
Nuno Capela wrote:
strange. it should just preset one error message box, that waits for
your action before start counting for the next retrial, maybe fixed in qjackctl 0.3.6.27+ (today's
svn trunk)
Works nicely, many thanks !
There is still the (older but not very old) problem of
qjackctl going into and endless loop when it somehow
fails to start jackd. The only solution in that case is
to terminate it. Which can be a shooting game as windows
keep popping up, and you have to close them all before
a close on the main window is accepted.
or you have system tray icon activated and their
messages
just pop without blocking,
I don't even know what a 'system tray' is...
but in a "normal" desktop environment
they should not stack up, the one
just replaces the one before, which stays there for 3 seconds maximum.
They don't stack up, but even without that the automatic
retrial is just a big nuisance. In 99.99% of all cases it
doesn't help, it just keeps on repeating itself, and there
is no way to stop it. At least, [Retry?] should be an
option, but even that is quite useless as pressing [Start]
again is just as easy.
When starting Jackd fails, two windows pop up. My first reaction
is to click [Setup] to find out what's wrong. So now we have
three windows (plus the main one) open. Editing the setup (if
the error is there) doesn't help, and getting out of all this
is just a big mess as Qjackctl won't accept the main close
button as long as any other of its windows is open (why ?),
and they just keep coming back.
So *please* remove this, it's just a big nuisance and I don't
see in what situation it could ever be useful.
12:58 a.m.
On Wed, 16 Jun 2010 00:00:50 +0100
Rui Nuno Capela <rncbc(a)rncbc.org> wrote:
Thanks :)
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
On 06/15/2010 09:37 PM, fons(a)kokkinizita.net wrote:
<snip>
So *please*
remove this, it's just a big nuisance and I don't
see in what situation it could ever be useful.
ok, will make it retry just once then.
bbl
10 a.m.
On Wed, Jun 16, 2010 at 12:00:50AM +0100, Rui Nuno Capela wrote:
ok, will make it retry just once then.
Having to wait for that retry to fail (it will)
is probably as irritating as it is now.
See also Fernando's message - I can confirm this 100%.
What about a [Retry] [Cancel] choise in your
error box ? Or just nothing, you can always
click [Start] again...
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
2:53 a.m.
On Tue, 2010-06-15 at 22:37 +0200, fons(a)kokkinizita.net wrote:
On Tue, Jun 15, 2010 at 09:26:16PM +0100, Rui Nuno
Capela wrote:
I have found the qjackctl automatic retry to not help at all as well.
I would really like for it to go away - is it configurable somehow?
(sorry if this was mentioned in the thread, I have only had time lately
to skim through the lists - where does time go??).
This is how it (does not) work(s) in my case (0.3.6):
- point to a non existing card on purpose so that jackd can't start
- press "Start"
- jackd does not start :-)
- qjackctl pops up a window that says:
"Error: Jack Audio Connection Kit", etc, etc.
- click on "Cancel" (the only option it shows).
- click on "Setup" to fix the problem
- qjackctl pops up the error window again before I'm done
- it has _focus_ so I can't continue working on the "Setup" panel
LABEL AGAIN:
- click on "Cancel" again
- keep working on "Setup"
- if (managed to fix problem) GOTO FIXED
LABEL WHAT?:
- pop up window shows up again (I'm old and slow)
- GOTO AGAIN
LABEL FIXED:
- if (do nothing and wait a bit) GOTO WHAT?
- give up and press "Start", jackd starts fine.
Not useful. Not even retrying once. I can't think of a situation where
jackd fails to start on the first time and will on the second try a few
seconds later.
-- Fernando
but in a "normal" desktop environment
they should not stack up, the one
just replaces the one before, which stays there for 3 seconds maximum.
They don't stack up, but even without that the automatic
retrial is just a big nuisance. In 99.99% of all cases it
doesn't help, it just keeps on repeating itself, and there
is no way to stop it. At least, [Retry?] should be an
option, but even that is quite useless as pressing [Start]
again is just as easy.
When starting Jackd fails, two windows pop up. My first reaction
is to click [Setup] to find out what's wrong. So now we have
three windows (plus the main one) open. Editing the setup (if
the error is there) doesn't help, and getting out of all this
is just a big mess as Qjackctl won't accept the main close
button as long as any other of its windows is open (why ?),
and they just keep coming back.
So *please* remove this, it's just a big nuisance and I don't
see in what situation it could ever be useful.
10:02 a.m.
On Tue, 15 Jun 2010 17:53:18 -0700, Fernando Lopez-Lezcano
<nando(a)ccrma.Stanford.EDU> wrote:
oh my,
fwiw, the retry logic is there since dawn. i can assure you it's been
there for half a decade now ;) it's there for making sure qjackctl connects
to the starting jackd server as a client of its own.
indeed, this logic is some kind of a leftover from the early days. when
machines were slower (in errors per second:) and jackd had some
considerable startup overhead before stabilizing to accept client
connections.
the delay between retrials is/was even progressive ie. each retrial takes
a bit longer then the one before, but that's now irrelevant i'm afraid ;)
the retrial code path will be scrapped asap. the only way for you to avoid
qjackctl being stalled due to a (very) slow jackd startup is now giving it
a slack via the start delay configuration setting (cf Setup/Settings/Start
Delay).
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On Tue, 2010-06-15 at 22:37 +0200,
fons(a)kokkinizita.net wrote:
> On Tue, Jun 15, 2010 at 09:26:16PM +0100, Rui Nuno Capela wrote:
> > but in a "normal" desktop environment they should not stack up, the
one
> > just replaces the one before, which stays
there for 3 seconds
maximum.
They don't stack up, but even without that the automatic
retrial is just a big nuisance. In 99.99% of all cases it
doesn't help, it just keeps on repeating itself, and there
is no way to stop it. At least, [Retry?] should be an
option, but even that is quite useless as pressing [Start]
again is just as easy.
When starting Jackd fails, two windows pop up. My first reaction
is to click [Setup] to find out what's wrong. So now we have
three windows (plus the main one) open. Editing the setup (if
the error is there) doesn't help, and getting out of all this
is just a big mess as Qjackctl won't accept the main close
button as long as any other of its windows is open (why ?),
and they just keep coming back.
So *please* remove this, it's just a big nuisance and I don't
see in what situation it could ever be useful.
I have found the qjackctl automatic retry to not help at all as well.
I would really like for it to go away - is it configurable somehow?
(sorry if this was mentioned in the thread, I have only had time lately
to skim through the lists - where does time go??).
This is how it (does not) work(s) in my case (0.3.6):
- point to a non existing card on purpose so that jackd can't start
- press "Start"
- jackd does not start :-)
- qjackctl pops up a window that says:
"Error: Jack Audio Connection Kit", etc, etc.
- click on "Cancel" (the only option it shows).
- click on "Setup" to fix the problem
- qjackctl pops up the error window again before I'm done
- it has _focus_ so I can't continue working on the "Setup" panel
LABEL AGAIN:
- click on "Cancel" again
- keep working on "Setup"
- if (managed to fix problem) GOTO FIXED
LABEL WHAT?:
- pop up window shows up again (I'm old and slow)
- GOTO AGAIN
LABEL FIXED:
- if (do nothing and wait a bit) GOTO WHAT?
- give up and press "Start", jackd starts fine.
Not useful. Not even retrying once. I can't think of a situation where
jackd fails to start on the first time and will on the second try a few
seconds later.
10:27 a.m.
On Wed, 16 Jun 2010 09:01:58 +0100, Rui Nuno Capela wrote:
fwiw, the retry logic is there since dawn. i can assure you it's been
there for half a decade now ;) it's there for making sure qjackctl
connects
to the starting jackd server as a client of its own.
indeed, this logic is some kind of a leftover from the early days. when
machines were slower (in errors per second:) and jackd had some
considerable startup overhead before stabilizing to accept client
connections.
the delay between retrials is/was even progressive ie. each retrial
takes
a bit longer then the one before, but that's now
irrelevant i'm afraid
;)
the retrial code path will be scrapped asap. the only way for you to
avoid
qjackctl being stalled due to a (very) slow jackd
startup is now giving
it
a slack via the start delay configuration setting (cf
Setup/Settings/Start
Delay).
commited to svn trunk (qjackctl 0.3.6.28+)
- Client connection retrial logic scrapped. Being a leftover
from early ages, when machines were slower and JACK server
startup times were longer... now, if it can't connect first
time as client, it will tear down the server whether it's
starting up still or not at all. (cf. Setup/Settings/Start
Delay for the rescue).
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
3:18 p.m.
On Wed, Jun 16, 2010 at 09:27:31AM +0100, Rui Nuno Capela wrote:
commited to svn trunk (qjackctl 0.3.6.28+)
- Client connection retrial logic scrapped. Being a leftover
from early ages, when machines were slower and JACK server
startup times were longer... now, if it can't connect first
time as client, it will tear down the server whether it's
starting up still or not at all. (cf. Setup/Settings/Start
Delay for the rescue).
Doesn't work as expected. Whan 'Start' fails it seems to
leave qjackctl in an unusable state. Fixing the cause of
the failed start doesn't help, the only solution seems to
be to terminate and restrart qjackctl itself.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
4:23 p.m.
On Wed, 16 Jun 2010 15:13:15 +0200, fons(a)kokkinizita.net wrote:
On Wed, Jun 16, 2010 at 09:27:31AM +0100, Rui Nuno
Capela wrote:
what you mean by "unusable" state? does it hang? crash? can't
'Start'
again? what's the cause for the start failure? are there any error
messages? does it help increasing the start delay?
please
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
commited to svn trunk (qjackctl 0.3.6.28+)
- Client connection retrial logic scrapped. Being a leftover
from early ages, when machines were slower and JACK server
startup times were longer... now, if it can't connect first
time as client, it will tear down the server whether it's
starting up still or not at all. (cf. Setup/Settings/Start
Delay for the rescue).
Doesn't work as expected. Whan 'Start' fails it seems to
leave qjackctl in an unusable state. Fixing the cause of
the failed start doesn't help, the only solution seems to
be to terminate and restrart qjackctl itself.
4:52 p.m.
On Wednesday 16 June 2010 16:23:05 Rui Nuno Capela wrote:
Assuming this is the same issue as Fons':
When I try to start JACK the second time (after resolving whatever the
problem was), JACK actually starts just fine. I can connect other
clients to it, but QjackCtl itself fails to connect to the server and
stays in the "Starting" state forever. Changing the start delay doesn't
make any difference.
Dominic
Doesn't
work as expected. Whan 'Start' fails it seems to
leave qjackctl in an unusable state. Fixing the cause of
the failed start doesn't help, the only solution seems to
be to terminate and restrart qjackctl itself.
what you mean by "unusable" state? does it hang? crash? can't
'Start'
again? what's the cause for the start failure? are there any error
messages? does it help increasing the start delay?
6:06 p.m.
On Wed, Jun 16, 2010 at 04:51:04PM +0200, Dominic Sacré wrote:
Assuming this is the same issue as Fons':
When I try to start JACK the second time (after resolving whatever the
problem was), JACK actually starts just fine. I can connect other
clients to it, but QjackCtl itself fails to connect to the server and
stays in the "Starting" state forever. Changing the start delay doesn't
make any difference.
Confirmed.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
7:34 p.m.
On 06/16/2010 05:01 PM, fons(a)kokkinizita.net wrote:
On Wed, Jun 16, 2010 at 04:51:04PM +0200, Dominic
Sacré wrote:
ok. fixed (qjackcl 0.3.6.29+)
thanks
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Assuming this is the same issue as Fons':
When I try to start JACK the second time (after resolving whatever the
problem was), JACK actually starts just fine. I can connect other
clients to it, but QjackCtl itself fails to connect to the server and
stays in the "Starting" state forever. Changing the start delay doesn't
make any difference.
Confirmed.
17 Jun
17 Jun
10:47 p.m.
On 06/16/2010 10:50 PM, fons(a)kokkinizita.net wrote:
On Wed, Jun 16, 2010 at 06:41:02PM +0100, Rui Nuno
Capela wrote:
the uber-procrastinator is committing at relativistic speeds, as always.
rui, you're awesome!
ok. fixed (qjackcl 0.3.6.29+)
Works nicely, thanks ! 
10:54 p.m.
On Thursday 17 June 2010 22:47:06 Jörn Nettingsmeier wrote:
On 06/16/2010 10:50 PM, fons(a)kokkinizita.net wrote:
So thats his trick to stay young!
On Wed, Jun 16, 2010 at 06:41:02PM +0100, Rui
Nuno Capela wrote:
the uber-procrastinator is committing at relativistic speeds, as always. ok. fixed (qjackcl 0.3.6.29+)
Works nicely, thanks !
11:37 p.m.
On 06/17/2010 09:54 PM, Arnold Krille wrote:
On Thursday 17 June 2010 22:47:06 Jörn Nettingsmeier
wrote:
am i? =)
relative speeds are inversely proportional to the size of change -- in
fact, those recent moves were just one-liners ditching :)
byee
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On 06/16/2010 10:50 PM, fons(a)kokkinizita.net
wrote:
So thats his trick to stay young!
On Wed, Jun 16, 2010 at 06:41:02PM +0100, Rui
Nuno Capela wrote:
the uber-procrastinator is committing at relativistic speeds, as always. ok. fixed (qjackcl 0.3.6.29+)
Works nicely, thanks !
16 Jun
16 Jun
10:38 a.m.
On Wed, Jun 16, 2010 at 09:01:58AM +0100, Rui Nuno Capela wrote:
fwiw, the retry logic is there since dawn. i can
assure you it's been
there for half a decade now ;) it's there for making sure qjackctl connects
to the starting jackd server as a client of its own.
If the logic was there since the start of time, are you
sure it was working ? I've been using qjackctl for ages,
and *never* noticed this auto retry before half a year
ago ro so. Nor did I ever see it mentioned on the list
before that time.
the retrial code path will be scrapped asap. the only
way for you to avoid qjackctl being stalled due to a
(very) slow jackd startup is now giving it a slack via
the start delay configuration setting (cf Setup/Settings/Start
Delay).
This seems to confuse two things:
- the delay between 1) starting the jackd process and
2) trying to connect to it (which is indeed required),
- auto retrying when things fail.
When either step fails, AFAIK qjackctl is not 'stalled'.
You can (could) just fix the problem and try start again,
no problem at all.
Anyway, if the auto retry goes away I'll be happy.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
7 Jun
7 Jun
9:24 p.m.
On 06/07/2010 02:59 PM, Rui Nuno Capela wrote:
It must be even more exclusive. I have a responsive default server
running and qjackctl does not connect to it.
Please define "responsive to open qjackctl";
It certainly responds to ardour2, mplayer, jack-rack, patchage...
On Mon, 7 Jun 2010 08:18:23 -0400, drew Roberts
<zotz(a)100jamz.com>
<snip>
..and if the interface the running jackd uses matches the one in the
currently active qjackctl setup.
qjackctl (0.3.6.22 and jackd-1.9.6) here launches a new jackd even if
jackd is running but using a different interface (eg. jackd is using
hw:1 and the activated qjackctl setup says hw:0)
I'd like qjackctl to always connect to an existing server if the
jack-server name matches (see the "two reasons for jack2" thread).
Is that possible?
Hold on a second. Let me try walking through this.
We start qjackctl. Does it connect to a jack server at this point?
If so,
always or only if jack is currently running.
it connects only if jackd is currently running. In cases where
it might connect on startup, must it?
no. again it only connects automatically iif a (default) server is
found responsive to open qjackctl as one of its clients. Let's say
no jack is running and we start qjackctl. Let's say it
doesn't connect to jack at this point.
i does not.
Could there not be a setup option to indicate
what -n indicated
now?
qjackctl -n command line option is just convenient for you to start
jackd server with that precise server name and let qjackctl connect
immediately to it as client to that same server.
Let's say multiple jacks are running and we
start qjackctl. Is it
possible to discover that multiple jacks are running?
nope. qjackctl will only "see" the default jack server or the one
named by JACK_DEFAULT_SERVER environment variable at the time
qjackctl is launched.
If so, would it be possible to allow a choice
from within the gui
as to which one to connect to?
none atm. each qjackctl instance may only attach to one server at a
time.
cheers
11:58 p.m.
On 06/07/2010 08:24 PM, Robin Gareus wrote:
On 06/07/2010 02:59 PM, Rui Nuno Capela wrote:
It must be even more exclusive. I have a responsive default server
running and qjackctl does not connect to it.
Please define "responsive to open qjackctl";
It certainly responds to ardour2, mplayer, jack-rack, patchage...
maybe i messed "responsive" by "responsible"
anyway, the said general default jack server name is literally "default".
if you start the server for instance via `jackd -n fooserver ...` then
this server in particular will be identified by "fooserver". then you
will only connect to it as a client if either your application program
calls jack_client_open("barclient", JackServerName, "fooserver") or
you
have previously set JACK_DEFAULT_SERVER=fooserver to override the
default name (which is, uh, "default").
similarly, if this `jackd -n fooserver ...` server instance is already
found running, qjackctl will connect to it iif it's launched via
`qjackctl -n fooserver` or JACK_DEFAULT_SERVER=fooserver is properly set.
nb. when qjackctl attaches on startup to an already running jack server,
it doesn't give a damn nor matter to which device preset you have
configured within qjackctl settings. look, a matching jackd server name
is found already active and most probably it has been started with some
other means than qjackctl, so devices may differ.
byee
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On Mon, 7 Jun 2010 08:18:23 -0400, drew Roberts
<zotz(a)100jamz.com>
<snip>
In cases
where it might connect on startup, must it?
no. again it only connects automatically iif a (default) server is
found responsive to open qjackctl as one of its clients.
8 Jun
8 Jun
12:20 a.m.
On 06/08/2010 12:04 AM, Rui Nuno Capela wrote:
On 06/07/2010 08:24 PM, Robin Gareus wrote:
this is getting a bit OT here, but..
in my case it does not; qjackctl is already running and started jackd in
the first place, it disconnected from that jackd when changing the
driver-backend.
Then I press "start" in qjackctl again and it launches a new server
instead of re-connecting. The server-name has not changed (it's still
'default').
Reproduce:
use qjackctl to start a jackdmp on alsa hw:0
# jack_control dps device hw:1
# jack_control sm
qjackctl disconnects
Press start in qjackctl -> it launches a 2nd jackd (on hw:0).
What works is to disconnect qjackctl (but keep jackd running) before
calling jack_control. Switch the Qjackctl Preset to match the hw:1
and "press start" in qjackctl after the `jack_control sm`.
Hence the patch I sent you earlier to that makes qjackctl
react on DBUS org.rncbc.qjackctl.loadpreset int32:<preset>
robin
On 06/07/2010 02:59 PM, Rui Nuno Capela wrote:
It must be even more exclusive. I have a responsive default server
running and qjackctl does not connect to it.
Please define "responsive to open qjackctl";
It certainly responds to ardour2, mplayer, jack-rack, patchage...
maybe i messed "responsive" by "responsible"
anyway, the said general default jack server name is literally "default".
if you start the server for instance via `jackd -n fooserver ...` then
this server in particular will be identified by "fooserver". then you
will only connect to it as a client if either your application program
calls jack_client_open("barclient", JackServerName, "fooserver") or
you
have previously set JACK_DEFAULT_SERVER=fooserver to override the
default name (which is, uh, "default").
similarly, if this `jackd -n fooserver ...` server instance is already
found running, qjackctl will connect to it iif it's launched via
`qjackctl -n fooserver` or JACK_DEFAULT_SERVER=fooserver is properly set.
nb. when qjackctl attaches on startup to an already running jack server,
it doesn't give a damn nor matter to which device preset you have
configured within qjackctl settings. look, a matching jackd server name
is found already active and most probably it has been started with some
other means than qjackctl, so devices may differ.
On Mon, 7 Jun 2010 08:18:23 -0400, drew Roberts
<zotz(a)100jamz.com>
<snip>
In cases
where it might connect on startup, must it?
no. again it only connects automatically iif a (default) server is
found responsive to open qjackctl as one of its clients.
5326
days inactive
5337
days old
linux-audio-dev@lists.linuxaudio.org
35 comments
10 participants
participants (10)
-
Arnold Krille -
Dominic Sacré -
drew Roberts -
Fernando Lopez-Lezcano -
Folderol -
fons＠kokkinizita.net -
James Morris -
Jörn Nettingsmeier -
Robin Gareus -
Rui Nuno Capela