https://bugs.freedesktop.org/show_bug.cgi?id=97866
Bug ID: 97866
Summary: PulseAudio should deal with display DPMS when playing
audio on HDMI devices
Product: PulseAudio
Version: unspecified
Hardware: All
OS: Linux (All)
Status: NEW
Severity: enhancement
Priority: medium
Component: modules
Assignee: pulseaudio-bugs@lists.freedesktop.org
Reporter: rudd-o+freedesk...@rudd-o.com
QA Contact: pulseaudio-bugs@lists.freedesktop.org
CC: lenn...@poettering.net
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+bou...@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.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug._______________________________________________
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs
