Will a cheap graphics card help if replacing a HD3000 integrated graphics setup?

What are you using for the Firewire controller?
If it's not a good TI chipset Firewire controller, that's where you want to start.
Video is most likely not the culprit.
 
Also, check the system's DPC Latency using Latency Mon.
High DPC Latency will cause audible gliches.
Essentially, High DPC Latency equates to hiccups in data flow.
If your audio interface's buffer isn't filled in time, you'll hear audible glitches or (even worse) the transport will drop-out.

scottfa
Thanks for the reply. I have a Ti based fw to PCIe card and a Via onboard connection. Both are identical performance wise as far as I can tell. LatenceMon is fine, although I do get a number of hard page faults. This I attribute to the 7200 hard drive that has all my samples on it. It would be nice to get an SSD for the same drive but I can't afford that yet.
I just wonder if the HD3000 is too old for Windiws 10 nowadays.

I agree with Jim that video is probably not your culprit.  Likely something else in your setup.
 
But since I am running Win 10 and Intel HD 2500 (3rd gen) I did have a question similar to yours.  Intel published a disclaimer that the drivers for this gen of Intel HD graphics were supplied on an "as-is" basis and would not be certified by Microsoft.  Intel recommends moving to Windows 10 certified hardware.
 
So unless you were having actual graphics issues, or issues with the Intel drivers, I might say it is not worth $30-50 to get updated drivers.

mettelus
On cell so cannot see sigs, but agree that video is unlikely, but a buffer of 32 samples is. Is there a reason for a 32 sample buffer? Mine will do that but is overkill TBH. 96 samples is where I leave mine most times unless I need to bump it up for mixing. An extremely low buffer with any CPU-intensive (even mildly) VST isn't gonna cut it.

+1
 
I run with a buffer of 128. I could go down to 64, but haven't seen the need. I raise it to 1024 or 2048 for mixing.
 
A 32-sample buffer can put you in the CPU hell of "Hey!" "What?" interrupt processing with little time left for real work.

Well, I agree it is not much if a problem. A 32 sample buffer IS tiny.... I suspect that the hidden buffer is something to be considered. As a drummer of 40+ years I really need my TrapKat to have as low a latency as possible. Midi jitter, my midi interface(Motu) all play a part, but I can only control the buffer. So, as low as I can go. If a graphics card allows me a little more than that is good.
Anyway, I suspect that any graphics card won't help much. So far the comments back up this assumption.

That is quite a step up from a 30-50 dollar card😋. That will be next upgrade which will include a new case, motherboard, memory and CPU. But not for a while yet. Still crisis if the graphics card would help. Might just order one and find out.

A couple other things to consider since I am at a computer and can see the sig now.
 
1) With significant resources available, not only do programmers get sloppy, but the end user does too. Piling on CPU intensive items (VSTis, plugins, etc.) will chew up available resources quickly. Bear in mind that an audio track running through 18 FX requires each and every sample to be processed 18 times before it hits the buss. Freezing tracks of this type, or out-right baking them (bouncing to new tracks, then archiving the original), will let the CPU "breathe" and have more time to think while filling the buffer. Lowering the buffer to extremes in that situation makes it harder for the CPU to keep up, so being aware of what VSTs you are using is important. Trying to monitor a VST with look ahead can turn into a nightmare that even a smaller buffer won't solve.
 
2) I also have the i7-2600K and do not run mine overclocked. I have OC'd it a few times to check it, and in that situation the heat begins to throw faults from the CPU. Electrical components begin to suffer dielectric breakdown when exposed to excessive heat, and upping voltage just creates unnecessary heat at the CPU core. Even in fairly intensive projects, my CPU may get to 20%(ish), and the only things that will peg it are video rendering and encryption functions. Just to see this for yourself, PassMark has a benchmark utility that you can run and check different levels of OCing. Some levels of OCing are transparent (like 5% or so IIRC), but as that voltage goes above this, the faults start to come in, and each fault is going to find its way into the buffer at such a low buffer value - the CPU doesn't have time to calculate it a second time.
 
A couple things to consider is to back off the OCing in addition to upping the buffer to 96 or 128. After I saw your sig, I am not convinced that the OCing is not also contributing to what you are experiencing.

I missed the "32-sample ASIO buffer" size when first responding.
 
The problem is trying to run heavy loads at a 32-sample ASIO buffer size.  
With buffer sizes that low (.7ms at 44.1k), there's no margin for anything less than ideal circumstances.
 
Low/consistent DPC Latency (not just acceptable) is a must
 
BFD-3 is a wonderful drum plugin, but it's disk-streaming isn't the most efficient (compared to Kontakt).
If you've got a fast ride cymbal passage (with lots of ghost notes), polyphony can pile up fast.
With several disk-streaming sample libraries, you could easily exceed the capability of a 7200RPM "Samples" HD.
First thing I'd do is get BFD-3 library on SSD.
 
The MR816 is a nice audio interface, but it uses a large hidden safety-buffer.
With a smaller safety-buffer, you'd be able to (more comfortably) run it at a 64-sample ASIO buffer size.
For running heavy loads at a 32-sample ASIO buffer size, you'd do better with a PCIe audio interface (RME, MOTU, Lynx).
 
A recent make (well configured) machine would allow running heavier loads at a 32-sample ASIO buffer size.
 
 
I don't want to discourage the OP.  Effectively working at a 32-sample ASIO buffer size is demanding.
The solution isn't simple... as it involves every facet.
Any weak link throws a monkey-wrench
 
 
 

Mettelus:
Took your advice and monitored my CPU usage and dropped the OC to 4 GHZ. May drop it further but it is running with a peak temp of 54c and an average of 36c with the PassMark tests running.
Again, thanks

Just to wrap this up. After researching graphic cards I found little 2d improvenents. There may be something to gain by having a new card not take up system memory. Anyway, after really looking at the Task Manager I lowered my OC to 4 GHZ. In the bios I upped the internal graphics card frequency by a little.
In Bfd3 I increased the amount of RAM used. This helped a lot.
In Sonar using the "e" key to bypass all effects helped. Also using the pause key helped a little.
The end result is recording with a 32 sample buffer is better. In most cases I will try this out. I am very confident that a 64 sample buffer is rock steady. I have measured the RTL and at 64 sample buffer it is around 7.4 ms. A little high, but doable. Resplendence crashes using the 32 sample buffer unfortunately.
Anyway, thanks for all the great info.