[JayBeest]

Fixes the "completely silent on some systems" reports — #19 (Batocera /
32-bit PipeWire), #67 (Linux: No Audio on Arch with kernel "7.2.11-zen1-1-zen" using PipeWire audio) and (might not) #56 (Windows 11, all-zero sdlaudio.raw).

Symptom

The game runs, renders, responds to input, and produces no sound at all.
Music and SFX are both at 100%. The log looks healthy, because the only audio
line it prints is:

ge: audio: global volumes - music 100%, sound 100%

On Linux the failure also leaves a trail, because an SFX event queue that is
never drained eventually reports itself:

ge: snd: evtq FULL - 256 queued (254 due now) | pan 0 vol 0 play 18 decay 0
stop 0 end 0 other 238 | states 21 live, 0 voiced, 0 waiting for a voice
(0 of 16 voices) | heartbeat alive | coalesced 0 evicted 0 dropped 3328
ge: snd: event queue FULL - dropped event type 1024 (drop #3329)

That line is the whole diagnosis, and the numbers in it are exact:

• 256 queued is this build's queue capacity, not a round number:
  MUSIC_SFX_SEQ_CONFIG_MAX_EVENTS (0x40) × MUSIC_POOL_SCALE (2) ×
  MUSIC_SFX_EVENT_HEADROOM (2) = 256. The census only prints on a drop,
  so 256 means 100% full.
• 254 due now — the events are ready to run and nothing is running them.
• 0 voiced, 0 of 16 voices — no synth voice was ever allocated.
• heartbeat alive — the game thread is still posting happily.

Sound is not quiet. The synthesizer was never executed.

Root cause

portAudioPump() (port/src/audio_pc.c) is the only thing that runs the AL
synthesizer: alAudioFrame() is the sole caller of every AL client handler
(src/libultra/audio/synthesizer.c:189), so the SFX player's event queue, the
sound-state list and all three music sequencers advance only when the pump
renders. The synthesizer's clock is the game's audio clock.

The pump had three one-way exits, and two of them let the audio device decide
whether that clock runs at all:

if (s_AudioDead) return;                                        // permanent
if (SDL_GetQueuedAudioSize(dev) >= PORT_AUDIO_QUEUE_LOW) break; // per pump

So a device that cannot be opened — or that opens and then stops consuming —
freezes the entire audio subsystem, and the event queue saturates exactly as
logged above. s_AudioDead was set on any SDL_OpenAudioDevice failure and
never cleared, and the failure path printed nothing: no SDL_GetError(), no
driver name, no obtained format. This was the only SDL subsystem in the port
that failed without logging (input_pc.c:2119, video.c:5156,
raphnet.c:289 all log).

That is also why the reports are machine-specific while the code is not. The
port asks for an exact 22050 Hz / s16 / stereo device with
allowed_changes = 0. Almost no system has that natively; it works only
because the backend converts behind SDL's back — WASAPI AUTOCONVERTPCM,
CoreAudio, ALSA plug, PulseAudio/PipeWire resampling. Where that layer is not
reachable from a 32-bit client (the Batocera report), or the endpoint refuses
the spec, the open fails and the game goes permanently and silently mute.
Machines where audio works never touch either exit, which is why this survived
so much testing.

Changes

Both are in port/src/audio_pc.c.

1. Device setup is logged and retried, not fatal

portAudioInit() now returns success/failure and reports why on every exit
that leaves the game mute — the operation, SDL_GetError(), the current audio
driver, the attempt number, and the retry cadence. A successful open logs the
driver and the obtained spec:

ge: audio: device open - driver pipewire, 22050 Hz, 2 ch, 512 samples, 4096 byte buffer
ge: audio: SDL_OpenAudioDevice(22050 Hz, s16, stereo) failed (SDL: ...; driver none) -
    no output, attempt 1, retrying every 2000 ms

s_AudioDead is gone. The pump retries every PORT_AUDIO_RETRY_MS (2 s), so a
sink that appears or changes after boot is picked up: a USB headset plugged in,
a PipeWire restart, a 32-bit client stack that was not up yet. Failures are
rate-limited (first, then every 30th) so a permanently mute machine cannot bury
the rest of the log.

2. The render pace is wall time, and the device can no longer stall it

The pump now keeps an audio clock in samples owed (stored ×1000 to avoid
rounding a 147 Hz pump's fractional share of a 736-sample frame down to zero),
advanced by real elapsed wall time, clamped to 100 ms per pump so a debugger
pause or a long load cannot replay minutes of audio at once.

A frame is rendered when either:

• the clock owes a whole frame — this is what keeps game audio time honest with
  no device attached, and
• the playback queue is below PORT_AUDIO_QUEUE_LOW — the existing catch-up
  behaviour, unchanged, so a live DAC still sets the fine pace.

Neither branch can be blocked by the device. SDL_QueueAudio is still
skipped when the queue is over PORT_AUDIO_QUEUE_MAX; the frame is discarded,
not the render: the clock has already advanced, so dropping it costs sound, not
sequencer time.

Also fixed while here: portAudioPumpForce() now renders exactly one frame, as
its comment always claimed. The old code bypassed the queue gate per iteration,
so a forced call could render up to 8 frames, and music.c's stop-wait spins it
up to 512 times.

3. A sink that opens and never consumes is detected

The second mute shape: the device opens, the queue never drains, the top-up
stops, and nothing plays again. An unmoving full backlog for
PORT_AUDIO_STALL_PUMPS (~1 s) now closes the device and lets the retry path
reopen it, logged and rate-limited. This is the one heuristic piece here — it
is deliberately conservative (queue at the cap and byte-identical across
pumps), but it is the part most worth watching in field reports.

What this does not change

• The healthy path. Queue-driven catch-up is still there; the wall clock only
  adds a floor, so a machine where audio already works renders at the same
  rate as before.
• The 22050 Hz / s16 / stereo requirement with allowed_changes = 0. Accepting
  a device rate would need an SDL_AudioStream in front of the synth, because
  audi.c:344 bakes the rate into g_FrameSize. That is the natural follow-up
  (see below), not part of this patch.
• portAcmdRun's whole-frame validation bail-out (port/src/audio_pc.c,
  portAcmdValidate), which can silently discard every frame of a run. It only
  reports through GE_DUMP_BOND, so it stays invisible in normal logs. Flagged
  for a separate change.

Verification

What was checked:

• The file compiles clean with the exact flags and defines of the macOS build
  (-fsyntax-only, -std=gnu11 -arch arm64 -DGE_NATIVE_64=1 -DGE_VIDEO=1 ...,
  taken from that build's build.ninja). The unmodified file compiles clean in
  the same harness, so the comparison is meaningful.
• -Wall -Wextra produces no new diagnostics in the changed region; the only
  warnings are the pre-existing u32→pointer casts in the aspMain interpreter.

What was not checked, and should be before merge:

• No full build and no runtime test: this checkout is 32-bit-only upstream and
  the available machine is arm64 macOS, so the game was not run with this
  patch. Timing behaviour in particular (frame cadence at 60/120/147 Hz pumps)
  wants a real play session.
• The stall detector has not been exercised against a real stalled sink.

What to look for in a run log after this lands:

• ge: audio: device open - driver ... — confirms the sink and its real rate.
• ge: audio: ... failed ... retrying — the mute report now names its cause.
• The absence of ge: snd: evtq FULL on a machine with no audio — the game's
  audio clock should stay healthy even when nothing is plugged in.

Follow-ups

1. SDL_AudioStream fallback so a device that refuses 22050 Hz is accepted at
   its own rate instead of failing (open with
   SDL_AUDIO_ALLOW_FREQUENCY_CHANGE, stream 22050 → device rate).
2. Make portAcmdValidate's bail-out zero the frame and log unconditionally,
   so a garbage Acmd can never silently produce an all-zero run.
3. Trim the queue back to target instead of pinning at the cap, so a long
   session cannot accumulate fixed audio latency.

For reporters, after the build lands

# is a stream reaching the server at all?
pactl list short sink-inputs
SDL_AUDIODRIVER=disk ./ProjectMidas     # app-side isolation; writes sdlaudio.raw
python3 -c "d=open('sdlaudio.raw','rb').read(); print(len(d), sum(1 for b in d if b))"

Windows: SDL_AUDIODRIVER=disk ProjectMidas.exe, then check sdlaudio.raw
size and look for ge: audio: lines in Data/Logs/ge_direct.log. Before this
patch a mute system produced no ge: audio: line beyond the volume print; from
now on it produces a reason.

Type of Change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Other

How Has This Been Tested?

• Test on my own native macOS build. Sound works fine, then again, I cannot reproduce the issue in the first place..
• @ltm8plays-sudo tested the fix: audio works, they immediately found a new issue: bug: +- 100ms of audio delay - PP7 reload sound plays (almost) after animation finishes #71

Checklist

• My code has been thoroughly tested and is free of bugs
• I have performed a self-review of my code, not fully, I have to say, not a sound-expert here, then again I DO agree with the logic, and HAVE created functioning audio/video pumps before
• I have commented my code, particularly in hard-to-understand areas
• The commits I've made a clean, small and easy to understand
• My changes generate no compiler warnings
• My Code is AI-Generated or AI-assisted (Codewhale v0.10.1 <> DeepSeek V4.1-Flash-1017, heavily audited and directed by me.)
• My PR contains no AI-generated images, textures, models, sound or music (these are never accepted)
• I am an AI (please specify which AI model you are)
• I have reviewed my PR to make sure the above is truthful and accurate. I understand my PR can be rejected if it doesn't meet this project's standards.

[JayBeest]

Hey all, throwing this up as a draft because I know this touches the core audio pacing. I've verified the syntax compiles, but as noted, I couldn't reproduce the original mute bug on my Mac, so the stall detector and wall-clock logic haven't been stress-tested on a real Windows/Linux machine. I'm hoping the logging improvements alone are valuable enough to start a discussion on how to properly handle the audio device failures. Happy to iterate on the pacing logic if anyone has thoughts.

Edit: Oh god, I did it again, forgot to change branches...lemme try and clean up this mess...