On Tue, Oct 28, 2014 at 9:08 AM, Tanu Kaskinen < tanu.kaskinen at linux.intel.com> wrote: > On Mon, 2014-10-27 at 18:52 +0100, Mark Gaiser wrote: > > On Sun, Oct 26, 2014 at 6:18 PM, Tanu Kaskinen > > <tanu.kaskinen at linux.intel.com> wrote: > > > On Sun, 2014-10-19 at 13:20 +0200, Mark Gaiser wrote: > > >> 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: > > >> >> 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. > > > > > > I think we should refactor things so that module-rescue-streams would > > > use the same code for figuring out the target sink as what is used when > > > the new default sink is decided. I created a formal bug report: > > > https://bugs.freedesktop.org/show_bug.cgi?id=85488 > > > > Thank you very much for that. > > You're welcome. Unfortunately, I don't expect anything to happen with > that any time soon unless someone else steps up to fix it. > > > >> 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? > > > > > > When the device actually disappears, streams connected to it get > killed. > > > That's why module-rescue-streams has to act before the device actually > > > disappears. > > > > Oke, sounds sane to me. But there must be some code somewhere in > > pulseaudio that lets a stream kill gracefully, right? > > Yes, but "kill gracefully" still means killing the stream. Moving it in > the kill handler is not a good idea. > > Your underlying idea seems to be that we should reorder things so that > first the device is destroyed, leaving the streams "hanging in the air". > Then the default device should change. Only then the rescue operation > should be carried out, or if nobody rescues the streams, then the > streams should be killed. That sounds like good approach, but I believe > that would also take a fair bit of work to implement. > > -- > Tanu > > Hi, a _very_ late reply! Thank you - the pulseaudio team - for looking at this issue. I've just installed PulseAudio 8.0 and was at first slightly disappointed that it didn't seem to be fixed as advertised. 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! Thank you again for looking at this! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20160122/7f33ba7d/attachment.html>
