Is wavelab a real multicore program? Let me explain.I have Wavelab 10.0.30 on windows 10 pro 64 bit.My pc is an i9 9900 with 64 gb of ram.When i master at 96 kHz with 10 or more plugins from Acustica Audio Dmg Fabfilter etc the green bar near the transport gets almost or to 100% and the audio in play start to have some drop outs.BUT if look at the values given by process lasso pro which handles the priority of all active process, the CPU is only at 13% and the ram only at 10%.So i must think that Wavelab is not using all the cores of my cpu or is not a real multicore daw.
Is this correct? Thank you
WaveLab uses multiple core in the batch processor, or when rendering files while playback is occurring. But for the montage, there is a single core being used for DSP.
Ok thank you PG
Is this going to change in the future?
In mastering we use heavy-CPU plugins. I was having trouble with a montage doing stems mastering with only 4 tracks @ 96k and it was having a hard time. I have a 12 core xeon mac trashcan. Does this mean WL only uses 1 of the 12 cores in the montage?
lots of things don’t seem multithreaded
I think with ‘having a hard time’ you mean it took some time? And yes, only 1 core can be used because there is no distribution of tasks possible in a sequential process like rendering. Plugin A needs to be processed before Plugin B can be processed.
Having a hard time meant realtime playback feeling really heavy or sluggish.
So a machine with a higher clock speed work better than having more cores for rendering?
So a machine with a higher clock speed work better than having more cores for rendering?
For rendering a single file, yes, but no when batch processing.
Philippe
When rendering multiple regions from a Montage, would it be possible to use multiple cores? Wouldn’t each sequential process be handled separately?
When rendering multiple regions from a Montage, would it be possible to use multiple cores? Wouldn’t each sequential process be handled separately?
It is currently not possible, but it could become possible in the future.
It is currently not possible, but it could become possible in the future.
Please please please!!!
For me, and I’m sure many others, then this would be a massive time saver. I typically master a project/album in one montage. Once the analog captures have taken place and final processing is done then I bounce off the final masters. CPU hungry, post-analog processing plugins can take quite some time to render. Even on a fast machine. Being able to spread this via multiple cores would result in huge time savings for me.
I would say that if it’s technically possible, it would be very good to make it a priority. It seems that even on pretty decent computers, working at 96k with today’s modern mastering plugins is very easy to make out a CPU and make WaveLab feel slow.
I would 2nd Justin’s comments.
Thirded.
I’ve gone rounds with Presonus and Cakewalk on this. Their audio “engine” in real-time seems to only work on a single core. So, you’re not always likely to see a performance increase by going Hyper-threading, or adding more cores. In fact, more cores requires lower CPU GHz speed, in many cases, and the “scheduler” of tasks to each core slow you down as well. In both cases, I’ve had the recommendation to go with the absolute fastest CPU you can get.
When I’ve mixed 96Khz 30+ channel Presonus mixes in real-time, I’ve had to offload Waves plugins to a Waves Impact server, which provides more CPU. I’m using an i7 3770K 4.8Khz CPU from 2014 and 16Gb of RAM. I can easily go 10 DMG, Waves, Flux, Plugin Alliance, etc. plugins with minimal effort. The best work-around today still remains:
- Commit. Commit some processing to free up plugin CPU requirements.
- Shut down everything else on your machine while you work.
- Set your plugins for Low-CPU for listening, but then set them to highest quality for Rendering.
- Down-sample to 48Khz. This one is controversial, because a lot of people honestly believe there is a significant improvement between 48kHz and 96Khz. However, many Mastering engineers admit to using 48Khz.
- Go through your system and evaluate some services that run, but you don’t need. You can set them to Low-priority (green leaf) mode and save some CPU there in Windows 10.
- Update all your plugins and drivers.
- Reboot a few times, and certainly watch your Task Manager to see what’s eating your CPU.
Hope this helps!
Rendering an audio stream is inherently a single-threaded process at heart as you need all the results at any point in the rendering to feed into the next point.
Paul
FWIW, my comments are not aimed at rendering really, mo towards general playback while trying to work in a montage at 96k with commonly used 3rd party plugins for mastering.
It’s tough for me to fully gauge because my iMac Pro is at my studio where I usually lean more on analog gear and less plugins and my maxed out Mac Mini and fairly powerful MacBook Pro are of course only able to do “in the box” mastering and that’s where I feel WaveLab struggling prematurely when trying to work.
Render times are something I’m used to.
With Mac Mini’s and MacBook Pro’s, also keep in mind, Apple doesn’t usually provide the fastest CPU’s. They shoot more for rendering speeds and other work. More cores, slow down a CPU, and the CPU’s of higher core counts are slower in actual CPU speed. The idea is Macs can multi-task quite well. Unfortunately for the MacBookPro, Apple also lowered the speed priority in trade-ff of lowering heat cooling and power requirements.
Real-time playback at 96Khz sampling is also going to suffer if you don’t have the ability to set higher read buffers in your DAW for ASIO outputs, for example.
See if just one plugin consumes lots of CPU.
I think it would be cool if there was a facility in Wavelab that would automatically chop up a single audio file, by the number of cores available. render each segment and put each rendered segment back together again. It would make single renders really fast.
It would also require overlaps at the cuts of double the longest processing tail of any of the plugins in use, and probably various other complications.
Paul