<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Changing device profile to HDMI is reset to default after short delay" href="https://bugs.freedesktop.org/show_bug.cgi?id=93946#c17">Comment # 17</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Changing device profile to HDMI is reset to default after short delay" href="https://bugs.freedesktop.org/show_bug.cgi?id=93946">bug 93946</a> from <a class="email" href="mailto:tanuk@iki.fi" title="Tanu Kaskinen <tanuk@iki.fi>"> Tanu Kaskinen</a> <pre>(In reply to David Henningsson from <a href="show_bug.cgi?id=93946#c15">comment #15</a>) > 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. > 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. I agree about that preference. > > 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. 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. > 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?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>