Popping and Crackling - the next thread ...

[Obsidian Dragon]

Usually when I hear pops and clicks, it is often related to clocking issues between distal gear. Are you using any outboard gear (interfaces, AD/DA converters, mic preamps, channel strips, etc.)? Are these synced to a master clock? Is there only one device set as master clock source and the rest set to slave to that master clock? I've run across situations where two devices were set as master and that caused major headaches. Make sure all the synced devices are using the same protocol and clock rate. These may be basic settings for most, but it can sometimes be overlooked by seasoned pros. I believe clocking issues get magnified at higher sampling rates and lower buffer settings, so this might be something to look into. Connecting two pieces of gear might not exhibit the clicking and popping, but when you connect multiple pieces, it can show up.

[Wolfgang Eller]

Originally Posted by Obsidian Dragon

I believe clocking issues get magnified at higher sampling rates and lower buffer settings, so this might be something to look into.

That's why I asked for syncing problems.
I had an external device which worked without any problems in 44.1 and 48 but had real problems in 88.2 and 96.

[dgdsu]

LatencyMon interestingly shows 2 issues from a short glimpse, where one is obvious for me (and fixed now), but the other one surprised me.

The first was ... of course ... Nvidia. Didn't realized that Nvidia while updating slidely changed their setting silently in the background in the last months from Studio Driver to their spammy and malishous Game Experience crap. Turned it back now to Studio driver. The second is Windows Direct X ... holy crap ... I always disable it, but for some strange reason it is still running even if disabled?

[dgdsu]

Originally Posted by Obsidian Dragon

Are these synced to a master clock? Is there only one device set as master clock source and the rest set to slave to that master clock?

Good point! There is only 1(!) RME UFX audio interface running for audio monitoring and recording here in the chain via USB. And the clock in the RME ASIO panel is set to internal and if this means anything: it seems that Pro Tools can't do anything to change buffer size. I always HAVE TO set it on RME side and reboot Pro Tools Session to take over the new buffer setting.

[albee1952]

Windows 10 Pro x64 with Intel Xeon CPU E5-2630 v4 @ 2.20GHz, 2201 Mhz, 10/20 Core(s)

Is this current? If so, I see the cpu as your issue. Speed matters more than number of cores, so replacing the 2.2GHz 10 core for a 3.5GHz 6 or 8 core might give you the boost you need

[The Weed]

Originally Posted by dgdsu

...it seems that Pro Tools can't do anything to change buffer size. I always HAVE TO set it on RME side and reboot Pro Tools Session to take over the new buffer setting.

Normal operation for third party interfaces with Pro Tools. You can change the sample rate from within Pro Tools with RME's driver, not the buffer size. AFAIK, many interfaces can't change the sample rate from within Pro Tools or the buffer size.

Since you have a UFX, as I do, have a look here.

[dgdsu]

Thanks for all the shared thoughts and input on this. Very much appreciated. It doesn't matter if it fits here or not. You are awesome! Give it all to me. I will sort it out.

Originally Posted by The Weed

Since you have a UFX, as I do, have a look here.

Yeah I found the link to your thread before posting here. Awesome and massive detailed post you sharted over there. Heads up and +1 for this. But if there is one thing I have taken over from the developer side of me useful for other parts in work then it is that I like to tackle down to the explicit issues causing something to better understand the real issues behind. Your walk-thru best-of-practise for UFX is awesome, but some of it is outdated or "just-in-case" kind of setting, which should be handled with care to not improve sth. for the worse.

But one question tho' to your walk-thru: Reinstalling Nvidia with only the minimal parts really required was one of my first steps and changing from Gamer Driver to Studio Driver which is better for ProAudo/ProVideo PCs. But it didn't changed the Pro Tools issue yet. But it is better to do it anyway. Apart from that: Why do you kept installing PhysX? Do you play Games on this Computer. I do not think that you need it for Pro Tools and Media Composer or do I miss something here?

Another thing I realized when I found out that Direct X (baked in Win 10 sadly) causes Latency issues (at least regarding LatencyMon) is, that I can't really disable any parts of it. Disabling DirectPlay in Apps&Features, which is the only spot where you can do anything, doesn't do anything to this report. Weird. Apart from the fact that LatencyMon is the most biggest LatencyHog - hah!

Originally Posted by albee1952

I see the cpu as your issue. Speed matters more than number of cores

It depends. Look at this comparision and keep in mind that most ProAudio and ProVideo fully support Multicore on this comparision: https://www.technikaffe.de/cpu_vergl...5_1650_v3-483/ - In mixed suites where Audio and Video will be edited, thread safety (f.e.: file integrity checking) and cores is more important than speed, which is important for games and when you exhale the cores. Speed should always be seen in combination of things like L cache and in combination with cores depending on the application and its preference of course. Apart from that: Speed isn't an issue nowerdays no more. Most of the middle to upper speeded CPUs are abolutely fine for Audio. If there are issues in a scenario like I describe here (only one 2 Instruments, one frozen) the CPU speed of a former upperclass XEON 5 (outdated now a little) is just more than fine.

But of course there is one rule which will always stay: small buffers require higher core speeds, no matter how many cores.

A good read about it can be found here: https://www.gearslutz.com/board/musi...ore-count.html

[dgdsu]

Ok - just just to let you know, another test I did: Testing both NI Kontakt with multiple core support turned on (I choose 4) and turned off. No difference.

[dgdsu]

Now guess what: The good old HT ... Now, after tunring off Hyper Threading (thought this times would be over?) and turning off EM (CPU energy mangement) in Bios something happend and crackling seems to be much less. But needs further inverstigating, maybe something else comes into play. Especially since Windows is in the bad habit of that things take effect after multiple restarts and time passed sometimes. So it is still possible that the Nvidia clean up comes into the mix here just a certain time later...

[ChuckS]

A couple of things that seemed to help performance here (though imagination works wonders):

Set Processor Scheduling to favor Background processes.
Make sure audio device used for PT is not system audio also. I believe RME is multi-client so that is possible.
Set a process exclusion in Windows Defender antivirus for Pro Tools.exe (I also set ProTools.exe - not sure which AV is looking at). That exempts everything (plugs, samples, et al) PT loads.
Turn off Wifi.