Improve user experience for audio on Linux

[alice-i-cecile]

Audio failures on Linux are some of the most common reasons for end users to struggle with compiling and running Bevy. This makes for a terrible new user experience, takes a lot of help resources, and will be a barrier to actually releasing Bevy games on Linux.

This issue should be closed when following the instructions listed in the Bevy book generally results in working audio on Linux, or a clear error explaining why that's not possible and how to disable the relevant features.

See:

• ALSA lib Invalid value for card #1855
• ALSA Error Causes hard crash #2699
• Note on dependency arch for Fedora #1815
• bevy fails to compile/run on musl based linux distros #898
• Bevy crashes when not found any audio device #850

for some examples of this, and workarounds found within.

There are a couple of things I think we could do to make this better:

1. Improve docs for Linux users in the Bevy book, specifically calling this out as a potential issue and adding the workarounds and debugging steps found.
2. Fail gracefully in bevy_audio when no audio device is found.
3. Investigate the causes more fully, and attempt to make upstream fixes to https://alsa-project.org/wiki/Main_Page or encourage distro owners to fix distribution issues.

As far as I'm aware, there's no reasonable alternative to ALSA we could investigate :(

This is not at all my personal area of expertise though, so if you have more experience with this, please chime in with suggestions!

[bjorn3]

As far as I'm aware, there's no reasonable alternative to ALSA we could investigate :(

You can use pulseaudio and pipewire. They normally use ALSA as backend, but I expect them to work in much more cases than ALSA.

[Ixentus]

2 was (supposedly) fixed in #2269. This should allow Bevy to run without any audio configured.

I suspect the remaining issues are from users who haven't configured their audio properly. Maybe these are users who use Linux exclusively for development. They would notice their issues aren't Bevy's fault as soon as they try to run 2 apps using sound simultaneously. ALSA doesn't mix sound from different inputs. Like bjorn said, using pulseaudio or pipewire fixes this since they mix inputs before sending it to ALSA.

Ultimately I don't think there is anything to be done on the Bevy side of things other than pointing out common pitfalls. There are no upstream fixes to make. Linux audio has historically always been terrible, but it has mostly been fixed by the recent stabilization of pipewire and I recommend everyone with problems switch to it.

[admalledd]

Adding a note for common cause/fixes: Most users will have pulseaudio (or upcoming pipewire) and may need to ensure the pulseaudio-alsa or pipewire-alsa config/plugins that create/manage "dummy user-space alsa devices/apis" that then feed into respective audio service. (Name of config/plugins vary, on Arch they are as listed there, and Ubuntu "should" install them as default but a not uncommon recommendation for "crackling" audio involved messing with the config)

Personally, a better answer is using PulseAudio's userspace API on Linux vs ALSA directly. Pipewire provides a drop-in pulse-daemon replacement, and while PW is really good it isn't "1.0" itself yet or have enough of an install base to make it a default.

For now, my googling led me to this issue and was enough to clue me into personally having a broken pipewire-alsa (my own fault), and reinstalling that got everything to start working. So, possibly "Just document better, and graceful warnings/info for users/devs" is valid, I am just a random passer by poking with a stick.

To make google find this maybe a bit easier, my output that (eventually through the linked issues above) led me here:

ALSA lib pcm_dmix.c:1035:(snd_pcm_dmix_open) unable to open slave
thread 'main' panicked at 'called Result::unwrap() on an Err value: NoDevice', crates/bevy_audio/src/audio_output.rs

(Noting especially the "NoDevice" / "unable to open slave" which is the "your ALSA userspace is probably broken/already in use by pulseaudio/pipewire" hint)

[JulianGmp]

I've encountered a weird situation: When running the breakout example bevy seems to completely ignore pulseaudio's device configuration and it plays audio directly on the HDMI audio, despite the device being completely disabled in pulseaudio and my headset is the default/only audio device for everything else on the system.
Is there just something misconfigured on my system or has anyone else seen this? (Tested on v0.8.1)

Edit: I should have checked the std out; there's a message right there...

$ cargo run --example breakout                                                                                                        latest
    Finished dev [unoptimized + debuginfo] target(s) in 0.12s
     Running `target/debug/examples/breakout`
2022-10-14T20:12:50.927796Z  INFO winit::platform_impl::platform::x11::window: Guessed window scale factor: 1.1666666666666667
2022-10-14T20:12:50.955768Z  INFO bevy_render::renderer: AdapterInfo { name: "AMD RADV RENOIR", vendor: 4098, device: 5686, device_type: IntegratedGpu, backend: Vulkan }
ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave

This is the same as @ admalledd mentioned, except that it didn't crash for me but instead defaulted to a different device

[adsick]

Hi, I'm on Ubuntu 22.10, it uses pipewire.
I tried to run some examples, but it crashes with:

     Running `target/debug/examples/animate_shader`
2022-10-25T15:09:57.132414Z  INFO bevy_render::renderer: AdapterInfo { name: "NVIDIA GeForce RTX 3060 Laptop GPU", vendor: 4318, device: 9568, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "515.65.01", backend: Vulkan }
ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave
thread 'main' panicked at 'Error in Surface::configure: parent device is lost', /home/adsick/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.14.0/src/backend/direct.rs:274:9

previously I've used Fedora (which is pipewire by default) and didn't had that problem.

[adsick]

I guess the crash is related to some wayland stuff (I'm on wayland session, and I've enabled wayland as a default feature of Bevy) but still it seems to be some problem with alsa audio.

[orowith2os]

As far as I'm aware, there's no reasonable alternative to ALSA we could investigate :(

PulseAudio and PipeWire are the audio solutions developers should aim to support on Linux right now.

while PW is really good it isn't "1.0" itself yet or have enough of an install base to make it a default.

PipeWire has since declared its ABI stable, and is usable for screensharing and camera streams. Most major distributions use it by default, and it fixes a large number of issues that users have. It's also required for screensharing on Wayland.

The Rust PipeWire bindings seem to be in a sorry state right now though, so using it directly likely is out of the question. Limiting yourself to PulseAudio also isn't a good idea, since other APIs have their own advantages.

PipeWire also isn't usable outside of screensharing and camera streams inside of a (fully sandboxed) sandbox yet, this is awaiting additions to the generic Devices Portal, which should obsolete the Camera portal. It can work with a sandbox hole, similar to PulseAudio, so it's not too much of a worry.

I'd suggest using SDL for audio, and it can choose the appropriate audio backend (or let the user override it) with very little work on Bevy's end. SDL(2) supports JACK, ALSA, PipeWire, and PulseAudio.

[SolarLiner]

Disagree on SDL. It's pulling in a big dependency that isn't native, all for solving an already-solved issue (ie. cross-platform audio API support). PipeWire support is going to come eventually, if the demand is high enough. For now, PulseAudio is a good middle ground, well supported both for applications and in PipeWire itself. So this is definitely not a high-priority issue.

There's most probably a bug in cpal's default device selection on some cases, where it choses ALSA devices first instead of trying PulseAudio first. It may also be a system configuration issue, as highlighted in some of the issues mentioned.

[minecrawler]

I can see the merit of having more than one backend available. Namely the possibility to develop for embedded (minimal software stack which would benefit from ALSA) vs developing for a desktop (Pulse/Pipewire) vs using Bevy as an interface for an audio application (using Jack).

On top of having easy cross-platform capabilities using something like DirectXTK on Windows and other backends for other OSs.

However, I'm not sure if all backends have to be supported by Core Bevy. They're not always needed, heck, if you know your audience, you'll probably want to only support one at most (per platform/OS) anyway. Hiding them with feature flags might be an idea, but it may also be an idea to provide a general, well integrated API and have the backends in plugins. If a backend offers more than Bevy's API contains, developers could still make use of them directly. That would make cross-platform development easy, if you stick to the core features, and would also be in the spirit of leaving the door open for innovation (implement your own backend for Bevy's API, and if all backends want a feature promote it to core). It could even be super abstract and use another multi-backend crate. Think SDL2 as sound backend, but community-provided (if anyone actually wants that).

Not sure about consoles - since I never developed for one - but this might be helpful for them as well, if they bring their own audio stack. E.g. Switch support could be done with a (proprietary) Switch plugin for Bevy - which is sold by the Foundation :)

[SolarLiner]

Such alternative backend support could be provided to cpal directly, as its job is caring about abstracting audio driver access away from application code, and we definitely want to expose device (and driver) selection to not force people to use the default device; but I still don't see the benefits of providing a replacement for cpal as an alternative backend.

[sullyj3]

There's most probably a bug in cpal's default device selection on some cases, where it choses ALSA devices first instead of trying PulseAudio first.

I think cpal actually just doesn't support pulseaudio yet. RustAudio/cpal#554

At least, not directly - one of the comments in that thread seems to say that audio going into ALSA can be routed to pulse. This seems bizarre to me.

[bjorn3]

ALSA audio can indeed be routed into PulseAudio and PipeWire. Many distros have the library that does this installed by default, but some require the user to manually install it.