Severe Performance Regression: mixer().clone() blocks 10-15 seconds in git version

[Infraviored]

Summary

Severe playback start latency after the first sound when using CPAL git master with Rodio 0.21.1: subsequent sounds begin audibly 10–15 seconds after we append them, even though our code path and logs complete instantly. crates.io CPAL 0.16.0 starts playback immediately.

Environment

• CPAL Version: git master vs crates.io 0.16.0
• Rodio Version: 0.21.1
• Rust Version: Latest stable
• Audio Backend: PulseAudio (Pipwire 1.0.5), (observed on Ubuntu 24.04.3 LTS)

Reproduction

Complete minimal reproduction case: https://github.com/Infraviored/cpal-a8269d3-miniexample

Steps to Reproduce

1. Create an OutputStream using rodio::OutputStreamBuilder::open_default_stream() and keep it alive globally.
2. On a hotkey press, decode a short WAV and append it to a sink created from the stream’s mixer.
3. First press plays immediately. Subsequent presses: logs and append complete instantly, but audio begins 10–15 seconds later.

Observability

We log just-before and just-after append; timestamps show append_dt_ms=0 (effectively instant). The audible start is delayed by 10–15s without any additional synchronous work on the calling thread.

Measurements

• First playback: immediate.
• Subsequent playbacks: 10,000–15,000 ms between “append complete” and audible start.
• No blocking observed in code paths: logging and returns happen immediately.

Analysis (best-effort)

• The latency is not in mixer().clone(); control returns immediately. The delay is in when the backend actually begins rendering audio after additional appends.
• On CPAL git master, sink creation/reuse or backend configuration appears to trigger very large output latency after initial playback. Potential causes include:
  1. More expensive device validation or reconfiguration occurring on (re)use.
  2. A high latency target or buffering behavior in the Pulse/ALSA backend after idle.
  3. Differences from 0.16.0 where device configuration/latency was smaller or cached.
• Workarounds attempted:
  • Caching the mixer: no change (still delayed audible start).
  • Prebuilt sink pool and forced reuse (stop + append): appends log as instant; audible start still late.
  • Persistent sink kept alive: prevented device suspend but resulted in no audible output when mixing silence + clip on our setup; still indicates backend behavior differences.

Impact

• Follow-up sounds in interactive apps (hotkeys, UI clicks, games) begin far too late to be usable, despite low-latency code paths and immediate returns.

Expected Behavior

• After the first sound, subsequent short sounds should begin audibly within a few milliseconds of append, as with CPAL 0.16.0.

[roderickvd]

Thanks for the report. Is this on pipewire? If so please follow #1033 where I expect this will be fixed soonish - not yet - by optimizing the drop wait time.

If not on pipewire I’ll have to think harder what could be causing this - I’ve not experienced it on native ALSA yet.

[Infraviored]

I am actually on PulseAudio (on PipeWire 1.0.5), should have mentioned that.
Than you so much already, i will follow the MR.
Will this MR result in a new crates release?

[roderickvd]

Yes please try it out. And yes, we’re doing a shakedown on these and other bugs before pushing a new crate release out of the door.