crackling/popping sound on Intel Corporation Sunrise Point-LP HD Audio (rev 21)
 

So, what I've tried already (but was already in place or not effective) is to (1)switch the encoding to realtek, blacklist snd_soc_skl and verified that loopback is deactivated in alsamixer.

I found these "solutions" on various places online, but this issue is still haunting my speakers. Sure I have considered the speakers could be bust, but I doubt that is the issue on a fairly new and mostly unused laptop.

I'm running a Mageia 6 distro (and I've not tried in another distro).
I've never really had to deal much with sound on the computer, and thus I am running out of ideas. I am considering making a custom Kernel to try to see if that can solve it, but I've not yet done that.

I just don't understand where the issue is coming from, and I don't know how to handle the sound driver (snd_hda_intel). The sound in general is not very good, but I prescribed that to speakers not being good. I'd also like to tune and equalize the sound across the system, but I've not got the knowledge about the sound drivers, frameworks etc to do that.

First of all I need to get rid of the cracking/popping sound. I've run the sound over FFT based equalizer on KDE to try to improve the sound, and it did help slightly both with the poor sound quality and the popping (maybe, by my own faulty impressions).

So, any ideas how to solve this issue? Any ideas how to go about it in the first place?

I just tried the sound on a headset, with the same crackling and popping, so it's not the speakers.

Since I also want to tune and equalize the whole system, I don't mind complex solutions to this issue, including configuring and compiling a new Kernel, adding and equalizing framework to pulseaudio, dealing with pulseaudio and or tuning alsa.

Any suggestions would be appreciated, solutions will be rewarded with great joy and thanks.

additionally: verified that i915 firmware is loaded correctly
Alsamixer says: Chipet:Realtek ALC255

So i've tried to install a newer kernel version, 4.19.51 without changing the configuration (oldconfig), and there is no change to the sound situation.

I guess the next step will be to make a truly custom kernel with a new configuration and inspection of it. I already have an alternative working configuration file that I will use, and then review the configurations after loading that. I guess it would make most sense to really have a hard look into the devices -> sound cards and alsa to try to find something in there which can solve the issue or create another form of output.

I might also try the 5.10 kernel with the oldconfig file to see if that makes any difference as well, but my hope is not so high for this potential solution.

Maybe an option is to blacklist Realtek ALC255 and see if it is possible to run the sound over another type of output.

An additional entry to the todo list and further possible information:
https://help.ubuntu.com/community/HdaIntelSoundHowto

In my current oldconfig 4.19.51 Kernel, this is the situation:
Some useful Kerne.org information before getting into the configuration:
https://www.kernel.org/doc/html/v4.1...dio/notes.html

Nothing useful found in the Kernel configuration. No generic codec, no alternatives. Trying to simply compile without Realtek and see if there is a fallback mechanic of some sort. Not a solution that offers much hope. But smaller config without alot of unecessary stuff added to it. Fast to compile, will recompile with Realtek afterwards. If anything can be solved with this minimal Kernel it would be some kind of unecessary driver which conflicts with the sound somehow, but this ofcourse is a far stretch. Expected result, no sound at all, recompile with Realtek, will probably result in the same bad sound.

note to self. Remember to configure initrd when using a config file from a non-initrd kernel/distro. lol.

Surprise result after removing Realtek ALC255 codec support. There is a fallback mechanism in snd_hda_intel, and the sound still works:
Guessing the snd_soc_skl is not configured in my custom-config, or that the module is not needed. It is not loaded.

Some generic sound testing with music and videoes:
-Random popping sound seem to be gone
-Crackling sound in 1 of the test videoes is still there, but it could be down to the video itself.
-Going to test with further videoes, could one of the issues be encoding with gstreamer?
-Sound quality when playing music is without popping/crackling issues, which is already better than before, but sound quality is still not good in and of itself (maybe because I had better speakers on another laptop and got used to that?)

Sound testing commencing...

testing the video on another laptop, a video with real bad crackling and another one with random popping sounds, these issues are still present on this laptop with the current custom-kernel (generic hda codec). Testing the same video on another laptop with ALC271X, these crackling and popping sounds is not due to the video itself.

The mystery continues.

Note to self: could the crackling etc have to do with the sound range and output quality and could it be solved by en equalizer? other laptop "professionally tuned by dolby", this one with a poorer sound in general, could be wrongly tuned.

Sound testing complete. Result is better than with Realtek ALC255 codec. Trying to re-introduce ALC255 codec in a new Kernel configuration to make a more valid comparison.

Note to self. snd_soc_skl was blacklisted early in the process, thus not loaded. Unblacklist for testing with the new custom kernel with Realtek, if available in the Kernel. After soundtesting without.

New sound testing. No real difference with previous setup (custom kernel v1 - snd_hda generic codec).

Kernel config testing is reaching its limits and no real progress has been made with this path. But random popping sounds just randomly vanished somewhere during this process (generic kernel to custom kernel??). Conclusions that can be made from Kernel testing:

- There is a generic fallback SND_HDA codec if one removes the Realtek Codec. This is probably so with any codec for SND_HDA. Good to know.
- snd_soc_skl is not needed (can safely be blacklisted)
- The issue lays either with 1) SND_HDA itself 2) ALSA 3) Pulseaudio
- The issue can potentially be solved with "tuning", adding equalizer
- Updating bios?

Next step is dealing with ALSA and Pulseaudio of which I will not know what I am doing and will have issues dealing with alltogether. ALSA is closer to the Kernel and it might be easier for me to start there. Pulseaudio is greek to me.

Are there any pulseaudio experts out there? Anyone who can help with that? Anyone who have any ideas or tips in that regard?

Same goes for ALSA.

Note. Almost no testing has been done with suspend and resume. This has been a suggested issue for similar problems in various threads across the web:
-v2-realtek seems to have no such issue.
-custom kernel is configured without snd_soc_skl
-adding snd_soc_skl to another config for testing this
-no further results of interest from Kernel tweaks

I'm currently running the 5.1.11 custom Kernel. The final conclusion of the Kernel phase: no results from dealing with the Kernel

Next steps:

1. Software codecs etc (gstreamer??)
2. ALSA
3. Pulseaudio
4. Equalizer

Initial testing for software codec errors done. Probably not the cause of the issues. Run the same file through both gstreamer and vlc, same result.

ALSA
Alsaeq and Alsaequal (libasound2-plugin-equal) seem outdated and like dead ends in regards to getting an equalizer with Alsa. Ladspa based plugins to Alsamixer. There seem to be no equalizer for ALSA anymore and all efforts in that regards have ended. How sad. Managed to download alsaequal-0.6 from the internet time machine archive. Hardly something which will be useful for a productive 64 bit system.

Note to self. how sad is it to have a central sound architecture for Linux and GNU, but with absolutely no powerful tools. Not even a system wide equalizer. It would be so easy to have it implemented at this level wouldn't it? Sound analyses? Nothing? Just volume control... The policy is "do one thing and do it well" NOT "keep it simple stupid".

Onto more hands on approach to trying "something" with ALSA, a few tips might be available in this guide:
https://wiki.archlinux.org/index.php...ty_or_clipping

Adjusting sampling rate and width? Could that do anything?

Some further info on ALSA:
https://www.volkerschatz.com/noise/alsa.html

Converted the testvideo from mp4 to wav with ffmpeg, simply playing this file with aplay, the sound issue remains the same. This is interesting for analytical purposes. Going to try to play it in various ways with aplay. Assuming the issue is then not with Pulseaudio and cannot be fixed with Pulseaudio. Tested the same file in another distro, with aplay (on the same computer) and got the same result.

Makes me think the issue is not with the driver or in Kernel, yet not in Pulseaudio. The issue has been observed in ALSA using aplay as well. Makes me very pessimistic of the prospect of solving this issue. Going to double check the Wav file on another computer to make sure it is not the sound processing alltogether (defect sound card?).

Note on aplay: I might have jumped to conclusions here. I assumed aplay run directly on ALSA without pulseaudio, but it seems that it might run through pulseaudio (perhaps).. Which makes it pointless to "test ALSA" with aplay outside of pulseaudio. Going to have to test the aplay with no-pulse on a no-systemd distro to avoid the perpetual pulseaudio daemon forcing that systemd enforces. Luckily, I have such a distro to try on.

Note to self. Does pulseaudio really need to take control of ALSA? I guess that is the general policy of the pulseaudio creator, to control everything in an authoritarian fashion. It makes very little sense that aplay uses pulseaudio instead of a direct stream with ALSA. ffs.

ALSA test complete: (NOT, this test was later invalidated by file integrity testing)
On a non-systemD distro edit /etc/pulse/client.conf autospawn both to no, and move /etc/asound.conf to another file. System (in my case) will fall back on ALSA and not be able to use Pulse or libpulse and work without these as "pure ALSA".
Playing the same file with aplay on a "pure ALSA" system, the result was the same bad sound. Now I just need to verify the integrity of the file on another system to make sure the sound processing on this system has not altered the file in some way. If the sound is as expected (good) on the other computer, tests can be verified.

File verification:
So this thing just got a whole lot worse. Testing the same .wav file on the other computer, which plays the video with no sound issues, there are the SAME issues when playing the wav file extracted from the machine with the problematic sound! The inegrity of the file is NOT verified. To make matters worse, I did the same process in reverse. Used ffmpeg to convert the same (but seperate download) mp4 video to a wav file on the other machine. When playing this file on the sound problematic machine, there is no issue with the sound on the file!

The conclusion I have to draw from this test is that there is an issue with the entire sound processing.

Note to self. Sound process does not only depend on ALSA but also depends on pulseaudio, codecs (gstreamer etc) unless this is done on a "pure ALSA" system. Currently no testing can be done in this regards on the "pure ALSA" system as it does not have the right codecs to play and convert the online testvideo. On a "pure ALSA" system the sound processing will still depend on codecs (gstreamer) but not pulseaudio. Doing testing this way one can analyse if pulseaudio is relevant to this issue and possibly make a preliminary conclusion on pulseaudio role in this issue.

This could be done with alc255 driver codec and/or with the generic snd codec.

For now I have given up on this issue, but I will return to it when I have time. If anyone has any useful input here, please help me!

As of now it seems to be a "sound processing issue". As I've read a sound card really only process digital signals and make these into analogues and record analogue and make them into digital. Alot of sound seems to work fine, but some sound not so much. Certain sound ranges seem to produce a "random" crackling sound while some sound source material seem to produce constant crackling/garbled sound and very poor results. I'm guessing these digital sources is processed into analogue sound to produce on the speakers and on the headset. I guess this happens via ALSA, via the Kernel (in & out) which does not indicate that this issue surely is a hardware/firmware issue. To test this theory, one could ofcourse test an installation of Windows or OS X, but I don't currently have the time for this, and I'm not sure my available Windows 7 copy would suffice, and I'm not prepared to invest anything into Microsoft products to try.

Another alternative is to re-test the "pure-ALSA" system, but this would take significant time and research as I would need to install the correct codecs on this system to be able to process the same test-video-file on that pure-ALSA system. It seems like a logical next step, but I can't spends weeks installing different codecs and media programs and all their dependencies manually without knowing exactly where it is leading, so I first need to narrow down to as few software packages as possible to be able to handle the youtube file correctly with a pure-ALSA system. On both systems I've downloaded the file as a 720p MP4 in the browser and used ffmpeg to extract a wav file from it. However on my pure-ALSA system I cannot play the video file in the browser or the download file in any media programs I have on that system. I could try without a codec, but I wouldn't feel that it would be a 100% reliable test.

I have the Intel Panther Point (I HATE stupid software names). That's Series 7.

Back in 2015, I had to get HDMI Audio, and it sucked real bad. It sounded like I was getting square waves instead of sinewaves to my low-fi techie's ear. Bu8t a guy here said it needed resampling. So the sound came at 44khz, was re-sampled at 48khz, and that sorted it. I still have the .asoundrc, and a script to tweak so that hdmi sound went to the earphone jack plug (I know, I know - There was a good reason for that).

You could try booting to a Live CD of something and testing the audio. If the problem happens with the Live CD, it could be a hardware problem. If nothing else, the test might be worthwhile to rule out hardware, because, if it is hardware, no amount of mucking about in software will fix it.

During the summer (holiday, no further testing done) I have also noticed a disturbance on the sound on the analogue output to a headset. When there is no sound playing, there is a kind of whistling/grinding sound on the headset. This could ofcourse be due to the headset, but could also be due to the sound situation which was not fixed.

Generally I've not had such an issue with this headset on other units, but the headset is old. However, I do suspect the issue is not due to the headset, but I've not tested this extensively yet, but on the other units I have tested it on, there is no such disturbing sounds. Sound can be described alike to that which is present during a bad headset connection.

Just noting this down for when I have time to revisit the issue.

Might this be the problem?

https://www.reddit.com/r/linux/comme...ug_in_snd_hda/

Not if that issue is ONLY with AMD. I have an Intel processor on this laptop.

However, just from a first peek that reddit thread looks like it might have alot of useful information. I need to read through it.

Tried to re-initialize the driver with alsa this did not help.

Tried to change a setting in /etc/pulseaudio/default.pa adding the "tsched=0" did not help.

Found this link with various HDA_Intel guides and troubleshooting links:
https://ubuntuforums.org/showthread.php?t=1043568

In a related thread (https://bugzilla.kernel.org/show_bug.cgi?id=195303) it seems this issue was introduced with a Kernel version. It could possibly be a solution to try an old Kernel pre-4.10 to test.

I've not actually figured out how to resample the sound. This is one of the things I wanted to try. However, doing any equalizing or re-sampling in the systemD times of oversimplified and complicated solutions to everything, seems to be near impossible. As far as I've researched, there is no longer any existing system-sound-equalizer in GNU/Linux (alsa/pulseaudio)..

I did try to look into resampling the sound, and I think I even tried a few things, but with no success. As far as I remember it either stayed at the same sample frequency or did nothing at all. It seems to be almost as complicated as trying to find a system equalizer. Any concrete indications of a working alsa/pulseaudio re-samling would be much appreciated. Or any pointers to somewhere I can find an actual working solution.

Anyways, this issue keeps haunting me from time to time. The sound if actually mostly working, but sometimes it's just terrible with cracking/popping sounds all over the place. In particular I've noticed that this problem is present whenever I watch a video where people speak into some kind of microphone. So I think I've narrowed the issue down a bith further to that, but I'm not 100% sure. I might have with some of the solutions above manage to solve the random popping issue as I haven't heard this much recently. Now it's mostly the crackling issue left, or only.. It's a bit difficult to say and it is near impossible to say that I've resolved the popping issue and which solution solved that, sadly.

Working with this sound issue, I've found out that trying to deal with sound is a bit diffuse. It's difficult to make things concrete for others to understand. It is also difficult to deal with Alsa and Pulseaudio to try to resolve possible issues that one might experience with sound. There are very few useful utilities, and very few sound functions in both Alsa and Pulseaudio. A clear degredation to how things were before. Sound was more complex and you had more tools and utilities. But perhaps I remember it wrong.

Anyhow, I think the saying is "do one thing and do it well", not "do one thing and simplify it to the max". I think Alsa is excellent and they do one thing and do it well, but sadly I think in that mission they have sacrificed some complexities and oversimplified the system for the user, in favour of making it easier for the developers. I could be wrong in saying that, but it would be understandable at least if they made the decisions for that reason, rather than just dumb things down for the user and offer them less tools and utilities for no reason.

Pulseaudio does one thing in a very stupid way is my impression. And the commands etc do deal with pulseaudio is very un-unix like. Isn't the point of pulseaudio just to split hardware sound and offer this as a service to multiple output/inputs? Then why does it have to be so damn complex? Why not just do one thing and do it well? I think perhaps systemD answers that question. Do everything and do one thing well, but everything poorly, that is the policy of the day.

It would be nice to have an alsa sound server instead, one that does what pulseaudio tried to do. Now we end up with two things that do one thing, and none of them have the toos and utilities to satisfy the user and more complex needs.

Ok, so this post turned into some kind of rant, my apologies. I'm just a user, and from a user perspective it does work well in general, but it's overly complex and offers users no real satisfaction and control over things. Even something as simple as shutting down pulseaudio is like trying to dethrone a tyrant.

This was given to me in 2015, in my pre-pulse days. I was trying to achieve 2 things

1. Do something about the %&@£! awful hdmi sound
2. Find a way of diverting hdmi audio to the jackplug to facilitate simultaneous translation.

Sound on that <insert your choice of expletives> Intel card was at 44khz. The 48000 changed that to 48khz, and the effect was magical. I think the redirection to jackplug was done with a script which dropped in another config file, or pulled it out. I had it licked on my box, and no windows or Mac user could do it, so they all had to use linux for the day. Here's the ~/.asoundrc Your device numbers probably won't be the same, but otherwise try leaving it and see what damage it does. How it will interact with pulse is another matter.

The other thing not to overlook is blown speakers. a lot of overdriving or use at full volume blows speakers, quite frequently especially on laptops.

Thanks for your input, I'll have a look into that. I don't think the speakers are blown, it was a new laptop and the sound was like this from the beginning. It does kindof sound like blown speakers, but I doubt it is. I'm pretty sure it's not infact. I'm 99% sure it is a "sound processing" issue. I recorded a file on this computer and transferred it to another computer without any sound issues, and the issue was then the same on the other computer with the file processes on this computer.

So, I pretty much concluded it HAS to be a sound processing issue, and that is probably either down to poor/defect hardware OR poor/defect/non-working driver or otherwise software. I'm not 100% sure it is possible to solve with software, the issue could be hardware, but I have a feeling it could be possible to solve with software, but it could be down to the driver itself, and in that case I cannot fix it myself.

Pulse and Alsa makes things more difficult to pinpoint, so there is definetely a very annoying aspect of interaction with pulse, even if pulse is not the issue. To further isolate pulse or alsa as the source of the issue, I need the same soundfile processed on my ALSA-ONLY (non-systemd) distro to isolate the sound processing to ALSA. However, right now that is an issue, as this distro is seriously lacking my attention and need a bunch of stuff installed to be able to process the video/sound codec. I imagine that will be a job in and of itself. But once that is done I can narrow it down to alsa or pulseaudio.

However, I think I'll need to try some other steps before that, as it might take awhile with the current situation of that distro and the amount of work it would be to get the correct codec installed to even be able to process the video/sound file with that distro. Not to mention that I have to deal with manually getting the wifi network up on that distro every time, and disable pulseaudio yet again.

I hope in the end I can resolve the issue and that this thread might be a goto for other people who experience the same issue. I've still got alot of work ahead of me to reach that point. Fixing diffuse sound issues is not exactly the easiest thing as you might see from all the effort I already put in.

sidenote: playing a normal video file yesterday with some added music, I had the same issue with the crackling sound, so it is NOT ONLY with microphone recorded content as I speculated earlier

If it's dud speakers, turning the volume down should help. In fact it's always a good idea to try it at low volume.

It's not the speakers, volume doesn't make any difference in regards to the bad sound. It MIGHT be a faulty card/circuit, but I have a feeling it is not. I'm 99% sure this issue is "sound processing" as it even carries over into different systems after processing the sound using this system with this card.

Testing with another distro is something I plan to do, but has not yet got around to. Processing with Alsa only is yet another test I will make. Possibly trying a pre-4.14 kernel as well. I guess these tests should narrow down the problem further.

Fixing my test environment Slackware with the correct codex to actually investigate and process the same video/sound files will accomplish these two tests. It's just that I have to find out about the codec stuff, and I don't exactly know a whole lot about these codecs and encoders etc and which ones will actually process the particular test video/files that I'm trying to deal with.

If anyone could point me in the right direction, the files are played on and downloaded from youtube. Probably it is mp4a (aac) and vp9 (or possibly h263, h264). I think I'd need vp9 encoder and aac encoder only.

Codecs are unlikely to be the issue. They're a whole area to themselves. There's a basic set with the soundcard, and others are optionally added. I thionk my soundcard has Realtek codecs, and never gave trouble. This is at least my 2nd soundcard to have Realtek codecs.

To fault find, stick with something bog simple, like aplay & arecord, where you can play & record, and set the rate you record at. You can take codecs for granted there, unless something is majorly defective. Man arecord for it's options, record a .wav from your phone or some such, then aplay to hear it. BTW, have you Skype? How does that work?

So, in a twist of turns, when I updated my whole distro to a new version (new install) the issue "magically" went away.

I marked the thread as solved, although the issue is not really "solved", since I do not know what caused the issue in the first place. Anyways, someone with similar problems might try the same solution. Sadly I have no idea which software caused the issue and which "new version" solved it. But the newest version of software X, Y, Z should solve the issue.

Not only is the Kernel new, but I assume new versions of Alsa and Pulseaudio is also installed, and I know I have a new version of Firefox. Those are the main suspects in the first place. Additionally I've installed a bunch of codecs etc in their new versions.

My personal issue is solved, but I might continue to investigate this issue to find the root of the issue, but I would need to install a version of the old distro again. I think the old version will have the same issue as before, as my "old version" was a fresh install on new hardware in the first place.

I use a persistent /home folder, so the issue was not due to local settings or anything like that.

According to distrowatch some selection of software versions that might be relevant:
- Alsa moved from 1.1.4.1 to 1.1.7
- Firefox moved from 60.x to 67.x (esr)
- Kernel from 4.9.x to 5.2.x (current 5.2.10)
- Systemd 230 to 241

not sure about pulseaudio on the old version, but current is 12.2