Thanks - I'll give it a shot.

I have a Gigabyte GA-P35-DS3R. F2 seems to reduce the DPC spike to around 20us but it does not allow an overclock. Newer revisions allow me to overclock to 3600. Anyone know if I could get both?

Paul , I overclock mine to 3.2 on the F3h BIOS without any problems?

If I get the 13b bios must I flash it with a floppy? (I don't have a floppy drive.)

You can install it from a download with the @BIOS Facility that comes on your Gigabyte Install Disc. I Was tired of plugging a Diskette drive into The board with every BIOS Update and Found that you can point @BIOS app to any Path and install the BIOS File from within windows like all motherboards these days.

ORIGINAL: foxwolfen


I will lay you dimes to dollars that the problem has nothing to do with the MB, but due to the M-Audio driver.

The repeating pattern shown in your first image is caused by the BIOS, not the drivers.

Woa Dang,

Don't be afraid to update the BIOS, just be careful to follow the directions carefully. I use a USB stick with the Q-Flash function in the BIOS. I've read that it is much safer than flashing the BIOS from within Windows. You don't need to use a floppy drive. All of the info you need should be in your motherboard manual.

ORIGINAL: Dan DAmico

ORIGINAL: foxwolfen


I will lay you dimes to dollars that the problem has nothing to do with the MB, but due to the M-Audio driver.

The repeating pattern shown in your first image is caused by the BIOS, not the drivers.

I was talking about the crash spike....

No, its caused by the system event scheduler, which if your machine is set to PNP aware, is controlled by the OS, and the OS is using the HAL to bypass the bios because BIOSes are slow! Why do you think XP has reached its end of life? Because the kernel timer can no longer keep up with the speed of the hardware. Change the polling interval and you will see the spikes drop. You guys are using a sledge hammer to kill a fly.

All these things are there for the finding if a person takes the time to look. Latency of this type is the least of our concerns. One fellow posted a topic recently with an article about where latency that effects us really occurs. And it isn't DPC.

Where in the chain does having these polling intervals actually effect anything? In this entire thread, and the others like it, not one person has demonstrated a genuine problem that you can actually tie to polling that is in the normal range as shown by the DPC application (IE around 2ms). There are 310 posts in this thread trying to fix a problem that does not actually effect anything. Its like everybody is OCD (obsessive compulsive). You all keep cleaning a spot that is already clean...

What I am trying to suggest is that there is no problem.

The worst that was seen (on machines not in an error state) was a difference of 1MS. This is not even detectable by a human being, and it is not cumulative. Its perfectly normal behavior (and having slightly longer latency in this area can actually be beneficial to overall system stability).

The spikes that are way out of whack, those that shoot up to the 25ms second range (or off the scale like the crashed application) are not due to polling. They are due to the system being in an error state. Of course the DPC application will show a huge spike... the app crashed and hung a driver. Does the application tell you what driver hung, does it tell you which device is not responding to the poll? Unless your DPC application is different than mine, the answer is "no".

WRT Gigabyte: unless they included a "we fixed the DPC spike problem" in their release notes for the bios, saying that Gigabyte has admitted a problem is purely conjecture. The segment of the market that would even care about this is so small as to be trivial. Gigabyte sells some 10 million motherboards a year (based on the 2006 annual report) - weigh that against a couple of hundred people with a DPC spike of 2ms... do you honestly think they care?. If it makes you feel better about your system, great. But, I will again lay dimes to dollars that its purely coincidental.

Cheers
Shad

LOL - Actually, thats what I feel about you and the other nonsense spewers here.

This is the part that is useful:

"What I am trying to suggest is that there is no problem."

Show me a real problem with the polling latency, and I will do just what you ask. Otherwise, take your own advice bub.

Cheers
Shad

So I am guessing that means you can not actually show me a real problem?

Why? I will tell you why. Because there is so much misinformation being tossed around this place. This is disservice to those members who come here looking for real solutions. There is a large amount of baseless snobbery about products and methods by people who clearly have no idea about what they are talking about. Wrong information about sound devices, video devices, operating systems and so on.

I will continue to provide correct information so that those people who want the right information are not mislead. Information based on verifiable facts, not conjecture or wishful thinking.

Cheers
Shad

ORIGINAL: foxwolfen


This is the part that is useful:

"What I am trying to suggest is that there is no problem."

Show me a real problem with the polling latency, and I will do just what you ask.

Check my posts in this thread where I show the results of the Sonar benchmark test. There is a definite improvement with the beta BIOS that corrects the DPC spiking. Nothing else was changed, just the BIOS. So it isn't Windows XP causing the problem.

Dewdman is right. If you haven't experienced the problem - good for you. Leave those of us that have experienced it alone so we can find a solution. It's not your problem to solve.

no, that is not what you did. You have attacked people for trying to eliminate the spiking in a way that you don't approve of. The reality is that some people have eliminated the spiking doing exactly the things you disprove. Some of them have reported perf gains. Whether or not its there is really non-issue. its a potential for perf gain and worth pursuing. now freaking go away dude and stop being a pest.

(roll eyes). Sick of this conversation. If I ignore you will you go away?

ORIGINAL: Dan DAmico

ORIGINAL: foxwolfen



And in what way does the benchmark reflect real world problems? Don't get me wrong, I enjoy making benchmarks scream too - but I do realize that those minor changes really have little impact on performance in the real world.

On my system, I was unable to use a 64 sample buffer at all with ASIO drivers with the DPC spiking. With the beta BIOS, I can. That is a real world performance difference. I am able to detect timing differences related to higher latencies.

Uh huh. Riiight.

Well then you're superhuman Dan. Most people are biologically incapable of detecting discrete differences in latency of about 25 MS or lower... this is the time it takes for a neurotransmitter to travel across the synaptic gap between neurons. For the most of us, two events that occur within that time (like a key press and the resulting sound) are perceived as one event. It takes about 300 milliseconds before your brain processes that information. This is 1st year Perceptual/Cognative Psych.

Maybe you can see why I am not overly concerned about a 2ms polling spike every 2 seconds or so (you guys act like these spikes are occurring on every clock cycle. Its not, its occurring every 6 billion or so). And, judging by my music, I am not seeing much problem there either. I can play just fine (other than my own lousy timing issues ). You can also now see why I think this is more to do with pride (that which I call bragging rights), than any real need.

Besides, I am still prepared to put money on the fact that the BIOS fixed something other than the DPC (like, perhaps, adjusting the PCI bus latency from 128 to 64 by default... which you could have done yourself in the bios setup screens (the common default it actually 64, but occasionally motherboard bioses are set higher to give peripherals like the sound card a longer time slice to process if the board is deemed "high perf - this can actually smooth overall system response). Polling spikes really have little to do with monitoring latency, as it is not related to this part in the manner you wish to ascribe.

Care to take me up on that bet?

Ok, guys, its me with the total loss of sound in BF2.

Thanks for your comments.

I had imagined all along that it was the M-Audio drivers since the BF2 application doesn't actually crash, I just lose all sound at the same instance as the latency checker reports the spike. While BF2 taxes the graphical components more than the DAW, I don't remember losing sound in FSX on this system, but I don't play that online. I wonder if the sudden massive spike might be related to my network connection, if a slight lag might make the game lose contact with the M-Audio drivers? The problem seems to occur less at night when there's perhaps less traffic.

Personally, I have no problems running lots and lots of tracks with VST's, no problem at all. I never just lose all sound running the DAW, and the latency pattern DOES NOT change at all whether I just browse etc (the top pic) or work in the DAW. So, really, it doesn't appear to be a problem with my work, - but as any semi-tweaker knows, if performance can be increased, heck, a topic looks interesting.
At the same time, it appears that a significant amount of people report that the BIOS update actually cures a problem with their sound, and this makes me quit keen on trying it out. I mean, can we agree that the (even the "unproblematic") spikes are unusual and undesired? It would be interesting to see screenshots of various mobos and a brief rundown on any audio problems encountered, although, perhaps not in this thread. We already heard of people with ASUS and Abit boards who also report this.

Thanks for the tip on flashing, I'll probably end up doing it.

Foxwolfen, I've just turned off my system event schedular and will give BF2 a go (yeah, tough troubleshooting:). But I'm not sure it'll be that easy, let's see.

ORIGINAL: Dan DAmico

ORIGINAL: foxwolfen



Uh huh. Riiight.

I've been trying to be patient with you, because I assume that most people who come to this forum are either seeking answers, or are providing assistance to those that are. But you are proving yourself to be on some sort of ego trip.

Listen carefully. No one is advocating that you or anyone else change your system if you are satified with your performance. This thread is trying to help people that are experiencing degraded system performance caused by DPC spikes. Gigabyte admits there is a problem and has released a BIOS that corrects the problem, whether you believe in it or not. It is not up to you to prove it doesn't exist or doesn't matter.

And if you cannot detect a 25ms latency, I don't know how you can record anything requiring tight timing.

Dan,

Actually... you listen carefully. Very very carefully. Now, I know you guys are very used to bullying the people you disagree with, but I am not so easily bullied.

"No one is advocating that you or anyone else change your system if you are satified (sic) with your performance." Horse pucky. That is exactly what you are doing.

I have read many people coming in and trashing a brand here based on nothing other than some mysterious spikes on some application that nobody has actually verified as being useful as a diagnostic tool. I am trying to be reasonable about a problem that one or two others who have some real hardware experience have also mentioned may not be a problem.

I mentioned more than once that we are not talking about monitoring latency, were talking about occasional brief spikes during system polling. This, at worst relates to noise and dropouts, not input monitoring latency, which is what this thread seems to lead people to believe. I have the spikes, and I run at 4-8 ms input monitoring latency. Therefore the DPC spikes are perhaps not the real culprit to your 64 sample buffer problem. This is what I have been talking about, over and over and over. So my main problem with this thread is the blurring of lines between two different types of events on a system, which is highly misleading.

I have put forth, three times now, a request that you show us where gigabyte admits this problem with DPC. Three times I have been ignored.

I asked if the release notes address the DPC issues. Do they verify that the bios had a problem with 2ms dpc spikes causing input monitoring latency problems (the 2ms "spikes" seem to be the common "problem" reported here - not the obvious anomalies where the spike are huge - I am not debating those, and I have said as much - nor am I debating that a new bios may have allowed you to get slightly lower latency out of your sound card)?. If they do, then please post the release notes and I will shutup and admit my mistake.

If they are not in the release notes, then you (guys) are asking me to simply take your word for it. This is hard to do. I am not really interested in going and tracking it down myself, but its looking like I will need to, just to prove a point, and that irritates the heck out of me. For what its worth, vendors give out beta's all the time, so the fact that they gave you one is no proof that they admit there is a problem with DPC causing input monitoring latency problems. The proof, as they say, is in the pudding; show me where it is officially written.

If this is an "ego trip", fine... believe what you want, but with repeated requests for verification of the claims put forth here, there has been no response, other than the usual Cakewalk forums "you suck for questioning us" kind of replies. And yes, I get pretty tired of those, and the people with 10 year old mentalities who do it.

Cheers
Shad

OK, lets cool it down to keep this thread valuable:

1) Latency in the DAW is obviously NOT the same as latency reported by DPC checker. Those are two different things.
2) It is clearly possible for some (including myself) to NOT feel any bad effects in the DAW despite a non-patched BIOS (I run at 2ms in FL8). Thus the latency reported by DPC checker does not necessarily entail a problem.
3) It appears that some people have done away with their problems with a BIOS update which ALSO affects the latency reported by the DPC checker. It would appear natural to assume that somewhere along the chain, something happened to some kind of data transfer.
4) Has Gigabyte support described to one of the receivers why the BIOS might help with stabilizing multitrack audio applications? If so, let's have a quote?