Hi Martin, I've found HWinfo sensor monitoring is causing audio/video glitches (from DPC latency spikes) on some Haswell mobile cpus under load.
Fortunately disabling Periodic polling of Bus Clock completely fixed them.
I think it should be disabled by default (poll only on startup): people who need it are the ones that are changing BCLK on the fly, and are less than the ones that may be impacted by the "on" default.
Thanks for your work!
That's interesting, since this option should not cause such issues on those systems.
Are you sure it wasn't caused by another option or sensor (e.g. EC) ?
Absolutely sure. Hwinfo can't read EC on this laptop, and I tested disabling / re-enabling each sensor monitor to be sure: it's only caused by the clock polling. During heavy CPU load it can cause usb audio to mute for 1-2 seconds. How you're reading it exactly, comparing QueryPerformanceCounter and TSC?
Which CPU is on that notebook and do you have the "Bus Clock-based" option enabled ?
Measurement process depends on CPU family and features supported, so it's more complicated. TSC can't be used on later CPUs, because it's running invariant of current P-State.
Bus Clock Based enabled cause one only one spike on startup, adding Periodic cause spikes on each update, disabling Bus Clock Based remove all of them (even leaving periodic on).
This seems to happens only during video playing, so I think there's some conflict with an hardware timer.
OT: I found another strange bug related to video: it seems if I start HWinfo while a video is playing it will find a new sensor called iGFX voltage that it never find otherwise.
Are you reading iGFX info from some Intel driver interface or from MCHBAR?
Well yes, theoretically there might be some timer conflict when certain kinds on applications are running.
The iGFX voltage comes from MCHBAR.