[pulseaudio-discuss] 98766: Bug and bounty to improve HDMI handling in PA

[Manuel Amador (Rudd-O)]

From https://bugs.freedesktop.org/token.cgi?t=yKdSDlY31y

PulseAudio should block display DPMS when playing audio on HDMI devices

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

-- 
    Rudd-O
    http://rudd-o.com/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20160919/109b9060/attachment.sig>