HDMI audio on Raspberry Pi with SDL2/KMS backend

[MichaIng]

I was made aware of a regression when using the SDL2 graphics backend instead of DispmanX:

• One needs to enable the full KMS display driver via dtoverlay=vc4-kms-v3d
• This forcefully disables the firmware/bcm2835 HDMI audio driver, and replaces it with one provided by the KMS driver, which appears as vc4hdmi in aplay -l.
• This vc4hdmi sound device however only supports the IEC958 audio format. The libasound2-data package, provided by the Raspberry Pi repository, provides a configuration file /usr/share/alsa/cards/vc4-hdmi.conf, which sets up the default and sysdefault ALSA PCMs for this sound card with an ALSA plugin and configuration, which does the needed IEC958 audio conversion.
• In the Amiberry GUI, hence what is detected by SDL2, one can however not select ALSA PCMs, like default, shown when using aplay -L, but only hardware sound cards, shown via aplay -l. The latter bypass and ALSA configuration and plugins, and hence cannot work with KMS HDMI audio, as long as the audio source does not do provide the stream in IEC958 format.
• I tried to manually override the kernel parameter to have the bcm2835 HDMI audio driver enabled, even when KMS is enabled, but this does not work, as KMS and this HDMI audio driver break each other, basically confirming the reason why it is forcefully disabled since a while: bcm2835-audio HDMI device is not present on Pi 4 running with KMS and VC4 HDMI devices disabled raspberrypi/linux#4651

I am not sure whether or what can be done on Amiberry side, or whether playing audio through ALSA PCMs is a feature which would need to be added to SDL2? Maybe someone knows more or has an idea.

For now, as far as I can think of, HDMI audio is impossible with Amiberry on Raspberry Pi, when building with SDL2 backend and full KMS. One would need to use DispmanX, but AFAIK, Raspberry Pi OS Bookworm, respectively the new kernel/firmware packages, do not provide the required libraries anymore.

[solskogen]

Install pulseaudio.

…

On Tue, Mar 12, 2024, 21:52 MichaIng ***@***.***> wrote: I was made aware of a regression when using the SDL2 graphics backend instead of DispmanX: - One needs to enable the full KMS display driver via dtoverlay=vc4-kms-v3d - This forcefully disables the firmware/bcm2835 HDMI audio driver, and replaces it with one provided by the KMS driver, which appears as vc4hdmi in aplay -l. - This vc4hdmi sound device however only supports the IEC958 audio format. The libasound2-data package, provided by the Raspberry Pi repository, provides a configuration file /usr/share/alsa/cards/vc4-hdmi.conf, which sets up the default and sysdefault ALSA PCMs for this sound card with an ALSA plugin and configuration, which does the needed IEC958 audio conversion. - In the Amiberry GUI, hence what is detected by SDL2, one can however not select ALSA PCMs, like default, shown when using aplay -L, but only hardware sound cards, shown via aplay -l. The latter bypass and ALSA configuration and plugins, and hence cannot work with KMS HDMI audio, as long as the audio source does not do provide the stream in IEC958 format. - I tried to manually override the kernel parameter to have the bcm2835 HDMI audio driver enabled, even when KMS is enabled, but this does not work, as KMS and this HDMI audio driver break each other, basically confirming the reason why it is forcefully disabled since a while: raspberrypi/linux#4651 <raspberrypi/linux#4651> I am not sure whether or what can be done on Amiberry side, or whether playing audio through ALSA PCMs is a feature which would need to be added to SDL2? Maybe someone knows more or has an idea. For now, as far as I can think of, HDMI audio is impossible with Amiberry on Raspberry Pi, when building with SDL2 backend and full KMS. One would need to use DispmanX, but AFAIK, Raspberry Pi OS Bookworm, respectively the new kernel/firmware packages, do not provide the required libraries anymore. — Reply to this email directly, view it on GitHub <#1241>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHY72DHP634DUQCGJGQP6LYX5THFAVCNFSM6AAAAABES62SSSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE4DENRUHA4TANI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[MichaIng]

I actually want to avoid that, since our audio config uses plain ALSA. PulseAudio does all the IEC958 conversion, and SDL2 detects the PA PCMs which do that (when you build SDL2 with PulseAudio support)?

[solskogen]

Then you're on your own :-)

[MichaIng]

Using ALSA PCMs is not exactly something exotic 😉. People use PulseAudio (which is also just an ALSA wrapper) to avoid complex ALSA configurations, but in this case, the complex configuration file already exists, and the default ALSA PCMs are set. Amiberrry/SDL2 just needs to pick "default", instead of allowing to choose between "hw:0" and "hw:1" only (respectively their beautified names), what it practically allows now. If I am not all mistaken, also PulseAudio provides just ALSA PCMs in the end, but probably also another API to access/control them, not sure.

So I am quite sure, if this is really only at SDL2 end, a feature which does either already exist and just needs a certain build flag, or can be relatively easily implemented. But I want to make sure that really Amiberry does nothing else than leveraging SDL2 for a list of audio devices, and that the API is uses for this does not allow to select between raw sound cards and (ALSA) PCMs already.

[midwan]

@MichaIng
Amiberry doesn't do anything special in this regard. It enumerates all the available sound devices through SDL2, and lists them in the dropdown, having the first one found as the selected one. Whatever you pick there is then used to initialize that device, and use it for audio output.

[MichaIng]

Hmm, do you use https://wiki.libsdl.org/SDL2/SDL_GetNumAudioDevices and https://wiki.libsdl.org/SDL2/SDL_GetAudioDeviceName? ... yes I see it already. Indeed, this seems to get the devices/cards, but not the ALSA PCMs.

There seems to be a hint: https://wiki.libsdl.org/SDL2/SDL_GetDefaultAudioInfo#remarks

Some (but not all!) platforms have an isolated mechanism to get information about the "default" device. This can actually be a completely different device that's not in the list you get from SDL_GetAudioDeviceSpec(). It can even be a network address! (This is discussed in SDL_OpenAudioDevice().)

And: https://wiki.libsdl.org/SDL2/SDL_OpenAudioDevice#remarks

Passing in a device name of NULL requests the most reasonable default (and is equivalent to what SDL_OpenAudio() does to choose a device). The device name is a UTF-8 string reported by SDL_GetAudioDeviceName(), but some drivers allow arbitrary and driver-specific strings, such as a hostname/IP address for a remote audio server, or a filename in the diskaudio driver.

So maybe passing a device name NULL will make it use the "default" or "sysdefault" ALSA PCM, and similarly passing "default" or "sysdefault" as device name might work.

[midwan]

@MichaIng
That might work.

But of course, we want to be able to choose the audio device also, as there are many cases where the users have more than one.
Currently, the "default" (NULL) is used if all else fails to open, as a fallback. But I think I could add a special entry in the dropdown, which when selected would use "NULL" instead of the device name.

Not sure if that will solve your problem, but it should be safe to try at least. :)

[midwan]

@MichaIng
Test after the latest commit above please. There's a new checkbox in the Sound panel, when that is enabled it will initialize the OpenAudioDevice with nullptr, which might do the trick :)

[MichaIng]

Many thanks, I compiled it and gave it our user to test.

Btw, is there some free Kickstart ROM and application/game/demo I can use for testing, which runs well on RPi 1/Zero? I just used some random ROM and Prince of Persia game, but it runs horribly slow. I have really no knowledge about Amiga hardware, whether/which requires less host CPU power to emulate and which game likewise. And I am pretty sure that the one I use is no legal. I tied this demo with the builtin AROS ROM, but I land in a console, stating that "runme.exe" is not executable. Actually the zip of the demo does not even contain such file, but an agt-driftwood.exe: https://ada.untergrund.net/?p=demo&i=954

However, the Prince of Persia game did produce some sound, so I guess it works.

[giantclambake]

@MichaIng --- Stunt Car Racer is worth a try ; seems to run fine with included AROS rom

[midwan]

@MichaIng
FYI, a Pi1/Zero is too slow for most cases, it will struggle with everything but the most simple things for Amiga emulation. I'd say minimum would be a Pi3, and the faster the better if you're looking to get smooth 50Hz emulation in the most demanding cases.

[MichaIng]

Thanks for the hint, I'll at least give Stunt Car Racer a try on the RPi Zero W. If it does not run smooth either, I'll switch to Raspberry Pi 5 for Amiberry testing then. The Zero W ist just much simpler and quicker to spin up on any USB port, while the Raspberry Pi 5 is quite larger/heavy, requires a dedicated PSU etc 😄.

[MichaIng]

Okay great, the user with the HDMI audio problem finally also reported that it works for him. One needs to take care to disable the Broadcom audio driver via dtparam=audio=off in config.txt or at least disable analogue audio with snd_bcm2835.enable_headphones=0 in cmdline.txt. Else the default audio device will be the 3.5mm jack.