CPU issues

[jochicago]

So I'm new to DAW work and just got started with Tracktion 6 (loving it).

I'm using a video-editing computer that should have enough CPU for days. So I'm living the dream, mixing a 15-track song and just going ninja ape using VST plugins liberally, and when I got to the 55+th or so plugin the real-time audio started stuttering. Now I'm facing the possibility of having to be adult-like with my use of plugins.

Tracktion's CPU meter shows about 75% when the audio starts crashing, but at the same time my computer says that I'm using less than 15% of my 16 CPU cores.

I feel like something's off. Help me live the dream. I positively refuse to route my EQ and reverb into a dedicated track. Every one of my tracks needs to have multiple layers of EQ and reverb to round out the other 5-7 plugins per track.
#NoCompromiseEverNoMatterWhat #BecuaseWeCan-WhyElse

I checked the settings and it is set to use 16 cores. Maybe I need to pull back on the millisecond stuff?

[zzz00m]

Audio chains per track cannot make use of multi cores, due to dependencies on processing the signal flow.

So at best any DAW could use one thread per track. At this point it about Ghz processing speed per CPU core for each thread. If you are maxing any one thread, you will get breakups and dropouts.

You will need to think about how many plugins you are trying to run at once.

[jochicago]

It's really a tube amp plugin that according to the Tracktion 6 meter uses up about 25% by itself. I'm trying to put it in the final mix track but it looks like by then Tracktion has run out of steam.

But like I said, I'm monitoring the 16 CPU cores via the Win10 Resource Monitor and not one of them reports any high numbers.
With everything on at Tracktion and with the sound stuttering, Tracktion's meter is at ~89%, but on the Win10 Resource Monitor the total CPU usage is ~6%, Tracktion as a process is at ~12%, and of the 16 cores the highest spike is core #8 at around 20-30%. And the other CPU cores appear near unused.

I think there's something off at Tracktion's settings. I would understand if at least one of my cores was at like 90%, but my system seems untaxed while Tracktion is coughing up a lung.

[zzz00m]

Here are some helpful tips that should apply to any DAW. It's not magic, just engineering. Good reading!

How to avoid crackles and audio dropouts
https://help.ableton.com/hc/en-us/artic ... o-dropouts

Reducing the CPU load
https://help.ableton.com/hc/en-us/artic ... e-CPU-load

Multi-core CPU handling FAQ
https://help.ableton.com/hc/en-us/artic ... e-machines

[jochicago]

Thank you for the links, I'm taking a look.

I tried fiddling with the buffer settings to no avail. I can make the problem worse with those settings but nothing makes it perceptibly better.

Most of this does make sense within the Tracktion UI. The processor meter is giving me feedback, the meter details show the plugins utilization and show the worst offenders, and disabling plugins makes the CPU meter respond consistently.

It is just that it all feels like it is operating inside an emulator. The computer seems to have plenty left to give. Ram is at 37%, the HD usage is at 0%, CPU usage is at 7%. I tried looking at any potential power savings throttling but I couldn't find any. The Tracktion process was already set as high priority. I also tested to see if my cores are responding correctly so I ran a web benchmark tool and that made all my CPU cores spike to near 100% from within Firefox, so I'm pretty confident the computer is not throttling the CPU cores.

All ideas welcome. This is not a problem, as already Tracktion has amazed me with its ability to handle dozens of plugins in real time inside of 5ms latency. I can definitely continue on as-is. But why stop now, when the CPU still has 93% to go?

[jabe]

You could check out the track freeze and rendering options. There are a few options. You can insert the Freeze Point plug-in at any point in the plug-in chain for a track, and it means that a version of the track with all plug-ins up to the Freeze Point is created so that only subsequent ones are in use and adjustable (but you can move or remove the Freeze Point plug-in to adjust earlier ones). You can render a track entirely, so that on playback you will hear the track as it would sound with all the plug-ins as you had set them, but during playback they wouldn't be operating, so there'd be less CPU used. With MIDI tracks, you could render to create an audio track instead.

These ought to free up some CPU.

[jochicago]

Thank you for the ideas.

The freeze solution is quite useful. I still think it would be helpful for everyone if we can get to the root of the CPU weirdness.

I tried the freeze but it says I can't apply it to tracks that route to another track. This is my routing:
1. section groups with individual effects
- percussions
- guitars
- voices
- other (bass, piano)
2. final effects/master

So I'm routing everything into a final effects track which I'm using for overall atmosphere and final touch ups. Since I'm right there, I'm also using it to apply mastering work, so this final track is the heaviest of the project.

I was not able to apply a freeze to the section groups because it said I cannot apply if the track outputs to another track (in this case the final track). However, I was able to apply the freeze to the start of the final track, thus freezing the entire project up to that point and allowing me to go as heavy as I want on that final track.

So, thank you, this freeze trick already empowers me to continue to work ninja ape style with zero regard to using a sensitive professional approach - I just have to give it a minute every time I unfreeze/freeze the final track.

However, I'm wondering if there's a trick to apply the freeze earlier in the routing, so that I can freeze some sections but still retain control over other sections.

For instance, I'm still working on my percussion section and I'm finding the mastering track useful in identifying tweaks to the percussion. If I could freeze the other sections, Tracktion would have enough processing power to maintain the heavy mastering track and the percussion section open for editing at the same time.

[jochicago]

BTW, to answer my own question, I believe I could render the sections then import into a separate project for final touch ups.

What I'm hoping to be able to do is keep it all in the same project because I'm a rookie, so being able to go back and forth is helping me learn and also helping me correct the sections as I hear it all in context with my final adjustments/mastering.

[zzz00m]

Something to consider is that the lower your audio buffer settings, (for low latency), the harder your CPU must work to service all of the plugins without dropouts.

Try raising your buffer settings a bit (increasing latency), and see if that improves the workload on your CPU.

A lot of folks use low latency while recording a track, especially for monitoring effects in the box. Then once you are done recording, you could set the buffers higher while mixing the tracks and tweaking the effects. Also if you can freeze the tracks you are done with, then you only need extra CPU power for the track(s) you are working with.

[MaxC]

I'm experiencing the same issue on my rig (Tracktion 6 on Windows 7). The CPU meter in Tracktion is consistently reading 25-30 percentage points higher than Windows Resource Monitor, regardless of buffer size. I even went so far as to buy a new interface with better ASIO drivers, thinking that perhaps ASIO4ALL was the culprit, but the new drivers made no difference at all.

Is anyone else experiencing the same issue? It's frustrating to hear audio dropouts start to manifest as Tracktion's CPU meter approaches 80-85%, only to see the Task Manager show the CPU (Core i7) working at only 50% capacity. Perhaps the better question would be, is there anyone else in our circumstances (Tracktion 6 on Windows 7) who is not having this issue?

[zzz00m]

I'm experiencing the same issue on my rig (Tracktion 6 on Windows 7). The CPU meter in Tracktion is consistently reading 25-30 percentage points higher than Windows Resource Monitor, regardless of buffer size. I even went so far as to buy a new interface with better ASIO drivers, thinking that perhaps ASIO4ALL was the culprit, but the new drivers made no difference at all.

Is anyone else experiencing the same issue? It's frustrating to hear audio dropouts start to manifest as Tracktion's CPU meter approaches 80-85%, only to see the Task Manager show the CPU (Core i7) working at only 50% capacity. Perhaps the better question would be, is there anyone else in our circumstances (Tracktion 6 on Windows 7) who is not having this issue?

I think that the Tracktion CPU usage reflects the Tracktion audio engine only and not the entire computer, as the Windows resource monitor does.

You are probably maxing out a CPU core/thread with a hungry plugin or effects chain. Some audio processing cannot be split (multi-threaded) over multiple cores Your Windows CPU usage is showing the total available to all cores.

[spoontechnique]

It's worth noting that freezing and rendering doesn't work within submixes (at least in the most recent non-beta build). My current solution is to drag tracks out of submixes, render them, then put them back in. Or you can start with a folder track, render the tracks within, and then apply processing to the group, converting it to a submix.

There's a neat feature if you click on the CPU usage monitor. There's a button underneath that gives you the option to freeze all tracks, so you can un-freeze any you want to work on. However, like I said earlier, that doesn't help if you have tracks in submixes.

[zzz00m]

It's worth noting that freezing and rendering doesn't work within submixes (at least in the most recent non-beta build). My current solution is to drag tracks out of submixes, render them, then put them back in. Or you can start with a folder track, render the tracks within, and then apply processing to the group, converting it to a submix.

There's a neat feature if you click on the CPU usage monitor. There's a button underneath that gives you the option to freeze all tracks, so you can un-freeze any you want to work on. However, like I said earlier, that doesn't help if you have tracks in submixes.

That's a good tip!

[MaxC]

I think that the Tracktion CPU usage reflects the Tracktion audio engine only and not the entire computer, as the Windows resource monitor does.

You are probably maxing out a CPU core/thread with a hungry plugin or effects chain. Some audio processing cannot be split (multi-threaded) over multiple cores Your Windows CPU usage is showing the total available to all cores.

That was my first inclination as well when somebody made a similar suggestion above, however I monitored all 8 threads of the four core CPU and they tended to max out at around 55%, so I don't think it's a single track bottlenecking a specific thread.

[zzz00m]

I think that the Tracktion CPU usage reflects the Tracktion audio engine only and not the entire computer, as the Windows resource monitor does.

You are probably maxing out a CPU core/thread with a hungry plugin or effects chain. Some audio processing cannot be split (multi-threaded) over multiple cores Your Windows CPU usage is showing the total available to all cores.

That was my first inclination as well when somebody made a similar suggestion above, however I monitored all 8 threads of the four core CPU and they tended to max out at around 55%, so I don't think it's a single track bottlenecking a specific thread.

I typically get audio drop outs at 50% core use on Windows 10. So that is "maxed out" for me. I don't think you are going to get to 100% on a core before something breaks... real-time audio is too sensitive to CPU latency.

DPC (Delayed Procedure Call) latency is the key, no matter how fast your CPU is. Run LatencyMon http://www.resplendence.com/latencymon to test your system for DPC latency.