[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 #15 from David Henningsson <david.henningsson at canonical.com> ---
(In reply to Tanu Kaskinen from comment #13)
> (In reply to David Henningsson from comment #12)
> > (In reply to Tanu Kaskinen from comment #11)
> > > Requiring users to edit the path files doesn't seem like a good solution to
> > > me. 
> > 
> > Correct - the real solution is module-port-manager.
> > 
> > > I'd rather revert the patch that caused this regression (and I plan to
> > > do so in OpenEmbedded).
> > 
> > It's not a regression. Switching to analog speakers when HDMI is unplugged
> > (or turned off) is an improvement.
> 
> It's not an improvement for the user who reported this bug. Instead, the
> change breaks the user's setup that used to work, and the setup isn't some
> weird corner case that doesn't need to be supported.

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.

Where "corner case" for me means that it's perfectly fine to not support it
OOTB (and doing so would break other use cases too), but it's nice if people
can configure PulseAudio to support that corner case, which in this case is
entirely possible, e g, by making changes to either hdmi-output-0.conf or
analog-output-speakers.conf.

The only big question here is whether to prefer internal speakers or HDMI when
both are available. Neither is a corner case, but because it seems somewhat
more likely that people will connect HDMI devices with non-functional speakers
on them, I'm leaning towards keeping the current preference of analog speakers.


> 
> > > But here's another idea for a solution:
> > > 
> > > 1) Remember the last profile the user selected for a card.
> > 
> > Isn't that what module-card-restore already does?
> 
> It's only remembered in the card-restore database. The information isn't
> available to module-switch-on-port-available currently.
> 
> > > 2) When a port becomes available, check if the currently active profile on
> > > that card was selected by the user. If not, and the port is part of the last
> > > user-selected profile, switch to the user-selected profile.
> > 
> > Sorry, but there's too much left out in the above sentence to be able to
> > tell which scenarios this will break.
> 
> Yeah, sorry about the overly terse explanation.
> 
> If the user has manually selected a profile on a card, we know that the user
> wants to use that profile and some port on it, when that port is available.

Just a reminder:

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. 

> 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.

> If a port then becomes
> available on the user-selected profile, we should switch to it, since the
> user wants to use that profile. Or rather, the user wants to use some port
> on that profile, and since we don't necessarily know which port, blindly
> switching to the profile can indeed break some use cases.
> 
> To increase the safety of my proposal, we can make the change more
> conservative while still fixing the problem with HDMI. For some profile
> changes we know which port the user wants to use. If the activated profile
> has only one output port, we know that the user wants to use that port. So,
> rather than remembering the last user-selected profile, we need to remember
> the last user-selected port (input and output ports remembered separately).
> If a profile change is ambiguous about the desired port, then we don't have
> enough information, but when selecting a profile for HDMI output, the
> information is always sufficient with the default configuration (custom
> profiles with HDMI + some other sink are ambiguous, however).

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.

-- 
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/7e9a6b42/attachment.html>