No sound from right audio channel

Bug #1721987 reported by joshua on 2017-10-07
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Linux
Confirmed
Medium
linux (Ubuntu)
Medium
Unassigned

Bug Description

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

joshua (there) wrote :

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Joseph Salisbury (jsalisbury) wrote :

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

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Incomplete
joshua (there) wrote :

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

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
tags: added: kernel-bug-exists-upstream
joshua (there) wrote :

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

joshua (there) wrote :
Kai-Heng Feng (kaihengfeng) wrote :

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)

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) wrote :

Created attachment 260539
alsa-info.sh output

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

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) wrote :

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.

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

Changed in linux:
importance: Unknown → Medium
status: Unknown → Confirmed

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.

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

Download full text (20.2 KiB)

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...

(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.

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 ?

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

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

Guy Baconniere (lordbaco) wrote :

This is my backport of Tomas Espeleta's patch to Linux 4.15.18 (linux-source-4.15.0 / 4.15.0-45.48 available on Ubuntu 18.04.2 LTS)

tags: added: patch
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.