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
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.
12:58 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, 17 May 2009, Rui Nuno Capela wrote:
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...
Newbie question: Is it harmful to have QJackctl and Ardour both running
at the same time? Do they have to potential to fight eachother, or to
make changes to the Jack environment that will be made by one but not
realized by the other, either in regard to jackd parameters, or in
regard to the connection patchbays?
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
1:38 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, 17 May 2009 09:58:47 -0500 (CDT)
Brent Busby <brent(a)keycorner.org> wrote:
Newbie question: Is it harmful to have QJackctl and
Ardour both running
at the same time? Do they have to potential to fight eachother, or to
make changes to the Jack environment that will be made by one but not
realized by the other, either in regard to jackd parameters, or in
regard to the connection patchbays?
I always start jack with qjackctl when I'm running ardour. When ardour
sees the running instance of jack, it uses it. Perhaps that behavior
could be changed, but it's just how I want it.
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
1:38 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, May 17, 2009 at 10:58 AM, Brent Busby <brent(a)keycorner.org> wrote:
Newbie question: Is it harmful to have QJackctl and Ardour both running
at the same time? Do they have to potential to fight eachother, or to
make changes to the Jack environment that will be made by one but not
realized by the other, either in regard to jackd parameters, or in
regard to the connection patchbays?
There is no harm whatsoever. Ardour will write, and QJackctl can
write, ~/.jackdrc so that auto-started JACK servers will be created
with the same parameters as "last time". But if JACK is already
running, Ardour does nothing like this, and ditto for QJackctl. As Rui
has pointed out, its even an option whether or not QJackctl writes
this file at all.
18 May
18 May
8:41 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
Paul Davis <paul(a)linuxaudiosystems.com> writes:
On Sun, May 17, 2009 at 10:58 AM, Brent Busby
<brent(a)keycorner.org> wrote:
Having two writters to single file without protection (serialization) is
call for trouble. I wouldnt call this harmless. Yes, I know probablity
is very low. Still it is posible. Also AFAIK qjackctl uses different
configuration file and just can export to ~/.jackdrc
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Newbie question: Is it harmful to have QJackctl and Ardour both running
at the same time? Do they have to potential to fight eachother, or to
make changes to the Jack environment that will be made by one but not
realized by the other, either in regard to jackd parameters, or in
regard to the connection patchbays?
There is no harm whatsoever. Ardour will write, and QJackctl can
write, ~/.jackdrc so that auto-started JACK servers will be created
with the same parameters as "last time". But if JACK is already
running, Ardour does nothing like this, and ditto for QJackctl. As Rui
has pointed out, its even an option whether or not QJackctl writes
this file at all.
17 May
17 May
2:19 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
Brent Busby wrote:
On Sun, 17 May 2009, Rui Nuno Capela wrote:
not at all. ardour and qjackctl can coexist peacefully as ever.
the original issue on debate, as brought by Fons, was due to a probable
mishap caused by the new d-bus stuff in jack2 (aka jackdmp): apparently,
jackdbus is auto-starting the jackd service without regard to what's in
~/.jackdrc. it doesn't matter whomever wrote that file in the first
place, either ardour, qjackctl or even jackd itself. jackdbus is just
making a fool out of it :)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
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...
Newbie question: Is it harmful to have QJackctl and Ardour both running
at the same time? Do they have to potential to fight eachother, or to
make changes to the Jack environment that will be made by one but not
realized by the other, either in regard to jackd parameters, or in
regard to the connection patchbays?
3:08 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, May 17, 2009 at 05:19:21PM +0100, Rui Nuno Capela wrote:
the original issue on debate, as brought by Fons, was
due to a probable
mishap caused by the new d-bus stuff in jack2 (aka jackdmp): apparently,
jackdbus is auto-starting the jackd service without regard to what's in
~/.jackdrc. it doesn't matter whomever wrote that file in the first
place, either ardour, qjackctl or even jackd itself. jackdbus is just
making a fool out of it :)
That would be a minor sin compared to what actually
happens. Even if the autostarted jack is terminated
as soon as the app that started it terminates, it
comes back as soon as qjackctl is started. It is
impossible then impossible to start the right jackd
from qjackctl.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
3:37 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
Fons Adriaensen wrote:
On Sun, May 17, 2009 at 05:19:21PM +0100, Rui Nuno
Capela wrote:
can you explain a bit what is supposed to be "the right jackd"?
afaict, qjackctl starts jackd with the exact argument parameters as
given in its setup dialog, no more, no less, no guessing. you can check
that on the messages window, the exact jackd command line that qjackctl
invokes.
if that happen not to be "the right jackd" then there's something going
hideously wrong from inside jackd code path, as it probably is ignoring
or overriding its own command line arguments.
seeya
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
the original issue on debate, as brought by Fons,
was due to a probable
mishap caused by the new d-bus stuff in jack2 (aka jackdmp): apparently,
jackdbus is auto-starting the jackd service without regard to what's in
~/.jackdrc. it doesn't matter whomever wrote that file in the first
place, either ardour, qjackctl or even jackd itself. jackdbus is just
making a fool out of it :)
That would be a minor sin compared to what actually
happens. Even if the autostarted jack is terminated
as soon as the app that started it terminates, it
comes back as soon as qjackctl is started. It is
impossible then impossible to start the right jackd
from qjackctl.
4:23 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, May 17, 2009 at 10:37 AM, Rui Nuno Capela <rncbc(a)rncbc.org> wrote:
Fons Adriaensen wrote:
I wonder if there are two copies of Jack on the system, sort of a
/usr/bin and a /usr/local/bin. I've had that happena few times when I
forgot to explicitly set a path building code by hand.
I agree with Rui's comments. If Jack is set up correctly on my system
I've never had qjackctl do anything other than use what I put in the
settings box and show it to me in the message window.
On Sun, May 17, 2009 at 05:19:21PM +0100, Rui
Nuno Capela wrote:
can you explain a bit what is supposed to be "the right jackd"?
afaict, qjackctl starts jackd with the exact argument parameters as
given in its setup dialog, no more, no less, no guessing. you can check
that on the messages window, the exact jackd command line that qjackctl
invokes.
if that happen not to be "the right jackd" then there's something going
hideously wrong from inside jackd code path, as it probably is ignoring
or overriding its own command line arguments.
seeya
-- the original issue on debate, as brought by Fons,
was due to a probable
mishap caused by the new d-bus stuff in jack2 (aka jackdmp): apparently,
jackdbus is auto-starting the jackd service without regard to what's in
~/.jackdrc. it doesn't matter whomever wrote that file in the first
place, either ardour, qjackctl or even jackd itself. jackdbus is just
making a fool out of it :)
That would be a minor sin compared to what actually
happens. Even if the autostarted jack is terminated
as soon as the app that started it terminates, it
comes back as soon as qjackctl is started. It is
impossible then impossible to start the right jackd
from qjackctl.
10:34 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, May 17, 2009 at 11:23:32AM -0700, Mark Knecht wrote:
I wonder if there are two copies of Jack on the
system, sort of a
/usr/bin and a /usr/local/bin. I've had that happena few times when I
forgot to explicitly set a path building code by hand.
Up to two hours ago no Jack had ever been compiled
on this system which is quite recent. It just had a
binary install of jackdmp 1.9.2 and qjackctl 0.3.4.
I agree with Rui's comments. If Jack is set up
correctly on my system
I've never had qjackctl do anything other than use what I put in the
settings box and show it to me in the message window.
It's probably not qjackctl doing something wrong,
but rather the dbus daemon left behind by a previous
server preventing qjackctl to do the right thing -
start a server using the configuration defined in
its Setup window. The previous server restarts as
soon as qjackctl is started, it just doesn't get
a chance to configure anything else.
Two remarks:
1. The whole idea of using daemons to provide
'persistence' is fundamentally wrong. If I want
something to be persistent I will configure it,
and that configuration should be just **data**
in a file. Allowing daemons to take that role
is as stupid as accepting executable content
in mail.
2. If autostart is to be useful it should at
least be possible to configure the server that
gets autostarted. This seems to be impossible.
The obvious place to put such a configuration,
~/.jackdrc, is completely ignored by jackd,
despite that file's name.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
18 May
18 May
8:39 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
Fons Adriaensen <fons(a)kokkinizita.net> writes:
1. The whole idea of using daemons to provide
'persistence' is fundamentally wrong. If I want
something to be persistent I will configure it,
and that configuration should be just **data**
in a file. Allowing daemons to take that role
is as stupid as accepting executable content
in mail.
jackd autolanched by libjack is not less a daemon. It is detached. Only
you miss the log file. I.e. if jack server is autostarted by launching
jackd when jack application is started you get no feedback from jack
server unless you start all applications from commandline so you can see
the stdout. I thing this is fundamentally wrong. Also fundamentally
wrong is to reinvent the wheel (dbus in this case).
2. If autostart is to be useful it should at
least be possible to configure the server that
gets autostarted. This seems to be impossible.
The obvious place to put such a configuration,
~/.jackdrc, is completely ignored by jackd,
despite that file's name.
jackd parameters are read by libjack when jackd is launched.
So do you want want jackd to read settings or not? Are you opposed just
to jackd writting the settings file not to reading it?
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
10:12 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Monday 18 May 2009 06:38:31 Nedko Arnaudov wrote:
I think what Fons is saying is that these parameters are not being read. (I
could be wrong here though. I have tried to pay fairly close attention all
this time though.)
The obvious
place to put such a configuration,
~/.jackdrc, is completely ignored by jackd,
despite that file's name.
jackd parameters are read by libjack when jackd is launched.
So do you want want jackd to read settings or not? Are you opposed just
to jackd writting the settings file not to reading it?
all the best,
drew
17 May
17 May
9:59 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, May 17, 2009 at 06:37:27PM +0100, Rui Nuno Capela wrote:
can you explain a bit what is supposed to be "the
right jackd"?
OK. The 'right' one is the one that qjackctl is configured
for, also the one specified in ~/jackdrc. It uses the
Terratec EWT88 card which is hw:1.
The 'wrong' one is using the on-board Intel stuff which
is hw:0.
1. I accidentally start a jackified app without a server
running. This autostarts the wrong jackd. Jackd seems to
ignore ~/.jackdrc.
2. No problem, this jackd had the -T option, when I stop
the application then the jackd is gone as well.
Without dbus all is ok afterwards. But with dbus:
3. I start qjackctl. It immediately shows a running
jackd (** there was none before, so running qjackctl
started it **). This jackd is the 'wrong' one.
4. Stopping and starting in qjackctl does not help,
this always starts the 'wrong' one. Qjackctl's setup
window still shows the 'right' one, but all settings
there are ignored.
5. So it's now impossible to start the 'right' one
from qjackctl. To revert to normal you have to kill
a daemon created by the dbus stuff.
afaict, qjackctl starts jackd with the exact argument
parameters as
given in its setup dialog, no more, no less, no guessing.
Not is this case.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
10:27 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, May 17, 2009 at 4:50 PM, Fons Adriaensen <fons(a)kokkinizita.net> wrote:
On Sun, May 17, 2009 at 06:37:27PM +0100, Rui Nuno
Capela wrote:
<SNIP>
4. Stopping and starting in qjackctl does not help,
this always starts the 'wrong' one. Qjackctl's setup
window still shows the 'right' one, but all settings
there are ignored.
5. So it's now impossible to start the 'right' one
from qjackctl. To revert to normal you have to kill
a daemon created by the dbus stuff.
Are you setting the Interface box to hw:1,0? I do that for my system
and QJackCtl always starts on the right device, my HDSP 9652, and not
the on-board nvidia chip.
I've not paid much attention to the details but Geoff Beasly once told
me to get rid of the dbus stuff completely as it didn't work well with
Jack so I've tended to stay away from it. I have dbus turned off in my
use flags and don't start it at boot time.
- Mark
18 May
18 May
6:06 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Mon, May 18, 2009 00:50, Fons Adriaensen wrote:
On Sun, May 17, 2009 at 06:37:27PM +0100, Rui Nuno
Capela wrote:
fwiw, qjackctl calls jack_client_open() with the *JackNoStartServer*
option flag set.
iow, qjackctl should never invoke the jackd auto-start feature. if it ever
starts jackd, it starts explicitly with its own fork+exec method (ie.
QProcess::start()).
so, and i'm just guessing, it is the jackdbus devil stack that is pushing
the jackd auto-starting into our throats, with complete disrespect with
what's in the official jack api (i supect it doesn't give a damn to a
legitimate JackNoStartServer option:).
byee
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
can you explain a bit what is supposed to be
"the right jackd"?
OK. The 'right' one is the one that qjackctl is configured
for, also the one specified in ~/jackdrc. It uses the Terratec EWT88 card
which is hw:1.
The 'wrong' one is using the on-board Intel stuff which
is hw:0.
1. I accidentally start a jackified app without a server
running. This autostarts the wrong jackd. Jackd seems to ignore ~/.jackdrc.
2. No problem, this jackd had the -T option, when I stop
the application then the jackd is gone as well.
Without dbus all is ok afterwards. But with dbus:
3. I start qjackctl. It immediately shows a running
jackd (** there was none before, so running qjackctl started it **). This
jackd is the 'wrong' one.
4. Stopping and starting in qjackctl does not help,
this always starts the 'wrong' one. Qjackctl's setup window still shows the
'right' one, but all settings
there are ignored.
5. So it's now impossible to start the 'right' one
from qjackctl. To revert to normal you have to kill a daemon created by the
dbus stuff.
afaict, qjackctl starts jackd with the exact
argument parameters as
given in its setup dialog, no more, no less, no guessing.
Not is this case.
8:45 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
"Rui Nuno Capela" <rncbc(a)rncbc.org> writes:
so, and i'm just guessing, it is the jackdbus
devil stack that is pushing
the jackd auto-starting into our throats, with complete disrespect with
what's in the official jack api (i supect it doesn't give a damn to a
legitimate JackNoStartServer option:).
No, it is FUD campaign in lau ml :(
The official jack api is respected and it the JackNoStartServer option
IS respected.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
10:17 a.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Monday 18 May 2009 06:44:45 Nedko Arnaudov wrote:
No, it is FUD campaign in lau ml :(
The official jack api is respected and it the JackNoStartServer option
IS respected.
OK, so how do we explain the behavior that Fons is seeing.
No jack is running.
He starts qjackctl.
qjackctl shows a jack is running once it is started.
the jack that qjackctl finds started is not the one it is configured to start.
(Is this about right for the one problem you described Fons?)
all the best,
drew
12:24 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
drew Roberts <zotz(a)100jamz.com> writes:
On Monday 18 May 2009 06:44:45 Nedko Arnaudov wrote:
Packaging not suited to user's needs. I explain it like this. Also
packagers are not given enough warnings about the problems. Both
problems are fixed in svn and thus in next jack2 release.
No, it is FUD campaign in lau ml :(
The official jack api is respected and it the JackNoStartServer option
IS respected.
OK, so how do we explain the behavior that Fons is seeing. No jack is running.
He starts qjackctl.
qjackctl shows a jack is running once it is started.
That means jack server is running. It may have been started through dbus
or through qjackctl (i think it has that option - autostart jack on
launch).
the jack that qjackctl finds started is not the one it
is configured to start.
The the server was started through dbus mechanism. This is caused by
mixing the two models. OTOH you dont get messages in qjackctl when jackd
is autolaunched by an application. Once again, package needs to be fixed
and there is fix in the svn that should make it harder for packagers to
do this error.
(Is this about right for the one problem you described
Fons?)
I'm still not completely sure what proble Fons has. Except ban dbus
statement.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
7:12 a.m.
New subject: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)
On Mon, 18 May 2009 01:50:45 +0200, Fons Adriaensen <fons(a)kokkinizita.net>
wrote:
Hi,
Let's try to find an acceptable workaround until this is all sorted out.
1. I accidentally start a jackified app without a
server
running. This autostarts the wrong jackd. Jackd seems to
ignore ~/.jackdrc.
2. No problem, this jackd had the -T option, when I stop
the application then the jackd is gone as well.
Without dbus all is ok afterwards. But with dbus:
3. I start qjackctl. It immediately shows a running
jackd (** there was none before, so running qjackctl
started it **). This jackd is the 'wrong' one.
Very strange indeed... I'll test that.
4. Stopping and starting in qjackctl does not help,
this always starts the 'wrong' one. Qjackctl's setup
window still shows the 'right' one, but all settings
there are ignored.
5. So it's now impossible to start the 'right' one
from qjackctl. To revert to normal you have to kill
a daemon created by the dbus stuff.
There's something you could try. In qjackctl there's a way to launch some
commands prior to jack startup. Could you try to add "jack_control stop" to
it ? This should stop any running server started in the jackdbus way. Be
aware though that the jackdbus process will remain even if the jack server
is
stopped. If you want the jackdbus to exit cleanly, you can add
"jack_control exit" to the other command. This should also work for what
you do in (5.) and is more convenient than a kill -9.
Of course, you also need to be aware that jack_control will use the dbus
interface to send those calls to jackdbus... It might as well eat your
babies :)
Cheers,
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
11:01 a.m.
New subject: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)
Marc,
I'd be interested in hearing about your results on this little test.
I tried it, as you've suggested, and it worked initially. But as you
rightly say, the dbus daemon is used, and this brought up another
challenge. When the system is rebooted, the dbus tries to assume
priority, and i found jack was already started when i tried to open an
instance of jack, so we're already facing a challenge just to get
warmed up.
After inserting the command, it worked the first time, but subsequent
command calls didn't when restarting Qjackctl, even though the
jack_control command was still present in Qjackctl setup as a command
to be run before jack startup. On the contrary, jack tried to start
but got shutdown almost immediately, and i had to remove the command,
and run jack_control stop several times before the server finally laid
down and died. (A Linux Warrior to the last. Make sure your enemy is
truly out of the picture.)
I've STILL yet to hear an answer to my question though.
Will the Jack team be continuing a completely non-dbus/pulse build for
those who want more control over their audio environments, or are we
to be enslaved to this new lack of choice for all eternity? (I'm sure
the armour's going to get rusty before then.)
What disturbs me more than anything about this is the seemingly
enthusiastic freefall into a hybrid that seems to cater almost
exclusively to a particular distro type, that of package install.
I finally got enough smarts together, and installed Gentoo and Fluxbox
as a working audio/midi environment for writing music, and i'd hate to
think i'm still to be 'forced' to adopt a dbus/pulse baby eating
hybrid, because Johnny Air Guitar wants to listen to pistols and
flowers in a non jack server written app, while he's plagarising
guitar licks. I'm using Jack1 now, the non infant muncher version, so
i've escaped much of Fon's angst, but i'm still wondering what the
jackserver future holds, given the current, what seems, relentless
determination on the part of enthusiastic jack devs to 'persuade' us
into the alternative.
Humour to the fore as usual in these challenging times, but also an
increasingly unsettled perspective on what seems like capable and
skilled people trying to featurise something that isn't broken at all,
to cater for devs and distros that choose to use yet another
soundserver, instead of actively contributing to the fine server we
already have.
surely the old adage still hold true in this case.
"If it ain't broke..."
Alex.
p.s. what does pulse/dbus do, that Jack can't, if the same relentless
effort being put into the dbus/pulse hybrid, were put into maturing
Jack even further? And what of the devs who refuse, are reluctant to,
or don't see the advantages in writing Jack audio code, and plugins
for their apps? I still don't understand how writing a pulse plugin is
any harder than writing a jack audio plugin, or code.
On Mon, May 18, 2009 at 1:12 PM, MarcO'Chapeau <marco(a)marcochapeau.org> wrote:
On Mon, 18 May 2009 01:50:45 +0200, Fons Adriaensen
<fons(a)kokkinizita.net>
wrote:
Hi,
Let's try to find an acceptable workaround until this is all sorted out.
--
Parchment Studios (It started as a joke...)
1. I accidentally start a jackified app without a
server
running. This autostarts the wrong jackd. Jackd seems to
ignore ~/.jackdrc.
2. No problem, this jackd had the -T option, when I stop
the application then the jackd is gone as well.
Without dbus all is ok afterwards. But with dbus:
3. I start qjackctl. It immediately shows a running
jackd (** there was none before, so running qjackctl
started it **). This jackd is the 'wrong' one.
Very strange indeed... I'll test that.
4. Stopping and starting in qjackctl does not
help,
this always starts the 'wrong' one. Qjackctl's setup
window still shows the 'right' one, but all settings
there are ignored.
5. So it's now impossible to start the 'right' one
from qjackctl. To revert to normal you have to kill
a daemon created by the dbus stuff.
There's something you could try. In qjackctl there's a way to launch some
commands prior to jack startup. Could you try to add "jack_control stop" to
it ? This should stop any running server started in the jackdbus way. Be
aware though that the jackdbus process will remain even if the jack server
is
stopped. If you want the jackdbus to exit cleanly, you can add
"jack_control exit" to the other command. This should also work for what
you do in (5.) and is more convenient than a kill -9.
Of course, you also need to be aware that jack_control will use the dbus
interface to send those calls to jackdbus... It might as well eat your
babies :)
Cheers,
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
11:28 a.m.
New subject: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)
On Mon, 18 May 2009 17:01:27 +0400, alex stone <compose59(a)gmail.com> wrote:
Marc,
I'd be interested in hearing about your results on this little test.
I tried it, as you've suggested, and it worked initially. But as you
rightly say, the dbus daemon is used, and this brought up another
challenge. When the system is rebooted, the dbus tries to assume
priority, and i found jack was already started when i tried to open an
instance of jack, so we're already facing a challenge just to get
warmed up.
After inserting the command, it worked the first time, but subsequent
command calls didn't when restarting Qjackctl, even though the
jack_control command was still present in Qjackctl setup as a command
to be run before jack startup. On the contrary, jack tried to start
but got shutdown almost immediately, and i had to remove the command,
and run jack_control stop several times before the server finally laid
down and died. (A Linux Warrior to the last. Make sure your enemy is
truly out of the picture.)
I admit it was just a blind guess. I need to test this myself and I won't
be available till tomorrow... I'll keep you posted. And again, that would
probably be just a workaround, not a long term solution.
I've STILL yet to hear an answer to my question
though.
Will the Jack team be continuing a completely non-dbus/pulse build for
those who want more control over their audio environments, or are we
to be enslaved to this new lack of choice for all eternity? (I'm sure
the armour's going to get rusty before then.)
Answer will be another question: who's talking about pulse ?
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
11:36 a.m.
New subject: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)
Marc,
hehe, and the waltz continues. So let's assume that pulse isn't being
considered here as part of the dbus paradigm intent .
Is there going to be a non dbus jack version going forward? And please
assume here i'm talking about a complete non dbus version, not a
compile time option to disable it.
Alex.
On Mon, May 18, 2009 at 5:28 PM, MarcO'Chapeau <marco(a)marcochapeau.org> wrote:
On Mon, 18 May 2009 17:01:27 +0400, alex stone
<compose59(a)gmail.com> wrote:
--
Parchment Studios (It started as a joke...)
Marc,
I'd be interested in hearing about your results on this little test.
I tried it, as you've suggested, and it worked initially. But as you
rightly say, the dbus daemon is used, and this brought up another
challenge. When the system is rebooted, the dbus tries to assume
priority, and i found jack was already started when i tried to open an
instance of jack, so we're already facing a challenge just to get
warmed up.
After inserting the command, it worked the first time, but subsequent
command calls didn't when restarting Qjackctl, even though the
jack_control command was still present in Qjackctl setup as a command
to be run before jack startup. On the contrary, jack tried to start
but got shutdown almost immediately, and i had to remove the command,
and run jack_control stop several times before the server finally laid
down and died. (A Linux Warrior to the last. Make sure your enemy is
truly out of the picture.)
I admit it was just a blind guess. I need to test this myself and I won't
be available till tomorrow... I'll keep you posted. And again, that would
probably be just a workaround, not a long term solution.
I've STILL yet to hear an answer to my
question though.
Will the Jack team be continuing a completely non-dbus/pulse build for
those who want more control over their audio environments, or are we
to be enslaved to this new lack of choice for all eternity? (I'm sure
the armour's going to get rusty before then.)
Answer will be another question: who's talking about pulse ?
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
12:25 p.m.
New subject: What are we talking about. (Was: KILL DBUS)
On Mon, 18 May 2009 17:36:11 +0400, alex stone <compose59(a)gmail.com> wrote:
Marc,
hehe, and the waltz continues. So let's assume that pulse isn't being
considered here as part of the dbus paradigm intent .
Hi again.
Ok, let's stop dancing then :) Let me try to explain that dbus here is not
the center of what has changed in JACK2.
The new feature in JACK2 is the control API. That is: a *C control API*.
Now it is very important to read the previous sentence over and over again.
Once the dbus keyword has disappeared of your focus, read on.
So, this C/C++ control API allows one to start/stop jack, configure it, and
manage connections in between clients. This C control API allows one to
control the server entirely in a cleaner fashion than what was used before.
jackd makes use of this new API.
And now the fun part. Say we want to control JACK with hmm... OSC. One will
program something called jackosc that will *expose* the jack control API
through a small OSC server. it's as simple as some python bindings for
instance.
Now that I have explained most of the new stuff in JACK2, back to our
issue. jackdbus is just like what I described with jackosc, except that
instead of *exposing the C API* through an OSC interface, we do that
through a DBUS interface.
Is there going to be a non dbus jack version going
forward?
You should already have the answer : there is and there will always be.
The
JACK control API is the core and is C, dbus is just an interface, just like
any other kind of interface would be (OSC, HTTP, whatever...).
And please assume here i'm talking about a
complete
non dbus version, not a compile time option to disable it.
So you want to have 2
separate versions maintained ? One with a control API
and no interfaces other than plain C and one with interfaces included ?
Because if it's not a compile time option, I don't see what else it could
be.
Who wants to maintain to trees just to hide a compile time option ? what if
we really add jackosc to the list ? Should that be a third tree ?
Nedko, Stéphane: If I made any mistakes in my explanations, please correct
me :)
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
12:35 p.m.
New subject: [Jack-Devel] What are we talking about. (Was: KILL DBUS)
On Mon, May 18, 2009 at 10:25 AM, MarcO'Chapeau <marco(a)marcochapeau.org> wrote:
On Mon, 18 May 2009 17:36:11 +0400, alex stone
<compose59(a)gmail.com> wrote:
i'm just going to trying to summarize even more from what Marc has
said. There are two issues that have become tangled up in this recent
email flurry.
1) the current D-Bus support can be mishandled by packagers and this
can lead to problems for some users
2) the only actual implementation that uses the control API is based
on D-Bus, and this is not a source of happiness and cake for everyone.
There is nothing stopping other implementations (pure C, OSC, python
etc) using the control API, but at this time, nothing else does.
Stephane has attempted to correct problem (1) in svn with warnings
etc. to packagers.
--p
Marc,
hehe, and the waltz continues. So let's assume that pulse isn't being
considered here as part of the dbus paradigm intent .
Hi again.
Ok, let's stop dancing then :) Let me try to explain that dbus here is not
the center of what has changed in JACK2.
12:51 p.m.
New subject: [Jack-Devel] What are we talking about. (Was: KILL DBUS)
Le 18 mai 09 à 16:35, Paul Davis a écrit :
On Mon, May 18, 2009 at 10:25 AM, MarcO'Chapeau
<marco(a)marcochapeau.org
Some more words about that:
JACK2 SVN makes now clear what can be built:
- "classic" JACK : this target compiles the "jackd" executable. This
exe behaves exactly as JACK1 is behaving (beside possible bugs). This
target is the *default* one (that is the one resulting from "./waf
configure). This version is meant to be used with usual tools
Qjackctl, Ardour... (to start the server)... and so on.
- D-Bus JACK: this target compiles the "jackdbus" executable *only*
(that is the "jackd" is not compiled anymore). This target is obtained
using --dbus at configure time. This version is meant to be controled
with D-Bus based control applications (Nedko please clarify this
point...)
- both targets can be mixed but a WARNING is issued at configure time;
that is "./waf configure --dbus --classic" will compile both "jackd"
and "jackdbus" executable. This is to be done only by people who know
exactly what they are doing.
Packagers are then strongly recommended to prepare the "classic" or
the "D-Bus" JACK2. Dependancies have to be handled accordingly (Nedko
please clarify this point...)
The "mixed" target should *not be used* for packaging.
(see http://trac.jackaudio.org/wiki/JackDbusPackaging)
Stephane
wrote:
On Mon, 18 May 2009 17:36:11 +0400, alex stone
<compose59(a)gmail.com> wrote:
i'm just going to trying to summarize even more from what Marc has
said. There are two issues that have become tangled up in this recent
email flurry.
1) the current D-Bus support can be mishandled by packagers and this
can lead to problems for some users
2) the only actual implementation that uses the control API is based
on D-Bus, and this is not a source of happiness and cake for everyone.
There is nothing stopping other implementations (pure C, OSC, python
etc) using the control API, but at this time, nothing else does.
Stephane has attempted to correct problem (1) in svn with warnings
etc. to packagers.
--p Marc,
hehe, and the waltz continues. So let's assume that pulse isn't
being
considered here as part of the dbus paradigm intent .
Hi again.
Ok, let's stop dancing then :) Let me try to explain that dbus here
is not
the center of what has changed in JACK2.
1:22 p.m.
New subject: [Jack-Devel] What are we talking about.
Stéphane Letz <letz(a)grame.fr> writes:
Packagers are then strongly recommended to prepare the
"classic" or
the "D-Bus" JACK2. Dependancies have to be handled accordingly (Nedko
please clarify this point...)
The "mixed" target should *not be used* for packaging.
(see http://trac.jackaudio.org/wiki/JackDbusPackaging)
We have suggested packaging approach:
http://trac.jackaudio.org/wiki/SuggestedPackagingApproach
We can fix something if someone thinks it is not good.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
12:37 p.m.
New subject: What are we talking about. (Was: KILL DBUS)
Marc,
Thanks, and a great user oriented explanation.
I'm also mindful of the considerable work being done with the LADI
tools, and the testing i enjoyed doing last year.
Just to be clear here, i still can't see the need for an additional
layer of 'complication' (don't forget i'm just a user, not a coder.),
but i'll continue to be open minded about the progress. The old Jackd
is definitely my comfort zone, and it would true to say, that anything
that upsets that stability starts me asking questions.
Thanks again, i just learned something, whether i agree with it
currently, or not.
Alex.
On Mon, May 18, 2009 at 6:25 PM, MarcO'Chapeau <marco(a)marcochapeau.org> wrote:
On Mon, 18 May 2009 17:36:11 +0400, alex stone
<compose59(a)gmail.com> wrote:
--
Parchment Studios (It started as a joke...)
Marc,
hehe, and the waltz continues. So let's assume that pulse isn't being
considered here as part of the dbus paradigm intent .
Hi again.
Ok, let's stop dancing then :) Let me try to explain that dbus here is not
the center of what has changed in JACK2.
The new feature in JACK2 is the control API. That is: a *C control API*.
Now it is very important to read the previous sentence over and over again.
Once the dbus keyword has disappeared of your focus, read on.
So, this C/C++ control API allows one to start/stop jack, configure it, and
manage connections in between clients. This C control API allows one to
control the server entirely in a cleaner fashion than what was used before.
jackd makes use of this new API.
And now the fun part. Say we want to control JACK with hmm... OSC. One will
program something called jackosc that will *expose* the jack control API
through a small OSC server. it's as simple as some python bindings for
instance.
Now that I have explained most of the new stuff in JACK2, back to our
issue. jackdbus is just like what I described with jackosc, except that
instead of *exposing the C API* through an OSC interface, we do that
through a DBUS interface.
Is there going to be a non dbus jack version
going forward?
You should already have the answer : there is and there will always
be. The
JACK control API is the core and is C, dbus is just an interface, just like
any other kind of interface would be (OSC, HTTP, whatever...).
And please assume here i'm talking about a
complete
non dbus version, not a compile time option to disable it.
So you want to have 2
separate versions maintained ? One with a control API
and no interfaces other than plain C and one with interfaces included ?
Because if it's not a compile time option, I don't see what else it could
be.
Who wants to maintain to trees just to hide a compile time option ? what if
we really add jackosc to the list ? Should that be a third tree ?
Nedko, Stéphane: If I made any mistakes in my explanations, please correct
me :)
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
12:52 p.m.
New subject: [Jack-Devel] What are we talking about. (Was: KILL DBUS)
On Mon, May 18, 2009 at 04:25:23PM +0200, MarcO'Chapeau wrote:
Now that I have explained most of the new stuff in
JACK2, back to our
issue. jackdbus is just like what I described with jackosc, except that
instead of *exposing the C API* through an OSC interface, we do that
through a DBUS interface.
Apparently that is not true, the dbus layer is doing
more than just providing communication.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
1:18 p.m.
New subject: [Jack-Devel] What are we talking about.
Fons Adriaensen <fons(a)kokkinizita.net> writes:
On Mon, May 18, 2009 at 04:25:23PM +0200,
MarcO'Chapeau wrote:
It is true.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Now that I have explained most of the new stuff
in JACK2, back to our
issue. jackdbus is just like what I described with jackosc, except that
instead of *exposing the C API* through an OSC interface, we do that
through a DBUS interface.
Apparently that is not true, the dbus layer is doing
more than just providing communication.
2:04 p.m.
New subject: The simple thruth about jack-dbus
On Mon, May 18, 2009 at 06:18:06PM +0300, Nedko Arnaudov wrote:
Fons Adriaensen <fons(a)kokkinizita.net> writes:
That is a lie, and you know it.
* Jack-dbus is not just exposing the C API.
It is *not* an optional way to access the
C API as the OSC server that Marc described
would be.
* It interferes with the C API.
* It forces itself between the client and the
server, even if the client does not want to
use dbus at all, and it breaks the C API.
Otherwise tell me why running a client that
does not make a single dbus call is starting
a dbus daemon. Which then goes on to prevent
qjackctl, not using dbus, starting the server
it wants to start.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
On Mon, May 18, 2009 at 04:25:23PM +0200,
MarcO'Chapeau wrote:
It is true. Now that I have explained most of the new stuff
in JACK2, back to our
issue. jackdbus is just like what I described with jackosc, except that
instead of *exposing the C API* through an OSC interface, we do that
through a DBUS interface.
Apparently that is not true, the dbus layer is doing
more than just providing communication.
2:31 p.m.
New subject: [Jack-Devel] The simple thruth about jack-dbus
Fons Adriaensen <fons(a)kokkinizita.net> writes:
That is a lie, and you know it.
negative
* Jack-dbus is not just exposing the C API.
It is *not* an optional way to access the
C API as the OSC server that Marc described
would be.
It is exposing the C APIs (control and jack.h one). Most of them
(transport dbus interface development is halted in early stage atm).
It is *alternative* way to access it. And optional because it is enabled
optionaly at configure time. Using both interfaces can get things nasty
and this is clearly described in the packager doc available on the trac
wiki.
From http://trac.jackaudio.org/wiki/JackDbusPackaging :
D-Bus JACK and Classic JACK mixture
- If D-Bus session bus gets misconfigured/non-functional, user will get classic
auto-launching associated with:
- User is blind about what happens with JACK server execution, unless server is
manually started.
- No JACK D-Bus aware control/monitor applications can be used. They
will claim JACK server is not started (cannot be contacted) even
when JACK server is actually running and normal JACK applications
are connected and probably using it.
* It interferes with the C API.
Yes, with both C APIs (control and jack.h one)
* It forces itself between the client and the
server, even if the client does not want to
use dbus at all, and it breaks the C API.
client wants to use jack server and in jackdbus setup this is the way to
start it. The one who enabled jackdbus in this system forced jack
clients to use dbus for staring the server through the same jack.h API
as implemented in libjack.so (it is implemennted in libjackserver.so
too).
Otherwise tell me why running a client that
does not make a single dbus call is starting
a dbus daemon. Which then goes on to prevent
qjackctl, not using dbus, starting the server
it wants to start.
Because libjack.so implementation is using dbus to start the server (if
and only if dbus operation was enabled at configure stage).
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
2:46 p.m.
New subject: [Jack-Devel] The simple thruth about jack-dbus
So if I understand this correctly (and please correct me if I am wrong), we
now have a way to build jack clients which work only with dbus or with
direct access to C API? If so, what happens if an app that has been built to
work with dbus support only (is this even possible?) tries to access jackd
that has no dbus support built-in? If the app has no automatic means of
falling back to the C API access this basically makes jackd as problematic
as the early years of ALSA when apps were unable to work with it because
they only supported OSS... If so, I think this is a *really bad* move. In
addition, is "falling back" aspect of this hypothetical case something that
jack handles automagically or is this an added overhead for a programmer?
Latter, of course, would be yet another *really bad* move IMHO...
Ico
3:17 p.m.
New subject: [Jack-Devel] The simple thruth about jack-dbus
"Ivica Ico Bukvic" <ico(a)vt.edu> writes:
So if I understand this correctly (and please correct
me if I am wrong), we
now have a way to build jack clients which work only with dbus or with
direct access to C API?
We have a way to build jack clients that work over dbus, yes. But only
"control" clients. I.e. like qjackctl. You cant use dbus for audio
(buff/sample leve) stuff. D-Bus is not realtime at all. You dont need
realtime IPC for starting jack server, right? ;)
If so, what happens if an app that has been built to
work with dbus support only (is this even possible?) tries to access jackd
that has no dbus support built-in?
apps access jack server. jack server can be started by jackd or by
jackdbus. jack server is the thing that runs the drivers, that sets the
realtime threads, loads internal clients (netjack2), etc.
If the app has no automatic means of
falling back to the C API access this basically makes jackd as problematic
as the early years of ALSA when apps were unable to work with it because
they only supported OSS...
normal app does not use dbus for this at all. the same IPC between jack
client and jack server is used, regardless of jackd or jackdbus being
used. I.e you use same jack.h API for accessing both jackd and jackdbus
(server), the jack.h implementation in libjack.so is same. With one
exception, the launching of the jack server in the case when it was not
already started and when the "noautostart" option was enabled (env
variable or parameter to the function call). If libjack.so wants to
launch the jack server, it is done differently depending of whether
jackd or jackdbus model is choosen by the packager.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
4:03 p.m.
New subject: [Jack-Devel] The simple thruth about jack-dbus
On Monday 18 May 2009 13:16:53 Nedko Arnaudov wrote:
If libjack.so wants to
launch the jack server, it is done differently depending of whether
jackd or jackdbus model is choosen by the packager.
Does it *have* to be done differently?
all the best,
drew
4:47 p.m.
New subject: [Jack-Devel] The simple thruth about jack-dbus
drew Roberts <zotz(a)100jamz.com> writes:
On Monday 18 May 2009 13:16:53 Nedko Arnaudov wrote:
Yes. If jackdbus model is installed user wants dbus enabled applications
to access the jackdbus object through dbus.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
If libjack.so wants to
launch the jack server, it is done differently depending of whether
jackd or jackdbus model is choosen by the packager.
Does it *have* to be done differently?
4:56 p.m.
New subject: [Jack-Devel] The simple thruth about jack-dbus
On Monday 18 May 2009 14:47:05 Nedko Arnaudov wrote:
drew Roberts <zotz(a)100jamz.com> writes:
OK (does anyone who is not ignorant like me disagree with this or ??? - this
bit in () is here in all humility and just for completeness), and does it
*have* to *completely* ignore what is in the rc files?
all the best,
drew
On Monday 18 May 2009 13:16:53 Nedko Arnaudov
wrote:
Yes. If jackdbus model is installed user wants dbus enabled applications
to access the jackdbus object through dbus. If libjack.so wants to
launch the jack server, it is done differently depending of whether
jackd or jackdbus model is choosen by the packager.
Does it *have* to be done differently? 
7:24 p.m.
New subject: What are we talking about. (Was: KILL DBUS)
On Mon, May 18, 2009 at 3:25 PM, MarcO'Chapeau <marco(a)marcochapeau.org> wrote:
The new feature in JACK2 is the control API. That is:
a *C control API*.
Now it is very important to read the previous sentence over and over again.
Once the dbus keyword has disappeared of your focus, read on.
So, this C/C++ control API allows one to start/stop jack, configure it, and
manage connections in between clients. jackdbus [does] that
through a DBUS interface.
Thanks Marc, that was a really helpful summary.
I wasn't quite sure whether to be outraged by or indifferent to this
whole argument; now I'm _reasonably_ sure I can write it down to
technical problems rather than a big conceptual worry, and go back to
sleep instead.
Chris
19 May
19 May
4:30 p.m.
New subject: What are we talking about. (Was: KILL DBUS)
On Mon, May 18, 2009 at 10:24:45PM +0100, Chris Cannam wrote:
On Mon, May 18, 2009 at 3:25 PM, MarcO'Chapeau
<marco(a)marcochapeau.org> wrote:
So this kerfluffle is not related to clients but rather to packagers?
The control interface is available *publicly* to other clients, but JACK uses dbus
*internally* between its component parts, and thus no JACK app need use dbus if it
doesn't want to?
Seems reasonable to me. Another dependency, perhaps, but not a huge major big deal.
-ken
The new feature in JACK2 is the control API. That
is: a *C control API*.
Now it is very important to read the previous sentence over and over again.
Once the dbus keyword has disappeared of your focus, read on.
So, this C/C++ control API allows one to start/stop jack, configure it, and
manage connections in between clients. jackdbus [does] that
through a DBUS interface.
Thanks Marc, that was a really helpful summary.
I wasn't quite sure whether to be outraged by or indifferent to this
whole argument; now I'm _reasonably_ sure I can write it down to
technical problems rather than a big conceptual worry, and go back to
sleep instead.
18 May
18 May
12:37 p.m.
New subject: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)
p.s. what does pulse/dbus do, that Jack can't, if the same relentless
effort being put into the dbus/pulse hybrid, were put into maturing
Jack even further? And what of the devs who refuse, are reluctant to,
or don't see the advantages in writing Jack audio code, and plugins
for their apps? I still don't understand how writing a pulse plugin is
any harder than writing a jack audio plugin, or code.
Pulse and DBus are two completely different things....
DBus is a means for two processes to communicate with each other. It is the
standard way of communicating with running applications on GNOME and KDE 4
Desktop environments. KDE 2/3 had a different IPC mechanism which was very
similar.
Though it is typically run in a desktop environment AFAIK it is not dependent
on having a desktop. Using DBus for IPC is a bit like using XML to do your
config files... You get to do the job using standard tools and libraries and end
up maintaining less code.
It also means that users and developers now have a standardised method of
talking to your app/daemon while it is running. I am hoping this can go some
ways to providing a LASH interface that works properly.
Currently I don't see any long term downsides to using DBus as the IPC. The
short term problems is that applications like qjackctl can't yet properly
interact with a dbus based Jack and until that happens the old method should
be the one that the distros use by default.
Pulse on the other hand is a sound deamon that does seem to be taking over
things. Mostly it provides a means of using different applications together on
hardware that does not support hardware mixing. (something I would much rather
see ALSA fixed properly to do. To me it is a reasonable idea in theory but a
PITA in practice. Fortunately I have a FFADO soundcard which means that jack
is the only supported means of communicating with the hardware. Since xinelib
now supports jack - pretty much everything I want to use will work. You know
for when I want to listen to Pistols and Flowers in Amarok and plagiarise
guitar licks :p
12:46 p.m.
New subject: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)
Danni, and i'm sure you have a fine collection of headscarfs to
complete the 'picture'. :)
Thanks for the explanation about Dbus.
And for what it's worth, i think you've hit the nub of this (imho). If
app builders use jack by default, or have a jack option in audio and
midi preferences, we'd be discussing the weather instead.
Alex.
On Mon, May 18, 2009 at 6:37 PM, Danni Coy <danni.coy(a)gmail.com> wrote:
--
Parchment Studios (It started as a joke...)
p.s. what does pulse/dbus do, that Jack can't, if the same relentless
effort being put into the dbus/pulse hybrid, were put into maturing
Jack even further? And what of the devs who refuse, are reluctant to,
or don't see the advantages in writing Jack audio code, and plugins
for their apps? I still don't understand how writing a pulse plugin is
any harder than writing a jack audio plugin, or code.
Pulse and DBus are two completely different things....
DBus is a means for two processes to communicate with each other. It is the
standard way of communicating with running applications on GNOME and KDE 4
Desktop environments. KDE 2/3 had a different IPC mechanism which was very
similar.
Though it is typically run in a desktop environment AFAIK it is not dependent
on having a desktop. Using DBus for IPC is a bit like using XML to do your
config files... You get to do the job using standard tools and libraries and end
up maintaining less code.
It also means that users and developers now have a standardised method of
talking to your app/daemon while it is running. I am hoping this can go some
ways to providing a LASH interface that works properly.
Currently I don't see any long term downsides to using DBus as the IPC. The
short term problems is that applications like qjackctl can't yet properly
interact with a dbus based Jack and until that happens the old method should
be the one that the distros use by default.
Pulse on the other hand is a sound deamon that does seem to be taking over
things. Mostly it provides a means of using different applications together on
hardware that does not support hardware mixing. (something I would much rather
see ALSA fixed properly to do. To me it is a reasonable idea in theory but a
PITA in practice. Fortunately I have a FFADO soundcard which means that jack
is the only supported means of communicating with the hardware. Since xinelib
now supports jack - pretty much everything I want to use will work. You know
for when I want to listen to Pistols and Flowers in Amarok and plagiarise
guitar licks :p
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
11:09 p.m.
New subject: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)
Don't get me started about Ubuntu and jack support. It really is a second
class citizen - As it stands jack is not an officially supported package (It's
in Universe in Ubuntu speak)... Which means that if you want jack support for
any supported application you need to compile it yourself. I think a big part
of this is ignorance on the part of the packagers. I imagine that other
distros are similar.
Part of the problem is that Jack still takes considerable leg work to get up
and running properly. It's value may not be apparent to a new user and it is
different to how things are done on other platforms. Guaging from places like
the Ubuntu Forums and even things like Linux Audio Podcasts only a small
subset of users actually get a functional jackd setup working. I am not sure
how but it seems to me that the shortest path should be shortened.
On Tue, 19 May 2009 12:46:46 am alex stone wrote:
Danni, and i'm sure you have a fine collection of
headscarfs to
complete the 'picture'. :)
Thanks for the explanation about Dbus.
And for what it's worth, i think you've hit the nub of this (imho). If
app builders use jack by default, or have a jack option in audio and
midi preferences, we'd be discussing the weather instead.
Alex.
On Mon, May 18, 2009 at 6:37 PM, Danni Coy <danni.coy(a)gmail.com> wrote:
>> p.s. what does pulse/dbus do, that Jack can't, if the same relentless
>> effort being put into the dbus/pulse hybrid, were put into maturing
>> Jack even further? And what of the devs who refuse, are reluctant to,
>> or don't see the advantages in writing Jack audio code, and plugins
>> for their apps? I still don't understand how writing a pulse plugin is
>> any harder than writing a jack audio plugin, or code.
>
> Pulse and DBus are two completely different things....
>
> DBus is a means for two processes to communicate with each other. It is
> the standard way of communicating with running applications on GNOME and
> KDE 4 Desktop environments. KDE 2/3 had a different IPC mechanism which
> was very similar.
>
> Though it is typically run in a desktop environment AFAIK it is not
> dependent on having a desktop. Using DBus for IPC is a bit like using XML
> to do your config files... You get to do the job using standard tools and
> libraries and end up maintaining less code.
>
> It also means that users and developers now have a standardised method of
> talking to your app/daemon while it is running. I am hoping this can go
> some ways to providing a LASH interface that works properly.
>
> Currently I don't see any long term downsides to using DBus as the IPC.
> The short term problems is that applications like qjackctl can't yet
> properly interact with a dbus based Jack and until that happens the old
> method should be the one that the distros use by default.
>
> Pulse on the other hand is a sound deamon that does seem to be taking
> over things. Mostly it provides a means of using different applications
> together on hardware that does not support hardware mixing. (something I
> would much rather see ALSA fixed properly to do. To me it is a reasonable
> idea in theory but a PITA in practice. Fortunately I have a FFADO
> soundcard which means that jack is the only supported means of
> communicating with the hardware. Since xinelib now supports jack - pretty
> much everything I want to use will work. You know for when I want to
> listen to Pistols and Flowers in Amarok and plagiarise guitar licks :p
>
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
--
If it's worth hacking on well, it's worth hacking on for money.
19 May
19 May
12:27 a.m.
New subject: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)
On Mon, May 18, 2009 at 6:09 PM, Danni Coy <danni.coy(a)gmail.com> wrote:
I imagine that other
distros are similar.
Certainly not something like PlanetCCRMA and on Gentoo we have the
whole Pro-Audio overlay which supports all this stuff. Is your comment
more about Ubuntu proper. It cannot be about the music oriented
distros based on Ubunt, can it?
- Mark
1:15 a.m.
New subject: pulseaudio issues [was Re: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)]
Sorry, I'm hijacking this thread.
Mark Knecht wrote:
On Mon, May 18, 2009 at 6:09 PM, Danni Coy
<danni.coy(a)gmail.com> wrote:
I haven't had any problem with jackd on fedora. I haven't even seen a
jackdbus version on Fedora 10.
I have got a problem with pulseaudio and jack not playing together. More
importantly I have got a problem with pulseaudio being the default sound
server and not having automated functionality to connect with jack. If
after 10 years of running Linux audio, I have issues with getting
pulseaudio to play nicely then pulseaudio is failing to meet it's main
objective of making things easy for desktop users.
I would really like to encourage the pulseaudio people who are reading
here to make pulse gracefully and automatically cede control to jack and
then auto configure itself as a jack interface.
This feature would save alot of people alot of hassles and would go a
long way to making multimedia and audio on the desktop a going concern
out of the box.
It would also go a long way to quelling the mass of derision on the net
about the state of Linux audio. Many people refuse to acknowledge the
effort that has gone into pulseaudio and the advances that have been
made simply because pulse tries to take over the system and refuses to
get off the court when the adults are playing. Hence it is now seen as a
pita and gettign in the way by many people. This can be fixed with a
little more work.
Desktop Linux users need these features:
1: Auto detect sound card
2: Easily accessible volume controls
3: Easy to define default sound card and route audio streams
4: Easy to start mutiple multimedia apps and route the audio
5: Easy to change from being a consumer user to a professional user and
back again.
IMO 1 to 4 have been fairly well accomplished but step 5 is currently fubar.
Pulse should detect if jack has been started and cede control of the
audio device.
Pulse should allow users the option of auto switching to the jack i/os
or using a different device.
Pulse should retain these configuration settings.
Pulse should assume that when a user starts jack they want their audio
to be temporarily reconfigured and if that means routing the pulse
stream to /dev/null for a brief period then it should handle that
internally and maintain existing application streams. Once it has
successfully reconfigured to connect with jack or an alternate device it
can redirect the audio streams to the chosen output.
Patrick Shirkey
Boost Hardware Ltd
I imagine that other
distros are similar.
Certainly not something like PlanetCCRMA and on Gentoo we have the
whole Pro-Audio overlay which supports all this stuff. Is your comment
more about Ubuntu proper. It cannot be about the music oriented
distros based on Ubunt, can it?
1:23 a.m.
New subject: pulseaudio issues [was Re: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)]
On Tue, 19 May 2009 10:00:11 +0700
Patrick Shirkey <pshirkey(a)boosthardware.com> wrote:
I would really like to encourage the pulseaudio people
who are reading
here to make pulse gracefully and automatically cede control to jack and
then auto configure itself as a jack interface.
Oh merciful $deity, THIS.
Patrick, this encompasses everything that would make me go from hating
PulseAudio with the burning fury of a thousand white-hot suns to
peacefully co-existing with it. I hope someone who can make a difference
reads it.
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
1:29 a.m.
New subject: pulseaudio issues [was Re: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)]
On Mon, May 18, 2009 at 11:00 PM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
I have got a problem with pulseaudio and jack not
playing together. More
importantly I have got a problem with pulseaudio being the default sound
server and not having automated functionality to connect with jack. If
after 10 years of running Linux audio, I have issues with getting
pulseaudio to play nicely then pulseaudio is failing to meet it's main
objective of making things easy for desktop users.
I would really like to encourage the pulseaudio people who are reading
here to make pulse gracefully and automatically cede control to jack and
then auto configure itself as a jack interface.
Pulse includes "pasuspender" to handle this use case. From the man page:
pasuspender is a tool that can be used to tell a local
PulseAudio sound server to temporarily suspend access to the audio
devices, to allow other applications access them directly. pasuspender
will suspend access to the audio devices, fork a child process,
and when the child process terminates, resume access again.
I guess this should be integrated into qjackctl & friends.
Lee
1:42 a.m.
New subject: pulseaudio issues [was Re: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)]
Lee Revell wrote:
On Mon, May 18, 2009 at 11:00 PM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
I disagree. It should be up to pulse to autodetect and reconfigure
itself gracefully.
Pulse is the system that takes control and generally refuses to let go
in a graceful fashion so it should not be up to everyone else to force
it to play nicely.
Also, do you know if pasuspend can handle connecting to jack?
For example IIUC currently you need to run a seperate config file for
pulse to even try to connect to jack. So if pasuspend is used will pulse
actually connect to a jack server or will it just idle until jack is
shutdown?
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd.
I have got a problem with pulseaudio and jack not
playing together. More
importantly I have got a problem with pulseaudio being the default sound
server and not having automated functionality to connect with jack. If
after 10 years of running Linux audio, I have issues with getting
pulseaudio to play nicely then pulseaudio is failing to meet it's main
objective of making things easy for desktop users.
I would really like to encourage the pulseaudio people who are reading
here to make pulse gracefully and automatically cede control to jack and
then auto configure itself as a jack interface.
Pulse includes "pasuspender" to handle this use case. From the man page:
pasuspender is a tool that can be used to tell a local
PulseAudio sound server to temporarily suspend access to the audio
devices, to allow other applications access them directly. pasuspender
will suspend access to the audio devices, fork a child process,
and when the child process terminates, resume access again.
I guess this should be integrated into qjackctl & friends.
2:06 a.m.
New subject: pulseaudio issues [was Re: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)]
Lee Revell wrote:
On Mon, May 18, 2009 at 11:00 PM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
Further testing reveals that it's been identified as a problem for a while.
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2008-November/002603…
Does anyone here know of the reasoning behind not making pulse audio
handle this process by default?
Cheers.
Patrick Shirkey
Boost Hardware Ltd
I have got a problem with pulseaudio and jack not
playing together. More
importantly I have got a problem with pulseaudio being the default sound
server and not having automated functionality to connect with jack. If
after 10 years of running Linux audio, I have issues with getting
pulseaudio to play nicely then pulseaudio is failing to meet it's main
objective of making things easy for desktop users.
I would really like to encourage the pulseaudio people who are reading
here to make pulse gracefully and automatically cede control to jack and
then auto configure itself as a jack interface.
Pulse includes "pasuspender" to handle this use case. From the man page:
pasuspender is a tool that can be used to tell a local
PulseAudio sound server to temporarily suspend access to the audio
devices, to allow other applications access them directly. pasuspender
will suspend access to the audio devices, fork a child process,
and when the child process terminates, resume access again.
I guess this should be integrated into qjackctl & friends.
11:16 a.m.
New subject: pulseaudio issues [was Re: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)]
Hi,
Funny thing is that I'm looking at the docs for pulse audio and no where
so far is there a mention of jack.
In the faq, "perfect setup", "first steps"... It would appear that
jack support for PA is/was an after thought. One could even get the
impression that the people who wrote the pulse audio documentation
believe that jack is redundant.
Now, if this is not a strategically motivated ommission to keep people
employed working on pulse audio then I have to wonder what is the
reasoning behind pulse audio being presented as the all in one solution
for audio on Linux when jack is clearly and undeniably the sound server
of choice for professional audio.
Patrick Shirkey
Boost Hardware Ltd
11:49 a.m.
New subject: pulseaudio issues [was Re: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)]
This is, i believe, at the heart of the problem.
As a user looking in from the outside, it appears odd that the pulse
team didn't jump onboard with jack, and bring all that enthusiasm and
expertise to further enhancing jack to be the 'one solution'.
Was pulse built to truly provide a 1 stop solution, or an attempt to
sideline jack in favour of a domestic entertainment model?
Because it's clear from the structure of pulse with it's enforced
latency, and the online documentation, that professional users, and
those who want a realtime audio framework are going to be out of luck,
and well.."too bad".
Trying not to sound cynical here, but i've seen all this before in the
windows and mac worlds, where the generic game playing majority ruled
supreme, over those of us who, for example, were using 250 tracks in
daws, not 25. And 80 midi ports, instead of 8.
We had to jump through many hoops, most of which tripped us up,
because commercial devs didn't give a shit about increasing midi port
numbers, or developing multi app audio options, or anything remotely
associated with alternate uses for the software.
I'll be frank, i think the enforced pulse option is a selfish, and
self interested one, with little or no consideration for a sizable
majority of users, and is diamatrically opposite to the spirit of
opensource, and the choice it used to give the user.
No doubt i'll get flamed for this, but after two years of linux, and
countless hours put into testing apps, steep learning curves, and
encouraging and helping new users, i'm starting to wonder if it was
worth it, when the very tools i migrated for, are so easily dismissed
in favour of devs so eagerly chasing the....flash plugin crowd.
Frankly, that sucks.
I think Patrick's right in the options he presented. And from what
i've seen and read over the last 2 years, i'm inclined to think there
was a concerted effort to supplant jack in favour of a domestic option
in the pursuit of 'generic' accolades.
As for pulse handling tasks that jack can't, i'm yet to see evidence
of this. If the same...'tasks' had been added to Jack by the same
pulse devs, we wouldn't even be having this discussion.
A linux dev recently remarked to me that the politics of linux was a
hindrance to progress.
I'm beginning to understand why he said it.
Alex.
On Tue, May 19, 2009 at 5:17 PM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
Hi
Funny thing is that I'm looking at the docs for pulse audio and no where
so far is there a mention of jack.
In the faq, "perfect setup", "first steps"... It would appear that
jack support for PA is/was an after thought. One could even get the
impression that the people who wrote the pulse audio documentation
believe that jack is redundant.
Now, if this is not a strategically motivated ommission to keep people
employed working on pulse audio then I have to wonder what is the
reasoning behind pulse audio being presented as the all in one solution
for audio on Linux when jack is clearly and undeniably the sound server
of choice for professional audio.
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
--
Parchment Studios (It started as a joke...)
1:41 p.m.
New subject: pulseaudio issues [was Re: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)]
On Tue, May 19, 2009 at 9:49 AM, alex stone <compose59(a)gmail.com> wrote:
This is, i believe, at the heart of the problem.
As a user looking in from the outside, it appears odd that the pulse
team didn't jump onboard with jack,
"they" (i.e. Lennart) know all about JACK. JACK and Pulse superfically
some similarities ("sound server") but at a deeper level have almost
diametrically opposed goals. JACK is focused on low latency, realtime
performance, with a bias towards music creation and pro-audio
applications. Pulse is focused on ease of integration with legacy
APIs, network transparency and low power consumption.
these goals *might* be unifiable, but nobody involved was willing to
work that hard at doing so. JACK does what it does very well, and
Pulse does what it does quite well. they do not do the same thing.
Making them do the same thing would compromise both goals.
and before somebody notes that CoreAudio does all of this with one API:
* CoreAudio is a mandatory audio API on OS X, so every app uses it
and there are no legacy APIs to support
* CoreAudio does not support network transparency out of the box
(3rd party products are required)
* CoreAudio's design is friendly to low power consumption but not
as friendly as Pulse
A linux dev recently remarked to me that the politics
of linux was a
hindrance to progress.
I'm beginning to understand why he said it.
Its not politics. Its the lack of politics. There are no leaders with
any power to enforce any decisions. There is no police authority to
identify people who fail to comply with "joint decisions". There is no
justice system to punish or expel those who do. This is an anarchistic
meritocracy, and yes, its harder to get system infrastructure
developed in this environment than in a system like windows or OS X
where a single person can say "it shall be thus". thats good, and its
bad.
7:18 p.m.
New subject: pulseaudio issues [was Re: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Paul Davis schrieb:
On Tue, May 19, 2009 at 9:49 AM, alex stone
<compose59(a)gmail.com> wrote:
Do you think, that Jack and Pulse could see each other as perfect
abstractions:
Pulse sees Jackd as just another "soundcard"-Port it can deliver its
stream to - the same as it does with alsa
Jackd sees Pulse as just another application that delivers a stream -
the same as it is related to Zyandd or Ardour
?
Or would realtime-issues in Pulse still destabilize Jackd if Pulse runs
as a jack-client?
best regs
HZN
This is, i believe, at the heart of the problem.
As a user looking in from the outside, it appears odd that the pulse
team didn't jump onboard with jack,
"they" (i.e. Lennart) know all about JACK. JACK and Pulse superfically
some similarities ("sound server") but at a deeper level have almost
diametrically opposed goals. -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoTIjEACgkQ1Aecwva1SWPLWQCfTfbaNFHp59GK1J45lmCTqqtY
cckAnioCH9Um1iqkQmoWZQlHHUUhBU21
=NKhH
-----END PGP SIGNATURE-----
20 May
20 May
1:26 a.m.
New subject: pulseaudio issues [was Re: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)]
Hartmut Noack wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Paul Davis schrieb:
Is the situation with pulse and jack really this bad that pulse can
actually take down jack if it has a runtime issue?
I don't recall anyone mentioning that scenario over the past few years.
It wouldn't surprise me though as pulse is a unique beast and may put
strain on the system if it is competing with jack.
Patrick Shirkey
Boost Hardware Ltd
On Tue, May 19, 2009 at 9:49 AM, alex stone
<compose59(a)gmail.com> wrote:
Do you think, that Jack and Pulse could see each other as perfect
abstractions:
Pulse sees Jackd as just another "soundcard"-Port it can deliver its
stream to - the same as it does with alsa
Jackd sees Pulse as just another application that delivers a stream -
the same as it is related to Zyandd or Ardour
?
Or would realtime-issues in Pulse still destabilize Jackd if Pulse runs
as a jack-client?
This is, i believe, at the heart of the problem.
As a user looking in from the outside, it appears odd that the pulse
team didn't jump onboard with jack,
"they" (i.e. Lennart) know all about JACK. JACK and Pulse
superfically
some similarities ("sound server") but at a deeper level have almost
diametrically opposed goals.
4:59 a.m.
New subject: pulseaudio issues [was Re: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)]
It was the reason i removed it, Patrick.
Every time the pulse server would crash, or freeze, jack would get
taken down as well. I don't know, frankly, if this was a problem in my
setup, but the install was a standard one, without tweaks, at the
time.
Alex.
On Wed, May 20, 2009 at 7:27 AM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
Hartmut Noack wrote:
--
Parchment Studios (It started as a joke...)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Paul Davis schrieb:
Is the situation with pulse and jack really this bad that pulse can
actually take down jack if it has a runtime issue?
I don't recall anyone mentioning that scenario over the past few years.
It wouldn't surprise me though as pulse is a unique beast and may put
strain on the system if it is competing with jack.
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
On Tue, May 19, 2009 at 9:49 AM, alex stone
<compose59(a)gmail.com> wrote:
Do you think, that Jack and Pulse could see each other as perfect
abstractions:
Pulse sees Jackd as just another "soundcard"-Port it can deliver its
stream to - the same as it does with alsa
Jackd sees Pulse as just another application that delivers a stream -
the same as it is related to Zyandd or Ardour
?
Or would realtime-issues in Pulse still destabilize Jackd if Pulse runs
as a jack-client?
This is, i believe, at the heart of the problem.
As a user looking in from the outside, it appears odd that the pulse
team didn't jump onboard with jack,
"they" (i.e. Lennart) know all about JACK. JACK and Pulse superfically
some similarities ("sound server") but at a deeper level have almost
diametrically opposed goals.
21 May
21 May
1:08 p.m.
New subject: pulseaudio issues [was Re: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)]
On Tue, May 19, 2009 at 5:18 PM, Hartmut Noack <zettberlin(a)linuxuse.de> wrote:
Do you think, that Jack and Pulse could see each other as perfect
abstractions:
Pulse sees Jackd as just another "soundcard"-Port it can deliver its
stream to - the same as it does with alsa
Jackd sees Pulse as just another application that delivers a stream -
the same as it is related to Zyandd or Ardour
?
This already exists and is functional.
22 May
22 May
9:13 p.m.
New subject: pulseaudio issues [was Re: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)]
Paul Davis wrote:
Its not politics. Its the lack of politics. There are no leaders with
any power to enforce any decisions. There is no police authority to
identify people who fail to comply with "joint decisions". There is no
justice system to punish or expel those who do. This is an anarchistic
meritocracy, and yes, its harder to get system infrastructure
developed in this environment than in a system like windows or OS X
where a single person can say "it shall be thus". thats good, and its
bad.
This actually paints quite a good picture of the situation since the truth may be worse.
The lack of a single leadership to direct developments is that Linux has become
unbelievably segmented to the point where it is no longer a single operating system - it
is several tens of them. They all position themselves under the same umbrella but the
feature sets, libraries, maintenance capabilities are very, very diverse to the point
where the only commonality is the name.
As Paul says, roughly, its anarchy. If you like that then work with it but don't
expect things to be easy for a long time, if ever. If you like it then accept having your
computer right on the edge of stability since you will be mixing applications/drivers that
work on one distribution and 'almost' work on another and some of these have to
work together which is a very big demand/expectation. If you don't like that idea then
there are other operating systems available, just put your money on the table. Life is
full of choices and what goes into and out of your wallet is one of them but don't
expect any of those choices to be correct. If it were that simple there would only be a
single OS and it would probably not be called something as generic as Linux for the simple
reason that Linux is no longer 'one' OS.
Regards, and power to your debuging tools.
_________________________________________________________________
Windows Live™: Keep your life in sync. Check it out!
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009
25 May
25 May
7:47 a.m.
New subject: pulseaudio issues [was Re: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)]
Nick Copeland wrote:
IIUC true anarchists believe that we can only move forward by allowing
everyone the freedom to disagree. If everyone is free to disagree then
consensus can take a lot longer to be reached as everyone has to be
educated to the same or similar level about the topic of discussion.
One major issue with Linux and OSS development is that there are so many
people arguing, stepping on toes and egos that fragmentation is the only
way for many developers to move their ideas forward as it is the only
way they feel they can actually get anything done.
Funnily enough as the majority of developers are male and males
generally have difficulty communicating effectively it's kind of amazing
that Linux and OSS development has come as far as it has over the past
18 years.
One of the more positive things I have noticed is that often fragmented
projects will cause lively competition with results being feedback into
each project. However it takes time for the results to be integrated.
One of the sadder things is that often fragmented projects will cause
the demise of thriving projects they come from or the new code will be
unwanted by the original project managers so the split will result in
both projects dying.
Patrick Shirkey
Boost Hardware Ltd
Paul Davis
wrote:
Its not politics. Its the lack of politics. There are no leaders with
any power to enforce any decisions. There is no police authority to
identify people who fail to comply with "joint decisions". There is no
justice system to punish or expel those who do. This is an anarchistic
meritocracy, and yes, its harder to get system infrastructure
developed in this environment than in a system like windows or OS X
where a single person can say "it shall be thus". thats good, and its
bad.
This actually paints quite a good picture of the situation since the
truth may be worse. The lack of a single leadership to direct
developments is that Linux has become unbelievably segmented to the
point where it is no longer a single operating system - it is several
tens of them. They all position themselves under the same umbrella but
the feature sets, libraries, maintenance capabilities are very, very
diverse to the point where the only commonality is the name.
As Paul says, roughly, its anarchy. If you like that then work with it but don't
expect things to be easy
for a long time, if ever. If you like it then accept having your
computer right on the edge of stability since you will be mixing
applications/drivers that work on one distribution and 'almost' work
on another and some of these have to work together which is a very big
demand/expectation. If you don't like that idea then there are other
operating systems available, just put your money on the table. Life is
full of choices and what goes into and out of your wallet is one of
them but don't expect any of those choices to be correct. If it were
that simple there would only be a single OS and it would probably not
be called something as generic as Linux for the simple reason that
Linux is no longer 'one' OS.
Regards, and power to your debuging tools.
------------------------------------------------------------------------
Windows Live™: Keep your life in sync. Check it out!
<http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009>
------------------------------------------------------------------------
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
19 May
19 May
12:07 p.m.
New subject: pulseaudio issues [was Re: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
Patrick Shirkey schrieb:
Hi,
Funny thing is that I'm looking at the docs for pulse audio and no where
so far is there a mention of jack.
Did anyone ever recieved an answer/statement regarding these matters
from those, who are responsible for PA?
best regs
HZN
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoSvToACgkQ1Aecwva1SWMwXQCZATWa5Mx8rQAfFMDP0CWeWtHu
R3gAn1fVw0NnQMvzKQ+pBAf5MY0M0bBU
=weGp
-----END PGP SIGNATURE-----
12:11 p.m.
New subject: pulseaudio issues [was Re: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)]
Hartmut Noack wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
Patrick Shirkey schrieb:
I have sent a message to the pulse audio list today for clarification.
As Nedko says it is already fixed in the latest code so intend to test
this tomorrow or the next day,
I have received a response that the actual auto reconfiguration code si
being worked on by Lennart so I am hopeful that he is planning a blitz
at some point.
Cheers.
Patrick Shirkey
Boost Hardware Ltd
Hi,
Funny thing is that I'm looking at the docs for pulse audio and no where
so far is there a mention of jack.
Did anyone ever recieved an answer/statement regarding these matters
from those, who are responsible for PA?
5:10 a.m.
New subject: pulseaudio issues [was Re: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)]
Patrick Shirkey <pshirkey(a)boosthardware.com> writes:
I have got a problem with pulseaudio and jack not
playing together. More
importantly I have got a problem with pulseaudio being the default sound
server and not having automated functionality to connect with jack. If
after 10 years of running Linux audio, I have issues with getting
pulseaudio to play nicely then pulseaudio is failing to meet it's main
objective of making things easy for desktop users.
I would really like to encourage the pulseaudio people who are reading
here to make pulse gracefully and automatically cede control to jack and
then auto configure itself as a jack interface.
AFAIK the fix is already implemented in both jack and
pulseaudio. Interestingly, the fix involves using D-Bus (nobody whants
to reinvent wheels for no reason). Of course it will take *some* time
until the dbus cooperation mechanism between jack and pulse gets
included in distro releases.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
5:49 a.m.
New subject: pulseaudio issues [was Re: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)]
Patrick Shirkey wrote:
Desktop Linux users need these features:
1: Auto detect sound card
2: Easily accessible volume controls
3: Easy to define default sound card and route audio streams
4: Easy to start mutiple multimedia apps and route the audio
5: Easy to change from being a consumer user to a professional user and
back again.
IMO 1 to 4 have been fairly well accomplished but step 5 is currently fubar.
Pulse should detect if jack has been started and cede control of the
audio device.
Pulse should allow users the option of auto switching to the jack i/os
or using a different device.
Pulse should retain these configuration settings.
Pulse should assume that when a user starts jack they want their audio
to be temporarily reconfigured and if that means routing the pulse
stream to /dev/null for a brief period then it should handle that
internally and maintain existing application streams. Once it has
successfully reconfigured to connect with jack or an alternate device it
can redirect the audio streams to the chosen output.
And for those of us running two soundcards (one for desktop, one for
recording) it would be polite if I Pulse would refrain from touching the
'studio' card. Ever.
R
18 May
18 May
11:33 p.m.
New subject: jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)
Interestingly I use KDE 4 and with that as long as your libxine supports jack
(that means recompiling it on Ubuntu) you get jack in your list of preferred
sound devices. Its possible to use Jack for one class of applications (say
music) and use something else for communications applications. If jack is not
available it will automatically fall back to Pulse or Alsa.
Of course the application needs to support Phonon (Mostly qt and KDE apps) but
it is a nice start. I suspect that GNOME users don't fair so well in this
regards.
On Tue, 19 May 2009 12:46:46 am alex stone wrote:
Danni, and i'm sure you have a fine collection of
headscarfs to
complete the 'picture'. :)
Thanks for the explanation about Dbus.
And for what it's worth, i think you've hit the nub of this (imho). If
app builders use jack by default, or have a jack option in audio and
midi preferences, we'd be discussing the weather instead.
Alex.
--
Reality -- what a concept!
-- Robin Williams
17 May
17 May
5:23 p.m.
New subject: [Jack-Devel] more jack/qjackctl madness
On Sun, 17 May 2009 09:58:47 -0500 (CDT)
Brent Busby <brent(a)keycorner.org> wrote:
On Sun, 17 May 2009, Rui Nuno Capela wrote:
Well, they basically don't interfere BUT
I had (have?) a problem where qjackctl did interfere with ardour.
When I tried to export a project in ardour and had qjackctl running, no
matter if qjackctl started jackd or not, ardours export got stuck,
ardour was not responding anymore. If qjackctl was not running export
behaved fine. Rui (qjackctl author) said it was a problem with either
jack or ardour.
Personally, with all the trouble surrounding qjackctl recently, I now
just start jackd with my desktop session (until I have a way to start
it as daemon with user privileges) and make connections in patchage.
Regards,
Philipp
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...
Newbie question: Is it harmful to have QJackctl and Ardour both
running at the same time? Do they have to potential to fight
eachother, or to make changes to the Jack environment that will be
made by one but not realized by the other, either in regard to jackd
parameters, or in regard to the connection patchbays?
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
5458
days inactive
5467
days old
linux-audio-user@lists.linuxaudio.org
64 comments
21 participants
participants (21)
-
alex stone -
Brent Busby -
Chris Cannam -
Danni Coy -
drew Roberts -
Fons Adriaensen -
Hartmut Noack -
hollunder＠gmx.at -
Ivica Ico Bukvic -
Joe Hartley -
Ken Restivo -
Lee Revell -
MarcO'Chapeau -
Mark Knecht -
Nedko Arnaudov -
Nick Copeland -
Patrick Shirkey -
Paul Davis -
rob -
Rui Nuno Capela -
Stéphane Letz