[pulseaudio-tickets] [Bug 93946] Changing device profile to HDMI is reset to default after short delay

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=93946

--- Comment #20 from David Henningsson <david.henningsson at canonical.com> ---
(In reply to Tanu Kaskinen from comment #17)
> (In reply to David Henningsson from comment #15)
> > Broken internal speakers is a corner case.
> > 
> > Wanting to play back audio to something that's turned off or unplugged is
> > also a corner case.
> 
> Indeed. However, if you tell PulseAudio to use HDMI for output, it's not a
> corner case to expect the audio output stay at HDMI after you've taken a 10
> minute break and the display has gone to sleep.

Okay, maybe so. But at the same time, if we fix that, then we get another quirk
instead; if a user plays back audio through HDMI, then unplugs it and playback
continues through the internal speaker, connects to another HDMI monitor which
has a non-functional speaker, then the result is that sound suddenly disappears
(because it's being rerouted to the new HDMI monitor).

We might decide that quirk is less of an issue (and probably,
module-port-manager would have that quirk too if it doesn't start looking at
ELD info), but it wouldn't surprise me if we got bug reports for that scenario,
if we implement things your way.

> > We do not have a "select port and profile in one go"-API (even though I've
> > been talking about it a few times, and even have a draft implementation
> > somewhere). This means that when you select a port in the Gnome/Unity API,
> > it first issues a command to change profile. This will likely lead to that
> > profile is being seen by PA as manually selected, even if the user just
> > clicked on the port.
> 
> The "select port and profile in one go" API is not required for my proposal,
> but it will reduce the cases a lot where we can't do automatic profile
> switches due to ambiguous user preference.
> 
> The Gnome UI raises an interesting point, though. The user selects only an
> output port or an input port, but PulseAudio doesn't know which. I
> previously implied that each profile switch would update the preference for
> both input and output port. It looks like the algorithm should be even more
> conservative: we have confidence about the preference only if the profile
> switch changes only the output and keeps the input part of the profile
> intact, or vice versa.
> 
> > > If the currently selected profile is different than the user-selected
> > > profile, it means that we have automatically switched the profile. In the
> > > default configuration, such profile switch can only happen if all ports on
> > > the user-selected profile have become unavailable. 
> > 
> > This sentence breaks one of the use cases the patch set fixes; i e, you're
> > on 5.1 surround line out, plug headphones in, PA switches to stereo. When
> > headphones are unplugged, previously PA would stay on stereo, now it goes
> > back to 5.1 as expected.
> 
> Can you explain how my proposal would break that? I don't think it does.

I'm not really sure, but I read "profile switch can only happen if all ports on
the user-selected profile have become unavailable". In the case of going back
to 5.1, stereo is still available on line out, so profile switching does not
happen...?

> > So what you're suggesting is to remember the last user selected port, and
> > give that the highest priority? Well, add a priority list of devices, and
> > you have implemented something very similar to module-port-manager.
> 
> True. However, I believe there's a huge difference in implementation effort
> between my proposal and full-blown priority list routing. I'm not
> volunteering to write module-port-manager by 9.0. Are you?

I can't promise when I have time and energy to continue writing
module-port-manager. I also believe what you're suggesting is far from trivial
(including that out of experience, routing algorithm changes are very likely to
break some other use case), so I rather spend my efforts on module-port-manager
than writing something to change this particular scenario.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-bugs/attachments/20160202/a56169ab/attachment.html>