Skipping or Intermittent Stop/Start in Audio

Also identical Bios, firmware and driver versions?

try swapping memory between laptops…

Try to disable Audio Real-Time on I/O Configuration. It works with me 😀

I’ve experienced this several times in the past wheretwo or more "identical" PCs behaved differently. Part of the problem is the Qualityt Control testing of each of the components. They set the tolerance levels so far apart that many components may be on the brink of failure, but still pass the test. If you get lucky, you buy a machine where all the components are on the high side of average. If unlucky, everything in it is borderline, and you will be plagued with problems.

Incidentally, I’ve had the same thing with motor vehicles. The theory is, you should always buy a car manufactured on a Wednesday – after the weekend where the workers are still suffering hangovers, and before the end of the week, when all they can think about is the next weekend.

hehe…

Congratulations! I don’t have the reason about it, but on laptops it works better without this option.

Best regards!

@ clock speed changes…

the first place i would be looking is at driver DPC latency spiking when it happens. for badly coded drivers. the bus speeds don’t change with the CPU or GPU clocking, and the functions which software can use to get timing information from Windows shouldn’t get drastically altered by the CPU clock at all.

that being said, Breakaway’s audio timing accuracy for *adapting* to the I/O rates, vs the system timings, is above 1mHz (the actual adaptation is even more accurate). so if you don’t have DPC spikes coming from a driver that are causing the buffer size/count to fail (because of Breakaway not being able to access a soundcard driver, and/or a soundcard driver not being able to access the soundcard) then any potential clock jitter being caused by the CPU changing speeds shouldn’t be anywhere near audible, and should measure incredibly well even to high-end DACs that are re-clocking the input source and also NOT doing ASRC (my Apogee Mini-DAC is one of very few that come to mind).

—

in real-world applications of course… sometimes the power settings for clocking might be able to prevent the problem from happening because of a device driver. the thing that sucks about this is that you’re not taking advantage of the power savings (not that huge a deal until you’re 100s of units deep in rack-mounted computers, been there done that)… which increase the lifetime of the power supply and power-regulation-related parts on the motherboard.

as for the ability to switch fast enough to keep up with demands, trying to argue that it’s a problem for audio applications is a difficult one. you’re comparing buffer speeds as high as 500 Hz (almost always lower), to clock speeds of 3,000,000,000+ Hz. the switching mechanisms are done in hardware, not software, and they adapt soooo much faster than 1 cycle @ 500 Hz that it’s not worth going on about. 😉

there is definitely a few cases with specific hardware and drivers than are coded so wrong for their timing that they can be effected by the CPU clock itself though, spiking the DPC latency, and that’s really the sad part. don’t buy hardware that uses drivers like that. 😉 (such as nVidia’s GeForce 3xx M series, holy cluster-f* that can’t be fixed no matter what power or clock settings you use or disable)