Context With PipeWire in Pro Audio mode, the Focusrite Clarett exposes a multi-channel capture source (many inputs, no UCM “mic” semantics). This is correct and intentional.
What Firefox does by default
Firefox’s WebRTC (getUserMedia) tries to negotiate audio formats dynamically. When it sees a multi-channel PipeWire source, it:
- Tries to open audio with varying channel counts (mono, stereo, etc.)
- Fails to settle on a stable format with a pro, multi-channel source
- Retries repeatedly
Due to a bug in Firefox’s WebRTC / cubeb backend, each failed retry leaks PipeWire audio streams, causing:
- rapidly increasing PipeWire nodes
- growing Firefox memory usage
- the issue stopping only when Firefox is fully closed
What the setting does
media.getusermedia.audio.max_channels = 1
Forces Firefox to only ever request mono audio from PipeWire.
Why this works
- PipeWire can immediately provide a valid mono stream (input 1)
- No format negotiation loop occurs
- Firefox stops retrying
- No leaked streams are created
Result
- Microphone works normally in all WebRTC sites
- Pro Audio profile remains correct
- PipeWire graph stays stable
- No extra sinks or virtual devices needed
Summary (one line)
Firefox leaks PipeWire streams when negotiating multi-channel capture devices; forcing mono input avoids the negotiation bug and stabilizes WebRTC audio.