ALSA problem

Kocsonya · 2023-11-29 05:10:08

I have a Dell G16 laptop with Arch.
I have alsa installed and mplayer and everything else is happy with it, including Firefox playing youtube videos.
Playback seems to work just fine.

Recording is a different issue. If I start arecord, it records nothing. However, if I specify a specific device, then it works. It seems that the built-in microphone is connected to hw:1,7 but the default alsa configuration selects some other channel as the default input source.

I don't really know how alsa works internally and couldn't really find a documentation of its configuration but even if I could, I doubt that that would be enough without understanding the inner workings.

Thus, I would much appreciate if someone in the know could tell me the magic incantations that would make hw:1,7 the default input.
It would be the icing on the cake if there was a way of getting rid of channels that are there but nothing is connected to them, so that alsamixer or audacity, for example, wouldn't get cluttered channels that are useless.

V1del · 2023-11-29 12:32:49

Make a ~/.asoundrc with the contents

defaults.pcm.dsnoop.card 1
defaults.pcm.dsnoop.device 7

that's slightly ugly because you're hardcoding a potentially unstable index, what do you get from

arecord -lL

?

FWIW there's also https://wiki.archlinux.org/title/Advanc … ure_device -- but that approach is quite verbose and somewhat unflexible, but "should" have more or less the same end result (other than it allocating exclusive access to the mic resource, i.e. only one program could be recording at a time)

Lone_Wolf · 2023-11-29 12:33:17

Let's verify first if you indeed have a 'pure alsa' setup .

Please post output of

$ pacman -Qs pulse
$ pacman -Qs pipewire

having libpulse & libpipewire installed is ok, but no other parts of pulseaudio / pipewire must be present.

EDIT: Videl already mentioned that page.

Last edited by Lone_Wolf (2023-11-29 12:34:53)

Kocsonya · 2023-11-29 19:25:18

Output of pacman:

[zoltan@menyus ~]$ pacman -Qs pulse
local/libcanberra 1:0.30+r2+gc0620e4-3
    A small and lightweight implementation of the XDG Sound Theme Specification
local/libpulse 16.1-6
    A featureful, general-purpose sound server (client library)

[zoltan@menyus ~]$ pacman -Qs pipewire
local/lib32-libpipewire 1:0.3.80-1
    Low-latency audio/video router and processor - 32-bit - client library
local/lib32-pipewire 1:0.3.80-1
    Low-latency audio/video router and processor - 32-bit
local/lib32-pipewire-v4l2 1:0.3.80-1
    Low-latency audio/video router and processor - 32-bit - V4L2 interceptor
local/libpipewire 1:0.3.80-1
    Low-latency audio/video router and processor - client library
local/pipewire 1:0.3.80-1
    Low-latency audio/video router and processor
local/pipewire-media-session 1:0.4.2-2
    Legacy session manager for PipeWire (deprecated)
local/pipewire-v4l2 1:0.3.80-1
    Low-latency audio/video router and processor - V4L2 interceptor

Output of arecord:

[zoltan@menyus ~]$ arecord -lL
null
    Discard all samples (playback) or generate zero samples (capture)
lavrate
    Rate Converter Plugin Using Libav/FFmpeg Library
samplerate
    Rate Converter Plugin Using Samplerate Library
speexrate
    Rate Converter Plugin Using Speex Resampler
jack
    JACK Audio Connection Kit
oss
    Open Sound System
pulse
    PulseAudio Sound Server
speex
    Plugin using Speex DSP (resample, agc, denoise, echo, dereverb)
upmix
    Plugin for channel upmix (4,6,8)
vdownmix
    Plugin for channel downmix (stereo) with a simple spacialization
usbstream:CARD=NVidia
    HDA NVidia
    USB Stream Output
default:CARD=sofhdadsp
    sof-hda-dsp, 
    Default Audio Device
sysdefault:CARD=sofhdadsp
    sof-hda-dsp, 
    Default Audio Device
usbstream:CARD=sofhdadsp
    sof-hda-dsp
    USB Stream Output
**** List of CAPTURE Hardware Devices ****
card 1: sofhdadsp [sof-hda-dsp], device 0: HDA Analog (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: sofhdadsp [sof-hda-dsp], device 6: DMIC (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: sofhdadsp [sof-hda-dsp], device 7: DMIC16kHz (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

As far as I know, I don't have PulseAudio or pipewire installed, at least not deliberately.

Thanks!

Head_on_a_Stick · 2023-11-29 19:45:39

Kocsonya wrote:

local/pipewire-media-session 1:0.4.2-2
    Legacy session manager for PipeWire (deprecated)

So does wireplumber work? Pacman defaults to the "deprecated" [sic] pipewire-media-session package when pipewire is installed, which is really silly.

Last edited by Head_on_a_Stick (2023-11-29 19:46:19)

Kocsonya · 2023-11-29 23:08:39

V1del wrote:

Make a ~/.asoundrc with the contents
defaults.pcm.dsnoop.card 1
defaults.pcm.dsnoop.device 7

That results in this:

[zoltan@menyus ~]$ arecord -f cd foo
ALSA lib conf.c:1224:(parse_value) card is not an integer
ALSA lib conf.c:2012:(_snd_config_load_with_include) _toplevel_:1:27:Invalid argument
ALSA lib conf.c:4120:(config_file_open) /home/zoltan/.asoundrc may be old or corrupted: consider to remove or fix it
ALSA lib conf.c:4042:(snd_config_hooks_call) function snd_config_hook_load returned error: Invalid argument
ALSA lib conf.c:4649:(snd_config_update_r) hooks failed, removing configuration
arecord: main:834: audio open error: Invalid argument

Head_on_a_Stick wrote:

So does wireplumber work? Pacman defaults to the "deprecated" [sic] pipewire-media-session package when pipewire is installed, which is really silly.

It is not installed, I believe:

[zoltan@menyus ~]$ wireplumber
bash: wireplumber: command not found

V1del · 2023-11-30 01:16:01

If you want to not use pipewire for audio you don't want wireplumber anyway.

Try using

defaults.pcm.dsnoop.!card "sofhdadsp"
defaults.pcm.dsnoop.device 7

instead in that case.

While we are on the topic, any particular reason for wanting to avoid a sound server?

Kocsonya · 2023-11-30 23:48:57

Same result:

[zoltan@menyus ~]$ arecord -vvv -f cd foo
ALSA lib conf.c:1224:(parse_value) device is not an integer
ALSA lib conf.c:2012:(_snd_config_load_with_include) _toplevel_:3:0:Invalid argument
ALSA lib conf.c:4120:(config_file_open) /home/zoltan/.asoundrc may be old or corrupted: consider to remove or fix it
ALSA lib conf.c:4042:(snd_config_hooks_call) function snd_config_hook_load returned error: Invalid argument
ALSA lib conf.c:4649:(snd_config_update_r) hooks failed, removing configuration
arecord: main:834: audio open error: Invalid argument

I've played a bit with the file, without actually knowing its specific syntax.
The error goes away if I put a bang into the second line :

defaults.pcm.dsnoop.!device 7

but then there is no recording, i.e. the device select line becomes formally valid, but not effective.

Is there a formal specification document that describes the exact format of the ALSA config files and explains in detail what option does what?

As per sound server, I had bad experience with pulse. On a different (and admittedly some 5 years old) system I installed it and from that on quite a few programs that worked before, either became mute or straight spit the dummy.
It was better to live without programs that depended on PA than without the ones that it broke, so it got removed. It is possible that pulse came a long way since, but it is still quite easy to find recent posts on the net cursing it, so I'm a bit cautious.
And in any case, ALSA-only apps need a working ALSA config, so I need to solve my immediate problem regardless of having a sound server or not.

V1del · 2023-11-30 23:59:28

The config snippet I suggested should configure the default device and default card of dsnoop, which should be the default method of accessing the mic.

I was assuming these defaulted to indices in general, but adding the ! will explicity override and configure a certain device/card regardless of whether you use the name or the string variation, and I think I might've flubbed the syntax, does

defaults.pcm.dsnoop.!card 1;
defaults.pcm.dsnoop.!device 7;

work?

If you use a sound server (and fwiw pipewire is the new hotness here) it can provide a working ALSA plugin and allow better control of the default devices than fidgeting around with ALSA configuration.

If you do not need multiple programs accessing the mic, following the suggestion in the linked section will make use of the mic exclusive to a single application but should generally work the same way as specifying it with aplay -Dhw:1,7 -- what exact error do you get with the adjusted defaults node?

As for config references, reading some of our wiki and generally the alsa reference docs

https://wiki.archlinux.org/title/Advanc … figuration
https://www.alsa-project.org/alsa-doc/alsa-lib/

Last edited by V1del (2023-12-01 00:08:32)

Kocsonya · 2023-12-01 10:52:26

With the bangs the config file is accepted, but no cigar.

arecord -vvv -f cd foo

records all 0-s, while

arecord -vvv -f cd --device hw:1,7 foo

does indeed record the mic.
Without the device spec the following is printed by arecord (uninteresting bits deleted for brevity):

[zoltan@menyus ~]$ arecord -vvv -f cd foo
Plug PCM: Rate conversion PCM (48000, sformat=S16_LE)
Converter: libspeex (external)
Protocol version: 10003
Its setup is:
  <lots of sample format and buffer info deleted>
Slave: Hardware PCM card 1 'sof-hda-dsp' device 0 subdevice 0
Its setup is:
  <again, sample format info deleted>

That is, it simply ignores the default set in .asoundrc.

If I specify the device, the blurb is:

[zoltan@menyus ~]$ arecord -vvv -f cd --device hw:1,7 foo
Warning: rate is not accurate (requested = 44100Hz, got = 16000Hz)
         please, try the plug plugin 
Hardware PCM card 1 'sof-hda-dsp' device 7 subdevice 0
Its setup is:
  <format info omitted>

It should be noted that 1,7 has a fixed sample rate of 16kHz, must be some Dell HW specific restriction.

I will take a look at pipewire, but in any case I would really like to fix the ALSA default setup. There should be a way of selecting the default device, I'm probably not the first one who faced a problem like this, especially on laptops with weird HW configs.

V1del · 2023-12-01 11:32:31

The thing is ALSA default device selection is inherently very brittle and unreliable due to there existing multiple mechanisms for querying the "default" while it's not really standardized which should be used. You will have software that will honor your configuration and software that will hardcode hw:0,0.

16KHz limitation is quite normal for mics that's not immediately out of the ordinary.

From a general standpoint I'd assume the config in https://wiki.archlinux.org/title/Advanc … ure_device to be the most promising you need to replace the card identifier for the pcm.usb (you can select the "usb" here as you want) but the card there should be sofhdadsp. e.g.

pcm.sofmic
{
    type hw
    card sofhdadsp
    device 7
}

pcm.!default
{
    type asym
    playback.pcm
    {
        type plug
        slave.pcm "dmix"
    }
    capture.pcm
    {
        type plug
        slave.pcm "sofmic"
    }
}

Kocsonya · 2023-12-02 19:50:20

That last one works perfectly!

THANK YOU!

V1del · 2023-12-03 23:20:25

Right... The reason I went with my initial suggestion is because the above will make the mic exclusive, so only one application can record at a time, though unlike the reverse case this is probably not that big of a deal most of the time.

If you consider this [SOLVED] please mark it as such by editing the title in your first post.

Arch Linux

#1 2023-11-29 05:10:08

ALSA problem

#2 2023-11-29 12:32:49

Re: ALSA problem

#3 2023-11-29 12:33:17

Re: ALSA problem

#4 2023-11-29 19:25:18

Re: ALSA problem

#5 2023-11-29 19:45:39

Re: ALSA problem

#6 2023-11-29 23:08:39

Re: ALSA problem

#7 2023-11-30 01:16:01

Re: ALSA problem

#8 2023-11-30 23:48:57

Re: ALSA problem

#9 2023-11-30 23:59:28

Re: ALSA problem

#10 2023-12-01 10:52:26

Re: ALSA problem

#11 2023-12-01 11:32:31

Re: ALSA problem

#12 2023-12-02 19:50:20

Re: ALSA problem

#13 2023-12-03 23:20:25

Re: ALSA problem

Board footer