No, this is a very real concern. And just because something might not be obvious up front doesn't mean it isn't a trainwreck waiting to happen in the midst of a session. There is a misunderstanding in thinking the whole IRQ issue has been solved by modern BIOS and Windows enhancements. Granted it is not quite the same type of concern as back in the day prior to W2K with IRQ conflicts, but it is still a very real concern. There are two levels of things going on, one is the actual interrupt layout at the physical board design layer, the other is the IRQ assignment. Even when using APIC, if things are lumped onto a single IRQ it seems that is still asking for trouble. Every device still has to service an inquiry to see who is supposed to service the interrupt. The more devices on the same IRQ, the more queries, and the higher likelihood if anybody does not behave properly & expeditiously there can be negative impacts to audio streams.
If somebody can explain how this is NOT a concern, please do so, I'm interested to learn why you feel what I've stated isn't valid.
Here is the Intel manual WRT the controller involved:
https://www.intel.com/content/www/us/en/io/i-o-controller-hub-7-datasheet.htmlFor more detail look at sections on pages 43, 62 and 140. I'm trying to decipher all this still so any help is appreciated. From what I can see so far, it does seem in APIC mode most single-trigger entities will end up on IntA and IRQ16. I can't believe there isn't some way to have at least ONE isolated card/bus. Every board used to have this ability back in the day. I'm also perplexed why open legacy IRQ's below 16 seem like they can't be used. Anyway, this is a bit over my head so maybe some of the techy guru's on the forum can figure this out...
Sonic