Dell XPS 13 9350/9360 headphone audio hiss

[Andrew McLeod]

=== SRU Justification ===
[Impact]
XPS 13 9350/9360 has unbearlbe headphone noise after recent kernel
updates.

[Fix]
Lock Headphone Mic Boost level to 1 as an workaround to solve the issue.

[Test]
Plug a headphone to audio jack, the noise is really bad.
After applying the patch the noise is gone.

[Regression Potenial]
Low. This change only targets to 2 systems, so it has limited impact.

=== Original Bug Report ===
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)]

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)]

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

[spike speigel (frail-knight)]

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)]

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)]

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

[bwat47 (bwat47)]

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)]

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

[spike speigel (frail-knight)]

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)]

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

[Launchpad Janitor (janitor)]

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

[Esokrates (esokrarkose)]

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)]

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)]

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

[Esokrates (esokrarkose)]

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

[Jared Dominguez (jared-dominguez)]

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

[Kai-Heng Feng (kaihengfeng)]

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)]

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?

[spike speigel (frail-knight)]

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

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

[Esokrates (esokrarkose)]

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)]

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)]

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)]

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)]

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)]

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

[Esokrates (esokrarkose)]

@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)]

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)]

@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)]

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)]

@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/

[Daniel van Vugt (vanvugt)]

^^^
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)]

@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)]

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

[Kai-Heng Feng (kaihengfeng)]

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)]

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)]

@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)]

@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)]

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)]

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.

[Esokrates (esokrarkose)]

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)]

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)]

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)]

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)]

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)]

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

[Kai-Heng Feng (kaihengfeng)]

Here you go:

http://people.canonical.com/~khfeng/lp1654448-2/

[Esokrates (esokrarkose)]

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)]

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

[Kai-Heng Feng (kaihengfeng)]

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

[Esokrates (esokrarkose)]

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?

[Kai-Heng Feng (kaihengfeng)]

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)]

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)]

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)]

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)]

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

[Kai-Heng Feng (kaihengfeng)]

Daniel,

Do you observe this on 9370?

[Daniel van Vugt (vanvugt)]

Not myself, no. That was just to cover duplicate bug 1809856. If that's incorrect, feel free to remove it.

[Chris (forgetso)]

Hi Kai-Heng Feng, I experience a hissing noise on Ubuntu Ubuntu 18.04.2 LTS with Dell XPS 9370. Is there some patch I can apply to prevent this from happening?

The hissing begins as soon as I plug headphones or speakers in and it goes away when I mute the system.

[Kai-Heng Feng (kaihengfeng)]

Chris,

Please file a separate bug report which collects information, so I can work on a patch and build a test kernel.

[Daniel van Vugt (vanvugt)]

You can use bug 1809856 for the 9370.

[Chris (forgetso)]

Sure, Daniel, Kai-Heng. Please let me know what information you would like added to bug 1809856 for the 9370. FYI, the fix

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

does not work on my laptop.

[caoilte (caoilte)]

Weird. I've had an XPS 9360 running ubuntu since November 2017. Last week I picked up all the updates from August, rebooted and ran straight into this bug with headphones that had previously been fine. I dual boot into Windows and that is fine so it isn't a hardware problem.

[Ed Saunders (seddy12)]

I've recently just run into the same problem since recent updates, I've had my XPS since October 2017 and am currently running Ubuntu 18.04.3. No issues until last week. I think I may have selected "headset with microphone" by accident once when inserting headphones without a microphone, but no evidence that this was related; I just remember doing it when I don't recall doing that before.

The initial workaround in this thread of updating "Headphone Mic Boost" setting up one notch in alsamixer works for me, so I assume this is a regression or was this never fixed?

[Ionut Negru (blackjohnny)]

The same happen with my XPS 13. Since a couple of days I have noticed this annoying hiss. I use Ubuntu 19.04.

The workaround also fixes the issue for me (amixer -c 0 set 'Headphone Mic Boost',0 1)

Regards

[LaurensV (laurens-daemon)]

Same issue as previous 3 reporters. All was fine until the latest update(s), I now have the hiss back... Any idea on what might've changed?

[Esokrates (esokrarkose)]

I've had this issue since 2017 all the time. As you can see in the comments, Kai suggested that this is an hardware issue. He developed a workaround for the kernel that I tested, however it made the general output volume significantly lower, see #96, which is the reason this fix was never shipped.

So it's really strange to me that you guys did not observe the issue until now. Are you all having the 9360 model or a newer one?

[Dig Digger (diggerdig)]

Like several of the most recent posters above I've had a 9360 for a couple of years without any hiss problems. A few days ago I started getting a pretty bad hiss thru headphones. Tried various headphones - all have bad hiss. All are ok on other devices. Running 19.04. Something has changed.

[Kai-Heng Feng (kaihengfeng)]

The fix is now in upstream. Please refer to the patch for justification:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=1099f48457d06b816359fb43ac32a4a07e33219b

[Esokrates (esokrarkose)]

Indeed, I forgot to upgrade so I missed the issue. Now that I did I see the hiss is indeed much louder. Thanks Kai for sending this upstream already.

[James (james-r-barker)]

I observe this on my XPS 13 9360.
As mentioned by others, the headphone hissing goes away when I mute the system or when I run "amixer -c0 sset 'Headphone Mic Boost' 10dB". I created an even in /etc/acpi/events to call run this whenever headphones are inserted so that it persists after reboot.

Has anyone had luck advising Dell of the suspected hardware issue?

James

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

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed-bionic'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[Khaled El Mously (kmously)]

@Kai-Heng: Is there something that needs to be done to verify this bug in -proposed?

[Kai-Heng Feng (kaihengfeng)]

It's the same one as #1845810 so we can mark it as verified.

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 4.15.0-72.81

---------------
linux (4.15.0-72.81) bionic; urgency=medium

  * bionic/linux: 4.15.0-72.81 -proposed tracker (LP: #1854027)

  * [Regression] Bionic kernel 4.15.0-71.80 can not boot on ThunderX
    (LP: #1853326)
    - Revert "arm64: Use firmware to detect CPUs that are not affected by
      Spectre-v2"
    - Revert "arm64: Get rid of __smccc_workaround_1_hvc_*"

  * [Regression] Bionic kernel 4.15.0-71.80 can not boot on ThunderX2 and
    Kunpeng920 (LP: #1852723)
    - SAUCE: arm64: capabilities: Move setup_boot_cpu_capabilities() call to
      correct place

linux (4.15.0-71.80) bionic; urgency=medium

  * bionic/linux: 4.15.0-71.80 -proposed tracker (LP: #1852289)

  * Bionic update: upstream stable patchset 2019-10-29 (LP: #1850541)
    - panic: ensure preemption is disabled during panic()
    - f2fs: use EINVAL for superblock with invalid magic
    - [Config] updateconfigs for USB_RIO500
    - USB: rio500: Remove Rio 500 kernel driver
    - USB: yurex: Don't retry on unexpected errors
    - USB: yurex: fix NULL-derefs on disconnect
    - USB: usb-skeleton: fix runtime PM after driver unbind
    - USB: usb-skeleton: fix NULL-deref on disconnect
    - xhci: Fix false warning message about wrong bounce buffer write length
    - xhci: Prevent device initiated U1/U2 link pm if exit latency is too long
    - xhci: Check all endpoints for LPM timeout
    - usb: xhci: wait for CNR controller not ready bit in xhci resume
    - USB: adutux: fix use-after-free on disconnect
    - USB: adutux: fix NULL-derefs on disconnect
    - USB: adutux: fix use-after-free on release
    - USB: iowarrior: fix use-after-free on disconnect
    - USB: iowarrior: fix use-after-free on release
    - USB: iowarrior: fix use-after-free after driver unbind
    - USB: usblp: fix runtime PM after driver unbind
    - USB: chaoskey: fix use-after-free on release
    - USB: ldusb: fix NULL-derefs on driver unbind
    - serial: uartlite: fix exit path null pointer
    - USB: serial: keyspan: fix NULL-derefs on open() and write()
    - USB: serial: ftdi_sio: add device IDs for Sienna and Echelon PL-20
    - USB: serial: option: add Telit FN980 compositions
    - USB: serial: option: add support for Cinterion CLS8 devices
    - USB: serial: fix runtime PM after driver unbind
    - USB: usblcd: fix I/O after disconnect
    - USB: microtek: fix info-leak at probe
    - USB: dummy-hcd: fix power budget for SuperSpeed mode
    - usb: renesas_usbhs: gadget: Do not discard queues in
      usb_ep_set_{halt,wedge}()
    - usb: renesas_usbhs: gadget: Fix usb_ep_set_{halt,wedge}() behavior
    - USB: legousbtower: fix slab info leak at probe
    - USB: legousbtower: fix deadlock on disconnect
    - USB: legousbtower: fix potential NULL-deref on disconnect
    - USB: legousbtower: fix open after failed reset request
    - USB: legousbtower: fix use-after-free on release
    - staging: vt6655: Fix memory leak in vt6655_probe
    - iio: adc: ad799x: fix probe error handling
    - iio: adc: axp288: Override TS pin bias current for some models
    - iio: light: opt3001: fix mutex unlock race
    - efivar/ssdt: Don't iterate over EFI va...

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

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-disco' to 'verification-done-disco'. If the problem still exists, change the tag 'verification-needed-disco' to 'verification-failed-disco'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

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

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-eoan' to 'verification-done-eoan'. If the problem still exists, change the tag 'verification-needed-eoan' to 'verification-failed-eoan'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[spike speigel (frail-knight)]

Verified the fix works on eoan with my 9360 running kernel 5.3.0-25 proposed. Updated the tag. Hope I did this right :S

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 5.3.0-26.28

---------------
linux (5.3.0-26.28) eoan; urgency=medium

  * eoan/linux: 5.3.0-26.28 -proposed tracker (LP: #1856807)

  * nvidia-435 is in eoan, linux-restricted-modules only builds against 430,
    ubiquity gives me the self-signed modules experience instead of using the
    Canonical-signed modules (LP: #1856407)
    - Add nvidia-435 dkms build

linux (5.3.0-25.27) eoan; urgency=medium

  * eoan/linux: 5.3.0-25.27 -proposed tracker (LP: #1854762)

  * CVE-2019-14901
    - SAUCE: mwifiex: Fix heap overflow in mmwifiex_process_tdls_action_frame()

  * CVE-2019-14896 // CVE-2019-14897
    - SAUCE: libertas: Fix two buffer overflows at parsing bss descriptor

  * CVE-2019-14895
    - SAUCE: mwifiex: fix possible heap overflow in mwifiex_process_country_ie()

  * [CML] New device id's for CMP-H (LP: #1846335)
    - mmc: sdhci-pci: Add another Id for Intel CML
    - i2c: i801: Add support for Intel Comet Lake PCH-H
    - mtd: spi-nor: intel-spi: Add support for Intel Comet Lake-H SPI serial flash
    - mfd: intel-lpss: Add Intel Comet Lake PCH-H PCI IDs

  * i915: Display flickers (monitor loses signal briefly) during "flickerfree"
    boot, while showing the BIOS logo on a black background (LP: #1836858)
    - [Config] FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y

  * Please add patch fixing RK818 ID detection (LP: #1853192)
    - SAUCE: mfd: rk808: Fix RK818 ID template

  * Kernel build log filled with "/bin/bash: line 5: warning: command
    substitution: ignored null byte in input" (LP: #1853843)
    - [Debian] Fix warnings when checking for modules signatures

  * Lenovo dock MAC Address pass through doesn't work in Ubuntu (LP: #1827961)
    - r8152: Add macpassthru support for ThinkPad Thunderbolt 3 Dock Gen 2

  * Dell XPS 13 9350/9360 headphone audio hiss (LP: #1654448) // [XPS 13 9360,
    Realtek ALC3246, Black Headphone Out, Front] High noise floor (LP: #1845810)
    - ALSA: hda/realtek: Reduce the Headphone static noise on XPS 9350/9360

  * no HDMI video output since GDM greeter after linux-oem-osp1 version
    5.0.0-1026 (LP: #1852386)
    - drm/i915: Add new CNL PCH ID seen on a CML platform
    - SAUCE: drm/i915: Fix detection for a CMP-V PCH

  * [broadwell-rt286, playback] Since Linux 5.2rc2 audio playback no longer
    works on Dell Venue 11 Pro 7140 (LP: #1846539)
    - [Config] Drop snd-sof-intel-bdw build
    - SAUCE: ASoC: SOF: Intel: Broadwell: clarify mutual exclusion with legacy
      driver

  * [CML-S62] Need enable turbostat patch support for Comet lake- S 6+2
    (LP: #1847451)
    - SAUCE: tools/power turbostat: Add Cometlake support

  * External microphone can't work on some dell machines with the codec alc256
    or alc236 (LP: #1853791)
    - SAUCE: ALSA: hda/realtek - Move some alc256 pintbls to fallback table
    - SAUCE: ALSA: hda/realtek - Move some alc236 pintbls to fallback table

  * Memory leak in net/xfrm/xfrm_state.c - 8 pages per ipsec connection
    (LP: #1853197)
    - xfrm: Fix memleak on xfrm state destroy

  * CVE-2019-18660: patches for Ubuntu (LP: #1853142) // CVE-2019-18660
    - powerpc/64s: support nospectre_v2 cmdline option
    - powerp...

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 5.0.0-38.41

---------------
linux (5.0.0-38.41) disco; urgency=medium

  * disco/linux: 5.0.0-38.41 -proposed tracker (LP: #1854788)

  * [Regression] Failed to boot disco kernel built from master-next (kernel
    kernel NULL pointer dereference) (LP: #1853981)
    - SAUCE: blk-mq: Fix blk_mq_make_request for mq devices

  * CVE-2019-14901
    - SAUCE: mwifiex: Fix heap overflow in mmwifiex_process_tdls_action_frame()

  * CVE-2019-14896 // CVE-2019-14897
    - SAUCE: libertas: Fix two buffer overflows at parsing bss descriptor

  * CVE-2019-14895
    - SAUCE: mwifiex: fix possible heap overflow in mwifiex_process_country_ie()

  * [CML] New device id's for CMP-H (LP: #1846335)
    - mmc: sdhci-pci: Add another Id for Intel CML
    - i2c: i801: Add support for Intel Comet Lake PCH-H
    - mtd: spi-nor: intel-spi: Add support for Intel Comet Lake-H SPI serial flash
    - mfd: intel-lpss: Add Intel Comet Lake PCH-H PCI IDs

  * Please add patch fixing RK818 ID detection (LP: #1853192)
    - SAUCE: mfd: rk808: Fix RK818 ID template

  * [SRU][B/OEM-B/OEM-OSP1/D] Enable new Elan touchpads which are not in current
    whitelist (LP: #1853246)
    - Input: elan_i2c - export the device id whitelist
    - HID: quirks: Refactor ELAN 400 and 401 handling

  * Lenovo dock MAC Address pass through doesn't work in Ubuntu (LP: #1827961)
    - r8152: Add macpassthru support for ThinkPad Thunderbolt 3 Dock Gen 2

  * [CML-S62] Need enable turbostat patch support for Comet lake- S 6+2
    (LP: #1847451)
    - SAUCE: tools/power turbostat: Add Cometlake support

  * External microphone can't work on some dell machines with the codec alc256
    or alc236 (LP: #1853791)
    - SAUCE: ALSA: hda/realtek - Move some alc256 pintbls to fallback table
    - SAUCE: ALSA: hda/realtek - Move some alc236 pintbls to fallback table

  * Memory leak in net/xfrm/xfrm_state.c - 8 pages per ipsec connection
    (LP: #1853197)
    - xfrm: Fix memleak on xfrm state destroy

  * CVE-2019-18660: patches for Ubuntu (LP: #1853142) // CVE-2019-18660
    - powerpc/64s: support nospectre_v2 cmdline option
    - powerpc/book3s64: Fix link stack flush on context switch
    - KVM: PPC: Book3S HV: Flush link stack on guest exit to host kernel

  * Raydium Touchscreen on ThinkPad L390 does not work (LP: #1849721)
    - HID: i2c-hid: fix no irq after reset on raydium 3118

  * Make Goodix I2C touchpads work (LP: #1853842)
    - HID: i2c-hid: Remove runtime power management
    - HID: i2c-hid: Send power-on command after reset

  * Touchpad doesn't work on Dell Inspiron 7000 2-in-1 (LP: #1851901)
    - Revert "UBUNTU: SAUCE: mfd: intel-lpss: add quirk for Dell XPS 13 7390
      2-in-1"
    - lib: devres: add a helper function for ioremap_uc
    - mfd: intel-lpss: Use devm_ioremap_uc for MMIO

  * CVE-2019-19055
    - nl80211: fix memory leak in nl80211_get_ftm_responder_stats

  * [CML-S62] Need enable intel_rapl patch support for Comet lake- S 6+2
    (LP: #1847454)
    - powercap/intel_rapl: add support for CometLake Mobile
    - powercap/intel_rapl: add support for Cometlake desktop

  * [CML-S62] Need enable intel_pmc_core driver patch for Comet l...