No sound from right audio channel

[joshua]

No audio comes out of the right speaker on the laptop. When playing a test video such as https://www.youtube.com/watch?v=hTvJoYnpeRQ the right-channel audio is never heard (i.e., it does not get converted into mono and played through the left speaker).

When plugging in headphones, audio is heard from both channels.

In Windows, both speakers work, so it is not a physical problem with the speakers.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: linux-image-4.13.0-12-generic 4.13.0-12.13 [modified: boot/vmlinuz-4.13.0-12-generic]
ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
Uname: Linux 4.13.0-12-generic x86_64
ApportVersion: 2.20.7-0ubuntu1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: user 1127 F.... pulseaudio
CurrentDesktop: ubuntu:GNOME
Date: Sat Oct 7 12:58:01 2017
InstallationDate: Installed on 2017-10-07 (0 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170926)
MachineType: HUAWEI HUAWEI MateBook X
ProcEnviron:
 PATH=(custom, no username)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.13.0-12-generic.efi.signed root=UUID=f0a69f35-7c1e-4280-b325-6b7fec6e174a ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-4.13.0-12-generic N/A
 linux-backports-modules-4.13.0-12-generic N/A
 linux-firmware 1.168
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/14/2017
dmi.bios.vendor: HUAWEI
dmi.bios.version: 1.12
dmi.board.name: HUAWEI MateBook X
dmi.board.vendor: HUAWEI
dmi.board.version: 2.0
dmi.chassis.type: 10
dmi.chassis.vendor: HUAWEI
dmi.modalias: dmi:bvnHUAWEI:bvr1.12:bd08/14/2017:svnHUAWEI:pnHUAWEIMateBookX:pvr2.0:rvnHUAWEI:rnHUAWEIMateBookX:rvr2.0:cvnHUAWEI:ct10:cvr:
dmi.product.family: HUAWEI MateBook
dmi.product.name: HUAWEI MateBook X
dmi.product.version: 2.0
dmi.sys.vendor: HUAWEI

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.14 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14-rc4

[joshua (there)]

It never worked properly as far as I know. The problem still exists with 4.14-rc7.

Linux mi 4.14.0-041400rc7-generic #201710292231 SMP Sun Oct 29 22:32:07 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

[Kai-Heng Feng (kaihengfeng)]

Please try kernel here,
http://people.canonical.com/~khfeng/lp1721987/

[joshua (there)]

Hi, I get the same result with that kernel.

[ 0.000000] Linux version 4.14.0-rc7-lp1721987 (khfeng@Precision-3520) (gcc version 7.2.0 (Ubuntu 7.2.0-12ubuntu1)) #1 SMP Mon Nov 6 04:50:16 EST 2017

[Kai-Heng Feng (kaihengfeng)]

FWIW, the original connection is 0x17 -> 0x0d -> 0x03. I override it with 0x17 -> 0x0c -> 0x02, which is same as ALC298_FIXUP_SPK_VOLUME. Unfortunately it didn't work for you.

Please file an upstream bug at https://bugzilla.kernel.org
Product: Driver
Component: Sound(ALSA)

[jcs (jcs-linux-kernel-bugs)]

Created attachment 260537
dmesg

No audio comes out of the right speaker on the laptop. When playing a test video such as https://www.youtube.com/watch?v=hTvJoYnpeRQ the right-channel audio is never heard (i.e., it does not get converted into mono and played through the left speaker).

When plugging in headphones, audio is heard from both channels.

In Windows, both speakers work, so it is not a physical problem with the speakers.

This is being moved upstream from the Ubuntu bug at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1721987

alsa-info.sh output at http://www.alsa-project.org/db/?f=dbe13f8a856c2178d5794cb787b153b6ce311a80

[joshua (there)]

I've filed an upstream bug https://bugzilla.kernel.org/show_bug.cgi?id=197801

[jcs (jcs-linux-kernel-bugs)]

Created attachment 260539
alsa-info.sh output

[jerin04 (jerin04-linux-kernel-bugs)]

Hello, is this bug assigned to anyone? Never used bug tracker before.

Just want put more voice to this bug as I have a Matebook X as well. Only one of the speakers work. I am sure there are others buying this machine and wants to run linux variants.

Some more info in case it helps: https://github.com/lidel/linux-on-huawei-matebook-x-2017

[samsau (samsau-linux-kernel-bugs)]

Bump.
I am one of the aforementioned 'others'. The problem is rather annoying and hasn't been solved as of 4.15.

[Daniel Martin (dmanlfc)]

Did you try the laptop-dmic parameter?

sudo nano /etc/modprobe.d/alsa-base.conf

add to the bottom of the file:
options snd-hda-intel model=laptop-dmic

And reboot.

[hajek1 (hajek1-linux-kernel-bugs)]

Mee too. I can confirm the problem on 4.16.13-1-ARCH kernel.

[tiwai (tiwai-linux-kernel-bugs)]

From the given alsa-info.sh output, there is nothing wrong there.
So it must be some vendor-specific initialization, and only Huawei knows.
Try to contact your vendor.

[jcs (jcs-linux-kernel-bugs)]

Obviously contacting my vendor went nowhere.

While doing more testing, I get the same result of audio only through one speaker in Windows 10 with the default audio drivers that Windows ships with. The Realtek/Dolby audio drivers from the vendor (Huawei) need to be installed in order to get sound out of both speakers in Windows, too.

I've been playing with VFIO to be able to boot Linux and hand off the PCI audio device to Windows 10 inside of qemu with the proper Realtek Windows drivers installed. This allows me to log all of the PCI IO activity from qemu.

While doing this, I noticed that if I boot Windows 10 in qemu, then boot Linux in qemu, audio works in Linux through both speakers with no other changes. This only works through qemu/VFIO, as rebooting the full system resets the PCI device.

So something must be getting initialized or toggled on the device in Windows that affects the device through to initialization in Linux. One of the pins that the device presents is configured slightly different in Linux after booting Windows first (nid 0x19 0x411111f0 -> 0x811111f0), and I've tried explicitly setting that pin configuration in Linux without booting Windows first but it has no effect.

I have qemu logging all of the VFIO PCI reads and writes under Windows, and I instrumented some custom code to store the RIRBLBASE and CORBLBASE values and then print out the contents of those DMA addresses (+ current queue offset) whenever CORBWP/RIRBWP are written to, in order to be able to see the commands submitted to the CORB and the response from the RIRB when running Windows.

Is there anything else similar to the CORB/RIRB that I should be logging to try to see what else the Windows driver could be doing?

VFIO limits the emulated Windows instance to see only the PCI audio device, so there is no ACPI configuration or other IO that it could be doing other than PCI config read/write, PCI region read/write, and DMA with the audio device. But still, there must be something the

[jcs (jcs-linux-kernel-bugs)]

Here is the magic sequence of CORB commands needed to enable both speakers. This is actually part of a much larger sequence that the Windows driver does, but through trial and error, this is the minimum required to make both speakers work.

I can attach the full PCI I/O and CORB logs if needed, but it's 4.6Mb.

I have no idea what these commands do, but nid 0x6 is a DAC and 0x20 is a vendor-specific nid. It looks like the same sequence repeating over and over, but the params to 0x400 and 0x500 commands change slightly.

nid:0x6 verb:0x73e param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0xc00 param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0xc00 param:0x0
nid:0x6 verb:0x73e param:0x80
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0xc00 param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0x4f0 param:0x0
nid:0x20 verb:0x500 param:0x22
nid:0x20 verb:0x400 param:0x31
nid:0x20 verb:0x500 param:0x23
nid:0x20 verb:0x400 param:0xb
nid:0x20 verb:0x500 param:0x25
nid:0x20 verb:0x400 param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0x4b0 param:0x10
nid:0x6 verb:0x73e param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0xc00 param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0x4b0 param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0xc00 param:0x0
nid:0x21 verb:0xf09 param:0x0
nid:0x6 verb:0x73e param:0x80
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0xc00 param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0x4f0 param:0x0
nid:0x20 verb:0x500 param:0x23
nid:0x20 verb:0x400 param:0xc
nid:0x20 verb:0x500 param:0x25
nid:0x20 verb:0x400 param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0x4b0 param:0x10
nid:0x6 verb:0x73e param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0xc00 param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0x4b0 param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0xc00 param:0x0
nid:0x6 verb:0x73e param:0x80
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0xc00 param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0x4f0 param:0x0
nid:0x20 verb:0x500 param:0x23
nid:0x20 verb:0x400 param:0xd
nid:0x20 verb:0x500 param:0x25
nid:0x20 verb:0x400 param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0x4b0 param:0x10
nid:0x6 verb:0x73e param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0xc00 param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0x4b0 param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0xc00 param:0x0
nid:0x6 verb:0x73e param:0x80
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0xc00 param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0x4f0 param:0x0
nid:0x20 verb:0x500 param:0x23
nid:0x20 verb:0x400 param:0xe
nid:0x20 verb:0x500 param:0x25
nid:0x20 verb:0x400 param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0x4b0 param:0x10
nid:0x6 verb:0x73e param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0xc00 param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0x4b0 param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0xc00 param:0x0
nid:0x6 verb:0x73e param:0x80
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0xc00 param:0x0
nid:0x20 verb:0x500 param:0x26
nid:0x20 verb:0x4f0 param:0x0
nid:0x20 verb:0x500 param:0x23
nid:0x20 verb:0x400 param:0xf
nid:0x20 verb:0x500 para...

[tiwai (tiwai-linux-kernel-bugs)]

(In reply to jcs from comment #7)
> Here is the magic sequence of CORB commands needed to enable both speakers.
> This is actually part of a much larger sequence that the Windows driver
> does, but through trial and error, this is the minimum required to make both
> speakers work.

That's great!

> I can attach the full PCI I/O and CORB logs if needed, but it's 4.6Mb.

If the minimal verbs work, it's fine without the full log.

> I have no idea what these commands do, but nid 0x6 is a DAC and 0x20 is a
> vendor-specific nid. It looks like the same sequence repeating over and
> over, but the params to 0x400 and 0x500 commands change slightly.

Right, NID 0x20 is the typical widget Realtek codecs use for accessing the COEFs.
NID 0x06 is the DAC, but the verb issued there (0x73e) looks like some non-standard one. Judging from the value used with the verb (0x00 and 0x80), it might be an extra AMP control or such.

The verb 0x500 and 0x400 are in a pair to set the COEF index and value, respectively.
The verb 0xc00 is the verb to read the COEF value of the current index.
So, it implies that Windows driver performs some reads & modify sequences.
But we cannot know which bits are actually tested, so we have to stick with the static values.

That is, likely you can remove the sequence 0x5xx:xx 0xCxx:xx.

BTW, the verb and the parameter compose 20bit values, so verb 0x4f0 param 0x00 is equivalent with the verb 0x400 param 0xf000.

[post (post-linux-kernel-bugs)]

Hi there,

I am also struggling with the right speaker on my Matebook X.
Is this still being worked on and can I assist in any way ?

[tomas.fufa (tomas.fufa-linux-kernel-bugs)]

I blindly applied the verbs sequence to master's sound/pci/hda/patch_realtek.c, and stereo it's now working perfectly. Not an expert, just a very thankful user ;)
https://github.com/tespeleta/linux/commit/761cca49e9153b7832fa3f887b875e5ad1517892

[tomas.fufa (tomas.fufa-linux-kernel-bugs)]

I managed to re-create the recurring pattern and clean the code. I submitted a patch to alsa-dev. https://patchwork.kernel.org/patch/10764291/

[Reda Borchardt (omegadota)]

Would there be by any chance a way to send that magic sequence through the bus using a script or tool from within the terminal?

I am on Manjaro 4.19.16.1 and I was unable to recompile my kernel using the patch, replacing the c file or manually editing it. My notebook takes about 4 hours to compile the kernel, which does not help.

Here is my information: http://www.alsa-project.org/db/?f=4bbd25ca31126e42e28f73c16143d1158b6eb27a

PS: Wonderful work by the way. I just wished I could hack this myself into the patch_realtek.c file for Manjaro. However, I am hoping that sending the magic sequence while the machine is running might work too. I just wouldn't know how.

[Reda Borchardt (omegadota)]

After reading the Linux audio sub system documentation I discovered /sys/class/sound/hwC0D0 and hda-verb. That will hopefully do the trick.

[Reda Borchardt (omegadota)]

Ok, I got it working without needing to recompile the kernel. Make sure that you have the alsa-tools installed on your machine. Running the attached script at runtime will send the necessary verbs to the sound card to enable the right speaker.

Here is my systemd service file to launch it at startup. (Type idle is important to launch it at the end)

[Unit]
Description=Huawei-soundfix

[Service]
Type=idle
ExecStart=/usr/bin/bash /usr/bin/huawei-sound.sh

[Install]
WantedBy=multi-user.target
~

[Max Fuxjäger (maxvalue)]

Hey, I tried the script solution together with the systemd service file. It works very nicely!

I noticed that you also have to run the script when the device wakes from standby (e.g. closing-reopening the lid).
For that to work, you have to add a few more targets to WantedBy (I just searched around, I did not test which ones you really need for that to work):

suspend.target hibernate.target hybrid-sleep.target

[Reda Borchardt (omegadota)]

It never ceases to amaze me how collectively we manage to overcome these issues. Yes, your wantedby list is a great addition. The left speaker is so loud I hardly noticed the lack of stereo after waking.

[Sid (siddharth2986)]

Still, the issue with the right speakers persist. I am not proficient in running or compiling scripts or programs in Linux. I am currently running Ubuntu 19.04. The strange thing I noticed is that the power switch toggle [even a soft toggle without fully turning on/off] fixes the right speaker immediately. However, whenever there is loud audio, the right speaker turns off (i don't know if its some channel or stream that turns off).

[tiwai (tiwai-linux-kernel-bugs)]

This bug has been forgotten for a while, sorry for that.

Since the verbs are reverse-engineered and there is a significant risk of breakage, we shouldn't apply it as default *yet*. So, instead, the workaround is applied when user explicitly specifies the model=huawei-mbx-stereo option to snd-hda-intel module.

The patch was submitted to upstream and I'm going to merge for 5.4 kernel.

[tiwai (tiwai-linux-kernel-bugs)]

Created attachment 284299
The patch that will be merged for 5.4 kernel

Should be applicable on 5.3 kernel cleanly.

[Todd Patt (capnzyrain)]

I was still having problems with my Lenovo Legion laptop, this is one of the pages where I stopped in and tried everything on it, to no avail. It looks like the specific issue here was fixed, and any other info I found on the internet was not working either.

Turns out that by default, headphone jack had right channel turned all the way down! Here's what I did to fix:

Open terminal window. Execute command: sudo alsamixer
This is a terminal-based application that allows you to change audio output levels for different ports. You may need to press F6 to select your sound card -- mine was selected when I started the application. Basically Master and PCM all had both left and right channels maxed into the red zone. Headphones ONLY had the left channel. Press the right-arrow on your keyboard to go over to Headphones, then press the up-arrow repeatedly and the right channel level should increase, take it to the max with the left channel. Exit Alsa Mixer with the escape key.

This fixed it but then the audio in the right channel, for whatever reason, was extremely quiet. I went into Ubuntu's basic sound settings window (Settings > Sound). I made sure I had the "Headphones - Built-in Audio" selected in the dropdown box for Output, then drug the balance slider all the way to the left and let go of mouse button. Then all the way to the right and let go of mouse button. Then back to the middle and let go of the mouse button.

Now it was working and sounded great! I went back into alsamixer one more time, and noticed the right channel on the headphones had dropped a tiny notch compared to the left. I put it back to max, and exited Alsa Mixer.

I now have no problems with my headset! If you're still struggling even though this bug fix was released a year ago, try my simple suggestion before you go all crazy editing files. It might save you many hours of internal screaming :)