In the past I have seen that too, but quite a while ago. I remember it happened when changing buffer sizes under very heavy load.

same here with Cubase 7.52 and Wavelab 8.51 on 2700K with 32GB DDR2000

can only play 256. 128 will start to jitter and indeed get the card in a state it won't recover from, 64/32 are impossible.

bump

--mobo: asus p9x79
--hdsp not in a pcie slot; it's a pci version, and occupies the sole such port on the mobo
--c-state off
--speedstep off

--power profile: high performance

--latencymon: reporting system is suitable for handling realtime audio

Interesting, too bad that I don't have a new system yet, still waiting for the new X99 chipset.
Makes me curious to investigate on this topic.

A few tips from my side, as I had a bad board and needed to measure and fine tune like hell ~2-3y ago.

Things like i.e. changing the clock speed needs time to align on the new cpu frequency, so turning off speedstep and getting a fix CPU frequency was up to now always one of many little things to optimize kernel latency down to 1-2 µs. And I personally assume this is a generic thing that can't be solved so easily.

Especially C-States brought on my BIOS / Board combination (P55 Chipset) + ~60-80 µs more kernel latency on an idle system. So I am curious what will happen on my future system.

Maybe one tip in regards to LatencyMon measuring. It also heavily depends whether you measure with Windows 7 or Windows 8. And also it depends on the HW, whether you measure on a real Desktop PC or on an energy optimized Laptop, there you can expect higher values. The values I mention in this thread are related to Desktop PC (i7 860 with MSI P55 GD65 - evil mainboard - and the better successor P55A GD65).

On windows 7 the accuracy appears to be more fine granular, as you can measure the kernel timer latency in µs. Sane values are on a i7 860 in the range of approx 1-10µs. Most values shall be 2-3 with some spikes at about 12. Of course some more if maybe a job is being started in the background.
The best LatencyMon version appears to me v4.02 as this was the latest which had the focus on Windows 7.

On windows 8 Windows changed something which forced LatencyMon to do a different measuring which appears to me one level higher, maybe on process scheduler level. You recognize it as the values are now in the range of 200µs and the parameters are named differently. I personally like the higher accuracy on Windows 7 more.
And there is another issue. The new version of LatencyMon (I think it was v6.0 when I tested) could be configured, when being used on a Windows 7 system, to do the old measuring of kernel timer latency, BUT THEN you got strange (too high) results.

So IMHO the measuring of system tuning for Audio works best on Windows 7 using LatencyMon v4.02. Then you need to observe on an idle system how low the kernel time can go and in what range the values usually are.

When I had a bad mainboard (P55-GD65) the values were on an untuned system in the range of 200-300µs. With peaks because of spawning system processes and what not .. With decent tuning it went down to 70µs. Especially Cubase (v6 at that time) did a good job, as enabling "mode for optimized audio performance" arranged some things in the power profile, that I reached even 65µs.

Then surprise surprise during vacation on an very old holiday PC with much older AMD CPU I got on this "little system" values like 1-2µs kernel timer latency.

At the end of the day I bought and update of that board with little re-design "P55A GD65" it was called and all my problems went away.

You need to let LatencyMon run for lets say at least 10-30 minutes to see, to get a feeling whether there are some background jobs being started ... There are some jobs which you can disable in Windows Task Scheduler.

Other things to check are i.e. drivers. An oldver version of Logitech setpoint software raised the DPCs .. in other words blocked CPU for too long, things like this you can also observe using LatencyMon. For 2y I used then the standard Microsoft driver which was much better in that regards. Now with the Logitech GD400 and newer drivers this issue didn't pop up again. I mention this only as there can be several reasons that a system is not in ideal shape.

Maybe your measurement is at the edge and with a little system load more you run into problems.

I remember that the 200-300µs kernel latency didn't trigger LatencyMon to yell that the system is not capable of audio streaming. It were some peaks that went over 800µs that happened within 10-30 seconds, when I started my investigations.

So .. if your system is maybe running stable at 200-300µs kernel timer latency and without spikes then you think all is ok, but your system is IMHO still in a state, where I would say, something is still wrong and should be much better, as you have then a factor 200-300x higher latency compared to whats should be possible.

Mainboard + BIOS settings, Windows Drivers and Windows tuning have a very big impact on the results.
But with a bogus board you can tune like hell but you won't reach values down to 1-2µs .. can happen.

All this need time and patience and everything starts on a freshly installed windows where you start to measure the latency after every driver installation and then on a minumum system with only basic drivers installed you 1st look, whats possible by fine tuning the BIOS. If you get good results there, then you continue to install firewall, more software etc but measure after every software installation. And of course you need to test your Audio Card how it reacts .. So you need a player and then also make tests how far the ASIO buffer may go down ... This you need to test also at the beginning when playing with BIOS settings ... Takes much time, but then you really know your system well.