The HDMI spec makes it so that when audio is playing through an HDMI output (the sink, set to profile HDMI), audio stops playing. This causes problems such as music players appearing to "stop playback" (but silently continuing playback), or YouTube playback (even in fullscreen) appearing to "shut up", when the desktop environment / X11 window system tells the display to save power. There are three workarounds to this problem, both of which are inadequate: i. Wiggling the mouse to get the display to remain on. This is exceedingly annoying and shouldn't be required of the user. ii. Extending the display DPMS (power-saving) timeout. This merely extends the need to do (i), as well as wasting power when the machine isn't playing sounds at all. iii. Simulating user interaction with an external program that detects when streams play in PulseAudio to HDMI devices. This doesn't require (i) or (ii), but it does mean that we waste power polling PulseAudio in a loop within such a program. It may also mean that the computer itself will fail to execute on other power policy, such as suspend on low battery. I believe that there's a good compromise to be made: 1. if PulseAudio ('s D-Bus session) is tied to a GUI session in X11 or Wayland, 4. and there is a spec-compliant screen saver on the same D-Bus session bus (GNOME's or KDE's, for example), 2. and at least one audio stream is playing to a sink, which has the HDMI profile selected (we will call this a "qualifying stream"), 5. then it may be plausible to use D-Bus messages to delay screen saving until all qualifying streams pause or stop playback. When any of these circumstances are not met, the policy module operates exactly as a no-op. It's my honest belief that this will improve the desktop experience for many users of PulseAudio — especially high-end users who connect their HTPCs to their receivers and other equipment — as well as keep the user experience unaltered for anyone else. This could be implemented as a policy module. As an implementation detail, prospectively, this could be an enhancement to the stream-interaction subsystem that already exists in PulseAudio. Remaining questions to be tackled: a. Do we need to inform the user that the screen saver is blocked while sound is playing back? If so, how? b. Do we provide a mechanism to turn the policy off / on? If so, how? (In paprefs? / As a module option?) c. Do we load this proposed policy module by default? In many (if not most) use cases, it seems that this should in fact be the default. I really would like to get this issue solved, but my own technical expertise with C and the PulseAudio internals make it very hard for me to do the necessary contribution to solve this issue. Therefore, I volunteer U.S. $500 as a bounty for an initial proof-of-concept in-tree (to mean, e.g., a Github fork of PulseAudio that compiles and runs) policy module that would enact this very behavior as specified above. To engage with me for the bounty, just contact me at my e-mail address rudd-o+bounty@rudd-o.com. I will then help you steward the necessary changes to get the module upstreamed and into PulseAudio. Thank you in advance for considering this proposal.
Can you give a pointer to an API that is used to inhibit display power-saving? > Remaining questions to be tackled: > > a. Do we need to inform the user that the screen saver is blocked while > sound is playing back? If so, how? This is a question for desktop environment designers. PulseAudio itself can't really show any notifications. > b. Do we provide a mechanism to turn the policy off / on? If so, how? (In > paprefs? / As a module option?) paprefs could maybe do it. paprefs uses gconf for storing its settings, however, which has serious problems, which is why I don't really like adding more stuff under the control of paprefs. If a GUI toggle is needed, I think it would be better if the module provided an API through the native protocol. paprefs could still be the program to implement the GUI (I think pavucontrol would be fine too), but if the toggle was available in the native protocol, using gconf for this could be avoided. > c. Do we load this proposed policy module by default? In many (if not most) > use cases, it seems that this should in fact be the default. Enabling by default seems sensible to me. (To be clear, I'm not volunteering to implement this any time soon. I just wanted to comment.)
qdbus org.freedesktop.ScreenSaver /ScreenSaver method uint org.freedesktop.ScreenSaver.Inhibit(string application_name, string reason_for_inhibit) The companion method is the UnInhibit() method. Someone else will need to confirm that these are present in GNOME's screensaver, but even if they aren't, that's still a starting point, and GNOME can gain it later (remember I said if the APIs are not supported, the module would be a no-op).
GNOME has an upstream bug. So the thing here is that ideally we don't inhibit the lock screen from happening but just prevent the monitors from being turned on through DPMS. As a start I have created a small PA module which can make the decision (attaching) and am planning to look into how to hook that up on the desktop side next. There are different options for this, but ideally the solution is desktop environment agnostic so anything that directly pushes the information to mutter or g-s-d might be a bit odd.
Created attachment 132341 [details] [review] Proof of concept to track the state in PA, signalling to DE is missing Proof of concept of how it could be implemented in PA. The whole protocol with the DE to actually prevent the DPMS off state is still missing. The information is only logged.
Thanks for working on this! I had a look at the code. I didn't see any big problems, but I have a question: why do you read the "prevent dpms off" bit from a proplist? Do you plan to set the property from some other module? If so, why?
Created attachment 136571 [details] [review] Identical module as patch including other changes Hrm, I completely forgot about this again and didn't even realise there was reply :) Using a property seemed like an easy way to tag all the relevant sinks as there are already configurations and e.g. the device.icon_name property (which is set to "video-display" in this case). Don't have a strong opinion on how to detect the case. Note that one could even go further than this an e.g. figure out the relevant DRM device for the monitor so that only that monitor will be kept on.
Can you send the patch to pulseaudio-discuss@lists.freedesktop.org? That will give it more visibility and make it tracked by patchwork, so it won't get forgotten. Posting to pulseaudio-discuss requires subscription, here's the listinfo page: https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/451.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.