Attempting to isolate Virus Scanner as problem
John Bond
audio playback on our specialized audio card (meets various operator headset
standards, yada yada). The board is rather old, but the DSP is peppy enough
for the simple tasks it must do. Using KeQueryPerformanceCounters, I have
been able to show that the DSP/ISR/DPC are behaving in nearly idea timing
with absolutely no problems seen of dropped or delayed audio packets.
The problem is only occuring on systems using N*** antivirus. We have
tested over thirty systems so far. Their corporate policy will not allow
disabling the antivirus. The attempts to stop the AV from triggering on
reading WAV files has not yet improved the problem.
The problem has been isolated to a 6 to 9 second delay occuring outside of
our DLL/driver interaction. As I have added fprintf's to the DLL and WPP
TraceEvents to the driver, the delay has moved closer and closer to the start
of the DLL function that ultimately launches the IOCTL that starts a
PlayBuffer on the first channel.
I have seen this effect before when the cause of the CPU-cycle-robbing
process occurs "before" the call to my code. The customer's app opens a WAV
file, copies it to a buffer, then passes me a pointer to the buffer. As I
have added more time consuming fopen/fprintf/fclose trace messages to the DLL
the delay has moved closer to the start of my DLL function.
The CPU-cycle-robbing process does not seem to stop the DPC from copying the
audio buffer to the DSPs double buffer. That timing is fine.
Does anyone have any further advice or need more details? Thanks in advance.
--
Mr. Fixit needs your help! - John Bond
Scott Noone
> advance.
What are the characteristics of the delay? Is the CPU active during that
time period (i.e. CPU spike) or is it idle?
CPU spikes are generally easier to deal with since they'll show up in xperf,
kernrate, or VTune traces.
Idle delays can be a bit stickier as they won't show up in any of those
traces (this is why I have my own package for measuring elapsed function
time, though that needs to be compiled in unfortunately). If I have a
consistent repro for these I typically repro the delay and then break in
with a kernel debugger so that I can inspect any threads that might be
involved.
Not much of a help yet, but maybe understanding the characteristics of the
delay will help guide folks a bit.
-scott
--
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
"John Bond" <john...@newsgroup.nospam> wrote in message
news:A3FA1E7A-2E9B-478B...@microsoft.com...