2034333 - Slow cubeb operations in the AudioIPC server event loop stall content-process cubeb RPCs

Status: ASSIGNED

(Core :: Audio/Video: cubeb, defect, P3)

Description

[Matthew Gregan [:kinetik]]

The content-process cubeb API (context, stream) is implemented as a set
of synchronous RPCs to the AudioIPC server in the parent process. The
server runs its event loop single-threaded (tokio), so any slow
operation within that loop — e.g. a WASAPI device enumeration, a
PulseAudio reconnect, or a cubeb backend call that takes hundreds of
ms to seconds in the wild — serialises all client RPCs queued behind
it.

Symptoms observed in the field include:

• Main-thread stall during new AudioContext() via
  CubebUtils::MaxNumberOfChannels (bug 1553653, "Massive jank under
  CubebUtils::MaxNumberOfChannels when refreshing talky.io").
• MDSM blocking for seconds on audioipc_client::stream::position
  during playback (see bug 1657146 profile 2).
• MediaTrackGraph monitor contention cascades when MDSM can't make
  progress.

Root cause isn't specific to any single cubeb API — the server event
loop has no bounded budget for handling individual RPC requests, and
clients have no alternate path for quickly-cached or less-critical
queries.

This is distinct from bug 2024498 (AudioIPC connection-creation blocking
the parent main thread) and bug 1430704 (avoid calling cubeb from the
Gecko main thread); even with both of those resolved, a slow server
backend call would still stall client RPCs on whatever thread made
them.

Tracking upstream at mozilla/audioipc#187. Filing this Gecko-side
tracker so individual symptom bugs can depend on it.