"An unbaked sound-mixer slot resolves to null and plays nothing — silently"

• Every loop and one-shot sound in the game is a silent no-op, yet the audio call stack looks fully wired: the emitter fires, the mixer resolves, play is invoked.
• The console is completely clean — no error, no warning, nothing in the chain logs a failure.
• If you add a debug line that prints a real volume / playing-state pair, it reports playing 0 on every actor; a debug line that sits after the null-handle guard never prints at all.

This applies to a project-authored sound-mixer / catalog layer — a system that bakes a set of picks and resolves a named slot to a concrete sound at play time. (This is a different system from the engine's own built-in Mixer class with its Master / Default / Voice buses — same word, unrelated behavior. Don't conflate a baked-slot failure with an engine mixer-routing question.)

Two things combine into a silent mute:

1. A slot with no baked pick and no fallback event resolves to null. If none of a catalog's slots have a baked selection (and no legacy fallback event is set), resolving a slot returns an empty result. The play wrapper returns null before it ever reaches the engine's real play call — so nothing plays, and nothing logs, because the failure happens above the engine boundary.
2. Slot ids are never validated. A typo'd slot id parses, stores, and resolves to nothing, with no warning at any layer. There is no "unknown slot" diagnostic to catch a mistake.

A clean console is therefore not evidence that a slot resolved to anything real.

When audio is missing from an otherwise-working stack and the console is silent, check the mix layer before suspecting the caller, the emitter, or the mixer routing:

• Confirm the mix has actually been baked for the slot you're playing. An unbaked catalog resolves every slot to null.
• Confirm a fallback exists (a legacy event or a default) for slots that may not have a baked pick.
• Verify the slot id against the catalog — because ids aren't validated, a typo silently resolves to nothing.

Add a diagnostic at the resolve boundary so a null resolution is loud, not silent:

var pick = catalog.Resolve( slotId );
if ( pick is null )
{
    Log.Warning( $"Audio slot '{slotId}' resolved to nothing — unbaked mix or bad id?" );
    return;
}

The mute happens above the engine's play call: the project wrapper short-circuits on a null resolution and returns before the engine is ever asked to make sound, so none of the engine's own logging runs. The only place that knows the slot failed is the resolve step — so that's where a diagnostic has to go. Baking the mix (or supplying a fallback) gives the slot a concrete pick to return, and logging a null resolution turns an invisible failure into an obvious one.