1

This randomly started happening today. Yesterday I opened up my laptop to clean it out. I also disconnected the CMOS battery cable by mistake.

When I open alsamixer in a terminal, the following things happen when I try to control the channels:

  • Controlling the 'PCM' channel is the only way for me to change the volume.

  • Using the up/down arrow keys when selecting the master channel, it changes the numbers but doesn't actually change the volume. Even weirder: controlling the master volume mutes it instead. It also mutes the headphone channel, but not the speaker channel.

  • Unmuting the master channel by pressing 'M' doesn't bring the audio back. To do that, I have to press Fn+F1, which is bound to pactl set-sink-mute 0 toggle in sxhkdrc (using bspwm).

  • Using Fn+F2/F3 (bound to pactl set-sink-volume 0 -/+ 5%) to decrease/increase changes the master channel but doesn't change the audio, but also doesn't mute it.

  • (un)Muting the headphone channel doesn't do anything to the audio. Increasing/decreasing the headphone channel doesn't change the volume.

  • Muting the master channel also mutes the headphone channel, but unmuting the master channel doesn't unmute the headhpone channel.

  • I can't get the speakers to work at all.

  • When I lower the master channel using the function keys all the way to 0, the headphone channel goes down as well. When the headphone channel gets to 0, it mutes only the right channel (wtf?).

Everything works in Windows (I did have a problem with audio drivers in Windows but a reboot fixed it) and in Ubuntu 18.10 on a USB live stick. I'm on a laptop (Lenovo Legion Y520) running Arch Linux. According to alsamixer I'm using the HDA Intel PCH soundcard and Realtek ALC233 chip.

EDIT: I saw in pavucontrol that I have two audio outputs: Headphones and Speakers. Next to speakers, it says 'unavailable'.

EDIT: dmesg: https://pastebin.com/YUr4MyDf

output of ls /proc/asound/card*/codec*:

/proc/asound/card0/codec#0

/proc/asound/card0/codec#2

Improve this question
1
  • I just tried that and now only my left headphones work. wtf? EDIT: I rebooted again and now both sides work. Weird Commented Nov 3, 2018 at 23:24

2 Answers 2

Reset to default
3

You are seeing the pulse plugin control, which only has a single volume control. Try using F6 to access the hardware control(s) of your sound card(s).

However, since you are now running Pulseaudio as your main audio system (possibly you rebooted for the first time because of the cleaning, and it's the consequence of some update you did a longer time ago?), I'd recommend to leave alsamixer alone, and use pavucontrol or the sound settings of your Desktop (if you are using one) instead.

Using both can misconfigure the intermediate amplifiers, causing clipping and sound distortion.

As you already played around it with, you may to have to use alsamixer once to restore everything to a good state (e.g. unmute accidentally muted nodes, etc.)

Edit

Your codec is properly recognized:

[ 3.845593] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) ... [ 3.883968] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC233: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker [ 3.883969] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 3.883970] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x21/0x0/0x0/0x0/0x0) [ 3.883971] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 [ 3.883972] snd_hda_codec_realtek hdaudioC0D0: inputs: [ 3.883973] snd_hda_codec_realtek hdaudioC0D0: Mic=0x19 [ 3.883974] snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x12

but soon after, something fails fails:

[ 16.496761] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x202f2d00 [ 17.500096] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x202f2d00 [ 18.510492] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x202f2d00

and then things start to look funny:

[ 138.168712] azx_single_send_cmd: 14 callbacks suppressed [ 391.888726] azx_single_send_cmd: 34 callbacks suppressed [ 403.161786] azx_single_send_cmd: 114 callbacks suppressed [ 447.315584] azx_single_send_cmd: 46 callbacks suppressed [ 514.846522] azx_single_send_cmd: 70 callbacks suppressed

So, guess: While cleaning your laptop (unless you did something else you didn't tell us about), you caused electrostatic discharge, and/or the battery cable you disconnected by accident touched something it shouldn't, and now something relating to sound card/codec communication doesn't work properly.

This will be difficult to properly diagnose and fix. You can play around with hda-verb and look at the contents of the codec file, and see if you can further narrow down the problems, but to do this, you need to read up on how this stuff works. It's not something we can remotely debug with a Q&A.

I don't know why it works in Windows and doesn't work in Linux. Possibly Windows initializes the hardware differently.

Improve this answer
20
  • 1
    hda intel pch is your hardware. If you don't see controls, possibly the Intel Soundcard can't find the codec. Have a close look at dmesg after boot; if you don't understand edit, upload it into pastebin etc. and edit question with link. Also, edit question with output of ls /proc/asound/card*/codec*. Commented Nov 4, 2018 at 10:39
  • 1
    If it's software related, the place to look is in the kernel (though the Intel HDA soundcard should be sufficiently stable). Ubuntu is 4.18.0, Arch is 4.18.16 (custom built?). Try a 4.18.0 kernel on Arch and see what happens. If it works, file a regression bug on the kernel bugtracker. Commented Nov 4, 2018 at 15:31
  • 1
    The question remains why it has to fall back to single command mode on Arch, but doesn't on Ubuntu ... And if the Codec single command mode is a red herring, the question is what else doesn't work. Commented Nov 4, 2018 at 15:35
  • 1
    My money is still on "static discharge etc. screwed up a hardware circuit somewhere, now it's acting randomly and sometimes works, sometimes doesn't". Commented Nov 8, 2018 at 11:18
  • 1
    Again: Windows uses a different hardware initialization/access sequence, which doesn't cause the problematic hardware part to act up. (But all this is a guess, and hard to confirm). Commented Nov 8, 2018 at 13:19
0

I fixed it with this: https://help.ubuntu.com/community/HdaIntelSoundHowto#Playing_with_probe_mask

I still have an error in dmesg: snd_hda_intel 0000:00:1f.3: control 2:0:0:PCM Playback Volume:0 is already present, but I don't experience any problems.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.