Ubuntu 21.10 / Tiger Lake sound?

Hmm, okay, then it’s not the kill switch (that switch only disables the mic, not sound output).

I’d use this guide to make sure the audio cable is plugged in all the way (go up to step 5 and then close it back up, since you’re not replacing the audio board).

No luck there. It was very well-seated; I cycled both ends of the ribbon cable, but I still only see “Dummy output”

Just FYI, I have sound but no microphone on mine as well. I suspect driver issue because microphone used to work. I’m on openSUSE with 5.15.1

@Bryan_Elliott U21.10 works ok for me. The dmesg output you shared is a little unusual since it shows no response from codec.

$ uname -a 
  Linux***5.13.0-22-generic #22-Ubuntu SMP Fri Nov 5 13:21:36 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

$ sudo dmesg -k | grep snd_hda_intel
[  258.312185] snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040380
[  258.312239] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002)
[  258.315667] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])

What bios version do you have? Do you have a Tempo mainboard or Realtek Mainboard?

   sudo dmidecode --type bios

For the mainboard type: you can run

sudo dmidecode --type chassis 

And share the first 10 digits of the serial number.

1 Like

uname -a

Linux sproket 5.13.0-22-generic #22-Ubuntu SMP Fri Nov 5 13:21:36 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

sudo dmidecode --type bios

# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.

Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
	Vendor: INSYDE Corp.
	Version: 03.06
	Release Date: 10/18/2021
	Address: 0xE0000
	Runtime Size: 128 kB
	ROM Size: 12 MB
	Characteristics:
		PCI is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		8042 keyboard services are supported (int 9h)
		CGA/mono video services are supported (int 10h)
		ACPI is supported
		USB legacy is supported
		BIOS boot specification is supported
		Targeted content distribution is supported
		UEFI is supported
	BIOS Revision: 3.6

Handle 0x0011, DMI type 13, 22 bytes
BIOS Language Information
	Language Description Format: Long
	Installable Languages: 4
		en|US|iso8859-1,0
		fr|FR|iso8859-1,0
		zh|TW|unicode,0
		ja|JP|unicode,0
	Currently Installed Language: en|US|iso8859-1,0

sudo dmidecode --type chassis | sed -e 's/\(Serial Number\|Asset Tag\): \([[:alnum:]]\{10\}\)[[:alnum:]]*$/\1: \2********/'

# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.

Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
	Manufacturer: Framework
	Type: Notebook
	Lock: Not Present
	Version: AA
	Serial Number: FRANBMCPAA********
	Asset Tag: FRANBMCPAA*********
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Safe
	Security Status: None
	OEM Information: 0x00000000
	Height: Unspecified
	Number Of Power Cords: 1
	Contained Elements: 0
	SKU Number: FRANBMCP0A

Wanna hear something fun? Last night just before bed, I had sound working (through no action but a couple reboots), and I figured I’d report back after work. I put it to sleep to switch to my company computer and when I woke it back up: no sound again.

Hey everyone,

I’m new here and pretty new to Ubuntu as well but wanted to share how I fixed my dummy output issue. Initially I had the same issue where my Output device was designated as Dummy Output and nothing was visible in the Input Device, even after toggling the physical switch. The issue turned out the me with the official instructions for how to make the 3.5mm jack support, here. After Removing:
options snd-hda-intel model=dell-headset-multi
from:
/etc/modprobe.d/alsa-base.conf
Everything started working perfectly.
Hope this helps,
Cheers!

My laptop seems to be affected by the same issue and since upgrading to Ubuntu 22.04 didn’t fix it (my secret hope), I’d hope for some support in the forums.

So:

  • “aplay” on a wav file runs but gives no audio output
  • My Pulseaudio setup only shows “Dummy Ausgabe” (German for “Dummy Output”) as an output device. Sound typically can’t be heard. Listing via command line ‘pacmd list-sinks’:
1 sink(s) available.
  * index: 0
	name: <auto_null>
	driver: <module-null-sink.c>
	flags: DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY
	state: RUNNING
	suspend cause: (none)
	priority: 1000
	volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 100% / 0.00 dB
	        balance 0.00
	base volume: 65536 / 100% / 0.00 dB
	volume steps: 65537
	muted: no
	current latency: 1648.55 ms
	max request: 344 KiB
	max rewind: 344 KiB
	monitor source: 0
	sample spec: s16le 2ch 44100Hz
	channel map: front-left,front-right
	             Stereo
	used by: 1
	linked by: 1
	configured latency: 2000.00 ms; range is 0.50 .. 2000.00 ms
	module: 13
	properties:
		device.description = "Dummy-Ausgabe"
		device.class = "abstract"
		device.icon_name = "audio-card"
  • My Framework is running Ubuntu 22.04 but the issue was already there on Ubuntu 21.10.
  • I’m on BIOS v3.07 which should be current:
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.

Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
	Vendor: INSYDE Corp.
	Version: 03.07
	Release Date: 12/14/2021
	Address: 0xE0000
	Runtime Size: 128 kB
	ROM Size: 12 MB
	Characteristics:
		PCI is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		8042 keyboard services are supported (int 9h)
		CGA/mono video services are supported (int 10h)
		ACPI is supported
		USB legacy is supported
		BIOS boot specification is supported
		Targeted content distribution is supported
		UEFI is supported
	BIOS Revision: 3.7

Handle 0x0011, DMI type 13, 22 bytes
BIOS Language Information
	Language Description Format: Long
	Installable Languages: 4
		en|US|iso8859-1,0
		fr|FR|iso8859-1,0
		zh|TW|unicode,0
		ja|JP|unicode,0
	Currently Installed Language: en|US|iso8859-1,0
  • my chassis information (I’m impressed by the ‘sed’ expression):
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.

Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
	Manufacturer: Framework
	Type: Notebook
	Lock: Not Present
	Version: AA
	Serial Number: FRANBMCPAA********
	Asset Tag: FRANBMCPAA********
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Safe
	Security Status: None
	OEM Information: 0x00000000
	Height: Unspecified
	Number Of Power Cords: 1
	Contained Elements: 0
	SKU Number: FRANBMCP0A
  • what seems weird to me is that the snd_hda_intel module reports a codec issue:
[   14.326522] snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040380
[   14.326582] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002)
[   14.326817] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[   15.343764] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000
[   16.351890] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x000f0000
[   17.355750] snd_hda_intel 0000:00:1f.3: Codec #0 probe error; disabling it...
  • I’ve tried with and without the “dell-headset-multi” option in ‘/etc/modprobe.d/alsa-base.conf’ but I see no effect there.
  • I cannot really tell what makes the sound work sometimes… and sometimes not work. Could these really be loose cables on the sound board!?

To be clear, I still don’t have a solution for this. Whether sound works is kinda random on boot and, if I’m lucky enough to have it working, I try very hard not to shut the laptop down or suspend it.

It kinda sucks. The model setting for snd_hda_intel doesn’t do anything.

I have the exact same behavior here except mine is not intermittent - it has literally never worked (My framework is gen-less, Tempo chip, I5, bought about 3 weeks ago).

But it works on Windows 10 using the standard MS driver, and it works on Windows 10 inside a QEMU VM with the Tiger Lake sound device passed through to the VM. It doesn’t matter what OS I use - everything down to 18.04 Ubuntu, Void, Manjaro, Debian, Arch all display the exact same behaviour outlined in the logs.

I suspect this is an initialization bug in the BIOS or linux driver for some reason, and has been worked around in Windows. Why it only affects some Frameworks and not others is an absolute mystery to me and so far, Framework support have been rather silent on the matter. I don’t know much about SOF / the Intel HDA driver but I’ve been poking around in the kernel source / Tempo data sheet to see if I can work out what’s going on, but since I can’t see what Windows is doing differently it’s kinda flying blind.

Using

snd-hda-intel model=dell-headset-multi

is not needed on mainboards with the Tempo codec. I think this may pass some invalid parameters to the codec.

However This does not sound like the root cause of issues most people are experiencing in this thread.

The Mic switch only cuts off the mic, not audio output.

If someone could enable hda tracing and unload and reload the snd_hda_intel module, it might shed some light onto what is happening.

echo 1 > /sys/kernel/debug/tracing/events/hda/enable

reload the snd_hda_intel module

cat /sys/kernel/debug/tracing/trace

And lets see what shows up

modprobe -r -f -a snd_hda_intel fails with

FATAL: Module snd_intel_dspcfg is in use

So does modprobe -r -f -a snd_intel_dspcfg

@Kieran_Levin

Nothing shows up.

I’m using the following script to unload and reload the module:

CADDR="0000:00:1f.3"
DRIVERS="snd_sof_pci_intel_tgl snd_sof_intel_hda snd_hda_codec_hdmi snd_hda_intel snd_soc_skl_hda_dsp snd_soc_intel_hda_dsp_common snd_hda_codec"

CDIR=/sys/bus/pci/devices/${CADDR}
# Device directory is a symlink 
[[ -L "${CDIR}" ]] && {
	echo "Removing card..."
	echo '1' > ${CDIR}/remove
}
echo "Unloading drivers..."
modprobe -ar ${DRIVERS}
echo "Loading new drivers..."
#modprobe -a ${DRIVERS}
echo "Rescanning PCI bus..."
echo '1' > /sys/bus/pci/rescan
journalctl -k -f

If I enable hda and hda_intel tracing via sysfs first and then run this, I see the same kernel output from journalctl but zero output from the trace endpoint:

root@valent:~/# cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 0/0   #P:8
#
#                                _-----=> irqs-off/BH-disabled
#                               / _----=> need-resched
#                              | / _---=> hardirq/softirq
#                              || / _--=> preempt-depth
#                              ||| / _-=> migrate-disable
#                              |||| /     delay
#           TASK-PID     CPU#  |||||  TIMESTAMP  FUNCTION
#              | |         |   |||||     |         |

I’m already using the following options in modprobe.d to get verbose logs from the modules themselves:

options snd_sof sof_debug=1
options snd_sof_intel_byt dyndbg=+p
options snd_sof_intel_bdw dyndbg=+p
options snd_sof_intel_ipc dyndbg=+p
options snd_sof_intel_hda_common dyndbg=+p
options snd_sof_intel_hda dyndbg=+p
options snd_sof dyndbg=+p
options snd_sof_pci dyndbg=+p
options snd_sof_acpi dyndbg=+p
options snd_sof_of dyndbg=+p
options snd_sof_nocodec dyndbg=+p
options sof-audio-pci-intel-tgl dyndbg=+p

options soundwire_bus dyndbg=+p
options soundwire_generic_allocation dyndbg=+p
options soundwire_cadence dyndbg=+p
options soundwire_intel_init dyndbg=+p
options soundwire_intel dyndbg=+p
options snd_soc_skl_hda_dsp dyndbg=+p
options snd_intel_dspcfg dyndbg=+p

journalctl output:

Jul 03 21:19:20 valent kernel: pci 0000:00:1f.3: Removing from iommu group 19
Jul 03 21:19:21 valent kernel: pci 0000:00:1f.3: [8086:a0c8] type 00 class 0x040380
Jul 03 21:19:21 valent kernel: pci 0000:00:1f.3: reg 0x10: [mem 0x4017004000-0x4017007fff 64bit]
Jul 03 21:19:21 valent kernel: pci 0000:00:1f.3: reg 0x20: [mem 0x4017100000-0x40171fffff 64bit]
Jul 03 21:19:21 valent kernel: pci 0000:00:1f.3: PME# supported from D3hot D3cold
Jul 03 21:19:21 valent kernel: pci 0000:00:1f.3: Adding to iommu group 19
Jul 03 21:19:22 valent kernel: pci 0000:00:1f.3: BAR 4: assigned [mem 0x4017100000-0x40171fffff 64bit]
Jul 03 21:19:22 valent kernel: pci 0000:00:1f.3: BAR 0: assigned [mem 0x4017004000-0x4017007fff 64bit]
Jul 03 21:19:22 valent kernel: snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040380
Jul 03 21:19:22 valent kernel: snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
Jul 03 21:19:23 valent kernel: snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000
Jul 03 21:19:24 valent kernel: snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x000f0000
Jul 03 21:19:25 valent kernel: snd_hda_intel 0000:00:1f.3: Codec #0 probe error; disabling it...
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input39
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input40
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input41
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input42
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=10 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input43
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=11 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input44
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=12 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input45
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=13 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input46
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=14 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input47
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=15 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input48
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=16 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input49
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=17 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input50

In an update to my previous statement, I have seen the card work a few (2 or 3) times in Linux - it is not consistent in any fashion except never works when booting the laptop from cold or restarting - it seems to start working randomly after sleeping or hibernating, which makes me think this is some sort of power / initialization / timing issue in the way the Tempo chip is started.

I’ve exhausted the suggestions from Framework Support at this point so pretty much at a loss unless we can work out a way to log HDA verbs and work out why the chip won’t start / be detected.

I’ve managed to use qemu to dump the init and HDA verbs from both Windows 10 (sound working) and Ubuntu 18.04 (sound not working) and the TL;DR is that this is something that fails very very early on in the codec initialisation process in Linux.

Windows:

CORBUBASE write of 0x1
CORBLBASE write of 0x2d6a7000
RIRBUBASE write of 0x1
RIRBLBASE write of 0x2d6a7800
CORBUBASE write of 0x1
CORBLBASE write of 0x2d6a7000
RIRBUBASE write of 0x1
RIRBLBASE write of 0x2d6a7800
CORBWP advance to 3, last WP 0
CORB[1] = 0xf0000 (caddr:0x0 nid:0x0 control:0xf00 param:0x0)
CORB[2] = 0xf0002 (caddr:0x0 nid:0x0 control:0xf00 param:0x2)
CORB[3] = 0xf0004 (caddr:0x0 nid:0x0 control:0xf00 param:0x4)
RIRBWP advance to 3, last WP 0
CORB caddr:0x0 nid:0x0 control:0xf00 param:0x0 response:0x111d7695 (ex 0x0)
CORB caddr:0x0 nid:0x0 control:0xf00 param:0x2 response:0x100101 (ex 0x0)
CORB caddr:0x0 nid:0x0 control:0xf00 param:0x4 response:0x10001 (ex 0x0)
CORBWP advance to 5, last WP 3
CORB[4] = 0x1f0001 (caddr:0x0 nid:0x1 control:0xf00 param:0x1)
CORB[5] = 0x1f0005 (caddr:0x0 nid:0x1 control:0xf00 param:0x5)
RIRBWP advance to 5, last WP 3

Linux:

CORBLBASE write of 0x1fe4a000
CORBUBASE write of 0x4
CORBWP advance to 0, last WP 0
RIRBLBASE write of 0x1fe4a800
RIRBUBASE write of 0x4
CORBWP advance to 1, last WP 0
CORB[1] = 0xf0000 (caddr:0x0 nid:0x0 control:0xf00 param:0x0)
RIRBWP advance to 8, last WP 0
CORB caddr:0x0 nid:0x0 control:0xf00 param:0x0 response:0xffffffff (ex 0x10)
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0xffffffff (ex 0x10)
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0xffffffff (ex 0x10)
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0xffffffff (ex 0x10)
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0xffffffff (ex 0x10)
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0xffffffff (ex 0x10)
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0xffffffff (ex 0x10)
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0xffffffff (ex 0x10)
RIRBWP advance to 15, last WP 8
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0xffffffff (ex 0x10)
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0xffffffff (ex 0x10)
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0xffffffff (ex 0x10)

These CORB caddr lines with all values set to 0 except the response (255) are the driver continually trying to probe the unresponsive codec - the decoded command:

Command Received for Node ID 0x0: AC_VERB_PARAMETERS with parameter: AC_PAR_VENDOR_ID
Command Received for Node ID 0x0: Unknown Command: 0x0 with parameter: AC_PAR_VENDOR_ID

The Windows code succeeds this command instantly on the first try and moves onto further probing:

Command Received for Node ID 0x0: AC_VERB_PARAMETERS with parameter: AC_PAR_VENDOR_ID
Command Received for Node ID 0x0: AC_VERB_PARAMETERS with parameter: AC_PAR_REV_ID
Command Received for Node ID 0x0: AC_VERB_PARAMETERS with parameter: AC_PAR_NODE_COUNT
Command Received for Node ID 0x1: AC_VERB_PARAMETERS with parameter: AC_PAR_SUBSYSTEM_ID
Command Received for Node ID 0x1: AC_VERB_PARAMETERS with parameter: AC_PAR_FUNCTION_TYPE
Command Received for Node ID 0x1: AC_VERB_GET_SUBSYSTEM_ID with parameter: AC_PAR_VENDOR_ID

I don’t know how these initialization steps differ as I don’t have anything to decode the commands being sent here but they’re clearly very different.

Edit to update: The code I was using to log writes / reads to the PCI device doesn’t take into account anything outside the HDA process (i.e. once the card appears to be initialised) - so these logs above are maybe not helpful to track down the actual issue. It should be possible to modify the patch to capture the correct info and convert it to a format that makes sense.

I’ve also noticed that it is possible to trigger the same ‘looping probe’ behaviour in Windows with the sound not working, so this isn’t solely a Linux issue but does appear to be very, very, very rare in Windows.

I have the exact same issue.

I got a replacement mainboard due to this issue (Piece of mainboard partially melted).
My old board works perfectly fine (audio wise) switching between old the and new board one has working audio ther other doesn’t.

@Kieran_Levin Does this suggest hardware issue?

I get all the same output from dmeg as other above do “no response from codec”
Also seeing constant CPU activity of 1-1.5% with the new board and generally higher power drain though I don’t know if that is related.

Try running watch -n1 -d cat /proc/interrupts and look for the line identifying snd_intel_hda:card0 on the right. For me it’s IRQ 16, and goes up by around 350 interrupts per second on CPU 6.

            CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7       
   1:          0          0      82338          0          0          0          0          0  IR-IO-APIC    1-edge      i8042
   8:          0          0          0          0          0          0          0          0  IR-IO-APIC    8-edge      rtc0
   9:          0     435474          0          0          0          0          0          0  IR-IO-APIC    9-fasteoi   acpi
  12:          0        280          0          0          0          0          0          0  IR-IO-APIC   12-edge      i8042
  14:          0          0          0          0     503446          0          0          0  IR-IO-APIC   14-fasteoi   INT34C5:00
  16:          0          0          0          0          0          0    7505306          0  IR-IO-APIC   16-fasteoi   intel_ish_ipc, i801_smbus, snd_hda_intel:card0
  27:          0          0          0          0          0          0          0          0  IR-IO-APIC   27-fasteoi   idma64.0, i2c_designware.0
  30:          0          0          0          0          0          0    9337572          0  IR-IO-APIC   30-fasteoi   idma64.2, i2c_designware.2
  40:          0          0          0          0          0         87          0          0  IR-IO-APIC   40-fasteoi   idma64.1, i2c_designware.1

See IRQ 191

           CPU0       CPU1	  CPU2       CPU3	CPU4	   CPU5       CPU6	 CPU7
   1:          0          0          0          0          0          0      51170          0  IR-IO-APIC    1-edge	 i8042
   8:          0          0          0          0          0          0          0          0  IR-IO-APIC    8-edge	 rtc0
   9:          0     224333          0          0          0          0          0          0  IR-IO-APIC    9-fasteoi   acpi
  14:          0     420947          0          0          0          0          0          0  IR-IO-APIC   14-fasteoi   INT34C5:00
  16:          0          0     134437          0          0          0          0          0  IR-IO-APIC   16-fasteoi   intel_ish_ipc, i801_smbus
  27:          0          0          0          0          0          0          0          0  IR-IO-APIC   27-fasteoi   i2c_designware.0, idma64.0
  30:          0          0          0   11426907          0          0          0          0  IR-IO-APIC   30-fasteoi   i2c_designware.2, idma64.2
  40:          0          0        178          0          0          0          0          0  IR-IO-APIC   40-fasteoi   i2c_designware.1, idma64.1
 120:          0          0          0          0          0          0          0          0  DMAR-MSI    4-edge      dmar4
 121:          0          0          0          0          0          0          0          0  DMAR-MSI    3-edge      dmar3
 122:          0          0          0          0          0          0          0          0  DMAR-MSI    2-edge      dmar2
 123:          0          0          0          0          0          0          0          0  DMAR-MSI    1-edge      dmar1
 124:          0          0          0          0          0          0          0          0  DMAR-MSI    0-edge      dmar0
 125:          0          0          0          0          0          0          0          0  DMAR-MSI    5-edge      dmar5
 126:          0          0          0          0          0          0          0          0  IR-PCI-MSI 98304-edge	  PCIe PME
 127:          0          0          0          0          0          0          0          0  IR-PCI-MSI 114688-edge	   PCIe PME, pciehp
 128:          0          0          0          0          0          0          0          0  IR-PCI-MSI 116736-edge	   PCIe PME, pciehp
 129:          0          0          0          0          0          0          0          0  IR-PCI-MSI 118784-edge	   PCIe PME, pciehp
 130:          0          0          0          0          0          0          0          0  IR-PCI-MSI 120832-edge	   PCIe PME, pciehp
 131:          0          0          0          0          0          0          0          0  IR-PCI-MSI 475136-edge	   PCIe PME
 132:          0          0          0          0          0          0          0          0  IR-PCI-MSI 212992-edge	   xhci_hcd
 133:          0          0          0          0          0	  22185          0          0  IR-PCI-MSI 327680-edge	   xhci_hcd
 134:          0         29          0          0          0          0          0          0  INT34C5:00  335  FRMW0001:00
 135:          0     420919          0          0          0          0          0          0  INT34C5:00    3  PIXA3854:00
 136:          0          0          0      26140          0          0          0          0  IR-PCI-MSI 524288-edge	   nvme0q0
 137:       9261          0          0          0          0          0          0          0  IR-PCI-MSI 524289-edge	   nvme0q1
 138:          0      10181          0          0          0          0          0          0  IR-PCI-MSI 524290-edge	   nvme0q2
 139:          0          0	 11277          0          0          0          0          0  IR-PCI-MSI 524291-edge	   nvme0q3
 140:          0          0          0      12821          0          0          0          0  IR-PCI-MSI 524292-edge	   nvme0q4
 141:          0          0          0          0	7116          0          0          0  IR-PCI-MSI 524293-edge	   nvme0q5
 142:          0          0          0          0          0	  10932          0          0  IR-PCI-MSI 524294-edge	   nvme0q6
 143:          0          0          0          0          0          0      10017          0  IR-PCI-MSI 524295-edge	   nvme0q7
 144:          0          0          0          0          0          0          0	11724  IR-PCI-MSI 524296-edge	   nvme0q8
 145:          0          0          0          0    2295110          0          0          0  IR-PCI-MSI 32768-edge	  i915
 146:          0          0          0          0          0        879          0          0  IR-PCI-MSI 217088-edge	   thunderbolt
 147:          0          0          0          0          0          0       1919          0  IR-PCI-MSI 217089-edge	   thunderbolt
 164:          0          0          0          0          0          0          0         35  IR-PCI-MSI 360448-edge	   mei_me
 165:          0        917          0          0          0          0          0          0  IR-PCI-MSI 219136-edge	   thunderbolt
 166:          0          0	  1989          0          0          0          0          0  IR-PCI-MSI 219137-edge	   thunderbolt
 181:          0          0          0      28556          0          0          0          0  IR-PCI-MSI 89128960-edge      iwlwifi:default_queue
 182:        389          0          0          0          0          0          0          0  IR-PCI-MSI 89128961-edge      iwlwifi:queue_1
 183:          0        281          0          0          0          0          0          0  IR-PCI-MSI 89128962-edge      iwlwifi:queue_2
 184:          0          0        498          0          0          0          0          0  IR-PCI-MSI 89128963-edge      iwlwifi:queue_3
 185:          0          0          0      12772          0          0          0          0  IR-PCI-MSI 89128964-edge      iwlwifi:queue_4
 186:          0          0          0          0        457          0          0          0  IR-PCI-MSI 89128965-edge      iwlwifi:queue_5
 187:          0          0          0          0          0	   1197          0          0  IR-PCI-MSI 89128966-edge      iwlwifi:queue_6
 188:          0          0          0          0          0          0         10          0  IR-PCI-MSI 89128967-edge      iwlwifi:queue_7
 189:          0          0          0          0          0          0          0        192  IR-PCI-MSI 89128968-edge      iwlwifi:queue_8
 190:          0          0          0          0          0         11          0          0  IR-PCI-MSI 89128969-edge      iwlwifi:exception
 191:          0          0          0          0  337469094          0          0          0  IR-PCI-MSI 514048-edge	   snd_hda_intel:card0
 NMI:          0          0          0          0          0          0          0          0   Non-maskable interrupts
 LOC:    2770023    1867902    1757985    2775119   11485590    4991902    1728517    1767911   Local timer interrupts
 SPU:          0          0          0          0          0          0          0          0   Spurious interrupts
 PMI:          0          0          0          0          0          0          0          0   Performance monitoring interrupts
 IWI:	   16527      23054	 24296      21378    1173622	  21975      22132	20748   IRQ work interrupts
 RTR:          0          0          0          0          0          0          0          0   APIC ICR read retries
 RES:	   43903      29856	 17097      36567     196868	  16662      16502	18392   Rescheduling interrupts
 CAL:     490275     252999     205334     192336     122022     158013     171050     175833   Function call interrupts
 TLB:	   65627      65136	 64376      64131      45775	  52753      58380	64106   TLB shootdowns

Sorry can you clarify what you mean here?

Yeah if you use the watch command from above, you should be able to see which core is handling interrupts from the sound card - in your case it looks like CPU5 (the only non zero field on IRQ191). It looks like you already have a ton of interrupts and it’s probably going up pretty fast.

Thanks. When I ran the command I looked briefly and I did not realise it was a cumulative count. For me it is going up at a rate of ~40/s.

Support have offered to replace my mainboard to try and fix this issue.

I would be surprised if that does not solve the issue. Here is to hoping all is well with the new board.