<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#c21">Comment # 21</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#c20">comment #20</a>) > (In reply to Tanu Kaskinen from <a href="show_bug.cgi?id=93946#c17">comment #17</a>) > > 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. I guess we will have to live with that. > > > > 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...? If you re-read what I wrote, you'll see that I was only talking about profile switches that change the profile away from the user-selected one (which is the surround profile in this scenario). If I'm not mistaken, those don't happen unless all ports on the profile have become unavailable. > 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. Ok, that's fine. I'll try to implement my proposal in time for 9.0. If that fails, we should revert the change that caused this regression.</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>