dasbin
10-24-2012, 12:31 PM
I've been battling, in a new system, some issues with IRQ sharing (can't move slots), specifically between the built-in graphics of an i3 and my audio cards, which all share IRQ16.
In searching high and low for answers, I came across a very interesting thread at Gearslutz: http://www.gearslutz.com/board/music-computers/440166-windows-7-irqs.html
I know a lot of you are still running XP, so this applies less to you, but I found the information intriguing and wanted to ask here about the potential accuracy of it. Specifically this:
Yet running the audio engine itself in realtime priority would indeed mask some of the other related issues if they're not attended to as well, and imo it would be best to have all bases covered: applications using modern WDDM compliant display routines (which has been necessary since Vista!) and not mixing incompatible modes (directdraw & GDI+ or Opengl for example) in addition to audio engines properly prioritized and aware of cpu core affiniity & what resources are available.) The general gist being that if you need to increase your application priority, or if sharing IRQ's with graphics is an issue, the fault doesn't lie in Windows but rather with the application potentially not following "WDDM compliant display routines." I admit to not have looked deeply into what exactly compliance is in this case, yet.
My understanding is that turning off Aero actually offloads graphics compositing onto the CPU, which, in theory, we don't really want. We want the GPU to do the work, and not have the CPU interrupt an audio thread to do graphics compositing. So theoretically, disabling Aero should actually make things worse... unless the display routine of SAC maybe isn't doing things that way Microsoft would like.
Yet, in my case, just to get a usuable Win7 system even at 2x128, I need to disable Aero, and run SAC at realtime priority... and I can't get to the lower buffer settings that I really want. I imagine being able to switch IRQ's would solve this, but that is impossible on newer systems (and I'm out of PCIe slots).
I am curious, therefore, if there is room for any potential performance improvement in the future (particularily for those using OS's newer than XP) by looking into this and changing the display routine to MS's new compliance standards.
This stuff is a bit above my head, but the impression I got is that if thread priority or IRQ sharing present any audio issues (as they do for me in SAC, in a big way), these are not the issue in themselves, but rather symptoms of some potential mismanagement within the application (which, admittedly, sounds like a common theme among audio software in general.)
Not casting any stones here, just curious as to potential future improvement. Could potentially save a lot of the headaches of future setups needing to go through an endless array of "tweaks" just to play nice with SAC. Wouldn't it be nice not to have to guide every new user through this results-not-guaranteed process for every new build.
In searching high and low for answers, I came across a very interesting thread at Gearslutz: http://www.gearslutz.com/board/music-computers/440166-windows-7-irqs.html
I know a lot of you are still running XP, so this applies less to you, but I found the information intriguing and wanted to ask here about the potential accuracy of it. Specifically this:
Yet running the audio engine itself in realtime priority would indeed mask some of the other related issues if they're not attended to as well, and imo it would be best to have all bases covered: applications using modern WDDM compliant display routines (which has been necessary since Vista!) and not mixing incompatible modes (directdraw & GDI+ or Opengl for example) in addition to audio engines properly prioritized and aware of cpu core affiniity & what resources are available.) The general gist being that if you need to increase your application priority, or if sharing IRQ's with graphics is an issue, the fault doesn't lie in Windows but rather with the application potentially not following "WDDM compliant display routines." I admit to not have looked deeply into what exactly compliance is in this case, yet.
My understanding is that turning off Aero actually offloads graphics compositing onto the CPU, which, in theory, we don't really want. We want the GPU to do the work, and not have the CPU interrupt an audio thread to do graphics compositing. So theoretically, disabling Aero should actually make things worse... unless the display routine of SAC maybe isn't doing things that way Microsoft would like.
Yet, in my case, just to get a usuable Win7 system even at 2x128, I need to disable Aero, and run SAC at realtime priority... and I can't get to the lower buffer settings that I really want. I imagine being able to switch IRQ's would solve this, but that is impossible on newer systems (and I'm out of PCIe slots).
I am curious, therefore, if there is room for any potential performance improvement in the future (particularily for those using OS's newer than XP) by looking into this and changing the display routine to MS's new compliance standards.
This stuff is a bit above my head, but the impression I got is that if thread priority or IRQ sharing present any audio issues (as they do for me in SAC, in a big way), these are not the issue in themselves, but rather symptoms of some potential mismanagement within the application (which, admittedly, sounds like a common theme among audio software in general.)
Not casting any stones here, just curious as to potential future improvement. Could potentially save a lot of the headaches of future setups needing to go through an endless array of "tweaks" just to play nice with SAC. Wouldn't it be nice not to have to guide every new user through this results-not-guaranteed process for every new build.