Line references are pinned to main at bac2f765.

Pre-existing on main. Not introduced by #368 — that PR moved the mixer into audio::output::mix_bus unchanged, so do not bisect to it.

Where

src-tauri/src/audio/output/mix_bus.rs L15-17 (mix_stem_resampled), with the same early return in the linear path at L86-88. Callers: src-tauri/src/audio/output/mod.rs L209 and L396, plus the crossfade loop in crossfade_render.rs L94-116.

What goes wrong

mix_stem_resampled reports "nothing rendered, nothing consumed" when the master gain is exactly zero:

// mix_bus.rs L15-17
if gain == 0.0 {
    return (0, 0);
}

The second element of that tuple is the source-frame advance. The render path feeds it straight into the transport clock:

// mod.rs L396
playback.advance_render_frame(src_frames_advanced);

master is snapshot.volume (mod.rs L155) and set_volume clamps into 0.0..=1.0 (audio/playback.rs L411-412), so a user dragging the slider to the bottom produces exactly 0.0. With that, render_frame never advances: the reported position freezes, the track never reaches EOF, so no natural end, no gapless swap and no advance to the next track — while the state snapshot still says playing. Restoring the volume resumes from the frozen position, as if the elapsed silence never happened.

The per-stem mixer in the same file already gets this right, and says so:

// mix_bus.rs L447-452
let gain = gains.get(i).copied().unwrap_or(0.0);
if gain == 0.0 {
    // Muted: still advances with budget (lockstep).
    continue;
}

That invariant (referenced in the file as the core of issue #143) is applied to muted stems but not to a zero master gain.

Conditions

Master volume set to exactly 0 during playback, on the non-stem path. A near-zero-but-nonzero volume behaves correctly, which is why this is easy to miss.

Effect

Playback silently stalls at zero volume: position stops, autoadvance never happens, and the UI keeps claiming the track is playing.

Not fixing here

Filed for tracking only.