FS#67058 - [alsa-ucm-conf] Upgrade from 1.2.3-1 to 1.2.3-2 breaks pulseaudio

Attached to Project: Arch Linux
Opened by fokxs (fokxs) - Saturday, 20 June 2020, 20:00 GMT
Last edited by David Runge (dvzrv) - Friday, 10 December 2021, 20:51 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To David Runge (dvzrv)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No

Details

Description:
After upgrading the alsa-ucm-conf package from 1.2.3-1 to 1.2.3-2, pulseaudio does not recognize my onboard sound chip (Realtek ACL1220) anymore and falls back to dummy output device.

Downgrading to 1.2.3-1 immediately solves the problem. pulseaudio recognizes the chip and sound works again.


Additional info:
* package version(s)
alsa-ucm-conf 1.2.3-2

* config and/or log files etc.
journalctl output seems normal except these:
pulseaudio[2356]: W: [pulseaudio] alsa-ucm.c: UCM file does not specify 'PlaybackChannels' or 'CaptureChannels'for device Mic2, assuming stereo duplex.
pulseaudio[2356]: W: [pulseaudio] alsa-ucm.c: UCM file does not specify 'PlaybackChannels' or 'CaptureChannels'for device Mic1, assuming stereo duplex.
pulseaudio[2356]: W: [pulseaudio] alsa-ucm.c: UCM file does not specify 'PlaybackChannels' or 'CaptureChannels'for device Line, assuming stereo duplex.
pulseaudio[2356]: W: [pulseaudio] alsa-ucm.c: UCM file does not specify 'PlaybackChannels' or 'CaptureChannels'for device SPDIF, assuming stereo duplex.
pulseaudio[2356]: W: [pulseaudio] alsa-ucm.c: UCM file does not specify 'PlaybackChannels' or 'CaptureChannels'for device Headphones, assuming stereo duplex.

* link to upstream bug report, if any

Steps to reproduce:
This task depends upon

Closed by  David Runge (dvzrv)
Friday, 10 December 2021, 20:51 GMT
Reason for closing:  Deferred
Comment by David Runge (dvzrv) - Monday, 22 June 2020, 09:30 GMT
@fokxs: Thanks for the report.

I can not reproduce your issue unfortunately. The only thing that has changed between those two pkgrels is that now /usr/share/alsa/ucm2/ucm.conf is packaged again (it was missing before).

Is this still an issue with alsa-lib 1.2.3.1-1?
Comment by fokxs (fokxs) - Monday, 22 June 2020, 12:40 GMT
I just upgraded alsa-lib (1.2.3-1 -> 1.2.3.1-1) and unfortunately the problem persists.

Deleting the ucm.conf also resolves the issue, because as you said, that's the only difference between the 1 and 2 revision.
This file seems to define on how to resolve a specific card / audio profile configuration for a system.

I've attached the audio configuration from my DE, (1) with ucm.conf present and (2) without it.
I suspect that the default configuration might not work with my board/chip.

   with_ucm.png (105.5 KiB)
   without_ucm.png (108.2 KiB)
Comment by David Runge (dvzrv) - Monday, 22 June 2020, 13:11 GMT
Did you restart the system and/or the user service pulseaudio.service after upgrading?
Comment by fokxs (fokxs) - Monday, 22 June 2020, 13:17 GMT
I initially restarted the system when the problem first appeared.

Now, I stop pulseaudio every time after upgrading/deleting/restoring the ucm.conf file and then run pulseaudio with --start --daemonize=no to check the output, but there was no obvious errors other than in the journals logs I already posted.
Comment by Cole Deck (thirstyshark) - Friday, 26 June 2020, 19:08 GMT
Similar issue on my system - audio devices are still picked up however, but when playing audio it just plays a faint grinding-ish noise. Microphone does not work either. Problem persists with latest version, downgrading to 1.2.3-1 and rebooting fixes it. On my system I have the "Intel Corporation Cannon Point-LP High Definition Audio Controller" using the sof-audio-pci driver.
Comment by fokxs (fokxs) - Saturday, 27 June 2020, 14:23 GMT
It seems with version 1.2.3-2 and placing that ucm.conf file it enables all supplied profiles and some of them seem to be buggy (mine's & maybe @thirstyshark's too).

I fixed my initial problem after searching through the alsa-ucm-conf repository. Adjusting the configuration for my chipset according to this commit https://github.com/alsa-project/alsa-ucm-conf/commit/48b11a4c33f267c8ffd9a6c584c3e651eda7e5ec and it solved my issue. This will break with the next upgrade though.
Comment by David Rosenstrauch (darose) - Thursday, 02 July 2020, 21:15 GMT
I believe this change also caused a problem I was seeing today when using my Dell D3100 USB dock (using usb audio). The dock had been working as recently as last week. Today it wasn't, and it seemed like it was due to different device profiles that got loaded for it. I wasn't able to select a profile (using pavucontrol) that successfully gave me audio output from the dock.

This was at my office today. I didn't see this bug till I got home, and can test if the downgrade fixes the issue until the next time I'm in the office again.
Comment by Dario (dario86) - Sunday, 02 August 2020, 20:52 GMT
I have the same issue. I have a ROG Strix X470-F Gaming motherboard. When booted the system will randomly choose either a dummy device, the digital output or the analog one. Downgrading the package to version 1.2.3-1 fixes the issue.
Comment by David Rosenstrauch (darose) - Monday, 10 August 2020, 14:49 GMT
I think my issue was that I had disabled udev-detect (to work around another issue). Once I turned that back on this was no longer an issue for me and I was able to upgrade to 1.2.3-2 successfully.
Comment by David Runge (dvzrv) - Sunday, 28 February 2021, 15:42 GMT
@fokxs is this still an issue?

Have you tried upstreaming the fixes you apply? As this is hardware specific, please file a bug report upstream, if you haven't already.
Comment by David Rosenstrauch (darose) - Monday, 01 March 2021, 15:06 GMT
No longer an issue for me. (See my last comment.)
Comment by fokxs (fokxs) - Wednesday, 03 March 2021, 15:01 GMT
@dvzrv yeah, still an issue.

As this seems to be intended behavior, I have to apply the fix whenever my configuration is overwritten by an update.

I guess I have to live with it until I can convince the maintainers otherwise. Guess this issue can be closed then.
Comment by Yuriy Shevyrov (dev_null) - Sunday, 04 April 2021, 09:49 GMT
I'm gentoo user and right now found the bug.
Removing of /usr/share/alsa/ucm2/ucm.conf fixes the issue.

Big thank you.
I also have ALC1220.
It was very hard to understand what;s going on because from HW viewpoint the device is detected.
Comment by Yuriy Shevyrov (dev_null) - Sunday, 04 April 2021, 10:04 GMT
https://github.com/alsa-project/alsa-ucm-conf/issues/86 I left a report, I hope it can be fixed somehow.
Comment by David Runge (dvzrv) - Tuesday, 01 June 2021, 12:21 GMT
Is this still an issue with alsa-ucm-conf 1.2.5 (currently in [testing])?

Loading...