Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#65440 - [alsa-plugins] upgrading 1.2.1-1 -> 1.2.1-4 breaks alsa (no pulse)

Attached to Project: Arch Linux
Opened by Javier (je-vv) - Monday, 10 February 2020, 01:48 GMT
Last edited by David Runge (dvzrv) - Monday, 10 February 2020, 15:17 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To David Runge (dvzrv)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 10
Private No

Details

Description:

Today's alsa-plugins upgrade:

[2020-02-09T16:48:45-0600] [ALPM] upgraded alsa-plugins (1.2.1-1 -> 1.2.1-4)

Broke alsa, by making the default card be:

Card: Alsa-DSP external ctl plugin
Chip: ALSA-DSP plugin Mixer

Which are not physical ones, and which keep the system muted. Efforts to change the default card, like setting /etc/asound.conf, as depicted under "https://www.alsa-project.org/main/index.php/Setting_the_default_device" are futile. The only way to get alsa working back was to downgrade alsa-plugins from recent 1.2.1-4 to previous 1.2.1-1.

I don't use pulse-audio, or any other sort of mixer on top of alsa, so I really depend on alsa working properly, as it was with 1.2.1-1. I seems the patches applied, according to "https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/alsa-plugins", make more harm then good.

Additional info:
* package version(s)
1.2.1-1 -> 1.2.1-4 (this breaks alsa)
* link to upstream bug report, if any
Patches applied on Arch breaking alsa (1.2.1-1 was working fine)
Steps to reproduce:
Just install recent 1.2.1-4 version, on plain alsa Arch box (no pulse), and you'll notice the effect. Not sure if related to my sound card (intel one, which seems pretty common), so I'm including:

% aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC888 Analog [ALC888 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 1: ALC888 Digital [ALC888 Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0

% lspci | 'grep' -i audio
00:1b.0 Audio device: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller (rev 04)
This task depends upon

Closed by  David Runge (dvzrv)
Monday, 10 February 2020, 15:17 GMT
Reason for closing:  Fixed
Additional comments about closing:  The problematic maemo plugin configuration symlink has been removed in alsa-plugins 1.2.1-5.
Comment by Adler (Adler) - Monday, 10 February 2020, 02:39 GMT
Also experiencing this with ALC892 HD audio. Downgraded to 1.2.1-1 as a workaround.
Comment by Marc Sven Schulte (msschulte) - Monday, 10 February 2020, 05:36 GMT
Same problem here.
Comment by David Runge (dvzrv) - Monday, 10 February 2020, 09:15 GMT
@je-vv thanks for the report.

Unfortunately, I'm unable to reproduce this.

For my laptop I have the following setup (note card 0 is not the one I'm using, as it's the HDMI output):

```
**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 8: HDMI 2 [HDMI 2]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 9: HDMI 3 [HDMI 3]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 10: HDMI 4 [HDMI 4]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 0: ALC3232 Analog [ALC3232 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
```

With `cat /proc/asound/cards`:

```
0 [HDMI ]: HDA-Intel - HDA Intel HDMI
HDA Intel HDMI at 0xb4a30000 irq 36
1 [PCH ]: HDA-Intel - HDA Intel PCH
HDA Intel PCH at 0xb4a34000 irq 37
2 [NVidia ]: HDA-Intel - HDA NVidia
HDA NVidia at 0xb3000000 irq 17
```

And `lspci |grep Audio`:

```
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 04)
01:00.1 Audio device: NVIDIA Corporation GK107 HDMI Audio Controller (rev a1)
```

I've configured my user's ~/.asoundrc (my /etc/asound.conf is unmodified) to have:

```
pcm.!default {
type hw
card 1
}

ctl.!default {
type hw
card 1
}
```

This worked before 1.2.1-1 and after 1.2.1-4 without any problems.

What does `cat /proc/asound/cards` give on 1.2.1-1 and on 1.2.1-4?
What is the difference between `aplay -l` on 1.2.1-1 and on 1.2.1-4?
Comment by sekret (sekret) - Monday, 10 February 2020, 09:40 GMT
@David, I have the very same problem and adding your ~/.asoundrc (only having card 0) solves this for me. But with this setting the sound card is being blocked when one program uses it. This means, that dmix isn't being used, right?

Anyway, the problem seems to be, that usually the default device is set kind of automatically. I've never had to configure anything, no ~/.asoundrc, no /etc/modprobe.d/alsa.conf, no nothing. I'm pretty sure that those, who have this problem, have the system configured the same way I do.

I solved this by just deleting alsa-plugins, since I don't need it.
Comment by slack3r (slack3r) - Monday, 10 February 2020, 11:21 GMT
Same here with HD-Audio and Realtek ALC1150 codec.

> alsamixer
> Card: Alsa-DSP external ctl plugin F1: Help │
> │ Chip: ALSA-DSP plugin Mixer
>
> dsp_protocol_probe_node(): Could not open pcm device file /dev/dsptask/pcm2
> dsp_protocol_probe_node(): Could not open pcm device file /dev/dsptask/pcm_rec

No ~/.asounrc, /etc/asound.conf.

Downgraded to 1.2.1-1 me too.
Comment by slack3r (slack3r) - Monday, 10 February 2020, 13:37 GMT
Got it!
Problem is '*alsa.conf.d/98-maemo.conf'.

It contains:
pcm.!default {
type alsa_dsp
playback_device_file [ "/dev/dsptask/pcm2" ]
recording_device_file [ "/dev/dsptask/pcm_rec" ]
}

ctl.!default {
type dsp_ctl
playback_devices [ "/dev/dsptask/pcm2" ]
recording_devices [ "/dev/dsptask/pcm_rec" ]
}

Rebuild with '--disable-maemo-plugin'.
Comment by David Runge (dvzrv) - Monday, 10 February 2020, 14:21 GMT
@slack3r: While I agree, that the pcm.!default{} and ctl.!default{} overrides by the maemo plugin are not really great, the problem really is a configuration issue IMHO.

e.g. if dmix on a default card is desired, one can use the following ~/.asoundrc (or /etc/asound.conf) (for an environment where `hw:1,0` is the card to be used (resampling is done at 44.1kHz)):

```
pcm.!default {
type plug
slave.pcm "dmixer"
}

pcm.dsp0 {
type plug
slave.pcm "dmixer"
}

pcm.dmixer {
type dmix
ipc_key 1234
slave {
pcm "hw:1,0"
period_size 1024
buffer_size 4096
rate 44100
}
}

ctl.mixer0 {
type hw
card 1
}
```

I guess a compromise would be to remove the configuration symlink for the plugin in the meantime and figure out a better way to set pcm.!default{} and ctl.!default{} (or not) through packaging.
The same is done btw. with the pulseaudio-alsa package [1], which overrides the two defaults.

[1] https://git.archlinux.org/svntogit/packages.git/tree/trunk/asound.conf?h=packages/pulseaudio-alsa

Loading...