Bug 93946

Can you reproduce the bug if you disable DPMS (i.e. disable screen powersaving when there is no user activity)?

Yes, using "xset s off -dpms", after setting the sound output to HDMI, and then leaving the machine alone for about 45 minutes the system was still set to HDMI output for sound, and had not switched to analog. So the problem indeed does not occur if dpms is disabled - of course dpms needs to be reset back to normal (enabled) again for continued use, since the monitor does not go into powersaving mode if dpms is off.  Does this lead to a possible solution to the problem?

Regression, marking as a 9.0 release blocker.

Mike, can you attach the server log with these steps:

1) systemctl --user stop pulseaudio.socket pulseaudio.service

2) pulseaudio -vv --log-time --log-target=file:/tmp/pulse.log (leave running in a terminal)

3) make sure HDMI is selected

4) let the display sleep

5) wake up the display

6) ctrl-c in the terminal window where pulseaudio is running

7) systemctl --user start pulseaudio.socket

8) attach /tmp/pulse.log to this bug

Created attachment 121425 [details]
/tmp/pulse.log as per comment #3

So (without the log) I have a theory.

When the monitor is DPMSed, its HDMI audio port becomes unavailable. PulseAudio notices that and, due to module-switch-on-port-available, switches. To verify the theory, please disable the module in /etc/pulse/default.pa, enable DPMS, and retest.

It would be especially interesting (but I understand that it's a bit more than one can expect from a user) if you compiled PulseAudio from git, with this commit reverted, just to prove or disprove that it is indeed the curlpit:

author	David Henningsson <david.henningsson@canonical.com>	2015-11-17 14:10:35 (GMT)
committer	Tanu Kaskinen <tanuk@iki.fi>	2015-11-22 02:59:30 (GMT)
commit	e87100d41ef6d14f8dc7f803582191d9f8d8f183 (patch)
tree	51caaca6a650c58a702fedb0a0228f7cf7775c23
parent	063a1d350fad1cb6fac28dbffe26a7e805626cb2 (diff)
module-switch-on-port-available: Route to preferred profile
This makes the routing slightly more aggressive:

 * It will try to route to another profile, if such a profile
   is preferred by the port.

 * It will allow changing profiles on transitions both to
   PA_AVAILABLE_YES and PA_AVAILABLE_NO

To accommodate there is also some refactoring.

Signed-off-by: David Henningsson <david.henningsson@canonical.com>



There is also a patch on the mailing list that attempts to fix up the module for a different bug, but I suspect that it will not help:

https://patchwork.freedesktop.org/patch/72053/

Your log confirms the guess:

( 675.820| 670.719) D: [pulseaudio] alsa-util.c: ELD info empty (for device=7)
( 675.822|   0.002) D: [pulseaudio] module-alsa-card.c: Jack 'HDMI/DP,pcm=7 Jack' is now unplugged
( 675.823|   0.000) D: [pulseaudio] device-port.c: Setting port hdmi-output-1 to status no
( 675.823|   0.000) D: [pulseaudio] module-switch-on-port-available.c: Trying to switch away from port hdmi-output-1, found analog-output-speaker
( 675.823|   0.000) D: [pulseaudio] module-switch-on-port-available.c: Trying to switch to port analog-output-speaker
( 675.823|   0.000) D: [pulseaudio] module-switch-on-port-available.c: Finding best profile for port analog-output-speaker, preferred = (null)

So it does try to switch back to HDMI, but fails:

( 738.156|   0.000) D: [pulseaudio] module-switch-on-port-available.c: No suitable profile found

It is not yet known why it thinks that the hdmi-stereo-extra1 profile is not suitable.

(In reply to Alexander E. Patrakov from comment #7)
> It is not yet known why it thinks that the hdmi-stereo-extra1 profile is not
> suitable.

The reason is most likely this in profile_good_for_output():

        if (sink->active_port->available != PA_AVAILABLE_NO)
            return false;

If the currently active port is not unavailable, no switching happens. David's patch relaxes this restriction so that if the currently active port has lower priority than the port that became available, then the switch is done, but since HDMI has lower priority than speakers, the switch doesn't happen, so the patch won't fix this bug.

One approach for fixing this would be to modify the port priorities based on user actions, so that manually selecting the HDMI output would increase the HDMI port priority above the currently active port (or even above all ports). Implementing that would be tricky, however, because the user doesn't always directly select the port. The user may switch the output by changing the profile, or since this is KDE, the user probably changes the routing by manipulating the priority lists in module-device-manager. Maybe module-switch-on-connect should be made aware of the priority configuration that module-device-manager maintains?

Actually there was an experimental patch from David doing something like that, "module-port-manager": http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/23018 - but the idea exhibits a lot of interference with module-stream-restore.

I would argue that:

Let's add the port priority patch ( https://patchwork.freedesktop.org/patch/72053/ )

and then, if a user prefers using HDMI over analog speakers, (s)he can set the priorities accordingly in /usr/share/pulseaudio/alsa-mixer/paths

For remembering a chain of devices in order, we need a working module-port-manager (and a "set port and profile in one go" API to go with it).

Requiring users to edit the path files doesn't seem like a good solution to me. I'd rather revert the patch that caused this regression (and I plan to do so in OpenEmbedded).

But here's another idea for a solution:

1) Remember the last profile the user selected for a card.

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.

(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. Staying on analog speakers when HDMI is plugged in, is to keep existing behaviour.

Also, Gnome has a desire to "implement predictable routing in PulseAudio" (see https://wiki.gnome.org/Design/SystemSettings/Sound ), and this is a step in that direction. Although that page lists HDMI above internal speakers, indicating that we should lower the priority of internal speakers. (Which would also solve this bug, but I'm not sure whether or not we want to do that by default anyway.)

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

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

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

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

Just adding a brief comment to the valuable previous comment #13 that Tanu made, in my case the "only" available speakers on my system are within the monitor, so falling back to analog means that gives no sound at all until the profile is switched back to HDMI. So current behaviour certainly breaks my sound support, and means that every single time I want to have sound after not using the machine for a matter of ten minutes or so I then have to go into the settings and switch profile again. That is not user friendly.  It will be nice to see an agreed solution for a good way forward, and I am thankful for the work being done on developing and fixing bugs in the pulseaudio packages.

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

(In reply to Mike C from comment #14)
> Just adding a brief comment to the valuable previous comment #13 that Tanu
> made, in my case the "only" available speakers on my system are within the
> monitor, so falling back to analog means that gives no sound at all until
> the profile is switched back to HDMI. So current behaviour certainly breaks
> my sound support, and means that every single time I want to have sound
> after not using the machine for a matter of ten minutes or so I then have to
> go into the settings and switch profile again. That is not user friendly. 

It's not user friendly to have broken internal speakers (you should talk to your computer manufacturer about that ;-) ). Then your computer tricks PA to think that they are in fact working, and as a result PA makes bad decisions.

If PA 8.0 makes worse decisions for the corner case of "broken internal speakers", but at the same time makes better decisions for many other people, then I would prefer not to revert my patch.

In the wait for a module-port-manager which I never seem to be able to finish (argh), there are at least two workarounds:

 1) Unload module-switch-on-port-available, which leaves all switching of ports up to you.

or

 2) Change /usr/share/pulseaudio/alsa-mixer/ports/analog-output-speaker.conf and add something random that disables it, e g:

[Element IDoNotExist]
required = any

> It will be nice to see an agreed solution for a good way forward, and I am
> thankful for the work being done on developing and fixing bugs in the
> pulseaudio packages.

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

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

(In reply to David Henningsson from comment #16)
> (In reply to Mike C from comment #14)
> > Just adding a brief comment to the valuable previous comment #13 that Tanu
> > made, in my case the "only" available speakers on my system are within the
> > monitor, so falling back to analog means that gives no sound at all until
> > the profile is switched back to HDMI. So current behaviour certainly breaks
> > my sound support, and means that every single time I want to have sound
> > after not using the machine for a matter of ten minutes or so I then have to
> > go into the settings and switch profile again. That is not user friendly. 
> 
> It's not user friendly to have broken internal speakers (you should talk to
> your computer manufacturer about that ;-) ). Then your computer tricks PA to
> think that they are in fact working, and as a result PA makes bad decisions.
> 
> If PA 8.0 makes worse decisions for the corner case of "broken internal
> speakers", but at the same time makes better decisions for many other
> people, then I would prefer not to revert my patch.
> 

The comment that I have "broken internal speakers" does not represent the physical situation at all. My computer is a small mini-itx motherboard with one of the Ivybridge series of processors, in a fanless enclosure, and does not have any internal speakers. So the speakers are not broken at all - they don't exist.  The video and audio goes out from the motherboard through HDMI to a monitor that has its own speakers that work perfectly through the HDMI connector. Therefore it would not seem unreasonable that having the sound set in my configs to go through HDMI to the monitor is the permanent setup irrespective of whether the monitor goes into powersaving mode when not used for some period. Moving the mouse to get the monitor screen lit up again after the system has been left idle is normal operation and I suspect not a corner case!

(In reply to Mike C from comment #18)
> (In reply to David Henningsson from comment #16)
> > (In reply to Mike C from comment #14)
> > > Just adding a brief comment to the valuable previous comment #13 that Tanu
> > > made, in my case the "only" available speakers on my system are within the
> > > monitor, so falling back to analog means that gives no sound at all until
> > > the profile is switched back to HDMI. So current behaviour certainly breaks
> > > my sound support, and means that every single time I want to have sound
> > > after not using the machine for a matter of ten minutes or so I then have to
> > > go into the settings and switch profile again. That is not user friendly. 
> > 
> > It's not user friendly to have broken internal speakers (you should talk to
> > your computer manufacturer about that ;-) ). Then your computer tricks PA to
> > think that they are in fact working, and as a result PA makes bad decisions.
> > 
> > If PA 8.0 makes worse decisions for the corner case of "broken internal
> > speakers", but at the same time makes better decisions for many other
> > people, then I would prefer not to revert my patch.
> > 
> 
> The comment that I have "broken internal speakers" does not represent the
> physical situation at all. My computer is a small mini-itx motherboard with
> one of the Ivybridge series of processors, in a fanless enclosure, and does
> not have any internal speakers. So the speakers are not broken at all - they
> don't exist. 

Still, something is telling us that there is an internal speaker, so please submit alsa-info ( https://wiki.ubuntu.com/Audio/AlsaInfo ) so we know for sure what it is.

Second, if this is a motherboard that has a "internal speaker" header on it which you chose not to connect when you built your HTPC, you should configure the system accordingly, e g by disabling the internal speaker through hda-jack-retask.

If there is not such a header, then you likely have a bug in BIOS, which we can work around in the Linux kernel.

> The video and audio goes out from the motherboard through HDMI
> to a monitor that has its own speakers that work perfectly through the HDMI
> connector. Therefore it would not seem unreasonable that having the sound
> set in my configs to go through HDMI to the monitor is the permanent setup
> irrespective of whether the monitor goes into powersaving mode when not used
> for some period. Moving the mouse to get the monitor screen lit up again
> after the system has been left idle is normal operation and I suspect not a
> corner case!

The "corner case" refers to your phantom internal speaker.

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

(In reply to David Henningsson from comment #20)
> (In reply to Tanu Kaskinen from comment #17)
> > 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.

(In reply to David Henningsson from comment #19)
> (In reply to Mike C from comment #18)
> > (In reply to David Henningsson from comment #16)
> > > (In reply to Mike C from comment #14)
> > > > Just adding a brief comment to the valuable previous comment #13 that Tanu
  
> Still, something is telling us that there is an internal speaker, so please
> submit alsa-info ( https://wiki.ubuntu.com/Audio/AlsaInfo ) so we know for
> sure what it is.
> 
> Second, if this is a motherboard that has a "internal speaker" header on it
> which you chose not to connect when you built your HTPC, you should
> configure the system accordingly, e g by disabling the internal speaker
> through hda-jack-retask.

> The "corner case" refers to your phantom internal speaker.

On the system one way to show the analog "availability" is doing:
$ aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
pulse
    PulseAudio Sound Server
default
    Default ALSA Output (currently PulseAudio Sound Server)
sysdefault:CARD=PCH
    HDA Intel PCH, ALC892 Analog
    Default Audio Device
front:CARD=PCH,DEV=0
    HDA Intel PCH, ALC892 Analog
    Front speakers
surround21:CARD=PCH,DEV=0
    HDA Intel PCH, ALC892 Analog
    2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=PCH,DEV=0
    HDA Intel PCH, ALC892 Analog
    4.0 Surround output to Front and Rear speakers
surround41:CARD=PCH,DEV=0
    HDA Intel PCH, ALC892 Analog
    4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=PCH,DEV=0
    HDA Intel PCH, ALC892 Analog
    5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=PCH,DEV=0
    HDA Intel PCH, ALC892 Analog
    5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=PCH,DEV=0
    HDA Intel PCH, ALC892 Analog
    7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
hdmi:CARD=PCH,DEV=0
    HDA Intel PCH, HDMI 0
    HDMI Audio Output
hdmi:CARD=PCH,DEV=1
    HDA Intel PCH, HDMI 1
    HDMI Audio Output

Whilst in principle I could work to "disable" the internal speaker port using the tool you mentioned I don't think that this is something that the typical non-power user would be expected to do. After all there are a lot of tower computers that do not have any internal speakers in the box, even if there is a sound output socket on the motherboard. If a user chooses to have a simple HDMI connection from the box to a monitor or his house TV set to use as a monitor with sound, and have to clutter his desk having a set of speakers and associated additional physical leads, then getting it going for any up to date linux system, whether it is arch, Ubuntu, Fedora or any other flavour should not need the user to start looking at internal changes in order to have sound for normal desktop operation,  simply work with minimal config setup. 

I think it is perfectly reasonable for a user to expect to be able to install pulseaudio and its associated libraries and click on a GUI setup facility and select HDMI if he/she so chooses, and then expect it work continue to work whether his system sleeps or power saves his monitor, or not. After all the patch that caused this problem was added in the current release of pulseaudio, so it should either be reverted or the problem fixed.

(In reply to Tanu Kaskinen from comment #21)
> (In reply to David Henningsson from comment #20)
> > 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.

I disagree that this is a regression - the phantom internal speaker is a bug caused by lower layers (ALSA/BIOS/hw). We should not revert the change when it improves routing in several other scenarios; as we would then regress those scenarios instead.

Also, I'm far from confident that what you're proposing won't cause regressions in some other scenario.

(In reply to David Henningsson from comment #23)
> I disagree that this is a regression - the phantom internal speaker is a bug
> caused by lower layers (ALSA/BIOS/hw). We should not revert the change when
> it improves routing in several other scenarios; as we would then regress
> those scenarios instead.

You already agreed that it's a valid thing to expect HDMI continue working after display going to sleep. That use case worked before, now it doesn't work. Clearly a regression.

It's true that reverting the patch in 9.0 will cause a regression for those users who liked the new feature in 8.0, but the thing is that the patch should never have been applied in the first place.

> Also, I'm far from confident that what you're proposing won't cause
> regressions in some other scenario.

Then we'll fix those issues or revert my patch in 10.0.

(In reply to Mike C from comment #22)
> 
> On the system one way to show the analog "availability" is doing:
> $ aplay -L

*sigh*

I asked for alsa-info, not "aplay -L".

> Whilst in principle I could work to "disable" the internal speaker port
> using the tool you mentioned I don't think that this is something that the
> typical non-power user would be expected to do. After all there are a lot of
> tower computers that do not have any internal speakers in the box, even if
> there is a sound output socket on the motherboard. 

All those tower computers do not have the phantom internal speaker that you're having, therefore your reasoning does not apply.

The phantom internal speaker is not a common bug, and it's not a bug in PA, it's a bug in the lower layers of the audio stack. 



Tanu and Mike, I'm getting tired of arguing with you. Perhaps the most common routing bug/request I've got over the past few years is that when HDMI is unplugged, sound should be rerouted to internal speakers. Now that's implemented [1] - after many discussions and at least one rewrite just to make Tanu happy - and now you claim it's a regression and that it should be reverted. Every routing change breaks somebody's workflow, but it's an improvement for many, so don't revert it.

[1] At least for machines where HDMI and analog share the same sound card.

(In reply to Tanu Kaskinen from comment #24)
> You already agreed that it's a valid thing to expect HDMI continue working
> after display going to sleep. That use case worked before, now it doesn't
> work. Clearly a regression.

If so, that's a separate bug. This bug is mainly caused by a phantom internal speaker. (Well, at least very likely so, if Mike submits alsa-info I can tell for sure.)

HDMI will continue to work if there are no other outputs with higher priority. Which is the typical scenario for an HTPC or desktop, and which I believe is the least bad option at this point.

> It's true that reverting the patch in 9.0 will cause a regression for those
> users who liked the new feature in 8.0, but the thing is that the patch
> should never have been applied in the first place.

That's your opinion. I disagree.

(In reply to David Henningsson from comment #25)
> Tanu and Mike, I'm getting tired of arguing with you. Perhaps the most
> common routing bug/request I've got over the past few years is that when
> HDMI is unplugged, sound should be rerouted to internal speakers. Now that's
> implemented [1] - after many discussions and at least one rewrite just to
> make Tanu happy - and now you claim it's a regression and that it should be
> reverted. Every routing change breaks somebody's workflow, but it's an
> improvement for many, so don't revert it.

Don't get me wrong, your patches are very much appreciated. The new feature just wasn't yet ready for general use.

If you're now getting bug reports about people wanting audio to move to the internal speakers when HDMI is unplugged, what do you think those same people will think when the audio moves to the internal speakers every time they take a ten minute break while HDMI is plugged in?

Created attachment 121459 [details]
alsa-info.txt as requested by D Henningsson

(In reply to Mike C from comment #28)
> Created attachment 121459 [details]
> alsa-info.txt as requested by D Henningsson

Thanks. Indeed it is a sloppy BIOS vendor or motherboard manufacturer, who thinks you have both an internal speaker and an internal mic. They even left the "Manufacturer" field empty...

So, my recommendation remains: first use hda-jack-retask to disable what you don't have, reboot, and test that it in fact resolves this issue.

I can submit a patch to upstream ALSA for you that will remove speaker and mic for everyone with this motherboard (unless you want to do it yourself), but then you need to check that there is no pin header on the motherboard, which you can actually connect such a speaker or mic.

The motherboard is an Intel DQ77KB so it is pure Intel!  I will have a look at the hdajackretask documentation but from what I have seen it is on the sparse side so will need a bit of research. Thanks for the suggestions. I'd still like this to be resolved as working code within the pulseaudio packages.

By the way there is the possibility that I might want to use the mic input at some point without changing the HDMI sound out - so disabling that is not ideal! And of course at some point plugging in a headset with mic I'd hope would not require resetting the sound system in order to work also.

There is an integration guide for the motherboard available to download at https://downloadcenter.intel.com/download/21339/DQ77KB-Product-Documentation-Manuals in which it does clearly show that there is an "Internal stereo speakers connector" on the motherboard as well as "Front panel audio connector".  Section 1.8 gives further details of the audio connectors on the motherboard.  Just because there is nothing connected to them for normal operation should mean they have to have special changes made in order to use them at some point in the future.

It should be simple for the user to plug in a headset or speakers directly on the motherboard and be able to select them as a new default if the HDMI connected monitor is also present.  Hence killing the speaker output as a default way to make sure that HDMI works is not a good solution.  Some users of this same board might reasonably choose to plug speakers in and not have a monitor with integral speakers.  Each of those setups should work and not need any upstream disabling of the speaker output!

It does look like a more flexible solution than just disabling the speaker output would be a lot more satisfactory. However disabling the speaker pins is a temporary solution until a proper fix is implemented.

It depemd on your computer chassis,

You need to use early patching to fixup two pins the internal speaker and interrnal dmic

I made the suggested changes to the internal mic and internal speakers to attempt to effect an interim workaround by running hdajackretask and set the override for the internal mic and internal speakers to "not connected", applied the change as well as setting the boot override. After rebooting and checking those settings remained, I then let the screen timeout to powersave - and then brought the screen lighting back and tested the sound - despite having made those changes the HDMI sound had been reset back to analog stereo.  So unless there are other changes required this is not a workaround that helps.

But bit 8 of pin default of  headphone jack is set which imply no jack detect circuit, unsolicited event is not enabled



Node 0x1b [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out 
Control: name="Headphone Playback Switch", index=0, device=0 
ControlAmp: chs=3, dir=Out, idx=0, ofs=0 
Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 
Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 
Amp-Out vals: [0x80 0x80] Pincap 0x0001373e: IN OUT HP EAPD Detect Trigger 
Vref caps: HIZ 50 GRD 80 100 
EAPD 0x2: EAPD 
Pin Default 0x02214130: [Jack] HP Out at Ext Front Conn = 1/8, Color = Green DefAssociation = 0x3, Sequence = 0x0 Misc = NO_PRESENCE 
Pin-ctls: 0xc0: OUT HP VREF_HIZ 
Unsolicited: tag=00, enabled=0 
Power states: D0 D1 D2 D3 EPSS 
Power: setting=D0, actual=D0 
Connection: 5

For the moment I have made a workaround based on the comment #5 by Alexander, and edited /etc/pulse/default.pa to comment out the line:

#load-module module-switch-on-port-available

Now the selected HDMI port remains in place and remains selected after the monitor goes into powersave and later when I come back to the computer and re-activate the HDMI connected monitor.

However it will be valuable to see how Tanu's suggested remedy for the regression works out in version 9.0, ahead of a more complete fix in version 10.0

As your motherboard support hda front audio panel and ac97 front audio panel,
Bios seem not support selevt front audio panel type,do  your Mini itx computer chassis have hda front audio panel? 

Pin Default 0x02214130: [Jack] HP Out at Ext Front Conn = 1/8, Color = Green DefAssociation = 0x3, Sequence = 0x0 Misc = NO_PRESENCE

(In reply to Raymond from comment #37)
> As your motherboard support hda front audio panel and ac97 front audio panel,
> Bios seem not support selevt front audio panel type,do  your Mini itx
> computer chassis have hda front audio panel? 
> 
> Pin Default 0x02214130: [Jack] HP Out at Ext Front Conn = 1/8, Color = Green
> DefAssociation = 0x3, Sequence = 0x0 Misc = NO_PRESENCE

The chassis doesn't have a front panel - only a back panel. I guess that is why the NO-PRESENCE for that output is listed in the quoted lines?

Do you mean that you plug your headphone into green line out jack


Node 0x14 [Pin Complex] wcaps 0x40058d: Stereo 
Amp-Out Control: name="Line Out Playback Switch", index=0, device=0 
ControlAmp: chs=3, dir=Out, idx=0, ofs=0 
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 
Amp-Out vals: [0x00 0x00] Pincap 0x0001003e: IN OUT HP EAPD Detect Trigger EAPD 0x2: EAPD 
Pin Default 0x01014010: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Green DefAssociation = 0x1, Sequence = 0x0 
Pin-ctls: 0x40: OUT Unsolicited: tag=01, enabled=1 
Power states: D0 D1 D2 D3 EPSS 
Power: setting=D0, actual=D0 
Connection: 1 0x0c

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/Documentation/sound/alsa/HD-Audio.txt


You can use hdajackretask to fixup hp and mic at ext front as not connected

Change node 0x14 from line out to hp


Or

add_jack_modes (bool): add "xxx Jack Mode" enum controls to each I/O jack for allowing to change the headphone amp and mic bias VREF capabilities

Thank you Raymond, that is useful and I wasn't aware of these details.

Patches have been submitted:

1/3: https://patchwork.freedesktop.org/patch/74012/
2/3: https://patchwork.freedesktop.org/patch/74013/
3/3: https://patchwork.freedesktop.org/patch/74014/

Testing would be very welcome.

Tested these patches on top of the 8.0 release:

When my TV goes into sleep/switches refresh-rates, PA still switches away from the HDMI output.
Log with -vvv: https://gist.github.com/BtbN/21949536c438e2083872

Killing the PA server makes it select the correct HDMI output profile on startup again, until the HDMI port becomes unavailable for a moment again.

Thanks for testing! It seems that my code never sets the hdmi port as the preferred port. What if you shut down pulseaudio, remove ~/.config/pulse/*card-database* and then restart pulseaudio? After removing that file, HDMI should not be selected by default, but once you manually select HDMI, it should stick until you shut down pulseaudio. I would be interested to hear if it works as long as pulseaudio stays running.

When you later restart pulseaudio again, I expect it to be again similarly broken. I wrote in the commit message that it would be beneficial to save the preferred port on disk, but actually it seems to be not only beneficial, but absolutely critical. I don't know why I thought it would work without making the preference persistent...

Hmm... actually there's no need to remove the card-database file to verify my theory. Just switch to HDMI at any time a wrong profile is active. It should stay at HDMI after that, until you shut down pulseaudio. Can you check that for me?

Here's what I did to test now:

~ % pulseaudio -k
~ % rm .config/pulse/*card-database*
~ % killall kodi.bin
~ % pacmd list-cards | grep "active profile"
        active profile: <output:analog-stereo+input:analog-stereo>
~ % pactl set-card-profile 0 output:hdmi-stereo
~ % pacmd list-cards | grep "active profile"
        active profile: <output:hdmi-stereo>
~ % xrandr -s 1920x1080 -r 24
~ % pacmd list-cards | grep "active profile"
        active profile: <output:analog-surround-40>
~ % pactl set-card-profile 0 output:hdmi-stereo
~ % xrandr -s 1920x1080 -r 60
~ % pacmd list-cards | grep "active profile"
        active profile: <output:analog-surround-40>
~ % pactl set-card-profile 0 output:hdmi-stereo
~ % pacmd list-cards | grep "active profile"
        active profile: <output:hdmi-stereo>
~ % xrandr -s 1920x1080 -r 50
~ % pacmd list-cards | grep "active profile"
        active profile: <output:analog-surround-40>

It still switches away from hdmi-stereo whenever possible.
I also verified I'm indeed using 8.0 + the 3 patches.

(In reply to Mike C from comment #38)
> (In reply to Raymond from comment #37)
> > As your motherboard support hda front audio panel and ac97 front audio panel,
> > Bios seem not support selevt front audio panel type,do  your Mini itx
> > computer chassis have hda front audio panel? 
> > 
> > Pin Default 0x02214130: [Jack] HP Out at Ext Front Conn = 1/8, Color = Green
> > DefAssociation = 0x3, Sequence = 0x0 Misc = NO_PRESENCE
> 
> The chassis doesn't have a front panel - only a back panel. I guess that is
> why the NO-PRESENCE for that output is listed in the quoted lines?

No presence mean there is no jack detect ciruit at the front audio panel, pulseaudio just assume the state of   hp is unknown, 

You need to remove those redudant pins internal speaker,  hp,  mic

(In reply to Timo R. from comment #46)
> Here's what I did to test now:
> 
> ~ % pulseaudio -k
> ~ % rm .config/pulse/*card-database*
> ~ % killall kodi.bin
> ~ % pacmd list-cards | grep "active profile"
>         active profile: <output:analog-stereo+input:analog-stereo>
> ~ % pactl set-card-profile 0 output:hdmi-stereo
> ~ % pacmd list-cards | grep "active profile"
>         active profile: <output:hdmi-stereo>
> ~ % xrandr -s 1920x1080 -r 24
> ~ % pacmd list-cards | grep "active profile"
>         active profile: <output:analog-surround-40>
> ~ % pactl set-card-profile 0 output:hdmi-stereo
> ~ % xrandr -s 1920x1080 -r 60
> ~ % pacmd list-cards | grep "active profile"
>         active profile: <output:analog-surround-40>

Ok, that's certainly not what I would have expected. I'll do some testing to see if I can reproduce this sequence. I don't have the right kind of hardware, but when I originally tested the patches, I wrote configuration for my laptop that makes pulseaudio think that the sound card has a HDMI port (actually the sound goes to analog output) with jack detection (actually the "HDMI jack" is the mic jack).

Update: I now have a fix for the bug shown in comment 46, but writing the preferred ports on disk is still not implemented.

I submitted now a new set of patches:

1/6: https://patchwork.freedesktop.org/patch/75813/
2/6: https://patchwork.freedesktop.org/patch/75815/
3/6: https://patchwork.freedesktop.org/patch/75814/
4/6: https://patchwork.freedesktop.org/patch/75816/
5/6: https://patchwork.freedesktop.org/patch/75811/
6/6: https://patchwork.freedesktop.org/patch/75812/

I forgot to test the card-restore part, and it seems not to work...

Another set (v3) posted:

1/6: https://patchwork.freedesktop.org/patch/75856/
2/6: https://patchwork.freedesktop.org/patch/75857/
3/6: https://patchwork.freedesktop.org/patch/75858/
4/6: https://patchwork.freedesktop.org/patch/75861/
5/6: https://patchwork.freedesktop.org/patch/75859/
6/6: https://patchwork.freedesktop.org/patch/75860/

Only the fifth patch is different from the previous submission.

I have the same problem, with a variant that makes harder a fix with a simple alsa quirk:

I have a Zotac box, with
 * an HDMI port
 * a DVI port (incorrectly detected as an HDMI but this doesn't cause any problem here)
 * working internal analog audio with line out and headphone
 * an SPDIF optical output

every element on the previous list seems to have working presence detection (especially the analog audio which is never selected by switch-on-port-available because I don't plug anything do it), EXCEPT the SPDIF which is wired to IEC958. I don't think the hardware is able to detect whether there is something plugged in or not.

Only the HDMI is plugged in, nothing else. When the screen goes into powersave, the HDMI presence turns off, and switch-on-port-available selects the only port which is not "available: no" but rather "available: unknown", but then refuses to switch back to HDMI when the screen is on again.

Thinking that "it is my computer/bios/lower layer" which is broken won't help a bit, because even if *I* don't, other people might want to have something plugged into the SPDIF output.

And I know that I can use hdajackretask to force HDMI detection to PRESENT, or SPDIF to absent. Or that I can use an udev rule to use another profile.conf file in which I set HDMI priority to an higher level. And I did the former because I won't use the SPDIF out anytime soon (I just hope that when I do, I'll remember why it doesn't work). But you can't expect non-technical people to do so, and there's no solution for them as-is.

For them, the new behaviour would be a regression [1], even though I like it for my laptop that I wire now and then to the HDMI aux of my Home Cinema.

[1] In fact the Zotac isn't mine, but I assembled it for a friend who called me for help after an innocent upgrade.

As for the patch series that were submitted (and especially the 6th which is where all heuristics lie):
 - It seems to me rather hand-wavy the way you try to know if the profile change was intentional or not, and I worry about false positives.
 - Why not just remember:
    * whether the current profile/sink was switched to automatically by switch-on-port-available), and if true
    * the profile/sink that was active prior to the automatic switch ?

Then in profile_good_for_output(), if the profile being checked is the previously checked one, accept it (and maybe give it a priority boost since IIUC only the good profile with the highest priority is kept). Maybe this logic belongs to the caller of profile_good_for_output() to avoid the need for an output param for the new priority, or worse to change the priority in the profile struct.

This seems far simpler, and less subject to false positives, while solving this specific case of intermittent unavailability. That way you don't tread into the territory of a real profile manager, and the patch set would be accepted more easily.

The first three patches look OK to me.

Cheers

For the record, my comment was a bit off since SPDIF has a priority of 0. The reason the switch wasn't made back to HDMI was because I didn't have https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/module-switch-on-port-available.c?id=f6e1ac2dd2af01088fb9fea85bd57502a214335b applied.

This doesn't change the fact that the current behavior is a regression for people without hardware analog jack detection. Sure there probably isn't that many nowadays, so this might be what David Henningsson calls "corner cases".

Cheers,

(In reply to Julien "_FrnchFrgg_" RIVAUD from comment #54)
> As for the patch series that were submitted (and especially the 6th which is
> where all heuristics lie):
>  - It seems to me rather hand-wavy the way you try to know if the profile
> change was intentional or not, and I worry about false positives.

Surely the way to know if a profile switch was an explicit user request (which I assume you mean by "intentional") is not hand-wavy? It's trivial to know whether a profile change was an explicit request - just check the "save_profile" flag, that's set iff the user requested the profile switch.

Maybe you mean that the way the patch figures out whether the activation of a port was the user's explicit request is hand-wavy? That logic is more complicated, but I'm confident myself that the patch doesn't cause false positives. It would be very interesting to see a counter example.

>  - Why not just remember:
>     * whether the current profile/sink was switched to automatically by
> switch-on-port-available), and if true
>     * the profile/sink that was active prior to the automatic switch ?
> 
> Then in profile_good_for_output(), if the profile being checked is the
> previously checked one, accept it (and maybe give it a priority boost since
> IIUC only the good profile with the highest priority is kept). Maybe this
> logic belongs to the caller of profile_good_for_output() to avoid the need
> for an output param for the new priority, or worse to change the priority in
> the profile struct.
> 
> This seems far simpler, and less subject to false positives, while solving
> this specific case of intermittent unavailability. That way you don't tread
> into the territory of a real profile manager, and the patch set would be
> accepted more easily.

Blindly switching to the last manually selected profile has the problem that if the profile has multiple ports, you don't know which of those ports the user was interested in when he or she switched to that profile. If there are two unavailable ports in the profile and one of them becomes available, profile switch should only happen if the newly available port was the one that the user was previously interested in.

I'm not sure if that problem has any real-world examples, so your approach might be good enough, but your feedback did not convince me that it would be a good idea to rewrite my patches.

My primary concern with this patch series is that it is very common to plug in multiple HDMI devices to a single laptop (monitors, projectors, ...), and it appears that a preference to route to a single device ends up applying to all devices.

David had mentioned that this *may* be a problem. I'd go as far as to say that this is definitely a problem.

So as I understand it, we were looking at solving two problems:

1. Non-existent speakers when there is a speaker control

2. DPMS causing an HDMI unplug

For the first, I concur with David about this not being an issue we should try to solve, and we should let underlying layers fix this properly. *Maybe* we could look at having a pavucontrol option to mark a system as not having internal speakers (and store this on the card in some way).

For the second, I don't have a good solution. Yes, it would be a _lot_ better to be able to distinguish between the DPMS and unplugged states. There seemed to be a suggestion that this is possible at the graphics driver level. Is that true?

As an alternative, it may make sense to at least tie the preferred port setting with the corresponding device names from ELDs. That would prevent us from explicitly having to route to and away from every HDMI device explicitly. It's still not great since ELDs lie, and it's common to have multiple monitors of the same type being connected to (e.g. an office with homogenous monitor setups, but you only have headphones connected to your own workstation).

(In reply to Arun Raghavan from comment #57)
> My primary concern with this patch series is that it is very common to plug
> in multiple HDMI devices to a single laptop (monitors, projectors, ...), and
> it appears that a preference to route to a single device ends up applying to
> all devices.
> 
> David had mentioned that this *may* be a problem. I'd go as far as to say
> that this is definitely a problem.

A worse problem than what my patches fix? I don't think so.

> So as I understand it, we were looking at solving two problems:
> 
> 1. Non-existent speakers when there is a speaker control

My patches don't aim at solving that.

> 2. DPMS causing an HDMI unplug
> 
> For the first, I concur with David about this not being an issue we should
> try to solve, and we should let underlying layers fix this properly. *Maybe*
> we could look at having a pavucontrol option to mark a system as not having
> internal speakers (and store this on the card in some way).
> 
> For the second, I don't have a good solution. Yes, it would be a _lot_
> better to be able to distinguish between the DPMS and unplugged states.
> There seemed to be a suggestion that this is possible at the graphics driver
> level. Is that true?

I don't know. Was it suggested in this bug thread? I tried to search for "driver", "kernel" and "graphics", and I didn't find a place where that would have been suggested.

> As an alternative, it may make sense to at least tie the preferred port
> setting with the corresponding device names from ELDs. That would prevent us
> from explicitly having to route to and away from every HDMI device
> explicitly. It's still not great since ELDs lie, and it's common to have
> multiple monitors of the same type being connected to (e.g. an office with
> homogenous monitor setups, but you only have headphones connected to your
> own workstation).

Creating separate ports based on ELD seems like an improvement for some later time.

(In reply to Tanu Kaskinen from comment #58)
> (In reply to Arun Raghavan from comment #57)
> > My primary concern with this patch series is that it is very common to plug
> > in multiple HDMI devices to a single laptop (monitors, projectors, ...), and
> > it appears that a preference to route to a single device ends up applying to
> > all devices.
> > 
> > David had mentioned that this *may* be a problem. I'd go as far as to say
> > that this is definitely a problem.
> 
> A worse problem than what my patches fix? I don't think so.


> > 2. DPMS causing an HDMI unplug
> > 
> > For the first, I concur with David about this not being an issue we should
> > try to solve, and we should let underlying layers fix this properly. *Maybe*
> > we could look at having a pavucontrol option to mark a system as not having
> > internal speakers (and store this on the card in some way).
> > 
> > For the second, I don't have a good solution. Yes, it would be a _lot_
> > better to be able to distinguish between the DPMS and unplugged states.
> > There seemed to be a suggestion that this is possible at the graphics driver
> > level. Is that true?
> 
> I don't know. Was it suggested in this bug thread? I tried to search for
> "driver", "kernel" and "graphics", and I didn't find a place where that
> would have been suggested.

There seemed to be some discussion around this at:

  https://lists.freedesktop.org/archives/pulseaudio-discuss/2016-February/025394.html

> > As an alternative, it may make sense to at least tie the preferred port
> > setting with the corresponding device names from ELDs. That would prevent us
> > from explicitly having to route to and away from every HDMI device
> > explicitly. It's still not great since ELDs lie, and it's common to have
> > multiple monitors of the same type being connected to (e.g. an office with
> > homogenous monitor setups, but you only have headphones connected to your
> > own workstation).
> 
> Creating separate ports based on ELD seems like an improvement for some
> later time.

Doing a port based on ELDs is one way to do this. The other way to do this is to change how we store preferred_port in module-card-restore from a boolean choice to some other mechanism that allows a more fine-tuned selection of whether the port is the preferred port or not.

As an example, it could be a list of key/value pairs such that if we find any property on a card's port that matches the given (key, value), then it is a preferred port. We could special-case the "name" key to just be the port's name.

Now this does mean that module-card-restore will need to start being aware of the property we'll be adding on the ports. I don't see a way to avoid that.

(In reply to Tanu Kaskinen from comment #58)
> (In reply to Arun Raghavan from comment #57)
> > My primary concern with this patch series is that it is very common to plug
> > in multiple HDMI devices to a single laptop (monitors, projectors, ...), and
> > it appears that a preference to route to a single device ends up applying to
> > all devices.
> > 
> > David had mentioned that this *may* be a problem. I'd go as far as to say
> > that this is definitely a problem.
> 
> A worse problem than what my patches fix? I don't think so.

At least equally bad in my opinion, so I'd prefer avoiding trading one regression for another.

(In reply to Arun Raghavan from comment #60)
> At least equally bad in my opinion, so I'd prefer avoiding trading one
> regression for another.

Regression compared to what?

In 7.0 we kept the HDMI profile active until the user manually switches the profile.

In 8.0 we started to switch away from HDMI when it becomes unavailable.

My patches introduce no regression compared to 7.0 as far as I can see. There is a regression compared to 8.0, but in my books that doesn't count, because the routing changes in 8.0 shouldn't have been included in the release. The readily-available reasonable options that we have are to either revert everything back to 7.0 level, or apply my patches. Both of those cause a "regression" compared to 8.0, but I think that's fine. We can avoid the regression only by keeping things as they are (which is not a good idea in my opinion) or coming up with some new patches.

(In reply to Arun Raghavan from comment #59)
> There seemed to be some discussion around this at:
> 
>  
> https://lists.freedesktop.org/archives/pulseaudio-discuss/2016-February/
> 025394.html

Ok. I guess this (modifying graphics drivers) is not a viable solution for 9.0 (at least I'm not volunteering to modify the drivers).

> Doing a port based on ELDs is one way to do this. The other way to do this
> is to change how we store preferred_port in module-card-restore from a
> boolean choice to some other mechanism that allows a more fine-tuned
> selection of whether the port is the preferred port or not.
> 
> As an example, it could be a list of key/value pairs such that if we find
> any property on a card's port that matches the given (key, value), then it
> is a preferred port. We could special-case the "name" key to just be the
> port's name.
> 
> Now this does mean that module-card-restore will need to start being aware
> of the property we'll be adding on the ports. I don't see a way to avoid
> that.

I'd rather not do this, because I think you overstate the severity of the problem, and because a cleaner solution would be to dynamically create ports based on ELD, and any additions to the card-restore database schema will have to be supported indefinitely. But if you really think this is the best way forward, I can write new patches implementing this.

After sleeping on it, I've come around to the view that having these patches now definitely does takes us forwards in terms of the behaviour, and that we shouldn't block 9.0 on further improving this. These patches are merged now.

Could this patch (or functional fix) be backported to PulseAudio 8.0?

The current long-term support version of Ubuntu (16.04.1 LTS) has adopted PulseAudio 8.0 and is unlikely to switch to PulseAudio 9.0 per long-term support policy.

The current auto-routing experience is sub-optimal for many Ubuntu users (including myself).

Thanks!

PulseAudio upstream won't be making any more 8.x releases (unless someone volunteers to do all the work). It's probably better to ask Ubuntu if they'd be willing to backport the patches.

Definitely NOT resolved, because HDMI audio stops working every time the HDMI display resolution changes. This is especially problematic for SuperTuxKart, which changes resolution automatically at launch. There is currently no way to play fullscreen SuperTuxKart through HDMI and also hear the sound.

On a fresh, up-to-date installation of Ubuntu 16.04, on a Thinkpad T420 via DisplayPort -> HDMI, using the gnome-shell desktop.

Created attachment 128663 [details]
attachment-25067-0.html

This bug is fixed in PulseAudio 9.0, but Ubuntu 16.04 is using PulseAudio
8.0. I tried to backport the fix here:

https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1641954

You may find already built packages here:

https://launchpad.net/~cristiklein/+archive/ubuntu/ppa/+index?field.series_filter=xenial

Can you check if this fixes the issue for you?


On 26 Dec 2016 17:14, <bugzilla-daemon@freedesktop.org> wrote:

Chris Nicolai <deucularsaw@yahoo.com> changed bug 93946
<https://bugs.freedesktop.org/show_bug.cgi?id=93946>
What Removed Added
Resolution FIXED ---
Status RESOLVED REOPENED

*Comment # 65 <https://bugs.freedesktop.org/show_bug.cgi?id=93946#c65> on
bug 93946 <https://bugs.freedesktop.org/show_bug.cgi?id=93946> from Chris
Nicolai <deucularsaw@yahoo.com> *

Definitely NOT resolved, because HDMI audio stops working every time the HDMI
display resolution changes. This is especially problematic for SuperTuxKart,
which changes resolution automatically at launch. There is currently no way to
play fullscreen SuperTuxKart through HDMI and also hear the sound.

On a fresh, up-to-date installation of Ubuntu 16.04, on a Thinkpad T420 via
DisplayPort -> HDMI, using the gnome-shell desktop.

------------------------------
You are receiving this mail because:

   - You are on the CC list for the bug.

The cristiklein ppa fixes it in Ubuntu 16.04. Thanks!

Unable to install pulseaudio (ppa:cristiklein), please advise:

$ uname -a
Linux ganymede 4.4.0-89-generic #112-Ubuntu SMP Mon Jul 31 19:38:41 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/lsb-release 
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS"

$ sudo apt --reinstall install pulseaudio=1:8.0-0ubuntu3.1+ck1
Some packages could not be installed. ...
The following packages have unmet dependencies:
 pulseaudio : Depends: libpulse0 (= 1:8.0-0ubuntu3.1+ck1) but 1:8.0-0ubuntu3.3 is to be installed
              Recommends: pulseaudio-module-x11 but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

Created attachment 133415 [details]
attachment-25228-0.html

The fix is released in xenial-update since pulseaudio 1:8.0-0ubuntu3.2:
http://changelogs.ubuntu.com/changelogs/pool/main/p/pulseaudio/pulseaudio_8.0-0ubuntu3.3/changelog

Hence, there is no need to use my PPA.

If you still encounter this issue, then it means that either the fix is
incomplete or you encountered a new bug. Let me know!

2017-08-09 18:55 GMT+02:00 <bugzilla-daemon@freedesktop.org>:

> *Comment # 68 <https://bugs.freedesktop.org/show_bug.cgi?id=93946#c68> on
> bug 93946 <https://bugs.freedesktop.org/show_bug.cgi?id=93946> from Jeff
> Sheffel <jeff@sheffel.org> *
>
> Unable to install pulseaudio (ppa:cristiklein), please advise:
>
> $ uname -a
> Linux ganymede 4.4.0-89-generic #112-Ubuntu SMP Mon Jul 31 19:38:41 UTC 2017
> x86_64 x86_64 x86_64 GNU/Linux
>
> $ cat /etc/lsb-release
> DISTRIB_CODENAME=xenial
> DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS"
>
> $ sudo apt --reinstall install pulseaudio=1:8.0-0ubuntu3.1+ck1
> Some packages could not be installed. ...
> The following packages have unmet dependencies:
>  pulseaudio : Depends: libpulse0 (= 1:8.0-0ubuntu3.1+ck1) but 1:8.0-0ubuntu3.3
> is to be installed
>               Recommends: pulseaudio-module-x11 but it is not going to be
> installed
> E: Unable to correct problems, you have held broken packages.
>
> ------------------------------
> You are receiving this mail because:
>
>    - You are on the CC list for the bug.
>
>

Cristian,
I should have listed my installed pulseaudio packages (shown below).  The slow audio still occurs after suspending, but sounds correct after a reboot.

$ dpkg -l | grep pulse
ii  gstreamer1.0-pulseaudio:amd64               1.8.3-1ubuntu0.4                               amd64        GStreamer plugin for PulseAudio
ii  libcanberra-pulse:amd64                     0.30-2.1ubuntu1                                amd64        PulseAudio backend for libcanberra
ii  libpulse-mainloop-glib0:amd64               1:8.0-0ubuntu3.3                               amd64        PulseAudio client libraries (glib support)
ii  libpulse0:amd64                             1:8.0-0ubuntu3.3                               amd64        PulseAudio client libraries
ii  libpulsedsp:amd64                           1:8.0-0ubuntu3.3                               amd64        PulseAudio OSS pre-load library
ii  pulseaudio                                  1:8.0-0ubuntu3.3                               amd64        PulseAudio sound server
ii  pulseaudio-module-bluetooth                 1:8.0-0ubuntu3.3                               amd64        Bluetooth module for PulseAudio sound server
ii  pulseaudio-module-x11                       1:8.0-0ubuntu3.3                               amd64        X11 module for PulseAudio sound server
ii  pulseaudio-utils                            1:8.0-0ubuntu3.3                               amd64        Command line tools for the PulseAudio sound server

Jeff,

I am a bit unsure whether you encounter the same bug as originally reported. Could you give me more details? What were the steps that you did? What was the expected results? What was the actual result?