On modern Linux distributions where PipeWire is the default audio server (e.g., KDE Neon, Fedora, recent Ubuntu versions), Firefox currently defaults to the pulse-rust audio backend. This forces communication through the PipeWire-Pulse compatibility layer (pipewire-pulse), resulting in unnecessary overhead and higher latency compared to a native PipeWire connection.
Evidence from User System:
The system uses PipeWire as the main audio server.
The application status from about:support confirms the use of the legacy protocol: Audio Backend: pulse-rust.
The pactl list sink-inputs command confirms the use of the bridge: client.api = "pipewire-pulse".
Observed round-trip latency is high, which is typical for bridged connections: 73.63ms (found in about:support).
User Attempts (Failed to Force Native Backend):
We attempted to manually configure the native PipeWire backend via about:config:
Set media.cubeb.backends to pulse,pipewire,alsa (String).
Set media.peerconnection.webrtc.disable_pulseaudio to true (Boolean).
Result: These preferences did not successfully switch the browser to the native PipeWire backend, demonstrating that the current Firefox build prioritizes PulseAudio regardless of user settings.
Request:
We kindly request that the Firefox development team consider one of the following for Linux builds where PipeWire is detected:
Set the native PipeWire backend as the default audio choice.
Ensure that modifying the media.cubeb.backends preference successfully forces the use of the native PipeWire backend (pipewire) over the PulseAudio protocol (pulse-rust).
Lowering the latency is critical for media consumption and real-time communication (WebRTC). Thank you.
