[pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards

Tue Jun 15 00:40:46 PDT 2010

[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/]