16 May
2009
16 May
'09
8:40 p.m.
To whom it may concern: (again)
Jackdmp 1.9.2, Qjackctl 0.3.4
I do the following:
- Log in.
- Start a jack app.
- The app starts jackd, but using the wrong card,
and things don't work as expected.
Questions:
1. Which parameters are used for such an autostart ?
Certainly not the ones in ~/.jackdrc, these would
have been correct.
2. Qjackctl also ignores ~/.jackdrc, so what is the
purpose of this file ?
- I terminate the app. Check with ps, there is no
more jackd running.
- I start qjackctl. It immediately shows a running
jackd, but his has restarted the previous wrong one.
- Click Stop, Start in qjackctl. Get the same wrong
jackd again.
- Verify qjackctl's Setup window. This shows the
settings for the right jackd, while it is running
another one.
This is *madness*
One more: you can't terminate qjackctl without
terminating jackd as well. Why not ? Killing
qjackctl does the right thing.
A request to the jackdmp and qjackctl devs:
PLEASE REMOVE THAT DBUS MADNESS
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
17 May
17 May
5:36 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
To whom it may concern: (again)
Jackdmp 1.9.2, Qjackctl 0.3.4
I do the following:
- Log in.
- Start a jack app.
- The app starts jackd, but using the wrong card,
and things don't work as expected.
Questions:
1. Which parameters are used for such an autostart ?
Certainly not the ones in ~/.jackdrc, these would
have been correct.
2. Qjackctl also ignores ~/.jackdrc, so what is the
purpose of this file ?
- I terminate the app. Check with ps, there is no
more jackd running.
- I start qjackctl. It immediately shows a running
jackd, but his has restarted the previous wrong one.
- Click Stop, Start in qjackctl. Get the same wrong
jackd again.
- Verify qjackctl's Setup window. This shows the
settings for the right jackd, while it is running
another one.
This is *madness*
One more: you can't terminate qjackctl without
terminating jackd as well. Why not ? Killing
qjackctl does the right thing.
A request to the jackdmp and qjackctl devs:
PLEASE REMOVE THAT DBUS MADNESS
Ciao,
Fons,
I really appreciate your feedback..., but AFAICS Qjackctl is
*absolutely* not using the DBUS layer!
With jackdmp/jack2 compiled with default settings (that is *not*
using the --dbus at configure step), then it should absolutely behave
as jack1 was behaving.
And I guess Rui can better answer the points concerning "~/.jackdrc,"
and son on.
Stéphane
7:06 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, May 17, 2009 at 09:36:12AM +0200, Stéphane Letz wrote:
I really appreciate your feedback..., but AFAICS
Qjackctl is *absolutely*
not using the DBUS layer!
Then please tell what this is: (ps -ef output)
fons 2444 1 0 10:43 ? 00:00:00 /usr/bin/jackdbus auto
Killing this makes qjackctl behave normally again,
and allows me to start the server configured in it
Setup window instead of getting a different one.
And I guess Rui can better answer the points
concerning "~/.jackdrc," and
son on.
Qjackctl is not involved in autostarting jackd, so I
repeat the first question:
Which parameters are used for such an autostart ?
Certainly not the ones in ~/.jackdrc, these would
have been correct.
Given the usual convention of "APPNAME" using
"~/APPNAMErc" for default settings, why does jackd
not do this ? I know the file is created by qjackctl,
but qjackctl completely ignores the settings there,
so the file is cleary not meant for its own use.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
7:18 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
Le 17 mai 09 à 10:57, Fons Adriaensen a écrit :
On Sun, May 17, 2009 at 09:36:12AM +0200, Stéphane
Letz wrote:
If you compile jack2 *without* dbus support (that is the *default*
compilation setting) then this should never happen.
./waf configure
./waf build
sudo ./waf install
Stephane
I really appreciate your feedback..., but AFAICS
Qjackctl is
*absolutely*
not using the DBUS layer!
Then please tell what this is: (ps -ef output)
fons 2444 1 0 10:43 ? 00:00:00 /usr/bin/jackdbus auto
Killing this makes qjackctl behave normally again,
and allows me to start the server configured in it
Setup window instead of getting a different one.
> 
18 May
18 May
6:11 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
Fons Adriaensen <fons(a)kokkinizita.net> writes:
On Sun, May 17, 2009 at 09:36:12AM +0200, Stéphane
Letz wrote:
Presence of jackbus process does not mean that jack server is
started. It means that jack server may or may not be started. jackdbus
service is there to allow in future creation of multiple jack servers.
the easiest way to check whether jack server is started by jackdbus
service is:
jack_control status
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
I really appreciate your feedback..., but AFAICS
Qjackctl is *absolutely*
not using the DBUS layer!
Then please tell what this is: (ps -ef output)
fons 2444 1 0 10:43 ? 00:00:00 /usr/bin/jackdbus auto
Killing this makes qjackctl behave normally again,
and allows me to start the server configured in it
Setup window instead of getting a different one. 
7:23 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
So again, i'll ask the question.
Will we continue to have a Jack version minus the dbus infrastructure,
once jack2 is released?
Or are we destined to be dragged into a "compulsory" hybrid?
I share Fon's concerns, and still don't understand why the dbus/pulse
momentum is taking precedence over what has been up to now, a great
audio solution for any user who wants to write and create music.
I'm not a coder, but i'll ask the jack team, who i have a lot of
respect for, to take a step back and have another look at the bigger
picture again. Dbus may be a way into a partnership with Pulse, but
that implies a degree of compulsory requirement for the user.
And i don't think answering with "So don't use it" is an answer if
there's a question over the persistence of Dbus and Pulse overriding
the users intent.
Fon's description of "Big Brother" seems more applicable, and less
humorous, the more one thinks about this.
Alex.
p.s. I'm practical about software, so the Dbus "mantra" means nothing to
me.
On Mon, May 18, 2009 at 12:10 PM, Nedko Arnaudov <nedko(a)arnaudov.name> wrote:
Fons Adriaensen <fons(a)kokkinizita.net> writes:
--
Parchment Studios (It started as a joke...)
On Sun, May 17, 2009 at 09:36:12AM +0200,
Stéphane Letz wrote:
Presence of jackbus process does not mean that jack server is
started. It means that jack server may or may not be started. jackdbus
service is there to allow in future creation of multiple jack servers.
the easiest way to check whether jack server is started by jackdbus
service is:
jack_control status
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
I really appreciate your feedback..., but AFAICS
Qjackctl is *absolutely*
not using the DBUS layer!
Then please tell what this is: (ps -ef output)
fons 2444 1 0 10:43 ? 00:00:00 /usr/bin/jackdbus auto
Killing this makes qjackctl behave normally again,
and allows me to start the server configured in it
Setup window instead of getting a different one. 
7:48 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Mon, May 18, 2009 at 01:23:20PM +0400, alex stone wrote:
Will we continue to have a Jack version minus the dbus
infrastructure,
once jack2 is released?
As an uninvolved observer I am wondering why the dbus control interface,
if it is indeed only one of many potential interfaces using the c/c++
API, is not packaged separately as an optional add-on. If it is indeed a
compile time option, the design is flawed IMHO. Generally, the new
control API sounds like a good idea but why can't the new features be
exposed as new command line tools without dbus dependency per default?
So you want the dbus interface? Fine, just install jack-control-dbus or
whatever.
Or am I not getting it?
Jan
7:57 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
Jan Weil <jan.weil(a)web.de> writes:
On Mon, May 18, 2009 at 01:23:20PM +0400, alex stone
wrote:
You are getting it but obviously the one who has put those packages in
the "respected" repository is not getting it. I've packaged jack2 in the
way you've mentioned. Of course those are for specific distro (ubuntu)
and not real packages but draft packages that i've made to simplify
work of real packagers when they take the maintainership.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Will we continue to have a Jack version minus the
dbus infrastructure,
once jack2 is released?
As an uninvolved observer I am wondering why the dbus control interface,
if it is indeed only one of many potential interfaces using the c/c++
API, is not packaged separately as an optional add-on. If it is indeed a
compile time option, the design is flawed IMHO. Generally, the new
control API sounds like a good idea but why can't the new features be
exposed as new command line tools without dbus dependency per default?
So you want the dbus interface? Fine, just install jack-control-dbus or
whatever.
Or am I not getting it? 
10:07 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Monday 18 May 2009 05:49:01 Jan Weil wrote:
If it is indeed a
compile time option, the design is flawed IMHO. Generally, the new
control API sounds like a good idea but why can't the new features be
exposed as new command line tools without dbus dependency per default?
So you want the dbus interface? Fine, just install jack-control-dbus or
whatever.
Or am I not getting it?
Jan
I have asked similar questions with pretty much the same intent re the compile
time issue twice now and don't recall seeing a response to either.
Also, I have not seen anyone who is "championing" the dbus / pulse side of
things explain what is happening to Fons. It almost seems like they are
telling him he can't be seeing what he is reporting.
So, dbus guys, how is it that dbus is (re)starting on qjackctl launch? (Fons,
isn't that what you are saying?) And why is it starting a jackd with
different parameters that are in the rc file and in the qjackctl setup
config?
How does dbus know what parameters to start jack with? Where is that
configured? (Perhaps this will solve the issue, I don't recall this
information passing before my eyes in this thread so far.)
all the best,
drew
10:14 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
drew Roberts <zotz(a)100jamz.com> writes:
How does dbus know what parameters to start jack with?
Where is that
configured? (Perhaps this will solve the issue, I don't recall this
information passing before my eyes in this thread so far.)
jackbus reads the configuration file and then start jack server through
the control API. The configuration file is stored in
~/.config/jack/conf.xml (location conforming to the XDG Base Directory
Specification).
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
11:45 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Mon, May 18, 2009 at 03:14:08PM +0300, Nedko Arnaudov wrote:
The configuration file is stored in
~/.config/jack/conf.xml
(location conforming to the XDG Base Directory Specification).
Frankly I don't give a damn for that spec, or in fact
anything from that self-styled group of ******* who have
apparently never in their lives seen a computer without
a running desktop, have no idea of how things are done
on a Unix-like system, are the source of all misery I've
been confronted with lately, and are slowly turning Linux
into something worse than Windows (I mean freedesktop.org).
To start with, jackd is not a desktop app, and Unix/Linux
apps are traditionally configured using an ~/***rc file.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
12:36 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
Fons Adriaensen <fons(a)kokkinizita.net> writes:
On Mon, May 18, 2009 at 03:14:08PM +0300, Nedko
Arnaudov wrote:
To be honest I dont care about the location of the file. It is fine with
me and I'm not going to advocate XDG, it is a fight between you and
them.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
The configuration file is stored in
~/.config/jack/conf.xml
(location conforming to the XDG Base Directory Specification).
Frankly I don't give a damn for that spec, or in fact
anything from that self-styled group of ******* who have
apparently never in their lives seen a computer without
a running desktop, have no idea of how things are done
on a Unix-like system, are the source of all misery I've
been confronted with lately, and are slowly turning Linux
into something worse than Windows (I mean freedesktop.org).
To start with, jackd is not a desktop app, and Unix/Linux
apps are traditionally configured using an ~/***rc file.
7:52 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
alex stone <compose59(a)gmail.com> writes:
So again, i'll ask the question.
Will we continue to have a Jack version minus the dbus infrastructure,
once jack2 is released?
Or are we destined to be dragged into a "compulsory" hybrid?
I share Fon's concerns, and still don't understand why the dbus/pulse
momentum is taking precedence over what has been up to now, a great
audio solution for any user who wants to write and create music.
I'm not a coder, but i'll ask the jack team, who i have a lot of
respect for, to take a step back and have another look at the bigger
picture again. Dbus may be a way into a partnership with Pulse, but
that implies a degree of compulsory requirement for the user.
And i don't think answering with "So don't use it" is an answer if
there's a question over the persistence of Dbus and Pulse overriding
the users intent.
Fon's description of "Big Brother" seems more applicable, and less
humorous, the more one thinks about this.
Alex.
p.s. I'm practical about software, so the Dbus "mantra" means nothing to
me.
There are three packaging scenarios described in
http://trac.jackaudio.org/wiki/JackDbusPackaging
This document is created packagers can choose how to package jack. The
mixed setup is can easily lead to user frustration and this is
explained. I personally use the mixed setup but i know how the whole
mixed system behaves and I need to start jackd occasionally. I wouldn't
recommend packaging mixed setup. In ubuntu packages I've created
jackdbus is separate package. jackd is separate package too. They both
implement jack server virtual package. Packagers must choose between
classic jackd or dbus-only scenarios unless they want to cause pain to
their users.
Some more things I've implemented in the ubuntu packaging...
Only dbus control apps depend on jackdbus package. qjackctl depends on
jackd package. So if you install qjackctl but dont want (or dont know
about) jackdbus you get no dbus. If you install lpatchage or laditools
you get dbus setup. Users don't care about jackd vs jackdbus. They care
about the frontends. If they are used to qjackctl+jackd they will use
that and will get no "dbus ate my babies" feeling. If they like ladi
control apps, they will not use jackd.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
17 May
17 May
8:51 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
Stéphane Letz wrote:
qjackctl only writes to ~/.jackdrc *iif* you opt to (see Setup/Misc/Save
JACK audio server configuration). otherwise it *never* makes use of that
file ie. it never auto-starts jackd implicitly; it only does start jackd
explicitly if none is found running atm.
if you really want several jackd server running simultaneously you'll
have to take use of the JACK_DEFAULT_SERVER environment variable to tell
qjackctl which server it will refer to. in fact, that is the only tricky
way for you to have several qjackctl instances running as well.
Stephane is right, qjackctl makes no use of the d-bus interface in
jackaudio.org domain, although the latest in qjackctl cvs has some d-bus
stuff of its own (rncbc.org domain) and only serves for
starting/stopping qjackctl control--found useful for example to any
system suspend/resume script you may think of.
otoh, the only other jack application i know of that writes to
~/.jackdrc is ardour; have a look at your use case when starting jackd
from behind ardour's open session dialog...
cheera
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
To whom it may
concern: (again)
Jackdmp 1.9.2, Qjackctl 0.3.4
I do the following:
- Log in.
- Start a jack app.
- The app starts jackd, but using the wrong card,
and things don't work as expected.
Questions:
1. Which parameters are used for such an autostart ?
Certainly not the ones in ~/.jackdrc, these would
have been correct.
2. Qjackctl also ignores ~/.jackdrc, so what is the
purpose of this file ?
- I terminate the app. Check with ps, there is no
more jackd running.
- I start qjackctl. It immediately shows a running
jackd, but his has restarted the previous wrong one.
- Click Stop, Start in qjackctl. Get the same wrong
jackd again.
- Verify qjackctl's Setup window. This shows the
settings for the right jackd, while it is running
another one.
This is *madness*
One more: you can't terminate qjackctl without
terminating jackd as well. Why not ? Killing
qjackctl does the right thing.
A request to the jackdmp and qjackctl devs:
PLEASE REMOVE THAT DBUS MADNESS
Ciao,
Fons,
I really appreciate your feedback..., but AFAICS Qjackctl is
*absolutely* not using the DBUS layer!
With jackdmp/jack2 compiled with default settings (that is *not* using
the --dbus at configure step), then it should absolutely behave as jack1
was behaving.
And I guess Rui can better answer the points concerning "~/.jackdrc,"
and son on.
9:39 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, May 17, 2009 at 11:48:57AM +0100, Rui Nuno Capela wrote:
qjackctl only writes to ~/.jackdrc *iif* you opt to
(see Setup/Misc/Save
JACK audio server configuration). otherwise it *never* makes use of that
file ie. it never auto-starts jackd implicitly; it only does start jackd
explicitly if none is found running atm.
If the file is ignored by jackd, and by qjackctl, why
does qjackctl write it at all ?
if you really want several jackd server running
simultaneously
I don't want that. I want to get rid of one that was
started automatically, terminated, but restarted by
dbus (why on earth ?) when I run qjackctl. The net
result is that running qjackctl starts a server with
parameters that have no relation at all to its setup
(making it appear as if qjackctl has gone nuts), and
starting the one corresponding to qjackctl's setup
becomes impossible. It's very probably not qjackctl's
fault.
Two other things _are_:
1. I definitely want to be able to terminate qjackctl
without stopping jackd, even if that jackd was started
by qjackctl. This used to be possible.
2. Qjackctl-0.3.4 seems to have a bug handling the port
creation and destruction callbacks, it continues to show
ports that have been deleted and does not show some new
ones. This happens when the delete/create calls are close
together. Jack_evmon shows the right events in the right
order, so it must be qjackctl getting it wrong.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
11:10 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
Fons Adriaensen wrote:
On Sun, May 17, 2009 at 11:48:57AM +0100, Rui Nuno
Capela wrote:
unfortunately, Qt4's class which is being used for wrapping the jackd
process (QProcess) does kill it on its destructor. afaict, this behavior
wasn't present in Qt3 and that's why there's no option to keep jackd
running upon quitting qjackctl anymore.
qjackctl only writes to ~/.jackdrc *iif* you opt
to (see Setup/Misc/Save
JACK audio server configuration). otherwise it *never* makes use of that
file ie. it never auto-starts jackd implicitly; it only does start jackd
explicitly if none is found running atm.
If the file is ignored by jackd, and by qjackctl, why
does qjackctl write it at all ?
if you really want several jackd server running
simultaneously
I don't want that. I want to get rid of one that was
started automatically, terminated, but restarted by
dbus (why on earth ?) when I run qjackctl. The net
result is that running qjackctl starts a server with
parameters that have no relation at all to its setup
(making it appear as if qjackctl has gone nuts), and
starting the one corresponding to qjackctl's setup
becomes impossible. It's very probably not qjackctl's
fault.
Two other things _are_:
1. I definitely want to be able to terminate qjackctl
without stopping jackd, even if that jackd was started
by qjackctl. This used to be possible.
2. Qjackctl-0.3.4 seems to have a bug handling the
port
creation and destruction callbacks, it continues to show
ports that have been deleted and does not show some new
ones. This happens when the delete/create calls are close
together. Jack_evmon shows the right events in the right
order, so it must be qjackctl getting it wrong.
this might just be a side-effect of the jack_port_t* reuse issue that i
think has been discussed recently.
qjackctl does not handle port (un)registration callbacks but does its
book-keeping with this jack_port_t * handle as a unique key identifier.
if, for instance, one client unregisters one given port and registers
another in a quick sequence, it might just happen that the new port has
the very same jack_port_t* address value which got just reclaimed and
reused. alas, qjackctl assumes it's the very same port object as it
keeps jack_port_t*s as its unique port identifiers, so nothing changes.
i suppose i'll have to fix this soon. by properly handling port
unregistration callbacks, which will be a novelty after 5+ years of
doing just fine without on jack1 at least ;)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
11:22 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, May 17, 2009 8:07 am, Rui Nuno Capela wrote:
unfortunately, Qt4's class which is being used for
wrapping the jackd
process (QProcess) does kill it on its destructor. afaict, this behavior
wasn't present in Qt3 and that's why there's no option to keep jackd
running upon quitting qjackctl anymore.
Why not use QProcess::startDetached() ?
--
G a b r i e l M B e d d i n g f i e l d
2:04 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
Gabriel M. Beddingfield wrote:
On Sun, May 17, 2009 8:07 am, Rui Nuno Capela wrote:
simply because QProcess::startDetached() sets the process loose of
qjackctl control and all the IPC and inter-process sync facilities and
notification signal/slots will be useless or no-ops in that way--you'd
better start jackd from the command line if you take that route ;)
seeya
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
unfortunately, Qt4's class which is being
used for wrapping the jackd
process (QProcess) does kill it on its destructor. afaict, this behavior
wasn't present in Qt3 and that's why there's no option to keep jackd
running upon quitting qjackctl anymore.
Why not use QProcess::startDetached() ?
2:43 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, 17 May 2009, Rui Nuno Capela wrote:
That makes sense. Capturing stdout/stderr in QJackCtl *is* helpful. Not
sure what else is going on there.
though.
Why not use
QProcess::startDetached() ?
simply because QProcess::startDetached() sets the process loose of
qjackctl control and all the IPC and inter-process sync facilities and
notification signal/slots will be useless or no-ops in that way--you'd
better start jackd from the command line if you take that route ;)
seeya
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
2:46 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, May 17, 2009 11:43 am, Gabriel M. Beddingfield wrote:
On Sun, 17 May 2009, Rui Nuno Capela wrote:
That makes sense. Capturing stdout/stderr in QJackCtl *is* helpful. Not
sure what else is going on there.
though.
^^^^^^^^^^
(Grrr... e-mail sent before it was ready)
It would be nice if were an option to start jackd detached, though.
--
G a b r i e l M B e d d i n g f i e l d
Why not
use QProcess::startDetached() ?
simply because QProcess::startDetached() sets the process loose of
qjackctl control and all the IPC and inter-process sync facilities and
notification signal/slots will be useless or no-ops in that way--you'd
better start jackd from the command line if you take that route ;)
3:13 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, May 17, 2009 at 05:04:28PM +0100, Rui Nuno Capela wrote:
simply because QProcess::startDetached() sets the
process loose of
qjackctl control and all the IPC and inter-process sync facilities and
notification signal/slots will be useless or no-ops in that way--you'd
better start jackd from the command line if you take that route ;)
So what ? It's perfectly possible to start a process and
capture its stdout and stderr. What more IPC do you need ?
Become a client and use the interfaces provided to clients.
To kill the thing remember its pid and send a signal.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
3:49 p.m.
New subject: more jack/qjackctl madness : some comments
After all these discussions on JACK2, D-Bus and Qjackctl issues, here
are some general comments:
1) JACK2 *default* compilation mode defines the same starting scheme
at JACK1 was doing. So (beside possible bugs) it is supposed to be
completely "interchangeable" with JACK1. It can be controled with
Qjackctl as usual.
2) JACK2 compiled in D-Bus is supposed to be controlled by a D-Bus
based control application... (jack_control is a simple python example
of a control application part of the package). Using JACK2 compiled
in D-Bus with Qjackctl is a "receipe for trouble", even if if can be
done in some simple use cases. (The point is that in this case the
client auto-start feature starts the "jackdbus" exe instead of
"jackd" with all of the related "settings" issues).
3) The port issue Fons told about in Qjackctl 0.3.4 seems to be a
Qjackctl bug, so has to be fixed at the right place.
I don't see right now any raisonable way to fix this mess, better
than adding even more complexity in the design... (Nedko any idea?)
Otherwise I guess the only way is to make this totally clear for
packagers : 1) is the standard way that maintains complete
compatibility with legacy applications and control applications. 2)
is the "new" way to be used with new D-Bus based control application
(patchage ??)... So it would mean 2 separated packages.
Stephane
3:57 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Sun, May 17, 2009 at 1:49 PM, Stéphane Letz <letz(a)grame.fr> wrote:
After all these discussions on JACK2, D-Bus and
Qjackctl issues, here are
some general comments:
1) JACK2 *default* compilation mode defines the same starting scheme at
JACK1 was doing. So (beside possible bugs) it is supposed to be completely
"interchangeable" with JACK1. It can be controled with Qjackctl as usual.
2) JACK2 compiled in D-Bus is supposed to be controlled by a D-Bus based
control application... (jack_control is a simple python example of a control
application part of the package). Using JACK2 compiled in D-Bus with
Qjackctl is a "receipe for trouble", even if if can be done in some simple
use cases. (The point is that in this case the client auto-start feature
starts the "jackdbus" exe instead of "jackd" with all of the related
"settings" issues).
3) The port issue Fons told about in Qjackctl 0.3.4 seems to be a Qjackctl
bug, so has to be fixed at the right place.
I don't see right now any raisonable way to fix this mess, better than
adding even more complexity in the design... (Nedko any idea?) Otherwise I
guess the only way is to make this totally clear for packagers : 1) is the
standard way that maintains complete compatibility with legacy applications
and control applications. 2) is the "new" way to be used with new D-Bus
based control application (patchage ??)... So it would mean 2 separated
packages.
this sounds like a mess. there is a control API. i believe it was
agreed that the control API could be accessed directly (from C/C++
etc), or via other systems for which translators/layers were added
(e.g. DBus). i can see no reason why anyone would want to use choose
between a JACK server that can be controlled via either DBus or the
control API but not both. what is going on?
4:05 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Le 17 mai 09 à 19:57, Paul Davis a écrit :
On Sun, May 17, 2009 at 1:49 PM, Stéphane Letz
<letz(a)grame.fr> wrote:
The point is that when compiled in D-Bus mode, libjack behaves
differently regarding the way it start the server: it does not use
the fork+exec mode anymore but call the D-Bus service to start the
server. This "simple" change is the source of all the problems we
then see.
Stephane
After all these discussions on JACK2, D-Bus and
Qjackctl issues,
here are
some general comments:
1) JACK2 *default* compilation mode defines the same starting
scheme at
JACK1 was doing. So (beside possible bugs) it is supposed to be
completely
"interchangeable" with JACK1. It can be controled with Qjackctl as
usual.
2) JACK2 compiled in D-Bus is supposed to be controlled by a D-Bus
based
control application... (jack_control is a simple python example of
a control
application part of the package). Using JACK2 compiled in D-Bus with
Qjackctl is a "receipe for trouble", even if if can be done in
some simple
use cases. (The point is that in this case the client auto-start
feature
starts the "jackdbus" exe instead of "jackd" with all of the related
"settings" issues).
3) The port issue Fons told about in Qjackctl 0.3.4 seems to be a
Qjackctl
bug, so has to be fixed at the right place.
I don't see right now any raisonable way to fix this mess, better
than
adding even more complexity in the design... (Nedko any idea?)
Otherwise I
guess the only way is to make this totally clear for packagers :
1) is the
standard way that maintains complete compatibility with legacy
applications
and control applications. 2) is the "new" way to be used with new
D-Bus
based control application (patchage ??)... So it would mean 2
separated
packages.
this sounds like a mess. there is a control API. i believe it was
agreed that the control API could be accessed directly (from C/C++
etc), or via other systems for which translators/layers were added
(e.g. DBus). i can see no reason why anyone would want to use choose
between a JACK server that can be controlled via either DBus or the
control API but not both. what is going on?
4:10 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Sun, May 17, 2009 at 2:04 PM, Stéphane Letz <letz(a)grame.fr> wrote:
The point is that when compiled in D-Bus mode, libjack behaves differently
regarding the way it start the server: it does not use the fork+exec mode
anymore but call the D-Bus service to start the server. This "simple" change
is the source of all the problems we then see.
so if i understand correctly, there is effectively a layer of
indirection. rather than a request arriving via D-Bus leading to a
normal fork-exec, it leads to D-Bus service request, which presumably
(somewhere, sometime) leads to a fork-exec of the server? is this
correct?
4:19 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Le 17 mai 09 à 20:10, Paul Davis a écrit :
On Sun, May 17, 2009 at 2:04 PM, Stéphane Letz
<letz(a)grame.fr> wrote:
"Show me the code" :
http://trac.jackaudio.org/browser/jack2/trunk/jackmp/posix/
JackPosixServerLaunch.cpp
It starts the D-Bus jackaudio service that actually starts "jackdbus"
process with it's own logic (server settings save/restore and so on...)
Hoppefully I described it right (Nedko again?)
Stephane
The point is that when compiled in D-Bus mode, libjack behaves
differently
regarding the way it start the server: it does not use the fork
+exec mode
anymore but call the D-Bus service to start the server. This
"simple" change
is the source of all the problems we then see.
so if i understand correctly, there is effectively a layer of
indirection. rather than a request arriving via D-Bus leading to a
normal fork-exec, it leads to D-Bus service request, which presumably
(somewhere, sometime) leads to a fork-exec of the server? is this
correct?
6:15 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Sunday 17 May 2009 14:04:54 Stéphane Letz wrote:
The point is that when compiled in D-Bus mode, libjack
behaves
differently regarding the way it start the server: it does not use
the fork+exec mode anymore but call the D-Bus service to start the
server. This "simple" change is the source of all the problems we
then see.
Stephane
Can someone explain why this *must* be a compile time option rather that an
option in a config file?
all the best,
drew
10:08 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Sun, May 17, 2009 at 08:04:54PM +0200, Stéphane Letz wrote:
The point is that when compiled in D-Bus mode, libjack
behaves differently
regarding the way it start the server: it does not use the fork+exec mode
anymore but call the D-Bus service to start the server. This "simple"
change is the source of all the problems we then see.
That itself is not the source of the problems.
The source is that even after the server that was started
as explained above has been terminated, D-Bus leaves a
daemon running that tries to be clever but gets it wrong.
Which effectively blocks whatever the user wants to do,
as it only allows to restart the previous server and
even restarts it before anyone has asked for it.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
7:59 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Sun, 17 May 2009 13:57:29 -0400, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
I can't tell about the c/c++ API since I'm not really using it. The issue
here is with the legacy way of doing things: controlling jack from the
command line and it's set of switches, playing with PIDs, redirecting some
output...
Legacy can't work well along control API.
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
On Sun, May 17, 2009 at 1:49 PM, Stéphane Letz
<letz(a)grame.fr> wrote:
> After all these discussions on JACK2, D-Bus and Qjackctl issues, here
are
> some general comments:
>
> 1) JACK2 *default* compilation mode defines the same starting scheme at
> JACK1 was doing. So (beside possible bugs) it is supposed to be
> completely
> "interchangeable" with JACK1. It can be controled with Qjackctl as
usual.
2) JACK2 compiled in D-Bus is supposed to be controlled by a D-Bus based
control application... (jack_control is a simple python example of a
control
application part of the package). Using JACK2 compiled in D-Bus with
Qjackctl is a "receipe for trouble", even if if can be done in some
simple
use cases. (The point is that in this case the client auto-start feature
starts the "jackdbus" exe instead of "jackd" with all of the related
"settings" issues).
3) The port issue Fons told about in Qjackctl 0.3.4 seems to be a
Qjackctl
bug, so has to be fixed at the right place.
I don't see right now any raisonable way to fix this mess, better than
adding even more complexity in the design... (Nedko any idea?) Otherwise
I
guess the only way is to make this totally clear for packagers : 1) is
the
standard way that maintains complete compatibility with legacy
applications
and control applications. 2) is the "new" way to be used with new D-Bus
based control application (patchage ??)... So it would mean 2
separated
packages.
this sounds like a mess. there is a control API. i believe it was
agreed that the control API could be accessed directly (from C/C++
etc), or via other systems for which translators/layers were added
(e.g. DBus). i can see no reason why anyone would want to use choose
between a JACK server that can be controlled via either DBus or the
control API but not both. what is going on?
18 May
18 May
6:18 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Paul Davis <paul(a)linuxaudiosystems.com> writes:
On Sun, May 17, 2009 at 1:49 PM, Stéphane Letz
<letz(a)grame.fr> wrote:
Using the "dbus ate my babies" matra is causing mess because other
people don't think so. Using dbus interface in qjackctl would fix lot of
this mess and this is the reason I asked Rui about that. Of course "dbus
ate my babies" ppl would see usage of jackdbus in qjackctl as a bad
thing.
Does qjackctl support headless and multiserver jack setups?
How headless setups work? When someone logins through ssh, does it
access jackd server that runs as same user?
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
After all these discussions on JACK2, D-Bus and
Qjackctl issues, here are
some general comments:
1) JACK2 *default* compilation mode defines the same starting scheme at
JACK1 was doing. So (beside possible bugs) it is supposed to be completely
"interchangeable" with JACK1. It can be controled with Qjackctl as usual.
2) JACK2 compiled in D-Bus is supposed to be controlled by a D-Bus based
control application... (jack_control is a simple python example of a control
application part of the package). Using JACK2 compiled in D-Bus with
Qjackctl is a "receipe for trouble", even if if can be done in some simple
use cases. (The point is that in this case the client auto-start feature
starts the "jackdbus" exe instead of "jackd" with all of the related
"settings" issues).
3) The port issue Fons told about in Qjackctl 0.3.4 seems to be a Qjackctl
bug, so has to be fixed at the right place.
I don't see right now any raisonable way to fix this mess, better than
adding even more complexity in the design... (Nedko any idea?) Otherwise I
guess the only way is to make this totally clear for packagers : 1) is the
standard way that maintains complete compatibility with legacy applications
and control applications. 2) is the "new" way to be used with new D-Bus
based control application (patchage ??)... So it would mean 2 separated
packages.
this sounds like a mess. there is a control API. i believe it was
agreed that the control API could be accessed directly (from C/C++
etc), or via other systems for which translators/layers were added
(e.g. DBus). i can see no reason why anyone would want to use choose
between a JACK server that can be controlled via either DBus or the
control API but not both. what is going on?
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
6:50 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
hi Nedko,
On Mon, May 18, 2009 09:17, Nedko Arnaudov wrote:
Using the "dbus ate my babies" matra is causing mess because other
people don't think so. Using dbus interface in qjackctl would fix lot of
this mess and this is the reason I asked Rui about that. Of course "dbus
ate my babies" ppl would see usage of jackdbus in qjackctl as a bad thing.
main trouble, imo, is that jackdbus is currently not playing fair game
with qjackctl wrt. jackd auto-start functionality.
as noted in one my other post, qjackctl always issues jack_client_open()
with *JackNoStartServer* option, which explicitly instructs on jack stack
for *never* start jackd on its call. apparently, jackdbus lacks this call
and starts jackd no matter what, giving us all the "ate my babies" mantra
;)
so it seems like just a missing piece in the jackdbus implementation re.
the jack api. it this stands true, i guess it should be easily fixed so
that future jackdbus and legacy qjackctl can still live on together for
many years to come ;)
Does qjackctl support headless and multiserver jack
setups?
How headless setups work? When someone logins through ssh, does it
access jackd server that runs as same user?
well, of course, being qjackctl a X client, you can run qjackctl on the
headless machine and render the GUI on your local X server (ie. your
headtop, desktop, laptop, whatever) via ssh -X and DISPLAY trickery. if
you add that to disparate JACK_DEFAULT_SERVER environment settings, you
can have control of multiple jackd servers, either local or even remote.
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
7:15 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
"Rui Nuno Capela" <rncbc(a)rncbc.org> writes:
Of course instead of (or together with) DISPLAY trickery one can use
DBUS_SESSION_BUS_ADDRESS and achieve the same effect. I.e. jackdbus
operation in headless mode. Moreover, one can have non-X11 mode (without
ssh X11 forwarding). The bad news is that ssh has built in support for
X11 forwarding but has no support for dbus. Looks like feature request
for openssh :D
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
hi Nedko,
On Mon, May 18, 2009 09:17, Nedko Arnaudov wrote:
libjack does not start jack server if JackNoStartServer is
specified. This behaviour is same for both jackd autolaunching and dbus
jack server starting through activation. Presense of the jackdbus
process *DOES NOT MEAN* that jack server is started. It looks like fair
game to me.
Using the "dbus ate my babies" matra is causing mess because other
people don't think so. Using dbus interface in qjackctl would fix lot of
this mess and this is the reason I asked Rui about that. Of course "dbus
ate my babies" ppl would see usage of jackdbus in qjackctl as a bad thing.
main trouble, imo, is that jackdbus is currently not playing fair game
with qjackctl wrt. jackd auto-start functionality.
as noted in one my other post, qjackctl always issues jack_client_open()
with *JackNoStartServer* option, which explicitly instructs on jack stack
for *never* start jackd on its call. apparently, jackdbus lacks this call
and starts jackd no matter what, giving us all the "ate my babies" mantra
;)
so it seems like just a missing piece in the jackdbus implementation re.
the jack api. it this stands true, i guess it should be easily fixed so
that future jackdbus and legacy qjackctl can still live on together for
many years to come ;) Does qjackctl
support headless and multiserver jack setups?
How headless setups work? When someone logins through ssh, does it
access jackd server that runs as same user?
well, of course, being qjackctl a X client, you can run qjackctl on the
headless machine and render the GUI on your local X server (ie. your
headtop, desktop, laptop, whatever) via ssh -X and DISPLAY trickery. if
you add that to disparate JACK_DEFAULT_SERVER environment settings, you
can have control of multiple jackd servers, either local or even remote.
11:37 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Mon, May 18, 2009 at 12:15:10PM +0300, Nedko Arnaudov wrote:
libjack does not start jack server if
JackNoStartServer is
specified. This behaviour is same for both jackd autolaunching and dbus
jack server starting through activation. Presense of the jackdbus
process *DOES NOT MEAN* that jack server is started. It looks like fair
game to me.
This is definitely *not* true. Presence of the 'jackdbus auto'
daemon results in a jackd starting whenever qjackctl is
started, and the author of that app has already reported
that qjackctl explicitly requests no autostart when trying
to become a jack client.
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
12:13 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Fons Adriaensen <fons(a)kokkinizita.net> writes:
On Mon, May 18, 2009 at 12:15:10PM +0300, Nedko
Arnaudov wrote:
Fons I think we can both read C code, right?
From posix/JackPosixServerLaunch.cpp, line 166:
static int start_server(const char* server_name, jack_options_t options)
{
if ((options & JackNoStartServer) || getenv("JACK_NO_START_SERVER")) {
return 1;
}
#if defined(JACK_DBUS)
return start_server_dbus(server_name);
#else
....
jackd fork/exec stuff
....
presence of process with "jackdbus auto' commandline those not mean that
*server* is started. This is the dbus service, not the jack server
running.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
libjack does not start jack server if
JackNoStartServer is
specified. This behaviour is same for both jackd autolaunching and dbus
jack server starting through activation. Presense of the jackdbus
process *DOES NOT MEAN* that jack server is started. It looks like fair
game to me.
This is definitely *not* true. Presence of the 'jackdbus auto'
daemon results in a jackd starting whenever qjackctl is
started, and the author of that app has already reported
that qjackctl explicitly requests no autostart when trying
to become a jack client.
12:45 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Mon, May 18, 2009 at 05:13:19PM +0300, Nedko Arnaudov wrote:
Fons I think we can both read C code, right?
From posix/JackPosixServerLaunch.cpp, line 166:
static int start_server(const char* server_name, jack_options_t options)
{
if ((options & JackNoStartServer) || getenv("JACK_NO_START_SERVER")) {
return 1;
}
#if defined(JACK_DBUS)
return start_server_dbus(server_name);
#else
....
jackd fork/exec stuff
....
I can read this and it can mean different things.
- This code is not involved in what happens
- The value of the options argument is wrong.
presence of process with "jackdbus auto'
commandline those not mean that
*server* is started. This is the dbus service, not the jack server
running.
I know that. The fact remains that when the 'jackdus auto'
daemon is running a jackd is started whenever qjackctl is
started. You can go on to deny this, but that doesn't
change the facts.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
1:09 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Fons Adriaensen <fons(a)kokkinizita.net> writes:
So you complain about qjackctl missing support for jackdbus? Having that
will be nice :)
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
On Mon, May 18, 2009 at 05:13:19PM +0300, Nedko
Arnaudov wrote:
It is involved in what happenes. At least from what I've got about the
problem you have.
You have installed jack package that does not work well with
qjackctl (dbus enabled one). Your application autostarted jack server
through dbus. But you havent configured it. QJackCtl is dbus
ignorant. You should not use qjackctl with jackdbus system. Unless you
know what you are doing. Or unless qjackctl gets jackdbus support.
jackdrc style commandline options for jackd are for jackd. They are not
used for jackdbus. They cant be used for jackdbus. Because of the object
activation works in all distributed object systems I know. This includes
DCOM and D-Bus.
Fons I think we can both read C code, right?
From posix/JackPosixServerLaunch.cpp, line 166:
static int start_server(const char* server_name, jack_options_t options)
{
if ((options & JackNoStartServer) || getenv("JACK_NO_START_SERVER")) {
return 1;
}
#if defined(JACK_DBUS)
return start_server_dbus(server_name);
#else
....
jackd fork/exec stuff
....
I can read this and it can mean different things.
- This code is not involved in what happens
- The value of the options argument is wrong. presence of
process with "jackdbus auto' commandline those not mean that
*server* is started. This is the dbus service, not the jack server
running.
I know that. The fact remains that when the 'jackdus auto'
daemon is running a jackd is started whenever qjackctl is
started. You can go on to deny this, but that doesn't
change the facts.
1:41 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Mon, May 18, 2009 at 06:08:33PM +0300, Nedko Arnaudov wrote:
You have installed jack package that does not work
well with
qjackctl (dbus enabled one). Your application autostarted jack server
through dbus.
It did not. No jack app here uses dbus.
jackdrc style commandline options for jackd are for
jackd. They are not
used for jackdbus. They cant be used for jackdbus. Because of the object
activation works in all distributed object systems I know. This includes
DCOM and D-Bus.
What nonsense it this ? Everybody here tells me that
the dbus support is build on top of the existing C
API and nothing else, that it just a communication
layer allowing you to access the C API. Hence jackd
is the same with dbus or without. Or isn't this true,
and is the dbus support much more invasive than some
people want to admit ?
The client that autostarted a jackd did not use dbus.
When I later started qjackctl it did not use dbus.
Yet the 'jackdbus auto' daemon (which nobody needed
since all apps use the C API, but started anyway)
interferes with clients not using dbus at all.
Are you trying to say that on a jack+dbus system
*all* jack apps have to be dbus-aware (or fail) ?
So you complain about qjackctl missing support for
jackdbus? Having that
will be nice :)
Is that supposed to be funny ?
Final remark: the dbus advocates here are seriously
contradicting themselves.
1. Dbus is just a communication layer.
2. Dbus adds functionality that can't be
provided via the normal interfaces.
Both can't be true at the same time.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
1:58 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Fons Adriaensen <fons(a)kokkinizita.net> writes:
I dont get what you are talking about. Please explain.
Yes :)
On Mon, May 18, 2009 at 06:08:33PM +0300, Nedko
Arnaudov wrote:
If i got it right (dbus enabled libjack.so) then every jack app on your
machine uses dbus.
You have installed jack package that does not
work well with
qjackctl (dbus enabled one). Your application autostarted jack server
through dbus.
It did not. No jack app here uses dbus. jackdrc style
commandline options for jackd are for jackd. They are not
used for jackdbus. They cant be used for jackdbus. Because of the object
activation works in all distributed object systems I know. This includes
DCOM and D-Bus.
What nonsense it this ? Everybody here tells me that
the dbus support is build on top of the existing C
API and nothing else, that it just a communication
layer allowing you to access the C API. Hence jackd
is the same with dbus or without. Or isn't this true,
and is the dbus support much more invasive than some
people want to admit ? The client that autostarted a jackd did not use dbus.
When I later started qjackctl it did not use dbus.
libjack.so will not start jackd if compiled in dbus. Actually it can but
only if jack server start through dbus failed. Obvisouly it didnt
because you said that it got started with wrong arguments, right?
Yet the 'jackdbus auto' daemon (which nobody
needed
since all apps use the C API, but started anyway)
interferes with clients not using dbus at all.
again if you have jackdbus enabled libjack.so all your clients DO
interact with dbus.
Are you trying to say that on a jack+dbus system
*all* jack apps have to be dbus-aware (or fail) ?
NO. dbus knowledge is behind libjack. But yes, they load libdbus.so when
they are started. Maybe you want to verify that with ldd?
So you
complain about qjackctl missing support for jackdbus? Having that
will be nice :)
Is that supposed to be funny ? Final remark: the dbus advocates here are seriously
contradicting themselves.
1. Dbus is just a communication layer.
no
it is distributed object model. this somewhat bigger than IPC.
2. Dbus adds functionality that can't be
provided via the normal interfaces.
and no again
It can be added. You can reinvent the wheel. You can reuse other already
invented mechanism. D-Bus was choosen because it is already quite
widespread in Linux systems.
Both can't be true at the same time.
they are both false but even if they were true they can be both true,
according to my understanding of logic :D if A and B are not corelated
then A and B can be true at the same time.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
3:14 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Monday 18 May 2009 17:57:39 Nedko Arnaudov wrote:
Fons Adriaensen <fons(a)kokkinizita.net> writes:
You are missing the "just" which makes them correlated and means that either
dbus (at least its usage in jack) can't add functionality or it is not a plain
communication layer but more.
Here in this thread of the discussion 1 and 2 are contradictionary and really
can't be true at the same time. If you don't understand this, you don't
understand logic. (a=>b)
Arnold
1. Dbus is just a communication layer.
2. Dbus adds functionality that can't be
provided via the normal interfaces.
Both can't be true at the same time.
they are both false but even if they were
true they can be both true,
according to my understanding of logic :D if A and B are not corelated
then A and B can be true at the same time.
1:57 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Mon, May 18, 2009 16:08, Nedko Arnaudov wrote:
Fons Adriaensen <fons(a)kokkinizita.net> writes:
So you complain about qjackctl missing support for jackdbus? Having that
will be nice :)
from where i stand, qjackctl does not need jackdbus support whatsoever.
it's kind of the other way around, if i may say. and the way around is not
about qjackctl per se, but to plain old good command-line jackd.
fwiw, qjackctl just runs the jackd server as documented and interfaces to
libjack through its plain client api. it has been doing this for years and
rightly so, imo.
however, by having jackdbus in the picture and when everybody would think
it would be the holy grail, it is breaking all that instead just because
it wants to rule the game on its own. it's doing it with complete
disregard to what long time qjackctl/jackd users have been thought. that's
disgraceful to say the least.
i strongly believe that all this trouble is a matter or something that
just has been overlooked on the jackdbus development, that is, a
misinterpretation, a bug that can be squashed right away once it's
perfectly identified.
however, if all that is due on a jackdbus design decision instead, then i
am sorry, i'll digress. a completely new qjackctl has to be written from
the ground up. just don't ask me to do it, at least anytime soon :)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On Mon, May 18, 2009 at 05:13:19PM +0300, Nedko
Arnaudov wrote:
It is involved in what happenes. At least from what I've got about the
problem you have.
You have installed jack package that does not work well with
qjackctl (dbus enabled one). Your application autostarted jack server
through dbus. But you havent configured it. QJackCtl is dbus ignorant. You
should not use qjackctl with jackdbus system. Unless you know what you are
doing. Or unless qjackctl gets jackdbus support.
jackdrc style commandline options for jackd are for jackd. They are not
used for jackdbus. They cant be used for jackdbus. Because of the object
activation works in all distributed object systems I know. This includes
DCOM and D-Bus.
Fons I think we can both read C code, right?
From posix/JackPosixServerLaunch.cpp, line 166:
static int start_server(const char* server_name, jack_options_t
options) {
if ((options & JackNoStartServer) || getenv("JACK_NO_START_SERVER")) {
return 1; }
#if defined(JACK_DBUS)
return start_server_dbus(server_name); #else
....
jackd fork/exec stuff ....
I can read this and it can mean different things.
- This code is not involved in what happens
- The value of the options argument is wrong.
presence
of process with "jackdbus auto' commandline those not mean
that *server* is started. This is the dbus service, not the jack
server running.
I know that. The fact remains that when the 'jackdus auto'
daemon is running a jackd is started whenever qjackctl is started. You
can go on to deny this, but that doesn't change the facts.
2:10 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Mon, May 18, 2009 at 11:57 AM, Rui Nuno Capela <rncbc(a)rncbc.org> wrote:
from where i stand, qjackctl does not need jackdbus support whatsoever.
it's kind of the other way around, if i may say. and the way around is not
about qjackctl per se, but to plain old good command-line jackd.
i'd like to clarify (again) based on ongoing conversations in #jack.
the issue that qjackctl could consider is not jackdbus, or dbus in
general. its the JACK control API that was discussed at LAC 2008.
right now, qjackctl simply claims to know how to start the JACK
server, offers a dialog to let the user pick settings, and then
constructs a set of command line arguments for jackd.
this will continue to work forever, but it is less flexible than we
would like (consider what happens every time JACK gets a new option
added (or taken away). the control API allows a control application to
query the jack server (actually, its really querying the library that
contains the implementation of the jack server that the control app is
linked with), and discover what the available parameters are etc. etc.
the dbus stuff is really mostly orthogonal to this (i stress the
"mostly") - its just another example of a control app/system. there's
no reason why qjackctl would or should want to interact with it.
however, the one area where these things overlap is "auto-start". this
is because what it means to "auto-start" a JACK server differs in the
following two scenarios:
* vanilla JACK install - there is no "jack control" system in
place or in use
* with jackdbus - there is a daemon in place listening for
requests to start/stop/reconfigure the server
in the first scenario, the ~/.jackdrc file (if it exists) takes care
of auto-start. but if jackdbus is in use, then auto-start means
something really quite different.
we are are discussing ways to reconcile these differences on IRC.
for those who don't understand why the second scenario is worth
considering, i would point to the questions that (relatively)
frequently come from users about changing a running JACK system to use
another h/w interface, or to start/stop JACK temporarily for some
reason. there is one school of opinion that would say that "stop jackd
and restart it with the correct parameters" is the correct approach to
this question. i think that at LAC2008 it was felt that we could do
better.
--p
2:23 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Paul Davis <paul(a)linuxaudiosystems.com> writes:
On Mon, May 18, 2009 at 11:57 AM, Rui Nuno Capela
<rncbc(a)rncbc.org> wrote:
I confirm this it true (except about LAC2008 because i was not there and
i dont know). And i want to add that qjackctl can be made more flexible
if it can detect jackdbus.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
from where i stand, qjackctl does not need jackdbus support whatsoever.
it's kind of the other way around, if i may say. and the way around is not
about qjackctl per se, but to plain old good command-line jackd.
i'd like to clarify (again) based on ongoing conversations in #jack.
the issue that qjackctl could consider is not jackdbus, or dbus in
general. its the JACK control API that was discussed at LAC 2008.
right now, qjackctl simply claims to know how to start the JACK
server, offers a dialog to let the user pick settings, and then
constructs a set of command line arguments for jackd.
this will continue to work forever, but it is less flexible than we
would like (consider what happens every time JACK gets a new option
added (or taken away). the control API allows a control application to
query the jack server (actually, its really querying the library that
contains the implementation of the jack server that the control app is
linked with), and discover what the available parameters are etc. etc.
the dbus stuff is really mostly orthogonal to this (i stress the
"mostly") - its just another example of a control app/system. there's
no reason why qjackctl would or should want to interact with it.
however, the one area where these things overlap is "auto-start". this
is because what it means to "auto-start" a JACK server differs in the
following two scenarios:
* vanilla JACK install - there is no "jack control" system in
place or in use
* with jackdbus - there is a daemon in place listening for
requests to start/stop/reconfigure the server
in the first scenario, the ~/.jackdrc file (if it exists) takes care
of auto-start. but if jackdbus is in use, then auto-start means
something really quite different.
we are are discussing ways to reconcile these differences on IRC.
for those who don't understand why the second scenario is worth
considering, i would point to the questions that (relatively)
frequently come from users about changing a running JACK system to use
another h/w interface, or to start/stop JACK temporarily for some
reason. there is one school of opinion that would say that "stop jackd
and restart it with the correct parameters" is the correct approach to
this question. i think that at LAC2008 it was felt that we could do
better.
2:43 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Mon, May 18, 2009 at 12:10:45PM -0400, Paul Davis wrote:
the issue that qjackctl could consider is not
jackdbus, or dbus in
general. its the JACK control API that was discussed at LAC 2008.
right now, qjackctl simply claims to know how to start the JACK
server, offers a dialog to let the user pick settings, and then
constructs a set of command line arguments for jackd.
this will continue to work forever,
*** It already does not work anymore. ***
I have the impression that you are missing part
of the picture.
Jack-dbus is not just an (optional) server using
the C API and providing access to it via dbus.
I don not know what exactly is happening but it
interferes even if clients are just using the
C API. And it breaks it.
If it were just an optional interface that e.g.
an app such as qjackct could use to 'enhance the
user experience' that would be perfectly fine for
me. I would just not use it. It would also mean
that jackd and libjack stay just the same, they
don't have to know they are being controlled via
dbus.
But the current implementation imposes itself,
even if clients are just trying to use the C API.
And currently, maybe because of a bug, or by
design, it breaks the C API.
There is IMHO *no* reason why jack-dbus should
**intercept** C API calls, start its daemon,
and take control. As long as no client is
accessing jack via dbus, it should just not
be there. Those clients that want to use dbus
can apparently launch the server just by trying
to talk to it.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
2:50 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Mon, May 18, 2009 at 12:34 PM, Fons Adriaensen <fons(a)kokkinizita.net> wrote:
Jack-dbus is not just an (optional) server using
the C API and providing access to it via dbus.
I don not know what exactly is happening but it
interferes even if clients are just using the
C API. And it breaks it.
as far as we can tell, this is true *only* for the auto-start
situation, and that is because of the substantive difference that i
outlined in a previous message about what "auto-start" means in two
different run-time environments. and it showed up for you, as best as
can be determined, because of packaging/build issues that we hope have
been fixed.
everyone involved (i think) agrees that the current way this has to
come to be (a dbus-specific version of libjack) is not the right
solution. we are discussing ways to fix this on #jack at present.
4 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Monday 18 May 2009 12:50:50 Paul Davis wrote:
So perhaps the problem is that Fons is getting an autostart from somewhere, he
knows not where, that he doesn't know how to disable?
If there is a simple way to disable jack autostart on his system, can someone
clue him in and see if it solves his problems for now?
On Mon, May 18, 2009 at 12:34 PM, Fons Adriaensen
<fons(a)kokkinizita.net>
wrote:
Jack-dbus is
not just an (optional) server using
the C API and providing access to it via dbus.
I don not know what exactly is happening but it
interferes even if clients are just using the
C API. And it breaks it.
as far as we can tell, this is true *only* for the auto-start
situation, and that is because of the substantive difference that i
outlined in a previous message about what "auto-start" means in two
different run-time environments. and it showed up for you, as best as
can be determined, because of packaging/build issues that we hope have
been fixed.
everyone involved (i think) agrees that the current way this has to
come to be (a dbus-specific version of libjack) is not the right
solution. we are discussing ways to fix this on #jack at present.
all the best,
drew
3:58 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Monday 18 May 2009 12:34:41 Fons Adriaensen wrote:
On Mon, May 18, 2009 at 12:10:45PM -0400, Paul Davis
wrote:
Fons, are you able to make a screencast movie of what is going on with your
system and post it?
After reading this last round, things are even less clear and such an effort
may help make things plain.
the issue that qjackctl could consider is not
jackdbus, or dbus in
general. its the JACK control API that was discussed at LAC 2008.
right now, qjackctl simply claims to know how to start the JACK
server, offers a dialog to let the user pick settings, and then
constructs a set of command line arguments for jackd.
this will continue to work forever,
*** It already does not work anymore. ***
I have the impression that you are missing part
of the picture.
Jack-dbus is not just an (optional) server using
the C API and providing access to it via dbus.
I don not know what exactly is happening but it
interferes even if clients are just using the
C API. And it breaks it.
If it were just an optional interface that e.g.
an app such as qjackct could use to 'enhance the
user experience' that would be perfectly fine for
me. I would just not use it. It would also mean
that jackd and libjack stay just the same, they
don't have to know they are being controlled via
dbus.
But the current implementation imposes itself,
even if clients are just trying to use the C API.
And currently, maybe because of a bug, or by
design, it breaks the C API.
There is IMHO *no* reason why jack-dbus should
**intercept** C API calls, start its daemon,
and take control. As long as no client is
accessing jack via dbus, it should just not
be there. Those clients that want to use dbus
can apparently launch the server just by trying
to talk to it.
Ciao,
all the best,
drew
7:50 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Fons Adriaensen wrote:
There is IMHO *no* reason why jack-dbus should
**intercept** C API calls, start its daemon,
and take control.
Hmm?
libjack from non-DBUS package detects if JACK server is running, if not,
it starts the server by doing fork&exec.
libjack from DBUS package detects if JACK server is running, if not, it
starts the server by telling DBUS server to do fork&exec.
I don't see the problem, let alone OMG INTERCEPTING C API CALLS!!11! or
eating babies.
It may be harder to notice that the libjack-using application has just
started the JACK server because the server's output goes to a log file
and not stdout, but some people actually like it that way (especially
when used with tools like laditray).
I'm not saying DBUS version should be used by everyone, or that the
currently available set of tools can be safely used by general public.
On the other hand, I'm not buying into any anti-DBUS hysteria, because
the "JACK server as a background service and not stdout-spamming
application forked out from random client process" makes a lot of sense
to me.
Krzysztof
9:29 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Mon, May 18, 2009 at 10:50:01PM +0100, Krzysztof Foltman wrote:
I don't see the problem, let alone OMG
INTERCEPTING C API CALLS!!11! or
eating babies.
Well, the current implementation *does* intercept C API
calls in order to divert them to dbus, it's not just an
addition to the standard jackd. I never mentioned babies
being eaten.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
19 May
19 May
5:04 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Fons Adriaensen <fons(a)kokkinizita.net> writes:
On Mon, May 18, 2009 at 10:50:01PM +0100, Krzysztof
Foltman wrote:
As long as interface is same at C API level everything is fine. dbus
cant and does not intercept any C API calls. The implementation of the
jack_client_open(), only when compiled in dbus model, only when wants to
start jack server, starts the jack server by *CALLING* libdbus
function. That C level libdbus API call is then implemented by using the
dbus IPC mechanism (sockets) and then gets into jackdbus process that
executes the call. Nobody is intercepting jack.h API C level calls.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
I don't see the problem, let alone OMG
INTERCEPTING C API CALLS!!11! or
eating babies.
Well, the current implementation *does* intercept C API
calls in order to divert them to dbus, it's not just an
addition to the standard jackd. I never mentioned babies
being eaten.
5:37 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Tue, May 19, 2009 at 10:03:28AM +0300, Nedko Arnaudov wrote:
Fons Adriaensen <fons(a)kokkinizita.net> writes:
Nedko, you continue to contradict yourself.
What you write above confirms that the jack_client_open()
call is intercepted and its action modified.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
Well, the current implementation *does* intercept
C API
calls in order to divert them to dbus, it's not just an
addition to the standard jackd. I never mentioned babies
being eaten.
As long as interface is same at C API level everything is fine. dbus
cant and does not intercept any C API calls. The implementation of the
jack_client_open(), only when compiled in dbus model, only when wants to
start jack server, starts the jack server by *CALLING* libdbus
function. That C level libdbus API call is then implemented by using the
dbus IPC mechanism (sockets) and then gets into jackdbus process that
executes the call. Nobody is intercepting jack.h API C level calls.
6:23 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Fons Adriaensen <fons(a)kokkinizita.net> writes:
On Tue, May 19, 2009 at 10:03:28AM +0300, Nedko
Arnaudov wrote:
It is not intercepted. It is implemented. No hooking is made.
jack_client_open() action is not modified. It behaves as expected, as
documented in the API. jack server is autostarted.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Fons Adriaensen <fons(a)kokkinizita.net>
writes:
Nedko, you continue to contradict yourself.
What you write above confirms that the jack_client_open()
call is intercepted and its action modified. Well, the current implementation *does* intercept
C API
calls in order to divert them to dbus, it's not just an
addition to the standard jackd. I never mentioned babies
being eaten.
As long as interface is same at C API level everything is fine. dbus
cant and does not intercept any C API calls. The implementation of the
jack_client_open(), only when compiled in dbus model, only when wants to
start jack server, starts the jack server by *CALLING* libdbus
function. That C level libdbus API call is then implemented by using the
dbus IPC mechanism (sockets) and then gets into jackdbus process that
executes the call. Nobody is intercepting jack.h API C level calls.
6:46 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Tue, May 19, 2009 at 11:23:07AM +0300, Nedko Arnaudov wrote:
It is not intercepted. It is implemented. No hooking
is made.
jack_client_open() action is not modified. It behaves as expected, as
documented in the API. jack server is autostarted.
It's not just a different implementation. It has side effects
that the original call does not have (starting a daemon),
and these side effects will have consequences later.
If this is not true then the new implementation is
actually useless.
I would have no objection if you added e.g.
jack_client_open_via_dbus()
leaving the original call as it is.
If that new call has some real benefits then client
authors will use it. What you do now is forcing it
down everybody's throat.
Yesterday evening I had a visitor, a very fine musician
who knows nothing about computers let alone programming.
Seeing the discussion on #jack he asked me what this was
all about. So I told him this little fiction:
Someone sets up a firm that provides a free service:
they enhance your life by removing things from your
home and disposing of them.
One day I return home and find some things have been
removed.
I go the manager of the free service and tell him:
- Listen, I don't want you to enter my home and
remove things uninvited.
- But then I can't do my job !
- So you are thieves ?
- No, no, no, we just provide a free service
that enhances your life.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
7:17 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Fons Adriaensen <fons(a)kokkinizita.net> writes:
On Tue, May 19, 2009 at 11:23:07AM +0300, Nedko
Arnaudov wrote:
No and no again. jack clients dont care how jack server is started. they
want it started so they can use it. period. they dont care about jack
internal infrastructure. The whole point of abstrctions is to allow
changing the implementation. As it is with jack1 and jack2.
Why you dont want jack_client_open_jackdmp() ?
It is not intercepted. It is implemented. No
hooking is made.
jack_client_open() action is not modified. It behaves as expected, as
documented in the API. jack server is autostarted.
It's not just a different implementation. It has side effects
that the original call does not have (starting a daemon),
and these side effects will have consequences later.
If this is not true then the new implementation is
actually useless.
I would have no objection if you added e.g.
jack_client_open_via_dbus()
leaving the original call as it is. Someone sets up a firm that provides a free service:
they enhance your life by removing things from your
home and disposing of them.
One day I return home and find some things have been
removed.
I go the manager of the free service and tell him:
- Listen, I don't want you to enter my home and
remove things uninvited.
- But then I can't do my job !
- So you are thieves ?
- No, no, no, we just provide a free service
that enhances your life.
This is a BS, nobody is forcing you to use that. You have the free
will. You can choose what to use. There is an option that you dont
like. And nobody is telling you that it will enhance *your* life. It may
enahnce my life. Or someone else's. But not yours. This is why it is
optional. Even installing jack2 instead of jack1 is optional. You are
free to use VAX if you like it. Nobody is forcing you to use something
else.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
7:29 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Quoting "Fons Adriaensen" <fons(a)kokkinizita.net>et>:
I would have no objection if you added e.g.
jack_client_open_via_dbus()
How is the application supposed to know whether the user wants to use
dbus or not?
leaving the original call as it is.
I agree with Stephanes' 5):
An implementation where dbus and "classic" coexist in a single build
is the only way to go. The user environment would somehow tell jack
whether the user wants to use dbus or not. (In fact, I'd argue this
path should've been chosen from the start.)
Say for example "the file ~/.jack-classic exists" or "environment
variable JACK_COMMUNICATION=DBUS". Or a system wide configuration:
"/etc/jackd/configuration says OSC is enabled".
I agree with Nedko that this is not a change in the API. This is a
change in the implementation of the API. There's a huge difference as
we all know. We would run into all kinds of trouble if we would make
client software responsible for choosing the server communication
model. Hence the implementation was changed, not the API...
Is there anything really difficult here? Just make everyone live
happily together.
Sampo
7:38 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Le 19 mai 09 à 11:29, Sampo Savolainen a écrit :
Quoting "Fons Adriaensen"
<fons(a)kokkinizita.net>et>:
First we have to get a consensus on this "runtime choice of auto-start
strategy", then we'll have to find the best way to implement it.
Stephane
I would have no objection if you added e.g.
jack_client_open_via_dbus()
How is the application supposed to know whether the user wants to use
dbus or not?
leaving the original call as it is.
I agree with Stephanes' 5):
An implementation where dbus and "classic" coexist in a single build
is the only way to go. The user environment would somehow tell jack
whether the user wants to use dbus or not. (In fact, I'd argue this
path should've been chosen from the start.)
Say for example "the file ~/.jack-classic exists" or "environment
variable JACK_COMMUNICATION=DBUS". Or a system wide configuration:
"/etc/jackd/configuration says OSC is enabled".
I agree with Nedko that this is not a change in the API. This is a
change in the implementation of the API. There's a huge difference as
we all know. We would run into all kinds of trouble if we would make
client software responsible for choosing the server communication
model. Hence the implementation was changed, not the API...
Is there anything really difficult here? Just make everyone live
happily together.
7:45 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Stéphane Letz <letz(a)grame.fr> writes:
First we have to get a consensus on this "runtime
choice of auto-start
strategy", then we'll have to find the best way to implement it.
I was against mixed jack1/jack2 and i'm against the runtime choice
now. IMHO it complicates things for user instead of simplifying it.
It also complicates codebase and I think we can spend our efforts with
something else instead. Still, if someone has the motivation to do
runtime choice of auto-strategy - fine, i can live with it. The only
important thing is that with jackdbus the default strategy must be
autostarting through dbus. If it is not, by default jackdbus control apps
will not work with jackdbus. Such setup will be pretty useless, eh?
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
10:57 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Nedko Arnaudov wrote:
Stéphane Letz <letz(a)grame.fr> writes:
You will be isolating a whole lot of existing users by forcing a new
paradigm on them before they are ready. Just look at Facebook for a good
example of how this doesn't work.
I think jack devs have to put the effort into making the transition to a
more flexible system as subtle as possible rather than smacking people
round the head with it.
First we have to get a consensus on this
"runtime choice of auto-start
strategy", then we'll have to find the best way to implement it.
I was against mixed jack1/jack2 and i'm against the runtime choice
now. IMHO it complicates things for user instead of simplifying it.
It also complicates codebase and I think we can spend our efforts with
something else instead. Still, if someone has the motivation to do
runtime choice of auto-strategy - fine, i can live with it. The only
important thing is that with jackdbus the default strategy must be
autostarting through dbus. If it is not, by default jackdbus control apps
will not work with jackdbus. Such setup will be pretty useless, eh?
------------------------------------------------------------------------
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
11:08 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Patrick Shirkey <pshirkey(a)boosthardware.com> writes:
Nedko Arnaudov wrote:
I'm not forcing the new paradigm to anybody. I dont want to force and i
cant force because i dont maintain neither jack1 nor jack2. jackdbus was
optional and alternative from day zero. it was configure option in the
very first dbus.patch that was against jack1 codebase. Packagers force
users. Or users force themself. Developers create software. They may
give advice but they dont deploy to end user. At least in open source
world.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Stéphane Letz <letz(a)grame.fr> writes:
You will be isolating a whole lot of existing users by forcing a new
paradigm on them before they are ready. Just look at Facebook for a
good example of how this doesn't work.
I think jack devs have to put the effort into making the transition to
a more flexible system as subtle as possible rather than smacking
people round the head with it. First we have to get a consensus on this
"runtime choice of auto-start
strategy", then we'll have to find the best way to implement it.
I was against mixed jack1/jack2 and i'm against the runtime choice
now. IMHO it complicates things for user instead of simplifying it.
It also complicates codebase and I think we can spend our efforts with
something else instead. Still, if someone has the motivation to do
runtime choice of auto-strategy - fine, i can live with it. The only
important thing is that with jackdbus the default strategy must be
autostarting through dbus. If it is not, by default jackdbus control apps
will not work with jackdbus. Such setup will be pretty useless, eh?
1:50 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Tue, 2009-05-19 at 10:37 +0200, Fons Adriaensen wrote:
Someone sets up a firm that provides a free service:
they enhance your life by removing things from your
home and disposing of them.
One day I return home and find some things have been
removed.
I go the manager of the free service and tell him:
- Listen, I don't want you to enter my home and
remove things uninvited.
- But then I can't do my job !
- So you are thieves ?
- No, no, no, we just provide a free service
that enhances your life.
I have to say, I think this is really out of line, Fons. Implying free
software developers are theives because they've changed something and
you don't like it is quite extraordinary.
I think a better analogy would be like so:
Someone sets up a firm that provides and maintains free furniture,
appliances, plumbing and electricity for anybody's home.
One day, you come home and find half of your radiators don't work
because someone has started upgrading the plumbing and hasn't finished
yet.
You go to the manager of the free service and tell him:
- Listen, I don't want you to stop the radiators in my house from
working.
- That's fine, you're entirely free to install your own plumbing, or fix
the plumbing we've installed for you.
- I don't want to, you should do it for me and do it right dammit!
2:26 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Bob Ham wrote:
On Tue, 2009-05-19 at 10:37 +0200, Fons Adriaensen
wrote:
Both metaphors are error coloured.
If a community will do something together as an free alternative, than
nobody can command to get something that fit to his needs so much tuned,
as if he has paid for something.
But it's stupid for a free alternative, if working stuff can become
absolutely incompatible to older versions or cause major troubles for
many used functions.
I'm speaking in general, not especially for the different threads about
the rc files and dbus.
If people call attention to things that can cause trouble in the future
or that cause trouble right now, than it's not clever to answer, that he
should do it by himself, pay for something etc..
Ideas, different opinions or getting aware of something other people
haven't noticed and refer to it, isn't an attack against the people that
are working for free, especially not if it comes from people who do
their self work without being paid.
I'm using Linux since years (not rt-audio ;)) and the architecture of
Linux has one big disadvantage. You might have a Linux that is fine, the
times are changing and in addition you need an absolutely new
application, but you don't need to update any of the applications you're
using since years.
You can't install the new application, because dependencies needs to be
updated and that causes that also your perfect working applications
needs to be updated.
You do an update. The new applications is fine. The old, updated
applications ...
... are fine
... but not all, some are broken ...
... others are fine for new work, but you can't load old projects any
more ...
... other applications can't be installed any more ... etc. ...
Sometimes a coder or a packer (packages builder?!) don't work as
intensive with 'hi' application as the community does, so he can fail to
see some issues.
Resume: If something was fine, it's not an advantage if it gets broken.
If something needs to be broken, because of the development, it
shouldn't be released. We won't practise on stage, we practise in the
rehearsal room.
Sorry, I need to write this,
Ralf
Someone sets up a firm that provides a free
service:
they enhance your life by removing things from your
home and disposing of them.
One day I return home and find some things have been
removed.
I go the manager of the free service and tell him:
- Listen, I don't want you to enter my home and
remove things uninvited.
- But then I can't do my job !
- So you are thieves ?
- No, no, no, we just provide a free service
that enhances your life.
I have to say, I think this is really out of line, Fons. Implying free
software developers are theives because they've changed something and
you don't like it is quite extraordinary.
I think a better analogy would be like so:
Someone sets up a firm that provides and maintains free furniture,
appliances, plumbing and electricity for anybody's home.
One day, you come home and find half of your radiators don't work
because someone has started upgrading the plumbing and hasn't finished
yet.
You go to the manager of the free service and tell him:
- Listen, I don't want you to stop the radiators in my house from
working.
- That's fine, you're entirely free to install your own plumbing, or fix
the plumbing we've installed for you.
- I don't want to, you should do it for me and do it right dammit!
2:30 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> writes:
If something needs to be broken, because of the
development,
it shouldn't be released. We won't practise on stage, we practise in
the rehearsal room.
In open source world, with public source control repos each commit is a
publish. So you got a camera in your rehearshal room. And the live
stream is watched by whom likes your jaming.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
2:39 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Nedko Arnaudov wrote:
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
writes:
Watching the jam for free, you can learn a lot, but you don't get the
music you might wish to get, you need to go to the concert for free or
you need to download the recording for free AND the band can produce
different new versions, but it should be possible to hear the first
version of the concert in the future ... metaphors won't work ;).
If something needs to be broken, because of the
development,
it shouldn't be released. We won't practise on stage, we practise in
the rehearsal room.
In open source world, with public source control repos each commit is a
publish. So you got a camera in your rehearshal room. And the live
stream is watched by whom likes your jaming.
2:41 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> writes:
Nedko Arnaudov wrote:
The live stream is captured (public repo is persistent) and you can hear
the first version in the future. ;)
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
writes:
Watching the jam for free, you can learn a lot, but you don't get the
music you might wish to get, you need to go to the concert for free or
you need to download the recording for free AND the band can produce
different new versions, but it should be possible to hear the first
version of the concert in the future ... metaphors won't work ;). If something needs to be broken, because of the
development,
it shouldn't be released. We won't practise on stage, we practise in
the rehearsal room.
In open source world, with public source control repos each commit is a
publish. So you got a camera in your rehearshal room. And the live
stream is watched by whom likes your jaming.
2:52 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Nedko Arnaudov wrote:
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
writes:
Metaphors don't work :D.
Nedko Arnaudov wrote:
The live stream is captured (public repo is persistent) and you can hear
the first version in the future. ;)
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
writes:
Watching the jam for free, you can learn a lot, but you don't get the
music you might wish to get, you need to go to the concert for free or
you need to download the recording for free AND the band can produce
different new versions, but it should be possible to hear the first
version of the concert in the future ... metaphors won't work ;).
If something needs to be broken, because of the
development,
it shouldn't be released. We won't practise on stage, we practise in
the rehearsal room.
In open source world, with public source control repos each commit is a
publish. So you got a camera in your rehearshal room. And the live
stream is watched by whom likes your jaming.
2:32 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Ralf Mardorf wrote:
Sometimes a coder or a packer (packages builder?!)
don't work as
intensive with 'hi' application as the community does, so he can fail
to see some issues.
'hi' is missing an 's', it should be
'his' ... I guess my English is too
broken, so there seems to be the need to correct this, otherwise nobody
can understand what I was writing about.
2:27 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Bob Ham <rah(a)bash.sh> writes:
On Tue, 2009-05-19 at 10:37 +0200, Fons Adriaensen
wrote:
Even better:
Someone sets up a firm Foo that produces furniture,
appliances, plumbing, etc.
Someone sets up a firm Bar that provides and maintains free furniture,
appliances, plumbing and electricity for anybody's home by using the
prducts of firm Foo.
One day, you come home and find half of your radiators don't work
because someone has started upgrading the plumbing and hasn't finished
yet.
You go to the manager of the firm Foo and tell him:
- Listen, I don't want you to stop the radiators in my house from
working.
- I don't. I have no control with out. Why you dont ask the manager of
firm Bar?
- But you produce it!
- Yes, we produce toxic waste too. There are bacteria that eat it. I'm
affraid the manager of firm Bar got impression that you eat toxic
waste too. I'm sorry about situation. We will improve instructions
about our toxic waste product but still, you have to request Bar to
meet your requirements. Or stop using Bar and use Baz instead.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Someone sets up a firm that provides a free
service:
they enhance your life by removing things from your
home and disposing of them.
One day I return home and find some things have been
removed.
I go the manager of the free service and tell him:
- Listen, I don't want you to enter my home and
remove things uninvited.
- But then I can't do my job !
- So you are thieves ?
- No, no, no, we just provide a free service
that enhances your life.
I have to say, I think this is really out of line, Fons. Implying free
software developers are theives because they've changed something and
you don't like it is quite extraordinary.
I think a better analogy would be like so:
Someone sets up a firm that provides and maintains free furniture,
appliances, plumbing and electricity for anybody's home.
One day, you come home and find half of your radiators don't work
because someone has started upgrading the plumbing and hasn't finished
yet.
You go to the manager of the free service and tell him:
- Listen, I don't want you to stop the radiators in my house from
working.
- That's fine, you're entirely free to install your own plumbing, or fix
the plumbing we've installed for you.
- I don't want to, you should do it for me and do it right dammit!
2:36 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Tue, May 19, 2009 at 04:49:58PM +0100, Bob Ham wrote:
I have to say, I think this is really out of line,
Fons. Implying free
software developers are theives because they've changed something and
you don't like it is quite extraordinary.
I did not imply such a thing. You are completely
missing the point.
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
2:44 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Tue, 2009-05-19 at 18:27 +0200, Fons Adriaensen wrote:
On Tue, May 19, 2009 at 04:49:58PM +0100, Bob Ham
wrote:
Such is the danger of analogies. What was the point?
--
Bob Ham <rah(a)bash.sh>
I have to say, I think this is really out of
line, Fons. Implying free
software developers are theives because they've changed something and
you don't like it is quite extraordinary.
I did not imply such a thing. You are completely
missing the point.
2:56 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Bob Ham wrote:
On Tue, 2009-05-19 at 18:27 +0200, Fons Adriaensen
wrote:
Running gag: Metaphors don't work :D.
I wish you all get your views reconciled. Tonight I'll try to make music
with Linux again (by using jack).
Good luck to you, good luck to myself,
Ralf
On Tue, May 19, 2009 at 04:49:58PM +0100, Bob Ham
wrote:
Such is the danger of analogies. What was the point?
I have to say, I think this is really out of
line, Fons. Implying free
software developers are theives because they've changed something and
you don't like it is quite extraordinary.
I did not imply such a thing. You are completely
missing the point.
4:22 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
Ralf.
I find it hard to see how you actually understand Linux audio. I get the
impression that you have almost tried but instead have persistently
trolled on this point since you arrived.
The above is a "full stop" of Ralfs dialog, I say this just in case
there is a possible alternative that seems to make sense for a temporary
period.
Ralf.
Please stop with your destabilising crap.
- For reference : This must be the 50th time Ralf has been asked to stop
dissing Linux Audio...
Eventually someone from the mass media will see through his bs (and M$
fud). Until that time we are at his merciful prerogative to make Linux
audio look like he and his cronies give a shit. I have to wonder tho,
That if he is prepared to spend this much time dissing Linux audio,
then his boosses must be really scared about the results as they are
obviously well aware of how close we are to the existing sytem that has
been devised by the "Geniuses" at ...(insert your favorite sound system
here)
Ralf. I would really love to hear a conclusive rebuttal from you.. After
four years. (is it really that long?) I think we are owed a conclusive
response.
Patrick Shirkey
Boost Hardware Ltd
Ralf Mardorf wrote:
Bob Ham wrote:
On Tue, 2009-05-19 at 18:27 +0200, Fons
Adriaensen wrote:
Running gag: Metaphors don't work :D.
I wish you all get your views reconciled. Tonight I'll try to make music
with Linux again (by using jack).
Good luck to you, good luck to myself,
Ralf
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
On Tue, May 19, 2009 at 04:49:58PM +0100, Bob Ham
wrote:
Such is the danger of analogies. What was the point?
I have to say, I think this is really out of
line, Fons. Implying free
software developers are theives because they've changed something and
you don't like it is quite extraordinary.
I did not imply such a thing. You are completely
missing the point.
6:32 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
You get me wrong.
Patrick Shirkey wrote:
Ralf.
I find it hard to see how you actually understand Linux audio. I get
the impression that you have almost tried but instead have
persistently trolled on this point since you arrived.
The above is a "full stop" of Ralfs dialog, I say this just in case
there is a possible alternative that seems to make sense for a
temporary period.
Ralf.
Please stop with your destabilising crap.
- For reference : This must be the 50th time Ralf has been asked to
stop dissing Linux Audio...
Eventually someone from the mass media will see through his bs (and M$
fud). Until that time we are at his merciful prerogative to make Linux
audio look like he and his cronies give a shit. I have to wonder tho,
That if he is prepared to spend this much time dissing Linux audio,
then his boosses must be really scared about the results as they are
obviously well aware of how close we are to the existing sytem that
has been devised by the "Geniuses" at ...(insert your favorite sound
system here)
Ralf. I would really love to hear a conclusive rebuttal from you..
After four years. (is it really that long?) I think we are owed a
conclusive response.
Patrick Shirkey
Boost Hardware Ltd
Ralf Mardorf wrote:
--
Bob Ham wrote:
On Tue, 2009-05-19 at 18:27 +0200, Fons
Adriaensen wrote:
Running gag: Metaphors don't work :D.
I wish you all get your views reconciled. Tonight I'll try to make
music with Linux again (by using jack).
Good luck to you, good luck to myself,
Ralf
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
On Tue, May 19, 2009 at 04:49:58PM +0100, Bob Ham
wrote:
> I have to say, I think this is really out of line, Fons. Implying
> free
> software developers are theives because they've changed something and
> you don't like it is quite extraordinary.
>
I did not imply such a thing. You are completely missing the point.
Such is the danger of analogies. What was the point?
5:17 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Tue, May 19, 2009 at 05:44:36PM +0100, Bob Ham wrote:
Such is the danger of analogies. What was the point?
Scroll back 100 messages, read everything and maybe
you will grok it :-)
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
5:28 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Tue, 2009-05-19 at 21:08 +0200, Fons Adriaensen wrote:
On Tue, May 19, 2009 at 05:44:36PM +0100, Bob Ham
wrote:
I was reading through the thread when I encountered your fiction. It's
the previous messages that brought me to the conclusion I came to about
the point of the fiction. I was evidently wrong and I don't understand
what the point actually was.
--
Bob Ham <rah(a)bash.sh>
Such is the danger of analogies. What was the
point?
Scroll back 100 messages, read everything and maybe
you will grok it :-)
5:50 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Tue, May 19, 2009 at 08:28:21PM +0100, Bob Ham wrote:
Denial. The parrot is not dead. It's just a little bit tired.
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
Scroll back
100 messages, read everything and maybe
you will grok it :-)
I was reading through the thread when I encountered your fiction. It's
the previous messages that brought me to the conclusion I came to about
the point of the fiction. I was evidently wrong and I don't understand
what the point actually was.
6:37 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Tue, 2009-05-19 at 21:41 +0200, Fons Adriaensen wrote:
On Tue, May 19, 2009 at 08:28:21PM +0100, Bob Ham
wrote:
Denial. The parrot is not dead. It's just a little bit tired.
Heh, yeah I get that analogy :-) I can see where you were going with
the fiction now, too.
Scroll
back 100 messages, read everything and maybe
you will grok it :-)
I was reading through the thread when I encountered your fiction. It's
the previous messages that brought me to the conclusion I came to about
the point of the fiction. I was evidently wrong and I don't understand
what the point actually was. 
11:03 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Mon, May 18, 2009 at 12:10:45PM -0400, Paul Davis wrote:
On Mon, May 18, 2009 at 11:57 AM, Rui Nuno Capela
<rncbc(a)rncbc.org> wrote:
so please tell me why the dbus implementation CANT just read .jackdrc ?
i am really pissed on all you guys trampling on legacy stuff.
WHY cant jackdbus just use the .jackdrc if it does not find its own .xml
config ? or check, whether .jackdrc is newer than the xml ?
you always point at us saying we dont like dbus. its not about dbus. its
about dbus people ignoring legacy. stop breaking legacy !
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
from where i stand, qjackctl does not need jackdbus support whatsoever.
it's kind of the other way around, if i may say. and the way around is not
about qjackctl per se, but to plain old good command-line jackd.
i'd like to clarify (again) based on ongoing conversations in #jack.
the issue that qjackctl could consider is not jackdbus, or dbus in
general. its the JACK control API that was discussed at LAC 2008.
right now, qjackctl simply claims to know how to start the JACK
server, offers a dialog to let the user pick settings, and then
constructs a set of command line arguments for jackd.
this will continue to work forever, but it is less flexible than we
would like (consider what happens every time JACK gets a new option
added (or taken away). the control API allows a control application to
query the jack server (actually, its really querying the library that
contains the implementation of the jack server that the control app is
linked with), and discover what the available parameters are etc. etc.
the dbus stuff is really mostly orthogonal to this (i stress the
"mostly") - its just another example of a control app/system. there's
no reason why qjackctl would or should want to interact with it.
however, the one area where these things overlap is "auto-start". this
is because what it means to "auto-start" a JACK server differs in the
following two scenarios:
* vanilla JACK install - there is no "jack control" system in
place or in use
* with jackdbus - there is a daemon in place listening for
requests to start/stop/reconfigure the server
in the first scenario, the ~/.jackdrc file (if it exists) takes care
of auto-start. but if jackdbus is in use, then auto-start means
something really quite different.
11:15 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
torbenh(a)gmx.de writes:
so please tell me why the dbus implementation CANT
just read .jackdrc ?
i am really pissed on all you guys trampling on legacy stuff.
It can. Nobody has implemented it.
WHY cant jackdbus just use the .jackdrc if it does not
find its own .xml
config ? or check, whether .jackdrc is newer than the xml ?
Because it is useless. It is useless because you will still have two
configuration files. You are not solving the problem. qjackctl and
ardour will save to jackdrc, jackdbus (or multiconfig object) will save
to other file.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
18 May
18 May
2:16 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
"Rui Nuno Capela" <rncbc(a)rncbc.org> writes:
In jackdbus system qjackctl is unusable for starting and configuring the
jack server (there is no jackd executable). However qjackctl can still
be used to monitor xruns and DSP load and as a patchbay application.
So you
complain about qjackctl missing support for jackdbus? Having that
will be nice :)
from where i stand, qjackctl does not need jackdbus support whatsoever.
it's kind of the other way around, if i may say. and the way around is not
about qjackctl per se, but to plain old good command-line jackd. fwiw, qjackctl just runs the jackd server as
documented and interfaces to
libjack through its plain client api. it has been doing this for years and
rightly so, imo.
Yup I know that. And this is why it works as patchbay and monitor app
when used with jackdbus.
however, by having jackdbus in the picture and when
everybody would think
it would be the holy grail, it is breaking all that instead just because
it wants to rule the game on its own. it's doing it with complete
disregard to what long time qjackctl/jackd users have been thought. that's
disgraceful to say the least.
It is not breaking it is fixing issues. Or I'm wrong that qjackctl can't
show messages generated by jackd when jackd is autolaunched by regular
jack client application? Last time I checked those messages go to
application's stdout (that is inherited from the parent process - the
one of the normal jack client application).
The issue that started this holy war is that dbus enabled package that
contains also jackd got into the hands of Fons and ate his babies. The
problem is already fixed in svn. qjackctl will not work when dbus is
enabled unless both jackdbus and jackd are compiled and installed and
after the packager ignores the warning text at configure time. qjackctl
will not work because there will be not jackd executable installed.
i strongly believe that all this trouble is a matter
or something that
just has been overlooked on the jackdbus development, that is, a
misinterpretation, a bug that can be squashed right away once it's
perfectly identified.
Unless you point to what is wrong nobody who knows how jackdbus system
operates will understand what you mean.
however, if all that is due on a jackdbus design
decision instead, then i
am sorry, i'll digress. a completely new qjackctl has to be written from
the ground up. just don't ask me to do it, at least anytime soon :)
I asked you to add support for jackdbus (there are qt dbus wrappers)
more than a year ago. It was in December 2007 IIRC. Not that I hoped a
lot even back then.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
19 May
19 May
11:20 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Mon, May 18, 2009 at 07:15:23PM +0300, Nedko Arnaudov wrote:
"Rui Nuno Capela" <rncbc(a)rncbc.org>
writes:
In jackdbus system qjackctl is unusable for starting and configuring the
jack server (there is no jackd executable). However qjackctl can still
be used to monitor xruns and DSP load and as a patchbay application.
and why is this sooooooooo complicated ?
why not think a bit about legacy ?
this "i dont care for legacy" attitude is the problem. and it does not
help to say we think "dbus eats babies". this is just a cheap excuse.
we are pissed because you dont care.
and i am starting to care less and less for all this shit too.
So you
complain about qjackctl missing support for jackdbus? Having that
will be nice :)
from where i stand, qjackctl does not need jackdbus support whatsoever.
it's kind of the other way around, if i may say. and the way around is not
about qjackctl per se, but to plain old good command-line jackd. fwiw, qjackctl just runs the jackd server as
documented and interfaces to
libjack through its plain client api. it has been doing this for years and
rightly so, imo.
Yup I know that. And this is why it works as patchbay and monitor app
when used with jackdbus.
however, by having jackdbus in the picture and
when everybody would think
it would be the holy grail, it is breaking all that instead just because
it wants to rule the game on its own. it's doing it with complete
disregard to what long time qjackctl/jackd users have been thought. that's
disgraceful to say the least.
It is not breaking it is fixing issues. Or I'm wrong that qjackctl can't
show messages generated by jackd when jackd is autolaunched by regular
jack client application? Last time I checked those messages go to
application's stdout (that is inherited from the parent process - the
one of the normal jack client application).
The issue that started this holy war is that dbus enabled package that
contains also jackd got into the hands of Fons and ate his babies. The
problem is already fixed in svn. qjackctl will not work when dbus is
enabled unless both jackdbus and jackd are compiled and installed and
after the packager ignores the warning text at configure time. qjackctl
will not work because there will be not jackd executable installed. i strongly believe that all this trouble is a
matter or something that
just has been overlooked on the jackdbus development, that is, a
misinterpretation, a bug that can be squashed right away once it's
perfectly identified.
Unless you point to what is wrong nobody who knows how jackdbus system
operates will understand what you mean.
however, if all that is due on a jackdbus design
decision instead, then i
am sorry, i'll digress. a completely new qjackctl has to be written from
the ground up. just don't ask me to do it, at least anytime soon :)
I asked you to add support for jackdbus (there are qt dbus wrappers)
more than a year ago. It was in December 2007 IIRC. Not that I hoped a
lot even back then.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0> _______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
12:20 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
torbenh(a)gmx.de writes:
On Mon, May 18, 2009 at 07:15:23PM +0300, Nedko
Arnaudov wrote:
and why is this sooooooooo complicated ?
why not think a bit about legacy ?
this "i dont care for legacy" attitude is the problem. and it does not
help to say we think "dbus eats babies". this is just a cheap excuse.
we are pissed because you dont care.
and i am starting to care less and less for all this shit too.
I care about legacy. I've implemented a2jmidid to support legacy ALSA
seq stuff. I've tried to not obsolete legacy things. But when some part
is not designed to cooperate and is not extendable you have to give up.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
however,
by having jackdbus in the picture and when everybody would think
it would be the holy grail, it is breaking all that instead just because
it wants to rule the game on its own. it's doing it with complete
disregard to what long time qjackctl/jackd users have been thought. that's
disgraceful to say the least.
It is not breaking it is fixing issues. Or I'm wrong that qjackctl can't
show messages generated by jackd when jackd is autolaunched by regular
jack client application? Last time I checked those messages go to
application's stdout (that is inherited from the parent process - the
one of the normal jack client application).
The issue that started this holy war is that dbus enabled package that
contains also jackd got into the hands of Fons and ate his babies. The
problem is already fixed in svn. qjackctl will not work when dbus is
enabled unless both jackdbus and jackd are compiled and installed and
after the packager ignores the warning text at configure time. qjackctl
will not work because there will be not jackd executable installed.
18 May
18 May
12:21 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness : some comments
On Mon, May 18, 2009 10:15, Nedko Arnaudov wrote:
"Rui Nuno Capela" <rncbc(a)rncbc.org>
writes:
Nedko, that just doesn't seem to hold against what Fons has been reporting.
are you implying that the jackdbus stack is ignoring any explicit jackd
command line arguments and honoring what is in its own config file ???
imnsho, that's not plain wrong, that's terrorism! it does "ate all your
babies" alright >:(
nuff said?
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On Mon, May 18, 2009 09:17, Nedko Arnaudov
wrote:
libjack does not start jack server if JackNoStartServer is specified. This
behaviour is same for both jackd autolaunching and dbus jack server
starting through activation. Presense of the jackdbus process *DOES NOT
MEAN* that jack server is started. It looks like fair
game to me.
Using the "dbus ate my babies" matra is causing mess because other
people don't think so. Using dbus interface in qjackctl would fix lot
of this mess and this is the reason I asked Rui about that. Of course
"dbus
ate my babies" ppl would see usage of jackdbus in qjackctl as a bad
thing.
main trouble, imo, is that jackdbus is currently not playing fair game
with qjackctl wrt. jackd auto-start functionality.
as noted in one my other post, qjackctl always issues
jack_client_open() with *JackNoStartServer* option, which explicitly
instructs on jack stack for *never* start jackd on its call. apparently,
jackdbus lacks this call and starts jackd no matter what, giving us all
the "ate my babies" mantra ;)
so it seems like just a missing piece in the jackdbus implementation
re. the jack api. it this stands true, i guess it should be easily fixed
so that future jackdbus and legacy qjackctl can still live on together
for many years to come ;)
17 May
17 May
8:04 p.m.
New subject: more jack/qjackctl madness : some comments
Stéphane Letz wrote:
3) The port issue Fons told about in Qjackctl 0.3.4 seems to be a
Qjackctl bug, so has to be fixed at the right place.
the bug might have been fixed already on cvs (qjackctl 0.3.4.14+)
:-)
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
12:06 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, May 17, 2009 at 02:07:55PM +0100, Rui Nuno Capela wrote:
It shouldn't depend on jack being 1 or 2.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
unfortunately, Qt4's class which is being used for
wrapping the jackd
process (QProcess) does kill it on its destructor. afaict, this behavior
wasn't present in Qt3 and that's why there's no option to keep jackd
running upon quitting qjackctl anymore.
First, you don't need Qt classes to start a process,
so that's a bit weak. Second, I'd be surprise if
Qt would not allow you to keep a process it created
running.
2.
Qjackctl-0.3.4 seems to have a bug handling the port
creation and destruction callbacks, it continues to show
ports that have been deleted and does not show some new
ones. This happens when the delete/create calls are close
together. Jack_evmon shows the right events in the right
order, so it must be qjackctl getting it wrong.
i suppose i'll have to fix this soon. by properly handling port
unregistration callbacks, which will be a novelty after 5+ years of
doing just fine without on jack1 at least ;)
2:14 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sunday 17 May 2009 07:31:03 Fons Adriaensen wrote:
1. I definitely want to be able to terminate qjackctl
without stopping jackd, even if that jackd was started
by qjackctl. This used to be possible.
Indeed it did. I used to do it all the time. I have noticed I had problems
with this recently but figured my forgetteror was working in high gear.
It should certainly be possible to:
1. start qjackctl with a running jack and have it gain control over that jack
and then be able to quit that qjackctl and leave jack running.
2. start qjackctl, start jack from qjackctl, quit qjackctl leaving jack
running.
Are either of these now impossible by design and if so, why?
all the best,
drew
4:51 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, 17 May 2009 12:14:26 -0400
drew Roberts <zotz(a)100jamz.com> wrote:
On Sunday 17 May 2009 07:31:03 Fons Adriaensen wrote:
Currently 1) is possible, don't know about jack2, gave up on it for the
time being.
Philipp
1. I definitely want to be able to terminate
qjackctl
without stopping jackd, even if that jackd was started
by qjackctl. This used to be possible.
Indeed it did. I used to do it all the time. I have noticed I had
problems with this recently but figured my forgetteror was working in
high gear.
It should certainly be possible to:
1. start qjackctl with a running jack and have it gain control over
that jack and then be able to quit that qjackctl and leave jack
running.
2. start qjackctl, start jack from qjackctl, quit qjackctl leaving
jack running.
Are either of these now impossible by design and if so, why?
all the best,
drew
5:50 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, 17 May 2009 00:31:41 +0200, Fons Adriaensen <fons(a)kokkinizita.net>
wrote:
A request to the jackdmp and qjackctl devs:
PLEASE REMOVE THAT DBUS MADNESS
Hi Fons,
As long as there's a compile time switch, I don't see how dbus could ever
be a problem for those who don't want to use it... and for those who do, I
can tell you it works pretty well.
Cheers,
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
7:32 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, May 17, 2009 at 09:50:55AM +0200, MarcO'Chapeau wrote:
On Sun, 17 May 2009 00:31:41 +0200, Fons Adriaensen
<fons(a)kokkinizita.net>
wrote:
Compile time ? I'm a simple user installing things from
a reputable distro.
A request to the jackdmp and qjackctl devs:
PLEASE REMOVE THAT DBUS MADNESS
Hi Fons,
As long as there's a compile time switch, I don't see how dbus could ever
be a problem for those who don't want to use it... and for those who do, I can tell you it works pretty
well.
Are you serious ?
When jackd is autostarted by an app (with the wrong
settings, a separate problem), it creates a dbus daemon
that seems to prevent qjackctl to start jackd with
the right settings. The result is a jackd that does
not any way correspond the the setup in qjackctl, and
there is no way to escape from this, except by manually
killing the daemon. Do you call that 'working pretty
well' ?
When qjackctl starts displaying ports that don't
exist anymore and does not display those that
do exist (no problem with jack-0.116.1) do you
call that 'working pretty well' ?
I'd call it completely broken.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
8:20 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, 17 May 2009 11:23:03 +0200, Fons Adriaensen <fons(a)kokkinizita.net>
wrote:
Ok. a few things here:
- dbus is not the default compile time config option. Your distro should
probably disable it (until it's stable and shiny)
- When dbus is active, it is indeed not backwards compatible with the
legacy autostart feature... I agree it might need fixing
- The behavior you describe with ports is indeed a bug and needs fixing
And for the record, "fixing a mess" doesn't always need to be "deleting
all
the features that might create it".
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
On Sun, May 17, 2009 at 09:50:55AM +0200,
MarcO'Chapeau wrote:
> On Sun, 17 May 2009 00:31:41 +0200, Fons Adriaensen
> <fons(a)kokkinizita.net>
> wrote:
> > A request to the jackdmp and qjackctl devs:
> >
> > PLEASE REMOVE THAT DBUS MADNESS
>
> Hi Fons,
>
> As long as there's a compile time switch, I don't see how dbus could
ever
be a problem
for those who don't want to use it...
Compile time ? I'm a simple user installing things from
a reputable distro.
and for those who do, I can tell you it works
pretty well.
Are you serious ?
When jackd is autostarted by an app (with the wrong
settings, a separate problem), it creates a dbus daemon
that seems to prevent qjackctl to start jackd with
the right settings. The result is a jackd that does
not any way correspond the the setup in qjackctl, and
there is no way to escape from this, except by manually
killing the daemon. Do you call that 'working pretty
well' ?
When qjackctl starts displaying ports that don't
exist anymore and does not display those that
do exist (no problem with jack-0.116.1) do you
call that 'working pretty well' ?
I'd call it completely broken.
9:20 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, May 17, 2009 at 12:20:34PM +0200, MarcO'Chapeau wrote:
- dbus is not the default compile time config option.
Your distro should
probably disable it (until it's stable and shiny)
On this I agree.
- When dbus is active, it is indeed not backwards
compatible with the
legacy autostart feature... I agree it might need fixing
Very very nice. Good luck with it.
- The behavior you describe with ports is indeed a bug
and needs fixing
Seems to be qjackctl-0.3.4. Until this is fixed it is completely
useless for me.
And for the record, "fixing a mess"
doesn't always need to be "deleting all
the features that might create it".
Depends on what these features are supposed to add.
The only argument pro using dbus I'v heard so far
is that it permits run-time discovery of new backends,
internal clients and their parameters.
If it were true, it's a very weak argument. We
do have new backends every day do we ? The last
one added I know of was more than two years ago.
But it is bogus. The dbus server uses the existing
control interface and it can't provide any info
that can't be obtained there directly and with
much less hassle.
To get backend parameters, you can also just dlopen
the backend.so and read them directly - there's a
function for this, used by jackd for its help, and
also by the control interface.
Given the name of the backend it takes 10 lines
of code to do this, which is 3 orders of magnitude
less than all the dbus stuff required at both ends.
Dbus assumes there is a local login, without that
there is no session bus, and things don't work.
Most of my audio machines are headless, there is
no local login, but I still expect things to work,
and that, IMHO, is not unreasonable.
If it doesn't add any functionality that can be
provided in simpler ways, and if it doesn't work
in some perfectly legal use cases, there is no
reason for having it.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
9:43 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, 17 May 2009 13:11:23 +0200, Fons Adriaensen <fons(a)kokkinizita.net>
wrote:
The only argument pro using dbus I'v heard so far
is that it permits run-time discovery of new backends,
internal clients and their parameters.
That's unfair. Read the archives. There are more arguments to that.
Dbus assumes there is a local login, without that
there is no session bus, and things don't work.
Most of my audio machines are headless, there is
no local login, but I still expect things to work,
and that, IMHO, is not unreasonable.
It is not unreasonable. No one said you *had* to use dbus. This needs
fixing and until it is fixed, packagers should be advised to disable dbus.
If it doesn't add any functionality that can be
provided in simpler ways, and if it doesn't work
in some perfectly legal use cases, there is no
reason for having it.
The code for the legacy behavior might make jack a few lines lighter, but
have you looked at qjackctl's code ? Starting jack via some pseudo command
line scripting using Qt and c++ is not something I'd like to maintain. The
thing is, Rui had no choice since it is the only way one could build a
control application with the legacy jack. That's one of the things a
control API is meant to change.
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
10:25 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, May 17, 2009 at 01:43:55PM +0200, MarcO'Chapeau wrote:
The code for the legacy behavior might make jack a few
lines lighter, but
have you looked at qjackctl's code ? Starting jack via some pseudo command
line scripting using Qt and c++ is not something I'd like to maintain.
Starting a process in C/C++ is easy enough, and if Qt
makes it difficult that's Qt's problem.
Anyway, you don't need dbus, just provide a start()
function in the control interface, accepting the
options in a string, or as an argv[]. Why doesn't
this exist ? Why do you have to go through all the
movements of scanning parameters, types, ranges,
setting them one by one, if you already know the
command line (which will be the case in 99.99% of
cases jack is started) ?
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
10:48 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, 2009-05-17 at 14:17 +0200, Fons Adriaensen wrote:
Anyway, you don't need dbus, just provide a
start()
function in the control interface, accepting the
options in a string, or as an argv[]. Why doesn't
this exist ? Why do you have to go through all the
movements of scanning parameters, types, ranges,
setting them one by one, if you already know the
command line (which will be the case in 99.99% of
cases jack is started) ?
What I see as the most important thing, is that a client starting jack
doesn't need to know how jack is supposed to be ran. This is why
~/.jackrc was made, but this causes several issues for me. The most
important one of them being that the jackd server process is then
connected directly to the client starting it. If that client quits,
jackd dies (or leaves the client process hanging around until jackd is
no longer needed).
I hope to see from jack d-bus that clients will be able to tell the
environment (through dbus) that "I want jack". The environment has a
utility which is responsible for starting jack. This might be totally
invisible to the user (which fits a lot of people), or it might be a
more comprehensive tool like qjackctl. A tool that handles multiple jack
configurations. I run jack frequently with 3 different sound cards with
different parameters plus the dummy driver to do debugging.
As for execv(char *path, char *argv[]). What Marc meant was that there
could be (will be? is already) an API to give the client contorl over
server parameters without teaching every app what command line
parameters jackd has and how they're used.
Sampo
5:02 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
I noticed some of the issues with qjackctl and am glad they got
addressed now.
One question is still open tough:
Where does jack get it's options when it's auto-started by an
application (not ardour, that's not an auto-start imho).
Regards,
Philipp
7:08 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
hollunder(a)gmx.at wrote:
I noticed some of the issues with qjackctl and am glad
they got
addressed now.
One question is still open tough:
Where does jack get it's options when it's auto-started by an
application (not ardour, that's not an auto-start imho).
that's exactly the purpose of the ~/.jackdrc file: it contains the exact
and complete jackd command line that should get auto-started.
qjackctl can write to that file for you, meaning next time jackd gets
auto-started by any other application it gets started with the very same
options as last time set in qjackctl.
otoh, ardour does almost the same but in advance: when jackd is not
found currently running you're presented with the jack settings on the
session open dialog, which then will take effect in ~/.jackdrc and thus
to jackd when it gets immediately auto-started by ardour itself.
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
18 May
18 May
6:05 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
"MarcO'Chapeau" <marco(a)marcochapeau.org> writes:
ATM headless and multiserver setups are not covered by jackdbus. This
*can* be fixed with dbus model.
Packagers tha have made the packages should have read this before
enabling dbus:
http://trac.jackaudio.org/wiki/JackDbusPackaging
Maybe they did. I dont see why you Fons are attacking jackdbus because of
packaging not matching your needs.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
On Sun, 17 May 2009 13:11:23 +0200, Fons Adriaensen
<fons(a)kokkinizita.net>
wrote:
All features that jackdbus offers can be added without dbus. Using dbus
was and still is the best way. It will be the best until there is better
reusable model invented. Or if someone donates (development time) to
implement such object model. Most important thing missing in jackd is
the log file. Then you have other missing features:
* no way several app to control single jack server. One needs to adopt it.
* no runtime discovery of jack settings
* no hierarchical settings file
* complex patchbay API that results in complicated code in patchbay apps
* multithread (for jack1 realtime too) threading model. (GUI) control
patchbay app should be allowed to be single threaded and not required
to handle graph change events in a realtime context.
The only argument pro using dbus I'v heard so
far
is that it permits run-time discovery of new backends,
internal clients and their parameters.
That's unfair. Read the archives. There are more arguments to that. Dbus assumes
there is a local login, without that
there is no session bus, and things don't work.
Most of my audio machines are headless, there is
no local login, but I still expect things to work,
and that, IMHO, is not unreasonable.
It is not unreasonable. No one said you *had* to use dbus. This needs
fixing and until it is fixed, packagers should be advised to disable dbus. 
25 May
25 May
1:54 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, 2009-05-17 at 13:11 +0200, Fons Adriaensen wrote:
On Sun, May 17, 2009 at 12:20:34PM +0200,
MarcO'Chapeau wrote:
(sorry for the delay, I just got back from a couple of weeks of no
internet access).
Yes, obviously you are not installing from a "reputable" distro. Sigh. I
shall rebuild and disable dbus, I thought at the time I built 1.9.2 it
would be an interesting option and did not realize all the problems it
could/would cause. Argh/sorry.
I have at the moment still 314 (pi??) more messages marked unread on the
jack list folder in my mail client so most probably this has been hashed
to death already...
Is there a way to disable the dbus functionality if jackmp is compiled
with it? ("jack_control exit"?) I'm far from understanding the whole
thing in detail...
-- Fernando
- dbus is not the default compile time config
option. Your distro should
probably disable it (until it's stable and shiny)
On this I agree. - When dbus is
active, it is indeed not backwards compatible with the
legacy autostart feature... I agree it might need fixing
Very very nice. Good luck with it.
- The behavior you describe with ports is indeed
a bug and needs fixing
Seems to be qjackctl-0.3.4. Until this is fixed it is completely
useless for me.
And for the record, "fixing a mess"
doesn't always need to be "deleting all
the features that might create it".
Depends on what these features are supposed to add.
The only argument pro using dbus I'v heard so far
is that it permits run-time discovery of new backends,
internal clients and their parameters.
If it were true, it's a very weak argument. We
do have new backends every day do we ? The last
one added I know of was more than two years ago.
But it is bogus. The dbus server uses the existing
control interface and it can't provide any info
that can't be obtained there directly and with
much less hassle.
To get backend parameters, you can also just dlopen
the backend.so and read them directly - there's a
function for this, used by jackd for its help, and
also by the control interface.
Given the name of the backend it takes 10 lines
of code to do this, which is 3 orders of magnitude
less than all the dbus stuff required at both ends.
Dbus assumes there is a local login, without that
there is no session bus, and things don't work.
Most of my audio machines are headless, there is
no local login, but I still expect things to work,
and that, IMHO, is not unreasonable.
If it doesn't add any functionality that can be
provided in simpler ways, and if it doesn't work
in some perfectly legal use cases, there is no
reason for having it.
Ciao,
17 May
17 May
8:26 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fons Adriaensen schrieb:
On Sun, May 17, 2009 at 09:50:55AM +0200,
MarcO'Chapeau wrote:
Relax man.
Seems to be a problem of your distribution, compiled everything in the
package and don't let you choose.
Contact the distributors of that package for help.
If you're fed up with these binary distribution issues switch to a
source based distribution like gentoo.
On Sun, 17 May 2009 00:31:41 +0200, Fons
Adriaensen <fons(a)kokkinizita.net>
wrote:
Compile time ? I'm a simple user installing things from
a reputable distro.
A request to the jackdmp and qjackctl devs:
PLEASE REMOVE THAT DBUS MADNESS
Hi Fons,
As long as there's a compile time switch, I don't see how dbus could ever
be a problem for those who don't want to use it... and for those who do, I can tell you it works
pretty well.
Are you serious ?
When jackd is autostarted by an app (with the wrong
settings, a separate problem), it creates a dbus daemon
that seems to prevent qjackctl to start jackd with
the right settings. The result is a jackd that does
not any way correspond the the setup in qjackctl, and
there is no way to escape from this, except by manually
killing the daemon. Do you call that 'working pretty
well' ?
When qjackctl starts displaying ports that don't
exist anymore and does not display those that
do exist (no problem with jack-0.116.1) do you
call that 'working pretty well' ?
I'd call it completely broken.
Ciao,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoP17QACgkQVC26eJ+o0+2vAQCgi6xq/wYnoBigsbeC4kIJvb9v
tXQAnRt33GpIv1hoITwSsEm/NO3JN0E9
=jKpc
-----END PGP SIGNATURE-----
1:34 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sunday 17 May 2009 05:24:04 Christian wrote:
Fons Adriaensen schrieb:
I think he wants to know why he has to. Why must this be a compile time option
and not run time configurable?
all the best,
drew
On Sun, May 17, 2009 at 09:50:55AM +0200,
MarcO'Chapeau wrote:
Relax man.
Seems to be a problem of your distribution, compiled everything in the
package and don't let you choose.
Contact the distributors of that package for help.
If you're fed up with these binary distribution issues switch to a
source based distribution like gentoo. On Sun, 17 May 2009 00:31:41 +0200, Fons
Adriaensen
<fons(a)kokkinizita.net>
wrote:
Compile time ? I'm a simple user installing things from
a reputable distro.
A request to the jackdmp and qjackctl devs:
PLEASE REMOVE THAT DBUS MADNESS
Hi Fons,
As long as there's a compile time switch, I don't see how dbus could
ever be a problem for those who don't want to use it... and for those who do, I can tell you it works
pretty well.
Are you serious ?
When jackd is autostarted by an app (with the wrong
settings, a separate problem), it creates a dbus daemon
that seems to prevent qjackctl to start jackd with
the right settings. The result is a jackd that does
not any way correspond the the setup in qjackctl, and
there is no way to escape from this, except by manually
killing the daemon. Do you call that 'working pretty
well' ?
When qjackctl starts displaying ports that don't
exist anymore and does not display those that
do exist (no problem with jack-0.116.1) do you
call that 'working pretty well' ?
I'd call it completely broken.
Ciao,
1:46 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
drew Roberts schrieb:
On Sunday 17 May 2009 05:24:04 Christian wrote:
Uh right, didn't think of it that way.
Fons Adriaensen schrieb:
I think he wants to know why he has to. Why must this be a compile time option
and not run time configurable?
all the best,
drew
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
On Sun, May 17, 2009 at 09:50:55AM +0200,
MarcO'Chapeau wrote:
Relax man.
Seems to be a problem of your distribution, compiled everything in the
package and don't let you choose.
Contact the distributors of that package for help.
If you're fed up with these binary distribution issues switch to a
source based distribution like gentoo. On Sun, 17 May 2009 00:31:41 +0200, Fons
Adriaensen
<fons(a)kokkinizita.net>
wrote:
> A request to the jackdmp and qjackctl devs:
>
> PLEASE REMOVE THAT DBUS MADNESS
Hi Fons,
As long as there's a compile time switch, I don't see how dbus could
ever be a problem for those who don't want to use it...
Compile time ? I'm
a simple user installing things from
a reputable distro.
and for those who do, I can tell you it works
pretty well.
Are you serious ?
When jackd is autostarted by an app (with the wrong
settings, a separate problem), it creates a dbus daemon
that seems to prevent qjackctl to start jackd with
the right settings. The result is a jackd that does
not any way correspond the the setup in qjackctl, and
there is no way to escape from this, except by manually
killing the daemon. Do you call that 'working pretty
well' ?
When qjackctl starts displaying ports that don't
exist anymore and does not display those that
do exist (no problem with jack-0.116.1) do you
call that 'working pretty well' ?
I'd call it completely broken.
Ciao, -----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoQIu8ACgkQVC26eJ+o0+3N5wCfVdJPb4PnKbDOFc2XUBjL39Jy
RhYAoJ/lBBxD65VTxu92pFZmZJ0X0HPP
=e6HK
-----END PGP SIGNATURE-----
5460
days inactive
5468
days old
linux-audio-dev@lists.linuxaudio.org
98 comments
20 participants
participants (20)
-
alex stone -
Arnold Krille -
Bob Ham -
Christian -
drew Roberts -
Fernando Lopez-Lezcano -
Fons Adriaensen -
Gabriel M. Beddingfield -
hollunder＠gmx.at -
Jan Weil -
Krzysztof Foltman -
MarcO'Chapeau -
Nedko Arnaudov -
Patrick Shirkey -
Paul Davis -
Ralf Mardorf -
Rui Nuno Capela -
Sampo Savolainen -
Stéphane Letz -
torbenh＠gmx.de