Windows 7 and IRQ's
dbowman
Thread Starter
#1
15th November 2009
Old 15th November 2009
  #1
Gear maniac
 
Joined: Apr 2008
Posts: 164

Thread Starter
Windows 7 and IRQ's

Spending this weekend installing hardware/software on my new i7 920 DAW running Windows 7 32-bit. After installing my PCI based RME AES-32 audio interface I checked out IRQ assignments in the System Information. Obviously, Windows 7 does some different things. I saw over 100 separate IRQ's listed. My AES-32 was one of 10 sharing IRQ 16 (including my video card).

In my old XP system I would disable everything I could and move my cards around (2 UAD's and the AES-32) so that each had a dedicated IRQ. After looking at Windows 7 assignments, there looks to be no way to dedicate IRQ's to even my interface let alone each UAD card.

Under Windows 7, are IRQ assignments critical anymore? Does the new OS handle IRQ's in a way that avoids conflicts that would cause audio issues?

Regards,

DB
#2
15th November 2009
Old 15th November 2009
  #2
Lives for gear
 
Joined: Nov 2007
Location: N.Y.
Posts: 1,309

I haven't tried W7 yet so I can't help you on those details, but I have noticed that ever since 2K/XP IRQ shsring seemed to be less of a problem if any at all. Are you having a problem with RME's AES performance?
#3
15th November 2009
Old 15th November 2009
  #3
Lives for gear
 
Timur Born's Avatar
 
Joined: Mar 2008
Posts: 1,605

Working IRQ sharing is as old as Windows XP, but back then some hardware wouldn't play nice with it. Nowadays it shouldn't cause any much trouble.

Anyway, only IRQs 0-15 are "physical" IRQs, anything higher than 16 is "virtual" and thus it doesn't really matter what numbers you see. It's still strange that Windows assigns all your hardware to a single number, but shouldn't bother you unless you experience problems.
#4
15th November 2009
Old 15th November 2009
  #4
Lives for gear
 
Timur Born's Avatar
 
Joined: Mar 2008
Posts: 1,605

If you want to know the "real" physical IRQ sharing then take a look into your mainboard's manual. There should be a table listing the physical IRQ lines and how they are allocated among onboard devices and PCI slots. The latter helps to find a slot that doesn't share too much with other devices.



In this example of my old mainboard you can see that "PCI slot 3" does not share it's IRQ line with any other device. Unfortunately that is only half the truth, because the lowest PCI slot usually shares it's IRQ line with the graphic-card slot (aka highest slot), and so it did on this board.

On the other hand "PCI slot 2" only shares its line with the second LAN controller, which usually isn't needed anyway. So this is the perfect slot for an audio interface once the LAN controller is disabled.

But even using "PCI slot 1" didn't cause any problems with audio interfaces at low latencies on neither Windows XP nor Vista. The resulting IRQ table looked like follows and there were no problems going down to lowest audiobuffer settings on neither the PCI based Audiophile 2496 nor FW based Fireface 400 used in this system.

dbowman
Thread Starter
#5
15th November 2009
Old 15th November 2009
  #5
Gear maniac
 
Joined: Apr 2008
Posts: 164

Thread Starter
Honestly, I don't recall every having issues with IRQ assignments, but then again in XP I always made an effort to do what I could to isolate them to my audio cards. I'm still getting this new machine up and running so I can't speak as to whether the 10 assignments to IRQ 16 has any ill affects. I do know historically that both RME and UAD have issued caveats about sharing IRQ's under XP so I've always heeded that advice. So I was a little more than taken aback when I saw this:

IRQ 16 NVIDIA GeForce 9500 GT OK
IRQ 16 Intel(R) 5520/X58 I/O Hub PCI Express Root Port 5 - 340C OK
IRQ 16 Intel(R) ICH10 Family PCI Express Root Port 1 - 3A40 OK
IRQ 16 Intel(R) 5520/5500/X58 I/O Hub PCI Express Root Port 7 - 340E OK
IRQ 16 RME HDSP AES-32 OK
IRQ 16 Intel(R) 5520/5500/X58 I/O Hub PCI Express Root Port 9 - 3410 OK
IRQ 16 Intel(R) ICH10 Family PCI Express Root Port 5 - 3A48 OK
IRQ 16 Intel(R) ICH10 Family USB Universal Host Controller - 3A37 OK
IRQ 16 Intel(R) 5520/5500/X58 I/O Hub PCI Express Root Port 1 - 3408 OK
IRQ 16 Intel(R) 5520/5500/X58 I/O Hub PCI Express Root Port 3 - 340A OK

And I still have a UAD-2 and a UAD-1 card to install.

I'm new to Windows 7 so hopefully, I won't see any issues. Still, the disparity of how these IRQ's are allotted between XP and 7 has me concerned.

Thanks for the responses,

DB
#6
15th November 2009
Old 15th November 2009
  #6
Lives for gear
 
Joined: Oct 2002
Location: Suffern, NY
Posts: 510

Wow, this thread is freaking me out a little bit.

I'm more of a Mac guy, so depend upon "expert" friends for my pc knowledge.


They've all told me that ever since XP, you no longer have to worry about IRQ sharing.
I guess they were wrong?

If I understand this correctly, you can't assign IRQ channels in the bios, but you can still play with the allocation by moving cards around physically?
#7
15th November 2009
Old 15th November 2009
  #7
Lives for gear
 
Joined: Oct 2002
Location: Suffern, NY
Posts: 510

Quote:
Originally Posted by Timur View Post
In this example of my old mainboard you can see that "PCI slot 3" does not share it's IRQ line with any other device. Unfortunately that is only half the truth, because the lowest PCI slot usually shares it's IRQ line with the graphic-card slot (aka highest slot), and so it did on this board.
Timur, I don't quite understand. Can you explain this further? You are talking about the built-in mobo graphics hardware? It' always slot 3, and doesn't show in the manual's chart? (that makes no sense to me)

Suppose you are using a separate graphics card? -OK to just disable the onboard driver?

-thanks
dbowman
Thread Starter
#8
15th November 2009
Old 15th November 2009
  #8
Gear maniac
 
Joined: Apr 2008
Posts: 164

Thread Starter
Quote:
Originally Posted by speerchucker View Post
Wow, this thread is freaking me out a little bit.

I'm more of a Mac guy, so depend upon "expert" friends for my pc knowledge.


They've all told me that ever since XP, you no longer have to worry about IRQ sharing.
I guess they were wrong?

If I understand this correctly, you can't assign IRQ channels in the bios, but you can still play with the allocation by moving cards around physically?
Yep. At least with XP, it was typical of audio card manufacturers to address issues by instructing users to disable various ports in the BIOS and physically move cards around to try to isolate IRQ assignments.

On the other hand, there are many who have never paid any attention to IRQ assignments and have never encountered issues.

I always just assumed that freeing up IRQ resources for my audio devices had to be a good thing. At least that's what I inferred from speaking with manufacturers and people who have resolved one issue or another by switching the physical location of their cards.

On the other hand, I would be glad to be completely wrong about the issue.

Regards,

DB
#9
15th November 2009
Old 15th November 2009
  #9
Lives for gear
 
Timur Born's Avatar
 
Joined: Mar 2008
Posts: 1,605

Quote:
Originally Posted by speerchucker View Post
Timur, I don't quite understand. Can you explain this further? You are talking about the built-in mobo graphics hardware? It' always slot 3, and doesn't show in the manual's chart? (that makes no sense to me)

Suppose you are using a separate graphics card? -OK to just disable the onboard driver?

-thanks
That list doesn't include the PCI-Express slots and that's where the separate graphic-card plugs in. Also on many board the lowest slot shares a physical IRQ line with the slot that usually the graphic-card is inserted to (also in AGP systems).

You need to make a distinction between IRQ numbers and IRQ lines. IRQ lines are really that: physical conductor paths on the board (as you can see only 4 of them exists on my old board according to that list). Hardware running on the same IRQ line often gets assigned the same IRQ number though, but not always.

IRQ number 0-15 are IRQs assigned to devices by BIOS. Most of these are fixed, only 3-8 (2/9 are special) and 10-12 are assignable to add-on hardware. Sharing these IRQs can cause problems with some hardware, but normally shouldn't.

This is the priority order of IRQ (highest priorities first) which can also be found on the list on the above post ("Priority" coloum). This means that IRQ with higher priority are handled before IRQ of lower priority if two devices invoke an interrupt at the same time!

IRQ 0 - 2
IRQ 8 - 15
IRQ 3 - 7

As you may notice IRQ 10 has a higher priority than most other devices (only superseeded by the System Timer and Keyboard Controller). You may also want to use a PS/2 keyboard instead of an USB one when playing your DAW/instrument via computer-keyboard, because it will use IRQ 1 instead of the lower priority IRQ of the USB controller then.

IRQs 16 -23 are handled by Windows via ACPI which usually uses IRQ 9 itself. I do not know if these use the priority of IRQ 9, a priority lower than 15 but higher than 3, or a priority lower than everything else. Your only way to handle these manually is to turn off ACPI in Windows, so it doesn't matter that much anyway. Turning off ACPI will result in losing IRQ 16-23, which might lead to more problems with shared IRQs, but might also lead to less problems (because in this irq-sharing is not handled virtually by Windows, but physically). If you want to know which of these virtual IRQs share a physical IRQ have a look at the boot-screen of your desktop PC right before Windows boots (notebooks usually don't list IRQs there). If it's too fast for you use the PAUSE key on your keyboard.
#10
15th November 2009
Old 15th November 2009
  #10
Lives for gear
 
B-San's Avatar
 
Joined: Oct 2007
Posts: 529

Interesting thread gentlemen!!
#11
14th February 2010
Old 14th February 2010
  #11
Gear Head
 
bamm's Avatar
 
Joined: Jul 2007
Posts: 49

Sorry to dig up an old thread, but I may have some useful information concerning IRQ's in W7. I've been getting BSOD randomly over the past several weeks and it seemed to be related to audio. I'm using an RME FF800. I saw timur's posts on the RME forum and saw that you are in the middle of a troubleshooting diagnostic of your own...very impreessed with your pc knowledge timur...way over my head.

Anyway, I also have a number of IRQ's sharing, IRQ 19 in this case where my FireWire port resides. This includes USB "ports". This is interesting since the BSOD's were usually associated with the clicking of the mouse on audio apps (WMP, embeded audio, Cubase 5, etc). The BSOD's usually implied that a device did not "report" fast enough including irql less than or equal to zero, etc.

It seems that it is possible to set an IRQ priority in the registry. I will post the link with the instructions if anyone is interested. After I set 19 to priority 1 and restarted, I cranked on the audio apps pretty hard and then went into cubase and mixed an entire song. Very solid so far and the asio meter which was previously jumping a lot calmed down greatly.

One last thing...Windows Aero was killing my asio performance even though "sounds" are turned off. I recommend killing it in W7. Hope this helpful.

Peace
#12
14th February 2010
Old 14th February 2010
  #12
Lives for gear
 
valis's Avatar
 
Joined: Apr 2006
Location: Northwest USA
Posts: 4,691

If Aero is killing performance I recommend checking both the resource sharing with your graphics card's slot/IRQ and to see if you're using a card that is DX10 capable & has WDM 1.1 whql drivers... Win7 made significant improvements in the compositing engine used in Aero so now the GDI/GDI+ legacy path is no longer cpu bound (as it was in Vista) but gets composited on the card as well. The WDDM 1.0 > 1.1 move reduced 2d performance a bit to gain back a fair amount of ram overhead that WDDM 1.0/Vista had.

Unfortunately if you're having resource sharing issues, disabling aero 'seems' to fix it as the IRQ sharing is less of a problem, but you push all compositing back on the CPU.

Also fwiw, all of my Xeon machines have more than 4 addressing lines (due to typically having PCI-X & PCI bus lines in addition to more PCIe slots) and so IRQ sharing has been much less of an issue for me from the i860 (first P4 Xeons) on up...
#13
14th February 2010
Old 14th February 2010
  #13
Lives for gear
 
Joined: Mar 2005
Location: Cypress, CA
Posts: 508

Bamm, I notice you are using the ff800, have you already switched your firewire driver to the legacy driver? I assume you probably have, I just wanted to mention it in case you haven't because I know a ton of people have had to switch to the legacy firewire driver to get their firewire devices to work properly.
#14
15th February 2010
Old 15th February 2010
  #14
Lives for gear
 
Timur Born's Avatar
 
Joined: Mar 2008
Posts: 1,605

I would be interested in the link to the priority registry hacks for IRQs. And thanks for the flowers!

Concerning Aero: The main reason why it leads to performance problems with audio applications is because of the applications, it's their fault!

That is because most audio applications still use the highest non-realtime priority 15 which since Vista is also used by Aero. I only know Samplitude and Sonar to enable Realtime priorities for the audio and Midi threads. Samplitude offers an option to turn on priority 31 (highest realtime priority) and Sonar offers MMCSS (80-90% of the time on priority 26).

Other audio apps can often manually be set to "Realtime" priority via Task-Manager, but some cannot (Reaper can, but turns back to its own priorities with many of its functions once used, Cubase might not be possible at all, Live is possible). To be able do to switch a process to "Realtime" you either need to start Task-Manager "as Administrator" or turn off UAC.

Whether GDI is accellerated or not should not matter much with proper priority managment except for the GUI becoming more sluggish once audio load takes over (audio priority should supersede GUI priority). And many people on XP already experienced that sometimes turning *down* accelleration of GUI/GDI functions can even help performance (CPU load/priorities are better controllable than what the graphic-driver does on its own).

On Vista/W7 there are no options and controls for GDI accelleration anymore and it turns out to be quite a problem with *modern* graphic-cards. There is an article on Tomshardware on how current high profile (expensive) ATI cards draw 2D functions slower than what we got used. Fortunately most of our audio apps use bitmap based graphics (knobs are pictures) and not vectors (circles and lines). On the other hand all of those apps would benefit from OpenGL hardware-accellerated 3D vector drawing (especially by making the GUI fully scalable).

Current GUI technology still is far away from full 3D vector graphics, but there are already quite successful and stunning 2D bitmap layered on accellerated (and scalable) 3D OpenGL solutions. Scaling bitmap still leaves alot to be desired, but if you have a look at Expose and the likes you get a picture of what is possible.
#15
15th February 2010
Old 15th February 2010
  #15
Lives for gear
 
valis's Avatar
 
Joined: Apr 2006
Location: Northwest USA
Posts: 4,691

This is true.

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.)
#16
15th February 2010
Old 15th February 2010
  #16
Lives for gear
 
Timur Born's Avatar
 
Joined: Mar 2008
Posts: 1,605

Ableton Live is one good example of how GUI programming and improper priorization can mess with audio performance. For some reasons Live's GUI drawing often supersedes audio computing even though the thead priorities seem to be ok. One pronounced problem is moving the mouse over track-clips in Arrangement View. Turning Live to "Realtime" fixes the problems instantly.

The first 9 or 10 versions of Live 7 were unusable on Vista if you turned Aero *off* (Ableton refused to even acknowledge any problem). Whatever GUI drawing routines were used they caused such high CPU load and havoc behavior that you could not even playback a single audio clip without dropouts when using small audio buffers. Turning on Aero instantly fixed the CPU load issue because those GUI drawing routines were obviously handled by Aero/DWM/GPU then. So things are seemingly a bit more complicated.

Then Ableton changed something (without telling anyone about the issue or the fix) and now it doesn't matter much whether you are using Aero or not, the CPU load stays the same. The main problem remains with priorities now.

One thing I learned about Aero is that the whole off-screen composition thing of summing all single applications' output, doing some optimization and putting it out all at once not only can save CPU load but also fix some plugin drawing issues. Desktop composition is kind of a filter, an endpoint for all GUI output that predigests everything to uniform pieces before turning it over to the graphic-card driver.
#17
21st February 2010
Old 21st February 2010
  #17
Gear Head
 
bamm's Avatar
 
Joined: Jul 2007
Posts: 49

Appologies...been away. Here is the link for the IRQ priority mod. It seems that one could actually list new entires for all of their IRQ addresses and then assign them priority ranks. I just chose to set IRQ 19 to a "1" albeit probably compensating for other problems. Results have been good so far however.

How to configure interrupt request (IRQ) priorities in Windows Vista and 7

Thanks for the heads-up on the FF800 legacy drivers...yes I made that change recently also with seemingly good results. I was led to believe that the new RME drivers were to make this unecessary but I have my doubts.

Peace.
#18
21st February 2010
Old 21st February 2010
  #18
Gear nut
 
Joined: Jan 2009
Location: Kent - England
Posts: 104

The whole point of upgrading to W7 is have the 64bit platform surely!!
#19
8th November 2010
Old 8th November 2010
  #19
Gear interested
 
richtrix's Avatar
 
Joined: May 2006
Location: Georgia
Posts: 20

Windows 7 dropouts

Hi everyone,

tried some of the stuff on this thread to prevent dropouts and lost buffers whenever I scrolled my mixer window. None of the things tried here worked but after doing some basic research and learning about win 7 features I disable a lot of the display features, namely animated min/max of windows and other animations. Also getting rid of transparency seemed to help the most. All this can be found in C panel/system/advanced setting/performance.
I was able to keep some of the things checked like keeping a stylized taskbar etc. But just getting rid of anims and transparency got me rock solid. Use xp for years and before that 98 (98 lite actually, great OS) with various DAWs and feel stupid for not looking at the windows eye candy first instead of looking at IRQ conflicts. Here a pretty standard win 7 optimization page: Optimising your PC for audio on Windows 7 .: Focusrite Answerbase

Sincerely,
rich
#20
8th November 2010
Old 8th November 2010
  #20
Lives for gear
 
valis's Avatar
 
Joined: Apr 2006
Location: Northwest USA
Posts: 4,691

So the question is what app you were using and having problems in? Sounds like more Aero related issues, or an underpowered GPU to begin with perhaps?
#21
8th March 2011
Old 8th March 2011
  #21
Gear nut
 
Joined: Dec 2010
Posts: 82

I still don't understand how the IRQ and device prioritization works in current computers and Windows 7.

Look at the list of one of my machines:


M-AUDIO - Knowledge Base


1. How can you see and identify in a current computer the priority order of devices, which device has higher priority? I suppose traditionally the priority order was 0,1,2,8,9,10,11,12,13,14,15,3,4,5,6,7. But I see that most of my devices are assigned to interrupts that are not in this list (16-23, and -2!)

2. is even nowadays so that with ACPI and APIC, first audio interface throws IRQ and processor starts processing and moving data from memory to audio buffer, and if there becomes a higher priority interrupt in the middle (e.g. WLAN), processor will interrupt the data moving and start serving the higher priority device..?

3. Is there any other way to change device priorities than switching to different PCI slots or USB ports..?, a friend claimed that prioritization is done in software and I read from somewhere that you can set a priority in windows registry (e.g. IRQ13, priority 1, IRQ10, priority 2, etc..), but it seems too dangerous to me. Any safer way to do this?


4. What is the most desirable way to prioritize the following devices in a DAW: Audio Interface, Hard Disk, MIDI-controller, Display Adapter, ATA channels, SATA controller?


I really would want to know that e.g. if there comes IRQ 10, 16, 19 and -2 all at the same time, which one is processed first and which one last..?

Still one thing, is it better to choose plug&play OS Yes or No from BIOS in a dAW?
#22
10th March 2011
Old 10th March 2011
  #22
Lives for gear
 
Joined: Oct 2002
Location: Suffern, NY
Posts: 510

Golem, this is a good question.

I know you can set thread-priority (software, obviously) with a little app called "Prio," and also most (all?) DAWS grab thread -priority automatically, but I dunno about audio cards, and I have NO idea if this overrides IRQ issues. - Probably not.

I'm keeping an eye on this thread. I think that this, and the advanced power settings (core parking, etc) are two vastly overlooked issues that should concern current DAW users.
#23
10th March 2011
Old 10th March 2011
  #23
Lives for gear
 
Joined: Oct 2002
Location: Suffern, NY
Posts: 510

Quote:
Originally Posted by Timur View Post
You may also want to use a PS/2 keyboard instead of an USB one when playing your DAW/instrument via computer-keyboard, because it will use IRQ 1 instead of the lower priority IRQ of the USB controller then.
Interesting footnote to this:

For years, I have been battling distortion due to lost communication with my audio card. It's much more controlled now, but was horrible on my last system. On that system, I noticed that any time I used my trackball, I would get a significant DPC spike.

This doesn't happen on my new system, but I wonder if, on the old, it would have helped my problem to switch to a PS/2 trackball?

I assume that if one did need to do this, it would be fine to simply use one of those little USB-to-PS/2 adapters?
dbowman
Thread Starter
#24
11th March 2011
Old 11th March 2011
  #24
Gear maniac
 
Joined: Apr 2008
Posts: 164

Thread Starter
After starting this thread nearly a year and a half ago, running a PCI RME AES-32 interface, 2 PCIe UAD-2 cards, USB mouse and keyboard, MIDI communication with an external synth via USB, 2 USB external drives, a Tranzport connection via USB, and using Reaper as my DAW, I've had zero issues...not even a hint at one.

At least for me, fortunately, my initial concern about PCI assignments turned out to be no issue at all. W7 on my i7 920 has been rock solid and quite an improvement over all the tweaks and fixes required to get XP up to snuff. Nice to concern myself with making music and not wondering what the heck is going on with DAW.

Regards,

DB
#25
20th April 2011
Old 20th April 2011
  #25
Gear interested
 
Joined: Apr 2011
Posts: 1

Windows 7 & IRQ's...... !!!

Hi,

About a year or so ago I spent a whole bunch of my hard earned cash on what was supposed to be the mothership of all audio machines - in a ditch effort to finally have a DAW that would run pretty much anything without blinking an eyelid and hopefully totally glitch-free.....

$8000 australian dollars and much swearing and stressful months later and I have a pretty serious audio machine... but still having problems with glitchy audio AAAARRRRRHHHH !!!!

My machine is a Dual-quadcore Xeon machine (2 x E5430's @ 2.66Ghz) running on an intel workstation board -( s5000xvn)
4 gig of fully buffered ECC ram,
2 x 15k-rpm Seagate SAS hard-drives running on an adaptec Pci-x SAS controller,
Firewire 800 card with texas instruments chipset,
Nvidia Quadro FX 370 dual head video card,
Windows 7 ultimate 64bit
RME Fireface 800.

the machine runs fine with everything else except intermittant drop-outs and "glitchy" audio which is driving me insane... I just want to be able to focus on producing music and not have to worry about this crap !!!

anyway....
from the research I have done I have found out the following things...

apparently the video card I have is crap - this is evident in windows 7's performance rating which for my graphics card has a rating of only 3.4, according to the service tech at my local RME distributor - Audio programs can still be quite graphics processing intensive - especially on redraws for waveforms etc.... ( I never knew this )
I am happy to upgrade the graphics card, but thats not the only thing causing my audio problems....

it appears that my graphics card, my firewire card and my SAS controller are ALL sharing the same IRQ (16) ... there is also a whole bunch of other stuff sharing this IRQ as well which appears to somehow be related to the PCI bus itself....

Ok so what i can deduce from this is that my audio card ( which runs on firewire) is fighting for bandwidth on the PCI bus with my Hard-drive controller and also my graphics card.... !! I still don't understand how this has happened.... whats more astonishing is that it also appears that I am somehow seemingly unable to change my IRQ settings in either windows 7 (normally in the device manager) or in my BIOS....

I am seriously at a loss as to how I can sort out this fairly simple problem... there has to be a simple way for me to be able to assign these devices with their own interrupt.... ? can I do this by editing the windows registry ? or is there a Patch or Tool for windows 7 that will let me change the IRQ settings in windows 7 ? - note - I can't seem to change from automatic setting to manual - the checkbox in the resources tab is grayed out ....

PLEASE HELP ME (before I give up or blow a fuse !!! )

your help and advice is very much appreciated....

:-)
#26
20th April 2011
Old 20th April 2011
  #26
Gear maniac
 
oweng's Avatar
 
Joined: Mar 2011
Location: vancouver

none

#27
20th April 2011
Old 20th April 2011
  #27
Lives for gear
 
Joined: Oct 2002
Location: Suffern, NY
Posts: 510

I feel your pain.

-But everything you need to know is already in this thread. Some quick points:

1: In Win7 you can't re-assign IRQ slots with software. You must physically move them around. You should be able to find charts in your mobo manual that show both the "Standard Interrupt assignments" and the IRQ Assignments. (see Timur's posts, above)

- By cross-referencing, you will find the least used slot. Put you audio card there.

Another thing that might help: Get & install the app "Prio." (see my post, above) Assign first priority to the audio card, and second to your DAW.
----------

Also get an app that checks for DPC latency & spikes. (DPC Latency Checker and/or DPC spike checker) If you have spikes or an avg reading over, say 100, start looking into how to turn off various processes. Start with any wireless stuff.

Try a different graphics card, as some are known to cause spikes.

Last: See if there's a newer BIOS for your mobo. Some versions will can very spike-prone, esp in a server mobo where the manufacturer is rarely concerned about this issue.

If you do all this and still have high DPC latency, you are screwed. Some mobos & chipsets just stink for audio.

Good luck.
#28
20th April 2011
Old 20th April 2011
  #28
Lives for gear
 
Timur Born's Avatar
 
Joined: Mar 2008
Posts: 1,605

Quite likely the Nvidia graphic-card may be a culprit in your system, but not because it lacks processing/drawing powers, but rather because it driver misbehaves.

Run DPC Latency Checker: DPC Latency Checker

Change the Nvidia driver to Microsoft's "Standard VGA driver" via Device-Manager -> Update drivers - > Choose manually -> Choose from list.

Report back.
restpause
#29
20th April 2011
Old 20th April 2011
  #29
restpause
Guest
 
Posts: n/a

I'm not really sure, but isn't error correcting RAM slower? If so, is it helpful to disable the error correction in the BIOS or will the RAM fail if you do that?

I've never used error correcting RAM and it never seems necessary. Isn't that just for servers?
#30
21st April 2011
Old 21st April 2011
  #30
Lives for gear
 
Joined: Oct 2002
Location: Suffern, NY
Posts: 510

Yes, server ram is slower than desktop ram.

I asked about that once, and the general consensus is that it's a pretty minor factor, considering how fast all current ram is in general.

It probably does slow down a DAW a tiny bit, but I doubt it's the main cause of the OP's problem.
New Reply Submit Thread to Facebook Facebook  Submit Thread to Twitter Twitter  Submit Thread to LinkedIn LinkedIn  Submit Thread to Google+ Google+ 
 
Thread Tools
Search this Thread
Search this Thread:

Advanced Search
Similar Threads
Thread
Thread Starter / Forum
Replies
ttnash / Music Computers
4
foolsfortune / Music Computers
2
lukejs / Music Computers
2

Forum Jump
 
Register FAQ Search Today's Posts Mark Forums Read

SEO by vBSEO ©2011, Crawlability, Inc.