clicks and clock adjustment too large

[phofman]

Nice. Issues with latency when switching between power/frequency levels are quite common. E.g. on RPi switching to another CPU frequency has been measured to block the CPU for up to 4ms which is killing for low-latency audio. Therefore it is recommended there to run at full performance cpufreq governor (i.e. no frequency switching), but e.g. at the fixed lowest frequency of 600MHz (still plenty of CPU power) for reliable audio.

 

[andyc56]

i surprised myself and ran the latencyMon tool successfully, twice. First time it quite quickly decided the system was inadequate and recommended a solution which i googled on and disabled the power saving throttling mode in control panel, it ran a bit longer second time which is the screenshot attached. I tried some REW measurements for intersest and found half of them would run woithout warning boxes, not great but perhaps an improvement. Nevertheless i am now stumped again as i am not sure about disabling throttling in BIOS successfully.........
(whilst i was there i reduced the buffer again, thanks)

Hesitant to be overoptimistic, i think things have improved, my computer supporter found and suggested as follows;

Download PowerSettingsExplorer from here and run it as administrator. Then find the following 2 options: Processor Idle Demote Threshold and Processor Idle Promote Threshold, UNtick them both, then go to your power plan settings, find the new option under "Processor Power Management" and set both to 100%. That helps lower mostly all latencies, if you are happy, you can stop here, if you want to try and lower them even further, please continue.

I now have a useable system, I got 12 minutes playtime below 1ms with WIFI on and 15 minutes (at least) with WIFI off.

Hi Mike,

I too had a somewhat similar problem with my system, for which LatencyMon was exceeding its threshold occasionally. Although this didn't cause me a problem in REW, it did cause audible glitches about once or twice a week when listening to music on my system. This caused my listening experience to be completely ruined, as I was always listening for glitches rather that to the music itself. I'm retired with time on my hands, and this experience caused me to launch into a set of experiments that lasted several weeks.

Unlike you, my music playback computer doesn't have a super-powerful CPU - only a low-power two-core AMD Athlon 200GE supporting only 4 concurrent threads. So my problem is likely different from yours, but I'll try to list some software tools I ran into along the way that may help.

In my search, I came across PowerSettingsExplorer as you did, and tried various experiments with it. I was able to get some improvements, but not fix the problem entirely.

Another tool that came in handy was Driver Store Explorer. This shows a summary of all installed drivers, including both enabled and older, disabled ones. You can see if there's anything suspicious there. Unfortunately, it does not allow you to temporarily disable drivers and enable them later, only delete them. Still, seeing everything at a glance is often useful.

Another useful tool is Autoruns64.exe in the Sysinternals Suite by Mark Russinovich. He's the guy that originally uncovered the Sony rootkit scandal. Autoruns64 appears to show all items that are loaded at startup, both apps and drivers, when you look at the "Everything" tab. It also shows how they are launched (registry, task scheduler, startup folder, etc.) When run as administrator, it conveniently allows temporarily disabling or re-enabling startup items by simply unchecking or checking the checkbox next to it. I've used this tool to fix may problems.

Also in my travels, I discovered many sites with poor-quality information, including from people and entities that should know better, such as Focusrite. I finally did run into only one high-quality source of information. That was a blog by a guy named Pete Brown, a software engineer at Microsoft who works on the audio subsystem, does customer interface and has his own recording studio. It is called the Unofficial Windows 10 Audio Workstation build and tweak guide. He provides logical arguments for his suggestions, unlike most sites you'll find out there. It might be worth a look.

In the end, my problem was fixed in an unexpected way. I replaced the USB sound device I was using, an 8-channel Tascam US-16x08, with an 8-channel Topping DM7 DAC. This cut my DPC latency dramatically: about in half. I wasn't expecting this at all, because one of my earlier troubleshooting steps was removing the Tascam and its drivers and trying out a Focusrite 2i2 that I already had. This had the same DPC latency problem as the Tascam. I simply bought the Topping on a lark, not expecting that it would fix my situation. Then, after weeks of listening and zero glitches, I decided to run LatencyMon on it. That's when I discovered the massive DPC latency improvement. I don't know how to explain this. My working hypothesis is that the Topping uses asynchronous USB with a Thesycon driver, and it's possible that async USB usage improves DPC latency somehow. I have no way to prove that though.

Going back to your problem, it might be useful to try the Autoruns64 program to temporarily disable any startup items that look suspicious and see if you get an improvement. The beauty of that tool is that it allows you to put what you've changed back into its original state by just checking a checkbox and rebooting the system.

 

[Mike56]

Still searching!
Where would i disable frequency switching?
The only referenece i can find is highlighted in the attached SS
M

 

[Mike56]

Hi Mike,

I too had a somewhat similar problem with my system, for which LatencyMon was exceeding its threshold occasionally. Although this didn't cause me a problem in REW, it did cause audible glitches about once or twice a week when listening to music on my system. This caused my listening experience to be completely ruined, as I was always listening for glitches rather that to the music itself. I'm retired with time on my hands, and this experience caused me to launch into a set of experiments that lasted several weeks.

Unlike you, my music playback computer doesn't have a super-powerful CPU - only a low-power two-core AMD Athlon 200GE supporting only 4 concurrent threads. So my problem is likely different from yours, but I'll try to list some software tools I ran into along the way that may help.

In my search, I came across PowerSettingsExplorer as you did, and tried various experiments with it. I was able to get some improvements, but not fix the problem entirely.

Another tool that came in handy was Driver Store Explorer. This shows a summary of all installed drivers, including both enabled and older, disabled ones. You can see if there's anything suspicious there. Unfortunately, it does not allow you to temporarily disable drivers and enable them later, only delete them. Still, seeing everything at a glance is often useful.

Another useful tool is Autoruns64.exe in the Sysinternals Suite by Mark Russinovich. He's the guy that originally uncovered the Sony rootkit scandal. Autoruns64 appears to show all items that are loaded at startup, both apps and drivers, when you look at the "Everything" tab. It also shows how they are launched (registry, task scheduler, startup folder, etc.) When run as administrator, it conveniently allows temporarily disabling or re-enabling startup items by simply unchecking or checking the checkbox next to it. I've used this tool to fix may problems.

Also in my travels, I discovered many sites with poor-quality information, including from people and entities that should know better, such as Focusrite. I finally did run into only one high-quality source of information. That was a blog by a guy named Pete Brown, a software engineer at Microsoft who works on the audio subsystem, does customer interface and has his own recording studio. It is called the Unofficial Windows 10 Audio Workstation build and tweak guide. He provides logical arguments for his suggestions, unlike most sites you'll find out there. It might be worth a look.

In the end, my problem was fixed in an unexpected way. I replaced the USB sound device I was using, an 8-channel Tascam US-16x08, with an 8-channel Topping DM7 DAC. This cut my DPC latency dramatically: about in half. I wasn't expecting this at all, because one of my earlier troubleshooting steps was removing the Tascam and its drivers and trying out a Focusrite 2i2 that I already had. This had the same DPC latency problem as the Tascam. I simply bought the Topping on a lark, not expecting that it would fix my situation. Then, after weeks of listening and zero glitches, I decided to run LatencyMon on it. That's when I discovered the massive DPC latency improvement. I don't know how to explain this. My working hypothesis is that the Topping uses asynchronous USB with a Thesycon driver, and it's possible that async USB usage improves DPC latency somehow. I have no way to prove that though.

Going back to your problem, it might be useful to try the Autoruns64 program to temporarily disable any startup items that look suspicious and see if you get an improvement. The beauty of that tool is that it allows you to put what you've changed back into its original state by just checking a checkbox and rebooting the system.

Thanks, careful reading will follow!
M

 

[phofman]

My working hypothesis is that the Topping uses asynchronous USB with a Thesycon driver, and it's possible that async USB usage improves DPC latency somehow.

Sync or async is unlikely to make any difference, async means the driver justs adjusts the number of samples per USB packet, based on feedback sent by the device. In fact async is slightly more work for the driver.

But the actual driver for Tascam & Focusrite could be the culprit, or with some combination. Thesycon driver is quite well tested and similar to stock UAC2 driver in windows (contracted by Thesycon too).

 

[phofman]

Where would i disable frequency switching?

The issue I was talking about was handled in linux - setting the cpufreq governor to "performance" (i.e. running at fixed maximum frequency), and setting the max frequency to something small. No idea if windows allow that. If yes, then likely in the Power Plan configuration.

 

[Mike56]

The miniDSP driver is badged as UAC2 as well, so i guess thats what they use.

Back to Andy's reports, i too find myself listening for glitches.
They are largely gone now but i hope for better.
i shall read the audio man attachment/link carefully, thanks for that.

#47 link is a good but complicated guide including most things i have found useful so far, but there are still some processes interfering which i would like to find.

At one time i set the priority of the driver to high, and it seemed to be of benefit, but miniDSP say this is only the control panel, but i will try that again alongside the other changes that have got me to a half decent place now.

I find myself yearning for very short green lines on a latencymon screen!
Latencymon gives detailed reports as well, are they my guide?

 

[phofman]

The miniDSP driver is badged as UAC2 as well, so i guess thats what they use.

UAC2 is a protocol used by almost all modern USB audio devices which offer high resolution. The actual driver is the key. I do not know what driver miniDSP devices use - whether some Thesycon build, or their own make. They are large enough to afford their own driver.

 

[Mike56]

I thought i would try and minimise all opoerations, so turned off everything i thought i could in BIOS, that was;
LAN
Wireless/Bluetooth
Card reader
HD audio
Camera

and it looked really good for about 10 minutes, see first screen shot, all exceptions much lower than before.

then it gave up again, see second screen shot

Trouble is i cannot interpret from that what changed and i dont really wish to operate the computer that way either...........