Setting pulse not to grab a particular sound device

[Ng Oon-Ee]

I've been lurking round the jack-devel list, following the dbus
'thread' (I believe something of this magnitude is more a rope than a
thread, though). Someone mentioned PA grabbing everything, in the case
of more than one sound cards in the machine (as is the case with all
pro-audio setups, I believe).

Besides the solution that Lennart mentioned, pavucontrol, this can be
automated by editing /etc/pulse/default.pa, removing the lines
concerning module-hal-detect, and manually loading
module-alsa-sink/source with the correct hw parameters. This would be
more convenient for scripts/packagers, whatever.

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

[Lennart Poettering-16]

On Wed, 17.06.09 07:04, Ng Oon-Ee (ngoonee@...) wrote:

> I've been lurking round the jack-devel list, following the dbus
> 'thread' (I believe something of this magnitude is more a rope than a
> thread, though). Someone mentioned PA grabbing everything, in the case
> of more than one sound cards in the machine (as is the case with all
> pro-audio setups, I believe).
>
> Besides the solution that Lennart mentioned, pavucontrol, this can be
> automated by editing /etc/pulse/default.pa, removing the lines
> concerning module-hal-detect, and manually loading
> module-alsa-sink/source with the correct hw parameters. This would be
> more convenient for scripts/packagers, whatever.

Which I can only advise against. For many reasons: breaks hotplug,
module-alsa-sink/-source are obsolete, unstable device names, and so
on and so on.

Just use pavucontrol or just upgrade to JACK2 and everything starts to
work witout any further intervention due to the mentioned device
reservation logic.

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

[Ng Oon-Ee]

On Wed, 2009-06-17 at 01:29 +0200, Lennart Poettering wrote:

> On Wed, 17.06.09 07:04, Ng Oon-Ee (ngoonee@...) wrote:
>
> > I've been lurking round the jack-devel list, following the dbus
> > 'thread' (I believe something of this magnitude is more a rope than a
> > thread, though). Someone mentioned PA grabbing everything, in the case
> > of more than one sound cards in the machine (as is the case with all
> > pro-audio setups, I believe).
> >
> > Besides the solution that Lennart mentioned, pavucontrol, this can be
> > automated by editing /etc/pulse/default.pa, removing the lines
> > concerning module-hal-detect, and manually loading
> > module-alsa-sink/source with the correct hw parameters. This would be
> > more convenient for scripts/packagers, whatever.
>
> Which I can only advise against. For many reasons: breaks hotplug,
> module-alsa-sink/-source are obsolete, unstable device names, and so
> on and so on.
>
> Just use pavucontrol or just upgrade to JACK2 and everything starts to
> work witout any further intervention due to the mentioned device
> reservation logic.
>
> Lennart
>

Hi Lennart,

Would there be a script-based alternative to the pavucontrol method,
then? Or is Jack2 'it' in that sense?

As I have previously mentioned on the pulse list, the reason I turn off
hotplug through HAL is so I can, through scripts, define whether I want
PA accessing my sound card or my jack server (via
module-jack-sink/source). I admit to a lack of understanding on the
specifics of the new JACK2 device reservation, as well as the dbus
hoo-ha surrounding it, but it seems to me that the general effect would
be to suspend PA totally when JACK2 starts and resume it when JACK2
finishes. Is this understanding correct?

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

[Lennart Poettering-16]

On Wed, 17.06.09 07:35, Ng Oon-Ee (ngoonee@...) wrote:

> Hi Lennart,
>
> Would there be a script-based alternative to the pavucontrol method,
> then? Or is Jack2 'it' in that sense?

pactl set-card-profile foo off

> As I have previously mentioned on the pulse list, the reason I turn off
> hotplug through HAL is so I can, through scripts, define whether I want
> PA accessing my sound card or my jack server (via
> module-jack-sink/source). I admit to a lack of understanding on the
> specifics of the new JACK2 device reservation, as well as the dbus
> hoo-ha surrounding it, but it seems to me that the general effect would
> be to suspend PA totally when JACK2 starts and resume it when JACK2
> finishes. Is this understanding correct?

The device reservation logic is (as the name suggests...) per
device. i.e. only the device jack asks for will be released. And when
JACK goes away PA will again take posession of it. While the device is
taken by jack it is marked 'suspended' in PA.

And what I was proposing at the beginning of that other thread is that
if Jack takes a service name on the bus PA could watch for it and load
the connectivity modules automatically, providing some ports in jack
that folks can connect if they wish.

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

[Lennart Poettering-8]

On Wed, 17.06.09 02:22, Fons Adriaensen (fons@...) wrote:

>
> On Wed, Jun 17, 2009 at 01:57:40AM +0200, Lennart Poettering wrote:
>
> > And what I was proposing at the beginning of that other thread is that
> > if Jack takes a service name on the bus PA could watch for it and load
> > the connectivity modules automatically, providing some ports in jack
> > that folks can connect if they wish.
>
> I'm trying to understand this and failing (but maybe
> at 02:25 it's just too late).
>
> "some ports in jack that folks can connect if they wish"
>
> If jack has taken over a particular sound card, and
> created its own ports for that card, what would those
> ports you refer to represent ? Applications ?

Yes. Everything that doesn't use JACK natively but does support PA
would appear on those ports, since JACK would appear as virtual sound
card inside of PA.

Initially, when I wrote the PA/JACK connectivity modules for PA I
wrote it mostly as a toy and to understand jack better, not because it
really made much sense to me to use them for anything serious.

However as it turned out the lines between audio production and
desktop audio are blurred and a lot of folks seem to be using those
modules and have been asking for closer integration. And heck, maybe
it even makes sense, dunno.

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

[Ng Oon-Ee]

On Wed, 2009-06-17 at 01:57 +0200, Lennart Poettering wrote:

> On Wed, 17.06.09 07:35, Ng Oon-Ee (ngoonee@...) wrote:
>
> > Hi Lennart,
> >
> > Would there be a script-based alternative to the pavucontrol method,
> > then? Or is Jack2 'it' in that sense?
>
> pactl set-card-profile foo off
>
> > As I have previously mentioned on the pulse list, the reason I turn off
> > hotplug through HAL is so I can, through scripts, define whether I want
> > PA accessing my sound card or my jack server (via
> > module-jack-sink/source). I admit to a lack of understanding on the
> > specifics of the new JACK2 device reservation, as well as the dbus
> > hoo-ha surrounding it, but it seems to me that the general effect would
> > be to suspend PA totally when JACK2 starts and resume it when JACK2
> > finishes. Is this understanding correct?
>
> The device reservation logic is (as the name suggests...) per
> device. i.e. only the device jack asks for will be released. And when
> JACK goes away PA will again take posession of it. While the device is
> taken by jack it is marked 'suspended' in PA.
>
> And what I was proposing at the beginning of that other thread is that
> if Jack takes a service name on the bus PA could watch for it and load
> the connectivity modules automatically, providing some ports in jack
> that folks can connect if they wish.
>
> Lennart
>

Thank you. That does indeed seem a simple and powerful way of handling
it (ref. your last paragraph).

Apologies to others on this list for the non-dbus-related noise.

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

[Patrick Shirkey]

On 06/17/2009 06:57 AM, Lennart Poettering wrote:

On Wed, 17.06.09 07:35, Ng Oon-Ee (ngoonee@...) wrote:

  

Hi Lennart,

Would there be a script-based alternative to the pavucontrol method,
then? Or is Jack2 'it' in that sense?
    

pactl set-card-profile foo off

  

As I have previously mentioned on the pulse list, the reason I turn off
hotplug through HAL is so I can, through scripts, define whether I want
PA accessing my sound card or my jack server (via
module-jack-sink/source). I admit to a lack of understanding on the
specifics of the new JACK2 device reservation, as well as the dbus
hoo-ha surrounding it, but it seems to me that the general effect would
be to suspend PA totally when JACK2 starts and resume it when JACK2
finishes. Is this understanding correct?
    

The device reservation logic is (as the name suggests...) per
device. i.e. only the device jack asks for will be released. And when
JACK goes away PA will again take posession of it. While the device is
taken by jack it is marked 'suspended' in PA.

And what I was proposing at the beginning of that other thread is that
if Jack takes a service name on the bus PA could watch for it and load
the connectivity modules automatically, providing some ports in jack
that folks can connect if they wish.

  

I missed this initial post.

IMO, this is the final step in the fundamental logic required to have jack and pa work together nicely.

>From there on it would be a matter of enough people testing the system to fine tune the stability.

My machine is now fully updated with fedora 11 so I will be very happy to assist with testing this proposed solution.

Please let me know what I can do to help.



Cheers.





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

[melanie-36]

Obsolete? You mean to tell us that the only provided means to do a
full manual configuration (not depending on HAL/Hotplug) will be
removed?!
Not everyone wants Plug-n-Pray!

Melanie

Lennart Poettering wrote:

> On Wed, 17.06.09 07:04, Ng Oon-Ee (ngoonee@...) wrote:
>
>> I've been lurking round the jack-devel list, following the dbus
>> 'thread' (I believe something of this magnitude is more a rope than a
>> thread, though). Someone mentioned PA grabbing everything, in the case
>> of more than one sound cards in the machine (as is the case with all
>> pro-audio setups, I believe).
>>
>> Besides the solution that Lennart mentioned, pavucontrol, this can be
>> automated by editing /etc/pulse/default.pa, removing the lines
>> concerning module-hal-detect, and manually loading
>> module-alsa-sink/source with the correct hw parameters. This would be
>> more convenient for scripts/packagers, whatever.
>
> Which I can only advise against. For many reasons: breaks hotplug,
> module-alsa-sink/-source are obsolete, unstable device names, and so
> on and so on.
>
> Just use pavucontrol or just upgrade to JACK2 and everything starts to
> work witout any further intervention due to the mentioned device
> reservation logic.
>
> Lennart
>

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

[Lennart Poettering-16]

On Wed, 17.06.09 04:01, Fons Adriaensen (fons@...) wrote:

> > > If jack has taken over a particular sound card, and
> > > created its own ports for that card, what would those
> > > ports you refer to represent ? Applications ?
> >
> > Yes. Everything that doesn't use JACK natively but does support PA
> > would appear on those ports, since JACK would appear as virtual sound
> > card inside of PA.
>
> Which would mean that PA, depending on which 'sound card'
> it is using, would be either a Jack client, or be independent
> when using another card ?

Yes.

> But could PA do both at the same time - I mean routing
> one app to Jack and another to a second sound card ?
> Since PA seems to be able to do strange things I would
> not be surprised - but at the same time I won't believe
> it until you confirm it :-)

Yes. PA can handle multiple backends at the same time. You can even
move active streams between all active backends.

> > Initially, when I wrote the PA/JACK connectivity modules for PA I
> > wrote it mostly as a toy and to understand jack better, not because it
> > really made much sense to me to use them for anything serious.
> >
> > However as it turned out the lines between audio production and
> > desktop audio are blurred and a lot of folks seem to be using those
> > modules and have been asking for closer integration. And heck, maybe
> > it even makes sense, dunno.
>
> I think it makes a *lot* of sense. As I said before, I
> don't use PA not because I hate it, but because I don't
> need it, and until now it just got in my way so I removed
> it. But if it could operate as a Jack client I wouldn't
> mind having it running. As long as it doesn't autoconnect
> that is - it would be to the wrong ports most of the time
> and I've already been paying real cash for the damage caused
> by apps doing that.  

autoconnect is available, but optional.

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

[Lennart Poettering-16]

On Wed, 17.06.09 11:50, Melanie (melanie@...) wrote:

>
> Obsolete? You mean to tell us that the only provided means to do a full
> manual configuration (not depending on HAL/Hotplug) will be removed?!
> Not everyone wants Plug-n-Pray!

module-alsa-sink/-source are useful  only in very few cases. It's far
more useful to use module-alsa-card, which is a combination of both
but a bit more intelligent in many ways.

Also, I don't see why manual configuration could have any benefit here.

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

[melanie-36]

Well, I already gathered that you are the one who is in favor of a
completely automagical solution - however, I like control, as
fine-grained control as possible. So I have to spend a day on
setting up a new system - but afterwards I know exactly what it does
and why. No unpleasant surprises later on when hardware is
added/removed, or things switched from one USB port to another, etc,
etc, etc...

Not saying that autoconfiguration and plug&play are evil, they're
just not what I want in my Linux.

Melanie


Lennart Poettering wrote:

> On Wed, 17.06.09 11:50, Melanie (melanie@...) wrote:
>
>>
>> Obsolete? You mean to tell us that the only provided means to do a full
>> manual configuration (not depending on HAL/Hotplug) will be removed?!
>> Not everyone wants Plug-n-Pray!
>
> module-alsa-sink/-source are useful  only in very few cases. It's far
> more useful to use module-alsa-card, which is a combination of both
> but a bit more intelligent in many ways.
>
> Also, I don't see why manual configuration could have any benefit here.
>
> Lennart
>

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