[pulseaudio-discuss] PulseAudio, switch audio output on device connection

[Mark Gaiser]

On Sun, Oct 19, 2014 at 12:01 PM, Tanu Kaskinen
<tanu.kaskinen at linux.intel.com> wrote:
> On Thu, 2014-10-09 at 00:39 +0200, Mark Gaiser wrote:
>> On Wed, Oct 8, 2014 at 1:06 PM, Tanu Kaskinen
>> <tanu.kaskinen at linux.intel.com> wrote:
>> > On Mon, 2014-10-06 at 19:47 +0200, Mark Gaiser wrote:
>> >> Ok, i tried a bunch of different players. The results:
>> >> - mplayer (smplayer as well) : sound doesn't switch when attaching
>> a headphone
>> >> - rhythmbox : refused to play any plain simple mp3 file
>> >> - amarok : sound doesn't switch when attaching a headphone
>> >> - dragon player : sound doesn't switch when attaching a headphone
>> >> ...
>> >>
>> >> I did get rhythmbox to beep once and that one came out of my
>> headset.
>> >> Based on that i'm beginning to think that there is some GTK vs Qt
>> >> difference in play here.
>> >>
>> >> One thing i did found (in the kde settings) was that i can prefer
>> my
>> >> headphone to be first in sound order. Funny thing is, this is
>> actually
>> >> working for an application like amarok which then behaves as i
>> expect.
>> >> However, other apps don't seem that happy to comply and just spew
>> out
>> >> audio to my jack port.
>> >
>> > There shouldn't be that kind of differences between apps, unless you
>> > have previously moved manually those applications around. What if
>> you
>> > clear the pulseaudio state by doing this:
>> >
>> > - disable autospawning (so that you can be sure pulseaudio isn't
>> running
>> > during the next steps):
>> >     cat "autospawn = no" >> ~/.config/pulse/client.conf
>> >
>> > - killall pulseaudio
>> >
>> > - remove all files under ~/.config/pulse except client.conf
>> >
>> > - restart pulseaudio:
>> >     pulseaudio -D
>> >
>> > - load module-switch-on-connect:
>> >     pactl load-module module-switch-on-connect
>> >
>> > Is there still a difference in behaviour between amarok and other
>> > applications?
>> >
>> > Since you use kde, the routing may be a bit different than on my
>> > machine, if you have module-device-manager loaded, and that might
>> > explain the general problem of the automatic routing not working as
>> > expected. When you start your kde session, module-device-manager
>> gets
>> > loaded. On gnome, for example, that module is not loaded by default.
>> > Just restarting pulseaudio while the session is running should get
>> rid
>> > of module-device-manager, because it's only loaded when the session
>> > starts, but you can of course always unload it with "pactl
>> unload-module
>> > module-device-manager". You can verify that the module is not loaded
>> by
>> > running "pactl list modules short". If module-device-manager isn't
>> > listed, then it isn't loaded.
>> >
>> >> Could you perhaps test if you can get the same thing working under
>> mplayer?
>> >> mplayer -ao pulse <some_mp3_file>
>> >>
>> >> That is a quite simple test - easy to reproduce - and doesn't give
>> me
>> >> the expected result. I wonder how that works with you.
>> >
>> > Works fine.
>> >
>> > --
>> > Tanu
>> >
>>
>> And reporting back with my findings.
>>
>> First i verified if the module "module-device-manager" would be
>> loaded. It's not so that's probably not an issue.
>> Then i followed your steps and it - amazingly - worked! However, with
>> a issue.
>>
>> If i play a sound file (using mplayer as a test case) it:
>> - plays from my speakers by default (OK!)
>> - If i attach my (usb) headset the sound moves to the headset. Happy
>> me :)
>> - If i detach my usb headset again the sound isn't being played
>> anywhere anymore. Attaching/detaching many more times doesn't help
>> either.
>>
>> I also think i know why it happens, just not a solution to the issue.
>> If i type "pactl list short sinks" i get this output when my headset
>> is not attached:
>>
>> 0       alsa_output.pci-0000_01_00.1.hdmi-stereo
>>  module-alsa-card.c      s16le 2ch 44100Hz       SUSPENDED
>> 1       alsa_output.pci-0000_00_1b.0.analog-stereo
>>  module-alsa-card.c      s16le 2ch 44100Hz       SUSPENDED
>>
>> When i play a file the list changes:
>>
>> 0       alsa_output.pci-0000_01_00.1.hdmi-stereo
>>  module-alsa-card.c      s16le 2ch 44100Hz       SUSPENDED
>> 1       alsa_output.pci-0000_00_1b.0.analog-stereo
>>  module-alsa-card.c      s16le 2ch 44100Hz       RUNNING
>>
>> So far so good. I have no HDMI devices attached that can play sound (a
>> projector is attached. It can beam video, not audio :)
>>
>> When attaching the headset i get:
>> 0       alsa_output.pci-0000_01_00.1.hdmi-stereo
>>  module-alsa-card.c      s16le 2ch 44100Hz       SUSPENDED
>> 1       alsa_output.pci-0000_00_1b.0.analog-stereo
>>  module-alsa-card.c      s16le 2ch 44100Hz       IDLE
>> 7
>> alsa_output.usb-Corsair_Components__Inc._Corsair_Vengeance_1500-00-C1500.analog-stereo  module-alsa-card.c      s16le 2ch 44100Hz       RUNNING
>>
>> Note the added usb headset and it is running now. All perfectly fine
>> thus far.
>> But when i detach my headset the list becomes wrong:
>>
>> 0       alsa_output.pci-0000_01_00.1.hdmi-stereo
>>  module-alsa-card.c      s16le 2ch 44100Hz       RUNNING
>> 1       alsa_output.pci-0000_00_1b.0.analog-stereo
>>  module-alsa-card.c      s16le 2ch 44100Hz       SUSPENDED
>>
>> Note the hdmi sink is now suddenly playing the sound!
>> I would expect the sink to continue device that was sitting idle, but
>> somehow it picked the other device.
>> Did i actually find a bug just now or is this also some magic setting
>> that i can change somewhere?
>
> It's a bug (or an unimplemented feature, depending on your point of
> view). I didn't try to reproduce this, but I speculate that this
> happens, because at the time when module-rescue-streams notices that the
> headset is going away, it would like to move the stream to the default
> sink, but at that time the default sink is still the headset, so instead
> of the default sink, module-rescue-streams uses some other heuristics
> for choosing the sink where it moves the stream. When the headset
> finally disappears, the analog sink becomes the new default, based on
> different heuristics than what module-rescue-streams used.
>
> When you re-attach the usb headset, the move doesn't happen, because the
> stream is not connected to the default sink, and
> module-switch-on-connect only moves streams that are connected to the
> default sink.
>
> While better automatic routing is very much in my interests, it's not
> the highest priority right now, so I don't know when this will be fixed.
> There was some talk last week about improving module-device-manager and
> then enabling it by default. If someone is going to work on that, it
> will quite likely fix this issue.
>
> As a workaround, you can set the HDMI card profile to "off".

Hi Tanu,

Thank you very much for the detailed description. To me it sounds like
module-rescue-streams might have a bug then. Also,
module-rescue-streams apparently moves the stream to my hdmi, but
shouldn't that become the default then? I mean, that would make
module-switch-on-connect work again on re-attaching cases.

Or another way; Shouldn't module-rescue-streams only be invoked when a
device actually disappeared? I mean, that would probably fix the
stream moving back to the default stream and would also fix the
re-attach case, right?

I'm just guessing :)
For now, I just keep using the workaround.

Thank you very much for your detailed reply's. I really appreciate it.
Mark