[PATCH] Automatically switch to new devices

[mterry]

I was thinking it would be nice to automatically switch to a new device if the user connected one. My primary use case was connecting new Bluetooth devices.

When you plug in new (jack) headphones, those automatically switch. So Bluetooth seemed like it should work the same way. I suppose the same holds true for HDMI (or whatever devices provide sinks/sources).

Attached is my naive attempt at doing so. It provides a new module switch-on-connect. When a new source or sink is made available (during the session, not during startup), it makes it the new default and switches outputs/inputs from the previous default to the new one. I'd welcome feedback on the approach or implementation.

[coling]

Awesome. Thanks for your work :)

This may in some way crossover with module-device-manager which I recently committed to git master.

m-d-m will maintain a priority list of devices (per role) that allow you to specify your priority. This is currently hooked up to the KDE multimedia settings via a series of patches I've written for phonon and kdebase-runtime. There is currently no GUI in gnome and the module is only loaded under KDE at present.

It would be fairly easily to default the new device to the highest priority (currently the opposite is true).

IMO we really need a bit more joined up thinking on how to implement the routing policy as I'm not 100% happy about some of the ways module-device-manager works and how it should work under KDE. That said, the choice of routing policy could be aided by module-loader which will contain some smarts on top of the rather dumb paprefs options so we can expose these options to users (and automatically load the relevant modules internally).

Anyway, I've not looked at the code, but thought I'd make you aware of this other work and perhaps some more discussion can result. There is no real conflict between this work and mine, but the order in which the module is loaded and the hooks are triggered may need tweaking (i've not looked!)

[lennart]

I guess the idea in general does make sense: if a user plugs in a new device this could indeed be seen as an indication that he actually wants to use it... ;-)

Some comments on the patch:

I don't see why this module should hook into PA_CORE_HOOK_SINK_INPUT_MOVE_FAIL.

Also, this module should make sure not to touch streams/device that have the 'intended roles' property set. Handling of that should be left to module-intended-roles. Also, if the "save_device" flag is set for a stream it should be left alone, since that is a sign that the user manually moved the stream to the device, and we shouldn't fiddle with that.

Hmm, the find_evacuation_sink() call doesn't make too much sense here, does it? I mean, that looks a bit too much like a 1:1 copy from m-rescue-streams. But that module looks into devices that go away and then searches for a replacement sink fo the stream, this module here looks into sinks being added, and they themselves should be the destination where to move streams to.

[mterry]

Well, you're right in the sense that the module was almost a direct copy of rescue-streams, and that's where most of any oddities will appear.

Re: PA_CORE_HOOK_SINK_INPUT_MOVE_FAIL, you are right. They were part of the copy and I thought on first look that they were related to finishing up a move started by us if it failed. But I see they were in rescue-streams for generically handling move failures, and aren't something we want here.

Good info about intended roles and save_device.

Also fair point about find_evacuation_sink. We know the destination already, we don't have to search for it.

Will adjust patch.

[mterry]

When testing my latest patch, I noticed that due to the new intended-roles logic (i.e. we don't switch to or from devices with intended roles), it doesn't work for the bluetooth headset I tested. That is, the bluetooth headset had a role, but I still wanted it to switch to it automatically.

Is there more clever logic we could use? Or should we ignore intended roles for this purpose?

[mterry]

I just updated a more recent version of the patch (against 0.9.22). This one drops the intended-roles logic, as it didn't work right (BT devices had roles set, as I commented above). It also adds logic to not switch to ISA or PCI devices in case they show up for some reason after the module loads.

[coling]

Hi there,

On first glance the module looks fine. It may ultimately go through some changes once I've finished some other work but as I've been particularly tardy about that I see no reason to wait for that before this goes in!

Couple points re the patch itself:

1. It's (c) Canonical. Do you work for them or have you just copied it from elsewhere and forgot to update it?
2. If you want to retain authorship can you post your full name and email address (for the git commit feel free to obfuscate email address here but it'll go into the git history so will likely be listed on the web somewhere). If prefer to remain anonymous, that's fine too :)

Cheers

[mterry]

Oh, please, change it all you like. This version of the patch is something that works for me, but I'm not usually a pulseaudio developer and may not have anticipated certain issues. Thanks for looking at it! I think it is very useful.

I do work for Canonical, and the (c) Canonical is right, as this was for work. My authorship info is "Michael Terry <michael.terry@…>".

[mterry]

Uh, that was at canonical.com. Trac tried to help me out there.

[mgedmin]

Two questions:

* If a new network sink appears, will this module switch to it? That would be undesirable. (Use case: I'm listening to music on my laptop via headphones when someone reboots the shared office jukebox machine.)

* If I switch an audio stream to a different device (say, the above-mentioned network sink), and then I switch it back to my laptop's current default device (internal audio) -- will that keep the save_device flag set and prevent it from moving to a USB headset? That would be inconvenient.

[kiddo]

Anything holding that patch back (except the time to merge it)?

[coling]

There is nothing particularly preventing it per-se, but the module itself will ultimately disappear eventually.

I think what I'll do is include it in git master but not add it to default.pa. I'll then adjust paprefs to allow this module to be loaded or not depending on user choice.

That way, people can easily enable the option and eventually I can ditch it when the routing in the core allows such behaviour natively. That seems like a suitable stop-gap approach.

[coling]

Hello!

I totally forgot to update this ticket, but this module was committed to git master some time ago!  http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=6ed3a7dcc9de81469c5d35a5256e5f50bd48f804

Sorry for forgetting to update this ticket!

As I said in the above comment, I suspect this module will eventually die when replaced by more advanced routing options, but until then I think it's a good stop gap to get the functionality desired.