I incorrectly reopened an old issue related to the 4.4 kernel for the Dell XPS 2015. This report is the actual issue for 4.5. To confirm, this causes sound on the Dell XPS 2015 (9434) to stop working as well.

Same problem on an Asus Chromebook C200 (Bay Trail-M).
Module snd-soc-sst-byt-max98090-mach.ko is absent in newer kernels (since first 4.5 RC) so the sound card is not recognized at all.
Workaround is to downgrade to an older kernel release or switch to linux-lts.

jkbowling: That's exactly the solution. The problem is that it either requires every Arch user to have CONFIG_DW_DMAC=y as part of the kernel distributed with Arch, or alternatively for anyone using affected machines to build their kernel manually.

Ultimately, this seems to be an issue that will have to be resolved at the kernel level.

jkbowling: I don't think it would be much of an added problem for most users, but from reading other threads in other places, such as the Redhat forums, it was seen as an unacceptable way to 'solve' the problem. From a distribution's point of view, without getting changes adopted at the kernel level, it looks like it's the best solution. I also don't know how much it adds to the kernel, but given that it would fix broken sound for these chipsets it seems a good tradeoff to me.

Personally, and I don't know how the default kernel configuration for Arch is decided, I would love to see CONFIG_DW_DMAC=y simply added, as that would resolve the issue as I understand it.

I got burned on this also. I'm running a chromebook cb3-531 banjo. Extremely frustrating. I built the kernel three times using the suggestions above and still made no difference. I downgraded all the way to 4.4.4-1 Everything works perfectly after the downgrade. It's hard to believe something like this makes it through. Now I'm afraid to ever run pacman -Syu on any of my boxes.

I can confirm the problem on my Dell XPS 13 (9343). As a workarround I run the LTS kernel now but it has other problems (Freezes when using touchpad sometimes).
One can build the kernel himself or use linux-xps13 from AUR but as others already mentioned devices like soundcards, touchpads etc. have to work out of the box.

first, don't spam butracker with so long messages; use pastebin or similar services
second, use official kernel since could be a linux-ck specific issue... we don't know...!!!
third, do you have a dual-boot with windows?

I am not using extra kernel parameters (besides quiet). The problem happens with kernels 4.4.*, i.e., sound works for a while (from 10 or 20 minutes to a couple of hours) and then stops working. With kernel

try the 4.5.2 kernel in testing repo
output indicates that you are working with a connected monitor... try without it

anyway `CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y` is the option to force the audio in legacy mode; this information agree with the fact that 4.4+ kernel versions work in I2S mode... this means it is not an issue related to this bug!

do you have any file in `/etc/modprobe.d/` ?
do you have `alsa-lib` installed on your system?

What I read above, CONFIG_DW_DMAC=y is the temp fix, which is now enabled according my config but still no sound. I do now have a "Dummy Output (Pulseaudio mixer) sound card listed which wasn't there before. Staying on LTS kernel until fixed.

I have also swapped out my wireless card, and I can see sound cards, but when I do play sound it's got this weird horror-movie-esque static to any sound that's played. This very well could be a problem with the hardware, maybe to do with the wireless card switch, but I would think that with the changes in 4.5.2-1 that sound would play correctly.

My machine has Intel i7 processor, touchscreen, screen resolution: 3200 x 1800 pixels and Broadcom BCM43b1 wireless. It may be the case that kernel 4.5.2 fixes the problem for some 9343 machines but not for all 9343 machines. Is there anything I should try or do?

using Google Chrome or another browser (e.g., Vivaldi). (I mostly use Chrome.) Usually, that happens when I stop the video or streaming radio and try to resume it later. The crashes also happen when I try to record a screencast using SimpleScreenRecorder.

using Google Chrome or another browser (e.g., Vivaldi). (I mostly use Chrome.) Usually, that happens when I stop the video or streaming radio and try to resume it later. The crashes also happen when I try to record a screencast using SimpleScreenRecorder.

using Google Chrome or another browser (e.g., Vivaldi). (I mostly use Chrome.) Usually, that happens when I stop the video or streaming radio and try to resume it later. The crashes also happen when I try to record a screencast using SimpleScreenRecorder.

using Google Chrome or another browser (e.g., Vivaldi). (I mostly use Chrome.) Usually, that happens when I stop the video or streaming radio and try to resume it later. The crashes also happen when I try to record a screencast using SimpleScreenRecorder.

using Google Chrome or another browser (e.g., Vivaldi). (I mostly use Chrome.) Usually, that happens when I stop the video or streaming radio and try to resume it later. The crashes also happen when I try to record a screencast using SimpleScreenRecorder.

using Google Chrome or another browser (e.g., Vivaldi). (I mostly use Chrome.) Usually, that happens when I stop the video or streaming radio and try to resume it later. The crashes also happen when I try to record a screencast using SimpleScreenRecorder.

just out of curiosity. I do not have alsa-firmware installed, instead I extracted "IntcPP01.bin" from a copy of a Windows Realtek Audio driver (I think it was 9343_Audio_Driver_X22K2_WN32_7422.118.0_A01.EXE) and placed it in /usr/lib/firmware/intel/IntcPP01.bin
I did that a long time ago because I saw that error in dmesg and have (still) crackling sound on headphones (sometimes). But I think this has nothing to do with the sound problem people have with the latest kernels. As far as I remember sound always worked without this firmware and my sound also went away at one of the 4.5 kernels but is now back with 4.5.3.1 (i5 1920x1080 no touch).
So the firmware seems maybe not to be the problem.

But which allows me to get sound!!! For a little bit at least. Like Francisco, sound works for a bit (playing thru Audacious, VLC), but around the time I try watching web clips, maybe with pausing or resuming, sound stops working again, with the message:

@Willy Me too. I believe there are some issues with gdm and pulseaudio and they may be playing a role here. I switched to LightDM and was able to get I2S sound. The problem for me was that with Gnome 3.20 + LightDM I was unable to lock the screen and the screensaver no longer worked. That's why I returned to gdm. It would be nice if could give LightDM a try.

@Francisco Turns out you were on to something! I rebooted into the repo kernel (4.5.4), logged into Gnome 3.20 with lightdm, and my sound is currently working. It looks like it may actually be an issue with gdm

@Willy 1) Yes, I believe it is an issue with gdm. 2) How and where it can be reported? 3) Were you able to lock the screen and get the screensaver to work with LightDM? If so, how? The packages I installed: lightdm and lightdm-webkit2-greeter.

I believe the crashes that I described above are caused by gdm, as I have already explained. Is there anything that can be done to prevent such crashes short of disabling gdm? gdm starts an instance of pulseaudio. I followed the suggestion here:

I have a 9343 model (no-touchscreen, i5, broadcom) with gnome and gdm as well.
For installing pulseaudio I haven't done anything particular, so it should works out-the-box.
My suggestion is to start from a clean Arch installation...

@mattia the problem has persisted even after starting from clean Arch (even Fedora) installations. You may not be experiencing the issue because it is limited to certain configurations of the XPS 9343. Francisco and I both have the i7 touch version, though different DMIs, and we suffer the same issue. It seems to be a problem with gdm and pulseaudio and the driver in i2s mode. Using other DMs fixes it. In some cases I have had sound go out after resuming from suspend (after changing dm)

@mattia I had exactly the same problem with Fedora. So, I don't think there is anything wrong with my install. For some reason, this particular bug only affects some 9343 machines (my guess: Intel i7, touchscreen) that run gdm. A colleague of mine that with the same notebook (and the same configuration) was having the same problem with Fedora + gdm. Last week he installed Arch + Cinnamon + LightDM and now his I2S audio works flawless. The bug affects a small number of people (perhaps), but it is still a bug. Considerable progress was made when the source of the problem was identified: gdm. We are dutifully reporting the bug. Is there any chance that it can be fixed? Is there hope?

It seems there are a bunch of different bugs affecting Intel's ASoC. This one was originally about sound card not recognized at all because the module was not compiled in newer (>=4.5.0) kernels. Even though it is fixed for most of the ASoC, it's still not working with MAX98090 on Bay Trail because the module (snd_soc_sst_byt_max98090_mach) is still absent.
I think people encountering other problems (ie. sound card detected but not working correctly) should open a new issue.

As @piernov explains above, I am one of those max98090 sufferers. LTS kernel works fine but is getting closer in version number to 4.5 and I'm concerned that with the 4.5.x kernel not being fixed for this issue, I'll soon have no sound.

just a little update:
this weird behaviour has just happened and seem because I switched ON the microphone (from the gnome control center);
(this could explain the reason why it happened... e.g. Kali Linux turn it on at boot...)
so I power it off, power it on, power off and power on to restore a `normal` situation
NB: the first reboot dmesg provides a different message: simply this

I was hoping that kernel 4.6 would solve the problems that affect I2S audio in Dell XPS 13 9343 machines. The problems, nonetheless, remain. I realize that there are different problems at play (card not recognized, audio crashes etc.). I have been struggling with audio crashes since kernel 4.4 was released (I ran Fedora at that time). I am sure the developers are trying hard to solve this mess, but it would be useful if they could share some information with us. Is it likely that the problems will be solved in the 4.6 kernel series? Finally, is there additional information that we (users) can provide to help the developers?

Kernel 4.6.3, same old same old. No sound card, other than dummy, is detected. LTS 4.4 thankfully works, so I'll have to keep that. Is it just a matter of compiling the module for it if it was removed? I see that 4.4 has
/usr/lib/modules/4.4.14-1-lts/kernel/sound/soc/intel/boards/snd-soc-sst-byt-max98090-mach.ko.gz
/usr/lib/modules/4.4.14-1-lts/kernel/sound/soc/intel/boards/snd-soc-sst-cht-bsw-max98090_ti.ko.gz
but 4.6.3 has only /usr/lib/modules/4.6.3-1-ARCH/kernel/sound/soc/intel/boards/snd-soc-sst-cht-bsw-max98090_ti.ko.gz
I'm guessing the 'mach' version of the module is required for my particular baytrail sound chip...

I didn't try it yet, but I had another issue (on Linux 4.6 at least) which does not look related to this change. Sadly I did not save the log but it was something like "could not get gpio -1" then the byt_max98090 driver saying the hardware could not be initialized.

I fixed mine (similar problem, different hardware) by blacklisting the conflicting audio module,
in your case byt-max98090, in your modprobe.conf file and than rebuilding the mkinitcpio image.
Edit: I am on Kernel 4.8.10-1

I tried building my own ArchLinux kernel to get back the snd-soc-sst-byt-max98090-mach module. I've successfully built it but I was getting various errors and the sound wasn't working (even after switching back to BOOT_STUB) though.
I also tried Ubuntu and the sound wasn't working either.

@dalorin for me, the problem has persisted on all versions of the kernel since 4.3, up to 4.8.13-1-ARCH which i am on now. The old trick for using another dm besides gdm no longer seems to work. Also no success on Ubuntu, Debian, or Fedora. I will try GalliumOS like @piernov suggested today and see if I have any luck. Btw I have the Dell XPS 13 9343 (2015), with broadwell audio controller.

Users that own a Dell XPS 13 and run into the problem of only having HDMI sound should try to run the Audio-Test from within the BIOS diagnostics once. This brought back audio for me many times and I have working audio on Arch Linux with kernel 4.8.13-1-ARCH. I can sometimes/often force the sound card to be missing when suspending my computer and then the only way to get it back is to do the "soundtest-trick" but it brings back sound reliably.
See http://www.windowscentral.com/dell-xps-13-audio-problems-heres-fix#test (Start with point 4 when you are on Linux of course)

@duffydack I would be glad to try it if you can provide me your PKGBUILD.
It looks like the patch provided upstream is exactly about the issue I ran into when trying a 4.5+ kernel after re-enabling snd-soc-sst-byt-max98090-mach.

@piernov Nice one. I just noticed I never saved the config properly when removing all the other sound drivers (kernel n00b). Not a great deal of difference, might shave compile time a few mins. Also, I wasn't sure whether to disable a lot more stuff that's not relevant, but I decided to keep it as close to the arch kernel as possible, which I used.
Think this will ever be fixed in main? Hope so. Anyway, 1 more compile just to be sure, then I'll put on AUR.

@piernov, Just checked, they are already set on mine, not by me, must have been set in the asound.state I'm using, maybe.
I've just trimmed down the kernel of all the gpu drivers, non intel stuff, and other junk I don't need on my chromebook, shaved a good 20mb. I'll keep the AUR pkg as-is, but if you want the config for yourself....

@nTia89 Yes I did too. Shutdown time also. Have you tried 4.9 from arch core? I'll try it later, it should be the same since I'm using abs to build, just with the tiny patch that changes 2 lines for sound.

Just a fyi. I compiled with Takashi Iwai's legacy patch, installed ok, added the kernel boot line snd-soc-sst-dsp.bind_legacy=1, rebooted, same old same old. Only hdmi detected, and "Dummy output" for alsa.
/sigh

Oh dear Oh dear. Looks like I might have to start using 4.9LTS for my patched build. Just grabbed 4.11 from testing and it built and patched fine, just like the previous 4.9+ kernels, and loads the byt-max98090 module and shows my sound card, just as it should. 1 problem, there is NO sound. Using the same asound.state file, checked alsamixer levels, still silence.
/damnit

Don't know if anyone else is experiencing issues but after my last pacman -Syu I lost all audio, running on the patched kernel with the asound.state, SystemD returns that it failed to start the sound service,
(https://pastebin.com/ute0n5S0)

Interestingly the card is still detected but all i hear is a sort of stuttering ticking noise with headphones and nothing with speakers

Also Sorry to double post, but i just checked the pulseaudio logs and got :
E: [alsa-sink-Audio HiFi-0] alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_soc_sst_byt_max98090_mach'. Please report this issue to the ALSA developers.

@nTia89 I'm afriad so. The patches that fixed regressions were finally merged into 4.13, but, the kernel still needs compiling with the newer byt/cht drivers disabled before the old one can be built. I've recently been made aware that compiling the kernel (stock ARCH config) with just the relevant drivers disabled to build the old baytrail driver (no other modifications), there is no sound output. The card is detected same as before, sound 'looks' like being output, but there is no audible output. My kernel config is a heavily stripped down ARCH default config that I've carried over from 4.9 right up to 4.13 and sound works fine. I've diff'd the arch config with my stripped custom config, and I cannot see what it is that's making mine work and not a stock (with driver enabled) kernel. If i start off with a make localmodconfig (which sets sound config up correctly) and I enable everything else I need, sound works fine. Wish I could nail it down.

'Nicely' is a bit of an exaggeration :). The whole thing is FUBAR really. Still relies on an obsolete driver that needs force enabling, and then there's the whole duplex "daleks singing" effect when switching to headset/mic with stereo input+output enabled in PA. I'd like a complete fix, but I'm happy to carry on compiling (it's a tiny config now).
Cheers

I noticed 4.1 EOL was extended out to May, 2018 recently, for those able and willing to go back a bit with LTS. The mic seems to work most of the time as well. I have this LTS branch along with the CK patchset in AUR.

The mic does work once you stop the 'daleks', it just means switching pulseaudio profiles a few times before it finally 'locks' and stops being garbled.
Nice to know 4.1 is still alive and works. I'll add it to my AUR info.

As far as my chromebook's byt-max98090 goes, this is no longer an issue in linux 4.15. One thing to note however, to get sound working initially I had to use the chtmax98090 UCM from https://github.com/plbossart/UCM. Can be removed when sound is verified, it keeps working without it, (I guess the asound.state handles it). It is actually better without it because of the way mixers are oddly handled. /shrug