Arch Linux

I can confirm that this is a problem for the 9343 and I can't seem to find any workaround after a few hours trying to find a solution.

I can confirm having the same issue on the Dell XPS 13 (9343), however, it only breaks when I do a rebbot. Booting the machine up from a full powered off state works correctly.

EDIT: Per the wiki, it seems that *two* cold boots are required. After a second one all seems to be working again.

I can also confirm the same issue on the Dell XPS 13 (9343). However, after performing two cold boots, the sound is still not working.

How did you cold boot?
On my machine, doing 'sudo halt' (without -p), then powering off by holding down physical power button fixed the issue.

I was using `systemctl poweroff`. I just tried using `sudo halt`, without -p, and I still have the issue :(

Also, does anyone know if having audio in i2s mode for the Dell XPS 13 (9343), causes issues with the trackpad? Because also after upgrading to kernel 4.4, occasionally, my trackpad freezes, and then all my input methods stop working (keyboard, touchscreen, laptop lid). The only things that seem to work after that are the keyboard backlight button, and holding the power button to power off. It happens with either of the synaptics or libinput divers :/

also having issues with sound after upgrading to kernel 4.4 on an XPS 13 (9343). Speaker-test still works and I can still interact with alsamixer, but there is no sound. dmesg | grep audio prints out

[ 1.420085] haswell-pcm-audio haswell-pcm-audio: Direct firmware load for intel/IntcPP01.bin failed with error -2
[ 1.420090] haswell-pcm-audio haswell-pcm-audio: fw image intel/IntcPP01.bin not available(-2)
[ 1.420682] haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19
[ 1.454908] snd_hda_intel 0000:00:03.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[ 1.541241] broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> System Pin mapping ok
[ 1.541309] broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Offload0 Pin mapping ok
[ 1.541364] broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Offload1 Pin mapping ok
[ 1.541417] broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Loopback Pin mapping ok
[ 1.552261] broadwell-audio broadwell-audio: rt286-aif1 <-> snd-soc-dummy-dai mapping ok
[ 1.570619] input: broadwell-rt286 Headset as /devices/pci0000:00/INT3438:00/broadwell-audio/sound/card0/input12
[ 14.244734] haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19
[ 1472.502194] haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19

Same issue but I got sound working back again.

I don't know what have fixed the bug, but here steps I've done

1) BIOS update ( A03 => A07 )
2) Two cold boot

-- Note: sound doesn't work yet

3) check sound cards
> $ cat /proc/asound/cards
0 [HDMI ]: HDA-Intel - HDA Intel HDMI
HDA Intel HDMI at 0xf7418000 irq 48
1 [broadwellrt286 ]: broadwell-rt286 - broadwell-rt286
broadwell-rt286

The index have changed for me, so I change my .asoundrc :

> $ cat .asoundrc
defaults.pcm.card 1
defaults.ctl.card 1
defaults.ctl.card 1

pcm.!pulse {
type pulse
}

ctl.!pulse {
type pulse
}

-- Note: sound doesn't work yet! (ehggg)

I opened « pavucontrol » and the fallback have been set on HDMI, so I changed to broadwell-rt286 and now the sound is working as expected

After trying the various tricks mentioned here, I got back sound playback. However, I was never able to get the microphone (jack or internal) to work. Any idea?

Just adding a note here that after Arch kernel 4.4.* arrived then no matter what config changes I tried I could not get sound AND microphone to work properly on my Dell XPS 13 model 9343 (early 2015) notebook other than to recompile the Arch kernel with CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y set. With that set, sound and mic works perfectly, as it did using any 4.3 kernel. This problem is also true for kernel 4.5.0-1 today, I need that same config variable set. Note, for interest on 4.5+, I first tried just setting CONFIG_DW_DMAC_CORE=y (refer https://bugzilla.redhat.com/show_bug.cgi?id=1308792) but still see no sound card after that. Note I always do 2 cold reboots between any test.

Here is a reference to a RH bug relating to this present Arch bug: https://bugzilla.redhat.com/show_bug.cgi?id=131343.

The proposed change in the config also fixes  FS#46494 .

I got audio working on kernel 4.5.1 after adding the following options in kernel config file:

CONFIG_DW_DMAC=y
CONFIG_SND_SOC_INTEL_HASWELL_MACH=m
CONFIG_SND_SOC_INTEL_BROADWELL_MACH=m

Mads's suggestion fixed the problem for me on kernel 4.5.1-1.

@smradlev and @jkbowling, do you not notice on your 9343 laptop that your microphone does not work? There are other problems with sound as well with CONFIG_DW_DMAC option set but let's just start with the obvious one!

AFAIK, the only way to fix sound + mic problems completely on the XPS 13 9343 model is to compile the 4.5 kernel (or 4.4) with CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y. That restores the sound card to HDA mode like it was on kernel 4.3, not I2S mode which kernel 4.4 and 4.5 are trying to use, unsuccessfully on our 9343 laptop.

The CONFIG_DW_DMAC=y fix is for the 9350 model which is not the subject on this bug.

I was able to make the microphone work by opening pavucontrol and selecting a different sound card for input and selecting back the internal mike.

@bulletmark, indeed every time I need to use the microphone, I follow the same steps that benob listed. I did not realize those steps can be avoided if I used CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y instead. I'll try that next time I need to update the kernel.

@bulletmark I don't use mic so I have no clue about it but it seems to be pulse/alsa/gnome/whatever issue since kernel driver is there. Maybe change in default microphone interface is needed.

For me sound works good on XPS 9343 with I2S broadwell driver.

If you want fallback to HDA driver you may try adding to grub cmd (or other bootloader) with default arch kernel (reboot twice):

acpi_osi='!Windows 2013' acpi_osi='!Windows 2012'

@jkbowling, I rebooted (cold by 3) with those boot options on stock Arch kernel 4.5.1-1 and they don't have any effect.

BTW, you say you "don't use the mic" but be aware that most/many people use Skype, Google Hangouts, etc so the mic is extremely important.

@jkbowling: Do you use PulseAudio for sound on your 9343? Because I can confirm that sound on 9343 does *not* work with ALSA without CONFIG_ACPI_REV_OVERREIDE_POSSIBLE=y flag.

I2S sound for both the 9343 and 9350 models should be fixed in Arch kernel 4.5.2, which is in the testing repo right now. (Source: https://bugs.archlinux.org/task/48936) Please upgrade and see if it fixes your issues.

If you were previously using HDA audio (i.e. you had CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y set), remember to do two cold boots after upgrading.

@soren121, I just tried that new testing kernel 4.5.2 and, as I say above and in various posts over the forums (e.g https://bbs.archlinux.org/viewtopic.php?pid=1624334#p1624334), it does not fix sound for the 9343 model. There is a big delay on output which you can see via the GNOME sound test function in the config settings, and most importantly - the microphone does not work at all.

@bulletmark: I haven't seen complaints of audio delays anywhere else; it may be a confounding problem in your setup. I have the 9343 with GNOME 3.20 & Pulse installed and it works for me without issues, as well as for the people CC'ed on the corresponding Red Hat/Fedora bug (https://bugzilla.redhat.com/show_bug.cgi?id=1308792).

I added instructions to the XPS 13 wiki page a few hours ago on how to enable the built-in mic with I2S, does that work for you?

@soren121, installing alsa-utils and following your newly added wiki procedure does enable the mic but after a power reboot I have to re-enable it every time so that is not a workable solution. Also, the sound delay is still there. For the majority of people who use GNOME, just open the sound settings and do a "Test Speakers" and you will see the delay on the first speaker you select, or open the "Sound Effects" pane and you will find the first time you select an alert sound you don't hear anything due to the delay.

Ah. I thought you meant lag. I hear the initialization delay in your test, but it's not something I've encountered in any other application. I wonder if the bug is in ALSA or Pulse, or even in Gnome's Sound Settings...

And thanks for your report; I didn't know that the mic fix wasn't persistent. I'll have to see if I can make it so.

4.5-2 does *not* solve the sound problem on my XPS 9343. I don't have Pulse installed, only ALSA. As I noted above, this problem on 9343 is particular to ALSA only. Without CONFIG_ACPI_REV_OVERREIDE_POSSIBLE=y set, sound simply doesn't work on 9343 even with the lates 4.5-2.

@jonas_maj: Did you mean 4.5.2-1? If so, what's the output of aplay -l?

I can confirm that combination of pulseaudio and kernel 4.5.2 makes audio working

With kernel 4.5.2 and pulseaudio, playback does work but the microphone is not working by default. To make it work, you have to open pavucontrol, select a different microphone and come back to the main microphone. I don't know if this is an alsa or pulseaudio bug.

It does not work for me (Dell XPS 13, model 9343, bios A07). Kernel:

cribari@darwin4 ~ $ uname -a
Linux darwin4 4.5.2-1-ARCH #1 SMP PREEMPT Thu Apr 21 18:21:27 CEST 2016 x86_64 GNU/Linux

Sound works when I boot:

cribari@darwin4 ~ $ dmesg | grep haswell
[ 1.478193] haswell-pcm-audio haswell-pcm-audio: Direct firmware load for intel/IntcPP01.bin failed with error -2
[ 1.478195] haswell-pcm-audio haswell-pcm-audio: fw image intel/IntcPP01.bin not available(-2)
[ 1.479099] haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19
[ 11.716925] haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19

After a few minutes sound is gone:

cribari@darwin4 ~ $ dmesg | tail
[ 634.776942] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
[ 634.776946] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
[ 634.776949] System PCM: error: failed to commit stream -110
[ 634.776951] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110
[ 634.776953] System PCM: ASoC: hw_params FE failed -110
[ 635.083690] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
[ 635.083694] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
[ 635.083697] System PCM: error: failed to commit stream -110
[ 635.083699] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110
[ 635.083701] System PCM: ASoC: hw_params FE failed -110

Could the problem be related to pulseaudio? I have:
* pulseausio version 8.0-3
* pulseaudio-alsa version 2-2
* pulseaudio-bluetooth version 8.0-3
* pavucontrol version 3.0-4

Hello, I'm giving 4.5.2-1-ARCH a try too, after some time with a custom kernel (CONFIG_ACPI_REV_OVERRIDE_POSSIBLE enabled).

Sound works, but not without some artifacts :

* regular clips on headphones (heartbeat like, every second)
* bops on speakers when transitionning from silence to play, or headphones to speakers.


Francisco, you are pointing errors on your HDMI output. Maybe you should check that your stream goes through the broadwell-rt286 output (which this thread is about btw :]).

I think second issue is "normal" because could be the transition between the power-saving mode in which sound card enters when it is not used for a while... you can try to test disabling power-saving feature

@f3d I am new to Arch (I came to Arch from Fedora). I would appreciate it if you could let me know how to check that. This is what I have:

cribari@darwin4 ~ $ pacmd list-sources | grep -e device.string -e 'name:'
name: <alsa_output.pci-0000_00_03.0.hdmi-stereo.monitor>
device.string = "0"
name: <alsa_output.platform-broadwell-audio.HiFi__hw_broadwellrt286__sink.monitor>
device.string = "1"
name: <alsa_input.platform-broadwell-audio.HiFi__hw_broadwellrt286__source>
device.string = "hw:broadwellrt286"
cribari@darwin4 ~ $

cribari@darwin4 ~ $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 8: HDMI 2 [HDMI 2]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: broadwellrt286 [broadwell-rt286], device 0: System Playback/Capture (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: broadwellrt286 [broadwell-rt286], device 1: Offload0 Playback (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: broadwellrt286 [broadwell-rt286], device 2: Offload1 Playback (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
cribari@darwin4 ~ $

@Francisco you probably have pulseaudio installed and in use. There are different ways to define your (default) output sink (pacmd, pavucontrol, editing the main configuration file, using the controls settings of your desktop environment). Similar stuff is available for ALSA. You can pick and setup your card with alsamixer and test it with aplay (-D).

@f3d This is what I have on my system: https://dl.dropboxusercontent.com/u/2171814/sound-info.txt . I am trying to use

pacmd "set-default-source alsa_output.platform-broadwell-audio.HiFi__hw_broadwellrt286__sink.monitor"

Is that correct? Suggestions are welcome since I've been struggling with this for a while. Thank you very much.

@Francisco Nope, it's "set-default-sink". The following page might help you in your struggle : https://wiki.archlinux.org/index.php/PulseAudio/Examples

@f3d I included

set-default-sink alsa_output.platform-broadwell-audio.HiFi__hw_broadwellrt286__sink

at the end of /etc/pulse/default.pa and rebooted. I have

cribari@darwin4 ~ $ pacmd list-sinks|egrep -i 'index:|name:'
index: 0
name: <alsa_output.pci-0000_00_03.0.hdmi-stereo>
* index: 1
name: <alsa_output.platform-broadwell-audio.HiFi__hw_broadwellrt286__sink>

The problem persists, nonetheless. After a while sound is gone and dmesg informs

cribari@darwin4 ~ $ dmesg | tail
[ 2764.053910] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
[ 2764.053927] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
[ 2764.053934] System PCM: error: failed to commit stream -110
[ 2764.053939] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110
[ 2764.053947] System PCM: ASoC: hw_params FE failed -110
[ 2764.360555] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
[ 2764.360561] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
[ 2764.360564] System PCM: error: failed to commit stream -110
[ 2764.360566] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110
[ 2764.360571] System PCM: ASoC: hw_params FE failed -110

kernel:

cribari@darwin4 ~ $ uname -a
Linux darwin4 4.5.2-1-ARCH #1 SMP PREEMPT Thu Apr 21 18:21:27 CEST 2016 x86_64 GNU/Linux

It may be case that kernel 4.5.2 fixes the problem on some but not all 9343 machines. See https://bugs.archlinux.org/task/48936 . In my case, I have

cribari@darwin4 ~ $ dmesg | grep "XPS 13"
[ 0.000000] DMI: Dell Inc. XPS 13 9343/0310JH, BIOS A07 11/11/2015

cribari@darwin4 ~ $ sudo dmidecode | grep 0310JH
Product Name: 0310JH

My machine has Intel i7 processor, touchscreen, screen resolution: 3200 x 1800 pixels and Broadcom BCM43b1 wireless. Is there anything I should try?

Hardware:

cribari@darwin4 ~ $ dmesg | grep "XPS 13"
[ 0.000000] DMI: Dell Inc. XPS 13 9343/0310JH, BIOS A07 11/11/2015

i.e., 9343 model with Intel i7, touchscreen, 3200 x 1800 screen resolution, Broadcom wireless. (Notice the "0310JH".)

Kernel 4.5.3:

cribari@darwin4 ~ $ uname -a
Linux darwin4 4.5.3-1-ARCH #1 SMP PREEMPT Sat May 7 20:43:57 CEST 2016 x86_64 GNU/Linux

I have sound when I boot the computer, but dmesg informs:

[ 1.453753] haswell-pcm-audio haswell-pcm-audio: Direct firmware load for intel/IntcPP01.bin failed with error -2
[ 1.453755] haswell-pcm-audio haswell-pcm-audio: fw image intel/IntcPP01.bin not available(-2)

alsa-firmware is installed (version 1.0.29-1).

Sound is gone after a while, usually when I play YouTube videos or streaming radio from

http://cbn.globoradio.globo.com/

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.

When sound is gone, dmesg informs:

[24294.494682] haswell-pcm-audio haswell-pcm-audio: error: audio DSP boot timeout IPCD 0x0 IPCX 0x0
[24294.811357] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
[24294.811360] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
[24294.811375] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110
[24295.118072] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
[24295.118076] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
[24295.118082] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110

Also:

[24304.578677] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
[24304.578693] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
[24304.578695] System PCM: error: failed to commit stream -110
[24304.578698] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110
[24304.578700] System PCM: ASoC: hw_params FE failed -110
[24304.882091] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
[24304.882102] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
[24304.882107] System PCM: error: failed to commit stream -110
[24304.882112] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110
[24304.882117] System PCM: ASoC: hw_params FE failed -110

In order to have audio, I am having to compile my kernels with

CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y

What I have installed:

alsa-firmware v. 1.0.29-1
alsa-lib v. 1.1.1-1
alsa-plugins v. 1.1.1-1
alsa-tools v. 1.1.0-2
alsa-utils v. 1.1.1-1
lib32-alsa-lib v. 1.1.1-1
lib32-alsa-plugins v. 1.1.1-1
pulseaudio v. 8.0-3
pulseaudio-alsa v. 2-3
pulseaudio-bluetooth v. 8.0-3
pulseaudio-equalizer v. 8.0-3
pavucontrol v. 3.0-4
lib32-libpulse v. 0.30-6
libcanberra-pulse v. 0.30-6

It may be the case that kernel 4.5.2 (and later) fixed the problem for some 9343 machines (those with Intel i5 processors, maybe) but not for all.

I added set-default-sink alsa_output.platform-broadwell-audio.HiFi__hw_broadwellrt286__sink to /etc/pulse/default.pa , but it did not help.

Today's new Arch kernel 4.5.3-1 at least fixes the I2S microphone problem I talk about above.

@cribari: The failure to load IntcPP01.bin is normal; this firmware file does not seem to be necessary for I2S sound to work. The other errors you're experiencing are certainly not normal, however. You should report this upstream at bugzilla.kernel.org.

@soren121 I followed your suggestion: https://bugzilla.kernel.org/show_bug.cgi?id=118051.

Hi there! Just wanted to jump in and second Francisco Cribari, we have the same stats (i7 5600u, 3200x1800, touch), even though a different DMI:

DMI: Dell Inc. XPS 13 9343/0F5KF3, BIOS A07 11/11/2015

But like him, I cannot get sound on any kernel (for some time now, including and up to 4.5.3-1, my current kernel), UNLESS (the DMAC_CORE options have no effect) the kernel is recompiled with:

CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y

Which, as u all know, causes:

[ 0.000000] ACPI: DMI detected: DELL XPS 13 (2015) (force ACPI _REV to 5)

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:

kernel: haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
kernel: haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
kernel: haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110

Relevant arch bug: https://bugs.archlinux.org/task/48936

@Willy I suggest you report experience here: https://bugzilla.kernel.org/show_bug.cgi?id=93361 and here: https://bugzilla.kernel.org/show_bug.cgi?id=118051 .

@Willy Have you made any progress regarding I2S sound in your Dell XPS 13? I can only get sound by compiling the kernel with CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y
.

To anyone experiencing the errors described above by cribari and abrb_water: it is actually a hardware issue, which cribari recently confirmed in this kernel bug report: https://bugzilla.kernel.org/show_bug.cgi?id=118051
This explains why their audio output still failed when they switched to HDA mode. If you have this issue, please call Dell and ask for a motherboard replacement.

This hardware issue, however, is rare. For XPS 13 owners with working audio chipsets, the original software issue at hand has been fixed in Arch since kernel 4.5.3. Additionally, a better fix for all distros is forthcoming in mainline 4.8: https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/commit/?h=topic/intel&id=a395bdd6b24b692adbce0df6510ec9f2af57573e

I believe this bug report can be closed now.