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?
So is the EnableCacheWriteThru value only relevant while the caching config in the red circle area on this page applied (checkbox checked)?
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?