On Wed, 25 Aug 2021 11:26:01 +0200, David Gow wrote:
Le 25/8/21 à 5:17 pm, Takashi Iwai a écrit :
On Wed, 25 Aug 2021 11:05:09 +0200, David Gow wrote:
Le 25/8/21 à 4:41 pm, Takashi Iwai a écrit :
On Wed, 25 Aug 2021 10:21:35 +0200, munix9 wrote:
Am 25.08.21 um 10:16 schrieb Takashi Iwai:
On Tue, 24 Aug 2021 14:20:42 +0200, Jan Engelhardt wrote: > > > On Monday 2021-08-23 21:09, Len Nordstrom wrote (via private): >> >> The most recent version of SDL no longer seems to seems to be communicating with Pulse Audio. >> After updating to SDL 2.0.16 all my games that use SDL2 lost all sound. > > SDL2 does strict checking of the module name, something it only did > *very* loosely previously (commit > 25f9ed87ff6947d9576fc9d79dee0784e638ac58). > > The problem is in the pulseaudio RPM which: > > /etc/profile.d/pulseaudio.sh:export SDL_AUDIODRIVER=pulse > /etc/profile.d/pulseaudio.csh:setenv SDL_AUDIODRIVER pulse > > A cursory play-around-a-bit tells me this should be > "pulseaudio", not "pulse".
Aha, thanks for finding it out.
Can anyone confirm the theory, that replacing with "pulseaudio" fixes the issue, and open a Bugzilla entry?
thanks,
Takashi
https://wiki.libsdl.org/FAQUsingSDL#how_do_i_choose_a_specific_audio_driver
OK, that has been changed from the old SDL...
Now I opened a bug entry https://bugzilla.opensuse.org/show_bug.cgi?id=1189778
Takashi
Note that SDL 2.0.16 also adds support for comma-separated lists for SDL_AUDIODRIVER[1]. So it will accept SDL_AUDIODRIVER=pulse,pulseaudio if we need to handle both SDL 1.2 and SDL 2.0.
The downside is that -- while SDL 1.2 does now also support this[2] -- it's not getting a new release so hasn't been picked up by distros yet.
Yeah, that's the problem. OTOH, changing to pulseaudio would break SDL1 in anyway, so the situation isn't worse, and it might be worth to try.
(The point is somewhat moot, as I think just letting SDL default to pulse/pulseaudio is ultimately the right solution, and hopefully sdl12-compat[3] will take over and let SDL 1.2 applications use SDL 2.0 at some point, anyway.)
That's a good point. But note that things will be again complex when pipewire joins to the party.
I guess we may set up the multiple drivers in the list such as pipewire,pulseaudio,...
Can we specify the driver list at the build time of SDL2 package (and SDL)...?
SDL doesn't have a specific way of setting this at compile time, other than patching the default list and/or enabling/disabling specific drivers: https://github.com/libsdl-org/SDL/blob/main/src/audio/SDL_audio.c#L37
That being said, the default list (i.e., with SDL_AUDIODRIVER unset) should be pretty sensible under basically all circumstances. PulseAudio is currently the default, and it'll fallback cleanly to ALSA, etc. if it can't be loaded/initialised.
That being said, PipeWire is currently pretty low down the priority list, just due to how new it is, so PulseAudio is preferred at the moment. PipeWire's pulseaudio implementation works perfectly with SDL 2.0.16 for me, though, and you can always set SDL_AUDIODRIVER=pipewire in the meantime (which also works great for me). I imagine that SDL will try PipeWire before PulseAudio once it's more widely used.
So my personal thought here is that not setting SDL_AUDIODRIVER at all is the right thing to do. It certainly shouldn't cause a regression for SDL 2.0, as PulseAudio is the default anyway. I'm not sure about SDL 1.2 off the top of my head, but I've not seen any problems with it personally.
I checked SDL1.2 and it seems that the list order is more or less same, i.e. pulse, then alsa. Then we're likely be able to drop the override of the SDL_AUDIODRIVER. Let's try with that at first. thanks, Takashi