Sample Rate Switching for Applications that hold Audio Sessions
PipeWire's automatic sample-rate switching can be hindered by applications that maintain idle audio sessions, preventing switching to the highest active sample rate on normal multi-tasking desktop use. This is especially problematic for applications like Discord, TeamSpeak, RDP, and VNC connections, which often lack internal mechanisms to release the audio device when inactive, even when they don't actively output anything to the sink (0 gain).
Setup:
I have configured pipewire and wireplumber to allow switching sample rates via providing multiple options via the "default.clock.allowed-rates" and "audio.allowed-rates" config options.
When I just have a media player open and play songs with different sample rates (44.1kHz, 48kHz, 96kHz,...), the DAC correctly switches between frequencies and there is no resampling on Pipewire's end.
The problem now occurs, when other common applications like Discord, TeamSpeak, FreeRDP, Chrome,... these applications keep an idle audio session open to the sink, preventing switching to the currently highest used sample rate.
Considerations:
- I know that this is the applications fault, but this is a thing that will never be fixed on many of these everyday applications, resulting in Pipewire and Wireplumber not being able to work as intended.
- Some applications, like music and video production suites might benefit from being able to control or get the sample rate that the media is produced in, while not being hindered by other applications that might also be running on the system.
Current Limitations:
- No Prioritization: PipeWire lacks a mechanism to prioritize certain clients/applications for determining the overall system sample rate.
- No Idle Timeout: There's no built-in method to automatically suspend or disconnect audio sessions based on true inactivity (lack of output).
Feature Request Suggestion:
Implement either or both of the following features in PipeWire:
-
Client Prioritization for Sample Rates:
Allow users to assign priority levels to audio clients. Higher-priority clients would exert greater influence over the dynamically chosen sample rate. -
Automatically change sample without consideration for other clients: Introduce a setting that ignores that other clients are already connected and always sets the best/highest sample rate for the clients connected. In combination with 1., this might be an elegant solution to keep specific applications in absolute control of the current sample rate.
-
Gain-Based Idle Session Management:
- Include a method to monitor audio output gain of client sessions.
- Automatically suspend audio sessions that fall below a configurable gain threshold for a specified period, indicating true inactivity.
- Allow graceful reconnection of suspended sessions when the client resumes audio output.
This solution might be cool as well, but 1. and 2. would be easier to implement, while also allowing for further customization through user scripts.
- Something else, because both of these might be unproper solutions - I'm pretty new to Pipewire and WirePlumber myself.