XPS 13 9360 and 9350, Realtek ALC3246, Headphone audio hiss

Bug #1654448 reported by Andrew McLeod on 2017-01-06
84
This bug affects 14 people
Affects Status Importance Assigned to Milestone
Dell Sputnik
Undecided
Unassigned
alsa-driver (Ubuntu)
Medium
Unassigned
linux (Ubuntu)
Medium
Kai-Heng Feng
pulseaudio (Ubuntu)
Medium
Unassigned

Bug Description

Pertaining to 16.04 on a dell XPS 13 9360

ii alsa-base 1.0.25+dfsg-0ubuntu5

Advanced Linux Sound Architecture Driver Version k4.4.0-57-generic.

When headphones are plugged in, there is a clearly audible hiss (white noise). This is present as soon as the headphones are plugged in, whether 'headphones' or 'headset' are selected from the pop-up box.

Using alsamixer to debug the issue reveals that it is related to "Headphone Mic Boost" - the default setting is: dB gain 0.00, 0.00. If this is changed to:

10.00, 10.00 (one notch up) the hiss disappears.
20.00, 20.00 cause a louder hiss and
30.00, 30.00 causes an even louder hiss with high frequency audio artifacts.

When the headphones are removed and plugged back in the Headphone Mic Boost setting returns to dB gain 0 and the problem also returns.

This (problem and workaround) has been reported in the wild: https://news.ycombinator.com/item?id=13050843 and https://www.reddit.com/r/Dell/comments/4j1zz4/headphones_have_static_noise_with_ubuntu_1604_on/ for example

spike speigel (frail-knight) wrote :

I'm experiencing the same issue:

Dell XPS 13 Developer Edition

BIOS v1.3.2

Ubuntu 16.04

spike@blackhole:~$ uname -a
Linux blackhole 4.4.0-64-generic #85-Ubuntu SMP Mon Feb 20 11:50:30 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

spike@blackhole:~$ apt search alsa-base
Sorting... Done
Full Text Search... Done
alsa-base/xenial,xenial,now 1.0.25+dfsg-0ubuntu5 all [installed]
  ALSA driver configuration files

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in alsa-driver (Ubuntu):
status: New → Confirmed
spike speigel (frail-knight) wrote :

I would like to share that I found this post referring to a similar issue where sound settings weren't maintained, maintained being a better word than saved because I believe alsamixer might properly save the settings.

According to the post it is pulseaudio which is actually modifying the settings:

http://askubuntu.com/a/549939

I tested as suggested, by modifying the "Headphone Mic Boost" within alsamixer and exiting. I then ran:

pulseaudio -k

And pulseaudio reset the "Headphone Mic Boost" to dB gain 0.00, 0.00. The hissing reappeared.

If I could get pulseaudio to stop resetting the "Headphone Mic Boost" in alsamixer, then that would be an acceptable workaround.

But, I think the real issue still needs to be resolved. One would expect a dB gain 0.00, 0.00 to be absolutely silent. The user should not need to kick it up a notch to dB gain 10.00, 10.00.

bwat47 (bwat47) wrote :

This bug is pretty obnoxious...

So far the only way I've found to get the alsamixer settings to persist without pulseaudio repeatedly undoing it is editing the pulseaudio config files per the arch wiki here:

https://wiki.archlinux.org/index.php/Dell_XPS_13_(9350)

Hissing/Crackling noises when using headphones section

Unfortunately this disabled the internal mic completely though and the changes will get reset when pulseaudio is updated.

spike speigel (frail-knight) wrote :

It is!

I've also kept this one-liner in my bash history so I don't have to enter alsamixer and use multiple key strokes:

amixer -c 0 set 'Headphone Mic Boost',0 1

tags: added: 9360 alsa dell headphones pulse realtek xenial xps
bwat47 (bwat47) wrote :

It looks like there was some activity with a kernel patch from someone at canonical at some point: https://patchwork.kernel.org/patch/9128611/

spike speigel (frail-knight) wrote :

What's the diff between ALC256 and ALC3246?? It seems the 9350 has the ALC3246 as well.

spike speigel (frail-knight) wrote :

ALC256 looks like a codec, and I always thought ALC 3246 was the Realtek "model/chip". Not sure if my thoughts on that are accurate.

spike speigel (frail-knight) wrote :

Looks like that patch has just sat there since last year :(

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in pulseaudio (Ubuntu):
status: New → Confirmed
Esokrates (esokrarkose) wrote :

Subscribed Kai-Heng Feng, the submitter of the linked patch (https://patchwork.kernel.org/patch/9128611/), maybe he could give a status update!?

My two machines are affected too (XPS 13 9360), confirming the workaround from #5

amixer -c 0 set 'Headphone Mic Boost',0 1

Kai-Heng Feng (kaihengfeng) wrote :

The patch is included in mainline, and it's included in Xenial since 4.4.0-25.
Also, our testing machines are not the final mass production version - I'll try get one and take a look on it.

commit 423cd785619ac6778252fbdb916505aa1c153959
Author: Kai-Heng Feng <email address hidden>
Date: Fri May 20 15:47:23 2016 +0800

    ALSA: hda - Fix headphone noise on Dell XPS 13 9360

Esokrates (esokrarkose) wrote :

Wow, thanks for the quick reply, I am willing to provide any information you need, thanks very much for having a look.

Esokrates (esokrarkose) wrote :
Esokrates (esokrarkose) wrote :

The mentioned workaround

amixer -c 0 set 'Headphone Mic Boost',0 1

has the drawback of significantly lowering the headphone volume!
You can easily test it listening to audio and switching back to

amixer -c 0 set 'Headphone Mic Boost',0 0

tags: added: zesty
affects: pulseaudio → dell-sputnik

@frail-knight, the right people are already subscribed to this bug. Please *stop* changing bugs to affect dell-sputnik

Changed in dell-sputnik:
status: New → Incomplete
status: Incomplete → Invalid
no longer affects: dell-sputnik
Kai-Heng Feng (kaihengfeng) wrote :

I can't hear the hiss sound... either I am getting old or my headset is choppy.

Can you test the latest mainline linux kernel [1] to see if it helps?

[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.12-rc1/

Daniel van Vugt (vanvugt) wrote :

Comment #12 suggests the fix is already released (a kernel fix). However that also suggests the fix was released before the bug was reported :) So logic says that first fix didn't work(?).

Andrew: as original reporter can you please update your system and retest?

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Changed in alsa-driver (Ubuntu):
importance: Undecided → Medium
Changed in pulseaudio (Ubuntu):
importance: Undecided → Medium
spike speigel (frail-knight) wrote :

Here's an earlier bug report (~Dec 2015):

http://lkml.iu.edu/hypermail/linux/kernel/1512.1/02819.html

Esokrates (esokrarkose) wrote :

Kai, I have tested the 4.12 mainline kernel. The hiss is clearly audible.
Please make suggestions how I can help you.

My earphones are Bose Soundtrue Ultra, but I guess that wont be helpful to know.

Esokrates (esokrarkose) wrote :

Addendum to the original description:

Steps to reproduce:

0. Make sure tlp is NOT installed
1. Plug in headphones
2. Make sure volume is not muted!

NOTES:
Ad 0.: tlp configures audio power saving, the hiss is only noticeable when listening to music.
Ad 2.: If the headphones are muted then there is no hiss.

spike speigel (frail-knight) wrote :

I would like to say I have plain old Sony earbuds, and the sound is very noticeable without playing any sound what so ever. As previously mentioned, upping the dB gain on the headphone mic boost from 0.00 to 10.00 completely stops the hissing for whatever reason.

Also, the Arch Linux wiki has some related notes regarding TLP and hissing through headphones reported. I've not messed with TLP at all. /etc/default/tlp as referenced in the wiki does not exist on my system.

https://wiki.archlinux.org/index.php/Dell_XPS_13_(9360)#Troubleshooting

spike speigel (frail-knight) wrote :

Out of curiosity I tried my Bose Quiet Comfort 15s, and I can't detect the hiss in those at either a dB gain of 0.00 or 10.00 with the headphone mic boost.

That is odd.

Daniel van Vugt (vanvugt) wrote :

Please try both cable types of the Bose Quiet Comfort (assuming you have two). And you might want to try my favourite trick of plugging in via a headphone splitter/extension/adapter. Sometimes you just have to piggyback on a different connector to get a clean connection.

I'm not saying the primary bug isn't in the laptop, but it's also likely one or some people affected here also suffer from physical connector problems. Always happens...

Kai-Heng Feng (kaihengfeng) wrote :

Please try this kernel: http://people.canonical.com/~khfeng/lp1654448/
AAMIX is disabled, I can't verify it through my bad ear though.

Changed in linux (Ubuntu):
assignee: nobody → Kai-Heng Feng (kaihengfeng)
Esokrates (esokrarkose) wrote :

@spike speigel: The tlp issue in the arch Linux wiki is unrelated. The point I was that when tlp is installed and no audio is currently playing, tlp turns off the sound card and thus the hiss disappears.
The second point I was trying to say: Of course the white noise is audible when nothing is playing, but only if audio is not muted.

@Kai-Heng Feng: Unfortunately I can't boot your kernel (BTRFS error: could not find root 8).
Could you give me the applied patch or supply a more recent kernel build?

Esokrates (esokrarkose) wrote :

Regarding the Bose Quiet Comfort ... those are noise cancelling headphones, it is no surprise to me that those cancel the hiss.
I have tested multiple normal earphones and I can reproduce the issue everytime.

spike speigel (frail-knight) wrote :

@vanvugt I do have both cable types (with and without cable mic). In testing the Quiet Comfort 15s:

Bose CQ 15 w/ normal cable - The hiss is present with 0 dB headphone mic gain, but far more reduced than the Sony earbuds. It is almost unnoticeable. If I weren't trying to hear it, I'd miss it.

Bose CQ 15 w/ mic cable - I cannot detect any hiss present with 0 db gain.

@esokrarkose I'm sorry I misunderstood what you were saying about your experience with the hiss. I thought you were saying it only happened while playing a sound. I too experience the constant hiss with my earbuds. I don't doubt the hiss in normal headphones.

The Bose CQs do produce the hiss with one cable type. It is barely noticeable and much more subdued than the earbuds. I'm not sure what Bose does if anything with the sound signal coming from the headphone jack. Maybe it's just reduced due to higher quality speakers than say my earbuds. As I understand it the noise cancellation is meant for external sounds, but like you said, maybe it plays a role in making the hiss less audible. The noise cancellation itself does produce a level of white noise.

Daniel van Vugt (vanvugt) wrote :

There are multiple variables here you need to consider...

The headset socket is 4-contact to support headphones with built-in microphone. So if you plug in a 4-contact jack then you are more likely (not guaranteed) to get a clean connection (4 contacts touching 4 separate contacts).

However a "clean" connection is not helpful if you've plugged in the wrong type of headset. See there are different types (too many):

  https://technosyndicate.files.wordpress.com/2012/12/122312_0549_common35mm11.png
  http://www.cablechick.com.au/blog/understanding-trrs-and-audio-jacks/

So an imperfect connection is pretty common. And an imperfect connection might touch the laptop's mic contact to something else. In fact if you get a pair of Bose Quiet Comfort QC25 then you have a choice between buying one with Apple support or Samsung/Android support (although some stores will only stock Apple). One doesn't work in the other but they both appear to be identical 4-contact 3.5mm jacks.

Yes indeed this can be fixed in software to silence or reduce noise from the mic line. But remember it's a hardware problem as well as a software problem. You should try both hardware and software solutions.

Kai-Heng Feng (kaihengfeng) wrote :

@Esokrates that's weird. I can install the kernel, even on my Zesty machine.

This is for Zesty,
http://people.canonical.com/~khfeng/lp1654448-zesty/

summary: - XPS 13 9360, Realtek ALC3246, Headphone audio hiss
+ XPS 13 9360 and 9350, Realtek ALC3246, Headphone audio hiss
Daniel van Vugt (vanvugt) wrote :

^^^
Confirmed on an XPS 13 9350 too. And the 'Headphone Mic Boost' workaround works. Although like others, I find that concerning since it should in theory make the problem worse or make no difference.

Also confirmed the problem persists with:
 * 3-contact earphones (Sony)
 * 4-contact Apple Earpods
 * 4-contact Bose AE2 headphones (Apple-compatible cable)

All of these experience the hiss, but the Bose almost none (much harder to notice). I think the most interesting test should be to try some proper Android/Samsung/Nokia wired headphones/earphones in future.

If it turns out there's nothing wrong with the physical connection then this sounds like a kernel problem still.

kaihengfeng: I have just tested your kernel on zesty and it made no difference. The problem remains and the same old amixer workaround is required.

Esokrates (esokrarkose) wrote :

@vanvugt: The earphones I tested (Bose Soundtrue Ultra) are Android ones. I have also tested headphones with no microphone (Sennheiser HD202).

@kaihengfeng: I will install Ubuntu from scratch in order to test your kernelsl

Esokrates (esokrarkose) wrote :

Confirming Daniel van Vugt: The kernel http://people.canonical.com/~khfeng/lp1654448/ does not improve the situation.

Kai-Heng Feng (kaihengfeng) wrote :

Sorry, my bad, ALC256 doesn't have aaloop at first place, so my kernel does nothing =(

I'll ask Realtek codec guy about this issue.

Kai-Heng Feng (kaihengfeng) wrote :

Great, Kailiang has Launchpad account =)

@Kailiang
I personally cannot reproduce the issue on my $10 Logitech headphone, maybe this bug can only be reproduced on more beefy headphone.

Daniel van Vugt (vanvugt) wrote :

@kaihengfeng: I found the problem was only really noticeable with earbuds. Headphones tended to hide the problem.

Although it's also worth noting the workaround 'amixer -c 0 set 'Headphone Mic Boost',0 1' sounds like it's working because it actually reduces the audio output volume/gain. With the workaround enabled, ALL audio is quieter so (like using big headphones) the problem could become unnoticeable just because of that. So saying the problem and the solution are directly related to 'Headphone Mic Boost' might be a red herring.

Esokrates (esokrarkose) wrote :

@vanvugt: I can clearly reproduce the problem with headphones too, I do not notice they "hide" anything.

I noticed the hiss listening to music so I can always clearly hear it and it becomes very apparent in a quiet environment.

On another note, with the workaround in place the audio is way to quite, vanvugt, would you agree?
Setting down the volume generally should not be a solution to this bug (compared to the volume of other phones/laptops).

Daniel van Vugt (vanvugt) wrote :

Well, the problem might be more noticeable with low-impedance earphones/headphones. So more likely earphones, but possibly also headphones. (<--- This is now guessing)

Yes I would agree (and mentioned in comment #37) that the workaround makes audio quieter. That might be the best solution possible, but hopefully not.

One problem is that headphone sockets are notoriously noisy in many computers. And it's often not a problem that can be fixed in software. My general recommended solution on any PC is a hardware one: Always use a USB DAC (digital-to-analog converter), AKA a "USB sound card". That separates the analog audio signal generation from the physical machine and avoids such noise/hiss problems.

Esokrates (esokrarkose) wrote :

I tried blacklisting the snd_hda_codec_realtek module, sound works, but now I can hear the coil whine, depending on the activity of the cpu/gpu. Moving the mouse pointer around is clearly audible etc.

spike speigel (frail-knight) wrote :

I still haven't figured out how Pulse determines the default levels it forces upon the user at each start of the service. I think it should respect those levels set within ALSA/the system. If Pulse can't respect selected values, then I'd like to know where it gets its default values. That way I can manually change them and force my default values down Pulse's throat.

pactl is a hot mess to understand. I don't see a way to set volume on ports at all. Maybe it isn't even possible using pactl.

/etc/pulse/default.pa
/etc/pulse/system.pa

don't seem to provide help either. I tried modifying a few things there, and it broke the automatic muting when switching between headphones and internal speakers. So I put all that back the way it was.

I also noticed if:

1. I have alsamixer open along with pavucontrol
2. Set the headphone mic dB gain to 10% in alsamixer
3. In pavucontrol select the "Microphone" from the dropdown under the "Input Devices" tab

Result:
pavucontrol resets the dB gain to 0%, "the default" without me even touching the volume slider...in fact I CAN'T touch the volume slider for the mic. Why can't Pulse work with functionality ALSA clearly provides?

Googling for answers on pulse and volume issues just seems to return a lot of annoyed users and scripted hack answers which really aren't solutions.

If I had a way to set the port volume for the mic and have it remain that way permanently, that would work for me. After reducing the dB gain I can still up the volume to compensate without the hiss returning.

If we can determine it is a bug somewhere and fix it at the root, even better.

spike speigel (frail-knight) wrote :

/usr/share/pulseaudio/alsa-mixer/paths/analog-input-headphone-mic.conf

I just found this from a separate bug thread. This looks interesting. The options for volume are:

volume = ignore | merge | off | zero | <volume step>

# What to do with this volume: ignore it, merge it into the device
# volume slider, always set it to the lowest value possible, or always
# set it to 0 dB (for whatever that means), or always set it to
# <volume step> (this only makes sense in path configurations where
# the exact hardware and driver are known beforehand).

Is this touched by Pulse when updates are applied? I was going to test out zero and ignore to see what happens.

Esokrates (esokrarkose) wrote :

Kai-Heng Feng: Is there anybody still working in this? Are you sure Kailiang noticed this bug?
Is there anything else I could do for you to help?

Changed in dell-sputnik:
status: New → Confirmed
Kai-Heng Feng (kaihengfeng) wrote :
Changed in linux (Ubuntu):
status: Confirmed → In Progress
Daniel van Vugt (vanvugt) wrote :

@kaihengfeng: Sorry, that kernel did not improve the situation. The bug persists and the same workaround is required. I tested it on a fresh artful installation (9350 model).

tags: added: 9350 artful
Esokrates (esokrarkose) wrote :

I confirm Daniel van Vugt, same for me.

Kai-Heng Feng (kaihengfeng) wrote :

Sorry, I forgot to hook the new quirk function I wrote to the right place, so it's never being called. I'll compile a new kernel soon.

Kai-Heng Feng (kaihengfeng) wrote :

Please try kernels in #44 again, thanks!

Esokrates (esokrarkose) wrote :

Is it already the new one as of now? I have just tried it and it did not help :-(.

Kai-Heng Feng (kaihengfeng) wrote :

Update (again), please try it.

Esokrates (esokrarkose) wrote :

Unfortunately the hiss is still there :-(.

Kai-Heng Feng (kaihengfeng) wrote :

Can you attach dmesg with the kernel I built?

tags: added: 201507-18777 taipei-lab
tags: added: oem-sru
Esokrates (esokrarkose) wrote :
Kai-Heng Feng (kaihengfeng) wrote :

Updated, please try again. The new kernel disables "Headphone Mic Boost" completely.

Esokrates (esokrarkose) wrote :

Same situation :-(. The hiss is cleary audible, no change.

Esokrates (esokrarkose) wrote :

This time there are no KHFENG entries in dmesg.

Kai-Heng Feng (kaihengfeng) wrote :

Does "Headphone Mic Boost" disappear in alsamixer?

Esokrates (esokrarkose) wrote :

amixer -c 0 set 'Headphone Mic Boost',0 1 does not work, it says "Headphone Mic Boost" not found, so yes, I am however not familiar with alsamixer. Where would I find "Headphone Mic Boost"?

Esokrates (esokrarkose) wrote :

Yes it disappears! (forgot to run alsamixer as root).

Daniel van Vugt (vanvugt) wrote :

Unfortunately that did not work.

I can confirm that http://people.canonical.com/~khfeng/lp1654448-artful/
does now remove the 'Headphone Mic Boost' option.

However the headphone audio hiss remains, and now we have no workaround...

Daniel van Vugt (vanvugt) wrote :

At a guess the cause of the problem may be some kind of headphone volume boost option that's turned on by default, and weirdly turned off by "'Headphone Mic Boost',0 1". This may not be avoidable interference as much as just excessive volume boost turned on by default.

Kai-Heng Feng (kaihengfeng) wrote :

Linux kernel in [1] should solve the issue.
However, the jack loses the ability to record via traditional microphone - but I think people nowadays use headset most of the time.

[1] http://people.canonical.com/~khfeng/lp1654448-nomic/

Esokrates (esokrarkose) wrote :

Yes that solves the issue :-). Could you link me the code changes?
But are you sure you can't fix the support for traditional microphones? :-( Would be a sad loss, could you elaborate why this is not possible?

Esokrates (esokrarkose) wrote :

When you connect the jack you can choose between 3 options normally (with the kernel in [1] only two now)... isn't it somehow possible to operate with microphone disabled by default ... but leave the user the option to use a traditional mircophone? The white noise should then only be triggered when the user selects "Microphone"!?

Kai-Heng Feng (kaihengfeng) wrote :
Download full text (3.3 KiB)

Basically, I did the same thing as "amixer -c 0 set 'Headphone Mic Boost',0 1", and make the mic pin hidden as well. Otherwise, user space tools will change the value.

According to Kailang, the "Audio hiss" also happens on Windows - but windows has Noise Suppression filter, so it's not as noticeable as other OS.

So there are two ways to workaround the issue - use something like diff below, or use noise cancellation filter in PA.

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 1aa21d7e7245..23373d6dc5a4 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -4553,6 +4553,16 @@ static void alc271_hp_gate_mic_jack(struct hda_codec *codec,
        }
 }

+static void alc_fixup_dell_xps_9350(struct hda_codec *codec,
+ const struct hda_fixup *fix,
+ int action)
+{
+ if (action != HDA_FIXUP_ACT_PROBE)
+ return;
+
+ snd_hda_codec_amp_stereo(codec, 0x1a, HDA_INPUT, 0, HDA_AMP_VOLMASK, 1);
+}
+
 static void alc269_fixup_limit_int_mic_boost(struct hda_codec *codec,
                                             const struct hda_fixup *fix,
                                             int action)
@@ -4861,6 +4871,7 @@ enum {
        ALC298_FIXUP_DELL_AIO_MIC_NO_PRESENCE,
        ALC275_FIXUP_DELL_XPS,
        ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE,
+ ALC256_FIXUP_DELL_XPS_9350,
        ALC293_FIXUP_LENOVO_SPK_NOISE,
        ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY,
        ALC255_FIXUP_DELL_SPK_NOISE,
@@ -5500,7 +5511,13 @@ static const struct hda_fixup alc269_fixups[] = {
                        {}
                },
                .chained = true,
- .chain_id = ALC255_FIXUP_DELL1_MIC_NO_PRESENCE
+ .chain_id = ALC255_FIXUP_DELL2_MIC_NO_PRESENCE
+ },
+ [ALC256_FIXUP_DELL_XPS_9350] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc_fixup_dell_xps_9350,
+ .chained = true,
+ .chain_id = ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE
        },
        [ALC293_FIXUP_LENOVO_SPK_NOISE] = {
                .type = HDA_FIXUP_FUNC,
@@ -5622,10 +5639,10 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
        SND_PCI_QUIRK(0x1028, 0x06de, "Dell", ALC293_FIXUP_DISABLE_AAMIX_MULTIJACK),
        SND_PCI_QUIRK(0x1028, 0x06df, "Dell", ALC293_FIXUP_DISABLE_AAMIX_MULTIJACK),
        SND_PCI_QUIRK(0x1028, 0x06e0, "Dell", ALC293_FIXUP_DISABLE_AAMIX_MULTIJACK),
- SND_PCI_QUIRK(0x1028, 0x0704, "Dell XPS 13 9350", ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE),
+ SND_PCI_QUIRK(0x1028, 0x0704, "Dell XPS 13 9350", ALC256_FIXUP_DELL_XPS_9350),
        SND_PCI_QUIRK(0x1028, 0x0706, "Dell Inspiron 7559", ALC256_FIXUP_DELL_INSPIRON_7559_SUBWOOFER),
        SND_PCI_QUIRK(0x1028, 0x0725, "Dell Inspiron 3162", ALC255_FIXUP_DELL_SPK_NOISE),
- SND_PCI_QUIRK(0x1028, 0x075b, "Dell XPS 13 9360", ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE),
+ SND_PCI_QUIRK(0x1028, 0x075b, "Dell XPS 13 9360", ALC256_FIXUP_DELL_XPS_9350),
        SND_PCI_QUIRK(0x1028, 0x075d, "Dell AIO", ALC298_FIXUP_SPK_VOLUME),
        SND_PCI_QUIRK(0x1028...

Read more...

Esokrates (esokrarkose) wrote :

Thanks very much for the code!! Out of interest, how would you achieve the noise cancellation with pulseaudio?

I tried

load-module module-echo-cancel source_name=test
set-default-source test

which did not work.

A new device appears called "Built-in Audio Analog Stereo (echo cancelled with Built-in Audio Analog Stereo)" and one can move sound to that virtual device. Sound works, but the hiss is still there. I do not see how it would the hiss ...

Could you elaborate how one would do that with pulseaudio so I can test it?

Kai-Heng Feng (kaihengfeng) wrote :

I think you should use the webrtc one.

Esokrates (esokrarkose) wrote :

load-module module-echo-cancel aec_method=webrtc source_name=cancel
set-default-source cancel

does not improve the situation. The hiss remains unchanged for me.

Esokrates (esokrarkose) wrote :

Another question: You say your code does the same as the workaround "amixer -c 0 set 'Headphone Mic Boost',0 1" ... so the output volume is decreased too with your patch?

Kai-Heng Feng (kaihengfeng) wrote :

I am not a PA expert, but I guess you need to set the sink instead of source.

I am not sure I fully understand your second question, but output volume should remain the same.

Esokrates (esokrarkose) wrote :

Regarding the second question: The workaround "amixer -c 0 set 'Headphone Mic Boost',0 1" does lower the output volume significantly. If your patch does the same as the workaround, then the output volume would be significantly lower, I have not tested this yet though.

Esokrates (esokrarkose) wrote :

load-module module-echo-cancel aec_method=webrtc sink_name=cancel.out source_name=cancel.src
set-default-source cancel.src
set-default-sink cancel.out

does not change anything either. To make the hiss disappear I have to mute the hardware output device.

Would be glad if someone could point out how this is supposed to work.

Esokrates (esokrarkose) wrote :

Kai: Confirmed my assumption, your patch SIGNIFICANTLY lowers the output volume!

Kai-Heng Feng (kaihengfeng) wrote :

After discussion with Kailang, he concludes that it's likely to be a hardware issue - nothing serious can be done in the software level.

If we introduce the workaround,
- No more static noise in headset
- The headset volume will be drastically decreased, but you can increase the maximum volume in PA to 150%.
- The traditional microphone can still be used, but without level 2 and 3 amp.

So it's up to you guys - if you guys think it's a fair trade off, I'll upstream the fixup. If not, there's nothing more we can do in software level.

Daniel van Vugt (vanvugt) wrote :

Again, if audio quality matters to you, you can also consider a USB DAC (USB "audio card"). Using the onboard audio socket in any PC is often prone to system noise.

Esokrates (esokrarkose) wrote :

Kai: So you are saying the sound card is buggy on a hardware level? Does this only affect XPS13's or are other Laptops possibly affected too? I guess all that are using the same soundcard?

How about communicating this to Dell? Or isn't this their fault? Is the vendor of the sound card to fault? Or is it the headphone jack?

Is a component at fault I could swap on my own?

Daniel: Sry but on all my other laptops even lower end ones this works satisfying, this is no excuse for Dell selling me this in a flagship model. This is like selling me a crappy Display and telling me for a good Display I should use an external one anyway as any Laptop Display is worse than something I could connect via HDMI.
Furthermore blocking one USB port of only two is not an option for me ... apart from the fact that this is an ultra compact laptop I do not want to attach any obstacles to.

Daniel van Vugt (vanvugt) wrote :

It sounds like the Windows approach of using a noise suppression filter might generally be a good idea. It's likely Microsoft has seen many more laptops and desktops with this same problem.

Although I can't help but think that we could still fix this by limiting the volume more (or finding some gain setting that is on but shouldn't be). Having headphone volume that doesn't go high enough is already a common problem plenty of people would be used to. But the important thing is they won't report that as a bug, so maybe that's better.

Kai-Heng Feng (kaihengfeng) wrote :

Daniel expressed what I meant: it's often hard to avoid noise on onboard audio chip.
Lots of PCs have background noise - nothing really can be done at software level.

Esokrates (esokrarkose) wrote :

Kai: Yeah but it would be nevertheless good to communicate that to the right people of Dell.
Is this an integrated component I can't exchange? Is it Intel integrated Audio or is it an external chip?

Hence I would like to do something on hardware level ... is this not possible?

Kai-Heng Feng (kaihengfeng) wrote :

IIUC hardware amp (the "Headphone Mic Boost" here) is disabled for Headphone/Mic/Headset combo jack (which is used on this laptop) on Windows.

Esokrates,
The reality is that noise happens on a lot of machines - there are already lots of noise workaround in ALSA driver - this is just being one of them.

Daniel van Vugt (vanvugt) wrote :

It appears the headphone socket is right on the motherboard:
https://www.ifixit.com/Device/Dell_XPS_13

However, whether it's on the motherboard or a daughterboard probably would not matter in this case. The problem is so prevalent among XPS 13 models that replacing parts probably would not solve the issue.

Esokrates (esokrarkose) wrote :

Kai: I understand what you are saying ... but I would find it great if you could point that out to Dell ... just because now it is bad, does not mean it can't be improved in the future. With proper hardware testing this could have been avoided.

Kai-Heng Feng (kaihengfeng) wrote :

I think they are already aware - a quick google on "xps headphone noise" shows several results, affecting all OS.

So make the fix in the driver is a more practical approach.

Esokrates (esokrarkose) wrote :

Yeah but I don't think it gets through to the right people. If I read most of the forums discussions no one acknowledges the problem. Only suggestions are to install the latest drivers.
The 9360 came out one year after the 9350 and still has the same issue. User's experiences are not that grave compared to driver developers that point out an issue.

Esokrates (esokrarkose) wrote :

Kai, Thank you very much for looking into this and answering questions. Kudos!
I think the behavior should remain as it is if the output volume is reduced that much AND support for microphone devices is crippled.
My arguments: It is still better to hear the hiss when music is at low volume than have low output volume enforced (on high output volume you do not notice the hiss) and additionally lose some functionality.

If you could manage that classic microphones remain operable I would vote for inclusion.

Daniel van Vugt (vanvugt) wrote :

I haven't yet tested the latest test kernels but disagree with comment #85.

As mentioned in comment #77:
"Although I can't help but think that we could still fix this by limiting the volume more (or finding some gain setting that is on but shouldn't be). Having headphone volume that doesn't go high enough is already a common problem plenty of people would be used to. But the important thing is they won't report that as a bug, so maybe that's better."

I think we might need more people testing the potential fix to gauge whether or not a lower max volume is really worse than the hiss.

Kai-Heng Feng (kaihengfeng) wrote :

Esokrates,
Traditional Microphone can work while disabling the hiss. I'll build a new kernel for you to test.

Esokrates (esokrarkose) wrote :

Kai, http://people.canonical.com/~khfeng/lp1654448-2/ does not have the hiss :-).

Would compensating the lower output volume with setting pulseaudio to 100+% make the quality worse? Does setting pulseaudio to e.g. 130% disort the quality?

Esokrates (esokrarkose) wrote :

Could you please post the patch for http://people.canonical.com/~khfeng/lp1654448-2/ ?

Kai-Heng Feng (kaihengfeng) wrote :

That's exactly the testing kernel built for - to test if software boost performs well.

Esokrates (esokrarkose) wrote :

Kai: I do not understand your last comment, could you elaborate? Did you mean we should test if software boost = pulseaudio boost performs well enough?

Kai, I am quite happy with http://people.canonical.com/~khfeng/lp1654448-2/ please link me the patch as the only drawback would be the lower volume, right? :-).

I will try to test the pulseaudio boost in the next days. Could you explain a bit of theory? What would you expect in terms of quality regarding the pulseaudio boost? Is there something special I should consider? What would be a good way to test for disortion?

On Sat, Jul 1, 2017 at 1:11 AM, Esokrates <email address hidden> wrote:
> Kai: I do not understand your last comment, could you elaborate? Did you
> mean we should test if software boost = pulseaudio boost performs well
> enough?

Yes.

> Kai, I am quite happy with
> http://people.canonical.com/~khfeng/lp1654448-2/ please link me the
> patch as the only drawback would be the lower volume, right? :-).

Traditional microphone will lose hardware mic boost.
That said, software boost for mic should good enough.

> I will try to test the pulseaudio boost in the next days. Could you
> explain a bit of theory? What would you expect in terms of quality
> regarding the pulseaudio boost? Is there something special I should
> consider? What would be a good way to test for disortion?

There's no objective measurement. Use your own ear - if you think the
quality is good, then the quality is good.

>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1654448
>
> Title:
> XPS 13 9360 and 9350, Realtek ALC3246, Headphone audio hiss
>
> Status in Dell Sputnik:
> Confirmed
> Status in alsa-driver package in Ubuntu:
> Confirmed
> Status in linux package in Ubuntu:
> In Progress
> Status in pulseaudio package in Ubuntu:
> Confirmed
>
> Bug description:
> Pertaining to 16.04 on a dell XPS 13 9360
>
> ii alsa-base 1.0.25+dfsg-0ubuntu5
>
> Advanced Linux Sound Architecture Driver Version k4.4.0-57-generic.
>
>
> When headphones are plugged in, there is a clearly audible hiss (white noise). This is present as soon as the headphones are plugged in, whether 'headphones' or 'headset' are selected from the pop-up box.
>
> Using alsamixer to debug the issue reveals that it is related to
> "Headphone Mic Boost" - the default setting is: dB gain 0.00, 0.00. If
> this is changed to:
>
> 10.00, 10.00 (one notch up) the hiss disappears.
> 20.00, 20.00 cause a louder hiss and
> 30.00, 30.00 causes an even louder hiss with high frequency audio artifacts.
>
> When the headphones are removed and plugged back in the Headphone Mic
> Boost setting returns to dB gain 0 and the problem also returns.
>
> This (problem and workaround) has been reported in the wild:
> https://news.ycombinator.com/item?id=13050843 and
> https://www.reddit.com/r/Dell/comments/4j1zz4/headphones_have_static_noise_with_ubuntu_1604_on/
> for example
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/dell-sputnik/+bug/1654448/+subscriptions

Esokrates (esokrarkose) wrote :

Kai, I compile my own kernels and I would like to use this right now, could you please link me the patch? The test kernel floods my syslog badly with touchpad debug entries (unrelated to this bug).

Now regarding testing: By software boost you mean we should test both: Microphone software boost and output volume software boost, right?

Thanks for your detailed answers.

Kai-Heng Feng (kaihengfeng) wrote :

Here you go:

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 1aa21d7e7245..06af38c37fec 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -4553,6 +4553,17 @@ static void alc271_hp_gate_mic_jack(struct hda_codec *codec,
        }
 }

+static void alc256_fixup_dell_xps_13_headset_noise(struct hda_codec *codec,
+ const struct hda_fixup *fix,
+ int action)
+{
+ if (action != HDA_FIXUP_ACT_PRE_PROBE)
+ return;
+
+ snd_hda_codec_amp_stereo(codec, 0x1a, HDA_INPUT, 0, HDA_AMP_VOLMASK, 1);
+ snd_hda_override_wcaps(codec, 0x1a, get_wcaps(codec, 0x1a) & ~AC_WCAP_IN_AMP);
+}
+
 static void alc269_fixup_limit_int_mic_boost(struct hda_codec *codec,
                                             const struct hda_fixup *fix,
                                             int action)
@@ -4861,6 +4872,7 @@ enum {
        ALC298_FIXUP_DELL_AIO_MIC_NO_PRESENCE,
        ALC275_FIXUP_DELL_XPS,
        ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE,
+ ALC256_FIXUP_DELL_XPS_13_HEADSET_NOISE,
        ALC293_FIXUP_LENOVO_SPK_NOISE,
        ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY,
        ALC255_FIXUP_DELL_SPK_NOISE,
@@ -5502,6 +5514,12 @@ static const struct hda_fixup alc269_fixups[] = {
                .chained = true,
                .chain_id = ALC255_FIXUP_DELL1_MIC_NO_PRESENCE
        },
+ [ALC256_FIXUP_DELL_XPS_13_HEADSET_NOISE] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc256_fixup_dell_xps_13_headset_noise,
+ .chained = true,
+ .chain_id = ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE
+ },
        [ALC293_FIXUP_LENOVO_SPK_NOISE] = {
                .type = HDA_FIXUP_FUNC,
                .v.func = alc_fixup_disable_aamix,
@@ -5622,10 +5640,10 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
        SND_PCI_QUIRK(0x1028, 0x06de, "Dell", ALC293_FIXUP_DISABLE_AAMIX_MULTIJACK),
        SND_PCI_QUIRK(0x1028, 0x06df, "Dell", ALC293_FIXUP_DISABLE_AAMIX_MULTIJACK),
        SND_PCI_QUIRK(0x1028, 0x06e0, "Dell", ALC293_FIXUP_DISABLE_AAMIX_MULTIJACK),
- SND_PCI_QUIRK(0x1028, 0x0704, "Dell XPS 13 9350", ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE),
+ SND_PCI_QUIRK(0x1028, 0x0704, "Dell XPS 13 9350", ALC256_FIXUP_DELL_XPS_13_HEADSET_NOISE),
        SND_PCI_QUIRK(0x1028, 0x0706, "Dell Inspiron 7559", ALC256_FIXUP_DELL_INSPIRON_7559_SUBWOOFER),
        SND_PCI_QUIRK(0x1028, 0x0725, "Dell Inspiron 3162", ALC255_FIXUP_DELL_SPK_NOISE),
- SND_PCI_QUIRK(0x1028, 0x075b, "Dell XPS 13 9360", ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE),
+ SND_PCI_QUIRK(0x1028, 0x075b, "Dell XPS 13 9360", ALC256_FIXUP_DELL_XPS_13_HEADSET_NOISE),
        SND_PCI_QUIRK(0x1028, 0x075d, "Dell AIO", ALC298_FIXUP_SPK_VOLUME),
        SND_PCI_QUIRK(0x1028, 0x0798, "Dell Inspiron 17 7000 Gaming", ALC256_FIXUP_DELL_INSPIRON_7559_SUBWOOFER),
        SND_PCI_QUIRK(0x1028, 0x164a, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE),

Esokrates (esokrarkose) wrote :

For the output volume I made the following observations:
* Even with a volume boost of 150% in Pulseaudio (the maximum), the output volume is still significantly lower than the unpatched kernel
* With 150% pulseaudio boost, I can hear disortions and crackling, so the sound quality gets significantly worse, the over-amplification is too much.

It's a difficult decision as the volume is low compared to before and we can't really compensate it to the level before the patch.

Kai-Heng Feng (kaihengfeng) wrote :

Thanks for your feedback, so I'll leave it as it is.

Changed in linux (Ubuntu):
status: In Progress → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers