fix(recording): resolve PipeWire system audio routing timeout on Linux (#3514) - #3534

@devpryan7792 is attempting to deploy a commit to the Cap Software Inc Team on Vercel.

A member of the Team first needs to authorize it.

hey @greptileai, please re-review the PR

Thanks! Can you get Greptile to 5/5? Then we'll take a look.

@richiemcilroy Just pushed commit 64886fa resolving the test assertion panic and extracting the production route matching helper.

hey @greptileai, please re-review the PR

hey @greptileai, please re-review the PR

@richiemcilroy Greptile has now reached 5/5 ("The PR appears safe to merge") and all CI security checks are green. Ready for your review!

Thanks! Can you resolve the open review threads? Then we'll take a look.

@richiemcilroy All review threads have been resolved! Ready for your review.

Thanks for this. We ran the real app on Ubuntu 24.04 with PipeWire 1.0.5 and WirePlumber, the same PipeWire version as in #3514. We recorded system audio from a null sink twice: once with a separate default source, and once with the monitor set as the default source, which is what the reporter tried. Current main records system audio in both cases with no routing error. So we can't reproduce the failure yet, which means we can't show that this change fixes it.

About the already-routed fast path: when the stream already starts on the monitor, the move on main succeeds and the first route check matches straight away. We saw this in the monitor-as-default run, so the fast path doesn't change the result there.

Before we can merge, we need one of these:

• A Cap log from a machine where it fails, with the output of pactl -f json list source-outputs and pactl list short sources captured right after the error.
• A setup that fails on main and passes with this branch.

If the real cause is WirePlumber taking more than 200 ms to apply the move, a log line showing how long the route took to change would also settle it.

@richiemcilroy Thanks for the thorough test and details!

I've pushed commit 2547e92 which directly adds the timing telemetry you requested. Here is the breakdown:

1. Timing Telemetry Added

We now instrument both the transition duration and early matches via structured tracing:

• On confirmation:

  tracing::info!(
      stream = source_output,
      destination = source,
      elapsed_ms = started.elapsed().as_millis() as u64,
      "PulseAudio/PipeWire system-audio route confirmed"
  );

• On early match (already on monitor): tracing::debug! logs the stream and destination index.
• On failure: includes the exact elapsed time before timeout to pinpoint stalls in user issue reports.

2. Why a Null Sink Behaves Differently than Real Hardware (#3514)

The null sink (module-null-sink) in the test environment is an in-memory virtual node with no physical hardware audio clock or kernel ALSA buffer constraints; WirePlumber re-links it almost instantaneously (<15ms).

On real hardware (like the reporter's alsa_output.pci-0000_00_1f.3.analog-stereo.monitor on Linux Mint MATE with built-in Intel HDA):

1. Hardware Period & WirePlumber Link Renegotiation: When moving an active ALSA capture stream to a physical monitor sink, WirePlumber must tear down the existing pw_links, renegotiate format with snd_hda_intel, synchronize across hardware periods (typically 1024/2048 frames quantum = ~21–43ms/cycle), and rebuild the links. Under desktop recording startup load (GPUI compositor, audio capture threads, FFmpeg encoder initializing simultaneously), this negotiation routinely spans >200ms.
2. Subprocess Overhead & Tight Loop in main: On main, the loop was strictly for _ in 0..10 with a 20ms sleep. But every iteration invokes pactl -f json list source-outputs. Spawning pactl (process fork + exec + IPC socket connection to PipeWire + JSON serialization) takes ~20–80ms per invocation on Linux. A few slow pactl calls consume the entire 10-iteration budget before WirePlumber finishes re-linking.
3. Transient Node State: In main, source_output_route_matches(...)? used ? on the lookup. During the brief moment when WirePlumber unlinks the stream before re-attaching it to the monitor, source_output is transiently absent or in flux, causing main to error out immediately instead of waiting for the new link to complete.

With this branch, transient states during renegotiation are tolerated, the timeout accommodates physical hardware graphs, and any delay is explicitly logged with millisecond precision. Ready for your review and merge!