HDMI Audio sink lost/renumbered during resolution handshake on AMD Ryzen (Renoir chipset)

[Pinovski]

Batocera build version

41 batocera

Your architecture

x86_64 (AceMagician Mini PC with AMD Ryzen 5)

Your Graphic Processor Unit(s) (GPU)

Integrated AMD Radeon Graphics (Renoir)

Issue description

On an AMD Ryzen Mini PC (Renoir audio chipset), the HDMI audio output device is lost or re-indexed when transitioning from EmulationStation to an emulator.

The issue appears to be caused by the HDMI handshake (screen flicker/black screen) when the resolution changes between the Menu (1080p) and the Emulator (Native/Auto). During this brief signal negotiation, Linux detects a disconnect of the HDMI sink. When the video returns, the audio system fails to restore the previous HDMI sink, defaulting to "Auto" or a dummy output, causing a total loss of game audio until a reboot or manual re-selection.

Detailed reproduction steps*
Boot Batocera with es.resolution=1920x1080 set (default behavior).

Ensure Audio Output is set to "Renoir" (HDMI).

Launch any emulator (NES, SNES, N64, etc.) where the resolution is NOT globally forced (i.e., defaults to "Auto" or native resolution).

Observe: The TV/Monitor performs a handshake (screen goes black for 1-2 seconds) to switch resolution.

Result: Upon game start, audio is silent. Checking system status shows the HDMI audio sink is missing or has become invalid.

Secondary Effect: Loading Save States created while the audio was working causes an immediate crash/freeze of the audio driver, as the state references a hardware index (e.g., Card 0) that has shifted or disappeared.

I want to provide more technical detail on why this is a critical failure for the user experience, especially regarding Save States.

When the HDMI handshake occurs, the system doesn't just lose audio; it fails to re-associate the physical PCI address with the original audio sink. Instead, PulseAudio/PipeWire instantiates a new virtual sink every time the connection is re-established, incrementing the index (e.g., from alsa_output...sink to sink.2, sink.3, and so on).

The "Poisoned" Save State Issue: This "sink multiplication" is what causes the save state crashes I mentioned. When a save state is loaded in RetroArch, it expects the audio driver to be pointing to the exact device index/name that was active when the state was saved. Because the system has moved the HDMI audio to a new "sink.X" index, the audio pipeline breaks immediately upon loading the state. This results in:

Complete audio silence until the emulator is restarted.

In many cases, a total crash of the audio driver requiring a system reboot.

By forcing global.videomode=1920x1080, we are essentially bypassing a major bug in how the Renoir audio driver or the kernel handles sink persistence during display mode switches. Without this forced resolution, the system's audio mapping becomes a "moving target" that RetroArch cannot follow.

Detailed reproduction steps

Tried: Changing audio drivers (alsa, sdl2, pulse). Pulse is currently active but did not solve the disconnect issue alone.

Tried: Custom scripts (xset -dpms, etc.) to prevent HDMI sleep. Did not resolve the handshake disconnect.

Workaround Found (Current Fix): Adding global.videomode=1920x1080.60.00 to batocera.conf.

Logic: By matching the emulator resolution to the ES menu resolution, the TV never renegotiates the signal (no handshake/black screen). Because the link remains active, the HDMI sink is never "lost" by the OS, and the persistent PCI address (alsa_output.pci-0000_05_00.1.HiFi__HDMI1__sink) remains valid.

Details of any attempts to fix this yourself

audio Drivers: Tried switching between alsa, sdl2, and pulse drivers in batocera.conf. While pulse (global.retroarch.audio_driver=pulse) improved stability slightly, it did not prevent the HDMI sink from disconnecting during resolution changes.

Power Management: Attempted to use custom.sh scripts with xset -dpms commands to prevent the screen/audio from sleeping, but this did not solve the issue caused by the handshake.

Resolution Locking (Successful Workaround): I discovered that the HDMI audio sink was dropping specifically during the "black screen" handshake when launching a game. I modified batocera.conf to force global.videomode=1920x1080.60.00. This matches the ES menu resolution, preventing the display mode switch. Since applying this, the HDMI audio device (alsa_output.pci-0000_05_00.1.HiFi__HDMI1__sink) remains persistent and audio works correctly.

Details of any modifications you have made to Batocera.

I have manually edited /userdata/system/batocera.conf to include the following lines to mitigate the issue:

Ini, TOML
global.retroarch.audio_driver=pulse
es.resolution=1920x1080.60.00
global.videomode=1920x1080.60.00
(No other system modifications or custom kernels were used).

Logs and data

I am attaching the relevant configuration that stabilized the system. Hardware: AceMagician Mini PC (AMD Ryzen 5 / Renoir Chipset). Relevant batocera.conf settings:

Ini, TOML

Force PulseAudio

global.retroarch.audio_driver=pulse

Force Resolution to avoid HDMI Handshake/Disconnects

es.resolution=1920x1080.60.00
global.videomode=1920x1080.60.00

Persistent Audio Sink (Generated by system after resolution fix)

audio.device=alsa_output.pci-0000_05_00.1.HiFi__HDMI1__sink
audio.profile=HiFi@alsa_card.pci-0000_05_00.1

[DubaiShark]

That's an old version. Have you tested V42, V43, or the V43 ZEN3 butterfly builds to check if the issue exists?

[Pinovski]

That's an old version. Have you tested V42, V43, or the V43 ZEN3 butterfly builds to check if the issue exists?

Thanks for the suggestion. To clarify, I am currently staying on v41.

I actually tried v42 initially, but I encountered a different, persistent issue that forced me to downgrade: the physical power button wouldn't shut down the system correctly (it would either hang or take an extremely long time to shut down), which was very annoying and confusing. I tried modifying BIOS settings to fix this behavior but had no luck.

I did some research (and used AI to analyze the symptoms) which suggested it might be a kernel-level issue regarding ACPI/power management specific to this AceMagician hardware, though I couldn't confirm it 100%.

Do you think v43 or the v43 ZEN3 builds might handle the kernel/power management differently enough to avoid this shutdown bug? If there's a good chance it's fixed, I can try flashing it to test if the HDMI audio issue persists there.

[joinski1]

Do you think v43 or the v43 ZEN3 builds might handle the kernel/power management differently enough to avoid this shutdown bug?

Try it and let us know

[DubaiShark]

That's an old version. Have you tested V42, V43, or the V43 ZEN3 butterfly builds to check if the issue exists?

Thanks for the suggestion. To clarify, I am currently staying on v41.

I actually tried v42 initially, but I encountered a different, persistent issue that forced me to downgrade: the physical power button wouldn't shut down the system correctly (it would either hang or take an extremely long time to shut down), which was very annoying and confusing. I tried modifying BIOS settings to fix this behavior but had no luck.

I did some research (and used AI to analyze the symptoms) which suggested it might be a kernel-level issue regarding ACPI/power management specific to this AceMagician hardware, though I couldn't confirm it 100%.

Do you think v43 or the v43 ZEN3 builds might handle the kernel/power management differently enough to avoid this shutdown bug? If there's a good chance it's fixed, I can try flashing it to test if the HDMI audio issue persists there.

The same answer applies as above.