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
