Kira does not work if ALSA is not working - it does not attempt for other devices

[deavid]

Not sure if I should send this to this crate or bevy_kira_audio, but it does reproduce with this repository code alone too.

In my system, trying to start up any example of this git repo, I get:

ALSA lib pcm_dmix.c:1000:(snd_pcm_dmix_open) unable to open slave
Error: DefaultStreamConfigError(DeviceNotAvailable)

Whereas, with a bevy app, which uses bevy_audio, using rodio, I get:

ALSA lib pcm_dmix.c:1000:(snd_pcm_dmix_open) unable to open slave
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp

And it works.

Rodio seems to have some sort of detection or trying different devices until one works:

https://github.com/RustAudio/rodio/blob/v0.19.0/src/stream.rs#L56

Kira, either doesn't have this, or it's not clear enough and bevy_kira_audio doesn't do it correctly - but even then, your own examples do not work on my system.

And this is not a problem of my system, because kira is the only one that fails to reproduce audio. This is a Kubuntu fresh install (mostly) with Pipewirte and a Focusrite audio interface.

A small example of what does reproduce audio correctly in my system:

• Default Bevy games using bevy_audio
• Google Chrome, Firefox
• Steam games, native+proton emulated
• Audacity (which reports to be using ALSA)

[deavid]

Just a reminder, that while this might be sorted out by installing pipewire-alsa or equivalent, this is still bad behavior from Kira itself -> it basically does not work unless ALSA is there. And we have more modern standards. We're moving away from ALSA.

[rdrpenguin04]

This is the correct repository. Syrillian uses Kira directly, and it crashes in the same manner.

[tesselode]

I'd rather cpal handles this better, but I'll see what I can do on Kira's end.

[djgaven588]

I'd rather cpal handles this better, but I'll see what I can do on Kira's end.

Any updates on this or perhaps an associated cpal issue? I'm on Kira 0.11.0 and I've run into this a few times now with users using pulse on Arch Linux.

Some have found a work around, but I've struggled to figure out anything I can do to fix it.

[tesselode]

@djgaven588 thanks for the reminder about this issue. I agree that Kira (or preferably cpal, but I have control over Kira) should try various devices until one works, but in order to test that, I'd like to reproduce a situation where the default device doesn't work in Linux, which I'm having trouble doing.

I've tried running Kira in two different Arch Linux installations, one using archinstall's pipewire preset and one using its pulseaudio preset, and in both cases, I can play audio through the default device just fine. (In the case of pulseaudio, it bypasses KDE's volume control, but I think that might be because it's expecting applications to use pipewire.)

@deavid @rdrpenguin04 @djgaven588 are any of you able to give me more info on how your audio is set up? From my reading of the Arch wiki, ALSA is built into the Linux kernel and used in most modern systems, and I believe cpal requires it (or JACK).

[deavid]

@tesselode In my case is because a modern install of Kubuntu does install Pipewire, with pulseaudio emulation. Alsa exists, but there's no pipewire-alsa bridge installed by default. So Alsa is not emulated as far as I know. Apps and games on the system can output audio if they know how to talk to pipewire or to pulseaudio. Kira tries all, and not sure what order it follows, because it should try pipewire first, pulseaudio next and alsa last - and it just tries Alsa, it fails, and gives up.

The solution in the system itself is to install pipewire-alsa, the bridge. That emulates an ALSA server that actually routes to pipewire.

But this, from Kira's perspective, is very bad. Because ALSA is very old and doesn't have many capabilities. So even if ALSA works, we are possibly doing worse than if pulseaudio or pipewire were selected.

[djgaven588]

@deavid @rdrpenguin04 @djgaven588 are any of you able to give me more info on how your audio is set up? From my reading of the Arch wiki, ALSA is built into the Linux kernel and used in most modern systems, and I believe cpal requires it (or JACK).

From what I'm getting from an Arch user, it sounds like this is due to a "configuration L" (although I've seen it multiple times at this point so 🤷 ).

The before mentioned /etc/asound.conf and / or ~.asoundrc being removed should be able to reproduce it, but I haven't checked it myself yet.

[tesselode]

@deavid I tried installing Kubuntu 24.04 to reproduce your issue, and had a different issue instead. The default audio device didn't work, but it was just silent, no DeviceNotAvailable error. However, once I switched from my audio interface to my PC's headphone out, audio worked just fine. I tried manually setting my device to all the options that were available, and none of those made my audio interface work.

Furthermore, none of the devices were named anything containing "pipewire" and "pulse", so I'm not sure how Kira could identify a pipewire or pulseaudio device to choose it first.

I'm still in support of having Kira try a different device if the first one doesn't work, I just need to reproduce that situation before I can test the change. And the idea of trying pipewire, then pulse, then other options sounds great on paper, but I'm not seeing a way to implement that.

[tesselode]

@djgaven588 My Arch install didn't have /etc/asound.conf or ~/.asoundrc, and my audio worked fine*.

(*on pulse audio, it bypassed the system volume control, but I still had audio at least)

[djgaven588]

@djgaven588 My Arch install didn't have /etc/asound.conf or ~/.asoundrc, and my audio worked fine*.

(*on pulse audio, it bypassed the system volume control, but I still had audio at least)

I've done a fresh install of Arch and managed to get the issue to reproduce. It seems the current ISO ends up accidentally doing minimal instead of desktop, which may have something to do with reproducing it?

I had to install pipewire-alsa to resolve:
DefaultStreamConfigError(DeviceNotAvailable)

Then add the /etc/asound.conf to resolve:
BuildStreamError(BackendSpecific { err: BackendSpecificError { description: "ALSA function 'snd_pcm_hw_params' failed with error 'No such file or directory (2)'" } })

Reversing the changes consistently reproduces it.