<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Headphones selected on first run while unplugged and other ports are available" href="https://bugs.freedesktop.org/show_bug.cgi?id=87002#c16">Comment # 16</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Headphones selected on first run while unplugged and other ports are available" href="https://bugs.freedesktop.org/show_bug.cgi?id=87002">bug 87002</a> from <a class="email" href="mailto:david.henningsson@canonical.com" title="David Henningsson <david.henningsson@canonical.com>"> David Henningsson</a> <pre>(In reply to Mario Sanchez Prada from <a href="show_bug.cgi?id=87002#c15">comment #15</a>) > (In reply to David Henningsson from <a href="show_bug.cgi?id=87002#c14">comment #14</a>) > > Ok, I've looked at this issue now. > > > > The startup order is something like: > > > > 1) module_alsa_card's init_jacks initializes port availability, and for > > every port, we get a callback to port_available_hook_callback. No action is > > done here due to the fix for <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - Pulse Audio settings lost after reboot / HDMI is set as default" href="show_bug.cgi?id=73375">bug 73375</a>. > > > > 2) module_alsa_card's init_profile is called, which in turn creates sources > > and sinks. At this point, we don't switch profiles: our current profile is > > analog, we don't switch away from profiles when ports become unavailable. > > > > The thing is, to solve this properly, we should need a callback *between* 1) > > and 2). We can't act on 1), because not all ports are guaranteed to have its > > availability set yet. But acting on 2) is too late, because then the profile > > is already set. > > What about letting 1) and 2) to finish, as if everything went fine and then, > as a last and desperate attempt to avoid having a profile with no ports > available, check if there's a better option and switch profiles if needed? > > That's the "hack" I've been experimenting with lately in this device (notice > that we use PA 5.0, but an stable release, not the trunk), and so far seemed > to work fine, although I'm not 100% it's a totally broken or not. > > You can check it in this commit: > <a href="https://github.com/mariospr/pulseaudio/commit/">https://github.com/mariospr/pulseaudio/commit/</a> > 4d3fdd5bbe8bc003f98403188e38a02110ba4c91 > > Please let me know what you think > > Thanks a lot for the feedback! Well, it's a hack. And the hackier, the more likely we regress some other use case. I'm more thinking that maybe one could initialize the port availability earlier, even before pa_card_new, using the pa_device_port_new_data_set_available function. Then we could act accordingly already in the callback in 1).</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>