Jump to content

Parco

Members
  • Content Count

    2
  • Joined

  • Last visited

Community Reputation

1 Neutral
  1. 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?
  2. 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?
×
×
  • Create New...