[SOLVED] Alsa speaker-test "Setting of hwparams failed"

Trilby · 2020-07-20 14:50:31

This morning I fired up wesnoth and found my sound wasn't working. Sound was working fine in by browser (qutebrowser). Both of these worked fine yesterday. No packages have changed in the intervening time.

I checked with speaker-test and saw the following error:

$ speaker-test

speaker-test 1.2.3

Playback device is default
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
Channels count (1) not available for playbacks: Invalid argument
Setting of hwparams failed: Invalid argument

I had not rebooted since my last kernel upgrade (though this was also true yesterday when everthing worked) so I tried rebooting, and on a fresh boot speaker-test still failed with the output above. This is with uname and pacman -Q both reporting the kernel version 5.7.9-arch1-1.

For reference, my `aplay -L` and ~/.asoundrc are below:

$ aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
hdmi:CARD=HDMI,DEV=0
    HDA Intel HDMI, HDMI 0
    HDMI Audio Output
hdmi:CARD=HDMI,DEV=1
    HDA Intel HDMI, HDMI 1
    HDMI Audio Output
hdmi:CARD=HDMI,DEV=2
    HDA Intel HDMI, HDMI 2
    HDMI Audio Output
hdmi:CARD=HDMI,DEV=3
    HDA Intel HDMI, HDMI 3
    HDMI Audio Output
hdmi:CARD=HDMI,DEV=4
    HDA Intel HDMI, HDMI 4
    HDMI Audio Output
sysdefault:CARD=PCH
    HDA Intel PCH, ALC3232 Analog
    Default Audio Device
front:CARD=PCH,DEV=0
    HDA Intel PCH, ALC3232 Analog
    Front output / input
surround21:CARD=PCH,DEV=0
    HDA Intel PCH, ALC3232 Analog
    2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=PCH,DEV=0
    HDA Intel PCH, ALC3232 Analog
    4.0 Surround output to Front and Rear speakers
surround41:CARD=PCH,DEV=0
    HDA Intel PCH, ALC3232 Analog
    4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=PCH,DEV=0
    HDA Intel PCH, ALC3232 Analog
    5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=PCH,DEV=0
    HDA Intel PCH, ALC3232 Analog
    5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=PCH,DEV=0
    HDA Intel PCH, ALC3232 Analog
    7.1 Surround output to Front, Center, Side, Rear and Woofer speakers

$ cat ~/.asoundrc
pcm.!default {
    type hw
    card 1
}

ctl.!default {
    type hw
    card 1
}

I renamed ~/.asoundrc and tried again with the following result:

$ speaker-test

speaker-test 1.2.3

Playback device is default
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
ALSA lib pcm_dmix.c:1090:(snd_pcm_dmix_open) unable to open slave
Playback open error: -2,No such file or directory

This error is expected as in the absence of an ~/.asoundrc (or other setting) the the HDMI output is the default. For all subsequent tests I restored my ~/.asoundrc as shown above. I do not have a /etc/asoundrc nor any modules settings /etc/modprobe.d or /etc/modules-load.d, nor any kernel command line settings for sound or alsa.

Despite no packages changing since yesterday when everthing worked, I still tried downgrading (to 30 June), rebooted, and had the same error. I have since re-upgraded and rebooted and the problem remains. Sound still works in my browser, but speaker-test fails. Oddly, I just discovered that `aplay /path/to/some.wav` works (it plays the sound and reports no errors), but `speaker-test -w /path/to/some.wav` fails with the same error as plain `speaker-test`.

I also confirmed speaker-test was not a function/alias/etc:

$ type speaker-test
speaker-test is /usr/bin/speaker-test

$ pacman -Qo /bin/speaker-test
/usr/bin/speaker-test is owned by alsa-utils 1.2.3-2

$ pacman -Qkk alsa-utils
alsa-utils: 97 total files, 0 altered files

Given the error message states that Channels count (1) are not available, I tried specifying a channel count. For most specified channel counts (0, 1, 3, 5, 6, 7, 8, 9, 10) speaker-test gives the same error as with no parameters (except the number in parentheses changes accordingly). For specified channel counts of 2 and 4, I get a different error:

$ speaker-test -c 2

speaker-test 1.2.3

Playback device is default
Stream parameters are 48000Hz, S16_LE, 2 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 64 to 8544000
Period size range from 32 to 4272000
Using max buffer size 8544000
Periods = 4
Unable to set hw params for playback: Cannot allocate memory
Setting of hwparams failed: Cannot allocate memory

As my primary concern is sound failing in wesnoth, I may be chasing an X-Y problem (e.g., there is something wrong with speaker-test as well, but it may or may not be the root cause of the wesnoth issue). But wesnoth is not reporting any errors. Started either normally or with the debug flag, the only output is as follows, yet there is no sound:

$ wesnoth -d
Battle for Wesnoth v1.14.13
Started on Mon Jul 20 09:34:38 2020


Data directory:               /usr/share/wesnoth
User configuration directory: /home/USER/.config/wesnoth
User data directory:          /home/USER/.local/share/wesnoth/1.14
Cache directory:              /home/USER/.cache/wesnoth

Setting mode to 1280x720
Checking lua scripts... ok

I suspect that it may be easier for others here to help debug speaker-test first, and I suspect getting to the root of that problem will remedy the wesnoth issue as well.

In searching, I could find only one related thread from 5 years ago that is unsolved:
https://bbs.archlinux.org/viewtopic.php?id=199643

Why is speaker-test reporting a problem with "hw params" or "hwparams"? Where are these parameters set and can I try changing them?

------------------------------------------------

EDIT: Solved ... in a very mysterious way.

It turns out I hadn't searched for the error message with the channels specified. When I searched for that error message I found the much more recent thread here:
https://bbs.archlinux.org/viewtopic.php?id=256191

That solution not only resolved the `speaker-test -c 2` error message, but somehow made all other invocations of speaker-test work. It looks like the wiki needs to be updated as my ~/.asoundrc and that of the OP in the other thread followed the guidance in the wiki.

Now the weird part: speaker-test worked, but wesnoth didn't. At least not until I opened sound preferences in wesnoth and saw that the toggles for all sounds were off. I turned them back on and all was fine. I can only speculate that something went awry with alsa resulting in speaker-test failing and in wesnoth failing, but the latter, in response to a failed sound system, toggled off all sound. That is a very unsatisfactory explanation at many levels - but it's the only way I can figure.

EDIT 2: I restored my asoundrc to what I had before and restarted wesnoth, and sound still worked. I'm fucking baffled - it would seem that some change in Alsa made the asoundrc not work for speaker-test, perhaps some time ago, and coincidentally something else entirely unrelated caused wensoth's sound to all be toggled off this morning. *shrug*

Last edited by Trilby (2020-07-20 16:30:32)

V1del · 2020-07-22 01:35:17

Mhm, while I'm generally always a bit uneasy whenever I see direct index references to change the sound card (...without having ensured proper ordering via modprobe) it shouldn't really matter in this particular context, as at least from what I've seen, snd_hda_intel initialization for multiple cards is pretty consistent and the HDMI card always gets 0 and the integrated card always gets 1, but if it didn't for any reason you'd set the wrong default.

Symptoms read like you had something hard occupying the card this one instance (sudo fuser -v /dev/snd/* is your friend here) and when wesnoth couldn't access the card like usual and thus brokenness ensued.

FWIW both yours and the OP of the other threads suggestions for setting the default card come a bit "later" in the default card setting header with farther reaching effects than the methods suggested earlier in the wiki. Your chosen method in particular does have the red warning message above that it should probably not be used as is in most contexts as is, as it will basically destroy the entire "normal" default card setup (aplay -L shows this quite well, there's no exposed "default" PCM anymore, apparently automatic channel conversion gets broken, I did assume dmix as well but I guess you'd have noticed that earlier and differently) which could have more side effects than intended (the biggest program I know of that has an actual issue with this is firefox as it will only play back to a "default" PCM if it is actually exposed, otherwise hardcode on hw:0) ... programs that do not have an issue with this either enumerate available devices on their own, or just blindly try to play back on "default".

I do agree that the wiki could be reworked in that regard, and potentially a sort of ordering from "more likely to less likely to be what you want" given to the particular methods. I will have some actual free time next week, so I might sit down and try to rework that a bit, as it is ultimately one of the most asked questions here in regards to ALSA config if people can't just rely on their card 0 auto-setup being correct.

Arch Linux

#1 2020-07-20 14:50:31

[SOLVED] Alsa speaker-test "Setting of hwparams failed"

#2 2020-07-22 01:35:17

Re: [SOLVED] Alsa speaker-test "Setting of hwparams failed"

Board footer