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
