audio stopped working

[hulten]

I have an ThinkPad P14s with azalia(4) audio (see dmesg attached).

Last week audio playback and recording still worked. As of sometime this week not anymore.

I found issues on misc@ with AMD audio and MSI, but it is not the exact same device as I have. Apparently audio can stop working. There is a workaround for this in OpenBSD disabling MSI, but there is no complete solution, mostly due to lacking documentation from AMD, I understood. For this, this thread is relevant.

However, even as I had this issue (at random times audio not working anymore), now the issue is that audio output does not work at all (i.e., just no sound, still bytes go through). Rebooting the system does not help.

Any ideas how to go about this?

[hulten]

Controls show all positive values and nothing is muted:

$ mixerctl
inputs.dac-2:3=174,174
inputs.dac-0:1=174,174
record.adc-0:1_mute=off
record.adc-0:1=124,124
record.adc-2:3_mute=off
record.adc-2:3=124,124
outputs.spkr_source=dac-2:3
outputs.spkr_mute=off
outputs.spkr_eapd=on
inputs.mic=85,85
outputs.mic_dir=input-vr80
outputs.hp_source=dac-0:1
outputs.hp_mute=off
outputs.hp_boost=off
outputs.hp_eapd=on
record.adc-2:3_source=mic
record.adc-0:1_source=mic
outputs.mic_sense=unplugged
outputs.hp_sense=unplugged
outputs.spkr_muters=hp
outputs.master=200,200
outputs.master.mute=off
outputs.master.slaves=dac-2:3,dac-0:1,spkr,hp
record.volume=124,124
record.volume.mute=off
record.volume.slaves=adc-0:1,adc-2:3
record.enable=sysctl

[hulten]

I think I did not understand my problem properly. Through a headset, I also do not have sound. It is not a problem specific to the azalia audio device.

[jggimi]

The azalia(4) driver is a generic HD audio driver that manages any hardware which meets the HD Audio 1.0 standard. You're running on the September 3 amd64 snapshot kernel. I just updated to it, and my HD audio hardware -- which is different than yours -- still works.


To figure out what happened with your hardware, I recommend you build kernels, bisecting between a known good kernel and a known bad kernel, to isolate which commit caused the regression. I'd start with HEAD -- just in case there's something uncommitted in the snapshot that caused this, or, if the regression was already found and fixed since the snapshot was built. If there is still an audio failure from your new built kernel, I'd then drop back to a known good kernel and bisect back and forth through commit history to find the culprit.

If you've never built kernels from source before, the release(8) man page has complete instructions. If you clone OpenBSD's github mirror of the src repository into your local /usr/src working directory, git-bisect(1) automates the bisecting process. You just tell it known good and known bad commits, let it select a point-in-time, build, test, and report if its good or bad, lather, rinse, repeat. I can usually find a problem kernel commit in about 7 build/boot/test cycles.

[hulten]

This afternoon I decided to go back to my audio issue. I built and booted a new kernel, but only then I found out that the problem was not in the OpenBSD kernel but a bad environment setting (I had set AUDIOPLAYDEVICE=snd/play, testing different sndiod_flags). Audio works again after removing those.

Thanks for the help. Also, now I know how to build and boot new kernels!