Looking at the output from `/proc/interrupts`...I see that for irq 16 there are two entries in the last column: ehci_hcd:usb1 and snd_hda_intel, and that there is another snd_hda_intel entry for irq 45. (See the rows indicated by the added asterisks.)
CPU0 CPU1 CPU2 CPU3
0: 53 0 0 0 IR-IO-APIC-edge timer
1: 3 0 0 0 IR-IO-APIC-edge i8042
8: 1 0 0 0 IR-IO-APIC-edge rtc0
9: 0 0 0 0 IR-IO-APIC-fasteoi acpi
12: 4 0 0 0 IR-IO-APIC-edge i8042
* 16: 29065 0 0 0 IR-IO-APIC-fasteoi ehci_hcd:usb1, snd_hda_intel
23: 37100 0 0 0 IR-IO-APIC-fasteoi ehci_hcd:usb2
40: 0 0 0 0 DMAR_MSI-edge dmar0
41: 0 0 0 0 DMAR_MSI-edge dmar1
42: 11425 0 0 0 IR-PCI-MSI-edge eth0
43: 53906 0 0 0 IR-PCI-MSI-edge ahci
44: 60 0 0 0 IR-PCI-MSI-edge xhci_hcd
* 45: 235 0 0 0 IR-PCI-MSI-edge snd_hda_intel
NMI: 102 60 51 95 Non-maskable interrupts
LOC: 67413 40257 57679 43949 Local timer interrupts
SPU: 0 0 0 0 Spurious interrupts
PMI: 102 60 51 95 Performance monitoring interrupts
IWI: 0 0 0 0 IRQ work interrupts
RES: 150105 180510 183193 156750 Rescheduling interrupts
CAL: 396 638 603 655 Function call interrupts
TLB: 2362 3182 3646 3919 TLB shootdowns
TRM: 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 Threshold APIC interrupts
MCE: 0 0 0 0 Machine check exceptions
MCP: 13 13 13 13 Machine check polls
ERR: 0
MIS: 0(FWIW, the system's sound is fine AFAICT.)I see a glimmer of hope in this (apparent?) redundancy. My thinking goes like this: (1) *maybe* the snd_hda_intel listed for interrupt 16 is what's responsible for the unhandled interrupt, and (2) *maybe* this snd_hda_intel can be disabled altogether, in light of the snd_hda_intel listed for interrupt 45? But I really don't know what I'm talking about. More importantly, even if these wishful guesses turn out to be correct, I don't know how to go about disabling the snd_hda_intel associated with irq 16.