Dell XPS 13 9350/9360 headphone audio hiss

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

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

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.

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.

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

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

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

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.

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

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

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

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

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

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

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

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/

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?

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

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

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.

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.

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

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.

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

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

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

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.

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

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.

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

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

@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

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

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.

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.

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

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

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.

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.

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.

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

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?

Please try this: http://people.canonical.com/~khfeng/lp1654448-artful/

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

I confirm Daniel van Vugt, same for me.

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.

Please try kernels in #44 again, thanks!

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

Update (again), please try it.

Unfortunately the hiss is still there :-(.

Can you attach dmesg with the kernel I built?

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

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

This time there are no KHFENG entries in dmesg.

Does "Headphone Mic Boost" disappear in alsamixer?

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"?

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

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

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.

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/

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?

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"!?

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

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?

I think you should use the webrtc one.

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.

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?

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.

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.

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.

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

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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

Here you go:

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

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?

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

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

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

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.

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

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.

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

Daniel,

Do you observe this on 9370?

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

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.

Chris,

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

You can use bug 1809856 for the 9370.

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.

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.

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?

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

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?

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?

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.

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

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.

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

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!

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

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

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

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!

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!

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

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

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