Hi everybody,

I've got an onboard soundcard and two usb soundcards and I'd like it
if pulseaudio could switch automatically the default sound card (or
default sink to be more precise) depending on the soundcards that are
currently plugged in. Is this possible?

In case it's not clear what I want, let me explain it on an example:

I've got three soundcards: my onboard card (sd1), my usb card (sd2)
and my headset (sd3) and I want the default card to be the one with
the highest numbering in the sdX naming scheme that is currently
attached to the system.



Thanks,

Geralt.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

Hi everybody,

I've got an onboard soundcard and two usb soundcards and I'd like it
if pulseaudio could switch automatically the default sound card (or
default sink to be more precise) depending on the soundcards that are
currently plugged in. Is this possible?

In case it's not clear what I want, let me explain it on an example:

I've got three soundcards: my onboard card (sd1), my usb card (sd2)
and my headset (sd3) and I want the default card to be the one with
the highest numbering in the sdX naming scheme that is currently
attached to the system.



Thanks,

Geralt.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Dnia 2010-06-11, piÄ… o godzinie 23:37 +0200, Geralt pisze:
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Eh? No idea what sdX mean here.

If you want your audio to be heard over headset, then usb card, then
onboard card, depending on which are available, just set them as
fallbacks with pavucontrol or gnome-volume-control in the reverse
direction (that's - connect your usb card, set it as fallback, then
connect your headset and set that as fallback). That should be enough in
at least with a recent enough PA.

--

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

Hi everybody,

I've got an onboard soundcard and two usb soundcards and I'd like it
if pulseaudio could switch automatically the default sound card (or
default sink to be more precise) depending on the soundcards that are
currently plugged in. Is this possible?

In case it's not clear what I want, let me explain it on an example:

I've got three soundcards: my onboard card (sd1), my usb card (sd2)
and my headset (sd3) and I want the default card to be the one with
the highest numbering in the sdX naming scheme that is currently
attached to the system.



Thanks,

Geralt.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Dnia 2010-06-11, piÄ… o godzinie 23:37 +0200, Geralt pisze:
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Eh? No idea what sdX mean here.

If you want your audio to be heard over headset, then usb card, then
onboard card, depending on which are available, just set them as
fallbacks with pavucontrol or gnome-volume-control in the reverse
direction (that's - connect your usb card, set it as fallback, then
connect your headset and set that as fallback). That should be enough in
at least with a recent enough PA.

--

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
> Hi everybody,
>
> I've got an onboard soundcard and two usb soundcards and I'd like it
> if pulseaudio could switch automatically the default sound card (or
> default sink to be more precise) depending on the soundcards that are
> currently plugged in. Is this possible?
>
> In case it's not clear what I want, let me explain it on an example:
>
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Bascially you want a priority list of defaults and the current default
to the the highest priority available device to be the one used?

This is possible but no GUI exists on Gnome to exploit it just yet.

This is the routing policy used under KDE, and the PA module
module-device-manager implements this in PulseAudio.

Sadly my proposal to make PA's routing policy work in a (IMO) much more
sensible way, has not yet been endorsed by Lennart so I've not started
working on it. I'm pretty confident that even with some issues it
creates, it's a far more sensible configuration system than is currently
available.

The behaviour you describe would work perfectly under this setup, even
if the priority list itself is never actually exposed to the user via
confirguration GUIs.

Even the current module-default-device-restore does not actually work on
hotplug etc. (as the default is worked out at startup and then set, so
it's idea of the "default device" is lost).

Here is my proposal:
http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/


Hopefully when Lennart is less busy, we can revisit the discussions and
I can convince him I'm right!

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

Hi everybody,

I've got an onboard soundcard and two usb soundcards and I'd like it
if pulseaudio could switch automatically the default sound card (or
default sink to be more precise) depending on the soundcards that are
currently plugged in. Is this possible?

In case it's not clear what I want, let me explain it on an example:

I've got three soundcards: my onboard card (sd1), my usb card (sd2)
and my headset (sd3) and I want the default card to be the one with
the highest numbering in the sdX naming scheme that is currently
attached to the system.



Thanks,

Geralt.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Dnia 2010-06-11, piÄ… o godzinie 23:37 +0200, Geralt pisze:
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Eh? No idea what sdX mean here.

If you want your audio to be heard over headset, then usb card, then
onboard card, depending on which are available, just set them as
fallbacks with pavucontrol or gnome-volume-control in the reverse
direction (that's - connect your usb card, set it as fallback, then
connect your headset and set that as fallback). That should be enough in
at least with a recent enough PA.

--

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
> Hi everybody,
>
> I've got an onboard soundcard and two usb soundcards and I'd like it
> if pulseaudio could switch automatically the default sound card (or
> default sink to be more precise) depending on the soundcards that are
> currently plugged in. Is this possible?
>
> In case it's not clear what I want, let me explain it on an example:
>
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Bascially you want a priority list of defaults and the current default
to the the highest priority available device to be the one used?

This is possible but no GUI exists on Gnome to exploit it just yet.

This is the routing policy used under KDE, and the PA module
module-device-manager implements this in PulseAudio.

Sadly my proposal to make PA's routing policy work in a (IMO) much more
sensible way, has not yet been endorsed by Lennart so I've not started
working on it. I'm pretty confident that even with some issues it
creates, it's a far more sensible configuration system than is currently
available.

The behaviour you describe would work perfectly under this setup, even
if the priority list itself is never actually exposed to the user via
confirguration GUIs.

Even the current module-default-device-restore does not actually work on
hotplug etc. (as the default is worked out at startup and then set, so
it's idea of the "default device" is lost).

Here is my proposal:
http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/


Hopefully when Lennart is less busy, we can revisit the discussions and
I can convince him I'm right!

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

thanks for your replies :-)

> Dnia 2010-06-11, pi± o godzinie 23:37 +0200, Geralt pisze:
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Eh? No idea what sdX mean here.
>
I was refering to either sd1, sd2 or sd3.

> If you want your audio to be heard over headset, then usb card, then
> onboard card, depending on which are available, just set them as
> fallbacks with pavucontrol or gnome-volume-control in the reverse
> direction (that's - connect your usb card, set it as fallback, then
> connect your headset and set that as fallback). That should be enough in
> at least with a recent enough PA.
>
That's exactly what I want and thanks for mentioning pavucontrol, I
didn't know of this application (I've basically zero experience with
Pulseaudio, yet).

> 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
>> Hi everybody,
>>
>> I've got an onboard soundcard and two usb soundcards and I'd like it
>> if pulseaudio could switch automatically the default sound card (or
>> default sink to be more precise) depending on the soundcards that are
>> currently plugged in. Is this possible?
>>
>> In case it's not clear what I want, let me explain it on an example:
>>
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Bascially you want a priority list of defaults and the current default
> to the the highest priority available device to be the one used?
>
> This is possible but no GUI exists on Gnome to exploit it just yet.
>
> This is the routing policy used under KDE, and the PA module
> module-device-manager implements this in PulseAudio.
>
> Sadly my proposal to make PA's routing policy work in a (IMO) much more
> sensible way, has not yet been endorsed by Lennart so I've not started
> working on it. I'm pretty confident that even with some issues it
> creates, it's a far more sensible configuration system than is currently
> available.
>
> The behaviour you describe would work perfectly under this setup, even
> if the priority list itself is never actually exposed to the user via
> confirguration GUIs.
>
> Even the current module-default-device-restore does not actually work on
> hotplug etc. (as the default is worked out at startup and then set, so
> it's idea of the "default device" is lost).
>
> Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
>
> Hopefully when Lennart is less busy, we can revisit the discussions and
> I can convince him I'm right!
>
That is exactly what I want, however I don't use KDE, is there still a
way to use youre pulseaudio module?



Geralt
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

Hi everybody,

I've got an onboard soundcard and two usb soundcards and I'd like it
if pulseaudio could switch automatically the default sound card (or
default sink to be more precise) depending on the soundcards that are
currently plugged in. Is this possible?

In case it's not clear what I want, let me explain it on an example:

I've got three soundcards: my onboard card (sd1), my usb card (sd2)
and my headset (sd3) and I want the default card to be the one with
the highest numbering in the sdX naming scheme that is currently
attached to the system.



Thanks,

Geralt.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Dnia 2010-06-11, piÄ… o godzinie 23:37 +0200, Geralt pisze:
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Eh? No idea what sdX mean here.

If you want your audio to be heard over headset, then usb card, then
onboard card, depending on which are available, just set them as
fallbacks with pavucontrol or gnome-volume-control in the reverse
direction (that's - connect your usb card, set it as fallback, then
connect your headset and set that as fallback). That should be enough in
at least with a recent enough PA.

--

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
> Hi everybody,
>
> I've got an onboard soundcard and two usb soundcards and I'd like it
> if pulseaudio could switch automatically the default sound card (or
> default sink to be more precise) depending on the soundcards that are
> currently plugged in. Is this possible?
>
> In case it's not clear what I want, let me explain it on an example:
>
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Bascially you want a priority list of defaults and the current default
to the the highest priority available device to be the one used?

This is possible but no GUI exists on Gnome to exploit it just yet.

This is the routing policy used under KDE, and the PA module
module-device-manager implements this in PulseAudio.

Sadly my proposal to make PA's routing policy work in a (IMO) much more
sensible way, has not yet been endorsed by Lennart so I've not started
working on it. I'm pretty confident that even with some issues it
creates, it's a far more sensible configuration system than is currently
available.

The behaviour you describe would work perfectly under this setup, even
if the priority list itself is never actually exposed to the user via
confirguration GUIs.

Even the current module-default-device-restore does not actually work on
hotplug etc. (as the default is worked out at startup and then set, so
it's idea of the "default device" is lost).

Here is my proposal:
http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/


Hopefully when Lennart is less busy, we can revisit the discussions and
I can convince him I'm right!

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

thanks for your replies :-)

> Dnia 2010-06-11, pi± o godzinie 23:37 +0200, Geralt pisze:
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Eh? No idea what sdX mean here.
>
I was refering to either sd1, sd2 or sd3.

> If you want your audio to be heard over headset, then usb card, then
> onboard card, depending on which are available, just set them as
> fallbacks with pavucontrol or gnome-volume-control in the reverse
> direction (that's - connect your usb card, set it as fallback, then
> connect your headset and set that as fallback). That should be enough in
> at least with a recent enough PA.
>
That's exactly what I want and thanks for mentioning pavucontrol, I
didn't know of this application (I've basically zero experience with
Pulseaudio, yet).

> 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
>> Hi everybody,
>>
>> I've got an onboard soundcard and two usb soundcards and I'd like it
>> if pulseaudio could switch automatically the default sound card (or
>> default sink to be more precise) depending on the soundcards that are
>> currently plugged in. Is this possible?
>>
>> In case it's not clear what I want, let me explain it on an example:
>>
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Bascially you want a priority list of defaults and the current default
> to the the highest priority available device to be the one used?
>
> This is possible but no GUI exists on Gnome to exploit it just yet.
>
> This is the routing policy used under KDE, and the PA module
> module-device-manager implements this in PulseAudio.
>
> Sadly my proposal to make PA's routing policy work in a (IMO) much more
> sensible way, has not yet been endorsed by Lennart so I've not started
> working on it. I'm pretty confident that even with some issues it
> creates, it's a far more sensible configuration system than is currently
> available.
>
> The behaviour you describe would work perfectly under this setup, even
> if the priority list itself is never actually exposed to the user via
> confirguration GUIs.
>
> Even the current module-default-device-restore does not actually work on
> hotplug etc. (as the default is worked out at startup and then set, so
> it's idea of the "default device" is lost).
>
> Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
>
> Hopefully when Lennart is less busy, we can revisit the discussions and
> I can convince him I'm right!
>
That is exactly what I want, however I don't use KDE, is there still a
way to use youre pulseaudio module?



Geralt
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/

In my humble opinion....

Device by media.role is not that great.. it stand up for events, but
it should really be be per client (application)

The major use cases i have right now that suck... and are not solvable
without prior knowledge of how pa works
1 - If I plug in my USB or Bluetooth headset the music does not
change to headset like my analogue headset does...
2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
not be set to use that mic without restarting skype?
3 - There no way to easily set the media role or an app that dosn't
have one (yes the all should have a role but they don't), pa could be
doing better here using desktop files and the role should be saved..
4 - Videos do not cork music

By default I think pa should:
- Move all inputs and outputs to any newly connected local device (ie
usb, bluetooth whatever) that appears after pa has started (unless the
per client device has been set of course)
- There should be a simple UI for setting a clients default media
role (if one has not been set), and this role should be remembered by
pa
- Streams should inherit media role from the client if they don't
have one set... ie firefox is set to video, so all its streams have a
media role of video
- A module to cork music when video is playing

Those 4 things would solve every problem I can think of and make pa
function as I think 90% desktop users expect

Cheers


--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

Hi everybody,

I've got an onboard soundcard and two usb soundcards and I'd like it
if pulseaudio could switch automatically the default sound card (or
default sink to be more precise) depending on the soundcards that are
currently plugged in. Is this possible?

In case it's not clear what I want, let me explain it on an example:

I've got three soundcards: my onboard card (sd1), my usb card (sd2)
and my headset (sd3) and I want the default card to be the one with
the highest numbering in the sdX naming scheme that is currently
attached to the system.



Thanks,

Geralt.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Dnia 2010-06-11, piÄ… o godzinie 23:37 +0200, Geralt pisze:
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Eh? No idea what sdX mean here.

If you want your audio to be heard over headset, then usb card, then
onboard card, depending on which are available, just set them as
fallbacks with pavucontrol or gnome-volume-control in the reverse
direction (that's - connect your usb card, set it as fallback, then
connect your headset and set that as fallback). That should be enough in
at least with a recent enough PA.

--

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
> Hi everybody,
>
> I've got an onboard soundcard and two usb soundcards and I'd like it
> if pulseaudio could switch automatically the default sound card (or
> default sink to be more precise) depending on the soundcards that are
> currently plugged in. Is this possible?
>
> In case it's not clear what I want, let me explain it on an example:
>
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Bascially you want a priority list of defaults and the current default
to the the highest priority available device to be the one used?

This is possible but no GUI exists on Gnome to exploit it just yet.

This is the routing policy used under KDE, and the PA module
module-device-manager implements this in PulseAudio.

Sadly my proposal to make PA's routing policy work in a (IMO) much more
sensible way, has not yet been endorsed by Lennart so I've not started
working on it. I'm pretty confident that even with some issues it
creates, it's a far more sensible configuration system than is currently
available.

The behaviour you describe would work perfectly under this setup, even
if the priority list itself is never actually exposed to the user via
confirguration GUIs.

Even the current module-default-device-restore does not actually work on
hotplug etc. (as the default is worked out at startup and then set, so
it's idea of the "default device" is lost).

Here is my proposal:
http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/


Hopefully when Lennart is less busy, we can revisit the discussions and
I can convince him I'm right!

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

thanks for your replies :-)

> Dnia 2010-06-11, pi± o godzinie 23:37 +0200, Geralt pisze:
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Eh? No idea what sdX mean here.
>
I was refering to either sd1, sd2 or sd3.

> If you want your audio to be heard over headset, then usb card, then
> onboard card, depending on which are available, just set them as
> fallbacks with pavucontrol or gnome-volume-control in the reverse
> direction (that's - connect your usb card, set it as fallback, then
> connect your headset and set that as fallback). That should be enough in
> at least with a recent enough PA.
>
That's exactly what I want and thanks for mentioning pavucontrol, I
didn't know of this application (I've basically zero experience with
Pulseaudio, yet).

> 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
>> Hi everybody,
>>
>> I've got an onboard soundcard and two usb soundcards and I'd like it
>> if pulseaudio could switch automatically the default sound card (or
>> default sink to be more precise) depending on the soundcards that are
>> currently plugged in. Is this possible?
>>
>> In case it's not clear what I want, let me explain it on an example:
>>
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Bascially you want a priority list of defaults and the current default
> to the the highest priority available device to be the one used?
>
> This is possible but no GUI exists on Gnome to exploit it just yet.
>
> This is the routing policy used under KDE, and the PA module
> module-device-manager implements this in PulseAudio.
>
> Sadly my proposal to make PA's routing policy work in a (IMO) much more
> sensible way, has not yet been endorsed by Lennart so I've not started
> working on it. I'm pretty confident that even with some issues it
> creates, it's a far more sensible configuration system than is currently
> available.
>
> The behaviour you describe would work perfectly under this setup, even
> if the priority list itself is never actually exposed to the user via
> confirguration GUIs.
>
> Even the current module-default-device-restore does not actually work on
> hotplug etc. (as the default is worked out at startup and then set, so
> it's idea of the "default device" is lost).
>
> Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
>
> Hopefully when Lennart is less busy, we can revisit the discussions and
> I can convince him I'm right!
>
That is exactly what I want, however I don't use KDE, is there still a
way to use youre pulseaudio module?



Geralt
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/

In my humble opinion....

Device by media.role is not that great.. it stand up for events, but
it should really be be per client (application)

The major use cases i have right now that suck... and are not solvable
without prior knowledge of how pa works
1 - If I plug in my USB or Bluetooth headset the music does not
change to headset like my analogue headset does...
2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
not be set to use that mic without restarting skype?
3 - There no way to easily set the media role or an app that dosn't
have one (yes the all should have a role but they don't), pa could be
doing better here using desktop files and the role should be saved..
4 - Videos do not cork music

By default I think pa should:
- Move all inputs and outputs to any newly connected local device (ie
usb, bluetooth whatever) that appears after pa has started (unless the
per client device has been set of course)
- There should be a simple UI for setting a clients default media
role (if one has not been set), and this role should be remembered by
pa
- Streams should inherit media role from the client if they don't
have one set... ie firefox is set to video, so all its streams have a
media role of video
- A module to cork music when video is playing

Those 4 things would solve every problem I can think of and make pa
function as I think 90% desktop users expect

Cheers


--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Mon, 2010-06-14 at 09:59 +1200, Jason Taylor wrote:
> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video

No big issue with the rest of your proposals (besides the usual "who's
doing the work?" =p). However this one isn't a good idea, your web
browser plays tons of different things, alert sounds from web-apps,
videos (youtube and friends), audio from sites like pandora, game-sounds
from the various flash time-wasters. If this was classified as video, my
web-app giving me a new IM notification would cork my audio stream
(assuming your other proposals make it in)...

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

Hi everybody,

I've got an onboard soundcard and two usb soundcards and I'd like it
if pulseaudio could switch automatically the default sound card (or
default sink to be more precise) depending on the soundcards that are
currently plugged in. Is this possible?

In case it's not clear what I want, let me explain it on an example:

I've got three soundcards: my onboard card (sd1), my usb card (sd2)
and my headset (sd3) and I want the default card to be the one with
the highest numbering in the sdX naming scheme that is currently
attached to the system.



Thanks,

Geralt.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Dnia 2010-06-11, piÄ… o godzinie 23:37 +0200, Geralt pisze:
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Eh? No idea what sdX mean here.

If you want your audio to be heard over headset, then usb card, then
onboard card, depending on which are available, just set them as
fallbacks with pavucontrol or gnome-volume-control in the reverse
direction (that's - connect your usb card, set it as fallback, then
connect your headset and set that as fallback). That should be enough in
at least with a recent enough PA.

--

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
> Hi everybody,
>
> I've got an onboard soundcard and two usb soundcards and I'd like it
> if pulseaudio could switch automatically the default sound card (or
> default sink to be more precise) depending on the soundcards that are
> currently plugged in. Is this possible?
>
> In case it's not clear what I want, let me explain it on an example:
>
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Bascially you want a priority list of defaults and the current default
to the the highest priority available device to be the one used?

This is possible but no GUI exists on Gnome to exploit it just yet.

This is the routing policy used under KDE, and the PA module
module-device-manager implements this in PulseAudio.

Sadly my proposal to make PA's routing policy work in a (IMO) much more
sensible way, has not yet been endorsed by Lennart so I've not started
working on it. I'm pretty confident that even with some issues it
creates, it's a far more sensible configuration system than is currently
available.

The behaviour you describe would work perfectly under this setup, even
if the priority list itself is never actually exposed to the user via
confirguration GUIs.

Even the current module-default-device-restore does not actually work on
hotplug etc. (as the default is worked out at startup and then set, so
it's idea of the "default device" is lost).

Here is my proposal:
http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/


Hopefully when Lennart is less busy, we can revisit the discussions and
I can convince him I'm right!

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

thanks for your replies :-)

> Dnia 2010-06-11, pi± o godzinie 23:37 +0200, Geralt pisze:
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Eh? No idea what sdX mean here.
>
I was refering to either sd1, sd2 or sd3.

> If you want your audio to be heard over headset, then usb card, then
> onboard card, depending on which are available, just set them as
> fallbacks with pavucontrol or gnome-volume-control in the reverse
> direction (that's - connect your usb card, set it as fallback, then
> connect your headset and set that as fallback). That should be enough in
> at least with a recent enough PA.
>
That's exactly what I want and thanks for mentioning pavucontrol, I
didn't know of this application (I've basically zero experience with
Pulseaudio, yet).

> 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
>> Hi everybody,
>>
>> I've got an onboard soundcard and two usb soundcards and I'd like it
>> if pulseaudio could switch automatically the default sound card (or
>> default sink to be more precise) depending on the soundcards that are
>> currently plugged in. Is this possible?
>>
>> In case it's not clear what I want, let me explain it on an example:
>>
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Bascially you want a priority list of defaults and the current default
> to the the highest priority available device to be the one used?
>
> This is possible but no GUI exists on Gnome to exploit it just yet.
>
> This is the routing policy used under KDE, and the PA module
> module-device-manager implements this in PulseAudio.
>
> Sadly my proposal to make PA's routing policy work in a (IMO) much more
> sensible way, has not yet been endorsed by Lennart so I've not started
> working on it. I'm pretty confident that even with some issues it
> creates, it's a far more sensible configuration system than is currently
> available.
>
> The behaviour you describe would work perfectly under this setup, even
> if the priority list itself is never actually exposed to the user via
> confirguration GUIs.
>
> Even the current module-default-device-restore does not actually work on
> hotplug etc. (as the default is worked out at startup and then set, so
> it's idea of the "default device" is lost).
>
> Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
>
> Hopefully when Lennart is less busy, we can revisit the discussions and
> I can convince him I'm right!
>
That is exactly what I want, however I don't use KDE, is there still a
way to use youre pulseaudio module?



Geralt
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/

In my humble opinion....

Device by media.role is not that great.. it stand up for events, but
it should really be be per client (application)

The major use cases i have right now that suck... and are not solvable
without prior knowledge of how pa works
1 - If I plug in my USB or Bluetooth headset the music does not
change to headset like my analogue headset does...
2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
not be set to use that mic without restarting skype?
3 - There no way to easily set the media role or an app that dosn't
have one (yes the all should have a role but they don't), pa could be
doing better here using desktop files and the role should be saved..
4 - Videos do not cork music

By default I think pa should:
- Move all inputs and outputs to any newly connected local device (ie
usb, bluetooth whatever) that appears after pa has started (unless the
per client device has been set of course)
- There should be a simple UI for setting a clients default media
role (if one has not been set), and this role should be remembered by
pa
- Streams should inherit media role from the client if they don't
have one set... ie firefox is set to video, so all its streams have a
media role of video
- A module to cork music when video is playing

Those 4 things would solve every problem I can think of and make pa
function as I think 90% desktop users expect

Cheers


--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Mon, 2010-06-14 at 09:59 +1200, Jason Taylor wrote:
> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video

No big issue with the rest of your proposals (besides the usual "who's
doing the work?" =p). However this one isn't a good idea, your web
browser plays tons of different things, alert sounds from web-apps,
videos (youtube and friends), audio from sites like pandora, game-sounds
from the various flash time-wasters. If this was classified as video, my
web-app giving me a new IM notification would cork my audio stream
(assuming your other proposals make it in)...

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > No big issue with the rest of your proposals (besides the usual "who's
> doing the work?" =p).

If it would be accepted I would attempt to brush off my rusty c skills..
I'm just not sure how welcome this work would be in pa...

> However this one isn't a good idea, your web
> browser plays tons of different things, alert sounds from web-apps,
> videos (youtube and friends), audio from sites like pandora, game-sounds
> from the various flash time-wasters. If this was classified as video, my
> web-app giving me a new IM notification would cork my audio stream
> (assuming your other proposals make it in)...

The "browser" classification as video was just a suggestion for such a
generic player, nothing else really fits IIMHO.., if the stream was
tagged with correct media.role, then pa would use that, the "video"
would be a fall back position. If you kept your browser with no media
role then nothing would happen as now.. which sucks when viewing a
youtube video and having to open the music player and stop it so you
can hear the video..

html5 tags like video/audio would really help here but thats probably
3 to 5 years away of having any significant role..

I just realized I missed one other use case... pa has no concept of
window order..
- With 2 streams of the same role (other then notification) are
active the stream that has the higher client in the window stack
should be the active stream, all other streams should be corked

Cheers

--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

Hi everybody,

I've got an onboard soundcard and two usb soundcards and I'd like it
if pulseaudio could switch automatically the default sound card (or
default sink to be more precise) depending on the soundcards that are
currently plugged in. Is this possible?

In case it's not clear what I want, let me explain it on an example:

I've got three soundcards: my onboard card (sd1), my usb card (sd2)
and my headset (sd3) and I want the default card to be the one with
the highest numbering in the sdX naming scheme that is currently
attached to the system.



Thanks,

Geralt.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Dnia 2010-06-11, piÄ… o godzinie 23:37 +0200, Geralt pisze:
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Eh? No idea what sdX mean here.

If you want your audio to be heard over headset, then usb card, then
onboard card, depending on which are available, just set them as
fallbacks with pavucontrol or gnome-volume-control in the reverse
direction (that's - connect your usb card, set it as fallback, then
connect your headset and set that as fallback). That should be enough in
at least with a recent enough PA.

--

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
> Hi everybody,
>
> I've got an onboard soundcard and two usb soundcards and I'd like it
> if pulseaudio could switch automatically the default sound card (or
> default sink to be more precise) depending on the soundcards that are
> currently plugged in. Is this possible?
>
> In case it's not clear what I want, let me explain it on an example:
>
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Bascially you want a priority list of defaults and the current default
to the the highest priority available device to be the one used?

This is possible but no GUI exists on Gnome to exploit it just yet.

This is the routing policy used under KDE, and the PA module
module-device-manager implements this in PulseAudio.

Sadly my proposal to make PA's routing policy work in a (IMO) much more
sensible way, has not yet been endorsed by Lennart so I've not started
working on it. I'm pretty confident that even with some issues it
creates, it's a far more sensible configuration system than is currently
available.

The behaviour you describe would work perfectly under this setup, even
if the priority list itself is never actually exposed to the user via
confirguration GUIs.

Even the current module-default-device-restore does not actually work on
hotplug etc. (as the default is worked out at startup and then set, so
it's idea of the "default device" is lost).

Here is my proposal:
http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/


Hopefully when Lennart is less busy, we can revisit the discussions and
I can convince him I'm right!

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

thanks for your replies :-)

> Dnia 2010-06-11, pi± o godzinie 23:37 +0200, Geralt pisze:
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Eh? No idea what sdX mean here.
>
I was refering to either sd1, sd2 or sd3.

> If you want your audio to be heard over headset, then usb card, then
> onboard card, depending on which are available, just set them as
> fallbacks with pavucontrol or gnome-volume-control in the reverse
> direction (that's - connect your usb card, set it as fallback, then
> connect your headset and set that as fallback). That should be enough in
> at least with a recent enough PA.
>
That's exactly what I want and thanks for mentioning pavucontrol, I
didn't know of this application (I've basically zero experience with
Pulseaudio, yet).

> 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
>> Hi everybody,
>>
>> I've got an onboard soundcard and two usb soundcards and I'd like it
>> if pulseaudio could switch automatically the default sound card (or
>> default sink to be more precise) depending on the soundcards that are
>> currently plugged in. Is this possible?
>>
>> In case it's not clear what I want, let me explain it on an example:
>>
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Bascially you want a priority list of defaults and the current default
> to the the highest priority available device to be the one used?
>
> This is possible but no GUI exists on Gnome to exploit it just yet.
>
> This is the routing policy used under KDE, and the PA module
> module-device-manager implements this in PulseAudio.
>
> Sadly my proposal to make PA's routing policy work in a (IMO) much more
> sensible way, has not yet been endorsed by Lennart so I've not started
> working on it. I'm pretty confident that even with some issues it
> creates, it's a far more sensible configuration system than is currently
> available.
>
> The behaviour you describe would work perfectly under this setup, even
> if the priority list itself is never actually exposed to the user via
> confirguration GUIs.
>
> Even the current module-default-device-restore does not actually work on
> hotplug etc. (as the default is worked out at startup and then set, so
> it's idea of the "default device" is lost).
>
> Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
>
> Hopefully when Lennart is less busy, we can revisit the discussions and
> I can convince him I'm right!
>
That is exactly what I want, however I don't use KDE, is there still a
way to use youre pulseaudio module?



Geralt
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/

In my humble opinion....

Device by media.role is not that great.. it stand up for events, but
it should really be be per client (application)

The major use cases i have right now that suck... and are not solvable
without prior knowledge of how pa works
1 - If I plug in my USB or Bluetooth headset the music does not
change to headset like my analogue headset does...
2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
not be set to use that mic without restarting skype?
3 - There no way to easily set the media role or an app that dosn't
have one (yes the all should have a role but they don't), pa could be
doing better here using desktop files and the role should be saved..
4 - Videos do not cork music

By default I think pa should:
- Move all inputs and outputs to any newly connected local device (ie
usb, bluetooth whatever) that appears after pa has started (unless the
per client device has been set of course)
- There should be a simple UI for setting a clients default media
role (if one has not been set), and this role should be remembered by
pa
- Streams should inherit media role from the client if they don't
have one set... ie firefox is set to video, so all its streams have a
media role of video
- A module to cork music when video is playing

Those 4 things would solve every problem I can think of and make pa
function as I think 90% desktop users expect

Cheers


--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Mon, 2010-06-14 at 09:59 +1200, Jason Taylor wrote:
> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video

No big issue with the rest of your proposals (besides the usual "who's
doing the work?" =p). However this one isn't a good idea, your web
browser plays tons of different things, alert sounds from web-apps,
videos (youtube and friends), audio from sites like pandora, game-sounds
from the various flash time-wasters. If this was classified as video, my
web-app giving me a new IM notification would cork my audio stream
(assuming your other proposals make it in)...

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > No big issue with the rest of your proposals (besides the usual "who's
> doing the work?" =p).

If it would be accepted I would attempt to brush off my rusty c skills..
I'm just not sure how welcome this work would be in pa...

> However this one isn't a good idea, your web
> browser plays tons of different things, alert sounds from web-apps,
> videos (youtube and friends), audio from sites like pandora, game-sounds
> from the various flash time-wasters. If this was classified as video, my
> web-app giving me a new IM notification would cork my audio stream
> (assuming your other proposals make it in)...

The "browser" classification as video was just a suggestion for such a
generic player, nothing else really fits IIMHO.., if the stream was
tagged with correct media.role, then pa would use that, the "video"
would be a fall back position. If you kept your browser with no media
role then nothing would happen as now.. which sucks when viewing a
youtube video and having to open the music player and stop it so you
can hear the video..

html5 tags like video/audio would really help here but thats probably
3 to 5 years away of having any significant role..

I just realized I missed one other use case... pa has no concept of
window order..
- With 2 streams of the same role (other then notification) are
active the stream that has the higher client in the window stack
should be the active stream, all other streams should be corked

Cheers

--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. >> No big issue with the rest of your proposals (besides the usual "who's
>> doing the work?" =p).
>
> If it would be accepted I would attempt to brush off my rusty c skills..
> I'm just not sure how welcome this work would be in pa...

I think its just like other open-source projects, ie. "patches
welcome". Lennart is quite harsh on the quality of said patches, but
once you've met that you're good to go I'd think. Your proposals cover
a whole lot of ground though, and would probably take quite a bit of
hacking.
>
>> However this one isn't a good idea, your web
>> browser plays tons of different things, alert sounds from web-apps,
>> videos (youtube and friends), audio from sites like pandora, game-sounds
>> from the various flash time-wasters. If this was classified as video, my
>> web-app giving me a new IM notification would cork my audio stream
>> (assuming your other proposals make it in)...
>
> The "browser" classification as video was just a suggestion for such a
> generic player, nothing else really fits IIMHO.., if the stream was
> tagged with correct media.role, then pa would use that, the "video"
> would be a fall back position. If you kept your browser with no media
> role then nothing would happen as now.. which sucks when viewing a
> youtube video and having to open the music player and stop it so you
> can hear the video..
>
> html5 tags like video/audio would really help here but thats probably
> 3 to 5 years away of having any significant role..
>
Well, for me its an 'unsolvable' problem which should probably be best
left alone. Flash on linux is problematic anyway, such that it may
make more sense just to download the video and watch it outside the
browser.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

Hi everybody,

I've got an onboard soundcard and two usb soundcards and I'd like it
if pulseaudio could switch automatically the default sound card (or
default sink to be more precise) depending on the soundcards that are
currently plugged in. Is this possible?

In case it's not clear what I want, let me explain it on an example:

I've got three soundcards: my onboard card (sd1), my usb card (sd2)
and my headset (sd3) and I want the default card to be the one with
the highest numbering in the sdX naming scheme that is currently
attached to the system.



Thanks,

Geralt.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Dnia 2010-06-11, piÄ… o godzinie 23:37 +0200, Geralt pisze:
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Eh? No idea what sdX mean here.

If you want your audio to be heard over headset, then usb card, then
onboard card, depending on which are available, just set them as
fallbacks with pavucontrol or gnome-volume-control in the reverse
direction (that's - connect your usb card, set it as fallback, then
connect your headset and set that as fallback). That should be enough in
at least with a recent enough PA.

--

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
> Hi everybody,
>
> I've got an onboard soundcard and two usb soundcards and I'd like it
> if pulseaudio could switch automatically the default sound card (or
> default sink to be more precise) depending on the soundcards that are
> currently plugged in. Is this possible?
>
> In case it's not clear what I want, let me explain it on an example:
>
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Bascially you want a priority list of defaults and the current default
to the the highest priority available device to be the one used?

This is possible but no GUI exists on Gnome to exploit it just yet.

This is the routing policy used under KDE, and the PA module
module-device-manager implements this in PulseAudio.

Sadly my proposal to make PA's routing policy work in a (IMO) much more
sensible way, has not yet been endorsed by Lennart so I've not started
working on it. I'm pretty confident that even with some issues it
creates, it's a far more sensible configuration system than is currently
available.

The behaviour you describe would work perfectly under this setup, even
if the priority list itself is never actually exposed to the user via
confirguration GUIs.

Even the current module-default-device-restore does not actually work on
hotplug etc. (as the default is worked out at startup and then set, so
it's idea of the "default device" is lost).

Here is my proposal:
http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/


Hopefully when Lennart is less busy, we can revisit the discussions and
I can convince him I'm right!

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

thanks for your replies :-)

> Dnia 2010-06-11, pi± o godzinie 23:37 +0200, Geralt pisze:
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Eh? No idea what sdX mean here.
>
I was refering to either sd1, sd2 or sd3.

> If you want your audio to be heard over headset, then usb card, then
> onboard card, depending on which are available, just set them as
> fallbacks with pavucontrol or gnome-volume-control in the reverse
> direction (that's - connect your usb card, set it as fallback, then
> connect your headset and set that as fallback). That should be enough in
> at least with a recent enough PA.
>
That's exactly what I want and thanks for mentioning pavucontrol, I
didn't know of this application (I've basically zero experience with
Pulseaudio, yet).

> 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
>> Hi everybody,
>>
>> I've got an onboard soundcard and two usb soundcards and I'd like it
>> if pulseaudio could switch automatically the default sound card (or
>> default sink to be more precise) depending on the soundcards that are
>> currently plugged in. Is this possible?
>>
>> In case it's not clear what I want, let me explain it on an example:
>>
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Bascially you want a priority list of defaults and the current default
> to the the highest priority available device to be the one used?
>
> This is possible but no GUI exists on Gnome to exploit it just yet.
>
> This is the routing policy used under KDE, and the PA module
> module-device-manager implements this in PulseAudio.
>
> Sadly my proposal to make PA's routing policy work in a (IMO) much more
> sensible way, has not yet been endorsed by Lennart so I've not started
> working on it. I'm pretty confident that even with some issues it
> creates, it's a far more sensible configuration system than is currently
> available.
>
> The behaviour you describe would work perfectly under this setup, even
> if the priority list itself is never actually exposed to the user via
> confirguration GUIs.
>
> Even the current module-default-device-restore does not actually work on
> hotplug etc. (as the default is worked out at startup and then set, so
> it's idea of the "default device" is lost).
>
> Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
>
> Hopefully when Lennart is less busy, we can revisit the discussions and
> I can convince him I'm right!
>
That is exactly what I want, however I don't use KDE, is there still a
way to use youre pulseaudio module?



Geralt
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/

In my humble opinion....

Device by media.role is not that great.. it stand up for events, but
it should really be be per client (application)

The major use cases i have right now that suck... and are not solvable
without prior knowledge of how pa works
1 - If I plug in my USB or Bluetooth headset the music does not
change to headset like my analogue headset does...
2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
not be set to use that mic without restarting skype?
3 - There no way to easily set the media role or an app that dosn't
have one (yes the all should have a role but they don't), pa could be
doing better here using desktop files and the role should be saved..
4 - Videos do not cork music

By default I think pa should:
- Move all inputs and outputs to any newly connected local device (ie
usb, bluetooth whatever) that appears after pa has started (unless the
per client device has been set of course)
- There should be a simple UI for setting a clients default media
role (if one has not been set), and this role should be remembered by
pa
- Streams should inherit media role from the client if they don't
have one set... ie firefox is set to video, so all its streams have a
media role of video
- A module to cork music when video is playing

Those 4 things would solve every problem I can think of and make pa
function as I think 90% desktop users expect

Cheers


--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Mon, 2010-06-14 at 09:59 +1200, Jason Taylor wrote:
> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video

No big issue with the rest of your proposals (besides the usual "who's
doing the work?" =p). However this one isn't a good idea, your web
browser plays tons of different things, alert sounds from web-apps,
videos (youtube and friends), audio from sites like pandora, game-sounds
from the various flash time-wasters. If this was classified as video, my
web-app giving me a new IM notification would cork my audio stream
(assuming your other proposals make it in)...

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > No big issue with the rest of your proposals (besides the usual "who's
> doing the work?" =p).

If it would be accepted I would attempt to brush off my rusty c skills..
I'm just not sure how welcome this work would be in pa...

> However this one isn't a good idea, your web
> browser plays tons of different things, alert sounds from web-apps,
> videos (youtube and friends), audio from sites like pandora, game-sounds
> from the various flash time-wasters. If this was classified as video, my
> web-app giving me a new IM notification would cork my audio stream
> (assuming your other proposals make it in)...

The "browser" classification as video was just a suggestion for such a
generic player, nothing else really fits IIMHO.., if the stream was
tagged with correct media.role, then pa would use that, the "video"
would be a fall back position. If you kept your browser with no media
role then nothing would happen as now.. which sucks when viewing a
youtube video and having to open the music player and stop it so you
can hear the video..

html5 tags like video/audio would really help here but thats probably
3 to 5 years away of having any significant role..

I just realized I missed one other use case... pa has no concept of
window order..
- With 2 streams of the same role (other then notification) are
active the stream that has the higher client in the window stack
should be the active stream, all other streams should be corked

Cheers

--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. >> No big issue with the rest of your proposals (besides the usual "who's
>> doing the work?" =p).
>
> If it would be accepted I would attempt to brush off my rusty c skills..
> I'm just not sure how welcome this work would be in pa...

I think its just like other open-source projects, ie. "patches
welcome". Lennart is quite harsh on the quality of said patches, but
once you've met that you're good to go I'd think. Your proposals cover
a whole lot of ground though, and would probably take quite a bit of
hacking.
>
>> However this one isn't a good idea, your web
>> browser plays tons of different things, alert sounds from web-apps,
>> videos (youtube and friends), audio from sites like pandora, game-sounds
>> from the various flash time-wasters. If this was classified as video, my
>> web-app giving me a new IM notification would cork my audio stream
>> (assuming your other proposals make it in)...
>
> The "browser" classification as video was just a suggestion for such a
> generic player, nothing else really fits IIMHO.., if the stream was
> tagged with correct media.role, then pa would use that, the "video"
> would be a fall back position. If you kept your browser with no media
> role then nothing would happen as now.. which sucks when viewing a
> youtube video and having to open the music player and stop it so you
> can hear the video..
>
> html5 tags like video/audio would really help here but thats probably
> 3 to 5 years away of having any significant role..
>
Well, for me its an 'unsolvable' problem which should probably be best
left alone. Flash on linux is problematic anyway, such that it may
make more sense just to download the video and watch it outside the
browser.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I think its just like other open-source projects, ie. "patches
> welcome". Lennart is quite harsh on the quality of said patches, but
> once you've met that you're good to go I'd think. Your proposals cover
> a whole lot of ground though, and would probably take quite a bit of
> hacking.

No problem, one bit at a time.. I'd at least want to know that it had
a chance of work being accepted though instead of .. thats not the
direction we want to go... ;)

I have my python hacks that work for me but it would be nice to get
this stuff in pa where it should be.

> Well, for me its an 'unsolvable' problem which should probably be best
> left alone. Flash on linux is problematic anyway, such that it may
> make more sense just to download the video and watch it outside the
> browser.

Probably its impossible to get this 100% right due to the ugly flash
issues, but 80% right would be nice start and anything to encourage
html5 and kill flash must be a "good thing" ... as long as it dosn't
screw up by default.

Cheers

--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

Hi everybody,

I've got an onboard soundcard and two usb soundcards and I'd like it
if pulseaudio could switch automatically the default sound card (or
default sink to be more precise) depending on the soundcards that are
currently plugged in. Is this possible?

In case it's not clear what I want, let me explain it on an example:

I've got three soundcards: my onboard card (sd1), my usb card (sd2)
and my headset (sd3) and I want the default card to be the one with
the highest numbering in the sdX naming scheme that is currently
attached to the system.



Thanks,

Geralt.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Dnia 2010-06-11, piÄ… o godzinie 23:37 +0200, Geralt pisze:
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Eh? No idea what sdX mean here.

If you want your audio to be heard over headset, then usb card, then
onboard card, depending on which are available, just set them as
fallbacks with pavucontrol or gnome-volume-control in the reverse
direction (that's - connect your usb card, set it as fallback, then
connect your headset and set that as fallback). That should be enough in
at least with a recent enough PA.

--

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
> Hi everybody,
>
> I've got an onboard soundcard and two usb soundcards and I'd like it
> if pulseaudio could switch automatically the default sound card (or
> default sink to be more precise) depending on the soundcards that are
> currently plugged in. Is this possible?
>
> In case it's not clear what I want, let me explain it on an example:
>
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Bascially you want a priority list of defaults and the current default
to the the highest priority available device to be the one used?

This is possible but no GUI exists on Gnome to exploit it just yet.

This is the routing policy used under KDE, and the PA module
module-device-manager implements this in PulseAudio.

Sadly my proposal to make PA's routing policy work in a (IMO) much more
sensible way, has not yet been endorsed by Lennart so I've not started
working on it. I'm pretty confident that even with some issues it
creates, it's a far more sensible configuration system than is currently
available.

The behaviour you describe would work perfectly under this setup, even
if the priority list itself is never actually exposed to the user via
confirguration GUIs.

Even the current module-default-device-restore does not actually work on
hotplug etc. (as the default is worked out at startup and then set, so
it's idea of the "default device" is lost).

Here is my proposal:
http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/


Hopefully when Lennart is less busy, we can revisit the discussions and
I can convince him I'm right!

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

thanks for your replies :-)

> Dnia 2010-06-11, pi± o godzinie 23:37 +0200, Geralt pisze:
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Eh? No idea what sdX mean here.
>
I was refering to either sd1, sd2 or sd3.

> If you want your audio to be heard over headset, then usb card, then
> onboard card, depending on which are available, just set them as
> fallbacks with pavucontrol or gnome-volume-control in the reverse
> direction (that's - connect your usb card, set it as fallback, then
> connect your headset and set that as fallback). That should be enough in
> at least with a recent enough PA.
>
That's exactly what I want and thanks for mentioning pavucontrol, I
didn't know of this application (I've basically zero experience with
Pulseaudio, yet).

> 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
>> Hi everybody,
>>
>> I've got an onboard soundcard and two usb soundcards and I'd like it
>> if pulseaudio could switch automatically the default sound card (or
>> default sink to be more precise) depending on the soundcards that are
>> currently plugged in. Is this possible?
>>
>> In case it's not clear what I want, let me explain it on an example:
>>
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Bascially you want a priority list of defaults and the current default
> to the the highest priority available device to be the one used?
>
> This is possible but no GUI exists on Gnome to exploit it just yet.
>
> This is the routing policy used under KDE, and the PA module
> module-device-manager implements this in PulseAudio.
>
> Sadly my proposal to make PA's routing policy work in a (IMO) much more
> sensible way, has not yet been endorsed by Lennart so I've not started
> working on it. I'm pretty confident that even with some issues it
> creates, it's a far more sensible configuration system than is currently
> available.
>
> The behaviour you describe would work perfectly under this setup, even
> if the priority list itself is never actually exposed to the user via
> confirguration GUIs.
>
> Even the current module-default-device-restore does not actually work on
> hotplug etc. (as the default is worked out at startup and then set, so
> it's idea of the "default device" is lost).
>
> Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
>
> Hopefully when Lennart is less busy, we can revisit the discussions and
> I can convince him I'm right!
>
That is exactly what I want, however I don't use KDE, is there still a
way to use youre pulseaudio module?



Geralt
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/

In my humble opinion....

Device by media.role is not that great.. it stand up for events, but
it should really be be per client (application)

The major use cases i have right now that suck... and are not solvable
without prior knowledge of how pa works
1 - If I plug in my USB or Bluetooth headset the music does not
change to headset like my analogue headset does...
2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
not be set to use that mic without restarting skype?
3 - There no way to easily set the media role or an app that dosn't
have one (yes the all should have a role but they don't), pa could be
doing better here using desktop files and the role should be saved..
4 - Videos do not cork music

By default I think pa should:
- Move all inputs and outputs to any newly connected local device (ie
usb, bluetooth whatever) that appears after pa has started (unless the
per client device has been set of course)
- There should be a simple UI for setting a clients default media
role (if one has not been set), and this role should be remembered by
pa
- Streams should inherit media role from the client if they don't
have one set... ie firefox is set to video, so all its streams have a
media role of video
- A module to cork music when video is playing

Those 4 things would solve every problem I can think of and make pa
function as I think 90% desktop users expect

Cheers


--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Mon, 2010-06-14 at 09:59 +1200, Jason Taylor wrote:
> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video

No big issue with the rest of your proposals (besides the usual "who's
doing the work?" =p). However this one isn't a good idea, your web
browser plays tons of different things, alert sounds from web-apps,
videos (youtube and friends), audio from sites like pandora, game-sounds
from the various flash time-wasters. If this was classified as video, my
web-app giving me a new IM notification would cork my audio stream
(assuming your other proposals make it in)...

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > No big issue with the rest of your proposals (besides the usual "who's
> doing the work?" =p).

If it would be accepted I would attempt to brush off my rusty c skills..
I'm just not sure how welcome this work would be in pa...

> However this one isn't a good idea, your web
> browser plays tons of different things, alert sounds from web-apps,
> videos (youtube and friends), audio from sites like pandora, game-sounds
> from the various flash time-wasters. If this was classified as video, my
> web-app giving me a new IM notification would cork my audio stream
> (assuming your other proposals make it in)...

The "browser" classification as video was just a suggestion for such a
generic player, nothing else really fits IIMHO.., if the stream was
tagged with correct media.role, then pa would use that, the "video"
would be a fall back position. If you kept your browser with no media
role then nothing would happen as now.. which sucks when viewing a
youtube video and having to open the music player and stop it so you
can hear the video..

html5 tags like video/audio would really help here but thats probably
3 to 5 years away of having any significant role..

I just realized I missed one other use case... pa has no concept of
window order..
- With 2 streams of the same role (other then notification) are
active the stream that has the higher client in the window stack
should be the active stream, all other streams should be corked

Cheers

--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. >> No big issue with the rest of your proposals (besides the usual "who's
>> doing the work?" =p).
>
> If it would be accepted I would attempt to brush off my rusty c skills..
> I'm just not sure how welcome this work would be in pa...

I think its just like other open-source projects, ie. "patches
welcome". Lennart is quite harsh on the quality of said patches, but
once you've met that you're good to go I'd think. Your proposals cover
a whole lot of ground though, and would probably take quite a bit of
hacking.
>
>> However this one isn't a good idea, your web
>> browser plays tons of different things, alert sounds from web-apps,
>> videos (youtube and friends), audio from sites like pandora, game-sounds
>> from the various flash time-wasters. If this was classified as video, my
>> web-app giving me a new IM notification would cork my audio stream
>> (assuming your other proposals make it in)...
>
> The "browser" classification as video was just a suggestion for such a
> generic player, nothing else really fits IIMHO.., if the stream was
> tagged with correct media.role, then pa would use that, the "video"
> would be a fall back position. If you kept your browser with no media
> role then nothing would happen as now.. which sucks when viewing a
> youtube video and having to open the music player and stop it so you
> can hear the video..
>
> html5 tags like video/audio would really help here but thats probably
> 3 to 5 years away of having any significant role..
>
Well, for me its an 'unsolvable' problem which should probably be best
left alone. Flash on linux is problematic anyway, such that it may
make more sense just to download the video and watch it outside the
browser.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I think its just like other open-source projects, ie. "patches
> welcome". Lennart is quite harsh on the quality of said patches, but
> once you've met that you're good to go I'd think. Your proposals cover
> a whole lot of ground though, and would probably take quite a bit of
> hacking.

No problem, one bit at a time.. I'd at least want to know that it had
a chance of work being accepted though instead of .. thats not the
direction we want to go... ;)

I have my python hacks that work for me but it would be nice to get
this stuff in pa where it should be.

> Well, for me its an 'unsolvable' problem which should probably be best
> left alone. Flash on linux is problematic anyway, such that it may
> make more sense just to download the video and watch it outside the
> browser.

Probably its impossible to get this 100% right due to the ugly flash
issues, but 80% right would be nice start and anything to encourage
html5 and kill flash must be a "good thing" ... as long as it dosn't
screw up by default.

Cheers

--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Jason Taylor at 13/06/10 22:59 did gyre and gimble:
>> Here is my proposal:
>> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
> In my humble opinion....
>
> Device by media.role is not that great.. it stand up for events, but
> it should really be be per client (application)
>
> The major use cases i have right now that suck... and are not solvable
> without prior knowledge of how pa works
> 1 - If I plug in my USB or Bluetooth headset the music does not
> change to headset like my analogue headset does...

With your analogue headset "music" does not change to it, all output
changes to it. I know what you're hinting at, but the two cannot be
compared unless you just talk about "all output".

With my proposal, "music" could be configured to move to the new
USB/bluetooth headset.

> 2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
> not be set to use that mic without restarting skype?

Incorrect. When PA is used, Skype detects it and uses only it. It
(correctly) does not offer you the configuration choice inside Skype. It
is mostly up to tools like gnome-volume-control/pavucontrol etc. to
configure the Skype streams, but in the case of a USB or Bluetooth
headset, the PA module module-intended-roles kicks in and automatically
moves "voip" streams to "headset" devices. This currently works pretty
well (I don't have to do any configuration after setting up my bluetooth
headset for it to "just work" with Skype. It's quite nice, but not very
transparent. If you read the link I sent through, I believe I proposed
there (maybe it was afterwards on the list - can't quite recall) that
module-intended-roles becomes a passive module that simply injects brand
new (never seen before) devices into the appropriate place in the
priority list for the appropriate role. That way it's more transparent
to the user and the net functionality remains the same.

> 3 - There no way to easily set the media role or an app that dosn't
> have one (yes the all should have a role but they don't), pa could be
> doing better here using desktop files and the role should be saved..

PA *does* use .desktop files. That's what module-augment-properties does...

> 4 - Videos do not cork music

No they don't. Currently the automatic corking is implemented by
module-cork-music-on-phone. This could be made more generic with some
kind of simple "rules" file that could be parsed at startup to allow
"video corks music". That would be kinda sensible IMO.


> By default I think pa should:
> - Move all inputs and outputs to any newly connected local device (ie
> usb, bluetooth whatever) that appears after pa has started (unless the
> per client device has been set of course)

Perhaps, but I don't think everyone would agree here. I certainly would
not be appropriate for my crappy bluetooth headset here. It's acceptable
for phone streams, but really not for anything else.

> - There should be a simple UI for setting a clients default media
> role (if one has not been set), and this role should be remembered by
> pa

This could be done, but I'd personally rather not do it. An alternative
would be an independent "database" (like pci.ids or usb.ids) that could
"know" which apps are which roles, that we can update via the web and
bundle when we release, but I think letting users do this removes from
the simplicity that should underlie this system. If the user cares that
much, they can either edit the .desktop file or create a wrapper
script/alias that sets the relevant env vars to allow for role to be forced.

> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video

Not quite sure how easy this would be, but in theory if the client has a
proplist, it should be easy to make any streams that client creates
inherit that (I'd have to check to see if this is not done already!)

> - A module to cork music when video is playing

Should be trivial to do (although depending on the options and
combinations here it may be better to parse some simple rules (or just
rename module-cork-on-phone and call it module-auto-cork or something
and implement this extra rule (tho' I guess separate modules give users
more control).

> Those 4 things would solve every problem I can think of and make pa
> function as I think 90% desktop users expect

I think most points are valid. With the exception of the first one, the
others are not technically that much related to routing (the role points
are related if you assume most routing is role-based (at least
initially)) and as such are probably orthoganal to the routing overhaul
I suggest.

Certainly worth keeping in mind tho'.

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

Hi everybody,

I've got an onboard soundcard and two usb soundcards and I'd like it
if pulseaudio could switch automatically the default sound card (or
default sink to be more precise) depending on the soundcards that are
currently plugged in. Is this possible?

In case it's not clear what I want, let me explain it on an example:

I've got three soundcards: my onboard card (sd1), my usb card (sd2)
and my headset (sd3) and I want the default card to be the one with
the highest numbering in the sdX naming scheme that is currently
attached to the system.



Thanks,

Geralt.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Dnia 2010-06-11, piÄ… o godzinie 23:37 +0200, Geralt pisze:
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Eh? No idea what sdX mean here.

If you want your audio to be heard over headset, then usb card, then
onboard card, depending on which are available, just set them as
fallbacks with pavucontrol or gnome-volume-control in the reverse
direction (that's - connect your usb card, set it as fallback, then
connect your headset and set that as fallback). That should be enough in
at least with a recent enough PA.

--

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
> Hi everybody,
>
> I've got an onboard soundcard and two usb soundcards and I'd like it
> if pulseaudio could switch automatically the default sound card (or
> default sink to be more precise) depending on the soundcards that are
> currently plugged in. Is this possible?
>
> In case it's not clear what I want, let me explain it on an example:
>
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Bascially you want a priority list of defaults and the current default
to the the highest priority available device to be the one used?

This is possible but no GUI exists on Gnome to exploit it just yet.

This is the routing policy used under KDE, and the PA module
module-device-manager implements this in PulseAudio.

Sadly my proposal to make PA's routing policy work in a (IMO) much more
sensible way, has not yet been endorsed by Lennart so I've not started
working on it. I'm pretty confident that even with some issues it
creates, it's a far more sensible configuration system than is currently
available.

The behaviour you describe would work perfectly under this setup, even
if the priority list itself is never actually exposed to the user via
confirguration GUIs.

Even the current module-default-device-restore does not actually work on
hotplug etc. (as the default is worked out at startup and then set, so
it's idea of the "default device" is lost).

Here is my proposal:
http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/


Hopefully when Lennart is less busy, we can revisit the discussions and
I can convince him I'm right!

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

thanks for your replies :-)

> Dnia 2010-06-11, pi± o godzinie 23:37 +0200, Geralt pisze:
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Eh? No idea what sdX mean here.
>
I was refering to either sd1, sd2 or sd3.

> If you want your audio to be heard over headset, then usb card, then
> onboard card, depending on which are available, just set them as
> fallbacks with pavucontrol or gnome-volume-control in the reverse
> direction (that's - connect your usb card, set it as fallback, then
> connect your headset and set that as fallback). That should be enough in
> at least with a recent enough PA.
>
That's exactly what I want and thanks for mentioning pavucontrol, I
didn't know of this application (I've basically zero experience with
Pulseaudio, yet).

> 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
>> Hi everybody,
>>
>> I've got an onboard soundcard and two usb soundcards and I'd like it
>> if pulseaudio could switch automatically the default sound card (or
>> default sink to be more precise) depending on the soundcards that are
>> currently plugged in. Is this possible?
>>
>> In case it's not clear what I want, let me explain it on an example:
>>
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Bascially you want a priority list of defaults and the current default
> to the the highest priority available device to be the one used?
>
> This is possible but no GUI exists on Gnome to exploit it just yet.
>
> This is the routing policy used under KDE, and the PA module
> module-device-manager implements this in PulseAudio.
>
> Sadly my proposal to make PA's routing policy work in a (IMO) much more
> sensible way, has not yet been endorsed by Lennart so I've not started
> working on it. I'm pretty confident that even with some issues it
> creates, it's a far more sensible configuration system than is currently
> available.
>
> The behaviour you describe would work perfectly under this setup, even
> if the priority list itself is never actually exposed to the user via
> confirguration GUIs.
>
> Even the current module-default-device-restore does not actually work on
> hotplug etc. (as the default is worked out at startup and then set, so
> it's idea of the "default device" is lost).
>
> Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
>
> Hopefully when Lennart is less busy, we can revisit the discussions and
> I can convince him I'm right!
>
That is exactly what I want, however I don't use KDE, is there still a
way to use youre pulseaudio module?



Geralt
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/

In my humble opinion....

Device by media.role is not that great.. it stand up for events, but
it should really be be per client (application)

The major use cases i have right now that suck... and are not solvable
without prior knowledge of how pa works
1 - If I plug in my USB or Bluetooth headset the music does not
change to headset like my analogue headset does...
2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
not be set to use that mic without restarting skype?
3 - There no way to easily set the media role or an app that dosn't
have one (yes the all should have a role but they don't), pa could be
doing better here using desktop files and the role should be saved..
4 - Videos do not cork music

By default I think pa should:
- Move all inputs and outputs to any newly connected local device (ie
usb, bluetooth whatever) that appears after pa has started (unless the
per client device has been set of course)
- There should be a simple UI for setting a clients default media
role (if one has not been set), and this role should be remembered by
pa
- Streams should inherit media role from the client if they don't
have one set... ie firefox is set to video, so all its streams have a
media role of video
- A module to cork music when video is playing

Those 4 things would solve every problem I can think of and make pa
function as I think 90% desktop users expect

Cheers


--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Mon, 2010-06-14 at 09:59 +1200, Jason Taylor wrote:
> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video

No big issue with the rest of your proposals (besides the usual "who's
doing the work?" =p). However this one isn't a good idea, your web
browser plays tons of different things, alert sounds from web-apps,
videos (youtube and friends), audio from sites like pandora, game-sounds
from the various flash time-wasters. If this was classified as video, my
web-app giving me a new IM notification would cork my audio stream
(assuming your other proposals make it in)...

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > No big issue with the rest of your proposals (besides the usual "who's
> doing the work?" =p).

If it would be accepted I would attempt to brush off my rusty c skills..
I'm just not sure how welcome this work would be in pa...

> However this one isn't a good idea, your web
> browser plays tons of different things, alert sounds from web-apps,
> videos (youtube and friends), audio from sites like pandora, game-sounds
> from the various flash time-wasters. If this was classified as video, my
> web-app giving me a new IM notification would cork my audio stream
> (assuming your other proposals make it in)...

The "browser" classification as video was just a suggestion for such a
generic player, nothing else really fits IIMHO.., if the stream was
tagged with correct media.role, then pa would use that, the "video"
would be a fall back position. If you kept your browser with no media
role then nothing would happen as now.. which sucks when viewing a
youtube video and having to open the music player and stop it so you
can hear the video..

html5 tags like video/audio would really help here but thats probably
3 to 5 years away of having any significant role..

I just realized I missed one other use case... pa has no concept of
window order..
- With 2 streams of the same role (other then notification) are
active the stream that has the higher client in the window stack
should be the active stream, all other streams should be corked

Cheers

--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. >> No big issue with the rest of your proposals (besides the usual "who's
>> doing the work?" =p).
>
> If it would be accepted I would attempt to brush off my rusty c skills..
> I'm just not sure how welcome this work would be in pa...

I think its just like other open-source projects, ie. "patches
welcome". Lennart is quite harsh on the quality of said patches, but
once you've met that you're good to go I'd think. Your proposals cover
a whole lot of ground though, and would probably take quite a bit of
hacking.
>
>> However this one isn't a good idea, your web
>> browser plays tons of different things, alert sounds from web-apps,
>> videos (youtube and friends), audio from sites like pandora, game-sounds
>> from the various flash time-wasters. If this was classified as video, my
>> web-app giving me a new IM notification would cork my audio stream
>> (assuming your other proposals make it in)...
>
> The "browser" classification as video was just a suggestion for such a
> generic player, nothing else really fits IIMHO.., if the stream was
> tagged with correct media.role, then pa would use that, the "video"
> would be a fall back position. If you kept your browser with no media
> role then nothing would happen as now.. which sucks when viewing a
> youtube video and having to open the music player and stop it so you
> can hear the video..
>
> html5 tags like video/audio would really help here but thats probably
> 3 to 5 years away of having any significant role..
>
Well, for me its an 'unsolvable' problem which should probably be best
left alone. Flash on linux is problematic anyway, such that it may
make more sense just to download the video and watch it outside the
browser.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I think its just like other open-source projects, ie. "patches
> welcome". Lennart is quite harsh on the quality of said patches, but
> once you've met that you're good to go I'd think. Your proposals cover
> a whole lot of ground though, and would probably take quite a bit of
> hacking.

No problem, one bit at a time.. I'd at least want to know that it had
a chance of work being accepted though instead of .. thats not the
direction we want to go... ;)

I have my python hacks that work for me but it would be nice to get
this stuff in pa where it should be.

> Well, for me its an 'unsolvable' problem which should probably be best
> left alone. Flash on linux is problematic anyway, such that it may
> make more sense just to download the video and watch it outside the
> browser.

Probably its impossible to get this 100% right due to the ugly flash
issues, but 80% right would be nice start and anything to encourage
html5 and kill flash must be a "good thing" ... as long as it dosn't
screw up by default.

Cheers

--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Jason Taylor at 13/06/10 22:59 did gyre and gimble:
>> Here is my proposal:
>> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
> In my humble opinion....
>
> Device by media.role is not that great.. it stand up for events, but
> it should really be be per client (application)
>
> The major use cases i have right now that suck... and are not solvable
> without prior knowledge of how pa works
> 1 - If I plug in my USB or Bluetooth headset the music does not
> change to headset like my analogue headset does...

With your analogue headset "music" does not change to it, all output
changes to it. I know what you're hinting at, but the two cannot be
compared unless you just talk about "all output".

With my proposal, "music" could be configured to move to the new
USB/bluetooth headset.

> 2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
> not be set to use that mic without restarting skype?

Incorrect. When PA is used, Skype detects it and uses only it. It
(correctly) does not offer you the configuration choice inside Skype. It
is mostly up to tools like gnome-volume-control/pavucontrol etc. to
configure the Skype streams, but in the case of a USB or Bluetooth
headset, the PA module module-intended-roles kicks in and automatically
moves "voip" streams to "headset" devices. This currently works pretty
well (I don't have to do any configuration after setting up my bluetooth
headset for it to "just work" with Skype. It's quite nice, but not very
transparent. If you read the link I sent through, I believe I proposed
there (maybe it was afterwards on the list - can't quite recall) that
module-intended-roles becomes a passive module that simply injects brand
new (never seen before) devices into the appropriate place in the
priority list for the appropriate role. That way it's more transparent
to the user and the net functionality remains the same.

> 3 - There no way to easily set the media role or an app that dosn't
> have one (yes the all should have a role but they don't), pa could be
> doing better here using desktop files and the role should be saved..

PA *does* use .desktop files. That's what module-augment-properties does...

> 4 - Videos do not cork music

No they don't. Currently the automatic corking is implemented by
module-cork-music-on-phone. This could be made more generic with some
kind of simple "rules" file that could be parsed at startup to allow
"video corks music". That would be kinda sensible IMO.


> By default I think pa should:
> - Move all inputs and outputs to any newly connected local device (ie
> usb, bluetooth whatever) that appears after pa has started (unless the
> per client device has been set of course)

Perhaps, but I don't think everyone would agree here. I certainly would
not be appropriate for my crappy bluetooth headset here. It's acceptable
for phone streams, but really not for anything else.

> - There should be a simple UI for setting a clients default media
> role (if one has not been set), and this role should be remembered by
> pa

This could be done, but I'd personally rather not do it. An alternative
would be an independent "database" (like pci.ids or usb.ids) that could
"know" which apps are which roles, that we can update via the web and
bundle when we release, but I think letting users do this removes from
the simplicity that should underlie this system. If the user cares that
much, they can either edit the .desktop file or create a wrapper
script/alias that sets the relevant env vars to allow for role to be forced.

> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video

Not quite sure how easy this would be, but in theory if the client has a
proplist, it should be easy to make any streams that client creates
inherit that (I'd have to check to see if this is not done already!)

> - A module to cork music when video is playing

Should be trivial to do (although depending on the options and
combinations here it may be better to parse some simple rules (or just
rename module-cork-on-phone and call it module-auto-cork or something
and implement this extra rule (tho' I guess separate modules give users
more control).

> Those 4 things would solve every problem I can think of and make pa
> function as I think 90% desktop users expect

I think most points are valid. With the exception of the first one, the
others are not technically that much related to routing (the role points
are related if you assume most routing is role-based (at least
initially)) and as such are probably orthoganal to the routing overhaul
I suggest.

Certainly worth keeping in mind tho'.

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Yves (theYinYeti) at 14/06/10 08:48 did gyre and gimble:
> Le 14/06/2010 01:59, Jason Taylor a écrit :
>> I just realized I missed one other use case... pa has no concept of
>> window order..
>> - With 2 streams of the same role (other then notification) are
>> active the stream that has the higher client in the window stack
>> should be the active stream, all other streams should be corked
>
> I'm not absolutely sure of what "corked" means, but it seems to mean
> "paused".
> If so, I don't agree. Here's an example where I don't want anything to
> happen to current sound when another sound of the same nature begins:
>
> My son watches a cartoon on TV, the picture of which comes from the
> S-Video output of the PC (display :1 ); the sound is directed at the TV
> as well using sound card #2.
> Meanwhile, on the computer's screen (display :0 ), I watch a conference,
> the sound of which goes to the screen's integrated speakers through
> sound card #1.
>
> This setup is quite common with me. Even more often (but then roles are
> different I guess), the HiFi plays Deezer (good music) while the
> integrated speakers let me hear both the orator of the lengthy
> conference I'm attending, and the events' sounds of the little game I
> have alongside, for moments in the conference when there's nothing
> interesting being said.
>
> I definitely don't want any sound to ever be paused or stopped
> automatically. But then, maybe I'm not part of the normal users...

I think you're probably right about being "not part of the normal
users", but that's not to say the problem isn't solvable.

For example, each stream has the following property:
window.x11.display = ":0.0"

It would be theoretically possible to make the cork rules only affect
streams that are on the same display as the one that triggers them. e.g.
a video on display :1 would not affect music on display :0 or similar.

It obviously makes things more complicated, but it's theoretically
possible if someone puts in the work!


Col

--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

Hi everybody,

I've got an onboard soundcard and two usb soundcards and I'd like it
if pulseaudio could switch automatically the default sound card (or
default sink to be more precise) depending on the soundcards that are
currently plugged in. Is this possible?

In case it's not clear what I want, let me explain it on an example:

I've got three soundcards: my onboard card (sd1), my usb card (sd2)
and my headset (sd3) and I want the default card to be the one with
the highest numbering in the sdX naming scheme that is currently
attached to the system.



Thanks,

Geralt.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Dnia 2010-06-11, piÄ… o godzinie 23:37 +0200, Geralt pisze:
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Eh? No idea what sdX mean here.

If you want your audio to be heard over headset, then usb card, then
onboard card, depending on which are available, just set them as
fallbacks with pavucontrol or gnome-volume-control in the reverse
direction (that's - connect your usb card, set it as fallback, then
connect your headset and set that as fallback). That should be enough in
at least with a recent enough PA.

--

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
> Hi everybody,
>
> I've got an onboard soundcard and two usb soundcards and I'd like it
> if pulseaudio could switch automatically the default sound card (or
> default sink to be more precise) depending on the soundcards that are
> currently plugged in. Is this possible?
>
> In case it's not clear what I want, let me explain it on an example:
>
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Bascially you want a priority list of defaults and the current default
to the the highest priority available device to be the one used?

This is possible but no GUI exists on Gnome to exploit it just yet.

This is the routing policy used under KDE, and the PA module
module-device-manager implements this in PulseAudio.

Sadly my proposal to make PA's routing policy work in a (IMO) much more
sensible way, has not yet been endorsed by Lennart so I've not started
working on it. I'm pretty confident that even with some issues it
creates, it's a far more sensible configuration system than is currently
available.

The behaviour you describe would work perfectly under this setup, even
if the priority list itself is never actually exposed to the user via
confirguration GUIs.

Even the current module-default-device-restore does not actually work on
hotplug etc. (as the default is worked out at startup and then set, so
it's idea of the "default device" is lost).

Here is my proposal:
http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/


Hopefully when Lennart is less busy, we can revisit the discussions and
I can convince him I'm right!

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

thanks for your replies :-)

> Dnia 2010-06-11, pi± o godzinie 23:37 +0200, Geralt pisze:
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Eh? No idea what sdX mean here.
>
I was refering to either sd1, sd2 or sd3.

> If you want your audio to be heard over headset, then usb card, then
> onboard card, depending on which are available, just set them as
> fallbacks with pavucontrol or gnome-volume-control in the reverse
> direction (that's - connect your usb card, set it as fallback, then
> connect your headset and set that as fallback). That should be enough in
> at least with a recent enough PA.
>
That's exactly what I want and thanks for mentioning pavucontrol, I
didn't know of this application (I've basically zero experience with
Pulseaudio, yet).

> 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
>> Hi everybody,
>>
>> I've got an onboard soundcard and two usb soundcards and I'd like it
>> if pulseaudio could switch automatically the default sound card (or
>> default sink to be more precise) depending on the soundcards that are
>> currently plugged in. Is this possible?
>>
>> In case it's not clear what I want, let me explain it on an example:
>>
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Bascially you want a priority list of defaults and the current default
> to the the highest priority available device to be the one used?
>
> This is possible but no GUI exists on Gnome to exploit it just yet.
>
> This is the routing policy used under KDE, and the PA module
> module-device-manager implements this in PulseAudio.
>
> Sadly my proposal to make PA's routing policy work in a (IMO) much more
> sensible way, has not yet been endorsed by Lennart so I've not started
> working on it. I'm pretty confident that even with some issues it
> creates, it's a far more sensible configuration system than is currently
> available.
>
> The behaviour you describe would work perfectly under this setup, even
> if the priority list itself is never actually exposed to the user via
> confirguration GUIs.
>
> Even the current module-default-device-restore does not actually work on
> hotplug etc. (as the default is worked out at startup and then set, so
> it's idea of the "default device" is lost).
>
> Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
>
> Hopefully when Lennart is less busy, we can revisit the discussions and
> I can convince him I'm right!
>
That is exactly what I want, however I don't use KDE, is there still a
way to use youre pulseaudio module?



Geralt
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/

In my humble opinion....

Device by media.role is not that great.. it stand up for events, but
it should really be be per client (application)

The major use cases i have right now that suck... and are not solvable
without prior knowledge of how pa works
1 - If I plug in my USB or Bluetooth headset the music does not
change to headset like my analogue headset does...
2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
not be set to use that mic without restarting skype?
3 - There no way to easily set the media role or an app that dosn't
have one (yes the all should have a role but they don't), pa could be
doing better here using desktop files and the role should be saved..
4 - Videos do not cork music

By default I think pa should:
- Move all inputs and outputs to any newly connected local device (ie
usb, bluetooth whatever) that appears after pa has started (unless the
per client device has been set of course)
- There should be a simple UI for setting a clients default media
role (if one has not been set), and this role should be remembered by
pa
- Streams should inherit media role from the client if they don't
have one set... ie firefox is set to video, so all its streams have a
media role of video
- A module to cork music when video is playing

Those 4 things would solve every problem I can think of and make pa
function as I think 90% desktop users expect

Cheers


--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Mon, 2010-06-14 at 09:59 +1200, Jason Taylor wrote:
> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video

No big issue with the rest of your proposals (besides the usual "who's
doing the work?" =p). However this one isn't a good idea, your web
browser plays tons of different things, alert sounds from web-apps,
videos (youtube and friends), audio from sites like pandora, game-sounds
from the various flash time-wasters. If this was classified as video, my
web-app giving me a new IM notification would cork my audio stream
(assuming your other proposals make it in)...

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > No big issue with the rest of your proposals (besides the usual "who's
> doing the work?" =p).

If it would be accepted I would attempt to brush off my rusty c skills..
I'm just not sure how welcome this work would be in pa...

> However this one isn't a good idea, your web
> browser plays tons of different things, alert sounds from web-apps,
> videos (youtube and friends), audio from sites like pandora, game-sounds
> from the various flash time-wasters. If this was classified as video, my
> web-app giving me a new IM notification would cork my audio stream
> (assuming your other proposals make it in)...

The "browser" classification as video was just a suggestion for such a
generic player, nothing else really fits IIMHO.., if the stream was
tagged with correct media.role, then pa would use that, the "video"
would be a fall back position. If you kept your browser with no media
role then nothing would happen as now.. which sucks when viewing a
youtube video and having to open the music player and stop it so you
can hear the video..

html5 tags like video/audio would really help here but thats probably
3 to 5 years away of having any significant role..

I just realized I missed one other use case... pa has no concept of
window order..
- With 2 streams of the same role (other then notification) are
active the stream that has the higher client in the window stack
should be the active stream, all other streams should be corked

Cheers

--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. >> No big issue with the rest of your proposals (besides the usual "who's
>> doing the work?" =p).
>
> If it would be accepted I would attempt to brush off my rusty c skills..
> I'm just not sure how welcome this work would be in pa...

I think its just like other open-source projects, ie. "patches
welcome". Lennart is quite harsh on the quality of said patches, but
once you've met that you're good to go I'd think. Your proposals cover
a whole lot of ground though, and would probably take quite a bit of
hacking.
>
>> However this one isn't a good idea, your web
>> browser plays tons of different things, alert sounds from web-apps,
>> videos (youtube and friends), audio from sites like pandora, game-sounds
>> from the various flash time-wasters. If this was classified as video, my
>> web-app giving me a new IM notification would cork my audio stream
>> (assuming your other proposals make it in)...
>
> The "browser" classification as video was just a suggestion for such a
> generic player, nothing else really fits IIMHO.., if the stream was
> tagged with correct media.role, then pa would use that, the "video"
> would be a fall back position. If you kept your browser with no media
> role then nothing would happen as now.. which sucks when viewing a
> youtube video and having to open the music player and stop it so you
> can hear the video..
>
> html5 tags like video/audio would really help here but thats probably
> 3 to 5 years away of having any significant role..
>
Well, for me its an 'unsolvable' problem which should probably be best
left alone. Flash on linux is problematic anyway, such that it may
make more sense just to download the video and watch it outside the
browser.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I think its just like other open-source projects, ie. "patches
> welcome". Lennart is quite harsh on the quality of said patches, but
> once you've met that you're good to go I'd think. Your proposals cover
> a whole lot of ground though, and would probably take quite a bit of
> hacking.

No problem, one bit at a time.. I'd at least want to know that it had
a chance of work being accepted though instead of .. thats not the
direction we want to go... ;)

I have my python hacks that work for me but it would be nice to get
this stuff in pa where it should be.

> Well, for me its an 'unsolvable' problem which should probably be best
> left alone. Flash on linux is problematic anyway, such that it may
> make more sense just to download the video and watch it outside the
> browser.

Probably its impossible to get this 100% right due to the ugly flash
issues, but 80% right would be nice start and anything to encourage
html5 and kill flash must be a "good thing" ... as long as it dosn't
screw up by default.

Cheers

--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Jason Taylor at 13/06/10 22:59 did gyre and gimble:
>> Here is my proposal:
>> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
> In my humble opinion....
>
> Device by media.role is not that great.. it stand up for events, but
> it should really be be per client (application)
>
> The major use cases i have right now that suck... and are not solvable
> without prior knowledge of how pa works
> 1 - If I plug in my USB or Bluetooth headset the music does not
> change to headset like my analogue headset does...

With your analogue headset "music" does not change to it, all output
changes to it. I know what you're hinting at, but the two cannot be
compared unless you just talk about "all output".

With my proposal, "music" could be configured to move to the new
USB/bluetooth headset.

> 2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
> not be set to use that mic without restarting skype?

Incorrect. When PA is used, Skype detects it and uses only it. It
(correctly) does not offer you the configuration choice inside Skype. It
is mostly up to tools like gnome-volume-control/pavucontrol etc. to
configure the Skype streams, but in the case of a USB or Bluetooth
headset, the PA module module-intended-roles kicks in and automatically
moves "voip" streams to "headset" devices. This currently works pretty
well (I don't have to do any configuration after setting up my bluetooth
headset for it to "just work" with Skype. It's quite nice, but not very
transparent. If you read the link I sent through, I believe I proposed
there (maybe it was afterwards on the list - can't quite recall) that
module-intended-roles becomes a passive module that simply injects brand
new (never seen before) devices into the appropriate place in the
priority list for the appropriate role. That way it's more transparent
to the user and the net functionality remains the same.

> 3 - There no way to easily set the media role or an app that dosn't
> have one (yes the all should have a role but they don't), pa could be
> doing better here using desktop files and the role should be saved..

PA *does* use .desktop files. That's what module-augment-properties does...

> 4 - Videos do not cork music

No they don't. Currently the automatic corking is implemented by
module-cork-music-on-phone. This could be made more generic with some
kind of simple "rules" file that could be parsed at startup to allow
"video corks music". That would be kinda sensible IMO.


> By default I think pa should:
> - Move all inputs and outputs to any newly connected local device (ie
> usb, bluetooth whatever) that appears after pa has started (unless the
> per client device has been set of course)

Perhaps, but I don't think everyone would agree here. I certainly would
not be appropriate for my crappy bluetooth headset here. It's acceptable
for phone streams, but really not for anything else.

> - There should be a simple UI for setting a clients default media
> role (if one has not been set), and this role should be remembered by
> pa

This could be done, but I'd personally rather not do it. An alternative
would be an independent "database" (like pci.ids or usb.ids) that could
"know" which apps are which roles, that we can update via the web and
bundle when we release, but I think letting users do this removes from
the simplicity that should underlie this system. If the user cares that
much, they can either edit the .desktop file or create a wrapper
script/alias that sets the relevant env vars to allow for role to be forced.

> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video

Not quite sure how easy this would be, but in theory if the client has a
proplist, it should be easy to make any streams that client creates
inherit that (I'd have to check to see if this is not done already!)

> - A module to cork music when video is playing

Should be trivial to do (although depending on the options and
combinations here it may be better to parse some simple rules (or just
rename module-cork-on-phone and call it module-auto-cork or something
and implement this extra rule (tho' I guess separate modules give users
more control).

> Those 4 things would solve every problem I can think of and make pa
> function as I think 90% desktop users expect

I think most points are valid. With the exception of the first one, the
others are not technically that much related to routing (the role points
are related if you assume most routing is role-based (at least
initially)) and as such are probably orthoganal to the routing overhaul
I suggest.

Certainly worth keeping in mind tho'.

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Yves (theYinYeti) at 14/06/10 08:48 did gyre and gimble:
> Le 14/06/2010 01:59, Jason Taylor a écrit :
>> I just realized I missed one other use case... pa has no concept of
>> window order..
>> - With 2 streams of the same role (other then notification) are
>> active the stream that has the higher client in the window stack
>> should be the active stream, all other streams should be corked
>
> I'm not absolutely sure of what "corked" means, but it seems to mean
> "paused".
> If so, I don't agree. Here's an example where I don't want anything to
> happen to current sound when another sound of the same nature begins:
>
> My son watches a cartoon on TV, the picture of which comes from the
> S-Video output of the PC (display :1 ); the sound is directed at the TV
> as well using sound card #2.
> Meanwhile, on the computer's screen (display :0 ), I watch a conference,
> the sound of which goes to the screen's integrated speakers through
> sound card #1.
>
> This setup is quite common with me. Even more often (but then roles are
> different I guess), the HiFi plays Deezer (good music) while the
> integrated speakers let me hear both the orator of the lengthy
> conference I'm attending, and the events' sounds of the little game I
> have alongside, for moments in the conference when there's nothing
> interesting being said.
>
> I definitely don't want any sound to ever be paused or stopped
> automatically. But then, maybe I'm not part of the normal users...

I think you're probably right about being "not part of the normal
users", but that's not to say the problem isn't solvable.

For example, each stream has the following property:
window.x11.display = ":0.0"

It would be theoretically possible to make the cork rules only affect
streams that are on the same display as the one that triggers them. e.g.
a video on display :1 would not affect music on display :0 or similar.

It obviously makes things more complicated, but it's theoretically
possible if someone puts in the work!


Col

--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. [I think this was meant for the list so moving it back there]

'Twas brillig, and Jason Taylor at 15/06/10 02:37 did gyre and gimble:
>>> The major use cases i have right now that suck... and are not solvable
>>> without prior knowledge of how pa works
>>> 1 - If I plug in my USB or Bluetooth headset the music does not
>>> change to headset like my analogue headset does...
>>
>> With your analogue headset "music" does not change to it, all output
>> changes to it. I know what you're hinting at, but the two cannot be
>> compared unless you just talk about "all output".
>
> Yes by "default" I think pa should push "all output" to newly
> registered local devices...
> This is what users expect, as long as its easy to turn off advanced
> users wont have an issue

I really don't think this is wise. There are so many cases where this
doesn't work. If you are in the process of plugging something in, you
*expect* to have to take some action. You're in the mind set that you'll
need to take action to make the device work.

I'm not saying that your suggestion is bad. I've no doubt some users
would like it, but the fact remains that whenever a network device
appears on my network or a bluetooth hifi in the living room appears as
available, I most certainly do not want all my sound moved across to it.

This is the reason why module-intended-roles is contextual. It deals
with the cases where it *is* sensible to do things automatically and
even then it's does them piecemeal, not wholesale.

> advanced meaning anyone who understands the pulseaudio volume control ....

And novice users wont have a clue why their sound just disappeared.
There is always a flip-side.

>>> With my proposal, "music" could be configured to move to the new
>> USB/bluetooth headset.
>>
>>> 2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
>>> not be set to use that mic without restarting skype?
>>
>> Incorrect. When PA is used, Skype detects it and uses only it. It
>> (correctly) does not offer you the configuration choice inside Skype. It
>> is mostly up to tools like gnome-volume-control/pavucontrol etc. to
>> configure the Skype streams, but in the case of a USB or Bluetooth
>> headset, the PA module module-intended-roles kicks in and automatically
>> moves "voip" streams to "headset" devices. This currently works pretty
>> well (I don't have to do any configuration after setting up my bluetooth
>> headset for it to "just work" with Skype. It's quite nice, but not very
>> transparent. If you read the link I sent through, I believe I proposed
>> there (maybe it was afterwards on the list - can't quite recall) that
>> module-intended-roles becomes a passive module that simply injects brand
>> new (never seen before) devices into the appropriate place in the
>> priority list for the appropriate role. That way it's more transparent
>> to the user and the net functionality remains the same.
>
> I've just retired this on ubuntu luicd with skype 2.1.0.81 (confirmed
> the module-intended-roles is loaded)
> - unplugged headset
> - started a call
> - plugged in headset
> - no sound
> - no mic input to skype..
> and the current playing sound was not pushed to the headset.. although
> event sounds from skype seem to have done the right thing.
>
> Perhaps my headset is not detected as a headset? Ethier way it dosnt
> work and as you say pulse should be handling this. I can get it to go
> clicking the right buttons (and restarting skype), my parents or
> sister (who both have linux netbooks) can not...

If you set up anything manually using pavucontrol, this overrides
module-intended-roles, so if you've ever moved any skype stream to a new
device (even if you move it back again) then m-i-r will not work for
you. It's meant to deal with defaults only.

pacmd list (or list-sinks for less output) will tell you if your headset
is detected as a headset.

There was also a bug recently in m-i-r that managed to move skype input
(i.e. it's recording) to the monitor of the output which created a nice
echo for the other party.... I've fixed this, and I believe that Ubuntu
has this fix, but not 100% sure.


>>> By default I think pa should:
>>> - Move all inputs and outputs to any newly connected local device (ie
>>> usb, bluetooth whatever) that appears after pa has started (unless the
>>> per client device has been set of course)
>>
>> Perhaps, but I don't think everyone would agree here. I certainly would
>> not be appropriate for my crappy bluetooth headset here. It's acceptable
>> for phone streams, but really not for anything else.
>
> I'm not arguing it should not be configurable only default behavior

No argument there. I think an option is fine, but I disagree with your
default. It's also debatable whether an option is worth it considering
how many "new" devices a user has in the lifetime of their PC. Maybe a
dozen? Is moving the preference around that difficult under those
circumstances?

>>> - There should be a simple UI for setting a clients default media
>>> role (if one has not been set), and this role should be remembered by
>>> pa
>>
>> This could be done, but I'd personally rather not do it. An alternative
>> would be an independent "database" (like pci.ids or usb.ids) that could
>> "know" which apps are which roles, that we can update via the web and
>> bundle when we release, but I think letting users do this removes from
>> the simplicity that should underlie this system. If the user cares that
>> much, they can either edit the .desktop file or create a wrapper
>> script/alias that sets the relevant env vars to allow for role to be forced.
>
> Agree all apps should have a media role set by default, but asking a
> "human" to edit a file or a script to change media roles is insane...
> all this requires is a dropbox in the UI of the sound control...

I very strongly disagree here. Cluttering up the UI is very much
something we should avoid, especially as the only reason to do so is a
deficiency in metadata that should be sourced from elsewhere.

Like I say, spruce up module-augment-properties with a built in database
of apps->roles mappings will catch 90% of the relevant problem cases and
something that novice users don't have a clue about can be kept away
from causing them confusion in their GUIs. It's also non-trivial to
implement, remembering the client-server model of PA means that the
protocol has to be extended, message formats defined, storage databases
kept; then you have to deal with apps that didn't set their role before,
but now do, if that role is different to what the user picked then who
do you listen to etc. etc.

If power users want to override things, then there are already
mechanisms for that.

So I really do not like this idea. There are far more user friendly ways
to solve the problem of missing metadata.

>>> - Streams should inherit media role from the client if they don't
>>> have one set... ie firefox is set to video, so all its streams have a
>>> media role of video
>>
>> Not quite sure how easy this would be, but in theory if the client has a
>> proplist, it should be easy to make any streams that client creates
>> inherit that (I'd have to check to see if this is not done already!)
>
> If it is done then all thats probably required is saving the change..

As said above, saving the change is non-trivial and I really do not
recommend this approach. And if the client sets it, why would it *need*
to be saved anyway? When the client connects again, it will presumably
set it's role again and then it's streams can inherit it again.

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

Hi everybody,

I've got an onboard soundcard and two usb soundcards and I'd like it
if pulseaudio could switch automatically the default sound card (or
default sink to be more precise) depending on the soundcards that are
currently plugged in. Is this possible?

In case it's not clear what I want, let me explain it on an example:

I've got three soundcards: my onboard card (sd1), my usb card (sd2)
and my headset (sd3) and I want the default card to be the one with
the highest numbering in the sdX naming scheme that is currently
attached to the system.



Thanks,

Geralt.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Dnia 2010-06-11, piÄ… o godzinie 23:37 +0200, Geralt pisze:
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Eh? No idea what sdX mean here.

If you want your audio to be heard over headset, then usb card, then
onboard card, depending on which are available, just set them as
fallbacks with pavucontrol or gnome-volume-control in the reverse
direction (that's - connect your usb card, set it as fallback, then
connect your headset and set that as fallback). That should be enough in
at least with a recent enough PA.

--

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
> Hi everybody,
>
> I've got an onboard soundcard and two usb soundcards and I'd like it
> if pulseaudio could switch automatically the default sound card (or
> default sink to be more precise) depending on the soundcards that are
> currently plugged in. Is this possible?
>
> In case it's not clear what I want, let me explain it on an example:
>
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Bascially you want a priority list of defaults and the current default
to the the highest priority available device to be the one used?

This is possible but no GUI exists on Gnome to exploit it just yet.

This is the routing policy used under KDE, and the PA module
module-device-manager implements this in PulseAudio.

Sadly my proposal to make PA's routing policy work in a (IMO) much more
sensible way, has not yet been endorsed by Lennart so I've not started
working on it. I'm pretty confident that even with some issues it
creates, it's a far more sensible configuration system than is currently
available.

The behaviour you describe would work perfectly under this setup, even
if the priority list itself is never actually exposed to the user via
confirguration GUIs.

Even the current module-default-device-restore does not actually work on
hotplug etc. (as the default is worked out at startup and then set, so
it's idea of the "default device" is lost).

Here is my proposal:
http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/


Hopefully when Lennart is less busy, we can revisit the discussions and
I can convince him I'm right!

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

thanks for your replies :-)

> Dnia 2010-06-11, pi± o godzinie 23:37 +0200, Geralt pisze:
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Eh? No idea what sdX mean here.
>
I was refering to either sd1, sd2 or sd3.

> If you want your audio to be heard over headset, then usb card, then
> onboard card, depending on which are available, just set them as
> fallbacks with pavucontrol or gnome-volume-control in the reverse
> direction (that's - connect your usb card, set it as fallback, then
> connect your headset and set that as fallback). That should be enough in
> at least with a recent enough PA.
>
That's exactly what I want and thanks for mentioning pavucontrol, I
didn't know of this application (I've basically zero experience with
Pulseaudio, yet).

> 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
>> Hi everybody,
>>
>> I've got an onboard soundcard and two usb soundcards and I'd like it
>> if pulseaudio could switch automatically the default sound card (or
>> default sink to be more precise) depending on the soundcards that are
>> currently plugged in. Is this possible?
>>
>> In case it's not clear what I want, let me explain it on an example:
>>
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Bascially you want a priority list of defaults and the current default
> to the the highest priority available device to be the one used?
>
> This is possible but no GUI exists on Gnome to exploit it just yet.
>
> This is the routing policy used under KDE, and the PA module
> module-device-manager implements this in PulseAudio.
>
> Sadly my proposal to make PA's routing policy work in a (IMO) much more
> sensible way, has not yet been endorsed by Lennart so I've not started
> working on it. I'm pretty confident that even with some issues it
> creates, it's a far more sensible configuration system than is currently
> available.
>
> The behaviour you describe would work perfectly under this setup, even
> if the priority list itself is never actually exposed to the user via
> confirguration GUIs.
>
> Even the current module-default-device-restore does not actually work on
> hotplug etc. (as the default is worked out at startup and then set, so
> it's idea of the "default device" is lost).
>
> Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
>
> Hopefully when Lennart is less busy, we can revisit the discussions and
> I can convince him I'm right!
>
That is exactly what I want, however I don't use KDE, is there still a
way to use youre pulseaudio module?



Geralt
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/

In my humble opinion....

Device by media.role is not that great.. it stand up for events, but
it should really be be per client (application)

The major use cases i have right now that suck... and are not solvable
without prior knowledge of how pa works
1 - If I plug in my USB or Bluetooth headset the music does not
change to headset like my analogue headset does...
2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
not be set to use that mic without restarting skype?
3 - There no way to easily set the media role or an app that dosn't
have one (yes the all should have a role but they don't), pa could be
doing better here using desktop files and the role should be saved..
4 - Videos do not cork music

By default I think pa should:
- Move all inputs and outputs to any newly connected local device (ie
usb, bluetooth whatever) that appears after pa has started (unless the
per client device has been set of course)
- There should be a simple UI for setting a clients default media
role (if one has not been set), and this role should be remembered by
pa
- Streams should inherit media role from the client if they don't
have one set... ie firefox is set to video, so all its streams have a
media role of video
- A module to cork music when video is playing

Those 4 things would solve every problem I can think of and make pa
function as I think 90% desktop users expect

Cheers


--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Mon, 2010-06-14 at 09:59 +1200, Jason Taylor wrote:
> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video

No big issue with the rest of your proposals (besides the usual "who's
doing the work?" =p). However this one isn't a good idea, your web
browser plays tons of different things, alert sounds from web-apps,
videos (youtube and friends), audio from sites like pandora, game-sounds
from the various flash time-wasters. If this was classified as video, my
web-app giving me a new IM notification would cork my audio stream
(assuming your other proposals make it in)...

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > No big issue with the rest of your proposals (besides the usual "who's
> doing the work?" =p).

If it would be accepted I would attempt to brush off my rusty c skills..
I'm just not sure how welcome this work would be in pa...

> However this one isn't a good idea, your web
> browser plays tons of different things, alert sounds from web-apps,
> videos (youtube and friends), audio from sites like pandora, game-sounds
> from the various flash time-wasters. If this was classified as video, my
> web-app giving me a new IM notification would cork my audio stream
> (assuming your other proposals make it in)...

The "browser" classification as video was just a suggestion for such a
generic player, nothing else really fits IIMHO.., if the stream was
tagged with correct media.role, then pa would use that, the "video"
would be a fall back position. If you kept your browser with no media
role then nothing would happen as now.. which sucks when viewing a
youtube video and having to open the music player and stop it so you
can hear the video..

html5 tags like video/audio would really help here but thats probably
3 to 5 years away of having any significant role..

I just realized I missed one other use case... pa has no concept of
window order..
- With 2 streams of the same role (other then notification) are
active the stream that has the higher client in the window stack
should be the active stream, all other streams should be corked

Cheers

--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. >> No big issue with the rest of your proposals (besides the usual "who's
>> doing the work?" =p).
>
> If it would be accepted I would attempt to brush off my rusty c skills..
> I'm just not sure how welcome this work would be in pa...

I think its just like other open-source projects, ie. "patches
welcome". Lennart is quite harsh on the quality of said patches, but
once you've met that you're good to go I'd think. Your proposals cover
a whole lot of ground though, and would probably take quite a bit of
hacking.
>
>> However this one isn't a good idea, your web
>> browser plays tons of different things, alert sounds from web-apps,
>> videos (youtube and friends), audio from sites like pandora, game-sounds
>> from the various flash time-wasters. If this was classified as video, my
>> web-app giving me a new IM notification would cork my audio stream
>> (assuming your other proposals make it in)...
>
> The "browser" classification as video was just a suggestion for such a
> generic player, nothing else really fits IIMHO.., if the stream was
> tagged with correct media.role, then pa would use that, the "video"
> would be a fall back position. If you kept your browser with no media
> role then nothing would happen as now.. which sucks when viewing a
> youtube video and having to open the music player and stop it so you
> can hear the video..
>
> html5 tags like video/audio would really help here but thats probably
> 3 to 5 years away of having any significant role..
>
Well, for me its an 'unsolvable' problem which should probably be best
left alone. Flash on linux is problematic anyway, such that it may
make more sense just to download the video and watch it outside the
browser.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I think its just like other open-source projects, ie. "patches
> welcome". Lennart is quite harsh on the quality of said patches, but
> once you've met that you're good to go I'd think. Your proposals cover
> a whole lot of ground though, and would probably take quite a bit of
> hacking.

No problem, one bit at a time.. I'd at least want to know that it had
a chance of work being accepted though instead of .. thats not the
direction we want to go... ;)

I have my python hacks that work for me but it would be nice to get
this stuff in pa where it should be.

> Well, for me its an 'unsolvable' problem which should probably be best
> left alone. Flash on linux is problematic anyway, such that it may
> make more sense just to download the video and watch it outside the
> browser.

Probably its impossible to get this 100% right due to the ugly flash
issues, but 80% right would be nice start and anything to encourage
html5 and kill flash must be a "good thing" ... as long as it dosn't
screw up by default.

Cheers

--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Jason Taylor at 13/06/10 22:59 did gyre and gimble:
>> Here is my proposal:
>> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
> In my humble opinion....
>
> Device by media.role is not that great.. it stand up for events, but
> it should really be be per client (application)
>
> The major use cases i have right now that suck... and are not solvable
> without prior knowledge of how pa works
> 1 - If I plug in my USB or Bluetooth headset the music does not
> change to headset like my analogue headset does...

With your analogue headset "music" does not change to it, all output
changes to it. I know what you're hinting at, but the two cannot be
compared unless you just talk about "all output".

With my proposal, "music" could be configured to move to the new
USB/bluetooth headset.

> 2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
> not be set to use that mic without restarting skype?

Incorrect. When PA is used, Skype detects it and uses only it. It
(correctly) does not offer you the configuration choice inside Skype. It
is mostly up to tools like gnome-volume-control/pavucontrol etc. to
configure the Skype streams, but in the case of a USB or Bluetooth
headset, the PA module module-intended-roles kicks in and automatically
moves "voip" streams to "headset" devices. This currently works pretty
well (I don't have to do any configuration after setting up my bluetooth
headset for it to "just work" with Skype. It's quite nice, but not very
transparent. If you read the link I sent through, I believe I proposed
there (maybe it was afterwards on the list - can't quite recall) that
module-intended-roles becomes a passive module that simply injects brand
new (never seen before) devices into the appropriate place in the
priority list for the appropriate role. That way it's more transparent
to the user and the net functionality remains the same.

> 3 - There no way to easily set the media role or an app that dosn't
> have one (yes the all should have a role but they don't), pa could be
> doing better here using desktop files and the role should be saved..

PA *does* use .desktop files. That's what module-augment-properties does...

> 4 - Videos do not cork music

No they don't. Currently the automatic corking is implemented by
module-cork-music-on-phone. This could be made more generic with some
kind of simple "rules" file that could be parsed at startup to allow
"video corks music". That would be kinda sensible IMO.


> By default I think pa should:
> - Move all inputs and outputs to any newly connected local device (ie
> usb, bluetooth whatever) that appears after pa has started (unless the
> per client device has been set of course)

Perhaps, but I don't think everyone would agree here. I certainly would
not be appropriate for my crappy bluetooth headset here. It's acceptable
for phone streams, but really not for anything else.

> - There should be a simple UI for setting a clients default media
> role (if one has not been set), and this role should be remembered by
> pa

This could be done, but I'd personally rather not do it. An alternative
would be an independent "database" (like pci.ids or usb.ids) that could
"know" which apps are which roles, that we can update via the web and
bundle when we release, but I think letting users do this removes from
the simplicity that should underlie this system. If the user cares that
much, they can either edit the .desktop file or create a wrapper
script/alias that sets the relevant env vars to allow for role to be forced.

> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video

Not quite sure how easy this would be, but in theory if the client has a
proplist, it should be easy to make any streams that client creates
inherit that (I'd have to check to see if this is not done already!)

> - A module to cork music when video is playing

Should be trivial to do (although depending on the options and
combinations here it may be better to parse some simple rules (or just
rename module-cork-on-phone and call it module-auto-cork or something
and implement this extra rule (tho' I guess separate modules give users
more control).

> Those 4 things would solve every problem I can think of and make pa
> function as I think 90% desktop users expect

I think most points are valid. With the exception of the first one, the
others are not technically that much related to routing (the role points
are related if you assume most routing is role-based (at least
initially)) and as such are probably orthoganal to the routing overhaul
I suggest.

Certainly worth keeping in mind tho'.

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Yves (theYinYeti) at 14/06/10 08:48 did gyre and gimble:
> Le 14/06/2010 01:59, Jason Taylor a écrit :
>> I just realized I missed one other use case... pa has no concept of
>> window order..
>> - With 2 streams of the same role (other then notification) are
>> active the stream that has the higher client in the window stack
>> should be the active stream, all other streams should be corked
>
> I'm not absolutely sure of what "corked" means, but it seems to mean
> "paused".
> If so, I don't agree. Here's an example where I don't want anything to
> happen to current sound when another sound of the same nature begins:
>
> My son watches a cartoon on TV, the picture of which comes from the
> S-Video output of the PC (display :1 ); the sound is directed at the TV
> as well using sound card #2.
> Meanwhile, on the computer's screen (display :0 ), I watch a conference,
> the sound of which goes to the screen's integrated speakers through
> sound card #1.
>
> This setup is quite common with me. Even more often (but then roles are
> different I guess), the HiFi plays Deezer (good music) while the
> integrated speakers let me hear both the orator of the lengthy
> conference I'm attending, and the events' sounds of the little game I
> have alongside, for moments in the conference when there's nothing
> interesting being said.
>
> I definitely don't want any sound to ever be paused or stopped
> automatically. But then, maybe I'm not part of the normal users...

I think you're probably right about being "not part of the normal
users", but that's not to say the problem isn't solvable.

For example, each stream has the following property:
window.x11.display = ":0.0"

It would be theoretically possible to make the cork rules only affect
streams that are on the same display as the one that triggers them. e.g.
a video on display :1 would not affect music on display :0 or similar.

It obviously makes things more complicated, but it's theoretically
possible if someone puts in the work!


Col

--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. [I think this was meant for the list so moving it back there]

'Twas brillig, and Jason Taylor at 15/06/10 02:37 did gyre and gimble:
>>> The major use cases i have right now that suck... and are not solvable
>>> without prior knowledge of how pa works
>>> 1 - If I plug in my USB or Bluetooth headset the music does not
>>> change to headset like my analogue headset does...
>>
>> With your analogue headset "music" does not change to it, all output
>> changes to it. I know what you're hinting at, but the two cannot be
>> compared unless you just talk about "all output".
>
> Yes by "default" I think pa should push "all output" to newly
> registered local devices...
> This is what users expect, as long as its easy to turn off advanced
> users wont have an issue

I really don't think this is wise. There are so many cases where this
doesn't work. If you are in the process of plugging something in, you
*expect* to have to take some action. You're in the mind set that you'll
need to take action to make the device work.

I'm not saying that your suggestion is bad. I've no doubt some users
would like it, but the fact remains that whenever a network device
appears on my network or a bluetooth hifi in the living room appears as
available, I most certainly do not want all my sound moved across to it.

This is the reason why module-intended-roles is contextual. It deals
with the cases where it *is* sensible to do things automatically and
even then it's does them piecemeal, not wholesale.

> advanced meaning anyone who understands the pulseaudio volume control ....

And novice users wont have a clue why their sound just disappeared.
There is always a flip-side.

>>> With my proposal, "music" could be configured to move to the new
>> USB/bluetooth headset.
>>
>>> 2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
>>> not be set to use that mic without restarting skype?
>>
>> Incorrect. When PA is used, Skype detects it and uses only it. It
>> (correctly) does not offer you the configuration choice inside Skype. It
>> is mostly up to tools like gnome-volume-control/pavucontrol etc. to
>> configure the Skype streams, but in the case of a USB or Bluetooth
>> headset, the PA module module-intended-roles kicks in and automatically
>> moves "voip" streams to "headset" devices. This currently works pretty
>> well (I don't have to do any configuration after setting up my bluetooth
>> headset for it to "just work" with Skype. It's quite nice, but not very
>> transparent. If you read the link I sent through, I believe I proposed
>> there (maybe it was afterwards on the list - can't quite recall) that
>> module-intended-roles becomes a passive module that simply injects brand
>> new (never seen before) devices into the appropriate place in the
>> priority list for the appropriate role. That way it's more transparent
>> to the user and the net functionality remains the same.
>
> I've just retired this on ubuntu luicd with skype 2.1.0.81 (confirmed
> the module-intended-roles is loaded)
> - unplugged headset
> - started a call
> - plugged in headset
> - no sound
> - no mic input to skype..
> and the current playing sound was not pushed to the headset.. although
> event sounds from skype seem to have done the right thing.
>
> Perhaps my headset is not detected as a headset? Ethier way it dosnt
> work and as you say pulse should be handling this. I can get it to go
> clicking the right buttons (and restarting skype), my parents or
> sister (who both have linux netbooks) can not...

If you set up anything manually using pavucontrol, this overrides
module-intended-roles, so if you've ever moved any skype stream to a new
device (even if you move it back again) then m-i-r will not work for
you. It's meant to deal with defaults only.

pacmd list (or list-sinks for less output) will tell you if your headset
is detected as a headset.

There was also a bug recently in m-i-r that managed to move skype input
(i.e. it's recording) to the monitor of the output which created a nice
echo for the other party.... I've fixed this, and I believe that Ubuntu
has this fix, but not 100% sure.


>>> By default I think pa should:
>>> - Move all inputs and outputs to any newly connected local device (ie
>>> usb, bluetooth whatever) that appears after pa has started (unless the
>>> per client device has been set of course)
>>
>> Perhaps, but I don't think everyone would agree here. I certainly would
>> not be appropriate for my crappy bluetooth headset here. It's acceptable
>> for phone streams, but really not for anything else.
>
> I'm not arguing it should not be configurable only default behavior

No argument there. I think an option is fine, but I disagree with your
default. It's also debatable whether an option is worth it considering
how many "new" devices a user has in the lifetime of their PC. Maybe a
dozen? Is moving the preference around that difficult under those
circumstances?

>>> - There should be a simple UI for setting a clients default media
>>> role (if one has not been set), and this role should be remembered by
>>> pa
>>
>> This could be done, but I'd personally rather not do it. An alternative
>> would be an independent "database" (like pci.ids or usb.ids) that could
>> "know" which apps are which roles, that we can update via the web and
>> bundle when we release, but I think letting users do this removes from
>> the simplicity that should underlie this system. If the user cares that
>> much, they can either edit the .desktop file or create a wrapper
>> script/alias that sets the relevant env vars to allow for role to be forced.
>
> Agree all apps should have a media role set by default, but asking a
> "human" to edit a file or a script to change media roles is insane...
> all this requires is a dropbox in the UI of the sound control...

I very strongly disagree here. Cluttering up the UI is very much
something we should avoid, especially as the only reason to do so is a
deficiency in metadata that should be sourced from elsewhere.

Like I say, spruce up module-augment-properties with a built in database
of apps->roles mappings will catch 90% of the relevant problem cases and
something that novice users don't have a clue about can be kept away
from causing them confusion in their GUIs. It's also non-trivial to
implement, remembering the client-server model of PA means that the
protocol has to be extended, message formats defined, storage databases
kept; then you have to deal with apps that didn't set their role before,
but now do, if that role is different to what the user picked then who
do you listen to etc. etc.

If power users want to override things, then there are already
mechanisms for that.

So I really do not like this idea. There are far more user friendly ways
to solve the problem of missing metadata.

>>> - Streams should inherit media role from the client if they don't
>>> have one set... ie firefox is set to video, so all its streams have a
>>> media role of video
>>
>> Not quite sure how easy this would be, but in theory if the client has a
>> proplist, it should be easy to make any streams that client creates
>> inherit that (I'd have to check to see if this is not done already!)
>
> If it is done then all thats probably required is saving the change..

As said above, saving the change is non-trivial and I really do not
recommend this approach. And if the client sets it, why would it *need*
to be saved anyway? When the client connects again, it will presumably
set it's role again and then it's streams can inherit it again.

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I really don't think this is wise. There are so many cases where this
> doesn't work. If you are in the process of plugging something in, you
> *expect* to have to take some action. You're in the mind set that you'll
> need to take action to make the device work.

Can't disagree strongly enough here.

When you plug headphones into your laptop, the sound switches from the
speakers to the headphones. No intervention. This should definitely be
the same case with plugging in USB headphones.

To get it right, pulseaudio's going to need some logic here, to make
sure the "fallback" is reasonable, even in the light of plug/unplug
events.

--
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

Hi everybody,

I've got an onboard soundcard and two usb soundcards and I'd like it
if pulseaudio could switch automatically the default sound card (or
default sink to be more precise) depending on the soundcards that are
currently plugged in. Is this possible?

In case it's not clear what I want, let me explain it on an example:

I've got three soundcards: my onboard card (sd1), my usb card (sd2)
and my headset (sd3) and I want the default card to be the one with
the highest numbering in the sdX naming scheme that is currently
attached to the system.



Thanks,

Geralt.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Dnia 2010-06-11, piÄ… o godzinie 23:37 +0200, Geralt pisze:
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Eh? No idea what sdX mean here.

If you want your audio to be heard over headset, then usb card, then
onboard card, depending on which are available, just set them as
fallbacks with pavucontrol or gnome-volume-control in the reverse
direction (that's - connect your usb card, set it as fallback, then
connect your headset and set that as fallback). That should be enough in
at least with a recent enough PA.

--

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
> Hi everybody,
>
> I've got an onboard soundcard and two usb soundcards and I'd like it
> if pulseaudio could switch automatically the default sound card (or
> default sink to be more precise) depending on the soundcards that are
> currently plugged in. Is this possible?
>
> In case it's not clear what I want, let me explain it on an example:
>
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Bascially you want a priority list of defaults and the current default
to the the highest priority available device to be the one used?

This is possible but no GUI exists on Gnome to exploit it just yet.

This is the routing policy used under KDE, and the PA module
module-device-manager implements this in PulseAudio.

Sadly my proposal to make PA's routing policy work in a (IMO) much more
sensible way, has not yet been endorsed by Lennart so I've not started
working on it. I'm pretty confident that even with some issues it
creates, it's a far more sensible configuration system than is currently
available.

The behaviour you describe would work perfectly under this setup, even
if the priority list itself is never actually exposed to the user via
confirguration GUIs.

Even the current module-default-device-restore does not actually work on
hotplug etc. (as the default is worked out at startup and then set, so
it's idea of the "default device" is lost).

Here is my proposal:
http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/


Hopefully when Lennart is less busy, we can revisit the discussions and
I can convince him I'm right!

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

thanks for your replies :-)

> Dnia 2010-06-11, pi± o godzinie 23:37 +0200, Geralt pisze:
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Eh? No idea what sdX mean here.
>
I was refering to either sd1, sd2 or sd3.

> If you want your audio to be heard over headset, then usb card, then
> onboard card, depending on which are available, just set them as
> fallbacks with pavucontrol or gnome-volume-control in the reverse
> direction (that's - connect your usb card, set it as fallback, then
> connect your headset and set that as fallback). That should be enough in
> at least with a recent enough PA.
>
That's exactly what I want and thanks for mentioning pavucontrol, I
didn't know of this application (I've basically zero experience with
Pulseaudio, yet).

> 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
>> Hi everybody,
>>
>> I've got an onboard soundcard and two usb soundcards and I'd like it
>> if pulseaudio could switch automatically the default sound card (or
>> default sink to be more precise) depending on the soundcards that are
>> currently plugged in. Is this possible?
>>
>> In case it's not clear what I want, let me explain it on an example:
>>
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Bascially you want a priority list of defaults and the current default
> to the the highest priority available device to be the one used?
>
> This is possible but no GUI exists on Gnome to exploit it just yet.
>
> This is the routing policy used under KDE, and the PA module
> module-device-manager implements this in PulseAudio.
>
> Sadly my proposal to make PA's routing policy work in a (IMO) much more
> sensible way, has not yet been endorsed by Lennart so I've not started
> working on it. I'm pretty confident that even with some issues it
> creates, it's a far more sensible configuration system than is currently
> available.
>
> The behaviour you describe would work perfectly under this setup, even
> if the priority list itself is never actually exposed to the user via
> confirguration GUIs.
>
> Even the current module-default-device-restore does not actually work on
> hotplug etc. (as the default is worked out at startup and then set, so
> it's idea of the "default device" is lost).
>
> Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
>
> Hopefully when Lennart is less busy, we can revisit the discussions and
> I can convince him I'm right!
>
That is exactly what I want, however I don't use KDE, is there still a
way to use youre pulseaudio module?



Geralt
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/

In my humble opinion....

Device by media.role is not that great.. it stand up for events, but
it should really be be per client (application)

The major use cases i have right now that suck... and are not solvable
without prior knowledge of how pa works
1 - If I plug in my USB or Bluetooth headset the music does not
change to headset like my analogue headset does...
2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
not be set to use that mic without restarting skype?
3 - There no way to easily set the media role or an app that dosn't
have one (yes the all should have a role but they don't), pa could be
doing better here using desktop files and the role should be saved..
4 - Videos do not cork music

By default I think pa should:
- Move all inputs and outputs to any newly connected local device (ie
usb, bluetooth whatever) that appears after pa has started (unless the
per client device has been set of course)
- There should be a simple UI for setting a clients default media
role (if one has not been set), and this role should be remembered by
pa
- Streams should inherit media role from the client if they don't
have one set... ie firefox is set to video, so all its streams have a
media role of video
- A module to cork music when video is playing

Those 4 things would solve every problem I can think of and make pa
function as I think 90% desktop users expect

Cheers


--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Mon, 2010-06-14 at 09:59 +1200, Jason Taylor wrote:
> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video

No big issue with the rest of your proposals (besides the usual "who's
doing the work?" =p). However this one isn't a good idea, your web
browser plays tons of different things, alert sounds from web-apps,
videos (youtube and friends), audio from sites like pandora, game-sounds
from the various flash time-wasters. If this was classified as video, my
web-app giving me a new IM notification would cork my audio stream
(assuming your other proposals make it in)...

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > No big issue with the rest of your proposals (besides the usual "who's
> doing the work?" =p).

If it would be accepted I would attempt to brush off my rusty c skills..
I'm just not sure how welcome this work would be in pa...

> However this one isn't a good idea, your web
> browser plays tons of different things, alert sounds from web-apps,
> videos (youtube and friends), audio from sites like pandora, game-sounds
> from the various flash time-wasters. If this was classified as video, my
> web-app giving me a new IM notification would cork my audio stream
> (assuming your other proposals make it in)...

The "browser" classification as video was just a suggestion for such a
generic player, nothing else really fits IIMHO.., if the stream was
tagged with correct media.role, then pa would use that, the "video"
would be a fall back position. If you kept your browser with no media
role then nothing would happen as now.. which sucks when viewing a
youtube video and having to open the music player and stop it so you
can hear the video..

html5 tags like video/audio would really help here but thats probably
3 to 5 years away of having any significant role..

I just realized I missed one other use case... pa has no concept of
window order..
- With 2 streams of the same role (other then notification) are
active the stream that has the higher client in the window stack
should be the active stream, all other streams should be corked

Cheers

--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. >> No big issue with the rest of your proposals (besides the usual "who's
>> doing the work?" =p).
>
> If it would be accepted I would attempt to brush off my rusty c skills..
> I'm just not sure how welcome this work would be in pa...

I think its just like other open-source projects, ie. "patches
welcome". Lennart is quite harsh on the quality of said patches, but
once you've met that you're good to go I'd think. Your proposals cover
a whole lot of ground though, and would probably take quite a bit of
hacking.
>
>> However this one isn't a good idea, your web
>> browser plays tons of different things, alert sounds from web-apps,
>> videos (youtube and friends), audio from sites like pandora, game-sounds
>> from the various flash time-wasters. If this was classified as video, my
>> web-app giving me a new IM notification would cork my audio stream
>> (assuming your other proposals make it in)...
>
> The "browser" classification as video was just a suggestion for such a
> generic player, nothing else really fits IIMHO.., if the stream was
> tagged with correct media.role, then pa would use that, the "video"
> would be a fall back position. If you kept your browser with no media
> role then nothing would happen as now.. which sucks when viewing a
> youtube video and having to open the music player and stop it so you
> can hear the video..
>
> html5 tags like video/audio would really help here but thats probably
> 3 to 5 years away of having any significant role..
>
Well, for me its an 'unsolvable' problem which should probably be best
left alone. Flash on linux is problematic anyway, such that it may
make more sense just to download the video and watch it outside the
browser.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I think its just like other open-source projects, ie. "patches
> welcome". Lennart is quite harsh on the quality of said patches, but
> once you've met that you're good to go I'd think. Your proposals cover
> a whole lot of ground though, and would probably take quite a bit of
> hacking.

No problem, one bit at a time.. I'd at least want to know that it had
a chance of work being accepted though instead of .. thats not the
direction we want to go... ;)

I have my python hacks that work for me but it would be nice to get
this stuff in pa where it should be.

> Well, for me its an 'unsolvable' problem which should probably be best
> left alone. Flash on linux is problematic anyway, such that it may
> make more sense just to download the video and watch it outside the
> browser.

Probably its impossible to get this 100% right due to the ugly flash
issues, but 80% right would be nice start and anything to encourage
html5 and kill flash must be a "good thing" ... as long as it dosn't
screw up by default.

Cheers

--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Jason Taylor at 13/06/10 22:59 did gyre and gimble:
>> Here is my proposal:
>> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
> In my humble opinion....
>
> Device by media.role is not that great.. it stand up for events, but
> it should really be be per client (application)
>
> The major use cases i have right now that suck... and are not solvable
> without prior knowledge of how pa works
> 1 - If I plug in my USB or Bluetooth headset the music does not
> change to headset like my analogue headset does...

With your analogue headset "music" does not change to it, all output
changes to it. I know what you're hinting at, but the two cannot be
compared unless you just talk about "all output".

With my proposal, "music" could be configured to move to the new
USB/bluetooth headset.

> 2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
> not be set to use that mic without restarting skype?

Incorrect. When PA is used, Skype detects it and uses only it. It
(correctly) does not offer you the configuration choice inside Skype. It
is mostly up to tools like gnome-volume-control/pavucontrol etc. to
configure the Skype streams, but in the case of a USB or Bluetooth
headset, the PA module module-intended-roles kicks in and automatically
moves "voip" streams to "headset" devices. This currently works pretty
well (I don't have to do any configuration after setting up my bluetooth
headset for it to "just work" with Skype. It's quite nice, but not very
transparent. If you read the link I sent through, I believe I proposed
there (maybe it was afterwards on the list - can't quite recall) that
module-intended-roles becomes a passive module that simply injects brand
new (never seen before) devices into the appropriate place in the
priority list for the appropriate role. That way it's more transparent
to the user and the net functionality remains the same.

> 3 - There no way to easily set the media role or an app that dosn't
> have one (yes the all should have a role but they don't), pa could be
> doing better here using desktop files and the role should be saved..

PA *does* use .desktop files. That's what module-augment-properties does...

> 4 - Videos do not cork music

No they don't. Currently the automatic corking is implemented by
module-cork-music-on-phone. This could be made more generic with some
kind of simple "rules" file that could be parsed at startup to allow
"video corks music". That would be kinda sensible IMO.


> By default I think pa should:
> - Move all inputs and outputs to any newly connected local device (ie
> usb, bluetooth whatever) that appears after pa has started (unless the
> per client device has been set of course)

Perhaps, but I don't think everyone would agree here. I certainly would
not be appropriate for my crappy bluetooth headset here. It's acceptable
for phone streams, but really not for anything else.

> - There should be a simple UI for setting a clients default media
> role (if one has not been set), and this role should be remembered by
> pa

This could be done, but I'd personally rather not do it. An alternative
would be an independent "database" (like pci.ids or usb.ids) that could
"know" which apps are which roles, that we can update via the web and
bundle when we release, but I think letting users do this removes from
the simplicity that should underlie this system. If the user cares that
much, they can either edit the .desktop file or create a wrapper
script/alias that sets the relevant env vars to allow for role to be forced.

> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video

Not quite sure how easy this would be, but in theory if the client has a
proplist, it should be easy to make any streams that client creates
inherit that (I'd have to check to see if this is not done already!)

> - A module to cork music when video is playing

Should be trivial to do (although depending on the options and
combinations here it may be better to parse some simple rules (or just
rename module-cork-on-phone and call it module-auto-cork or something
and implement this extra rule (tho' I guess separate modules give users
more control).

> Those 4 things would solve every problem I can think of and make pa
> function as I think 90% desktop users expect

I think most points are valid. With the exception of the first one, the
others are not technically that much related to routing (the role points
are related if you assume most routing is role-based (at least
initially)) and as such are probably orthoganal to the routing overhaul
I suggest.

Certainly worth keeping in mind tho'.

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Yves (theYinYeti) at 14/06/10 08:48 did gyre and gimble:
> Le 14/06/2010 01:59, Jason Taylor a écrit :
>> I just realized I missed one other use case... pa has no concept of
>> window order..
>> - With 2 streams of the same role (other then notification) are
>> active the stream that has the higher client in the window stack
>> should be the active stream, all other streams should be corked
>
> I'm not absolutely sure of what "corked" means, but it seems to mean
> "paused".
> If so, I don't agree. Here's an example where I don't want anything to
> happen to current sound when another sound of the same nature begins:
>
> My son watches a cartoon on TV, the picture of which comes from the
> S-Video output of the PC (display :1 ); the sound is directed at the TV
> as well using sound card #2.
> Meanwhile, on the computer's screen (display :0 ), I watch a conference,
> the sound of which goes to the screen's integrated speakers through
> sound card #1.
>
> This setup is quite common with me. Even more often (but then roles are
> different I guess), the HiFi plays Deezer (good music) while the
> integrated speakers let me hear both the orator of the lengthy
> conference I'm attending, and the events' sounds of the little game I
> have alongside, for moments in the conference when there's nothing
> interesting being said.
>
> I definitely don't want any sound to ever be paused or stopped
> automatically. But then, maybe I'm not part of the normal users...

I think you're probably right about being "not part of the normal
users", but that's not to say the problem isn't solvable.

For example, each stream has the following property:
window.x11.display = ":0.0"

It would be theoretically possible to make the cork rules only affect
streams that are on the same display as the one that triggers them. e.g.
a video on display :1 would not affect music on display :0 or similar.

It obviously makes things more complicated, but it's theoretically
possible if someone puts in the work!


Col

--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. [I think this was meant for the list so moving it back there]

'Twas brillig, and Jason Taylor at 15/06/10 02:37 did gyre and gimble:
>>> The major use cases i have right now that suck... and are not solvable
>>> without prior knowledge of how pa works
>>> 1 - If I plug in my USB or Bluetooth headset the music does not
>>> change to headset like my analogue headset does...
>>
>> With your analogue headset "music" does not change to it, all output
>> changes to it. I know what you're hinting at, but the two cannot be
>> compared unless you just talk about "all output".
>
> Yes by "default" I think pa should push "all output" to newly
> registered local devices...
> This is what users expect, as long as its easy to turn off advanced
> users wont have an issue

I really don't think this is wise. There are so many cases where this
doesn't work. If you are in the process of plugging something in, you
*expect* to have to take some action. You're in the mind set that you'll
need to take action to make the device work.

I'm not saying that your suggestion is bad. I've no doubt some users
would like it, but the fact remains that whenever a network device
appears on my network or a bluetooth hifi in the living room appears as
available, I most certainly do not want all my sound moved across to it.

This is the reason why module-intended-roles is contextual. It deals
with the cases where it *is* sensible to do things automatically and
even then it's does them piecemeal, not wholesale.

> advanced meaning anyone who understands the pulseaudio volume control ....

And novice users wont have a clue why their sound just disappeared.
There is always a flip-side.

>>> With my proposal, "music" could be configured to move to the new
>> USB/bluetooth headset.
>>
>>> 2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
>>> not be set to use that mic without restarting skype?
>>
>> Incorrect. When PA is used, Skype detects it and uses only it. It
>> (correctly) does not offer you the configuration choice inside Skype. It
>> is mostly up to tools like gnome-volume-control/pavucontrol etc. to
>> configure the Skype streams, but in the case of a USB or Bluetooth
>> headset, the PA module module-intended-roles kicks in and automatically
>> moves "voip" streams to "headset" devices. This currently works pretty
>> well (I don't have to do any configuration after setting up my bluetooth
>> headset for it to "just work" with Skype. It's quite nice, but not very
>> transparent. If you read the link I sent through, I believe I proposed
>> there (maybe it was afterwards on the list - can't quite recall) that
>> module-intended-roles becomes a passive module that simply injects brand
>> new (never seen before) devices into the appropriate place in the
>> priority list for the appropriate role. That way it's more transparent
>> to the user and the net functionality remains the same.
>
> I've just retired this on ubuntu luicd with skype 2.1.0.81 (confirmed
> the module-intended-roles is loaded)
> - unplugged headset
> - started a call
> - plugged in headset
> - no sound
> - no mic input to skype..
> and the current playing sound was not pushed to the headset.. although
> event sounds from skype seem to have done the right thing.
>
> Perhaps my headset is not detected as a headset? Ethier way it dosnt
> work and as you say pulse should be handling this. I can get it to go
> clicking the right buttons (and restarting skype), my parents or
> sister (who both have linux netbooks) can not...

If you set up anything manually using pavucontrol, this overrides
module-intended-roles, so if you've ever moved any skype stream to a new
device (even if you move it back again) then m-i-r will not work for
you. It's meant to deal with defaults only.

pacmd list (or list-sinks for less output) will tell you if your headset
is detected as a headset.

There was also a bug recently in m-i-r that managed to move skype input
(i.e. it's recording) to the monitor of the output which created a nice
echo for the other party.... I've fixed this, and I believe that Ubuntu
has this fix, but not 100% sure.


>>> By default I think pa should:
>>> - Move all inputs and outputs to any newly connected local device (ie
>>> usb, bluetooth whatever) that appears after pa has started (unless the
>>> per client device has been set of course)
>>
>> Perhaps, but I don't think everyone would agree here. I certainly would
>> not be appropriate for my crappy bluetooth headset here. It's acceptable
>> for phone streams, but really not for anything else.
>
> I'm not arguing it should not be configurable only default behavior

No argument there. I think an option is fine, but I disagree with your
default. It's also debatable whether an option is worth it considering
how many "new" devices a user has in the lifetime of their PC. Maybe a
dozen? Is moving the preference around that difficult under those
circumstances?

>>> - There should be a simple UI for setting a clients default media
>>> role (if one has not been set), and this role should be remembered by
>>> pa
>>
>> This could be done, but I'd personally rather not do it. An alternative
>> would be an independent "database" (like pci.ids or usb.ids) that could
>> "know" which apps are which roles, that we can update via the web and
>> bundle when we release, but I think letting users do this removes from
>> the simplicity that should underlie this system. If the user cares that
>> much, they can either edit the .desktop file or create a wrapper
>> script/alias that sets the relevant env vars to allow for role to be forced.
>
> Agree all apps should have a media role set by default, but asking a
> "human" to edit a file or a script to change media roles is insane...
> all this requires is a dropbox in the UI of the sound control...

I very strongly disagree here. Cluttering up the UI is very much
something we should avoid, especially as the only reason to do so is a
deficiency in metadata that should be sourced from elsewhere.

Like I say, spruce up module-augment-properties with a built in database
of apps->roles mappings will catch 90% of the relevant problem cases and
something that novice users don't have a clue about can be kept away
from causing them confusion in their GUIs. It's also non-trivial to
implement, remembering the client-server model of PA means that the
protocol has to be extended, message formats defined, storage databases
kept; then you have to deal with apps that didn't set their role before,
but now do, if that role is different to what the user picked then who
do you listen to etc. etc.

If power users want to override things, then there are already
mechanisms for that.

So I really do not like this idea. There are far more user friendly ways
to solve the problem of missing metadata.

>>> - Streams should inherit media role from the client if they don't
>>> have one set... ie firefox is set to video, so all its streams have a
>>> media role of video
>>
>> Not quite sure how easy this would be, but in theory if the client has a
>> proplist, it should be easy to make any streams that client creates
>> inherit that (I'd have to check to see if this is not done already!)
>
> If it is done then all thats probably required is saving the change..

As said above, saving the change is non-trivial and I really do not
recommend this approach. And if the client sets it, why would it *need*
to be saved anyway? When the client connects again, it will presumably
set it's role again and then it's streams can inherit it again.

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I really don't think this is wise. There are so many cases where this
> doesn't work. If you are in the process of plugging something in, you
> *expect* to have to take some action. You're in the mind set that you'll
> need to take action to make the device work.

Can't disagree strongly enough here.

When you plug headphones into your laptop, the sound switches from the
speakers to the headphones. No intervention. This should definitely be
the same case with plugging in USB headphones.

To get it right, pulseaudio's going to need some logic here, to make
sure the "fallback" is reasonable, even in the light of plug/unplug
events.

--
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Jeremy Nickurak at 15/06/10 16:31 did gyre and gimble:
>> I really don't think this is wise. There are so many cases where this
>> doesn't work. If you are in the process of plugging something in, you
>> *expect* to have to take some action. You're in the mind set that you'll
>> need to take action to make the device work.
>
> Can't disagree strongly enough here.
>
> When you plug headphones into your laptop, the sound switches from the
> speakers to the headphones. No intervention. This should definitely be
> the same case with plugging in USB headphones.

But speaker jacks are completely different to USB sound devices. You
cannot use them as a comparable example here.

I mean, if I've got some USB speakers which have a jack socket on the
front of them (I'm looking at just such devices right now in front of
me) and I plug in some headphones to the jack socket on my computer, I
do not expect the sound to be moved across from playing on the USB
device to my internal device and subsequently on my headphones when this
happens.

Added to this, there are numerous examples of when I really don't want,
nor would expect this to happen. e.g. I'm playing music and I get my USB
headset to make a VoIP call. My music playing happily on my USB Speakers
and I want it stay there, but as soon as I plug in my headset it
transfers. I'd much rather it stayed where it was. I may want to leave
my USB Headset plugged in (I often do).

I don't think I'm out of the ordinary here. And there are countless
other scenarios where this just doesn't work OOTB.

The general rule is if you can't do something automatically that works
every time, then don't do it automatically at all, but make it easy and
obvious to the user how to do it manually.

Col





--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

Hi everybody,

I've got an onboard soundcard and two usb soundcards and I'd like it
if pulseaudio could switch automatically the default sound card (or
default sink to be more precise) depending on the soundcards that are
currently plugged in. Is this possible?

In case it's not clear what I want, let me explain it on an example:

I've got three soundcards: my onboard card (sd1), my usb card (sd2)
and my headset (sd3) and I want the default card to be the one with
the highest numbering in the sdX naming scheme that is currently
attached to the system.



Thanks,

Geralt.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Dnia 2010-06-11, piÄ… o godzinie 23:37 +0200, Geralt pisze:
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Eh? No idea what sdX mean here.

If you want your audio to be heard over headset, then usb card, then
onboard card, depending on which are available, just set them as
fallbacks with pavucontrol or gnome-volume-control in the reverse
direction (that's - connect your usb card, set it as fallback, then
connect your headset and set that as fallback). That should be enough in
at least with a recent enough PA.

--

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
> Hi everybody,
>
> I've got an onboard soundcard and two usb soundcards and I'd like it
> if pulseaudio could switch automatically the default sound card (or
> default sink to be more precise) depending on the soundcards that are
> currently plugged in. Is this possible?
>
> In case it's not clear what I want, let me explain it on an example:
>
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Bascially you want a priority list of defaults and the current default
to the the highest priority available device to be the one used?

This is possible but no GUI exists on Gnome to exploit it just yet.

This is the routing policy used under KDE, and the PA module
module-device-manager implements this in PulseAudio.

Sadly my proposal to make PA's routing policy work in a (IMO) much more
sensible way, has not yet been endorsed by Lennart so I've not started
working on it. I'm pretty confident that even with some issues it
creates, it's a far more sensible configuration system than is currently
available.

The behaviour you describe would work perfectly under this setup, even
if the priority list itself is never actually exposed to the user via
confirguration GUIs.

Even the current module-default-device-restore does not actually work on
hotplug etc. (as the default is worked out at startup and then set, so
it's idea of the "default device" is lost).

Here is my proposal:
http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/


Hopefully when Lennart is less busy, we can revisit the discussions and
I can convince him I'm right!

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

thanks for your replies :-)

> Dnia 2010-06-11, pi± o godzinie 23:37 +0200, Geralt pisze:
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Eh? No idea what sdX mean here.
>
I was refering to either sd1, sd2 or sd3.

> If you want your audio to be heard over headset, then usb card, then
> onboard card, depending on which are available, just set them as
> fallbacks with pavucontrol or gnome-volume-control in the reverse
> direction (that's - connect your usb card, set it as fallback, then
> connect your headset and set that as fallback). That should be enough in
> at least with a recent enough PA.
>
That's exactly what I want and thanks for mentioning pavucontrol, I
didn't know of this application (I've basically zero experience with
Pulseaudio, yet).

> 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
>> Hi everybody,
>>
>> I've got an onboard soundcard and two usb soundcards and I'd like it
>> if pulseaudio could switch automatically the default sound card (or
>> default sink to be more precise) depending on the soundcards that are
>> currently plugged in. Is this possible?
>>
>> In case it's not clear what I want, let me explain it on an example:
>>
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Bascially you want a priority list of defaults and the current default
> to the the highest priority available device to be the one used?
>
> This is possible but no GUI exists on Gnome to exploit it just yet.
>
> This is the routing policy used under KDE, and the PA module
> module-device-manager implements this in PulseAudio.
>
> Sadly my proposal to make PA's routing policy work in a (IMO) much more
> sensible way, has not yet been endorsed by Lennart so I've not started
> working on it. I'm pretty confident that even with some issues it
> creates, it's a far more sensible configuration system than is currently
> available.
>
> The behaviour you describe would work perfectly under this setup, even
> if the priority list itself is never actually exposed to the user via
> confirguration GUIs.
>
> Even the current module-default-device-restore does not actually work on
> hotplug etc. (as the default is worked out at startup and then set, so
> it's idea of the "default device" is lost).
>
> Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
>
> Hopefully when Lennart is less busy, we can revisit the discussions and
> I can convince him I'm right!
>
That is exactly what I want, however I don't use KDE, is there still a
way to use youre pulseaudio module?



Geralt
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/

In my humble opinion....

Device by media.role is not that great.. it stand up for events, but
it should really be be per client (application)

The major use cases i have right now that suck... and are not solvable
without prior knowledge of how pa works
1 - If I plug in my USB or Bluetooth headset the music does not
change to headset like my analogue headset does...
2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
not be set to use that mic without restarting skype?
3 - There no way to easily set the media role or an app that dosn't
have one (yes the all should have a role but they don't), pa could be
doing better here using desktop files and the role should be saved..
4 - Videos do not cork music

By default I think pa should:
- Move all inputs and outputs to any newly connected local device (ie
usb, bluetooth whatever) that appears after pa has started (unless the
per client device has been set of course)
- There should be a simple UI for setting a clients default media
role (if one has not been set), and this role should be remembered by
pa
- Streams should inherit media role from the client if they don't
have one set... ie firefox is set to video, so all its streams have a
media role of video
- A module to cork music when video is playing

Those 4 things would solve every problem I can think of and make pa
function as I think 90% desktop users expect

Cheers


--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Mon, 2010-06-14 at 09:59 +1200, Jason Taylor wrote:
> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video

No big issue with the rest of your proposals (besides the usual "who's
doing the work?" =p). However this one isn't a good idea, your web
browser plays tons of different things, alert sounds from web-apps,
videos (youtube and friends), audio from sites like pandora, game-sounds
from the various flash time-wasters. If this was classified as video, my
web-app giving me a new IM notification would cork my audio stream
(assuming your other proposals make it in)...

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > No big issue with the rest of your proposals (besides the usual "who's
> doing the work?" =p).

If it would be accepted I would attempt to brush off my rusty c skills..
I'm just not sure how welcome this work would be in pa...

> However this one isn't a good idea, your web
> browser plays tons of different things, alert sounds from web-apps,
> videos (youtube and friends), audio from sites like pandora, game-sounds
> from the various flash time-wasters. If this was classified as video, my
> web-app giving me a new IM notification would cork my audio stream
> (assuming your other proposals make it in)...

The "browser" classification as video was just a suggestion for such a
generic player, nothing else really fits IIMHO.., if the stream was
tagged with correct media.role, then pa would use that, the "video"
would be a fall back position. If you kept your browser with no media
role then nothing would happen as now.. which sucks when viewing a
youtube video and having to open the music player and stop it so you
can hear the video..

html5 tags like video/audio would really help here but thats probably
3 to 5 years away of having any significant role..

I just realized I missed one other use case... pa has no concept of
window order..
- With 2 streams of the same role (other then notification) are
active the stream that has the higher client in the window stack
should be the active stream, all other streams should be corked

Cheers

--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. >> No big issue with the rest of your proposals (besides the usual "who's
>> doing the work?" =p).
>
> If it would be accepted I would attempt to brush off my rusty c skills..
> I'm just not sure how welcome this work would be in pa...

I think its just like other open-source projects, ie. "patches
welcome". Lennart is quite harsh on the quality of said patches, but
once you've met that you're good to go I'd think. Your proposals cover
a whole lot of ground though, and would probably take quite a bit of
hacking.
>
>> However this one isn't a good idea, your web
>> browser plays tons of different things, alert sounds from web-apps,
>> videos (youtube and friends), audio from sites like pandora, game-sounds
>> from the various flash time-wasters. If this was classified as video, my
>> web-app giving me a new IM notification would cork my audio stream
>> (assuming your other proposals make it in)...
>
> The "browser" classification as video was just a suggestion for such a
> generic player, nothing else really fits IIMHO.., if the stream was
> tagged with correct media.role, then pa would use that, the "video"
> would be a fall back position. If you kept your browser with no media
> role then nothing would happen as now.. which sucks when viewing a
> youtube video and having to open the music player and stop it so you
> can hear the video..
>
> html5 tags like video/audio would really help here but thats probably
> 3 to 5 years away of having any significant role..
>
Well, for me its an 'unsolvable' problem which should probably be best
left alone. Flash on linux is problematic anyway, such that it may
make more sense just to download the video and watch it outside the
browser.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I think its just like other open-source projects, ie. "patches
> welcome". Lennart is quite harsh on the quality of said patches, but
> once you've met that you're good to go I'd think. Your proposals cover
> a whole lot of ground though, and would probably take quite a bit of
> hacking.

No problem, one bit at a time.. I'd at least want to know that it had
a chance of work being accepted though instead of .. thats not the
direction we want to go... ;)

I have my python hacks that work for me but it would be nice to get
this stuff in pa where it should be.

> Well, for me its an 'unsolvable' problem which should probably be best
> left alone. Flash on linux is problematic anyway, such that it may
> make more sense just to download the video and watch it outside the
> browser.

Probably its impossible to get this 100% right due to the ugly flash
issues, but 80% right would be nice start and anything to encourage
html5 and kill flash must be a "good thing" ... as long as it dosn't
screw up by default.

Cheers

--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Jason Taylor at 13/06/10 22:59 did gyre and gimble:
>> Here is my proposal:
>> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
> In my humble opinion....
>
> Device by media.role is not that great.. it stand up for events, but
> it should really be be per client (application)
>
> The major use cases i have right now that suck... and are not solvable
> without prior knowledge of how pa works
> 1 - If I plug in my USB or Bluetooth headset the music does not
> change to headset like my analogue headset does...

With your analogue headset "music" does not change to it, all output
changes to it. I know what you're hinting at, but the two cannot be
compared unless you just talk about "all output".

With my proposal, "music" could be configured to move to the new
USB/bluetooth headset.

> 2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
> not be set to use that mic without restarting skype?

Incorrect. When PA is used, Skype detects it and uses only it. It
(correctly) does not offer you the configuration choice inside Skype. It
is mostly up to tools like gnome-volume-control/pavucontrol etc. to
configure the Skype streams, but in the case of a USB or Bluetooth
headset, the PA module module-intended-roles kicks in and automatically
moves "voip" streams to "headset" devices. This currently works pretty
well (I don't have to do any configuration after setting up my bluetooth
headset for it to "just work" with Skype. It's quite nice, but not very
transparent. If you read the link I sent through, I believe I proposed
there (maybe it was afterwards on the list - can't quite recall) that
module-intended-roles becomes a passive module that simply injects brand
new (never seen before) devices into the appropriate place in the
priority list for the appropriate role. That way it's more transparent
to the user and the net functionality remains the same.

> 3 - There no way to easily set the media role or an app that dosn't
> have one (yes the all should have a role but they don't), pa could be
> doing better here using desktop files and the role should be saved..

PA *does* use .desktop files. That's what module-augment-properties does...

> 4 - Videos do not cork music

No they don't. Currently the automatic corking is implemented by
module-cork-music-on-phone. This could be made more generic with some
kind of simple "rules" file that could be parsed at startup to allow
"video corks music". That would be kinda sensible IMO.


> By default I think pa should:
> - Move all inputs and outputs to any newly connected local device (ie
> usb, bluetooth whatever) that appears after pa has started (unless the
> per client device has been set of course)

Perhaps, but I don't think everyone would agree here. I certainly would
not be appropriate for my crappy bluetooth headset here. It's acceptable
for phone streams, but really not for anything else.

> - There should be a simple UI for setting a clients default media
> role (if one has not been set), and this role should be remembered by
> pa

This could be done, but I'd personally rather not do it. An alternative
would be an independent "database" (like pci.ids or usb.ids) that could
"know" which apps are which roles, that we can update via the web and
bundle when we release, but I think letting users do this removes from
the simplicity that should underlie this system. If the user cares that
much, they can either edit the .desktop file or create a wrapper
script/alias that sets the relevant env vars to allow for role to be forced.

> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video

Not quite sure how easy this would be, but in theory if the client has a
proplist, it should be easy to make any streams that client creates
inherit that (I'd have to check to see if this is not done already!)

> - A module to cork music when video is playing

Should be trivial to do (although depending on the options and
combinations here it may be better to parse some simple rules (or just
rename module-cork-on-phone and call it module-auto-cork or something
and implement this extra rule (tho' I guess separate modules give users
more control).

> Those 4 things would solve every problem I can think of and make pa
> function as I think 90% desktop users expect

I think most points are valid. With the exception of the first one, the
others are not technically that much related to routing (the role points
are related if you assume most routing is role-based (at least
initially)) and as such are probably orthoganal to the routing overhaul
I suggest.

Certainly worth keeping in mind tho'.

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Yves (theYinYeti) at 14/06/10 08:48 did gyre and gimble:
> Le 14/06/2010 01:59, Jason Taylor a écrit :
>> I just realized I missed one other use case... pa has no concept of
>> window order..
>> - With 2 streams of the same role (other then notification) are
>> active the stream that has the higher client in the window stack
>> should be the active stream, all other streams should be corked
>
> I'm not absolutely sure of what "corked" means, but it seems to mean
> "paused".
> If so, I don't agree. Here's an example where I don't want anything to
> happen to current sound when another sound of the same nature begins:
>
> My son watches a cartoon on TV, the picture of which comes from the
> S-Video output of the PC (display :1 ); the sound is directed at the TV
> as well using sound card #2.
> Meanwhile, on the computer's screen (display :0 ), I watch a conference,
> the sound of which goes to the screen's integrated speakers through
> sound card #1.
>
> This setup is quite common with me. Even more often (but then roles are
> different I guess), the HiFi plays Deezer (good music) while the
> integrated speakers let me hear both the orator of the lengthy
> conference I'm attending, and the events' sounds of the little game I
> have alongside, for moments in the conference when there's nothing
> interesting being said.
>
> I definitely don't want any sound to ever be paused or stopped
> automatically. But then, maybe I'm not part of the normal users...

I think you're probably right about being "not part of the normal
users", but that's not to say the problem isn't solvable.

For example, each stream has the following property:
window.x11.display = ":0.0"

It would be theoretically possible to make the cork rules only affect
streams that are on the same display as the one that triggers them. e.g.
a video on display :1 would not affect music on display :0 or similar.

It obviously makes things more complicated, but it's theoretically
possible if someone puts in the work!


Col

--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. [I think this was meant for the list so moving it back there]

'Twas brillig, and Jason Taylor at 15/06/10 02:37 did gyre and gimble:
>>> The major use cases i have right now that suck... and are not solvable
>>> without prior knowledge of how pa works
>>> 1 - If I plug in my USB or Bluetooth headset the music does not
>>> change to headset like my analogue headset does...
>>
>> With your analogue headset "music" does not change to it, all output
>> changes to it. I know what you're hinting at, but the two cannot be
>> compared unless you just talk about "all output".
>
> Yes by "default" I think pa should push "all output" to newly
> registered local devices...
> This is what users expect, as long as its easy to turn off advanced
> users wont have an issue

I really don't think this is wise. There are so many cases where this
doesn't work. If you are in the process of plugging something in, you
*expect* to have to take some action. You're in the mind set that you'll
need to take action to make the device work.

I'm not saying that your suggestion is bad. I've no doubt some users
would like it, but the fact remains that whenever a network device
appears on my network or a bluetooth hifi in the living room appears as
available, I most certainly do not want all my sound moved across to it.

This is the reason why module-intended-roles is contextual. It deals
with the cases where it *is* sensible to do things automatically and
even then it's does them piecemeal, not wholesale.

> advanced meaning anyone who understands the pulseaudio volume control ....

And novice users wont have a clue why their sound just disappeared.
There is always a flip-side.

>>> With my proposal, "music" could be configured to move to the new
>> USB/bluetooth headset.
>>
>>> 2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
>>> not be set to use that mic without restarting skype?
>>
>> Incorrect. When PA is used, Skype detects it and uses only it. It
>> (correctly) does not offer you the configuration choice inside Skype. It
>> is mostly up to tools like gnome-volume-control/pavucontrol etc. to
>> configure the Skype streams, but in the case of a USB or Bluetooth
>> headset, the PA module module-intended-roles kicks in and automatically
>> moves "voip" streams to "headset" devices. This currently works pretty
>> well (I don't have to do any configuration after setting up my bluetooth
>> headset for it to "just work" with Skype. It's quite nice, but not very
>> transparent. If you read the link I sent through, I believe I proposed
>> there (maybe it was afterwards on the list - can't quite recall) that
>> module-intended-roles becomes a passive module that simply injects brand
>> new (never seen before) devices into the appropriate place in the
>> priority list for the appropriate role. That way it's more transparent
>> to the user and the net functionality remains the same.
>
> I've just retired this on ubuntu luicd with skype 2.1.0.81 (confirmed
> the module-intended-roles is loaded)
> - unplugged headset
> - started a call
> - plugged in headset
> - no sound
> - no mic input to skype..
> and the current playing sound was not pushed to the headset.. although
> event sounds from skype seem to have done the right thing.
>
> Perhaps my headset is not detected as a headset? Ethier way it dosnt
> work and as you say pulse should be handling this. I can get it to go
> clicking the right buttons (and restarting skype), my parents or
> sister (who both have linux netbooks) can not...

If you set up anything manually using pavucontrol, this overrides
module-intended-roles, so if you've ever moved any skype stream to a new
device (even if you move it back again) then m-i-r will not work for
you. It's meant to deal with defaults only.

pacmd list (or list-sinks for less output) will tell you if your headset
is detected as a headset.

There was also a bug recently in m-i-r that managed to move skype input
(i.e. it's recording) to the monitor of the output which created a nice
echo for the other party.... I've fixed this, and I believe that Ubuntu
has this fix, but not 100% sure.


>>> By default I think pa should:
>>> - Move all inputs and outputs to any newly connected local device (ie
>>> usb, bluetooth whatever) that appears after pa has started (unless the
>>> per client device has been set of course)
>>
>> Perhaps, but I don't think everyone would agree here. I certainly would
>> not be appropriate for my crappy bluetooth headset here. It's acceptable
>> for phone streams, but really not for anything else.
>
> I'm not arguing it should not be configurable only default behavior

No argument there. I think an option is fine, but I disagree with your
default. It's also debatable whether an option is worth it considering
how many "new" devices a user has in the lifetime of their PC. Maybe a
dozen? Is moving the preference around that difficult under those
circumstances?

>>> - There should be a simple UI for setting a clients default media
>>> role (if one has not been set), and this role should be remembered by
>>> pa
>>
>> This could be done, but I'd personally rather not do it. An alternative
>> would be an independent "database" (like pci.ids or usb.ids) that could
>> "know" which apps are which roles, that we can update via the web and
>> bundle when we release, but I think letting users do this removes from
>> the simplicity that should underlie this system. If the user cares that
>> much, they can either edit the .desktop file or create a wrapper
>> script/alias that sets the relevant env vars to allow for role to be forced.
>
> Agree all apps should have a media role set by default, but asking a
> "human" to edit a file or a script to change media roles is insane...
> all this requires is a dropbox in the UI of the sound control...

I very strongly disagree here. Cluttering up the UI is very much
something we should avoid, especially as the only reason to do so is a
deficiency in metadata that should be sourced from elsewhere.

Like I say, spruce up module-augment-properties with a built in database
of apps->roles mappings will catch 90% of the relevant problem cases and
something that novice users don't have a clue about can be kept away
from causing them confusion in their GUIs. It's also non-trivial to
implement, remembering the client-server model of PA means that the
protocol has to be extended, message formats defined, storage databases
kept; then you have to deal with apps that didn't set their role before,
but now do, if that role is different to what the user picked then who
do you listen to etc. etc.

If power users want to override things, then there are already
mechanisms for that.

So I really do not like this idea. There are far more user friendly ways
to solve the problem of missing metadata.

>>> - Streams should inherit media role from the client if they don't
>>> have one set... ie firefox is set to video, so all its streams have a
>>> media role of video
>>
>> Not quite sure how easy this would be, but in theory if the client has a
>> proplist, it should be easy to make any streams that client creates
>> inherit that (I'd have to check to see if this is not done already!)
>
> If it is done then all thats probably required is saving the change..

As said above, saving the change is non-trivial and I really do not
recommend this approach. And if the client sets it, why would it *need*
to be saved anyway? When the client connects again, it will presumably
set it's role again and then it's streams can inherit it again.

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I really don't think this is wise. There are so many cases where this
> doesn't work. If you are in the process of plugging something in, you
> *expect* to have to take some action. You're in the mind set that you'll
> need to take action to make the device work.

Can't disagree strongly enough here.

When you plug headphones into your laptop, the sound switches from the
speakers to the headphones. No intervention. This should definitely be
the same case with plugging in USB headphones.

To get it right, pulseaudio's going to need some logic here, to make
sure the "fallback" is reasonable, even in the light of plug/unplug
events.

--
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Jeremy Nickurak at 15/06/10 16:31 did gyre and gimble:
>> I really don't think this is wise. There are so many cases where this
>> doesn't work. If you are in the process of plugging something in, you
>> *expect* to have to take some action. You're in the mind set that you'll
>> need to take action to make the device work.
>
> Can't disagree strongly enough here.
>
> When you plug headphones into your laptop, the sound switches from the
> speakers to the headphones. No intervention. This should definitely be
> the same case with plugging in USB headphones.

But speaker jacks are completely different to USB sound devices. You
cannot use them as a comparable example here.

I mean, if I've got some USB speakers which have a jack socket on the
front of them (I'm looking at just such devices right now in front of
me) and I plug in some headphones to the jack socket on my computer, I
do not expect the sound to be moved across from playing on the USB
device to my internal device and subsequently on my headphones when this
happens.

Added to this, there are numerous examples of when I really don't want,
nor would expect this to happen. e.g. I'm playing music and I get my USB
headset to make a VoIP call. My music playing happily on my USB Speakers
and I want it stay there, but as soon as I plug in my headset it
transfers. I'd much rather it stayed where it was. I may want to leave
my USB Headset plugged in (I often do).

I don't think I'm out of the ordinary here. And there are countless
other scenarios where this just doesn't work OOTB.

The general rule is if you can't do something automatically that works
every time, then don't do it automatically at all, but make it easy and
obvious to the user how to do it manually.

Col





--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Nathan Kidd at 15/06/10 17:18 did gyre and gimble:
> I think the ability to say "this is my preferred sound device" would be
> ideal. So if that device gets plugged in it automatically becomes the
> output.
>
> You don't make your headset the preferred device, and you're happy. For
> me, I really want my good-sounding USB speakers to automatically work
> when I plug them into my (crappy-speakers-) laptop. The
> portability/sound quality tug-of-war causes me to be constantly fiddling
> with sound preferences.

What you want here is definitely something that will be supported.

That's not the debate. The discussion is about what should happen by
*default* the very first time a device is plugged in.

I maintain that the new device should not change your setup and that,
except in some special cases (like VoIP calls for Headset devices) the
new device should be injected in at the bottom of the priority list of
devices, not at the top.

Col

--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

Hi everybody,

I've got an onboard soundcard and two usb soundcards and I'd like it
if pulseaudio could switch automatically the default sound card (or
default sink to be more precise) depending on the soundcards that are
currently plugged in. Is this possible?

In case it's not clear what I want, let me explain it on an example:

I've got three soundcards: my onboard card (sd1), my usb card (sd2)
and my headset (sd3) and I want the default card to be the one with
the highest numbering in the sdX naming scheme that is currently
attached to the system.



Thanks,

Geralt.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Dnia 2010-06-11, piÄ… o godzinie 23:37 +0200, Geralt pisze:
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Eh? No idea what sdX mean here.

If you want your audio to be heard over headset, then usb card, then
onboard card, depending on which are available, just set them as
fallbacks with pavucontrol or gnome-volume-control in the reverse
direction (that's - connect your usb card, set it as fallback, then
connect your headset and set that as fallback). That should be enough in
at least with a recent enough PA.

--

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
> Hi everybody,
>
> I've got an onboard soundcard and two usb soundcards and I'd like it
> if pulseaudio could switch automatically the default sound card (or
> default sink to be more precise) depending on the soundcards that are
> currently plugged in. Is this possible?
>
> In case it's not clear what I want, let me explain it on an example:
>
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Bascially you want a priority list of defaults and the current default
to the the highest priority available device to be the one used?

This is possible but no GUI exists on Gnome to exploit it just yet.

This is the routing policy used under KDE, and the PA module
module-device-manager implements this in PulseAudio.

Sadly my proposal to make PA's routing policy work in a (IMO) much more
sensible way, has not yet been endorsed by Lennart so I've not started
working on it. I'm pretty confident that even with some issues it
creates, it's a far more sensible configuration system than is currently
available.

The behaviour you describe would work perfectly under this setup, even
if the priority list itself is never actually exposed to the user via
confirguration GUIs.

Even the current module-default-device-restore does not actually work on
hotplug etc. (as the default is worked out at startup and then set, so
it's idea of the "default device" is lost).

Here is my proposal:
http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/


Hopefully when Lennart is less busy, we can revisit the discussions and
I can convince him I'm right!

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

thanks for your replies :-)

> Dnia 2010-06-11, pi± o godzinie 23:37 +0200, Geralt pisze:
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Eh? No idea what sdX mean here.
>
I was refering to either sd1, sd2 or sd3.

> If you want your audio to be heard over headset, then usb card, then
> onboard card, depending on which are available, just set them as
> fallbacks with pavucontrol or gnome-volume-control in the reverse
> direction (that's - connect your usb card, set it as fallback, then
> connect your headset and set that as fallback). That should be enough in
> at least with a recent enough PA.
>
That's exactly what I want and thanks for mentioning pavucontrol, I
didn't know of this application (I've basically zero experience with
Pulseaudio, yet).

> 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
>> Hi everybody,
>>
>> I've got an onboard soundcard and two usb soundcards and I'd like it
>> if pulseaudio could switch automatically the default sound card (or
>> default sink to be more precise) depending on the soundcards that are
>> currently plugged in. Is this possible?
>>
>> In case it's not clear what I want, let me explain it on an example:
>>
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Bascially you want a priority list of defaults and the current default
> to the the highest priority available device to be the one used?
>
> This is possible but no GUI exists on Gnome to exploit it just yet.
>
> This is the routing policy used under KDE, and the PA module
> module-device-manager implements this in PulseAudio.
>
> Sadly my proposal to make PA's routing policy work in a (IMO) much more
> sensible way, has not yet been endorsed by Lennart so I've not started
> working on it. I'm pretty confident that even with some issues it
> creates, it's a far more sensible configuration system than is currently
> available.
>
> The behaviour you describe would work perfectly under this setup, even
> if the priority list itself is never actually exposed to the user via
> confirguration GUIs.
>
> Even the current module-default-device-restore does not actually work on
> hotplug etc. (as the default is worked out at startup and then set, so
> it's idea of the "default device" is lost).
>
> Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
>
> Hopefully when Lennart is less busy, we can revisit the discussions and
> I can convince him I'm right!
>
That is exactly what I want, however I don't use KDE, is there still a
way to use youre pulseaudio module?



Geralt
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/

In my humble opinion....

Device by media.role is not that great.. it stand up for events, but
it should really be be per client (application)

The major use cases i have right now that suck... and are not solvable
without prior knowledge of how pa works
1 - If I plug in my USB or Bluetooth headset the music does not
change to headset like my analogue headset does...
2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
not be set to use that mic without restarting skype?
3 - There no way to easily set the media role or an app that dosn't
have one (yes the all should have a role but they don't), pa could be
doing better here using desktop files and the role should be saved..
4 - Videos do not cork music

By default I think pa should:
- Move all inputs and outputs to any newly connected local device (ie
usb, bluetooth whatever) that appears after pa has started (unless the
per client device has been set of course)
- There should be a simple UI for setting a clients default media
role (if one has not been set), and this role should be remembered by
pa
- Streams should inherit media role from the client if they don't
have one set... ie firefox is set to video, so all its streams have a
media role of video
- A module to cork music when video is playing

Those 4 things would solve every problem I can think of and make pa
function as I think 90% desktop users expect

Cheers


--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Mon, 2010-06-14 at 09:59 +1200, Jason Taylor wrote:
> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video

No big issue with the rest of your proposals (besides the usual "who's
doing the work?" =p). However this one isn't a good idea, your web
browser plays tons of different things, alert sounds from web-apps,
videos (youtube and friends), audio from sites like pandora, game-sounds
from the various flash time-wasters. If this was classified as video, my
web-app giving me a new IM notification would cork my audio stream
(assuming your other proposals make it in)...

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > No big issue with the rest of your proposals (besides the usual "who's
> doing the work?" =p).

If it would be accepted I would attempt to brush off my rusty c skills..
I'm just not sure how welcome this work would be in pa...

> However this one isn't a good idea, your web
> browser plays tons of different things, alert sounds from web-apps,
> videos (youtube and friends), audio from sites like pandora, game-sounds
> from the various flash time-wasters. If this was classified as video, my
> web-app giving me a new IM notification would cork my audio stream
> (assuming your other proposals make it in)...

The "browser" classification as video was just a suggestion for such a
generic player, nothing else really fits IIMHO.., if the stream was
tagged with correct media.role, then pa would use that, the "video"
would be a fall back position. If you kept your browser with no media
role then nothing would happen as now.. which sucks when viewing a
youtube video and having to open the music player and stop it so you
can hear the video..

html5 tags like video/audio would really help here but thats probably
3 to 5 years away of having any significant role..

I just realized I missed one other use case... pa has no concept of
window order..
- With 2 streams of the same role (other then notification) are
active the stream that has the higher client in the window stack
should be the active stream, all other streams should be corked

Cheers

--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. >> No big issue with the rest of your proposals (besides the usual "who's
>> doing the work?" =p).
>
> If it would be accepted I would attempt to brush off my rusty c skills..
> I'm just not sure how welcome this work would be in pa...

I think its just like other open-source projects, ie. "patches
welcome". Lennart is quite harsh on the quality of said patches, but
once you've met that you're good to go I'd think. Your proposals cover
a whole lot of ground though, and would probably take quite a bit of
hacking.
>
>> However this one isn't a good idea, your web
>> browser plays tons of different things, alert sounds from web-apps,
>> videos (youtube and friends), audio from sites like pandora, game-sounds
>> from the various flash time-wasters. If this was classified as video, my
>> web-app giving me a new IM notification would cork my audio stream
>> (assuming your other proposals make it in)...
>
> The "browser" classification as video was just a suggestion for such a
> generic player, nothing else really fits IIMHO.., if the stream was
> tagged with correct media.role, then pa would use that, the "video"
> would be a fall back position. If you kept your browser with no media
> role then nothing would happen as now.. which sucks when viewing a
> youtube video and having to open the music player and stop it so you
> can hear the video..
>
> html5 tags like video/audio would really help here but thats probably
> 3 to 5 years away of having any significant role..
>
Well, for me its an 'unsolvable' problem which should probably be best
left alone. Flash on linux is problematic anyway, such that it may
make more sense just to download the video and watch it outside the
browser.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I think its just like other open-source projects, ie. "patches
> welcome". Lennart is quite harsh on the quality of said patches, but
> once you've met that you're good to go I'd think. Your proposals cover
> a whole lot of ground though, and would probably take quite a bit of
> hacking.

No problem, one bit at a time.. I'd at least want to know that it had
a chance of work being accepted though instead of .. thats not the
direction we want to go... ;)

I have my python hacks that work for me but it would be nice to get
this stuff in pa where it should be.

> Well, for me its an 'unsolvable' problem which should probably be best
> left alone. Flash on linux is problematic anyway, such that it may
> make more sense just to download the video and watch it outside the
> browser.

Probably its impossible to get this 100% right due to the ugly flash
issues, but 80% right would be nice start and anything to encourage
html5 and kill flash must be a "good thing" ... as long as it dosn't
screw up by default.

Cheers

--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Jason Taylor at 13/06/10 22:59 did gyre and gimble:
>> Here is my proposal:
>> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
> In my humble opinion....
>
> Device by media.role is not that great.. it stand up for events, but
> it should really be be per client (application)
>
> The major use cases i have right now that suck... and are not solvable
> without prior knowledge of how pa works
> 1 - If I plug in my USB or Bluetooth headset the music does not
> change to headset like my analogue headset does...

With your analogue headset "music" does not change to it, all output
changes to it. I know what you're hinting at, but the two cannot be
compared unless you just talk about "all output".

With my proposal, "music" could be configured to move to the new
USB/bluetooth headset.

> 2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
> not be set to use that mic without restarting skype?

Incorrect. When PA is used, Skype detects it and uses only it. It
(correctly) does not offer you the configuration choice inside Skype. It
is mostly up to tools like gnome-volume-control/pavucontrol etc. to
configure the Skype streams, but in the case of a USB or Bluetooth
headset, the PA module module-intended-roles kicks in and automatically
moves "voip" streams to "headset" devices. This currently works pretty
well (I don't have to do any configuration after setting up my bluetooth
headset for it to "just work" with Skype. It's quite nice, but not very
transparent. If you read the link I sent through, I believe I proposed
there (maybe it was afterwards on the list - can't quite recall) that
module-intended-roles becomes a passive module that simply injects brand
new (never seen before) devices into the appropriate place in the
priority list for the appropriate role. That way it's more transparent
to the user and the net functionality remains the same.

> 3 - There no way to easily set the media role or an app that dosn't
> have one (yes the all should have a role but they don't), pa could be
> doing better here using desktop files and the role should be saved..

PA *does* use .desktop files. That's what module-augment-properties does...

> 4 - Videos do not cork music

No they don't. Currently the automatic corking is implemented by
module-cork-music-on-phone. This could be made more generic with some
kind of simple "rules" file that could be parsed at startup to allow
"video corks music". That would be kinda sensible IMO.


> By default I think pa should:
> - Move all inputs and outputs to any newly connected local device (ie
> usb, bluetooth whatever) that appears after pa has started (unless the
> per client device has been set of course)

Perhaps, but I don't think everyone would agree here. I certainly would
not be appropriate for my crappy bluetooth headset here. It's acceptable
for phone streams, but really not for anything else.

> - There should be a simple UI for setting a clients default media
> role (if one has not been set), and this role should be remembered by
> pa

This could be done, but I'd personally rather not do it. An alternative
would be an independent "database" (like pci.ids or usb.ids) that could
"know" which apps are which roles, that we can update via the web and
bundle when we release, but I think letting users do this removes from
the simplicity that should underlie this system. If the user cares that
much, they can either edit the .desktop file or create a wrapper
script/alias that sets the relevant env vars to allow for role to be forced.

> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video

Not quite sure how easy this would be, but in theory if the client has a
proplist, it should be easy to make any streams that client creates
inherit that (I'd have to check to see if this is not done already!)

> - A module to cork music when video is playing

Should be trivial to do (although depending on the options and
combinations here it may be better to parse some simple rules (or just
rename module-cork-on-phone and call it module-auto-cork or something
and implement this extra rule (tho' I guess separate modules give users
more control).

> Those 4 things would solve every problem I can think of and make pa
> function as I think 90% desktop users expect

I think most points are valid. With the exception of the first one, the
others are not technically that much related to routing (the role points
are related if you assume most routing is role-based (at least
initially)) and as such are probably orthoganal to the routing overhaul
I suggest.

Certainly worth keeping in mind tho'.

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Yves (theYinYeti) at 14/06/10 08:48 did gyre and gimble:
> Le 14/06/2010 01:59, Jason Taylor a écrit :
>> I just realized I missed one other use case... pa has no concept of
>> window order..
>> - With 2 streams of the same role (other then notification) are
>> active the stream that has the higher client in the window stack
>> should be the active stream, all other streams should be corked
>
> I'm not absolutely sure of what "corked" means, but it seems to mean
> "paused".
> If so, I don't agree. Here's an example where I don't want anything to
> happen to current sound when another sound of the same nature begins:
>
> My son watches a cartoon on TV, the picture of which comes from the
> S-Video output of the PC (display :1 ); the sound is directed at the TV
> as well using sound card #2.
> Meanwhile, on the computer's screen (display :0 ), I watch a conference,
> the sound of which goes to the screen's integrated speakers through
> sound card #1.
>
> This setup is quite common with me. Even more often (but then roles are
> different I guess), the HiFi plays Deezer (good music) while the
> integrated speakers let me hear both the orator of the lengthy
> conference I'm attending, and the events' sounds of the little game I
> have alongside, for moments in the conference when there's nothing
> interesting being said.
>
> I definitely don't want any sound to ever be paused or stopped
> automatically. But then, maybe I'm not part of the normal users...

I think you're probably right about being "not part of the normal
users", but that's not to say the problem isn't solvable.

For example, each stream has the following property:
window.x11.display = ":0.0"

It would be theoretically possible to make the cork rules only affect
streams that are on the same display as the one that triggers them. e.g.
a video on display :1 would not affect music on display :0 or similar.

It obviously makes things more complicated, but it's theoretically
possible if someone puts in the work!


Col

--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. [I think this was meant for the list so moving it back there]

'Twas brillig, and Jason Taylor at 15/06/10 02:37 did gyre and gimble:
>>> The major use cases i have right now that suck... and are not solvable
>>> without prior knowledge of how pa works
>>> 1 - If I plug in my USB or Bluetooth headset the music does not
>>> change to headset like my analogue headset does...
>>
>> With your analogue headset "music" does not change to it, all output
>> changes to it. I know what you're hinting at, but the two cannot be
>> compared unless you just talk about "all output".
>
> Yes by "default" I think pa should push "all output" to newly
> registered local devices...
> This is what users expect, as long as its easy to turn off advanced
> users wont have an issue

I really don't think this is wise. There are so many cases where this
doesn't work. If you are in the process of plugging something in, you
*expect* to have to take some action. You're in the mind set that you'll
need to take action to make the device work.

I'm not saying that your suggestion is bad. I've no doubt some users
would like it, but the fact remains that whenever a network device
appears on my network or a bluetooth hifi in the living room appears as
available, I most certainly do not want all my sound moved across to it.

This is the reason why module-intended-roles is contextual. It deals
with the cases where it *is* sensible to do things automatically and
even then it's does them piecemeal, not wholesale.

> advanced meaning anyone who understands the pulseaudio volume control ....

And novice users wont have a clue why their sound just disappeared.
There is always a flip-side.

>>> With my proposal, "music" could be configured to move to the new
>> USB/bluetooth headset.
>>
>>> 2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
>>> not be set to use that mic without restarting skype?
>>
>> Incorrect. When PA is used, Skype detects it and uses only it. It
>> (correctly) does not offer you the configuration choice inside Skype. It
>> is mostly up to tools like gnome-volume-control/pavucontrol etc. to
>> configure the Skype streams, but in the case of a USB or Bluetooth
>> headset, the PA module module-intended-roles kicks in and automatically
>> moves "voip" streams to "headset" devices. This currently works pretty
>> well (I don't have to do any configuration after setting up my bluetooth
>> headset for it to "just work" with Skype. It's quite nice, but not very
>> transparent. If you read the link I sent through, I believe I proposed
>> there (maybe it was afterwards on the list - can't quite recall) that
>> module-intended-roles becomes a passive module that simply injects brand
>> new (never seen before) devices into the appropriate place in the
>> priority list for the appropriate role. That way it's more transparent
>> to the user and the net functionality remains the same.
>
> I've just retired this on ubuntu luicd with skype 2.1.0.81 (confirmed
> the module-intended-roles is loaded)
> - unplugged headset
> - started a call
> - plugged in headset
> - no sound
> - no mic input to skype..
> and the current playing sound was not pushed to the headset.. although
> event sounds from skype seem to have done the right thing.
>
> Perhaps my headset is not detected as a headset? Ethier way it dosnt
> work and as you say pulse should be handling this. I can get it to go
> clicking the right buttons (and restarting skype), my parents or
> sister (who both have linux netbooks) can not...

If you set up anything manually using pavucontrol, this overrides
module-intended-roles, so if you've ever moved any skype stream to a new
device (even if you move it back again) then m-i-r will not work for
you. It's meant to deal with defaults only.

pacmd list (or list-sinks for less output) will tell you if your headset
is detected as a headset.

There was also a bug recently in m-i-r that managed to move skype input
(i.e. it's recording) to the monitor of the output which created a nice
echo for the other party.... I've fixed this, and I believe that Ubuntu
has this fix, but not 100% sure.


>>> By default I think pa should:
>>> - Move all inputs and outputs to any newly connected local device (ie
>>> usb, bluetooth whatever) that appears after pa has started (unless the
>>> per client device has been set of course)
>>
>> Perhaps, but I don't think everyone would agree here. I certainly would
>> not be appropriate for my crappy bluetooth headset here. It's acceptable
>> for phone streams, but really not for anything else.
>
> I'm not arguing it should not be configurable only default behavior

No argument there. I think an option is fine, but I disagree with your
default. It's also debatable whether an option is worth it considering
how many "new" devices a user has in the lifetime of their PC. Maybe a
dozen? Is moving the preference around that difficult under those
circumstances?

>>> - There should be a simple UI for setting a clients default media
>>> role (if one has not been set), and this role should be remembered by
>>> pa
>>
>> This could be done, but I'd personally rather not do it. An alternative
>> would be an independent "database" (like pci.ids or usb.ids) that could
>> "know" which apps are which roles, that we can update via the web and
>> bundle when we release, but I think letting users do this removes from
>> the simplicity that should underlie this system. If the user cares that
>> much, they can either edit the .desktop file or create a wrapper
>> script/alias that sets the relevant env vars to allow for role to be forced.
>
> Agree all apps should have a media role set by default, but asking a
> "human" to edit a file or a script to change media roles is insane...
> all this requires is a dropbox in the UI of the sound control...

I very strongly disagree here. Cluttering up the UI is very much
something we should avoid, especially as the only reason to do so is a
deficiency in metadata that should be sourced from elsewhere.

Like I say, spruce up module-augment-properties with a built in database
of apps->roles mappings will catch 90% of the relevant problem cases and
something that novice users don't have a clue about can be kept away
from causing them confusion in their GUIs. It's also non-trivial to
implement, remembering the client-server model of PA means that the
protocol has to be extended, message formats defined, storage databases
kept; then you have to deal with apps that didn't set their role before,
but now do, if that role is different to what the user picked then who
do you listen to etc. etc.

If power users want to override things, then there are already
mechanisms for that.

So I really do not like this idea. There are far more user friendly ways
to solve the problem of missing metadata.

>>> - Streams should inherit media role from the client if they don't
>>> have one set... ie firefox is set to video, so all its streams have a
>>> media role of video
>>
>> Not quite sure how easy this would be, but in theory if the client has a
>> proplist, it should be easy to make any streams that client creates
>> inherit that (I'd have to check to see if this is not done already!)
>
> If it is done then all thats probably required is saving the change..

As said above, saving the change is non-trivial and I really do not
recommend this approach. And if the client sets it, why would it *need*
to be saved anyway? When the client connects again, it will presumably
set it's role again and then it's streams can inherit it again.

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I really don't think this is wise. There are so many cases where this
> doesn't work. If you are in the process of plugging something in, you
> *expect* to have to take some action. You're in the mind set that you'll
> need to take action to make the device work.

Can't disagree strongly enough here.

When you plug headphones into your laptop, the sound switches from the
speakers to the headphones. No intervention. This should definitely be
the same case with plugging in USB headphones.

To get it right, pulseaudio's going to need some logic here, to make
sure the "fallback" is reasonable, even in the light of plug/unplug
events.

--
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Jeremy Nickurak at 15/06/10 16:31 did gyre and gimble:
>> I really don't think this is wise. There are so many cases where this
>> doesn't work. If you are in the process of plugging something in, you
>> *expect* to have to take some action. You're in the mind set that you'll
>> need to take action to make the device work.
>
> Can't disagree strongly enough here.
>
> When you plug headphones into your laptop, the sound switches from the
> speakers to the headphones. No intervention. This should definitely be
> the same case with plugging in USB headphones.

But speaker jacks are completely different to USB sound devices. You
cannot use them as a comparable example here.

I mean, if I've got some USB speakers which have a jack socket on the
front of them (I'm looking at just such devices right now in front of
me) and I plug in some headphones to the jack socket on my computer, I
do not expect the sound to be moved across from playing on the USB
device to my internal device and subsequently on my headphones when this
happens.

Added to this, there are numerous examples of when I really don't want,
nor would expect this to happen. e.g. I'm playing music and I get my USB
headset to make a VoIP call. My music playing happily on my USB Speakers
and I want it stay there, but as soon as I plug in my headset it
transfers. I'd much rather it stayed where it was. I may want to leave
my USB Headset plugged in (I often do).

I don't think I'm out of the ordinary here. And there are countless
other scenarios where this just doesn't work OOTB.

The general rule is if you can't do something automatically that works
every time, then don't do it automatically at all, but make it easy and
obvious to the user how to do it manually.

Col





--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Nathan Kidd at 15/06/10 17:18 did gyre and gimble:
> I think the ability to say "this is my preferred sound device" would be
> ideal. So if that device gets plugged in it automatically becomes the
> output.
>
> You don't make your headset the preferred device, and you're happy. For
> me, I really want my good-sounding USB speakers to automatically work
> when I plug them into my (crappy-speakers-) laptop. The
> portability/sound quality tug-of-war causes me to be constantly fiddling
> with sound preferences.

What you want here is definitely something that will be supported.

That's not the debate. The discussion is about what should happen by
*default* the very first time a device is plugged in.

I maintain that the new device should not change your setup and that,
except in some special cases (like VoIP calls for Headset devices) the
new device should be injected in at the bottom of the priority list of
devices, not at the top.

Col

--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On 10-06-15 12:38 PM, Colin Guthrie wrote:
> 'Twas brillig, and Nathan Kidd at 15/06/10 17:18 did gyre and gimble:
>> I think the ability to say "this is my preferred sound device" would be
>> ideal. So if that device gets plugged in it automatically becomes the
>> output.
>>
>> You don't make your headset the preferred device, and you're happy. For
>> me, I really want my good-sounding USB speakers to automatically work
>> when I plug them into my (crappy-speakers-) laptop. The
>> portability/sound quality tug-of-war causes me to be constantly fiddling
>> with sound preferences.
>
> What you want here is definitely something that will be supported.
>
> That's not the debate. The discussion is about what should happen by
> *default* the very first time a device is plugged in.

Mea culpa for not reading the whole thread first.

-Nathan
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

Hi everybody,

I've got an onboard soundcard and two usb soundcards and I'd like it
if pulseaudio could switch automatically the default sound card (or
default sink to be more precise) depending on the soundcards that are
currently plugged in. Is this possible?

In case it's not clear what I want, let me explain it on an example:

I've got three soundcards: my onboard card (sd1), my usb card (sd2)
and my headset (sd3) and I want the default card to be the one with
the highest numbering in the sdX naming scheme that is currently
attached to the system.



Thanks,

Geralt.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Dnia 2010-06-11, piÄ… o godzinie 23:37 +0200, Geralt pisze:
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Eh? No idea what sdX mean here.

If you want your audio to be heard over headset, then usb card, then
onboard card, depending on which are available, just set them as
fallbacks with pavucontrol or gnome-volume-control in the reverse
direction (that's - connect your usb card, set it as fallback, then
connect your headset and set that as fallback). That should be enough in
at least with a recent enough PA.

--

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
> Hi everybody,
>
> I've got an onboard soundcard and two usb soundcards and I'd like it
> if pulseaudio could switch automatically the default sound card (or
> default sink to be more precise) depending on the soundcards that are
> currently plugged in. Is this possible?
>
> In case it's not clear what I want, let me explain it on an example:
>
> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
> and my headset (sd3) and I want the default card to be the one with
> the highest numbering in the sdX naming scheme that is currently
> attached to the system.

Bascially you want a priority list of defaults and the current default
to the the highest priority available device to be the one used?

This is possible but no GUI exists on Gnome to exploit it just yet.

This is the routing policy used under KDE, and the PA module
module-device-manager implements this in PulseAudio.

Sadly my proposal to make PA's routing policy work in a (IMO) much more
sensible way, has not yet been endorsed by Lennart so I've not started
working on it. I'm pretty confident that even with some issues it
creates, it's a far more sensible configuration system than is currently
available.

The behaviour you describe would work perfectly under this setup, even
if the priority list itself is never actually exposed to the user via
confirguration GUIs.

Even the current module-default-device-restore does not actually work on
hotplug etc. (as the default is worked out at startup and then set, so
it's idea of the "default device" is lost).

Here is my proposal:
http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/


Hopefully when Lennart is less busy, we can revisit the discussions and
I can convince him I'm right!

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi,

thanks for your replies :-)

> Dnia 2010-06-11, pi± o godzinie 23:37 +0200, Geralt pisze:
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Eh? No idea what sdX mean here.
>
I was refering to either sd1, sd2 or sd3.

> If you want your audio to be heard over headset, then usb card, then
> onboard card, depending on which are available, just set them as
> fallbacks with pavucontrol or gnome-volume-control in the reverse
> direction (that's - connect your usb card, set it as fallback, then
> connect your headset and set that as fallback). That should be enough in
> at least with a recent enough PA.
>
That's exactly what I want and thanks for mentioning pavucontrol, I
didn't know of this application (I've basically zero experience with
Pulseaudio, yet).

> 'Twas brillig, and Geralt at 11/06/10 22:37 did gyre and gimble:
>> Hi everybody,
>>
>> I've got an onboard soundcard and two usb soundcards and I'd like it
>> if pulseaudio could switch automatically the default sound card (or
>> default sink to be more precise) depending on the soundcards that are
>> currently plugged in. Is this possible?
>>
>> In case it's not clear what I want, let me explain it on an example:
>>
>> I've got three soundcards: my onboard card (sd1), my usb card (sd2)
>> and my headset (sd3) and I want the default card to be the one with
>> the highest numbering in the sdX naming scheme that is currently
>> attached to the system.
>
> Bascially you want a priority list of defaults and the current default
> to the the highest priority available device to be the one used?
>
> This is possible but no GUI exists on Gnome to exploit it just yet.
>
> This is the routing policy used under KDE, and the PA module
> module-device-manager implements this in PulseAudio.
>
> Sadly my proposal to make PA's routing policy work in a (IMO) much more
> sensible way, has not yet been endorsed by Lennart so I've not started
> working on it. I'm pretty confident that even with some issues it
> creates, it's a far more sensible configuration system than is currently
> available.
>
> The behaviour you describe would work perfectly under this setup, even
> if the priority list itself is never actually exposed to the user via
> confirguration GUIs.
>
> Even the current module-default-device-restore does not actually work on
> hotplug etc. (as the default is worked out at startup and then set, so
> it's idea of the "default device" is lost).
>
> Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
>
> Hopefully when Lennart is less busy, we can revisit the discussions and
> I can convince him I'm right!
>
That is exactly what I want, however I don't use KDE, is there still a
way to use youre pulseaudio module?



Geralt
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > Here is my proposal:
> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/

In my humble opinion....

Device by media.role is not that great.. it stand up for events, but
it should really be be per client (application)

The major use cases i have right now that suck... and are not solvable
without prior knowledge of how pa works
1 - If I plug in my USB or Bluetooth headset the music does not
change to headset like my analogue headset does...
2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
not be set to use that mic without restarting skype?
3 - There no way to easily set the media role or an app that dosn't
have one (yes the all should have a role but they don't), pa could be
doing better here using desktop files and the role should be saved..
4 - Videos do not cork music

By default I think pa should:
- Move all inputs and outputs to any newly connected local device (ie
usb, bluetooth whatever) that appears after pa has started (unless the
per client device has been set of course)
- There should be a simple UI for setting a clients default media
role (if one has not been set), and this role should be remembered by
pa
- Streams should inherit media role from the client if they don't
have one set... ie firefox is set to video, so all its streams have a
media role of video
- A module to cork music when video is playing

Those 4 things would solve every problem I can think of and make pa
function as I think 90% desktop users expect

Cheers


--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Mon, 2010-06-14 at 09:59 +1200, Jason Taylor wrote:
> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video

No big issue with the rest of your proposals (besides the usual "who's
doing the work?" =p). However this one isn't a good idea, your web
browser plays tons of different things, alert sounds from web-apps,
videos (youtube and friends), audio from sites like pandora, game-sounds
from the various flash time-wasters. If this was classified as video, my
web-app giving me a new IM notification would cork my audio stream
(assuming your other proposals make it in)...

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > No big issue with the rest of your proposals (besides the usual "who's
> doing the work?" =p).

If it would be accepted I would attempt to brush off my rusty c skills..
I'm just not sure how welcome this work would be in pa...

> However this one isn't a good idea, your web
> browser plays tons of different things, alert sounds from web-apps,
> videos (youtube and friends), audio from sites like pandora, game-sounds
> from the various flash time-wasters. If this was classified as video, my
> web-app giving me a new IM notification would cork my audio stream
> (assuming your other proposals make it in)...

The "browser" classification as video was just a suggestion for such a
generic player, nothing else really fits IIMHO.., if the stream was
tagged with correct media.role, then pa would use that, the "video"
would be a fall back position. If you kept your browser with no media
role then nothing would happen as now.. which sucks when viewing a
youtube video and having to open the music player and stop it so you
can hear the video..

html5 tags like video/audio would really help here but thats probably
3 to 5 years away of having any significant role..

I just realized I missed one other use case... pa has no concept of
window order..
- With 2 streams of the same role (other then notification) are
active the stream that has the higher client in the window stack
should be the active stream, all other streams should be corked

Cheers

--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. >> No big issue with the rest of your proposals (besides the usual "who's
>> doing the work?" =p).
>
> If it would be accepted I would attempt to brush off my rusty c skills..
> I'm just not sure how welcome this work would be in pa...

I think its just like other open-source projects, ie. "patches
welcome". Lennart is quite harsh on the quality of said patches, but
once you've met that you're good to go I'd think. Your proposals cover
a whole lot of ground though, and would probably take quite a bit of
hacking.
>
>> However this one isn't a good idea, your web
>> browser plays tons of different things, alert sounds from web-apps,
>> videos (youtube and friends), audio from sites like pandora, game-sounds
>> from the various flash time-wasters. If this was classified as video, my
>> web-app giving me a new IM notification would cork my audio stream
>> (assuming your other proposals make it in)...
>
> The "browser" classification as video was just a suggestion for such a
> generic player, nothing else really fits IIMHO.., if the stream was
> tagged with correct media.role, then pa would use that, the "video"
> would be a fall back position. If you kept your browser with no media
> role then nothing would happen as now.. which sucks when viewing a
> youtube video and having to open the music player and stop it so you
> can hear the video..
>
> html5 tags like video/audio would really help here but thats probably
> 3 to 5 years away of having any significant role..
>
Well, for me its an 'unsolvable' problem which should probably be best
left alone. Flash on linux is problematic anyway, such that it may
make more sense just to download the video and watch it outside the
browser.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I think its just like other open-source projects, ie. "patches
> welcome". Lennart is quite harsh on the quality of said patches, but
> once you've met that you're good to go I'd think. Your proposals cover
> a whole lot of ground though, and would probably take quite a bit of
> hacking.

No problem, one bit at a time.. I'd at least want to know that it had
a chance of work being accepted though instead of .. thats not the
direction we want to go... ;)

I have my python hacks that work for me but it would be nice to get
this stuff in pa where it should be.

> Well, for me its an 'unsolvable' problem which should probably be best
> left alone. Flash on linux is problematic anyway, such that it may
> make more sense just to download the video and watch it outside the
> browser.

Probably its impossible to get this 100% right due to the ugly flash
issues, but 80% right would be nice start and anything to encourage
html5 and kill flash must be a "good thing" ... as long as it dosn't
screw up by default.

Cheers

--
"Weekends don't count unless you spend them doing something completely
pointless. " - Calven
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Jason Taylor at 13/06/10 22:59 did gyre and gimble:
>> Here is my proposal:
>> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>
> In my humble opinion....
>
> Device by media.role is not that great.. it stand up for events, but
> it should really be be per client (application)
>
> The major use cases i have right now that suck... and are not solvable
> without prior knowledge of how pa works
> 1 - If I plug in my USB or Bluetooth headset the music does not
> change to headset like my analogue headset does...

With your analogue headset "music" does not change to it, all output
changes to it. I know what you're hinting at, but the two cannot be
compared unless you just talk about "all output".

With my proposal, "music" could be configured to move to the new
USB/bluetooth headset.

> 2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
> not be set to use that mic without restarting skype?

Incorrect. When PA is used, Skype detects it and uses only it. It
(correctly) does not offer you the configuration choice inside Skype. It
is mostly up to tools like gnome-volume-control/pavucontrol etc. to
configure the Skype streams, but in the case of a USB or Bluetooth
headset, the PA module module-intended-roles kicks in and automatically
moves "voip" streams to "headset" devices. This currently works pretty
well (I don't have to do any configuration after setting up my bluetooth
headset for it to "just work" with Skype. It's quite nice, but not very
transparent. If you read the link I sent through, I believe I proposed
there (maybe it was afterwards on the list - can't quite recall) that
module-intended-roles becomes a passive module that simply injects brand
new (never seen before) devices into the appropriate place in the
priority list for the appropriate role. That way it's more transparent
to the user and the net functionality remains the same.

> 3 - There no way to easily set the media role or an app that dosn't
> have one (yes the all should have a role but they don't), pa could be
> doing better here using desktop files and the role should be saved..

PA *does* use .desktop files. That's what module-augment-properties does...

> 4 - Videos do not cork music

No they don't. Currently the automatic corking is implemented by
module-cork-music-on-phone. This could be made more generic with some
kind of simple "rules" file that could be parsed at startup to allow
"video corks music". That would be kinda sensible IMO.


> By default I think pa should:
> - Move all inputs and outputs to any newly connected local device (ie
> usb, bluetooth whatever) that appears after pa has started (unless the
> per client device has been set of course)

Perhaps, but I don't think everyone would agree here. I certainly would
not be appropriate for my crappy bluetooth headset here. It's acceptable
for phone streams, but really not for anything else.

> - There should be a simple UI for setting a clients default media
> role (if one has not been set), and this role should be remembered by
> pa

This could be done, but I'd personally rather not do it. An alternative
would be an independent "database" (like pci.ids or usb.ids) that could
"know" which apps are which roles, that we can update via the web and
bundle when we release, but I think letting users do this removes from
the simplicity that should underlie this system. If the user cares that
much, they can either edit the .desktop file or create a wrapper
script/alias that sets the relevant env vars to allow for role to be forced.

> - Streams should inherit media role from the client if they don't
> have one set... ie firefox is set to video, so all its streams have a
> media role of video

Not quite sure how easy this would be, but in theory if the client has a
proplist, it should be easy to make any streams that client creates
inherit that (I'd have to check to see if this is not done already!)

> - A module to cork music when video is playing

Should be trivial to do (although depending on the options and
combinations here it may be better to parse some simple rules (or just
rename module-cork-on-phone and call it module-auto-cork or something
and implement this extra rule (tho' I guess separate modules give users
more control).

> Those 4 things would solve every problem I can think of and make pa
> function as I think 90% desktop users expect

I think most points are valid. With the exception of the first one, the
others are not technically that much related to routing (the role points
are related if you assume most routing is role-based (at least
initially)) and as such are probably orthoganal to the routing overhaul
I suggest.

Certainly worth keeping in mind tho'.

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Yves (theYinYeti) at 14/06/10 08:48 did gyre and gimble:
> Le 14/06/2010 01:59, Jason Taylor a écrit :
>> I just realized I missed one other use case... pa has no concept of
>> window order..
>> - With 2 streams of the same role (other then notification) are
>> active the stream that has the higher client in the window stack
>> should be the active stream, all other streams should be corked
>
> I'm not absolutely sure of what "corked" means, but it seems to mean
> "paused".
> If so, I don't agree. Here's an example where I don't want anything to
> happen to current sound when another sound of the same nature begins:
>
> My son watches a cartoon on TV, the picture of which comes from the
> S-Video output of the PC (display :1 ); the sound is directed at the TV
> as well using sound card #2.
> Meanwhile, on the computer's screen (display :0 ), I watch a conference,
> the sound of which goes to the screen's integrated speakers through
> sound card #1.
>
> This setup is quite common with me. Even more often (but then roles are
> different I guess), the HiFi plays Deezer (good music) while the
> integrated speakers let me hear both the orator of the lengthy
> conference I'm attending, and the events' sounds of the little game I
> have alongside, for moments in the conference when there's nothing
> interesting being said.
>
> I definitely don't want any sound to ever be paused or stopped
> automatically. But then, maybe I'm not part of the normal users...

I think you're probably right about being "not part of the normal
users", but that's not to say the problem isn't solvable.

For example, each stream has the following property:
window.x11.display = ":0.0"

It would be theoretically possible to make the cork rules only affect
streams that are on the same display as the one that triggers them. e.g.
a video on display :1 would not affect music on display :0 or similar.

It obviously makes things more complicated, but it's theoretically
possible if someone puts in the work!


Col

--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. [I think this was meant for the list so moving it back there]

'Twas brillig, and Jason Taylor at 15/06/10 02:37 did gyre and gimble:
>>> The major use cases i have right now that suck... and are not solvable
>>> without prior knowledge of how pa works
>>> 1 - If I plug in my USB or Bluetooth headset the music does not
>>> change to headset like my analogue headset does...
>>
>> With your analogue headset "music" does not change to it, all output
>> changes to it. I know what you're hinting at, but the two cannot be
>> compared unless you just talk about "all output".
>
> Yes by "default" I think pa should push "all output" to newly
> registered local devices...
> This is what users expect, as long as its easy to turn off advanced
> users wont have an issue

I really don't think this is wise. There are so many cases where this
doesn't work. If you are in the process of plugging something in, you
*expect* to have to take some action. You're in the mind set that you'll
need to take action to make the device work.

I'm not saying that your suggestion is bad. I've no doubt some users
would like it, but the fact remains that whenever a network device
appears on my network or a bluetooth hifi in the living room appears as
available, I most certainly do not want all my sound moved across to it.

This is the reason why module-intended-roles is contextual. It deals
with the cases where it *is* sensible to do things automatically and
even then it's does them piecemeal, not wholesale.

> advanced meaning anyone who understands the pulseaudio volume control ....

And novice users wont have a clue why their sound just disappeared.
There is always a flip-side.

>>> With my proposal, "music" could be configured to move to the new
>> USB/bluetooth headset.
>>
>>> 2 - If I plug in a USB or Bluetooth microphone apps like *skype* can
>>> not be set to use that mic without restarting skype?
>>
>> Incorrect. When PA is used, Skype detects it and uses only it. It
>> (correctly) does not offer you the configuration choice inside Skype. It
>> is mostly up to tools like gnome-volume-control/pavucontrol etc. to
>> configure the Skype streams, but in the case of a USB or Bluetooth
>> headset, the PA module module-intended-roles kicks in and automatically
>> moves "voip" streams to "headset" devices. This currently works pretty
>> well (I don't have to do any configuration after setting up my bluetooth
>> headset for it to "just work" with Skype. It's quite nice, but not very
>> transparent. If you read the link I sent through, I believe I proposed
>> there (maybe it was afterwards on the list - can't quite recall) that
>> module-intended-roles becomes a passive module that simply injects brand
>> new (never seen before) devices into the appropriate place in the
>> priority list for the appropriate role. That way it's more transparent
>> to the user and the net functionality remains the same.
>
> I've just retired this on ubuntu luicd with skype 2.1.0.81 (confirmed
> the module-intended-roles is loaded)
> - unplugged headset
> - started a call
> - plugged in headset
> - no sound
> - no mic input to skype..
> and the current playing sound was not pushed to the headset.. although
> event sounds from skype seem to have done the right thing.
>
> Perhaps my headset is not detected as a headset? Ethier way it dosnt
> work and as you say pulse should be handling this. I can get it to go
> clicking the right buttons (and restarting skype), my parents or
> sister (who both have linux netbooks) can not...

If you set up anything manually using pavucontrol, this overrides
module-intended-roles, so if you've ever moved any skype stream to a new
device (even if you move it back again) then m-i-r will not work for
you. It's meant to deal with defaults only.

pacmd list (or list-sinks for less output) will tell you if your headset
is detected as a headset.

There was also a bug recently in m-i-r that managed to move skype input
(i.e. it's recording) to the monitor of the output which created a nice
echo for the other party.... I've fixed this, and I believe that Ubuntu
has this fix, but not 100% sure.


>>> By default I think pa should:
>>> - Move all inputs and outputs to any newly connected local device (ie
>>> usb, bluetooth whatever) that appears after pa has started (unless the
>>> per client device has been set of course)
>>
>> Perhaps, but I don't think everyone would agree here. I certainly would
>> not be appropriate for my crappy bluetooth headset here. It's acceptable
>> for phone streams, but really not for anything else.
>
> I'm not arguing it should not be configurable only default behavior

No argument there. I think an option is fine, but I disagree with your
default. It's also debatable whether an option is worth it considering
how many "new" devices a user has in the lifetime of their PC. Maybe a
dozen? Is moving the preference around that difficult under those
circumstances?

>>> - There should be a simple UI for setting a clients default media
>>> role (if one has not been set), and this role should be remembered by
>>> pa
>>
>> This could be done, but I'd personally rather not do it. An alternative
>> would be an independent "database" (like pci.ids or usb.ids) that could
>> "know" which apps are which roles, that we can update via the web and
>> bundle when we release, but I think letting users do this removes from
>> the simplicity that should underlie this system. If the user cares that
>> much, they can either edit the .desktop file or create a wrapper
>> script/alias that sets the relevant env vars to allow for role to be forced.
>
> Agree all apps should have a media role set by default, but asking a
> "human" to edit a file or a script to change media roles is insane...
> all this requires is a dropbox in the UI of the sound control...

I very strongly disagree here. Cluttering up the UI is very much
something we should avoid, especially as the only reason to do so is a
deficiency in metadata that should be sourced from elsewhere.

Like I say, spruce up module-augment-properties with a built in database
of apps->roles mappings will catch 90% of the relevant problem cases and
something that novice users don't have a clue about can be kept away
from causing them confusion in their GUIs. It's also non-trivial to
implement, remembering the client-server model of PA means that the
protocol has to be extended, message formats defined, storage databases
kept; then you have to deal with apps that didn't set their role before,
but now do, if that role is different to what the user picked then who
do you listen to etc. etc.

If power users want to override things, then there are already
mechanisms for that.

So I really do not like this idea. There are far more user friendly ways
to solve the problem of missing metadata.

>>> - Streams should inherit media role from the client if they don't
>>> have one set... ie firefox is set to video, so all its streams have a
>>> media role of video
>>
>> Not quite sure how easy this would be, but in theory if the client has a
>> proplist, it should be easy to make any streams that client creates
>> inherit that (I'd have to check to see if this is not done already!)
>
> If it is done then all thats probably required is saving the change..

As said above, saving the change is non-trivial and I really do not
recommend this approach. And if the client sets it, why would it *need*
to be saved anyway? When the client connects again, it will presumably
set it's role again and then it's streams can inherit it again.

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > I really don't think this is wise. There are so many cases where this
> doesn't work. If you are in the process of plugging something in, you
> *expect* to have to take some action. You're in the mind set that you'll
> need to take action to make the device work.

Can't disagree strongly enough here.

When you plug headphones into your laptop, the sound switches from the
speakers to the headphones. No intervention. This should definitely be
the same case with plugging in USB headphones.

To get it right, pulseaudio's going to need some logic here, to make
sure the "fallback" is reasonable, even in the light of plug/unplug
events.

--
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Jeremy Nickurak at 15/06/10 16:31 did gyre and gimble:
>> I really don't think this is wise. There are so many cases where this
>> doesn't work. If you are in the process of plugging something in, you
>> *expect* to have to take some action. You're in the mind set that you'll
>> need to take action to make the device work.
>
> Can't disagree strongly enough here.
>
> When you plug headphones into your laptop, the sound switches from the
> speakers to the headphones. No intervention. This should definitely be
> the same case with plugging in USB headphones.

But speaker jacks are completely different to USB sound devices. You
cannot use them as a comparable example here.

I mean, if I've got some USB speakers which have a jack socket on the
front of them (I'm looking at just such devices right now in front of
me) and I plug in some headphones to the jack socket on my computer, I
do not expect the sound to be moved across from playing on the USB
device to my internal device and subsequently on my headphones when this
happens.

Added to this, there are numerous examples of when I really don't want,
nor would expect this to happen. e.g. I'm playing music and I get my USB
headset to make a VoIP call. My music playing happily on my USB Speakers
and I want it stay there, but as soon as I plug in my headset it
transfers. I'd much rather it stayed where it was. I may want to leave
my USB Headset plugged in (I often do).

I don't think I'm out of the ordinary here. And there are countless
other scenarios where this just doesn't work OOTB.

The general rule is if you can't do something automatically that works
every time, then don't do it automatically at all, but make it easy and
obvious to the user how to do it manually.

Col





--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Nathan Kidd at 15/06/10 17:18 did gyre and gimble:
> I think the ability to say "this is my preferred sound device" would be
> ideal. So if that device gets plugged in it automatically becomes the
> output.
>
> You don't make your headset the preferred device, and you're happy. For
> me, I really want my good-sounding USB speakers to automatically work
> when I plug them into my (crappy-speakers-) laptop. The
> portability/sound quality tug-of-war causes me to be constantly fiddling
> with sound preferences.

What you want here is definitely something that will be supported.

That's not the debate. The discussion is about what should happen by
*default* the very first time a device is plugged in.

I maintain that the new device should not change your setup and that,
except in some special cases (like VoIP calls for Headset devices) the
new device should be injected in at the bottom of the priority list of
devices, not at the top.

Col

--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On 10-06-15 12:38 PM, Colin Guthrie wrote:
> 'Twas brillig, and Nathan Kidd at 15/06/10 17:18 did gyre and gimble:
>> I think the ability to say "this is my preferred sound device" would be
>> ideal. So if that device gets plugged in it automatically becomes the
>> output.
>>
>> You don't make your headset the preferred device, and you're happy. For
>> me, I really want my good-sounding USB speakers to automatically work
>> when I plug them into my (crappy-speakers-) laptop. The
>> portability/sound quality tug-of-war causes me to be constantly fiddling
>> with sound preferences.
>
> What you want here is definitely something that will be supported.
>
> That's not the debate. The discussion is about what should happen by
> *default* the very first time a device is plugged in.

Mea culpa for not reading the whole thread first.

-Nathan
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > Added to this, there are numerous examples of when I really don't want,
> nor would expect this to happen. e.g. I'm playing music and I get my USB
> headset to make a VoIP call. My music playing happily on my USB Speakers
> and I want it stay there, but as soon as I plug in my headset it
> transfers. I'd much rather it stayed where it was. I may want to leave
> my USB Headset plugged in (I often do).

Okay, then the headset should be configured somehow to never become
the fallback. Maybe that's automatic based on profile information....
but it should probably be overridable. Let the user say what devices
are potential fall-back devices, and probably allow an ordering for
them.

OTOH, if I've got my nice new A2DP bluetooth headset, and I associate
it with my laptop, I probably immediately want all the "fallback"
music taken off the crummy tinny speakers onto my headset, without
intervention. Likewise for my home theatre system if I plug in there.

> I don't think I'm out of the ordinary here. And there are countless
> other scenarios where this just doesn't work OOTB.
>
> The general rule is if you can't do something automatically that works
> every time, then don't do it automatically at all, but make it easy and
> obvious to the user how to do it manually.

That's a great philosophy... but it applies mostly to hard-coding
things. We don't want the user to have to open up a control panel and
reconfigure things every time they plug/unplug a device, right?
Consider the case of docking stations, where any time the user sits
down at their desk, they want the sound redirected to the desktop.
(Although there's a case here to be careful about... we don't want to
take the output to speakers if they're currently blasting high-volume
heavy metal on headphones....)

--
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.