GNOME Bugzilla – Bug 656674
Need to handle passthrough support
Last modified: 2021-06-09 16:12:19 UTC
With the next releases of PulseAudio (1.0) and gst-plugins-good (0.10.31), we're going to have the ability to have passthrough streams transparently to applications. To deal with this, we need some additions to the Sound preferences: 1. The ability to select formats users' A/V receivers support. To start with, it should be sufficient to allow users to select one more more of AC3 (Dolby Digital), E-AC3 (Dolby Digital+) and DTS (PulseAudio can support more formats (like MP3), and yet more will need to be supported in GStreamer and PA (DTS-HD, Dolby TrueHD), but this should suffice for now). It might also be useful to have a "parent" check-box to enable/disable passthrough support in one shot. API to do this is provided by module-device-restore -- see pulse/ext-module-device-restore.h and the pavucontrol implementation at: http://cgit.freedesktop.org/pulseaudio/pavucontrol/commit/?id=479e7bcd6eb283750ee13d2270610d6d814add08 http://cgit.freedesktop.org/pulseaudio/pavucontrol/commit/?id=5c19f6b5d28566462d62bcc02221809a1c9b91aa 2. Grey out stream and sink volume sliders if a passthrough stream is active (preferably with some UI hint so the user knows what's happening). From API side, when a new sink input turns up, you can run pa_format_info_is_pcm(info.format) to know if the sink input is raw or compressed, and then use the same pa_sink_input_info to find the corresponding sink to grey that as well. 3. IMO it would be good if the above was also available as a UI hint in the volume control icon in the gnome-shell top-bar. At some point, it might be useful to have a way to enable/disable it quickly there as well.
> we're going to have the ability to have passthrough streams transparently to > applications. Can you describe this in some more detail ? What is the mental model that a user should have of 'passthrough streams' ? Or us developers, for that matter ?
(In reply to comment #1) > > we're going to have the ability to have passthrough streams transparently to > > applications. > > Can you describe this in some more detail ? What is the mental model that a > user should have of 'passthrough streams' ? Or us developers, for that matter ? From developers' perspective, the objective is to not think about passthrough at all. Or, at most, to use a special audio sink with playbin2 that transparently handles the presence or lack of support for compressed audio. The idea is that the underlying bits (GStreamer/PulseAudio/...) take care of all this for you, and each application that needs it doesn't reinvent its own UI for passthrough mode. (In more detail, when playbin2 gets a compressed format that pulsesink/PA /might/ support, it will try to plug in pulsesink without a decoder to see if the sink might support compressed audio directly, and if that fails, it plugs in a decoder). From users' perspective, I'd also have liked it to be only a matter of selecting the digital profile in sound preferences (and eventually make even this unnecessary), select what formats the receiver supports (in most do this only once, and that's it. However, if any other streams are connected (in my case it's usually Rhythmbox or the Flash plugin), you can't really make a passthrough connection and user intervention is required. To deal with this problem, I think we should do something like this -- when a passthrough stream is rejected because other PCM streams are active, we emit an event from PA and there would need to be a UI hint or notification allowing the user to do something about it (we could just kill the streams, but that would make Flash not output audio any more on Firefox till you restart, so probably something like a list of "blocking" applications for him/her to close) There's a work-in-progress gstreamer element that can automatically switch to passthrough mode if the sink changes, etc. I need to polish it up, and push it out, but with that plus the UI above, the player can be made to automatically switch to passthrough mode once the blocking streams go away. With these pieces in place, IMO we'll have a pretty pleasant user/developer experience for passthrough support.
Without thinking too deeply about it, this sounds to me like something that should just be handled transparently behind the scenes. As a user, I don't want to think about how my audio streams are routed and transcoded, I just want the best possible audio quality. Adding UI for manually tweaking these low-level details doesn't feel right to me. We should just wait until the infrastructure (that gstreamer element you were talking about) is in place to handle this properly.
The gstreamer element will make for a smoother experience, but it still doesn't do away with the need for user intervention. Users who have the hardware to handle compressed audio (and who have explicitly enabled support by picking the formats their receiver supports) would likely want to know what is preventing the functionality from being used.
Created attachment 194543 [details] pavucontrol format selection UI Just as a reference, attaching what the pavucontrol format selection UI (in git master) looks like.
Those checkboxes only turn up if the sink supports setting formats (can be determined during introspection). So these UI changes should only ever show up for people who have the required hardware (and, for now, explicitly enable it by selecting the digital profile). This will become more common as more devices start shipping with HDMI output, but that's a can of worms that we should deal with when HDMI support is better in lower levels of the stack (at the very least, getting ELD information and maybe even having some infrastructure to determine whether to respect it or not).
Mass reassign, sorry for the noise.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new bug report at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/ Thank you for your understanding and your help.