ALSA crash on init with EINVAL in snd_pcm_sw_params

[jtsiomb]

martypc crashes on init on my GNU/Linux system with: thread 'main' panicked at 'Failed to build an output audio stream: BackendSpecific { err: BackendSpecificError { description: "ALSA function 'snd_pcm_sw_params' failed with error 'EINVAL: Invalid argument'" } }', /usr/local/src/martypc/core/src/sound.rs:146:14

I'm running debian GNU/Linux without any audio daemons, just ALSA. The version of martypc I've built is the current git HEAD (f18b73e).

Here's the relevant part of a full backtrace, with all the rust unwind and backtrace display noise removed:

16:     0x5555557b5a2d - core::result::Result<T,E>::expect::h5577ddc278659af8
                           at /usr/src/rustc-1.70.0/library/core/src/result.rs:1046:23
17:     0x5555557a86dc - marty_core::sound::SoundPlayer::new::h52d87d0165aed411
                           at /usr/local/src/martypc/core/src/sound.rs:139:29
18:     0x5555557940df - martypc_pixels_desktop::run::h7f3e9de3742bc3cb
                           at /usr/local/src/martypc/frontends/martypc_pixels_desktop/src/lib.rs:523:36
19:     0x5555557917c7 - martypc::main::h2ad35e0e7d3e7dd8
                           at /usr/local/src/martypc/frontends/martypc_pixels_desktop/src/main.rs:38:5

[dbalsom]

your hardware configuration and RUST_LOG=trace output, please.

[dbalsom]

also, do the cpal examples run?
https://github.com/RustAudio/cpal

[jtsiomb]

Here's the stderr output when running with RUST_LOG=trace: https://pastebin.com/3tUFTdYS

The cpal examples seem to run fine. The beep example beeps, and the enumerate example produces this output (split into three parts because pastebin refused to accept more than 512kb per paste):

• part 1: https://pastebin.com/2K2wYKtw
• part 2: https://pastebin.com/JshhGfGH
• part 3: https://pastebin.com/xGtr7G2s

[jtsiomb]

What information do you need about my hardware configuration? Sound hardware is some on-board HDA-compatible on the motherboard: "Audio device: Intel Corporation 100 Series/C230 Series Chipset Family HD Audio Controller (rev 31)"

[dbalsom]

Can you provide the output of the 'enumerate' example from cpal examples?

[jtsiomb]

I did, it's the three-part pastebin above.

[dbalsom]

This seems to be similar to bevyengine/bevy#2699

From the linked article:
https://wiki.archlinux.org/title/Advanced_Linux_Sound_Architecture#Dmix

Integrated motherboard sound cards (such as Intel HD Audio), usually do not support hardware mixing. On such cards, software mixing is done by an ALSA plugin called dmix. This feature is enabled automatically if hardware mixing is unavailable.

can you verify if dmix is enabled?

[jtsiomb]

It is, but it's also irrelevant, I'm not trying to play back multiple audio streams, nor is the error about failing to open the dmix device.

[dbalsom]

are you using any particular distribution I could attempt to repo with? Nevermind, I missed the 'debian' in your initial message.

Is there a reason you're not running any audio daemon?

[jtsiomb]

Debian yes, but it shouldn't make any difference, as the default debian setup is very different to what I'm running.

I'm not running audio daemons because they are unnecessary bloat. The native ALSA kernel interface is more than sufficient for what I need for audio output, and I prefer to err towards simplicity.

[dbalsom]

Fair enough.

MartyPC is opening the audio device twice in rapid succession, and I think that is the problem. The long story short is it was a result of trying to encapsulate cpal's callback generics in a generic SoundPlayer struct. But to create the SoundPlayer struct I have to know the type of the sample format, which I need to ask cpal for, and it opens the device to retrieve that. The sample rate is returned only to be passed to the SoundPlayer's new() method, which opens the device again with the specified sample rate. This is not a great design, but didn't cause problems if the audio device can be opened multiple times.

Theoretically the device should be closed when the device struct is dropped at the end of the first function that reports the sample rate, but I suppose that it takes a non-zero amount of time to actually close the device in a manner such that it can be opened again.

I think the solution is to return the device handle along with the sample rate from ::get_sample_rate, and then I can pass both to new(), so we don't have to reopen the device when creating a SoundPlayer.

[jtsiomb]

Interesting. I tried adding thread::sleep_ms(10000) after the get_sample_format call in frontends/martypc_pixels_desktop/src/libs.rs but aside from the 10 second pause, it didn't make a difference, so I'm not sure it's a matter of time or inability to re-open the device.

I commented out the whole block, including get_sample_format and the match block, and replaced it with let sp = SoundPlayer::new::<i16>(); and it still failed in exactly the same way. I'm sure 16bit signed samples are supported, but just in case I also tried both other variants, and no difference. Btw I then also printed the result of get_sample_format and it is F32.

I hope this helps. If you want me to test some experiment let me know, but I'm not at all familiar with rust, so spell out any changes, or give me a patch to apply.

[dbalsom]

let's just see what this prints out
sound.rs.patch