yummay

about M series workstation lap

 
Darn! Looks that i'm in big trouble right now... I just hope the STUDIO 17 form Dell are made differently than the M series laptop...
 
I hope that i'll be able to sort this out...

And also...it's not like unusable DPC...just higher than I'd like to see and unstable. Like 150-450us and anywhere in between.

Slightly OT is there a good site for Win 7 tweaks to the OS?

I am getting pops occasionally when I record and Sonar/Window also freezes completely sometimes.    

I feel like it can be traced to the MOTU 424/2408 x64 drivers but can't prove it....especially on the freezes.   The pops I have no idea why....     

Anybody have the Motu and care to share their setting?   I bumped the ASIO buffer up to 256 to see if it helps...Also use the Wave RT box checked no?

OK... I'm really trying to gather my thoughts here, as I feel I have very little time to adress a very complex issue...

My DPC results were around 300us, but I had peaks up to 866us... very high !! How can we reach values high like those and still see very little CPU load on the ressources meters?? anyway... Looks like I found one cause of my problems here. (But I do not know yet what is causing these spikes...)

Also, I have found numerous threads on DELL's forum regarding the DPC issue with the STUDIO 1735 and later laptops (Mine is a 1747...)

http://en.community.dell.com/forums/t/19279703.aspx?PageIndex=1

And one thread on NI's website that looks... promising...

http://www.native-instruments.com/forum/showthread.php?t=75067

Hope these will help.

Ah, er.

I'd love to have the power to make this a sticky.

DPC latency measures the time it takes for a Deferred Procedure Call request to be actually honoured, from the time it was queued. The DPC mechanism exists to allow device drivers to schedule a relatively time-consuming operation to occur outside of a critical section in the driver code, thus allowing drivers to politely co-exist with each other. DPC requests can then be dequeued outside of these critical sections. Typically, a critical section involves code which has been called in response to an interrupt from a hardware device. This code should do whatever it has to do AS QUICKLY AS POSSIBLE and then GET THE HECK OUT OF THERE. If, in response to this interrupt, it needs to do something time-consuming, it makes a DPC request to have this work queued and then immediately returns. For example, filling an audio buffer. It would NOT actually do that inside the interrupt service code. It would queue the request as a DPC and then get called back later to do it.

Poorly-written drivers often perform time-critical code in the wrong place (WiFi drivers are particularly prone to this), causing the entire interrupt structure to 'block up' and interfering with other processes on the machine.

DPC latency values below 1,000us are in general highly unlikely to cause problems with audio streaming. Audio software can measure this value during startup and therefore predict how many buffers it will need to keep filled. The problem occurs when a poorly-written driver, or some other task, doesn't use this queuing mechanism properly and performs a time-consuming task inside a critical section. When this happens, other tasks suddenly find that their queued requests don't get honoured within the normal timeframe. What was, say, a 500us typical response time suddenly goes out to, say, 10,000us (10ms). Now there's a problem.

The DPC latency checker is not, therefore, measuring overall DPC time as some kind of 'figure of merit'. There are good reasons why on a number of systems, the average DPC latency can be quite high. As long as it remains consistently below 1,000us there is no reason to believe that DPC latency is the cause of dropouts, since, being constant, it is compensatable inside the audio software itself, which knows how far in advance it needs to fill a buffer. At 44.1KHz, a mono 24 bit buffer, assuming that we just throw away 8 bits and queue 32 bit words, consumes 44,100 words per second and so in 1000us you are consuming approximately 44 sample words. You can see therefore that in 100us you are consuming 4 sample words. Compared to actual buffer sizes, therefore, you can see that a DPC latency of 1000us is sufficient for all but the most ridiculously small buffer sizes and that by the time we get down to 500us the DPC latency is a small fraction of any conceivable audio buffer size.

Noel: you're closer to the coal-face than I am. This is what I understand based on years working with Windows and other embedded systems, and writing real-time software. Is there any reason why a consistent DPC latency around 1,000us would cause a problem with Sonar?. I would have thought unless that time starts jittering like crazy, you won't have an issue. Certainly my Vista 32 system, which has latencies around this figure, doesn't have any audio problems, unless I turn WiFi on, when I can see the huge DPC spikes to 23,000us that occur randomly and correlate them precisely with dropouts.

Not as up on the math as the two of you but real world experience to back it up last evening.  Booted up in XP Pro, shut off wifi and DPC averaged 30 microseconds, about 125 to 150 less than Win 7 Pro.  Not a pure test because the Motu drivers for XP are differ from the Win 7 drivers, but to completely avoid stuck or missing midi notes had to use the same size buffers in XP as in Win 7 though DPC showed XP operating at 150 microseconds less.  This seems to confirm that large spikes are necessary to make a difference to a DAW.

Now it seems the stuck notes are purely a midi problem.  Ideal room placement unfortunately requires long midi cables with extensions.  Perhaps increasing midi buffers would solve the problem.  if this doesn't work, will try temporarily removing the extensions, or connecting midi devices via hub (they're chained now).  Any suggestions to resolve stuck midi notes?

Zo:
No way, that not solve the "problem". The DPC Latency Checker data is unaltered.
With the NVidia GT120M enabled in Device Manager, I have from 170us to 1000us (spikes) in DPC Latency Checker. Disabling de NVidia (the generic video will be then used), I have from 90 to 160us in DPC Latency Checker. I believe this is a driver design problem. I already made tests with the driver downloaded from Asus website and also with the one downloaded from NVidia website and the DPCLC results are the same.
By now I prefer have minus video quality and more security about no audio pops/clicks, until that other workaround be available.
Thank you.

One more thing.

I've posted a new thread regarding my tests with the STUDIO 1747 from DELL.

http://forum.cakewalk.com/tm.aspx?high=&m=1940666&mpage=1#1940666

Brandon, I do not know if you will find it useful, as I am no professional computer tech, but anyways...

Thanks for your posts... I'm still trying to fully understand what Bitflipper and AJ wrote...

Hey guys,

I just wanted to add my experience with a recent migration to Windwos 7 Pro x64 from XP 32-bit and DPC latency. The same exact machine is being used for both OS's.

With A fresh copy of Windows 7 x64 installed I was seeing horrendous spikes through the roof with a machine that was near perfect when running XP. After a lot of knocking my head against the wall I discovered the main culprit was my malware detection program. I use MalwareBytes' Anti Malware which recently added a new feature call "IP Protection". When this feature was enabled I got severe DPC spikes. Especially when there was any network traffic. Once it was disabled I got a steady 130us or less. 

Other factors that helped reduce DPC latency was disabling the second (unused) LAN port on my motherbord. Updating the drivers for the LAN card from the manufacture's website. Win 7 installed drivers that were a bit older. Also the video card drivers Win 7 installed were a few versions behind the current one ATI supplied. While I can't seem to obtain the same level of DPC latency performance I was seeing with XP on the same machine I do not experience any spiking and my audio plays back just fine.

My question is what would be another factor that would make the DPC latency higher under Windows 7 x64 vs. XP x86? I was hoping to get the PDC latency performance improved even further with my Win7.

I'm going to take a look at my BIOS and see if I can disable HPET. 

Good thread fellas! Thanks.
 

aking the slider up to 128, 256 and 512 adds more latency but still keeps the DPC "in the green", but 1024 puts it constantly in the yellow, and 2048 (the highest allowed) produces all red bars.

That's not surprising. Normally, you just want to run DPC latency checker with all audio apps shut down so you can see what the "quiescent" state of the machine is. Of course the DAW app itself is going to drive the DPC latency up. That's fine. You just want to know that nothing else is going to interrupt it.

Actually, the Tascam FW-1884 Control Panel is not part of SONAR or any other DAW.

 
Ah. Okay. I missed that. I can only access my interface's latency control through SONAR. One thing I'd be curious about is whether there's any differen if you restart (not just reset, but close and reopen) the Latency Checker after making the adjustment. I've noticed that it seems to get locked into falsly displaying a continuous high level under certain circumstances. And if you restart it, it drops back to normal.
 
I just did a quick test, and changing buffer settings for my 1820m with SONAR running has no effect on DPC. In fact, even running a heavy project and adding load to the point the I start getting clicks from CPU strain didn't really affect average or peak DPC latency. I guess it's not that sensitive to what's going on at higher O/S levels.

Only for clarify:
1- In my tests, I haven't any program opened, only the DPC Latency Checker;
2- The tests was made booting the notebook in the audio boot, where are disabled all non used hardware devices, as wireless, network card, onboard audio card, no antivirus programs running, etc;
3- After disabling the NVidia driver all the spikes was gone and DPC Latency stay under the 90-120us range, what for audio purpose is an admissible range. So, is evident the relation between the NVidia driver and the DPC Latency spikes;
4- By other side, the fact of a NVidia technician have posted a topic asking for tecnical specs of user computers with NVidia video hardware devices wich have DPC Latency problems is an evidence of that the problem exist and need to be solved.
Waiting for a NVidia fix.
Best regards.

Scott,

Thanks for the reply. My system has been working great and the extra RAM access makes a much welcome difference. I'm pretty satisfied with Win7 X64 thus far. It took about a week to get everything sorted out and working. Between bit bridge and J-bridge all my plugs are working in Sonar x64. So well in fact I did not even install the x86 version.

That thread on the nVidia forums references laptops and power management specifically. Do nVidia cards for desktops have the same issue?

JohnCr


Hey ppl,

Often this option is forgotten in the lists of tweaks.
This only applies to people using Windows 7/Vista 64 bit who are experiencing problems.

If you are experiencing a lot of spikes and high latency's measured in DPC Latency checker and/or experiencing crackled sound when just watching a youtube HD video or playing an mp3 then see if you can disable the HPET (High Precision Event Timer) in your BIOS. This is mostly found in the power management setup.

On some i7 machines i saw the DPC latency checker drop from around 100us to 11us. This is of course not the same for everyone.
Also solved weird issues (syncing) when you work with video in Sonar. (Using m-audio soundcards).
 
 

Isn't there a risk that all measuring done by DPC tools is reduced when disabling HPET?
 
I mean what you readout might not be as accurate?
 
I've used the high resolution clocking to measure performance on routines when doing programming, but it depends on that it's supported.

bitflipper

That means it takes 5,800 microseconds to fill a buffer. That means the CPU has 5,800 microseconds to process the data before the next buffer demands to be processed. A typical modern CPU can execute over 64,000 instructions in that interval.

I just noticed this thread and I'm not trying to be picky here, isn't 64K instructions in 5ms rather too low?  We don't normally quote MIPS for PCs (like we always did for mainframes), but I'm thinking that a single core machine these days might have a MIPS rating of maybe 1000 (that's 1,000,000,000 intructions per second) or 5,000,000 instructions in a 20th of a second.  Now, I don't know the average figure for cycles/instruction, but at ~3GHz, and with each instruction taking 3 cycles on average, that would be 1000MIPS.