Re: jack2's dbus name

[Patrick Shirkey]

On 06/16/2009 11:13 AM, Paul Davis wrote:

On Tue, Jun 16, 2009 at 12:07 AM, Patrick
Shirkeypshirkey@... 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.
  

6:   Pulse audio provides a call for jack to signal and handles the process from there on. i.e jack could call "pactl -jack on", "pactl -jack off". If pa is configured to use jack if available then it would autoconnect to the jack-sink/source after a "pactl -jack on" and reconnect to alsa-sink/source after "pactl -jack off".

pactl then has all the code for handling dbus issues and jack has two simple calls to pactl.












_______________________________________________
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 10:12:14PM -0400, Paul Davis wrote:

> 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?

Even more simple solutions that will take even less of
your time:

1. Run Jack as permanent service, run PA as Jack client
when the user logs in (for users wanting both at a time).

2. Run Jack from a script that talks in whatever
civilised (dbus ?) or uncivilised (killall) way
to PA, runs jackd, waits for it to terminate,
restarts PA.
Lots of programs today are run from scripts like that.
It's completely invisible to the naive user and remains
easily run-time configurable for the more savvy ones.

3. Use qjackctl's Startup/Shutdown scripts, which
is similar to 2).


For me any decision to create a no-nonsense jackd
fork would be a purely economic one. The one-time
expense to do this could  be considerably less than
the continuous burden of having to deal with things
that I don't use.


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

[Stéphane Letz]

It is maybe time to clearly express our position at Grame. The  
following is part of a mail I've sent to Paul some weeks ago.

I have to say that I'm quite worried and tired about what is going on.  
I've put a *lot* of time and energy in the past 2 years to try to keep  
things in a good shape into the JACK2 source tree, trying to integrate  
contributions/improvements from a lot of people (even if the DBus work  
was probably not integrated the way it should have been..) and in the  
hope it would finally reach a stable and robust state to be considered  
the "new JACK reference implementation".

Even if there is no official fork of the source code, we are not far  
from that. We at Grame cannot afford to put more time into trying to  
solve (probably without real effect..) those endless political issues.  
I had a discussion with Yann about the situation and the result is  
that we will continue to work on JACK(2) only if the overall situation  
can be clarified.

The latest discussion about JACK/DBus again shows a very interesting  
effect: a *lot* of people are ready to argue, we get *tons* of  
commenting mails, but when we shift on real *technical* proposals then  
almost nobody takes time to only comment, test and improve the  
sucessives proposal that have been sent.

I've sent several mail on the list ("Keeping "guardians" and "rebels"  
on the same boat", "Status of server control plug-ins branch"...) and  
I am still waiting for *real constructive* feedback : Nedko the main  
JACK/DBus contributor is supposed to say *something* please...

The JACK community is surely quite "fragile", contributing developers  
are very few.  We cannot afford to break it up into even smaller  
pieces. I guess it is time for the JACK community to mature a bit and  
find better ways to structure it's work, otherwise we'll end up with a  
even bigger "Linux audio is a mess" state...

Do we really want that?

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

[Ralf Mardorf]

OT:

Hi Stéphane :)

I can't contribute something to the thread, but your effort bear fruit.
Compliment!

Stéphane Letz wrote:
> I've put a *lot* of time and energy in the past 2 years to try to keep
> things in a good shape into the JACK2 source tree, trying to integrate
> contributions/improvements from a lot of people

While JACK1 isn't fine with my hardware and I'm convinced it's for many,
many people I know too, JACK2 is fine. There are still a lot of other
troubles I've got with Linux for rt-audio, but one major trouble is
solved by JACK2.

I wish you success!
Ralf

--
http://www.dailywav.com/1002/beginning.wav

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

[melanie-36]

<delurks>
As a DJ, I use my laptop for my gigs. But, obviously, that laptop
also does other things for me. Now, I'm running Fedora10/Gnome, and
I found out the hard way that uninstalling pulseaudio is not an
option on that distro. There is no setup for the audio backend gnome
uses, it uses pulse and is silent when unavailable. So, for normal
desktop use, I _have_ to have pulseaudio or I get no clicks and
pops, no chat message notifies and no sound from videos in my browser!

Needless to say, I hate it!

Pulse is woefully underdocumented, a property it seems to have
inherited from ALSA. I have been able to set up my laptop, by
explicitly forcing pulse to use dmix, to be able to run other ALSA
apps that have no pullse support. However, that is little help for
Jack, since Jack through dmix makes little sense. So, I'm still left
with the problem of disabling pulse.

 From this user's point of view, I would like to see one of 2 things:

- pulseaudio vanishing from gnome, so I can uninstall it
or
- pasuspender's functionality becoming part of the jack system so I
can be sure pulse is gone while jack runs.

The jack backend to pulse is useless to me, because i frequently see
jack shutting down by itself because of issues with my software. If
pulse used jack, that would likely require a reboot to get sound
back, a logout at the least. Unacceptable, since I never turn off my
machine unless taking it with me and I have valuable chat sessions
and logs open.

I don't want a system that starts Jack for me. I want to start, and
monitor, Jack through QJackctl. What I need is a way to kick that
damn pulseaudio off the device without all the pain that that
entails today.

I wish I knew why PA is being forced down my throat anyway!

Melanie

<relurks>

Patrick Shirkey wrote:

> 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.
>
>
>
>
> Patrick Shirkey
> Boost Hardware Ltd
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel@...
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

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

[Ralf Mardorf]

IMHO JACK and/ or something else should enable 'perfect' rt-audio and
rt-MIDI usage for LINUX. Crackling paper sounds when using the trash bin
etc. are stupid for audio work. If I e.g. need a sound notification for
incoming messages, I enable the beep in my computer case. I guess there
are some more important issues to solve, than to fit consumer needs and
producer, resp. professional needs for one Linux installation at the
same time. I won't have any problem if I couldn't watch a YouTube video,
while I'm producing music, or if I were a DJ, while making music for
profession.

Just my (perhaps unwanted) 2 cents ;).

Best,
Ralf

Melanie wrote:

> <delurks>
> As a DJ, I use my laptop for my gigs. But, obviously, that laptop also
> does other things for me. Now, I'm running Fedora10/Gnome, and I found
> out the hard way that uninstalling pulseaudio is not an option on that
> distro. There is no setup for the audio backend gnome uses, it uses
> pulse and is silent when unavailable. So, for normal desktop use, I
> _have_ to have pulseaudio or I get no clicks and pops, no chat message
> notifies and no sound from videos in my browser!
>
> Needless to say, I hate it!
>
> Pulse is woefully underdocumented, a property it seems to have
> inherited from ALSA. I have been able to set up my laptop, by
> explicitly forcing pulse to use dmix, to be able to run other ALSA
> apps that have no pullse support. However, that is little help for
> Jack, since Jack through dmix makes little sense. So, I'm still left
> with the problem of disabling pulse.
>
> From this user's point of view, I would like to see one of 2 things:
>
> - pulseaudio vanishing from gnome, so I can uninstall it
> or
> - pasuspender's functionality becoming part of the jack system so I
> can be sure pulse is gone while jack runs.
>
> The jack backend to pulse is useless to me, because i frequently see
> jack shutting down by itself because of issues with my software. If
> pulse used jack, that would likely require a reboot to get sound back,
> a logout at the least. Unacceptable, since I never turn off my machine
> unless taking it with me and I have valuable chat sessions and logs open.
>
> I don't want a system that starts Jack for me. I want to start, and
> monitor, Jack through QJackctl. What I need is a way to kick that damn
> pulseaudio off the device without all the pain that that entails today.
>
> I wish I knew why PA is being forced down my throat anyway!
>
> Melanie
>
> <relurks>
>
> Patrick Shirkey wrote:
>> 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.
>>
>>
>>
>>
>> Patrick Shirkey
>> Boost Hardware Ltd

--

http://www.dailywav.com/1002/beginning.wav

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

[Fons Adriaensen-2]

On Tue, Jun 16, 2009 at 11:26:05AM +0200, Stéphane Letz wrote:

> Even if there is no official fork of the source code, we are not far from
> that. We at Grame cannot afford to put more time into trying to solve
> (probably without real effect..) those endless political issues. I had a
> discussion with Yann about the situation and the result is that we will
> continue to work on JACK(2) only if the overall situation can be clarified.

That is quite understandable. But things like stopping PA
when starting jackd should not even be your or any jack
developer's problem at all.

We have an OS that makes it easy to do such things
without hard-coding them into a binary or creating
dependencies. Just use it.


I *do* have some ideological views on accomodating 'users
who don't want to learn anything', but they are irrelevant
here, and it's not those that make me act as a rebel.

It is *the way some of these things are done* that upsets
me, and apparently also some others. Some examples:

- If you want to create kid directories (Desktop, Games,
My_Documents etc.) in a user's home you can write a script
to do that, put it in /etc, and call it form /etc/bash_profile
which in turn will be executed whenever a user logs in on most
systems. That is the sane way to do it. It also allows
users who don't want this to remove it once and for all.

- Same if you want to mount a filesystem in the user's
home when he/she logs in. What is the point of this is
anohter matter - you could as well use a tmp directory
of course.

- If you want to stop PA (or do anything similar) when
starting jack, you rename jackd to jackd_bin and call it
from a script name jackd. There are dbus bindings in all
scripting languages I know of, so adding the code to
stop/start PA via dbus from such a script should be a
trivial exercise. And it does not and should not take
a second of work of the jack developers.


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

[Fons Adriaensen-2]

On Tue, Jun 16, 2009 at 12:18:10PM +0200, Melanie wrote:

> I don't want a system that starts Jack for me. I want to start, and
> monitor, Jack through QJackctl. What I need is a way to kick that damn
> pulseaudio off the device without all the pain that that entails today.

Qjackctl can be configured to run extra commands before
starting jack and after terminating it, see the second
tab of the setup window.

If those can't be used to stop/start PA (i don't know)
then there is _really_ something wrong with it.

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

[Jonatan Liljedahl]

Paul Davis wrote:

> 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.

But why not just default to PA as jack backend on a PA+JACK system?

--
/Jonatan         [ http://kymatica.com ]
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[melanie-36]

This is not about getting those things at the same time. I don't
want desktop sound while DJing. But I don't want to have to
uninstall desktop sound permanently just to make DJing possible.

Melanie

Ralf Mardorf wrote:

> IMHO JACK and/ or something else should enable 'perfect' rt-audio and
> rt-MIDI usage for LINUX. Crackling paper sounds when using the trash bin
> etc. are stupid for audio work. If I e.g. need a sound notification for
> incoming messages, I enable the beep in my computer case. I guess there
> are some more important issues to solve, than to fit consumer needs and
> producer, resp. professional needs for one Linux installation at the
> same time. I won't have any problem if I couldn't watch a YouTube video,
> while I'm producing music, or if I were a DJ, while making music for
> profession.
>
> Just my (perhaps unwanted) 2 cents ;).
>
> Best,
> Ralf
>
> Melanie wrote:
>> <delurks>
>> As a DJ, I use my laptop for my gigs. But, obviously, that laptop also
>> does other things for me. Now, I'm running Fedora10/Gnome, and I found
>> out the hard way that uninstalling pulseaudio is not an option on that
>> distro. There is no setup for the audio backend gnome uses, it uses
>> pulse and is silent when unavailable. So, for normal desktop use, I
>> _have_ to have pulseaudio or I get no clicks and pops, no chat message
>> notifies and no sound from videos in my browser!
>>
>> Needless to say, I hate it!
>>
>> Pulse is woefully underdocumented, a property it seems to have
>> inherited from ALSA. I have been able to set up my laptop, by
>> explicitly forcing pulse to use dmix, to be able to run other ALSA
>> apps that have no pullse support. However, that is little help for
>> Jack, since Jack through dmix makes little sense. So, I'm still left
>> with the problem of disabling pulse.
>>
>> From this user's point of view, I would like to see one of 2 things:
>>
>> - pulseaudio vanishing from gnome, so I can uninstall it
>> or
>> - pasuspender's functionality becoming part of the jack system so I
>> can be sure pulse is gone while jack runs.
>>
>> The jack backend to pulse is useless to me, because i frequently see
>> jack shutting down by itself because of issues with my software. If
>> pulse used jack, that would likely require a reboot to get sound back,
>> a logout at the least. Unacceptable, since I never turn off my machine
>> unless taking it with me and I have valuable chat sessions and logs open.
>>
>> I don't want a system that starts Jack for me. I want to start, and
>> monitor, Jack through QJackctl. What I need is a way to kick that damn
>> pulseaudio off the device without all the pain that that entails today.
>>
>> I wish I knew why PA is being forced down my throat anyway!
>>
>> Melanie
>>
>> <relurks>
>>
>> Patrick Shirkey wrote:
>>> 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.
>>>
>>>
>>>
>>>
>>> Patrick Shirkey
>>> Boost Hardware Ltd

_______________________________________________
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:24 AM, Patrick
Shirkey<pshirkey@...> wrote:

> 6:   Pulse audio provides a call for jack to signal and handles the process
> from there on. i.e jack could call "pactl -jack on", "pactl -jack off". If
> pa is configured to use jack if available then it would autoconnect to the
> jack-sink/source after a "pactl -jack on" and reconnect to alsa-sink/source
> after "pactl -jack off".
>
> pactl then has all the code for handling dbus issues and jack has two simple
> calls to pactl.

initial this looks like a very attractive solution, but ...

(a) its not clear how these commands are executed
(b) it seems to shift the "dependence" that some perceive from DBus
(an app-independent IPC bus) to PulseAudio (a component that may not
even be installed), and i'm having a hard time seeing how this is
superior.

waking up this morning, it occured to me that the real place for this
device acquire/release negotiation is in ALSA, but that's another
story altogether.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

On Tue, Jun 16, 2009 at 5:01 AM, Fons Adriaensen<fons@...> wrote:

> On Mon, Jun 15, 2009 at 10:12:14PM -0400, Paul Davis wrote:
>
>> 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?
>
> Even more simple solutions that will take even less of
> your time:

> 1. Run Jack as permanent service, run PA as Jack client
> when the user logs in (for users wanting both at a time).

this requires decision making at a level way outside of the membership
of this list. if you really believe that mainstream distributions
which package both PA and JACK are going to do this, then you're a
greater believer in <something> than me.

> 2. Run Jack from a script that talks in whatever
> civilised (dbus ?) or uncivilised (killall) way
> to PA, runs jackd, waits for it to terminate,
> restarts PA.
> Lots of programs today are run from scripts like that.
> It's completely invisible to the naive user and remains
> easily run-time configurable for the more savvy ones.

whose responsibility is it to create such a script?

> 3. Use qjackctl's Startup/Shutdown scripts, which
> is similar to 2).

you suggest that JACK users to rely on a specific GUI front end? this
sounds quite un-fons-ian.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fons Adriaensen-2]

On Tue, Jun 16, 2009 at 07:52:35AM -0400, Paul Davis wrote:

> On Tue, Jun 16, 2009 at 5:01 AM, Fons Adriaensen<fons@...> wrote:
>
> > 1. Run Jack as permanent service, run PA as Jack client
> > when the user logs in (for users wanting both at a time).
>
> this requires decision making at a level way outside of the membership
> of this list. if you really believe that mainstream distributions
> which package both PA and JACK are going to do this, then you're a
> greater believer in <something> than me.

Myabe I am :-). Anyway using PA and Jack at the same time
is probably something required by users who know how to
configure it.

 > > 2. Run Jack from a script that talks in whatever
> > civilised (dbus ?) or uncivilised (killall) way
> > to PA, runs jackd, waits for it to terminate,
> > restarts PA.
> > Lots of programs today are run from scripts like that.
> > It's completely invisible to the naive user and remains
> > easily run-time configurable for the more savvy ones.
>
> whose responsibility is it to create such a script?

Responsability exists either as 1) the result of formal
hierarchical organisation, or 2) when someone takes it
up on his/her own initiative.

1) If you assume there is some hierarchy in the way the
Linux world is organised, then it would be up to the
creators of a distro to ensure it all works together.
They have to make choices about zillions of other things
as well, it is the essence of their job, and ensuring
that Jack and PA can be used on the same system is not
essentially different from other things they have to
organise. If they can create user home dirs, configure
X11 and the network, add application menus to desktops,
then they can install a simple script to run jackd as
well. Which does of course not imply that it would not
be a good idea for the jack devs to supply such a script
for them to use.

2) In this context it is the user's responsability,
like everything else. Freedom and responsability
come and go together.

But all this besides the point: there is no need to
put such things into an application binary.

And if more application writers start hard-coding
system configuration details into their apps this
will in the long term just lead to lots of misery.
You would set a very bad example.


> > 3. Use qjackctl's Startup/Shutdown scripts, which
> > is similar to 2).
>
> you suggest that JACK users to rely on a specific
> GUI front end? this sounds quite un-fons-ian.

I don't suggest they rely on it. But many people _are_
using qjackctl, it provides a simple way to solve this
non-problem, so it would be silly not to use that.

BTW, this also illustrates how to handle such things.
Qjackctl does not have any startup/shutdown commands
hard coded into it. It calls external scripts to do
whatever is necessary, and that makes a lot of sense.
It is the most flexible way to do such things and it
does not create any dependencies.


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

[Jack O'Quin]

On Tue, Jun 16, 2009 at 6:49 AM, Paul Davis<paul@...> wrote:

> waking up this morning, it occured to me that the real place for this
> device acquire/release negotiation is in ALSA, but that's another
> story altogether.

The same idea had occurred to me, just a few minutes before reading
your message.

Since ALSA manages the resources to be shared, it should provide a
better arbitration mechanism.  This introduces no new dependencies,
since all potential sharers are ALSA clients already.
--
 joq
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

Le 16 juin 09 à 16:32, Jack O'Quin a écrit :

> On Tue, Jun 16, 2009 at 6:49 AM, Paul  
> Davis<paul@...> wrote:
>
>> waking up this morning, it occured to me that the real place for this
>> device acquire/release negotiation is in ALSA, but that's another
>> story altogether.
>
> The same idea had occurred to me, just a few minutes before reading
> your message.
>
> Since ALSA manages the resources to be shared, it should provide a
> better arbitration mechanism.  This introduces no new dependencies,
> since all potential sharers are ALSA clients already.
> --
> joq

So Lennart, what do you think of that?

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

[Rui Nuno Capela]

On Tue, June 16, 2009 14:27, Fons Adriaensen wrote:

> On Tue, Jun 16, 2009 at 07:52:35AM -0400, Paul Davis wrote:
>>> 3. Use qjackctl's Startup/Shutdown scripts, which
>>> is similar to 2).
>>
>> you suggest that JACK users to rely on a specific GUI front end? this
>> sounds quite un-fons-ian.
>
> I don't suggest they rely on it. But many people _are_
> using qjackctl, it provides a simple way to solve this non-problem, so it
> would be silly not to use that.
>
> BTW, this also illustrates how to handle such things.
> Qjackctl does not have any startup/shutdown commands
> hard coded into it. It calls external scripts to do whatever is necessary,
> and that makes a lot of sense. It is the most flexible way to do such
> things and it does not create any dependencies.
>

yep, and the startup/shutdown scripts could just be issuing stop/start
pulseaudio commands accordingly, probably via dbus-send, whether
applicable.


qjackctl has all this potential to workaround the pulseaudio dilemma. it
has been doing that for arts since the beginning--does anyone still ask
why there's this 'artsshell -q terminate` around.

ok, now's time for some recipe i would suggest myself. it goes as follows:

1. on qjackctl/setup/options,
   1.1 execute script before startup = stop/suspend pulseaudio;
   1.2 execute script after startup = start/resume/pulseaudio
w/jack-module-whatever;
   1.3 execute script before shutdown = stop/suspend pulseaudio
w/jack-module;
   1.4 execute script after shutdown = start/resume/pulseaudio as usual.

2. and what about the dreaded jackd auto-start functionality? sure this
can be regarded one gross hack, but just let your ~/.jackdrc file have
this line and force it a read-only file:

   /path/to/qjackctl --start

and there you have it: complete jackd/pulseaudio coexistence and desktop
integration :P

bear in mind that i have not tested any of 1. just because all my boxes
are complete pulseaudio-free and i don't have a clue on how exactly one
can start/stop pulseaudio anyhow or via the cli.

however 2. has been pretty the rule here and even better since Torben's
libflashsupport-jack advent, i can do all the youtube'ing automagically
without sound backends juggling :)

byee
--
rncbc aka Rui Nuno Capela
rncbc@...

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

[Esben Stien]

Melanie <melanie@...> writes:

> I found out the hard way that uninstalling pulseaudio is not an
> option on that distro.

I don't understand why this isn't crystal clear. Pulse is part of the
GNOME framework, so all "gnome" app use a uniform framework to play
sounds. These sounds exit through pulseaudio, which allows you to
choose backends, such as ALSA or JACK.

How is this not clear?.

> There is no setup for the audio backend gnome uses

Sure, pulse is the GNOME audio server and has backends. You don't want
every god damn app in gnome to have support for the myriads of sound
API's out there, do you?.

> Needless to say, I hate it!

What do you propose?. You want apps to have support for more than one
API?. This would be bloat and you don't have a unified GNOME platform,
then. You're also not remembering the fact that no apps whatsoever
should really access ALSA by itself.

> I have been able to set up my laptop, by explicitly forcing pulse to
> use dmix, to be able to run other ALSA apps that have no pullse
> support.

This doesn't make sense at all. No ALSA apps need support for
pulseaudio to be able to talk to pulse. Pulse has a pulse plugin for
ALSA, so all your ALSA apps are routed into pulseaudio, which then
exits out to ALSA. This way, you hide the device itself for ALSA
apps. This would also work for devices requiring exclusive access.

> However, that is little help for Jack, since Jack through dmix makes
> little sense. So, I'm still left with the problem of disabling
> pulse.

If pulse doesn't allow itself to be detached from the audio device,
then this must of course be fixed, cause that's stupid. I never have
encountered this problem, cause I always run pulse on top of JACK.

> - pulseaudio vanishing from gnome, so I can uninstall it

This will never happen. If you think about it, you probably don't want
this to happen either. What would be the alternative?.

JACK is not an alternative for core GNOME apps today, because it
addresses totally different needs.

> - pasuspender's functionality becoming part of the jack system so I
>   can be sure pulse is gone while jack runs.

Right, or some dynamically way to configure pulse, so that it can
change backend at runtime.

Why is not Lennart taking part in these discussions?. (cc)

> What I need is a way to kick that damn pulseaudio off the device
> without all the pain that that entails today.

Indeed

> I wish I knew why PA is being forced down my throat anyway!

Because it's part of the GNOME framework. I think it makes a lot of
sense, though. Pulse and JACK currently handles different needs, but
for me atleast, they cooperate very nicely. After reading all these
mails, it's obvious that it doesn't work nicely for everybody and this
needs to be addressed. I run my own distro, so I always set up things
my own way and make sure they work for my needs. Probably why I don't
experience all the issues you all see.

--
Esben Stien is b0ef@e     s      a            
         http://www. s     t    n m
          irc://irc.  b  -  i  .   e/%23contact
           sip:b0ef@   e     e
           jid:b0ef@    n     n
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

On Tue, Jun 16, 2009 at 11:53 AM, Esben Stien<b0ef@...> wrote:
> Melanie <melanie@...> writes:
>
>> I found out the hard way that uninstalling pulseaudio is not an
>> option on that distro.
>
> I don't understand why this isn't crystal clear. Pulse is part of the
> GNOME framework, so all "gnome" app use a uniform framework to play
> sounds. These sounds exit through pulseaudio, which allows you to
> choose backends, such as ALSA or JACK.

This is a bit misleading. PulseAudio is, to this very day, explicitly
noted to be *NOT* an API that applications should use for audio I/O.
Instead it is a system to gather, collect, manage and do other cool
stuff with whatever APIs the application *are* using. Consequently, PA
is no more a uniform framework for apps to play sound inside GNOME
than JACK is uniform framework for apps to play sound on OS X. It
works, but it is actually not required by any apps other than those
that are actually part of PA. I de-installed PA from my Fedora 10
systems and had no issues at all, as i expected.

> What do you propose?. You want apps to have support for more than one
> API?. This would be bloat and you don't have a unified GNOME platform,
> then. You're also not remembering the fact that no apps whatsoever
> should really access ALSA by itself.

This is close to being the opposite of the advice on the PA website.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[melanie-36]

Uninstalling pulseaudio from Fedora 10 disabled desktop sounds (pops
and clicks) and sound played from within the packaged flash plugin.

Melanie

Paul Davis wrote:

> On Tue, Jun 16, 2009 at 11:53 AM, Esben Stien<b0ef@...> wrote:
>> Melanie <melanie@...> writes:
>>
>>> I found out the hard way that uninstalling pulseaudio is not an
>>> option on that distro.
>>
>> I don't understand why this isn't crystal clear. Pulse is part of the
>> GNOME framework, so all "gnome" app use a uniform framework to play
>> sounds. These sounds exit through pulseaudio, which allows you to
>> choose backends, such as ALSA or JACK.
>
> This is a bit misleading. PulseAudio is, to this very day, explicitly
> noted to be *NOT* an API that applications should use for audio I/O.
> Instead it is a system to gather, collect, manage and do other cool
> stuff with whatever APIs the application *are* using. Consequently, PA
> is no more a uniform framework for apps to play sound inside GNOME
> than JACK is uniform framework for apps to play sound on OS X. It
> works, but it is actually not required by any apps other than those
> that are actually part of PA. I de-installed PA from my Fedora 10
> systems and had no issues at all, as i expected.
>
>> What do you propose?. You want apps to have support for more than one
>> API?. This would be bloat and you don't have a unified GNOME platform,
>> then. You're also not remembering the fact that no apps whatsoever
>> should really access ALSA by itself.
>
> This is close to being the opposite of the advice on the PA website.
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel@...
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>
>

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

[Paul Davis]

On Tue, Jun 16, 2009 at 11:30 AM, Melanie<melanie@...> wrote:
> Uninstalling pulseaudio from Fedora 10 disabled desktop sounds (pops and
> clicks) and sound played from within the packaged flash plugin.

ok. i never use desktop sounds, and there is no 64 bit flash. that
would explain my experience.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org