Re: jack2's dbus name

[Stéphane Letz]

Le 15 juin 09 à 01:14, Lennart Poettering a écrit :

> Hmm,
>
> I was just thinking, when jack2 finished initialization it takes a
> name on the session bus, right?

Not sure about what you mean by " it takes name on the session bus". I  
hope Nedko can answer better here.

What is implemented right now is the acquire/release scheme based on  
your reserver.h,c code. This is done in the ALSA backend.

>
> If that's the case then I could hack up a little module in PA that
> will autoload the JACK connectivity modules as soon as jack becomes
> available. That way we could make the integration between PA and JACK
> a bit closer. Together with the device reservation logic we already
> have in place we could then have out-of-the-box user experience that
> would work like this:
>
> As soon as jack starts up and takes posession of the device, the hw
> device will appear grayed out in pa's volume control, however a new
> virtual device for connectivity with jack appears in the vc. Data
> written to that device will be passed to JACK on a couple of
> ports. It's then up to the user if he wants to make use of those ports
> and connect them inside of jack or just leave them unconnected. (as
> far as I understood the mere existance of a port when it is
> unconnected has no detrimental effect on jack latency behaviour, does
> it?). As soon as JACK terminates the virtual JACK device in PA will go
> away again, and the hw device won't be greyed out anymore.
>
> That way the seperation line between PA clients and JACK clients would
> be blurred a bit.
>
> One could even go a step further and reroute all existing streams from
> the hw device to the virtual jack device, as long as it exists and
> back afterwards. That way starting up jack would have the effect that
> PA's own ALSA backend would simply be temporarily be replaced by
> JACK.
>
> Does that make sense to you?
>
> Lennart

Technically it "could" make sense, but I'm not sure JACK users want  
that as the default behaviour. I would prefer if "real users" in JACK  
and LAD communities could elaborate on that.

Stephane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

Le 15 juin 09 à 14:59, Lennart Poettering a écrit :

> On Mon, 15.06.09 11:01, Stéphane Letz (letz@...) wrote:
>
>>> I was just thinking, when jack2 finished initialization it takes a
>>> name on the session bus, right?
>>
>> Not sure about what you mean by " it takes name on the session  
>> bus". I
>> hope Nedko can answer better here.
>
> I simply mean it calls dbus_bus_request_name()
> resp. org.freedesktop.DBus.RequestName to acquire a service name n the
> session bus, such as org.jack.foo.bar.

We recently had a strong debate on JACK dev list about the way DBus  
could/should be used with JACK. DBus is currently used a two different  
places in JACK2:

1) to deal with this "audio device reservation" idea to better  
cooperate with PulseAudio. This is coded in ALSA backend directly (and  
so is used only when ALSA backend is used..)

2) to deal with the so-called "server control API", that is a more  
powerful way to control the server from (DBus) based applications.

What I'm personally trying to achieve is a more "flexible" way  
(compared to what is currently a bit hard-coded in JAKC2 SVN) so that  
a DBus control component can be coded as a "plugin" to be possibly  
loaded in JACK server process. This new plugin model allows to keep  
basically 2 ways of using JACK server :  the "old way" (typically  
starting the jackd server using Qjackctl control application) or the  
new way using DBus based control applications (after the DBus control  
plug-in has been properly loaded in JACK server).  (Keeping the "old-
way" is also important on others platforms JACK2 runs on.)

If this new "control plugin" model is finally accepted by JACK  
community, then we'll distribute/package JACK2 compiled with the 1)  
option, so that it (at least) cooperates with PulseAudio. But 2) would  
then be optional, so PA can not rely on the DBus control plug-in to  
always be present.

The 1) code uses  "org.freedesktop.ReserveDevice1.AudioXX" name, and  
2) optional DBus plugin uses "org.jackaudio.service" name. If we want  
to implement your proposal, the we would need to request another name  
in  1) part, is that correct?

>
>>> As soon as jack starts up and takes posession of the device, the hw
>>> device will appear grayed out in pa's volume control, however a new
>>> virtual device for connectivity with jack appears in the vc. Data
>>> written to that device will be passed to JACK on a couple of
>>> ports. It's then up to the user if he wants to make use of those  
>>> ports
>>> and connect them inside of jack or just leave them unconnected. (as
>>> far as I understood the mere existance of a port when it is
>>> unconnected has no detrimental effect on jack latency behaviour,  
>>> does
>>> it?).
>
> Could you say something about this question of mine regarding the mere
> existance of ports in jack please?

Having JACK ports means a PulseAudio client is running. But it does  
not add any "latency" by itself.

>
>>> Does that make sense to you?
>>>
>>> Lennart
>>
>> Technically it "could" make sense, but I'm not sure JACK users want
>> that as the default behaviour. I would prefer if "real users" in JACK
>> and LAD communities could elaborate on that.
>
> I mean, the idea is to simply offer those PA innterconnection ports,
> it's up to the user to connect them or not. And if a user really
> doesn't want that we could even make that easily disabable in the PA
> UI somewhere.
>

Yes, I see.

Stephane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Lennart Poettering-15]

On Mon, 15.06.09 15:34, Stéphane Letz (letz@...) wrote:

>> On Mon, 15.06.09 11:01, Stéphane Letz (letz@...) wrote:
>>
>>>> I was just thinking, when jack2 finished initialization it takes a
>>>> name on the session bus, right?
>>>
>>> Not sure about what you mean by " it takes name on the session bus".
>>> I
>>> hope Nedko can answer better here.
>>
>> I simply mean it calls dbus_bus_request_name()
>> resp. org.freedesktop.DBus.RequestName to acquire a service name n the
>> session bus, such as org.jack.foo.bar.
>
> We recently had a strong debate on JACK dev list about the way DBus  
> could/should be used with JACK.

Yes, I noticed.

> What I'm personally trying to achieve is a more "flexible" way (compared
> to what is currently a bit hard-coded in JAKC2 SVN) so that a DBus
> control component can be coded as a "plugin" to be possibly loaded in
> JACK server process. This new plugin model allows to keep basically 2
> ways of using JACK server :  the "old way" (typically starting the jackd
> server using Qjackctl control application) or the new way using DBus
> based control applications (after the DBus control plug-in has been
> properly loaded in JACK server).  (Keeping the "old-way" is also
> important on others platforms JACK2 runs on.)

Distributions will certainly enable the D-Bus code in JACK if they
ship it. So, I have no problem with depending on a dbus'ified jack for
this logic to work. After all crazy folks who disable the dbus support
in jack because they think it's an abomination probably think that PA
is an even worse abomination anyway, so there's not need to cater for
them.

> If this new "control plugin" model is finally accepted by JACK  
> community, then we'll distribute/package JACK2 compiled with the 1)  
> option, so that it (at least) cooperates with PulseAudio. But 2) would  
> then be optional, so PA can not rely on the DBus control plug-in to  
> always be present.
>
> The 1) code uses  "org.freedesktop.ReserveDevice1.AudioXX" name, and 2)
> optional DBus plugin uses "org.jackaudio.service" name. If we want to
> implement your proposal, the we would need to request another name in  1)
> part, is that correct?

I think org.jackaudio.service should be fine. I don't think this
automatic logic needs to work on non-D-Bus jack builds. As I see it
you don't need to make any changes on jack for this to work. All I
need is the guarantee that by the time the service name is registered
on the bus jack is fully accessible. Otherwise we had a race here: if
PA looks for the org.jackaudio.service name to appear on the bus and
then imemdiately connects to it while jack isn't fully accessible yet
PA would fail.

Lennart

--
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

>
>> What I'm personally trying to achieve is a more "flexible" way  
>> (compared
>> to what is currently a bit hard-coded in JAKC2 SVN) so that a DBus
>> control component can be coded as a "plugin" to be possibly loaded in
>> JACK server process. This new plugin model allows to keep basically 2
>> ways of using JACK server :  the "old way" (typically starting the  
>> jackd
>> server using Qjackctl control application) or the new way using DBus
>> based control applications (after the DBus control plug-in has been
>> properly loaded in JACK server).  (Keeping the "old-way" is also
>> important on others platforms JACK2 runs on.)
>
> Distributions will certainly enable the D-Bus code in JACK if they
> ship it. So, I have no problem with depending on a dbus'ified jack for
> this logic to work.

In the proposed model, having "D-Bus code in JACK" will mean 1)  only  
would be on (reservation code used in ALSA backend). Having a DBus  
control plugin would be optional, that is, it should even probably be  
distributed as a separated package.

> After all crazy folks who disable the dbus support
> in jack because they think it's an abomination probably think that PA
> is an even worse abomination anyway, so there's not need to cater for
> them.

Well me current role as I see it is to try to keep "guardians" and  
"rebels" on the same boat...

>
>> If this new "control plugin" model is finally accepted by JACK
>> community, then we'll distribute/package JACK2 compiled with the 1)
>> option, so that it (at least) cooperates with PulseAudio. But 2)  
>> would
>> then be optional, so PA can not rely on the DBus control plug-in to
>> always be present.
>>
>> The 1) code uses  "org.freedesktop.ReserveDevice1.AudioXX" name,  
>> and 2)
>> optional DBus plugin uses "org.jackaudio.service" name. If we want to
>> implement your proposal, the we would need to request another name  
>> in  1)
>> part, is that correct?
>
> I think org.jackaudio.service should be fine.

But this is activated only by the *optional* DBus control plugin..

> I don't think this
> automatic logic needs to work on non-D-Bus jack builds. As I see it
> you don't need to make any changes on jack for this to work. All I
> need is the guarantee that by the time the service name is registered
> on the bus jack is fully accessible. Otherwise we had a race here: if
> PA looks for the org.jackaudio.service name to appear on the bus and
> then imemdiately connects to it while jack isn't fully accessible yet
> PA would fail.

This is not the case right now. The org.jackaudio.service is started  
and then DBus control application can access it, to configure, start/
stop the server... This mean that the JACK server is not always started.

So I guess we'll have to implement something new in the 1) part, since  
I guess we want this JACK/PA cooperation, even if users are not using  
DBus based control applications to control JACK.

Stephane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fernando Lopez-Lezcano]

On Mon, 2009-06-15 at 16:37 +0200, Lennart Poettering wrote:

> On Mon, 15.06.09 15:34, Stéphane Letz (letz@...) wrote:
>
> >> On Mon, 15.06.09 11:01, Stéphane Letz (letz@...) wrote:
> >>
> >>>> I was just thinking, when jack2 finished initialization it takes a
> >>>> name on the session bus, right?
> >>>
> >>> Not sure about what you mean by " it takes name on the session bus".
> >>> I hope Nedko can answer better here.
> >>
> >> I simply mean it calls dbus_bus_request_name()
> >> resp. org.freedesktop.DBus.RequestName to acquire a service name n the
> >> session bus, such as org.jack.foo.bar.
> >
> > We recently had a strong debate on JACK dev list about the way DBus  
> > could/should be used with JACK.
>
> Yes, I noticed.
>
> > What I'm personally trying to achieve is a more "flexible" way (compared
> > to what is currently a bit hard-coded in JAKC2 SVN) so that a DBus
> > control component can be coded as a "plugin" to be possibly loaded in
> > JACK server process. This new plugin model allows to keep basically 2
> > ways of using JACK server :  the "old way" (typically starting the jackd
> > server using Qjackctl control application) or the new way using DBus
> > based control applications (after the DBus control plug-in has been
> > properly loaded in JACK server).  (Keeping the "old-way" is also
> > important on others platforms JACK2 runs on.)
>
> Distributions will certainly enable the D-Bus code in JACK if they
> ship it. So, I have no problem with depending on a dbus'ified jack for
> this logic to work.

>From a packagers' (for Fedora/Planet CCRMA) point of view the future
dbus-capable jack should be able to be used without dbus support as well
as with it _without_ having to recompile it (that is without having to
repackage it differently). For an example of non-dbus usage, I may want
to start jack on a remote host where there is no desktop session at the
moment and thus dbus is not usable.

> > If this new "control plugin" model is finally accepted by JACK  
> > community, then we'll distribute/package JACK2 compiled with the 1)  
> > option, so that it (at least) cooperates with PulseAudio. But 2) would  
> > then be optional, so PA can not rely on the DBus control plug-in to  
> > always be present.
> >
> > The 1) code uses  "org.freedesktop.ReserveDevice1.AudioXX" name, and 2)
> > optional DBus plugin uses "org.jackaudio.service" name. If we want to
> > implement your proposal, the we would need to request another name in  1)
> > part, is that correct?
>
> I think org.jackaudio.service should be fine. I don't think this
> automatic logic needs to work on non-D-Bus jack builds.

I would change the wording to "on jack instances that are not using
dbus" (ie: whether you use dbus or not should not depend on the build).

-- Fernando


> As I see it
> you don't need to make any changes on jack for this to work. All I
> need is the guarantee that by the time the service name is registered
> on the bus jack is fully accessible. Otherwise we had a race here: if
> PA looks for the org.jackaudio.service name to appear on the bus and
> then imemdiately connects to it while jack isn't fully accessible yet
> PA would fail.


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fernando Lopez-Lezcano]

[it'd be nice if you keep all the cc'ed original lists in the thread]

On Mon, 2009-06-15 at 19:34 +0200, Lennart Poettering wrote:

> On Mon, 15.06.09 10:16, Fernando Lopez-Lezcano (nando@...) wrote:
>
> > > Distributions will certainly enable the D-Bus code in JACK if they
> > > ship it. So, I have no problem with depending on a dbus'ified jack for
> > > this logic to work.
> >
> > >From a packagers' (for Fedora/Planet CCRMA) point of view the future
> > dbus-capable jack should be able to be used without dbus support as well
> > as with it _without_ having to recompile it (that is without having to
> > repackage it differently). For an example of non-dbus usage, I may want
> > to start jack on a remote host where there is no desktop session at the
> > moment and thus dbus is not usable.
>
> No. That use case does not make any sense. The D-Bus session bus is
> autospawned if necessary these days.

So, let's say host A is where I am logged in now and I'm running a
desktop. The I start a terminal, just do "slogin B" (for simplicity
let's assume nobody is logged in into B at the time) and then I would
have dbus running there without a desktop? What is taking care of
setting up the dbus session, is that ssh? The login process?

> I personally see no value in dbus-less builds. That's just pointless
> conservatism, mostly based on unfounded anti D-Bus FUD. But then
> again, I am not really a jack developer, so what I think is mostly
> irrelevant.

I understand that you _personally_ would see no value in dbus-less
builds. But others do see value. I am assuming that others might have
valid reasons for doing things in a different way, and that my view of
the universe is not the only one possible.

In a very long thread about the dbus issues in the jack developers list
it was (I think) agreed that the core innards of jack would not
explicitly depend on dbus at compile time but rather at runtime. So you
could run jack with dbus support or without it, without having to
recompile it. Everyone is happy. Nothing is forced on anybody. Future
usage will eventually make the non-dbus option go away or not. Nobody is
inconvenienced by that.

-- Fernando


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fons Adriaensen-2]

On Mon, Jun 15, 2009 at 04:59:40PM +0200, Stéphane Letz wrote:

> In the proposed model, having "D-Bus code in JACK" will mean 1)  only would
> be on (reservation code used in ALSA backend). Having a DBus control plugin
> would be optional, that is, it should even probably be distributed as a
> separated package.

There is no good reason for having 1) compiled-in. The initiative
to talk to PA in order to claim a device is taken by Jack. It could
just load a plugin to do this, iff configured to do it.

I'll repeat this: if dbus becomes a dependency for Jack, I will
fork Jack. And maybe introduce incompatible changes - once the
first step is taken there's little reason to avoid that, and
there are good reasons to do it. The funds to do this have been
set aside - I'd just prefer to use them for something else.

Ciao,

--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

On Mon, Jun 15, 2009 at 6:25 PM, Fons Adriaensen<fons@...> wrote:
>
> I'll repeat this: if dbus becomes a dependency for Jack, I will
> fork Jack.

And I'll repeat: JACK will not depend on non-POSIX interfaces for any
essential functions unless the platform requires it, which it does not
in this case.

Good grief, Fons. Get a grip. We're trying to figure out how to make a
system installed by more and more distributors can play nice with
JACK. It has nothing to do with JACK functionality, and JACK is never
going to "depend" on DBus. What more do I have to do to make this
clear?

You'd prefer that we spend whatever development time we have for JACK
on *another* plugin system for the ALSA backend, or that we just do
the simple thing and provide ./configure --with-alsa-dbus-negotiation
so that distributors can make this work if they are building a package
that is intended to run on a PulseAudio-equipped machine?

> And maybe introduce incompatible changes - once the
> first step is taken there's little reason to avoid that, and
> there are good reasons to do it.

Maybe instead of continuing to threaten a fork over every mention of
DBus, you could implement some of these changes as patches, submit to
them to the list, and see them actually get integrated and put into
use.

What more do I have to do to make it clear that JACK WILL NEVER DEPEND
ON DBus ????
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[j4nKy]

On Mon, Jun 15, 2009 at 10:12:14PM -0400, Paul Davis wrote:

> On Mon, Jun 15, 2009 at 6:25 PM, Fons Adriaensen<fons@...> wrote:
> >
> > I'll repeat this: if dbus becomes a dependency for Jack, I will
> > fork Jack.
>
> And I'll repeat: JACK will not depend on non-POSIX interfaces for any
> essential functions unless the platform requires it, which it does not
> in this case.
>
> Good grief, Fons. Get a grip. We're trying to figure out how to make a
> system installed by more and more distributors can play nice with
> JACK.

maybe that is exactly the problem?  jack is for pro-audio, right?
shouldn't a pro know when jack needs to be started and other
audio device users stopped?  why not just have jackd run on top
of pulse, or vice-versa?  why would pulseaudio even exist in
a pro-audio setup?

basically, why is complexity being added to jack to deal with
desktop usage issues?  maybe because you yourself said jack backends
should not be added to "desktop" applications, that that job
is for pulse?

--
jakemsr@...
SDF Public Access UNIX System - http://sdf.lonestar.org
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fernando Lopez-Lezcano]

On Mon, 2009-06-15 at 22:12 -0400, Paul Davis wrote:

> On Mon, Jun 15, 2009 at 6:25 PM, Fons Adriaensen<fons@...> wrote:
> >
> > I'll repeat this: if dbus becomes a dependency for Jack, I will
> > fork Jack.
>
> And I'll repeat: JACK will not depend on non-POSIX interfaces for any
> essential functions unless the platform requires it, which it does not
> in this case.
>
> Good grief, Fons. Get a grip. We're trying to figure out how to make a
> system installed by more and more distributors can play nice with
> JACK. It has nothing to do with JACK functionality, and JACK is never
> going to "depend" on DBus. What more do I have to do to make this
> clear?
>
> You'd prefer that we spend whatever development time we have for JACK
> on *another* plugin system for the ALSA backend, or that we just do
> the simple thing and provide ./configure --with-alsa-dbus-negotiation
> so that distributors can make this work if they are building a package
> that is intended to run on a PulseAudio-equipped machine?

I don't remember if I have explicitly expressed my preferences with my
packager's hat on.

What I want to be able to do as a packager is, I think, simple (and I
want the same thing as a user!).

I want users to be able to choose whether to run jackd as before (ie: no
dbus), or run jackd with a dbus connection. I don't want to force them
to use either mode. The choice could be made with a jackd runtime switch
(in which case I would like to be able to select at compile time which
mode is the default), or it could be made by installing an additional
package (in which case installing an additional package would magically
add the dbus functionality and removing it would remove that
functionality[*]). I think I would prefer a runtime switch.

In other words I want the possibility to transition from one mode to the
other and back, and I want that possibility to be in the hands of each
user and not just in my hands as a packager.

I don't care that much about how this is accomplished.

-- Fernando


[*] BTW, "installing an additional package" means not modifying any of
the files of the original base jack-audio-connection-kit package but
rather adding something (shared library?) that is recognized by the
existing jackd and automatically adds the functionality.


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

On Mon, Jun 15, 2009 at 10:44 PM, Jacob Meuser<jakemsr@...> wrote:
>
> maybe that is exactly the problem?  jack is for pro-audio, right?

whether or not i agree with this is irrelevant. distributions are
pushing PulseAudio in front of users. users want to use JACK. they
collide. users are unhappy.
our job: make these users happy WITHOUT making fons and other similar
users unhappy.

> shouldn't a pro know when jack needs to be started and other
> audio device users stopped?

most people who want to run audio software don't have a clue about how
this all works.

>why not just have jackd run on top
> of pulse, or vice-versa?  why would pulseaudio even exist in
> a pro-audio setup?

in a real pro-audio setup, pulseaudio would play no role and would
likely not be installed. but thats not the sort of system that the
VAST majority of people using JACK and JACK enabled software will be
using. if that is not true today, as PulseAudio starts to spread, it
will be true tomorrow.

> basically, why is complexity being added to jack to deal with
> desktop usage issues?  maybe because you yourself said jack backends
> should not be added to "desktop" applications, that that job
> is for pulse?

Pulse has a JACK backend. Already. It works. If the user knows what
they are doing, they will use it and be happy. But many users do not
know what they are doing, and instead just suffer frustration when
something they rightfully expect should work simply fails to work and
for no reason they can discern.

Fixing this issue should not compromise the situation for users who DO
know what they are doing. But just because some people understand how
it all works, and what to do and what not to do does not mean that we
should stop working on behalf of those who don't.

Finally, yes, its possible that some future solution to the mess that
is Linux Audio might involve solutions that are more integrated that
"PulseAudio and JACK co-existing". But such solutions do not exist at
present, are not known to be planned and offer nothing to help the
problems people face right now.

--p
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

On Mon, Jun 15, 2009 at 10:46 PM, Fernando
Lopez-Lezcano<nando@...> wrote:

>
> I don't remember if I have explicitly expressed my preferences with my
> packager's hat on.
>
> What I want to be able to do as a packager is, I think, simple (and I
> want the same thing as a user!).
>
> I want users to be able to choose whether to run jackd as before (ie: no
> dbus), or run jackd with a dbus connection. I don't want to force them
> to use either mode. The choice could be made with a jackd runtime switch
> (in which case I would like to be able to select at compile time which
> mode is the default), or it could be made by installing an additional
> package (in which case installing an additional package would magically
> add the dbus functionality and removing it would remove that
> functionality[*]). I think I would prefer a runtime switch.
>
> In other words I want the possibility to transition from one mode to the
> other and back, and I want that possibility to be in the hands of each
> user and not just in my hands as a packager.

I don't believe that this is a feasible goal on any distribution that
chooses to package both PulseAudio and JACK as co-installed systems.
On such distributions, there are two choices that I can see:

    a) the user either chooses not to install or deinstalls one of the two
    b) the user only ever uses one or the other (effectively
equivalent to (a), but more difficult to accomplish reliably)
    c) the two systems co-operate in a very simplistic way to make
sure they do not collide

If you are a packager and building JACK to run on a system that you
are 97.5% certain will have PulseAudio installed, then its unclear to
me why you would choose to avoid (c).

We are not talking about a situation where a JACK with
"collaborate-via--<whatever IPC method doesn't freak you out>" has
been compiled in will fail or crash or otherwise malfunction if
PulseAudio is not running. If that option was compiled in, an attempt
to collaborate will be made, and then JACK will proceed as normal
(which may or may not succeed depending the rest of the state of the
machine).

If that option was not compiled in, and PulseAudio is installed and
running, JACK will not be able to start using the same audio interface
as PA. The user can manually shut down PA (or whatever else is using
the device). This is the situation today.

Which of these two would you prefer as a packager?

--p
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[j4nKy]

On Mon, Jun 15, 2009 at 10:55:01PM -0400, Paul Davis wrote:

> But many users do not
> know what they are doing

so teach them instead of making things more complicated.

> the mess that
> is Linux Audio

I suspect a large part of problem is from trying to make everything
"just work" in complicated ways instead of teaching people how to
make things work in simple ways.

--
jakemsr@...
SDF Public Access UNIX System - http://sdf.lonestar.org
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Chris Morgan-2]

On Mon, Jun 15, 2009 at 11:20 PM, Jacob Meuser<jakemsr@...> wrote:

> On Mon, Jun 15, 2009 at 10:55:01PM -0400, Paul Davis wrote:
>
>> But many users do not
>> know what they are doing
>
> so teach them instead of making things more complicated.
>
>> the mess that
>> is Linux Audio
>
> I suspect a large part of problem is from trying to make everything
> "just work" in complicated ways instead of teaching people how to
> make things work in simple ways.
>
> --

Having things "just work" is what most users, like myself, want. I'd
rather not have to learn something if I'm either busy with doing
something or simply not interested in knowing.

If some part of the behind-the-scenes system isn't working properly
then it should be worked on to simplify it but that's for the
developers, not the end users.

The goal should really be to help the user accomplish their goals,
ideally with the least amount of work on their part.

Chris
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

On Mon, Jun 15, 2009 at 11:20 PM, Jacob Meuser<jakemsr@...> wrote:
> I suspect a large part of problem is from trying to make everything
> "just work" in complicated ways instead of teaching people how to
> make things work in simple ways.

a vastly bigger part of the problem comes from the fact there is no
single "system" for audio on linux. thus the problem is not just how
to make JACK work the right way (which is complex enough, all by
itself), but how to allow different systems to (co|inter)operate in
ways that don't prove burdensome for users (whether they need the
(co|inter)operation or not).

this problem is not really amenable to technical solutions.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[j4nKy]

On Mon, Jun 15, 2009 at 11:27:13PM -0400, Chris Morgan wrote:

> On Mon, Jun 15, 2009 at 11:20 PM, Jacob Meuser<jakemsr@...> wrote:
> > On Mon, Jun 15, 2009 at 10:55:01PM -0400, Paul Davis wrote:
> >
> >> But many users do not
> >> know what they are doing
> >
> > so teach them instead of making things more complicated.
> >
> >> the mess that
> >> is Linux Audio
> >
> > I suspect a large part of problem is from trying to make everything
> > "just work" in complicated ways instead of teaching people how to
> > make things work in simple ways.
> >
> > --
>
> Having things "just work" is what most users, like myself, want. I'd
> rather not have to learn something if I'm either busy with doing
> something or simply not interested in knowing.
>
> If some part of the behind-the-scenes system isn't working properly
> then it should be worked on to simplify it but that's for the
> developers, not the end users.
>
> The goal should really be to help the user accomplish their goals,
> ideally with the least amount of work on their part.
>
> Chris

so, jack is not for pros, but for people too lazy to read simple docs?
there is a jack backend for pulse, so start jackd then pulse.  it's
that simple, isn't it?

on the flip side, if the solution relies in dbus, then what happens
when the user had dbus problems?  isn't that just more stuff to
figure out?

--
jakemsr@...
SDF Public Access UNIX System - http://sdf.lonestar.org
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[j4nKy]

On Mon, Jun 15, 2009 at 11:32:48PM -0400, Paul Davis wrote:

> On Mon, Jun 15, 2009 at 11:20 PM, Jacob Meuser<jakemsr@...> wrote:
> > I suspect a large part of problem is from trying to make everything
> > "just work" in complicated ways instead of teaching people how to
> > make things work in simple ways.
>
> a vastly bigger part of the problem comes from the fact there is no
> single "system" for audio on linux. thus the problem is not just how
> to make JACK work the right way (which is complex enough, all by
> itself), but how to allow different systems to (co|inter)operate in
> ways that don't prove burdensome for users (whether they need the
> (co|inter)operation or not).
>
> this problem is not really amenable to technical solutions.

imo, that is largely "the problem with Linux".  Linux people like
choices, which lead to interoperability problems.

I like choices too, but I realize that choices can also lead to
interoperability issues, and am willing to learn how to deal with
possible issues.

basically, Linux is never going to be as "simple for the user" as
windows or osx, because it offers way more choices.  trying to make
it "simple for the user" without removing choices just adds more
complexity.

at least, that's how I see it.

--
jakemsr@...
SDF Public Access UNIX System - http://sdf.lonestar.org
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Patrick Shirkey]

On 06/16/2009 10:20 AM, Jacob Meuser wrote:

On Mon, Jun 15, 2009 at 10:55:01PM -0400, Paul Davis wrote:

  

But many users do not
know what they are doing
    

so teach them instead of making things more complicated.

  

Most people don't want to "have" to learn. If you are driving a car you don't want to know about how the window washer system works to use it. We can automate this process. It's a fairly trivial code to implement. In fact we have several options on the table.

Play nicely together:

1: dbus - already implemented in jack-dbus
2: bash script to disconnect pulse from alsa-sink/source and connect jack-sink/source.

Override PA:

3: disable pulseaudio - already done by a large number of users by uninstalling, or turning off the server at boot.
4: run "pasuspender qjackctl" which suspends pulse audio until qjackctl is stopped.

the mess that
is Linux Audio
    

I suspect a large part of problem is from trying to make everything
"just work" in complicated ways instead of teaching people how to
make things work in simple ways.

  

The main problem is that some people who use jack for professional purposes don't see any point in having pulse running especially with a dbus server requirement for jack. However other professional and semi professional users would rather like jack and pa to work together nicely and also see an opportunity to automate the process for the rest of the world and in doing so make things just a little easier for the vast majority of casual users.






_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Patrick Shirkey]

On 06/16/2009 10:32 AM, Paul Davis wrote:

On Mon, Jun 15, 2009 at 11:20 PM, Jacob Meuserjakemsr@... wrote:
  

I suspect a large part of problem is from trying to make everything
"just work" in complicated ways instead of teaching people how to
make things work in simple ways.
    

a vastly bigger part of the problem comes from the fact there is no
single "system" for audio on linux. thus the problem is not just how
to make JACK work the right way (which is complex enough, all by
itself), but how to allow different systems to (co|inter)operate in
ways that don't prove burdensome for users (whether they need the
(co|inter)operation or not).

this problem is not really amenable to technical solutions.
  

Maybe true but also part of the reason we are all doing what we do... Solving the technical problems that the normal people have no hope in hell of doing.







_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

On Tue, Jun 16, 2009 at 12:07 AM, Patrick
Shirkey<pshirkey@...> wrote:
>
> Play nicely together:
>
> 1: dbus - already implemented in jack-dbus

No - implemented in an unacceptable way (made jack depend on DBus to
function at all).

> 2: bash script to disconnect pulse from alsa-sink/source and connect
> jack-sink/source.

crude.

> Override PA:
>
> 3: disable pulseaudio - already done by a large number of users by
> uninstalling, or turning off the server at boot.

possible, but not nice for many users.

> 4: run "pasuspender qjackctl" which suspends pulse audio until qjackctl is
> stopped.

viable, though non-automatic.

5. JACK's ALSA backend optionally (compile time) sends out a DBus
notification that will hopefully cause any other users of the audio
interface (at this point, just PulseAudio) to give up their use of the
device, and another to announce that its done. Neither delivery nor
release of the device is assumed or required by JACK, which then
carries on as normal, hopefully finding the device available for use.
PRO: it just works CON: compile time option unless we add Yet Another
Plugin System to JACK. Note that if JACK is built without this option,
it will work as it does today - failing if PulseAudio owns the device,
and proceeding normally otherwise.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org