Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1818883 - Update to 13.99.1 in F31+ breaks audio on Bay and Cherry Trail (Intel SST audio) devices
Summary: Update to 13.99.1 in F31+ breaks audio on Bay and Cherry Trail (Intel SST aud...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: pulseaudio
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-03-30 15:32 UTC by Hans de Goede
Modified: 2020-04-02 09:55 UTC (History)
5 users (show)

Fixed In Version: pulseaudio-13.99.1-3.fc32 pulseaudio-13.99.1-3.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-02 00:31:50 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Hans de Goede 2020-03-30 15:32:28 UTC 
While testing some other audio stuff I noticed that audio did not work an a Cherry Trail device with a RT5645 codec. I've also reproduced the issue on a Bay Trail device with a RT5651 codec.

The problem appears to be that pulseaudio does not run the EnableSequence for the SectionDevice which it selects as output profile at startup.

If I manually run: "alsaucm -c chtrt5645 set _verb HiFi set _enadev Speaker" then this fixes no audio coming from the speakers on the chrt5645 device (tested on multiple models). On the bytcr_rt5651 device (tested on a Point of View P1006W 2-in-1) this seems to not be enough, so maybe the "global" EnableSeq also is not run?

To reproduce take a chtrt5645 device with a fully up2date F31 or F32 and as root do:

rm /var/lib/alsa/asound.state
sync
reboot --force

Then notice how no sound is coming out of the speakers even though sound is playing.

Running "alsamixer -c 1" shows that the following 2 lines from ucm2/codecs/rt5645/SpeakerEnableSeq.conf did not execute:

cset "name='Speaker Channel Switch' on"
cset "name='Speaker Playback Volume' 31"

Toggling the output profile to HeadPhones by inserting HeadPhones and then unplugging them works around this, so as said it seems that the EnableSequence only does not run for the output profile selected at pulseaudio startup.

Downgrading pulseaudio to 13.0 fixes this.

Note this may also apply to input profiles, I only tested those after the downgrade to 13.0 and then they work fine.
Comment 1 Hans de Goede 2020-03-30 15:35:11 UTC 
Jaroslav, adding you to the Cc. since this is likely caused by the pulseaudio UCM changes you did. See the description for details, I hope I have gathered enough details to make this easy to fix.
Comment 2 Jaroslav Kysela 2020-03-31 06:55:30 UTC 
(In reply to Hans de Goede from comment #0)
> To reproduce take a chtrt5645 device with a fully up2date F31 or F32 and as
> root do:
> 
> rm /var/lib/alsa/asound.state
> sync
> reboot --force

A small advice: The asound.state daemon is handled through 'alsa-state.service'. 'systemctl stop alsa-state.service' instead 'sync' should be sufficient for the normal reboot without --force.

> Then notice how no sound is coming out of the speakers even though sound is
> playing.

I can reproduce this here on rt5640 machine (from you) with F31, too. I'll try to do an analysis tomorrow.

It seems tha the UCM device is not activated in pa_alsa_ucm_set_port() function on PA boot now.
Comment 3 Jaroslav Kysela 2020-03-31 11:38:11 UTC 
Fixes:

https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/276
Comment 4 Wim Taymans 2020-03-31 14:38:09 UTC 
I'm pushing these fixes to f31/f32/f33 now
Comment 5 Fedora Update System 2020-03-31 14:45:53 UTC 
FEDORA-2020-d5f7729083 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-d5f7729083
Comment 6 Fedora Update System 2020-03-31 14:46:35 UTC 
FEDORA-2020-1b72a87b08 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-1b72a87b08
Comment 7 Fedora Update System 2020-04-01 02:15:06 UTC 
FEDORA-2020-1b72a87b08 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-1b72a87b08`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1b72a87b08

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 8 Fedora Update System 2020-04-01 03:54:42 UTC 
FEDORA-2020-d5f7729083 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-d5f7729083`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d5f7729083

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 9 Hans de Goede 2020-04-01 10:15:09 UTC 
I can confirm that this fixes the audio issues I was seeing on devices using Intel SST audio.

Jaraslov, thank you for the quick fix.

Wim, thank you for quickly adding the fix to the Fedora packages.
Comment 10 Fedora Update System 2020-04-02 00:31:50 UTC 
FEDORA-2020-1b72a87b08 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.
Comment 11 Fedora Update System 2020-04-02 09:55:41 UTC 
FEDORA-2020-d5f7729083 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.
Note You need to log in before you can comment on or make changes to this bug.