Bug 60769 - [IOMMU]Gigabyte H87N-WIFI, MSI Z87I: HDMI audio does not work at all
[IOMMU]Gigabyte H87N-WIFI, MSI Z87I: HDMI audio does not work at all
Status: NEW
Product: Drivers
Classification: Unclassified
Component: Other
All Linux
: P1 normal
Assigned To: drivers_other
:
: 67321 86221 86311 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-19 15:15 UTC by Alexander E. Patrakov
Modified: 2016-04-07 00:51 UTC (History)
14 users (show)

See Also:
Kernel Version: 3.11-rc5
Tree: Mainline
Regression: No


Attachments
alsa-info.sh output (77.66 KB, text/plain)
2013-08-19 15:18 UTC, Alexander E. Patrakov
Details
Kernel config (123.23 KB, text/plain)
2013-08-19 15:19 UTC, Alexander E. Patrakov
Details
Full dmesg (92.67 KB, text/plain)
2013-08-19 15:20 UTC, Alexander E. Patrakov
Details
Full dmesg after BIOS update (88.69 KB, text/plain)
2013-08-21 07:12 UTC, Alexander E. Patrakov
Details
/proc/interrupts, three times (11.70 KB, text/plain)
2013-08-31 09:00 UTC, Alexander E. Patrakov
Details
alsa-info.sh output from MSI board (87.78 KB, text/plain)
2013-09-27 15:41 UTC, Alexander E. Patrakov
Details
dmesg from MSI board (94.26 KB, text/plain)
2013-09-27 15:43 UTC, Alexander E. Patrakov
Details
Debug patch (3.40 KB, patch)
2013-10-02 18:23 UTC, Alexander E. Patrakov
Details | Diff
Dmesg with the debugging patch above (270.45 KB, text/plain)
2013-10-02 18:33 UTC, Alexander E. Patrakov
Details
Good dmesg, just in case (85.12 KB, text/plain)
2013-10-05 19:02 UTC, Alexander E. Patrakov
Details
Good config (123.69 KB, application/octet-stream)
2013-10-05 19:02 UTC, Alexander E. Patrakov
Details
Fix buffer alignment for Haswell HDMI controllers (2.20 KB, patch)
2013-11-05 16:40 UTC, Takashi Iwai
Details | Diff
DMAR from the MSI board (184 bytes, application/octet-stream)
2013-11-05 17:04 UTC, Alexander E. Patrakov
Details
DMAR from the Gigabyte board (184 bytes, application/octet-stream)
2013-11-06 17:08 UTC, Alexander E. Patrakov
Details

Description Alexander E. Patrakov 2013-08-19 15:15:18 UTC
I built a new desktop PC based on the Gigabyte H87N-WIFI motherboard. It has one DVI and two HDMI outputs. However, I cannot get any sound over HDMI. The same OS image works perfectly on my laptop that also has an HDMI output.

This is not a pulseaudio problem, because the following command (with a 5-second wav file) takes a lot more than 5 seconds, and spams the kernel log with "playback write error (DMA or IRQ trouble?)":

pasuspender -- aplay -D hdmi:0,0 /usr/share/sounds/startup3.wav

I will attach more information to this bug.
Comment 1 Alexander E. Patrakov 2013-08-19 15:18:57 UTC
Created attachment 107242 [details]
alsa-info.sh output

The relevant card is 00:03.0 (Intel Haswell HDMI)
Comment 2 Alexander E. Patrakov 2013-08-19 15:19:48 UTC
Created attachment 107243 [details]
Kernel config
Comment 3 Alexander E. Patrakov 2013-08-19 15:20:34 UTC
Created attachment 107245 [details]
Full dmesg
Comment 4 Alexander E. Patrakov 2013-08-21 07:12:29 UTC
Created attachment 107267 [details]
Full dmesg after BIOS update

It was suggested that I update the BIOS and retry with -D hw:0,7. It didn't help, I still get the "playback write error (DMA or IRQ trouble?)" even with the F4 version of the BIOS.
Comment 5 Alexander E. Patrakov 2013-08-31 09:00:16 UTC
Created attachment 107373 [details]
/proc/interrupts, three times

On IRC, ohsix asked me for /proc/interrupts. Here is what I did:

cat /proc/interrupts > interrupts.txt
pasuspender -- aplay -D hw:1,0 /usr/share/sounds/startup3.wav   # works, plays through analog output
cat /proc/interrupts >> interrupts.txt
pasuspender -- aplay -D hw:0,3 /usr/share/sounds/startup3.wav   # hangs => ctrl+c
cat /proc/interrupts >> interrupts.txt
Comment 6 Mengdong Lin 2013-09-05 07:16:59 UTC
Backup info from Alexander:
"according to the log, this machine claims to have three HDMI outputs, while in fact it has one DVI (possibly wired for HDMI, at least ELD is successfully transferred over it) and two "real" HDMI.
All of them fail to transfer audio in the same way."
Comment 7 Alexander E. Patrakov 2013-09-09 13:25:46 UTC
More info possibly relevant to this bug: the board appears to have general IRQ problems.

1. The analog audio sometimes stutters. There is the following message in dmesg while playing a DVD (note: this is about the different card!):

[ 2158.573591] hda-intel: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj.

2. Sometimes the keyboard or mouse exhibits lags (characters get delayed or the cursor sticks for several hundred milliseconds, while other screen updates appear as they should). Initially I attributed them to the fact that they are wireless (and that's the first time I use a wireless keyboard and mouse) and suspected interference from some unknown source. But, given the above IRQ-related message, I decided to tell you about that, too.
Comment 8 Raymond 2013-09-10 15:18:30 UTC
your still have deadlock and oops


1.351918] ======================================================
[    1.351989] [ INFO: possible circular locking dependency detected ]
[    1.352056] 3.11.0-rc5+ #1 Not tainted
[    1.352122] -------------------------------------------------------
[    1.352195] crda/311 is trying to acquire lock:
[    1.352383] microcode: CPU5 sig=0x306c3, pf=0x2, revision=0x9
[    1.352258]  (genl_mutex){+.+.+.}, at: [<ffffffff81596902>] genl_lock+0x12/0x20
[    1.352562] 
but task is already holding lock:
[    1.352716] systemd-udevd[275]: renamed network interface eth0 to enp2s0
[    1.352666]  (nlk->cb_mutex){+.+.+.}, at: [<ffffffff81592b09>] netlink_dump+0x29/0x240
[    1.352940] 
which lock already depends on the new lock.

[    1.353039] 
the existing dependency chain (in reverse order) is:
[    1.353113] microcode: CPU6 sig=0x306c3, pf=0x2, revision=0x9
[    1.353189] 
-> #1 (nlk->cb_mutex){+.+.+.}:
[    1.353385]        [<ffffffff810ace97>] lock_acquire+0x87/0x130
[    1.353482]        [<ffffffff8166defc>] mutex_lock_nested+0x5c/0x3e0
[    1.353575]        [<ffffffff8159317f>] __netlink_dump_start+0xbf/0x1c0
[    1.353686]        [<ffffffff8159608c>] genl_family_rcv_msg+0x1bc/0x320
[    1.353753] microcode: CPU7 sig=0x306c3, pf=0x2, revision=0x9
[    1.353843]        [<ffffffff81596989>] genl_rcv_msg+0x79/0xb0
[    1.353938]        [<ffffffff81595bd9>] netlink_rcv_skb+0xa9/0xc0
[    1.354030]        [<ffffffff81595eb7>] genl_rcv+0x27/0x40
[    1.354123]        [<ffffffff8159516d>] netlink_unicast+0x10d/0x190
[    1.354214]        [<ffffffff815955f9>] netlink_sendmsg+0x359/0x760
[    1.354308]        [<ffffffff8154e082>] sock_sendmsg+0xc2/0xe0
[    1.354427] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    1.354409]        [<ffffffff8154e46c>] ___sys_sendmsg+0x37c/0x390
[    1.354619]        [<ffffffff81551144>] __sys_sendmsg+0x44/0x80
[    1.354729]        [<ffffffff8155118d>] SyS_sendmsg+0xd/0x20
[    1.354835]        [<ffffffff81678f16>] system_call_fastpath+0x1a/0x1f
[    1.354932] 
-> #0 (genl_mutex){+.+.+.}:
[    1.355129]        [<ffffffff810ac028>] __lock_acquire+0x1528/0x1dd0
[    1.355222]        [<ffffffff810ace97>] lock_acquire+0x87/0x130
[    1.355316]        [<ffffffff8166defc>] mutex_lock_nested+0x5c/0x3e0
[    1.355412]        [<ffffffff81596902>] genl_lock+0x12/0x20
[    1.355516]        [<ffffffff81596aec>] ctrl_dumpfamily+0x12c/0x140
[    1.355638]        [<ffffffff81592b70>] netlink_dump+0x90/0x240
[    1.355746]        [<ffffffff81593010>] netlink_recvmsg+0x2f0/0x3a0
[    1.355858]        [<ffffffff8154dd29>] sock_recvmsg+0xd9/0xf0
[    1.355964]        [<ffffffff8154d562>] ___sys_recvmsg+0x112/0x2a0
[    1.356076]        [<ffffffff81551384>] __sys_recvmsg+0x44/0x80
[    1.356181]        [<ffffffff815513cd>] SyS_recvmsg+0xd/0x20
[    1.356271]        [<ffffffff81678f16>] system_call_fastpath+0x1a/0x1f
[    1.356411] 
other info that might help us debug this:

[    1.356700]  Possible unsafe locking scenario:

[    1.356929]        CPU0                    CPU1
[    1.357081]        ----                    ----
[    1.357248]   lock(nlk->cb_mutex);
[    1.357517]                                lock(genl_mutex);
[    1.357823]                                lock(nlk->cb_mutex);
[    1.358098]   lock(genl_mutex);
[    1.358354] 
 *** DEADLOCK ***

[    1.358486] 1 lock held by crda/311:
[    1.358541]  #0:  (nlk->cb_mutex){+.+.+.}, at: [<ffffffff81592b09>] netlink_dump+0x29/0x240
[    1.358820] 
stack backtrace:
[    1.358898] CPU: 0 PID: 311 Comm: crda Not tainted 3.11.0-rc5+ #1
[    1.358969] Hardware name: Gigabyte Technology Co., Ltd. H87N-WIFI/H87N-WIFI, BIOS F4 08/03/2013
[    1.359059]  ffffffff820ac640 ffff8804253af878 ffffffff8166a218 0000000000000001
[    1.359296]  ffffffff820ac640 ffff8804253af8c8 ffffffff81665ed3 ffff8804253af898
[    1.359509]  ffff8804253af948 00000000005ea0ec ffff880426be86f8 00000000005ea0ec
[    1.359758] Call Trace:
[    1.359813]  [<ffffffff8166a218>] dump_stack+0x4f/0x84
[    1.359878]  [<ffffffff81665ed3>] print_circular_bug+0x2ae/0x2bf
[    1.359948]  [<ffffffff810ac028>] __lock_acquire+0x1528/0x1dd0
[    1.360010]  [<ffffffff810aa356>] ? check_irq_usage+0x96/0xe0
[    1.360086]  [<ffffffff810ace97>] lock_acquire+0x87/0x130
[    1.360146]  [<ffffffff81596902>] ? genl_lock+0x12/0x20
[    1.360223]  [<ffffffff81169ff0>] ? __kmalloc_node_track_caller+0x290/0x390
[    1.360287]  [<ffffffff81596902>] ? genl_lock+0x12/0x20
[    1.360363]  [<ffffffff8166defc>] mutex_lock_nested+0x5c/0x3e0
[    1.360424]  [<ffffffff81596902>] ? genl_lock+0x12/0x20
[    1.360501]  [<ffffffff8155a197>] ? __kmalloc_reserve.isra.45+0x37/0xa0
[    1.360564]  [<ffffffff81596902>] genl_lock+0x12/0x20
[    1.360661]  [<ffffffff81596aec>] ctrl_dumpfamily+0x12c/0x140
[    1.360722]  [<ffffffff8159205f>] ? netlink_alloc_skb+0xaf/0x1e0
[    1.360799]  [<ffffffff81592b70>] netlink_dump+0x90/0x240
[    1.360860]  [<ffffffff81593010>] netlink_recvmsg+0x2f0/0x3a0
[    1.360938]  [<ffffffff8154dd29>] sock_recvmsg+0xd9/0xf0
[    1.361000]  [<ffffffff8154d562>] ___sys_recvmsg+0x112/0x2a0
[    1.361078]  [<ffffffff8106ee6e>] ? up_read+0x1e/0x40
[    1.361138]  [<ffffffff81674fcc>] ? __do_page_fault+0x1fc/0x570
[    1.361215]  [<ffffffff8113d55f>] ? might_fault+0x4f/0xa0
[    1.361276]  [<ffffffff8154d3f3>] ? move_addr_to_user+0x83/0xe0
[    1.361354]  [<ffffffff81551384>] __sys_recvmsg+0x44/0x80
[    1.361416]  [<ffffffff815513cd>] SyS_recvmsg+0xd/0x20
[    1.361492]  [<ffffffff81678f16>] system_call_fastpath+0x1a/0x1f
Comment 9 Alexander E. Patrakov 2013-09-10 15:46:55 UTC
This is not a deadlock, just a lockdep warning that is unrelated to audio (i.e. a separate bug). If you want, I will blacklist the iwldvm module so that you don't see this.

As for my earlier comment about general IRQ problems - I stand corrected. This IS RF interference. In pulseaudio -vvv log, I see front headphone jack status changes that correspond in time to the glitches. However, this computer's case does not have frnt panel audio jacks, so I left the motherboard pins that should lead to the front panel audio unconnected to anything. And the keyboard becomes non-lagged if I shift it a bit on my table. Also, the Dell monitor sometimes shows some spurious light near its sensor "buttons". So, I now believe all of this strange activity is actually unrelated to the HDMI bug.
Comment 10 Alexander E. Patrakov 2013-09-27 13:21:35 UTC
I attempted to get rid of the bug by buying a different motherboard (MSI Z87I). The attempt is unsuccessful: the same bug manifests itself again on the new board.
Comment 11 Alexander E. Patrakov 2013-09-27 15:41:14 UTC
Created attachment 109811 [details]
alsa-info.sh output from MSI board

This is with today's drm-intel/drm-intel-nightly
Comment 12 Alexander E. Patrakov 2013-09-27 15:43:14 UTC
Created attachment 109821 [details]
dmesg from MSI board

Can you spot what's common (besides the form factor) between these two motherboards? Or should I suspect a faulty CPU?
Comment 13 Raymond 2013-09-28 03:36:09 UTC
which pin complex is DisplayPort and which pin complex is you HDMI ?

Do their ELD contain the monitor name ?

state.MID {
	control.1 {
		iface CARD
		name 'HDMI/DP,pcm=3 Jack'
		value true
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	
	control.6 {
		iface PCM
		device 3
		name ELD
		value '100009006a100001000000000000000010ac16f044454c4c2055323431300907070000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access 'read volatile'
			type BYTES
			count 83
		}
	}
	control.7 {
		iface CARD
		name 'HDMI/DP,pcm=7 Jack'
		value true
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}

		
	control.12 {
		iface PCM
		device 7
		name ELD
		value '100008006522000000000000000000001e6d01004c4720545615075009570700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access 'read volatile'
			type BYTES
			count 83
		}
	}
Comment 14 Raymond 2013-09-28 03:53:53 UTC
but your new motherboard does not have dual HDMI?

1.794216] hda-intel 0000:00:1b.0: codec_mask = 0x1
[    1.794413] hda-intel 0000:00:1b.0: codec #0 probed OK
[    1.796130] hda_codec: invalid CONNECT_LIST verb 7[1]:0
[    1.796132] hdmi: haswell: override pin connection 0x7
[    1.796677] HDMI hot plug event: Codec=0 Pin=5 Device=0 Inactive=0 Presence_Detect=1 ELD_Valid=1
[    1.796731] HDMI status: Codec=0 Pin=5 Presence_Detect=1 ELD_Valid=1
[    1.796738] HDMI status: Codec=0 Pin=5 Presence_Detect=1 ELD_Valid=1
[    1.798571] HDMI: detected monitor DELL U2410 at connection type HDMI
[    1.798573] HDMI: available speakers: FL/FR
[    1.798575] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000, bits = 16 20 24
[    1.800315] HDMI: detected monitor DELL U2410 at connection type HDMI
[    1.800318] HDMI: available speakers: FL/FR
[    1.800321] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000, bits = 16 20 24
[    1.800386] HDMI hot plug event: Codec=0 Pin=5 Device=0 Inactive=0 Presence_Detect=1 ELD_Valid=1
[    1.800407] HDMI status: Codec=0 Pin=6 Presence_Detect=1 ELD_Valid=1
[    1.800419] HDMI status: Codec=0 Pin=5 Presence_Detect=1 ELD_Valid=1
Comment 15 Alexander E. Patrakov 2013-09-28 07:08:38 UTC
> which pin complex is DisplayPort and which pin complex is you HDMI ?

I don't know how to figure this out. According to what you pasted, control.6 is DELL U2410, and control.12 is LG TV. Physically, DELL U2410 is connected to the DVI port using the DVI-to-HDMI cable, and LG TV to the HDMI. DisplayPort is unused.

> but your new motherboard does not have dual HDMI?

It sort-of does. It has one DVI connector that is seen as HDMI1 by xrandr and is actually connected to an HDMI encoder. Also it has a "real" HDMI connector that is seen as HDMI2 by xrandr. And it has a DisplayPort.

Also the old motherboard physically has one DVI and two HDMI sockets, but, from the software viewpoint, all three are HDMI. And actually, with the old board, the Dell monitor could produce audio clicks even when connected to the DVI output using DVI-to-HDMI cable.

So, in both cases, please treat the DVI physical connector as HDMI.
Comment 16 Raymond 2013-09-28 11:18:31 UTC
as you are using pulseaudio

what is the default sink ?

do these two available HDMI sinks have same priority ?

post the output of 

pactl stat

pactl list
Comment 17 Alexander E. Patrakov 2013-09-28 11:32:00 UTC
Sorry, I have replaced the motherboard back to Gigabyte H87N-WIFI, because it is more energy-effifient (to avoid the Streacom Nano150 PSU overload). So I cannot post any more output from the MSI board.

As for pulseaudio - it is completely irrelevant to this bug. As you can see from the comments above (including the original submission), the kernel complains even with pasuspender. If you want pulseaudio logs for some other reason, unrelated to this bug, please ask privately via e-mail.
Comment 18 Raymond 2013-09-29 03:54:13 UTC
did you only test the device 3 since your HDMI LG TV is connected to pin 6 which is device 5 ?
you are only connected your dell through DVI 
  

Advanced information - PCI Vendor/Device/Subsystem ID's
!!-------------------------------------------------------

00:03.0 0403: 8086:0c0c (rev 06)
	Subsystem: 1462:7851
--
00:1b.0 0403: 8086:8c20 (rev 04)
	Subsystem: 1462:d851





1.790068] hda-intel 0000:00:03.0: chipset global capabilities = 0x2001

[    1.790207] hda-intel 0000:00:1b.0: chipset global capabilities = 0x4401


seem haswell only support 2 SDO

only two independent HDMI streams
Comment 19 Raymond 2013-09-29 04:08:12 UTC
for multistreaming

the two streams must have different stream tags instead of Same tag 0x2




574956] hdmi_setup_stream: NID=0x5, pinctl=0x40
[   17.574958] hda_codec_setup_stream: NID=0x2, stream=0x2, channel=0, format=0x4011



[   17.578555] hdmi_setup_stream: NID=0x6, pinctl=0x40
[   17.578557] hda_codec_setup_stream: NID=0x2, stream=0x2, channel=0, format=0x4011
Comment 20 Alexander E. Patrakov 2013-09-29 04:34:01 UTC
I tested both devices. For X in 3, 7, 8 the following command produces either a click in either a TV or a monitor (on older kernels like 3.11) or no sound at all (on newer kernels from git, or on the "remaining" device that corresponds to the unconnected port), and logs "playback write error (DMA or IRQ trouble?)":

pasuspender -- aplay -D hw:0,$X /usr/share/sounds/startup3.wav

As for different vs the same stream tags - how do I test that it is indeed my problem?

P.S. there is a cat show today, I will be able to reply and test your suggestions only after it.
Comment 21 Raymond 2013-09-29 12:22:48 UTC
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/plain/Documentation/sound/alsa/HD-Audio.txt

Hint Strings
~~~~~~~~~~~~
The codec parser have several switches and adjustment knobs for
matching better with the actual codec or device behavior.  Many of
them can be adjusted dynamically via "hints" strings as mentioned in
the section above.  

try specify hint

stick_stream = false for haswell hdmi


- sticky_stream (bool): keep the PCM format, stream tag and ID as long
  as possible; default true



- trigger_sense (bool): indicates that the jack detection needs the
  explicit call of AC_VERB_SET_PIN_SENSE verb


- indep_hp (bool): provide the independent headphone PCM stream and
  the corresponding mixer control, if available


For alc892

trigger_sense = false
indepdent_hp = true
Comment 22 Raymond 2013-09-29 12:36:39 UTC
it seem that MSI user manual does not mention how to support 7.1 for desktop motherboard with 5 stack

even intel web site does not mention which jack need to be retask for (side channel playback)

http://www.intel.com/support/motherboards/desktop/sb/CS-034198.htm

8-channel audio
8-channel audio is available only on certain Intel® Desktop Boards. After installing the audio driver from the Intel Express Installer CD, multi-channel audio can be enabled:

    Connect speakers to A, B, C, D, or E as shown in the figure below, up to eight speakers.
Comment 23 Alexander E. Patrakov 2013-09-30 03:41:19 UTC
Raymond,

echo stick_stream = false > /sys/devices/pci0000:00/0000:00:03.0/sound/card0/hwC0D0/hints

does not help the IRQ or DMA problem.

And please do not hijack the bug for your multistreaming remarks.
Comment 24 Raymond 2013-09-30 03:44:45 UTC
did you rebbot the computer or reloaded the modules or dynamic reconfiguration ?
Comment 25 Raymond 2013-09-30 04:06:00 UTC
did you perform dynamic reconfigure 

# echo 1 > /sys/class/sound/hwC0D0/reconfig  


or

Early Patching
~~~~~~~~~~~~~~
When CONFIG_SND_HDA_PATCH_LOADER=y is set, you can pass a "patch" as a
firmware file for modifying the HD-audio setup before initializing the
codec.  This can work basically like the reconfiguration via sysfs in
the above, but it does it before the first codec configuration.

A patch file is a plain text file which looks like below:

------------------------------------------------------------------------
  [codec]
  0x12345678 0xabcd1234 2

  [model]
  auto

  [pincfg]
  0x12 0x411111f0

  [verb]
  0x20 0x500 0x03
  0x20 0x400 0xff

  [hint]
  jack_detect = no
------------------------------------------------------------------------


The hd-audio driver reads the file via request_firmware().  Thus,
a patch file has to be located on the appropriate firmware path,
typically, /lib/firmware.  For example, when you pass the option
`patch=hda-init.fw`, the file /lib/firmware/hda-init.fw must be
present.
Comment 26 Alexander E. Patrakov 2013-09-30 16:04:44 UTC
With the Gigabyte board, I did the following, without any effect except a single click. Note: no matter which HDMI device I specify, the click is most often in the TV speakers, not in the monitor output. But sometimes (rarely) the same aplay command produces a click both in the TV speakers and on the monitor output.

Created /lib/firmware/hda-init.fw with the following contents:

[hint]
stick_stream = false

Ran the following commands, without pulseaudio running:

fuser -k /dev/snd/* ; rmmod snd-hda-intel

modprobe snd-hda-intel patch=hda-init.fw

aplay -D hdmi:0,0 /usr/share/sounds/startup3.wav 

aplay -D hdmi:0,2 /usr/share/sounds/startup3.wav # in another terminal

Both aplay commands complete very slowly by themselves and lead to "playback write error (DMA or IRQ trouble?)" in the dmesg.
Comment 27 Raymond 2013-09-30 16:23:56 UTC
 should be sticky_stream = false

sticky_stream (bool): keep the PCM format, stream tag and ID as long as possible; default true


is it normal for the graphic driver get EDID from the dell monitor connected through dvi using DVI-HDMI adapter ?


only  HDMI and Displayport are defined in the two bits CONNECTOR TYPE field in EDID
Comment 28 Alexander E. Patrakov 2013-09-30 16:33:25 UTC
I have corrected the typo. Same effect: either a click in either the monitor or the TV, or no click at all, randomly.
Comment 29 Alexander E. Patrakov 2013-09-30 16:38:34 UTC
As for the EDID-over-HDMI-masquerading-as-DVI question - I think it is normal. At work, we had an Asrock-based machine with the onboard NVidia card, and a Fujitsu monitor connected to its DVI output via the DVI-to-HDMI cable. It worked as it should, including audio. Cannot recheck, as someone in the other department took that machine.
Comment 30 Alexander E. Patrakov 2013-10-01 04:23:57 UTC
Yesterday I made an observation by adding a few printk()s into azx_interrupt() (yes, I know, that's bad). The IRQs come fine when codec parameters are changed in the driver (but of course they are not consumed by snd_pcm_period_elapsed()). They don't come at all (or only one IRQ comes) when they are needed for snd_pcm_period_elapsed(). Could anyone please tell me how to check if they are somehow disabled by mistake?
Comment 31 Alexander E. Patrakov 2013-10-02 18:23:26 UTC
Created attachment 110171 [details]
Debug patch

A patch that adds some printks about IRQ handling
Comment 32 Alexander E. Patrakov 2013-10-02 18:33:17 UTC
Created attachment 110181 [details]
Dmesg with the debugging patch above

Dmesg from today's drm-intel/drm-intel-nightly with the debugging patch on top. No special kernel or snd_hda_intel options.

First I attempted to play sound via hdmi:0,0, then through plughw:1,0. In the HDMI case, only the first (bogus) interrupt comes through after starting the playback. 3.11.0 behaves the same, please disregard the comment about the difference above.
Comment 33 Alexander E. Patrakov 2013-10-02 18:35:35 UTC
Also I tried the following stupid hack on top of 3.11.0:

1. Deleted the !azx_dev->irq_pending check from azx_irq_pending_work()
2. Replaced all cases where azx_position_ok() returns -1 with the return code 0.
3. Made azx_irq_pending_work() reenqueue itself after msleep(10) instead of just returning when nothing is pending.

I.e. I effectively forced pending IRQ processing to run every 10 ms. Result: no complaints about IRQ or DMA problem, and "time aplay ..." takes about half of the time it should take. With only one copy of aplay, no sound (no matter which device I use and which output I listen to). With two copies of aplay (one for hdmi:0,0 and one for hdmi:0,2) there is crackling sound in the monitor's output, and, if the TV is also connected, from the TV.
Comment 34 Roc Vallès 2013-10-05 10:53:54 UTC
I'm experiencing the same issue on my GA-H87N-WIFI (same board), with an i5 4670 CPU.
Comment 35 Alexander E. Patrakov 2013-10-05 12:15:59 UTC
Breakthrough: HDMI audio works using Debian's kernel (3.10-3-amd64, from linux-image-3.10-3-amd64_3.10.11-1_amd64.deb). So it is some regression introduced after v3.10.
Comment 36 Alexander E. Patrakov 2013-10-05 14:35:07 UTC
This is not an introduced regression. It is a motherboard (hardware) bug well-hidden by some configuration option that differs in my kernel and in Debian kernel.

I have not yet identified the relevant set of configuration options, but disabling VT-d in the BIOS, or, alternatively, passing intel_iommu=off to the kernel command line allows the hardware to play the first period. Then it hangs (receives no further interrupts) in my kernel and happily continues in the Debian kernel.
Comment 37 Alexander E. Patrakov 2013-10-05 14:35:56 UTC
Forgot to say that CONFIG_INTEL_IOMMU_DEFAULT_ON=y in my kernel and =n in Debian kernel.
Comment 38 Alexander E. Patrakov 2013-10-05 18:12:38 UTC
OK, to get a working 3.10.14 kernel, two options are essential

CONFIG_INTEL_IOMMU_DEFAULT_ON=n (with y, I get complete silence)

CONFIG_SND_HDA_PREALLOC_SIZE=64 (with 1024, only the first period is played)

I have not yet tried these options on newer kernels.
Comment 39 Alexander E. Patrakov 2013-10-05 18:59:01 UTC
Changing these two options also helps on new kernels. So, I have a viable solution to my problem, but leave the bug open, as the failure mode is quite mysterious. Please add quirks so that IOMMU is not used on either of the boards, and that MID does not accept too-big preallocated buffers (even though SUSE had 1024 as the default for a long time - now we have a situation where this leads to bugs).
Comment 40 Alexander E. Patrakov 2013-10-05 19:02:09 UTC
Created attachment 110261 [details]
Good dmesg, just in case
Comment 41 Alexander E. Patrakov 2013-10-05 19:02:38 UTC
Created attachment 110271 [details]
Good config
Comment 42 Takashi Iwai 2013-10-07 08:01:57 UTC
Did you try intel_iommu=on,igfx_off boot option?  This allows IOMMU on other devices but disables the broken graphics (and HDMI audio).

Regarding the buffer size, try snoop=false option for snd-hda-intel, at first.
The restriction of preallocation size is not real solution, it just happens to work, and inappropriate to put into the driver statically as a quirk.
Comment 43 Alexander E. Patrakov 2013-10-07 15:52:52 UTC
Tried intel_iommu=on,igfx_off snd_hda_intel.snoop=0

Results are the same as with just disabling the IOMMU - i.e. one period plays, and then it gets stuck. So intel_iommu=igfx_off is useful, snd_hda_intel.snoop=0 has no effect.
Comment 44 Takashi Iwai 2013-10-07 16:03:26 UTC
Another thing to test is to pass enable_msi=0 to snd-hda-intel.
Comment 45 Alexander E. Patrakov 2013-10-07 16:30:45 UTC
Also tried: intel_iommu=igfx_off snd_hda_intel.snoop=0 snd_hda_intel.enable_msi=0

Result: the card still gets stuck.

P.S. I am currently in #alsa on freenode as patrakov and will be there for one hour, let's talk there if you want more interactive debugging.
Comment 46 Takashi Iwai 2013-10-08 07:07:46 UTC
OK, then try to adjust the preallocation size on the fly.  It can be changed via proc file, e.g.
   echo 1024 > /proc/asound/card1/pcm3p/sub0/prealloc
Comment 47 Alexander E. Patrakov 2013-10-08 09:11:52 UTC
I don't quite understand what you wanted me to test in comment #46. So I built some kernels with CONFIG_SND_HDA_PREALLOC_SIZE set to different values, and also tried to echo various values to /proc/asound/card0/pcm?p/sub0/prealloc (because HDMI is card0 here). Result: no matter how the value ends up in prealloc, values of 84 and below work, 88 and above don't, and once the card has seen 88 or higher while playing, there is no way out. The card won't play even the first period on the attempt to use aplay after "correcting" the situation.

Note: this testing was with a 44100 Hz S16_LE stereo wav file. Will reboot now and retest with different files.
Comment 48 Alexander E. Patrakov 2013-10-08 09:20:45 UTC
With prealloc = 88, this works:

Slave: Hardware PCM card 0 'HDA Intel MID' device 3 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 32000
  exact rate   : 32000 (32000/1)
  msbits       : 16
  buffer_size  : 16000
  period_size  : 4000
  period_time  : 125000
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 4000
  period_event : 0
  start_threshold  : 16000
  stop_threshold   : 16000
  silence_threshold: 0
  silence_size : 0
  boundary     : 9007199254740992000
  appl_ptr     : 0
  hw_ptr       : 0

This doesn't:

Slave: Hardware PCM card 0 'HDA Intel MID' device 3 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 22052
  period_size  : 5513
  period_time  : 125011
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 5513
  period_event : 0
  start_threshold  : 22052
  stop_threshold   : 22052
  silence_threshold: 0
  silence_size : 0
  boundary     : 6207086186423386112
  appl_ptr     : 0
  hw_ptr       : 0

With prealloc = 84, this works:

Slave: Hardware PCM card 0 'HDA Intel MID' device 3 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 21504
  period_size  : 5376
  period_time  : 121904
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 5376
  period_event : 0
  start_threshold  : 21504
  stop_threshold   : 21504
  silence_threshold: 0
  silence_size : 0
  boundary     : 6052837899185946624
  appl_ptr     : 0
  hw_ptr       : 0
Comment 49 Takashi Iwai 2013-10-08 09:24:01 UTC
Build CONFIG_SND_HDA_PREALLOC_SIZE=1024 as is, but adjust the prealloc size later on the running system via echo to a proc file.

At the untouched state, confirm that it shouldn't work (it's 1024).  Then change to 64, and check that it works.  Then echo 1024, check that it's actually changed (cat the same proc file will show the current value), then confirm that it breaks again.
Comment 50 Takashi Iwai 2013-10-08 09:25:32 UTC
Also, if it has something to do with buffer pages, you can try to disable 64bit DMA.  Add AZX_DCAPS_NO_64BIT should do it:

--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -610,7 +610,7 @@ enum {
         AZX_DCAPS_COUNT_LPIB_DELAY)
 
 #define AZX_DCAPS_INTEL_PCH \
-       (AZX_DCAPS_INTEL_PCH_NOPM | AZX_DCAPS_PM_RUNTIME)
+       (AZX_DCAPS_INTEL_PCH_NOPM | AZX_DCAPS_PM_RUNTIME | AZX_DCAPS_NO_64BIT)
 
 /* quirks for ATI SB / AMD Hudson */
 #define AZX_DCAPS_PRESET_ATI_SB \
Comment 51 Alexander E. Patrakov 2013-10-08 09:55:09 UTC
I have not tried your patch, but found that intel_iommu=on,igfx_off snd_hda_intel.align_buffer_size=1 fixes the problem. Should I still try the patch?
Comment 52 Takashi Iwai 2013-10-08 12:05:06 UTC
Hm, interesting.  I haven't heard of this for Intel chip.
Maybe specific to the combination of Haswell and HDMI and IOMMU.

But, yes, it's still interesting to check whether it influences on the behavior.  Test with and without align_buffer_size option.
Comment 53 Alexander E. Patrakov 2013-10-08 15:55:31 UTC
The patch does not help me to remove any of the following kernel parameters: intel_iommu=on,igfx_off snd_hda_intel.align_buffer_size=1. OTOH, it does not make the IRQ situation worse when both of those parameters are present.
Comment 54 Alexander E. Patrakov 2013-10-08 15:56:16 UTC
In other words, the patch has no visivle effect.
Comment 55 Raymond 2013-10-08 23:39:10 UTC
is the alignment only for haswell ?

how about your Intel hda controller with alc892 ?


859051] HDMI: detected monitor LG TV at connection type HDMI
[    1.859054] HDMI: available speakers: FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC FLW/FRW FLH/FRH TC FCH
[    1.859056] HDMI: supports coding type AC-3: channels = 6, rates = 32000 44100 48000, max bitrate = 640000
[    1.859059] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000 96000 192000, bits = 16 20 24


does playing audio different rate , channel , format to two HDMI TV at the same time work ?


321.906316] hdmi_setup_stream: NID=0x5, pinctl=0x40
[  321.906317] hda_codec_setup_stream: NID=0x2, stream=0x2, channel=0, format=0x4011

[  339.856738] hda-intel 0000:00:03.0: azx_pcm_prepare: bufsize=0x10000, format=0x4011
[  339.857090] hdmi_setup_stream: NID=0x7, pinctl=0x40
[  339.857091] hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x4011
Comment 56 Alexander E. Patrakov 2013-10-09 03:54:46 UTC
It is indeed possible to output two independent streams with different sample rates via two HDMI outputs.

The analog controller never had any problems that required patches or kernel parameters. It also allows independent analog and spdif streams with different sample rates.
Comment 57 Alexander E. Patrakov 2013-11-02 14:03:18 UTC
Hello Takashi,

I find it surprising that, despite the correct options being known, there is still no patch that adds a quirk. Is there any additional information that I need to add to the bug?
Comment 58 Raymond 2013-11-02 23:48:47 UTC
have you ask those Intel developers if you think your Intel controller need align buffer ?


http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/hda_intel.c?id=2ae66c26550cd94b0e2606a9275eb0ab7070ad0e
Comment 59 Alexander E. Patrakov 2013-11-04 12:32:08 UTC
If I read the code correctly, AZX_DCAPS_BUFSIZE means "this device does not need buffer size alignment".

And this code says that no Intel HD audio device needs buffer size alignment:

	/* Generic Intel */
	{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_ANY_ID),
	  .class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8,
	  .class_mask = 0xffffff,
	  .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_BUFSIZE },

...which is false according to the findings in this bug. I will try to insert an entry before this and see if it helps.

I do realize that I have not indicated whether both quirks apply to both boards - I don't know yet and have to test. Unfortunately, the construction of the fanless case makes it hard to disassemble, so I will definitely not test the MSI board today :(

An Intel engineer is already in the CC list.
Comment 60 Takashi Iwai 2013-11-04 17:39:15 UTC
Well, the biggest question is whether this is specific to what parameter, IOW, which condition triggers the bug.  Is it only on your mobo models, or only on a certain chipset, or only on some chipset revisions, or specific to (all) Haswell models, or happening only with combination of IOMMU (or any other kernel) setup?
It's hard to answer without more testing.

And, I have a bunch of (more than 20) Haswell machines here for testing, and none of them show such a problem.  That's why I didn't apply any patch, so far; i.e. you're the only person hitting the issue, and it can be worked around by a known option :)

Once if we can narrow down the condition, I'd be glad to apply the fix.
Comment 61 Alexander E. Patrakov 2013-11-05 15:23:22 UTC
As I promised, I have replaced the motherboard to MSI temporarily.

Results of the test: the MSI motherboard also needs both quirks (intel_iommu=on,igfx_off snd_hda_intel.align_buffer_size=1). So, as far as I am able to generalize from my data, the quirk needs to go on any 8086:0c0c device, regardless of any subsystem vendor/device IDs.
Comment 62 Alexander E. Patrakov 2013-11-05 15:39:45 UTC
Just to stress this again, the bug needs some very specific conditions to trigger:

1. CONFIG_SND_HDA_PREALLOC_SIZE=1024 (or in fact anything greater than 128)
2. CONFIG_INTEL_IOMMU_DEFAULT_ON=y
3. IOMMU enabled in the BIOS
4. A sound file with S16_LE, 44100 Hz, stereo - otherwise alsa-lib would choose a period size that is a multiple of 128
5. Testing directly with aplay -D hdmi:0,X - not via pulseaudio, and not via speaker-test, otherwise non-round period size will not be chosen

Takashi: are you sure that you have satisfied all those conditions during your tests? Even one unsatisfied condition could lead to you happily saying "there is no bug on this machine", while it in fact exists.
Comment 63 Takashi Iwai 2013-11-05 16:21:58 UTC
Hrm, OK, maybe it's safer to set the alignment for Haswell HDMI generically.

But before doing it: could you check whether the same problem happens even without IOMMU?  I guess this is independent from that.
Comment 64 Alexander E. Patrakov 2013-11-05 16:26:43 UTC
On the Gigabyte board, snd_hda_intel.align_buffer_size=1 is needed even with IOMMU disabled in the BIOS. Let me recheck with MSI, and please join #alsa or #pulseaudio on freenode if you want more interactive debugging.
Comment 65 Alexander E. Patrakov 2013-11-05 16:33:12 UTC
Well, the MSI board does not even have a setting to disable IOMMU in the BIOS. So nothing to test.
Comment 66 Takashi Iwai 2013-11-05 16:39:52 UTC
OK, thanks for quick tests.
Below is the patch I'm going to apply.  Please let me know if this works.
Comment 67 Takashi Iwai 2013-11-05 16:40:34 UTC
Created attachment 113501 [details]
Fix buffer alignment for Haswell HDMI controllers
Comment 68 David Woodhouse 2013-11-05 16:42:46 UTC
I'm confused by the IOMMU aspect of this. Surely the DMA for the *audio* will still from from the HD Audio controller, not from the graphics device? So turning off the IOMMU from the graphics device really shouldn't make any difference?

And if there's some mixup in hardware and the DMA transactions are actually happening with the PCI source-id of the graphics device instead of the HD audio controller... then we should see *faults*. But we don't; instead the DMA just silently fails?

How is the integration between the graphics and audio devices supposed to work?
Comment 69 Takashi Iwai 2013-11-05 16:48:49 UTC
In the case of Intel HDMI, the audio device is a kind of slave of GPU.  The actual data is handled solely in the graphics side.

And, on the recent Intel chips like Haswell, both are integrated more tightly.  For example, if GPU is turned off, just accessing to the audio PCI register gives kernel Oops or a hard lockup, although it looks independent in the PCI level.
Comment 70 David Woodhouse 2013-11-05 16:57:55 UTC
Please could you upload the DMAR tables from the offending machines? (/sys/firmware/acpi/tables/DMAR)
Comment 71 Alexander E. Patrakov 2013-11-05 16:59:34 UTC
(In reply to Takashi Iwai from comment #67)
> Created attachment 113501 [details]
> Fix buffer alignment for Haswell HDMI controllers

The patch works.
Comment 72 Alexander E. Patrakov 2013-11-05 17:04:35 UTC
Created attachment 113511 [details]
DMAR from the MSI board

I will not attach the DMAR from the Gigabyte board today, because it is rather hard to disassemble and reassemble the whole computer. At any given moment, at most one of those boards can be in my computer, because I don't have two Haswell CPUs.
Comment 73 Alexander E. Patrakov 2013-11-06 15:13:38 UTC
(yes I know this is unrelated to this bug)

(In reply to Raymond from comment #22)
> it seem that MSI user manual does not mention how to support 7.1 for desktop
> motherboard with 5 stack

Please don't worry. On the MSI board, 7.1 works over analog output out of the box. Here is what goes where, both according to the labels and to the fact:

Line In: blue jack
Front Left/Right: green jack
Microphone: red jack
Surround left/right: black jack
Center/LFE: orange (meant to be brown?) jack
Side Left/Right: light-gray jack
Comment 74 Raymond 2013-11-06 15:31:16 UTC
but your info did not have the channel mode to select 6ch , 8ch 




http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=a07a949be6eb1c9aab06adaadce72dbd27b7d9cb

ALSA: hda - Fix multi-io channel mode management
The multi-io channels can vary not only from 1 to 6 but also may vary
from 6 to 8 or such.  

spec->multi_ios = 1 when only  blue Jack is used for retasking 


 if (spec->multi_ios == 2) {
 		for (i = 0; i < 2; i++)
 			spec->private_dac_nids[spec->multiout.num_dacs++] =
 				spec->multi_io[i].dac;
 	} else if (spec->multi_ios) {
 		spec->multi_ios = 0;
 		badness += BAD_MULTI_IO;
 	}
Comment 75 Alexander E. Patrakov 2013-11-06 16:59:59 UTC
Raymond: there was indeed no such switch. From my "user" viewpoint, I don't see why it would be necessary on that board, as there are enough connectors and there is never any need to retask jacks. IOW, there is indeed no way to switch the board into a 5.1 mode and no need to do so.
Comment 76 Alexander E. Patrakov 2013-11-06 17:08:56 UTC
Created attachment 113661 [details]
DMAR from the Gigabyte board

I have replaced the board again in order to get the DMAR info. Unfortunately, in the process, one of the adhesive pads that keep the nuts from the passive cooling system in place was damaged.

This means slightly suboptimal position of the passive heatsink (but it still survives the full CPU load) and, more importantly, physical impossibility to remove the heatsink again (well, maybe with the help of thin flat pliers this is fixable, but I don't have them at hand now). So no more motherboard changes for your testing, I am stuck with Gigabyte :(

I do have a backup copy of "lspci -nnvv", "dmidecode --dump-bin" and all ACPI tables that were exposed in sysfs from the MSI board.
Comment 77 Alexander E. Patrakov 2014-02-22 13:24:31 UTC
Erased that lspci/dmidecode backup by accident :(

David Woodhouse: with both DMARs attached to this bug, why there is no further progress in the IOMMU side of the bug?
Comment 78 da_audiophile 2014-03-22 10:35:56 UTC
Alexander - I am considering the MSI Z87I and am wondering if your bug is still present in kernel version 3.13.6 (current stable) or in 3.14-rc7 (current rc).
Comment 79 Alexander E. Patrakov 2014-03-22 13:01:36 UTC
The buffer alignment bug is fixed. As for the IOMMU bug, I don't know. I still have a workaround on my kernel command line and I am too lazy to check whether it is still needed. However, the IOMMU bug, even if it still exists, is so easily workaroundable that you should not consider it as an argument against this board.
Comment 80 Mengdong Lin 2014-03-24 01:13:48 UTC
3.14-rc7 should have the bug fix patch by Takashi.
Not sure about 3.13.6
Comment 81 Alexander E. Patrakov 2014-07-14 04:34:54 UTC
Ping about the IOMMU bug.
Comment 82 st.smartie 2014-10-14 04:04:59 UTC
Ping about the IOMMU bug. 

The IOMMU broke my hdmi sound outputs on my ASUS B85M-G. I am developing intel IGD virtualization, so 'igfx_off' is not a way for me.

Should I file another bug to cover this issue?
Comment 83 Alan 2014-10-23 14:04:21 UTC
*** Bug 86311 has been marked as a duplicate of this bug. ***
Comment 84 Jani Nikula 2015-01-28 14:51:20 UTC
*** Bug 67321 has been marked as a duplicate of this bug. ***
Comment 85 Jani Nikula 2015-01-28 14:51:37 UTC
*** Bug 86221 has been marked as a duplicate of this bug. ***
Comment 86 Steven Brudenell 2015-04-13 20:40:04 UTC
Another ping. I've also had problems with Haswell + HDMI audio + IOMMU. For me, using the media player Kodi to bitstream AC3 or DTS data over HDMI doesn't work (other types of audio data work though).

This only happens with intel_iommu=on or CONFIG_INTEL_IOMMU_DEFAULT_ON=y. With IOMMU enabled I also see this line in dmesg:

[   35.168233] snd_hda_intel 0000:00:03.0: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.

My hardware is an Intel Haswell NUC D54250WYK.

I posted more info at http://forum.kodi.tv/showthread.php?tid=224324 if that helps.
Comment 87 Alza 2015-11-12 23:10:32 UTC
Hi there,

I also seem to be affected by this issue (Haswell i7-4790k, Asus Maximus Hero VII).

No HDMI Audio from integrated Intel HD 4600 graphics, with intel_iommu=on (I need this turned on in order to do GPU passthrough for a discrete Nvidia adapter). 

There is no audio being output, even though every command I try seems to confirm the HDMI audio device is present and 'working'.

Finally, can anyone confirm whether or not Skylake CPU's are also affected by this issue, or is the issue limited to Haswell CPU's only?

Thanks,
Comment 88 PS 2015-11-16 19:47:39 UTC
I also have the sound problem with intel_iommu=on and hdmi output via HDMI on a haswell cpu + nvidia gpu (Intel i7-4702HQ 2.2-3.2Ghz and GT750M). Is there any hope of getting this fixed to make PCI passthrough possible? Thanks !

Outputs + logs:
https://bbs.archlinux.org/viewtopic.php?id=204460
Comment 89 PS 2015-11-16 19:58:12 UTC
(In reply to etfaker from comment #88)
> I also have the sound problem with intel_iommu=on and hdmi output via HDMI
> on a haswell cpu + nvidia gpu (Intel i7-4702HQ 2.2-3.2Ghz and GT750M). Is
> there any hope of getting this fixed to make PCI passthrough possible?
> Thanks !
> 
> Outputs + logs:
> https://bbs.archlinux.org/viewtopic.php?id=204460

I should add that I also have no or very crappy/stuttering/low quality sound output via HDMI with intel_iommu=on which makes it useless :/ but I need it.
Comment 90 Adrian Sandu 2016-03-22 09:31:21 UTC
And .. after some days when I thought I was getting mad... or something wrong with my mobo ... I found this which fits perfectly !
I've never used my onboard hdmi .. now I use it since I passthrough the nvidia card to a VM and use the onboard hdmi to use it on the regular system ( maybe even launch a kodi if audio would work ).

So, workarounds ? Any way I can help debug ?

I'm on a 4.4.3 kernel, the cpu is a i7-4790 ( without the K ), the mobo is a ASUS H97-PRO GAMER. I don't use it for gaming though .. but more as a server and desktop ..
Comment 91 Alza 2016-04-01 17:23:56 UTC
Hi again,

Just a quick update subsequent to my original comment (see below)

I recently upgraded from Haswell to Skylake (i6700k, Asus Maximus Hero VIII Alpha) and it would appear that I no longer have the HDMI audio issue..

As in:

- I have vt-d enabled in the bios
- My currently booted kernel has iommu=on (verified via 'cat /proc/cmdline')
- The iommu seems to be working (verified via 'dmesg | grep iommu' and 'find /sys/kernel/iommu_groups/ -type l')
- With the above in place, I appear to have working HDMI audio (from the integrated Intel HD 530 graphics)

This would suggest the problem is Haswell specific, since Skylake doesn't appear to be affected?

Thanks,

(In reply to Alza from comment #87)
> Hi there,
> 
> I also seem to be affected by this issue (Haswell i7-4790k, Asus Maximus
> Hero VII).
> 
> No HDMI Audio from integrated Intel HD 4600 graphics, with intel_iommu=on (I
> need this turned on in order to do GPU passthrough for a discrete Nvidia
> adapter). 
> 
> There is no audio being output, even though every command I try seems to
> confirm the HDMI audio device is present and 'working'.
> 
> Finally, can anyone confirm whether or not Skylake CPU's are also affected
> by this issue, or is the issue limited to Haswell CPU's only?
> 
> Thanks,
Comment 92 Robert Hancock 2016-04-07 00:51:17 UTC
I have a problem with HDMI audio on Haswell integrated video that may be related as described in this PulseAudio bug report:

https://bugs.freedesktop.org/show_bug.cgi?id=94804

If I have "intel_iommu=on" on the kernel command line without adding "igfx_off", the HDMI audio works, but with significant timing problems. When playing a video, either the audio and video quickly start to drift out of sync, up to a few seconds off, or (in VLC's case) it starts having audio dropouts and complaining like this:

core warning: picture is too late to be displayed (missing 25 ms)
core debug: picture might be displayed late (missing 13 ms)
core warning: playback way too early (-121209): playing silence
core debug: inserting 5818 zeroes
core warning: playback too early (-40158): down-sampling
core warning: timing screwed (drift: -81704 us): stopping resampling
core warning: playback too early (-82366): down-sampling
core warning: playback way too early (-121032): playing silence
core debug: inserting 5809 zeroes
core debug: auto hiding mouse cursor
core warning: playback too early (-40230): down-sampling
core debug: auto hiding mouse cursor
core warning: timing screwed (drift: -80762 us): stopping resampling
core warning: playback too early (-81447): down-sampling
core warning: playback way too early (-120541): playing silence
core debug: inserting 5785 zeroes

Note You need to log in before you can comment on or make changes to this bug.