Created attachment 292759 [details] alsa-info.sh output When executing speaker-test -c 2, I get the following error: speaker-test 1.2.3 Playback device is default Stream parameters are 48000Hz, S16_LE, 2 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 aplay -L indicates that the default card is what I expected: default:CARD=Generic_1 HD-Audio Generic, Generic Analog Default Audio Device The problem seems to be simply that this is a brand new machine. Codec vendor id (0x10ec0230) is nowhere to be found in ALSA kernel code dir. I wish that I could do more to assist than just reporting but I'm not sure what I could do to help more. Let me know if you would like me to run stuff on my machine to probe this new HDA codec intricacies. Greetings
The first card is the HDMI output from GPU and the onboard audio is the second card. The third card is the digital mic. So you need to test with -Dplughw:1 for speaker-test.
your assessment about which is what is correct and that was my reading too but why is using the plughw:1 required? default device appears to be pointing on the correct second card (generic_1/card1), no? Your suggestion has been able to make speaker-test work with your suggestion except for: $ speaker-test -Dplughw:1 -c 2 speaker-test 1.2.3 Playback device is plughw:1 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 $ speaker-test -Dplughw:1 -c 2 -b 128000 speaker-test 1.2.3 Playback device is plughw:1 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 Requested buffer time 128000 us Periods = 4 was set period_size = 1536 was set buffer_size = 6144 0 - Front Left ^C 1 - Front Right Time per period = 2.285740 It is the first time that I need to adjust the buffer setting to make speaker-test work. Is it normal or could it be because the codec isn't recognized, therefore its capabilities are set to some generic usually good values that happens to be incorrect for it?
The memory error comes from your kconfig CONFIG_SND_HDA_PREALLOC_SIZE=0 Set it to the appropriate value, e.g. 2048. It's basically a bug in speaker-test that tries to allocate as much as possible, and the config above with the value 0 indicates it's unlimited.
The reason for -Dplughw:1 option is that alsa-lib expects the card 0 to be the default card, not the card 1. So, without the option, it'll try to access the card 0, which is the HDMI device.
Thank very much for your help! As a sidenote, I did create a /etc/asound.conf file with: defaults.pcm.card 1 defaults.ctl.card 1 and the need to provide a buffer value went away. A proud ALSA user that want to have nothing to do with apulse!
And, did you get the sound out of the box now? It's possible that you still need some device-specific tweaks. In that case, we'd need to ask Realtek people about this codec chip at first.
yes absolutely! With this asound.conf settings, it does work like a charm now. It seems to me that my struggle came from ALSA default device pick due to the unrecognized HDA chip but I'm not 100% but from my past experiences, its default device selection accuracy is better than what I have experienced in that case. If there remains something to do about at all with my report, that would to recognize this chip... but it is very minor since the generic probing did an excellent job to detect the correct device settings! At least, now with this bug, it is documented so the next Linux user getting the same experience will find the solution here. I also did report the CONFIG_SND_HDA_PREALLOC_SIZE issue to the ArchLinux maintainers. It used to be set to 4096 up to kernel 5.6 and it changed to 0 without any traces of explainations about the change... Weird... but you are amazing! 2 birds with 1 rock... You did really help with your intervention on this ticket! thx again