<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 28, 2014 at 9:08 AM, Tanu Kaskinen <span dir="ltr"><<a href="mailto:tanu.kaskinen@linux.intel.com" target="_blank">tanu.kaskinen@linux.intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Mon, 2014-10-27 at 18:52 +0100, Mark Gaiser wrote:<br>
> On Sun, Oct 26, 2014 at 6:18 PM, Tanu Kaskinen<br>
> <<a href="mailto:tanu.kaskinen@linux.intel.com">tanu.kaskinen@linux.intel.com</a>> wrote:<br>
> > On Sun, 2014-10-19 at 13:20 +0200, Mark Gaiser wrote:<br>
> >> On Sun, Oct 19, 2014 at 12:01 PM, Tanu Kaskinen<br>
> >> <<a href="mailto:tanu.kaskinen@linux.intel.com">tanu.kaskinen@linux.intel.com</a>> wrote:<br>
> >> > On Thu, 2014-10-09 at 00:39 +0200, Mark Gaiser wrote:<br>
> >> >> Note the hdmi sink is now suddenly playing the sound!<br>
> >> >> I would expect the sink to continue device that was sitting idle, but<br>
> >> >> somehow it picked the other device.<br>
> >> >> Did i actually find a bug just now or is this also some magic setting<br>
> >> >> that i can change somewhere?<br>
> >> ><br>
> >> > It's a bug (or an unimplemented feature, depending on your point of<br>
> >> > view). I didn't try to reproduce this, but I speculate that this<br>
> >> > happens, because at the time when module-rescue-streams notices that the<br>
> >> > headset is going away, it would like to move the stream to the default<br>
> >> > sink, but at that time the default sink is still the headset, so instead<br>
> >> > of the default sink, module-rescue-streams uses some other heuristics<br>
> >> > for choosing the sink where it moves the stream. When the headset<br>
> >> > finally disappears, the analog sink becomes the new default, based on<br>
> >> > different heuristics than what module-rescue-streams used.<br>
> >> ><br>
> >> > When you re-attach the usb headset, the move doesn't happen, because the<br>
> >> > stream is not connected to the default sink, and<br>
> >> > module-switch-on-connect only moves streams that are connected to the<br>
> >> > default sink.<br>
> >> ><br>
> >> > While better automatic routing is very much in my interests, it's not<br>
> >> > the highest priority right now, so I don't know when this will be fixed.<br>
> >> > There was some talk last week about improving module-device-manager and<br>
> >> > then enabling it by default. If someone is going to work on that, it<br>
> >> > will quite likely fix this issue.<br>
> >> ><br>
> >> > As a workaround, you can set the HDMI card profile to "off".<br>
> >><br>
> >> Hi Tanu,<br>
> >><br>
> >> Thank you very much for the detailed description. To me it sounds like<br>
> >> module-rescue-streams might have a bug then. Also,<br>
> >> module-rescue-streams apparently moves the stream to my hdmi, but<br>
> >> shouldn't that become the default then? I mean, that would make<br>
> >> module-switch-on-connect work again on re-attaching cases.<br>
> ><br>
> > I think we should refactor things so that module-rescue-streams would<br>
> > use the same code for figuring out the target sink as what is used when<br>
> > the new default sink is decided. I created a formal bug report:<br>
> > <a href="https://bugs.freedesktop.org/show_bug.cgi?id=85488" rel="noreferrer" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=85488</a><br>
><br>
> Thank you very much for that.<br>
<br>
</div></div>You're welcome. Unfortunately, I don't expect anything to happen with<br>
that any time soon unless someone else steps up to fix it.<br>
<span class=""><br>
> >> Or another way; Shouldn't module-rescue-streams only be invoked when a<br>
> >> device actually disappeared? I mean, that would probably fix the<br>
> >> stream moving back to the default stream and would also fix the<br>
> >> re-attach case, right?<br>
> ><br>
> > When the device actually disappears, streams connected to it get killed.<br>
> > That's why module-rescue-streams has to act before the device actually<br>
> > disappears.<br>
><br>
> Oke, sounds sane to me. But there must be some code somewhere in<br>
> pulseaudio that lets a stream kill gracefully, right?<br>
<br>
</span>Yes, but "kill gracefully" still means killing the stream. Moving it in<br>
the kill handler is not a good idea.<br>
<br>
Your underlying idea seems to be that we should reorder things so that<br>
first the device is destroyed, leaving the streams "hanging in the air".<br>
Then the default device should change. Only then the rescue operation<br>
should be carried out, or if nobody rescues the streams, then the<br>
streams should be killed. That sounds like good approach, but I believe<br>
that would also take a fair bit of work to implement.<br>
<span class=""><font color="#888888"><br>
--<br>
Tanu<br>
<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Hi,</div><div class="gmail_extra"><br></div><div class="gmail_extra">a _very_ late reply!</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thank you - the pulseaudio team - for looking at this issue.</div><div class="gmail_extra">I've just installed PulseAudio 8.0 and was at first slightly disappointed that it didn't seem to be fixed as advertised.</div><div class="gmail_extra">But it turns out that the KDE specific module for phonon "module-device-manager" was breaking things, disabling that module made it all work wonderfully well!</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thank you again for looking at this!</div></div>