Noel Borthwick

@Darcy

We've been close to Microsoft for over 20 years

There is no processor architecture specific coding in Cbb for multiprocessing and I would wager most other apps as well. It would be dangerous to do that since performance would vary across different CPU models. To Cbb all threads are equal. My guess is that with threads on virtual cores you are at the mercy of the OS implementation, system load and the hyperthreading implementation, since these threads are not truly running on a dedicated core. This old post kind of sums up this behavior. My guess is that when the primary core is really busy due to a heavy load, the virtual core doesnt get a lot of time to run. In a mixing workload with multiple tracks the full cycle cannot complete until all channels are complete so if some cores are starved I can see it having a detrimental effect to simply running without hyperthreading. I could try and add an experimental mode where we filter out processing workloads on threads assigned to virtual cores. Or perhaps do this dynamically based on the actual CPU workload. i.e. if the workload is lower, then utilize hyperthreaded cores but as it gets closer to 80% or some value dial back to physical cores only. Who knows if that will help

Please read this article. Plug in specific crashes should first be reported to the vendor since they are able to best investigate the problem. If you send us a dump file AND the project file we can forward it to Waves as well.

Ben or anyone else still having issues with iRig HD 2 i let us know if this is ok in the latest build. The folks at IK multimedia have validated the build and it works ok for them so if you have issues please contact IK directly and they can help troubleshoot it.

There are differences between logical and physical cores because the OS handles them differently. Esp in the case of hyperthreading or in the case of AMD simultaneous multithreading (SMT). There are API's to identify whether a core is logical or physical. See GetLogicalProcessorInformation See this benchmark that has more details on how hyperthreaded cores can effect performance.

Yes you can set a preferred core using the SetThreadIdealProcessor function. We in fact have support for this. There are CPU architectures where some cores are efficiency cores and others high performance. While this is very common in the mobile silicon (phones, iPad, etc) its is now becoming mainstream even on other CPU's. AMD's hyperthreading was different from Intel (not sure about their current offerings) and hyperthreading was not as efficient before. Also the new Apple silicon has low powered cores and high powered ones.

Which version of Cakewalk are you running? In case you can't open the app you can check the version in windows via the file properties of the exe file. Make sure you have installed the latest 2020.11 release which is build 99. If you are unsure you can uninstall the program and then re install via bandlab assistant.

@Erlend Holm your crash is different from the OP, its not the same issue. Its failing in the Waves 12 shell. This is something you will have to follow up with Waves on since its their crash. Please contact waves tech support and give them the same dump file AND the track template containing the waves plugins. If you send me the template file I can also forward it to them. Unhandled exception at 0x00007FFA19D6B3C3 (WaveShell2-VST3 12.0_x64.vst3) in Track 1_11282020_015537.dmp: 0xC0000005: Access violation reading location 0x0000000000000019.

Are you running the latest version of Cakewalk? Which browser drop down are you referring to? Please post a screenshot.

Yes if the request for to check for an update took long it was delaying the app start. This has been resolved.

There have been no changes to that area in the .11 release. What build were you running before you upgraded?

Historically I've found Intel multicore systems to be more deterministic with realtime apps. But I've been out of the loop with AMD for awhile so don't know much about how they stand up today.

Yes its possible that the other virtual cores are being preempted by the OS and not able to process as much as the main cores. @Jim Roseberry may know more about that CPU. Lookahead is really pre-buffering in parallel. Its possible at some point for us to look into. Of course that will cause latency when playing since audio is being processed ahead of time.

Interesting. I don't know much about the internal architecture of that CPU but are the virtual cores running at lower speed than the physical ones? That could explain why this helps because if a high workload is assigned to a low powered core it will delay the rest of the processing by that amount. In real time multithreaded streaming the thread that takes the longest processing time will scale down the performance since all other threads have to wait for it to complete before a buffer is complete.

Have you enabled the option to give keystrokes to the plugin in the plugin view?

The 2020.11 update 1 release is now available (help | check for updates). This fixes the above issue along with several others.

Your file did not attach properly.

@LeVonne E Johnson Jr the dump you sent was from build 88 which is earlier. So you get the same crash in build 93? You can upload the dump file to any file share like onedrive or google drive and send me the link. This is the preferred way to do it. Also zipping the file will save a lot of space. Something to try. Instead of opening the project from the start screen, please close that and open the file from the main application file menu. Or try File | New. Let me know if that works. How were you opening your project when it crashed? Its crashing because something has prevented the app from initializing fully according to the dump. I suspect that something failed when initializing your audio device. Do you get any error messages?

Please attach the minidump file listed in the error message so we can establish the cause off the crash. Have you tried the latest update release that we plan to release soon?

Another updated build was posted today fixing some reported issues.

@Herve Maratrey it seems like you are running a really old laptop with a very old BIOS from 2011. It is very underpowered by todays standards and only has 4GB of RAM. At least for the graphics and memory - the CPU is a quad core which should be fine. What is the PC model? BIOS: BIOS Date: 08/10/11 12:28:49 Ver: 04.06.03 (type: BIOS) Processor: Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz (8 CPUs), ~2.2GHz Memory: 4096MB RAM Available OS Memory: 4002MB RAM Page File: 4818MB used, 3534MB available Windows Dir: C:\WINDOWS DirectX Version: DirectX 12 There are no obvious errors in the log but my guess is our code is incompatible with this version in some way. User DPI Setting: 120 DPI (125 percent) System DPI Setting: 120 DPI (125 percent) Can you temporarily change your DPI scaling in windows back to 100% and retry to rule out a scaling problem?

No it doesn't. Once imported the data is lost since the file is transcoded. You will need to redo the data if you reexport.

The symptoms sounds exactly like the bug I fixed that's why I wanted you too retest with the new build.

Thanks we'll investigate it.