I'm using a Thinkpad Helix 2 with a Core M processor, or the Broadwell platform. On this platform, the soundcard is powered by rt286 / broadwell-audio. With Gnome 3 and PulseAudio, the audio playback just works with Linux 4.0-rc1 without any problem. But when earphones are plugged, it gets audio output with poor quality. I tried two wav files, each contains only left or right channel to debug the problem. I found when using speakers, the audio output works properly. But with earphones, no matter the wav only contains left or right channel, the sound comes from both channels of the earphones. In other words, only mono output is present (no stereo output) when earphones are plugged. System Information: $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: broadwellrt286 [broadwell-rt286], device 0: System Playback/Capture (*) [] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: broadwellrt286 [broadwell-rt286], device 1: Offload0 Playback (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: broadwellrt286 [broadwell-rt286], device 2: Offload1 Playback (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 $ dmesg | grep [ 1.446117] haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19 [ 67.472106] broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> System Pin mapping ok [ 67.472187] broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Offload0 Pin mapping ok [ 67.472264] broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Offload1 Pin mapping ok [ 67.472339] broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Loopback Pin mapping ok [ 67.472359] broadwell-audio broadwell-audio: rt286-aif1 <-> snd-soc-dummy-dai mapping ok [ 67.488806] input: broadwell-rt286 Headset as /devices/pci0000:00/INT3438:00/broadwell-audio/sound/card0/input19 [ 112.061854] haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19
I also tried for-next branch of broonie/sound.git at the latest commit 0179015b2c7f348a48a13cea85c745171b6cf9fd, but the problem still exists.
hi, Jinliang, can we duplicate this on WSB?
hi Tom, have you tried play a stereo file and listen if the left/right channels are rendered on corresponding headphones/speakers?
hi Tom, could you please send your test wav files and test steps(or commands) to us?
Created attachment 168391 [details] Left Channel
Created attachment 168401 [details] Right Channel
Mr.Wang, hello. I uploaded my test wav files. When I'm using speakers, left/right channels work separately without problem. But with earphones, the output comes from both left and right channel with the same volume. I tested them in single user mode under tty, and using aplay to play them. # aplay audiocheck.net_L.wav Playing WAVE 'audiocheck.net_L.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo # aplay audiocheck.net_R.wav Playing WAVE 'audiocheck.net_R.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo I can fully reproduce the issue. So the problem is not related to PulseAudio.
Thank you Tom. I have test the latest Mark Brown's kernel 4.0.0-rc1, commit is 0a32f2366a636d5d36810af92ae4eba6a4231f3b. On Wilson Beach (our test machine), with earphones, I only hear sound of "audiocheck.net_L.wav" form left channel, and hear sound of "'audiocheck.net_R.wav" from right channel. with speakers, thay all work fine. The test commands are: # aplay -D hw:broadwellrt286,0 audiocheck.net_L.wav Playing WAVE 'audiocheck.net_L.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo Warning: rate is not accurate (requested = 44100Hz, got = 48000Hz) please, try the plug plugin # aplay -D hw:broadwellrt286,0 audiocheck.net_R.wav Playing WAVE 'audiocheck.net_R.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo Warning: rate is not accurate (requested = 44100Hz, got = 48000Hz) please, try the plug plugin So I can't reproduce your problem on my side. I tried UI mode and text mode, and also tried kernel 3.19.0, have the same results.
Is this problem related to the headset mode of rt286? https://patchwork.ozlabs.org/patch/459735/ I am going to test this patch today.
Hmmm, with this patch, nothing has changed...Maybe Helix 2 uses some device specific way to deal with earphones output.
Tried to update alsa-lib to git version, that contains ucm files for rt286 with this patch applied http://article.gmane.org/gmane.linux.alsa.devel/138192/match=broadwell+rt286+change+set+capture+volume+device, but it still doesn't fix the issue. It seems the problem is still in kernel space...
assining it to me...
hi, Tom, can you still reproduce this issue? I don't have Thinkpad Helix 2, but can't duplicate it on my DELL XPS 13. please refer to: https://bugzilla.kernel.org/show_bug.cgi?id=93361
Yes, I can STILL reproduce the problem on Linux 4.2 with a fresh system. First, I compile the Linux kernel, second, I install the latest linux-firmware from git, then, I installed the alsa-utils and alsa-tools. the version of all userspace-alsa is 1.0.29. And finally, reboot the system. Now, I'm able to play a audio file, but there will be no sound. If I unmute SPO in alsamixer, then the speakers will start working with proper stereo sound. If I plug the earphones in, I have to unmute HPO L and HPO R, then the problem appears: a test audio which contains only left/right channel will come from both channels. Further, if I unmute the HPO L, but not HPO R, the audio contains only right channel will be no sound because it is muted, but the audio contains only left channel will come from both left and right earphones. Vice versa, If I unmute HPO R but not HPO L, the audio contains only left channel will be no sound, but the audio contains right channel will come from both earphones. I think it is a hardware/BIOS related issue. BTW, I have seen there are some hardware-specific hacks for Dell XPS 13 in the driver, that's why XPS 13 works well. I think adding hardware-specific hacks for Helix 2 is the only way to solve it.
BTW, the driver for Windows set the sound card to a completely different mode. I think it is similar to Dell XPS 13. I have to shut down the computer and perform a cold-boot when switching from Linux to Windows or from Windows to Linux to make sure that Linux or Windows has sound output. Earphones output on Windows doesn't have any issue and works flawlessly.
I'm not sure whether the problem is related to the userspace-ALSA tools/utils v1.0.29. ALSA always releases only a single version per year, v1.0.30 that contains rt286 patches will probably released in 2016. I'll try userspace ALSA tools/utils from git repo for the live version to verify if it makes any difference.
I just fixed the bug by myself! I feel hopeless and boring for this issue, and just now, I started to read rt286 source code as an entertainment, I saw a line of code to enable the combo jack, suddenly, I wonder whether the combo jack causes problems, I added my Helix 2 to the combo jack list, and right now the left and right channels for earphones are working properly! I'll provide a kernel patch soon.
Created attachment 187961 [details] This patch adds Thinkpad Helix 2nd to force_combo_jack_table, and fixes the issue of earphones
cool, Tom!
+Bard. I remember Bard added this to force combo jack enabled for WSB SDS. so, for Thinkpad Helix 2nd, it also use combo jack, right?
Yes, there is no output/microphone input but a combo jack on Thinkpad Helix 2nd.
just for the records I just bought the same hardware a few weeks ago and also ran into the same sound issue with debian stretch (kernel 4.8). After upgrading the UEFI-Bios to N17ET90W (1.90) plus additional loading of "OS-optimized" Defaults Settings, the sound issue disappeared. The firmware can be updated with the n17ur44w.iso from lenovo website. Unfortunately you need an external usb-cdrom, as the Bios does not recognize the Bootloader on the iso image if put to usb-sticks. Please note that you might need to restore the bootloader after loading Default Settings in the Bios. I'd bet that a Windows Bootloader Entry would have been left untouched.
sorry wrong bug, my comment was meant for https://bugzilla.kernel.org/show_bug.cgi?id=153901
Patch has been here for nearly two years without any responses... I just submitted the patch to LKML, hopefully it can be fixed soon.
The patch has been merged into today's linux-next, as fe0dfd6358a17c79bd7d6996af7512ba452a7059, hooray!
The patch has been included in Linux 4.12, also 4.9.37 and 4.11.10. Finally the issue is completely fixed, after two years, by myself ;-).