Source: faudio Severity: normal Tags: patch User: [email protected] Usertags: regression
After discussion with SDL upstream, I'm looking into what needs to happen for Debian (and indirectly Ubuntu) to replace "classic" SDL2 with sdl2-compat, following in the footsteps of other distros like Arch and Fedora. sdl2-compat is a reimplementation of the SDL 2 API using SDL 3. One issue that I've noticed is that ci.debian.net reports that the automated test for faudio has regressed when used with sdl2-compat as the default (all packages from Debian unstable, except sdl2-compat taken from experimental). This appears to be because of a behaviour change in the ALSA driver when no hardware is available. With "classic" SDL2, it reports zero devices, and FAudio gracefully fails to initialize, resulting in the vast majority of the test being skipped (5 out of about a thousand tests get run). With sdl2-compat, the ALSA driver reports a placeholder device each for the default playback and recording devices, but opening those devices fails. The FAudio test suite does not handle failure to open a device gracefully, and eventually crashes. I've reported the behaviour change to SDL upstream as https://github.com/libsdl-org/sdl2-compat/issues/562 so that they can assess whether this is something they want to change. However, even if sdl2-compat does change its behaviour, I think it would be better if the faudio autopkgtest explicitly used the `dummy` SDL audio driver. This results in *much* better test coverage: instead of > Finished with 5 successful tests and 0 failed tests. for the current test with "classic" SDL2, I get > Finished with 1223 successful tests and 0 failed tests. with `SDL_AUDIODRIVER=dummy` in the environment. Please consider applying the attached patch. With the patch I'm proposing, because SDL_AUDIODRIVER isn't modified if already set, you could still use a command like one of these: SDL_AUDIODRIVER=pulseaudio sadt SDL_AUDIODRIVER=pipewire debian/tests/run autopkgtest --env SDL_AUDIODRIVER=alsa ... to test against another audio backend that you happen to know works correctly on your specific system. Thanks, smcv
>From ba17bfd19a3f1f4e4e5e89b7dcdbfd8bf996b3f6 Mon Sep 17 00:00:00 2001 From: Simon McVittie <[email protected]> Date: Sat, 20 Dec 2025 15:28:07 +0000 Subject: [PATCH] d/tests/run: Use SDL's dummy audio driver by default This driver is the most appropriate for CI environments where real audio devices are unlikely to be available, but is not available unless explicitly requested like this. With "classic" SDL2, CI containers report that no audio devices are available, and the majority of the faudio test is skipped unless the dummy driver is explicitly used. With sdl2-compat replacing "classic" SDL2, the ALSA driver reports that a default device exists, but actually opening that device does not work. The faudio test suite is not prepared for this to happen, and crashes. Preferring the dummy driver avoids this crash. See also https://github.com/libsdl-org/sdl2-compat/issues/562 Closes: #-1 --- debian/tests/run | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/debian/tests/run b/debian/tests/run index 170c6cc..4885d83 100755 --- a/debian/tests/run +++ b/debian/tests/run @@ -1,3 +1,17 @@ #!/bin/sh + +set -eu + +# Use the dummy driver unless told otherwise: this is the only one that +# can be expected to work in CI containers, but isn't selected unless +# explicitly requested. +# +# Can be overridden with e.g. +# SDL_AUDIODRIVER='pulseaudio,pipewire,alsa,dummy' +# for manual testing. +if [ -z "${SDL_AUDIODRIVER-}" ]; then + export SDL_AUDIODRIVER=dummy +fi + triplet=$(dpkg-architecture -qDEB_HOST_MULTIARCH 2>/dev/null) /usr/lib/$triplet/faudio/faudio_tests -- 2.51.0
