Some further instructions of configurations in AUD.INI like ExtraPluginBufs and EnableCacheWriteThru which are not stated clearly...

[Parco]

I looked into your documentation to search for the parameter "ExtraPluginBufs" and read how to use it. But nothing more it tells me else. At least, I even don't know what unit is the value of this parameter. What does this value represent? the amount of samples? the multiple of my driver buffer size? or the time unit like milliseconds or microseconds? 

 ExtraPluginBufs=32 means 32 PCM samples of extra buffer? or means 32 times of my driver buffer size? (e.g. if 256 samples for each ASIO buffer then ExtraPluginBufs=32 = 32 x 256 samples = total 8192 samples size of extra buffer?) or means 32 milliseconds of extra buffer?

Could ExtraPluginBufs reduce or even cancel all the large latency produced by large buffering plugins like the linear phasing multiband effects? The size for each individual plugin or total limitation for all plugins summed up? Is this fixedly allocated whatever the plugin uses or whatever how much the plugin uses finally? Or is this just the limitation for dynamic allocation so how much it eats up the memory physically is just dependent on how much each plugin request? 

 

And beside, two more questions:

1. The EnableCacheWriteThru parameter. Does the "cache" here mean the physical cache memory chips just right on the PCB of my hard drive (which after SATA protocol communication)? Or the Windows 10 kernel default writing cache inside my RAM? or anywhere else? So when I config EnableCacheWriteThru=1 as default, then Cakewalk will bypass all the hardware physical caching mentioned above and force the write head of my harddisk to write into the magnetic sectors on the platters instantaneously at once until the actuator confirm the Cakewalk program?

2. How does the value 3 (aggressive) in parameter ThreadSchedulingModel work like? e.g. Automatically detect how many CPU cores installed inside this computer and auto allocate threads into each core? e.g. allocate 16 threads while 16 CPU cores detected and allocate 8 threads while 8 CPU cores detected?

[reginaldStjohn]

 

 

From what I read the unit is "buffers".  I don't know which ones how how big they are but it is telling cakewalk to to reserve more data buffers for plug-in processing because certain plugins take the available ones and hold on to them.  This seems to only be needed if you are experiencing drop-outs.  I don't think it would do anything to help with latency

 

As for your other two questions

1. The description seems pretty clear. Turn it on if you want to bypass the cache of your hard drive. I would only do this if you have some specific reason to do that.

2. Only one of the developer's can answer that. However,  I don't think you have to know how it works to use it. Try it and if it works better for you then keep it. The current recommendations seem to be keep it at 2

[azslow3]

All these parameters are internal tweaks for Cakewalk engine. Changing these settings can help with unexpected behavior under specific conditions. Googling particular problem sometimes show recommendation to change one or more such parameters.

In other words, till you have particular problem there is no reason to touch these parameters. Defaults are working well in most cases.

"Large buffering plug-ins" introduce corresponding latency. Cakewalk engine is "real-time" only, it is not able to cancel latency, it can only ignore it when required. As written in the documentation and suggested in the user guide, ExtraPluginBufs can only reduce/avoid audio drops when using some of these plug-ins. The "value" should not be interpreted as meaningful by user (even so it has some internal technical meaning for sure).

[bitflipper]

As noted above, some INI settings affect how Cakewalk deals with latency, but there is nothing in there that's going to be able to reduce latency. Especially when that latency occurs within a plugin, in which case Cakewalk has no choice but to wait it out, even if means doing nothing for N milliseconds. 

ThreadSchedulingModel tells Cakewalk which of the three variations (0-2) to threading algorithms to employ. The newest of those methods (#2) is intended to be more efficient with modern CPUs (4+ cores) and was designed with WASAPI in mind specifically. However, Cakewalk will utilize all of your CPU's cores regardless of which model you choose.

EnableCacheWriteThru is a true/false value that's true by default and is meant to make writing to disk more efficient by bypassing the drive's hardware cache. It is only relevant if write caching has been enabled, which it usually isn't - at least, not for audio applications where speed trumps efficiency and even reliability.

 

[Starship Krupa]

17 hours ago, bitflipper said:

ThreadSchedulingModel tells Cakewalk which of the three variations (0-2) to threading algorithms to employ. The newest of those methods (#2) is intended to be more efficient with modern CPUs (4+ cores) and was designed with WASAPI in mind specifically. However, Cakewalk will utilize all of your CPU's cores regardless of which model you choose.

Los Pastaleros introduced a 4th a couple of versions ago. #3 is "Aggressive" mode. It's supposed to take even better advantage of newer, faster, many-cored CPU's, but exactly how is probably a trade secret. ?

My guess is that Noel tightens up the timing as more processing power allows. And/or shifts priorities in regard to the audio engine vs. other tasks.

That's just speculation based on my own experimentation with a couple of older computers that preferred model 2. It felt like Cakewalk was stretched a bit thin. Switching back to model 2 made everything okay. It's there to take advantage of higher-performance systems, not to squeeze more performance out of aging systems.

The Word is: "Try it and see, but remember that you made the change, so that if your system responds unfavorably, you know to switch it back." I have trouble with the "remember" part sometimes....?

[bitflipper]

Thanks for the reminder, SK.  I'd excised mode 3 from my brain, the same way I've purged most memories of my teenage love life. Unlike the latter, mode 3 is still a WiP.

[Parco]

So now does it mean the ExtraPluginBufs is configured by multiple of audio driver buffer amount? e.g. If I give 32 to ExtraPluginBufs and my ASIO buffer size is 256 samples now then each plugins would get 32 x 256 = 8192 samples more buffer (plus the driver 256 samples buffer) to process? If some plugins don't really need so large buffer size so won't be allocate all 8192 samples of buffer (dynamic size allocation)? And won't Cakewalk just read ahead multiple times of 8192 samples data one off first immediately then keep filling in the "future" buffer to satisfy the plugin, and abandon those "future buffers" while stopped playback or realtime midi or audio input? This may increase CPU workloads (so only work this way with fast CPU) but could eliminate the waiting time which Cakewalk doesn't have to wait it out anymore, theoretically.

About the EnableCacheWriteThru, according to my comprehension about what you said, TRUE value forces Cakewalk make sure mechanically writing to the magnetic disk platter immediately and bypass the hardware cache chip in my WD hard drive and the Windows kernel writing cache in RAM as well? And False value may make Cakewalk use the WD cache chip and writing cache in RAM as well? I wanna make sure that I'm not misunderstanding the core concept... And may it speed up the process while using cache?

Quote

It is only relevant if write caching has been enabled, which it usually isn't

So is the EnableCacheWriteThru value only relevant while the caching config in the red circle area on this page applied (checkbox checked)?

 

Quote

#3 is "Aggressive" mode. It's supposed to take even better advantage of newer, faster, many-cored CPU's, but exactly how is probably a trade secret. ?

So is it supposed to take better advantage of such like the 8 physical cores (16 logical cores) i7 10700K and the 10 physical cores (20 logical cores) i9 10900K, which are 4+ cores CPUs?