Bug 89934

One thing I noticed is that the module-switch-on-connect is not loaded even if it is present on the system

paolo@murdock ~/dcv $ lsof -p 1947 | grep switch
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/42/gvfs
      Output information may be incomplete.
pulseaudi 1947 paolo  mem       REG               8,18     15112 1854808 /usr/lib64/pulse-6.0/modules/module-switch-on-port-available.so

Being present on the system isn't enough for a module to get loaded. module-switch-on-connect is not loaded by default. Maybe you had the module enabled in /etc/pulse/default.pa before the upgrade, and the upgrade overwrote that file?

(In reply to Tanu Kaskinen from comment #2)
> Being present on the system isn't enough for a module to get loaded.
> module-switch-on-connect is not loaded by default. Maybe you had the module
> enabled in /etc/pulse/default.pa before the upgrade, and the upgrade
> overwrote that file?

Could be, but for sure I did not change it manually in the past...

Any reason why that is not part of the default?


Anyway I'll try and see if that fixes the problem

(In reply to Paolo Borelli from comment #3)
> Any reason why that is not part of the default?

I think the reason is that there are important use cases where it's not appropriate to switch to a new device when it appears. I don't remember what those use cases are more specifically.

(In reply to Tanu Kaskinen from comment #4)
> I think the reason is that there are important use cases where it's not
> appropriate to switch to a new device when it appears. I don't remember what
> those use cases are more specifically.

Well, pluggin in a usb headset and expecting it to work seems an important use case and something that used to work without fiddling with etc files...

On my f22 box, /etc/pulse/default.pa contains:

### Should be after module-*-restore but before module-*-detect
load-module module-switch-on-port-available

module-switch-on-port-available is different from module-switch-on-connect. module-switch-on-port-available doesn't move streams between devices, it only controls which port is active on a sink or source that has multiple ports.

> 
> Well, pluggin in a usb headset and expecting it to work seems an important
> use case and something that used to work without fiddling with etc files...


you are assume that notebook has only one usb port , but most desktops have more than one usb port which allow  usb webcam and usb headset plugged at the same time

To do this properly, pulseaudio should fingerprint each audio device and remember if a user switched to it in the past. Since many devices are hotplug devices (including HDMI monitors), this is more important than it used to be.

Chrome OS had to recently implement this. Previously they had a stateless heuristic for choosing a device, but had to add persistence because of unpredictability of hotplug ordering and other issues.

http://crbug.com/308143 for reference.

Oh, it looks like module-default-device-restore is supposed to do this, with fingerprinting even. Sorry for not seeing this.

I guess that module is not working then?

module-default-device-restore is broken indeed. I hope it will be fixed in the upcoming release.

*** Bug 90870 has been marked as a duplicate of this bug. ***

I submitted a patch for fixing module-default-device-restore:
https://patchwork.freedesktop.org/patch/164480/

The module-default-device-restore patch is now in master. PulseAudio 11.0 should remember your choice if you set a USB device as the default.

Additionally, another patch has been applied earlier that makes USB device priority higher than built-in sound cards, so often you don't need any manual steps if you prefer to use a USB device.

I'll close this bug now.