• SONAR
  • Freezing tracks doesn't do what I think it is supposed to?
2013/12/13 19:47:03
grizwalter
I am mixing a 44 tracks tune, and while I generally don't have any problem, I've had to nurse my PC a bit on this particular project. Today I was nearing completion, and decided to freeze up the drums (about 10 tracks) the bass guitar (4 tracks) and some of the electric guitars (4 tracks worth).
 
My computer did not particularly thank me for this. In fact, I couldn't get through more than 8 measures of the song without the audio engine dropping out. I figured maybe some additional processing I'd added on the Master Bus was to blame (who wouldn't thunk SPAN had that level of impact? lol), so froze 4 more guitar tracks and a couple vocal ones. That 8 measure haul turned into about 3 measures, on a good run.
 
In X3 I'm happy to see they've added the CPU usage info, and that sucker was flickering yellow (mostly staying red for those measures) pretty much every time. When I could catch it in the yellow, it would show a usage of as much as 92%, and generally around 86% or more.
 
Well, being relatively logical, and after having done everything I could possibly consider to help the situation, I unfroze all the tracks. Viola'! Problem solved. CPU use dropped to the 50 percent range, dropouts ceased, etc.
 
Now, unless I'm missing something very fundamental, I thought freezing tracks was done expressly for the purpose of cutting down on CPU strain?! If so, then I'm thinking an X3e patch needs to be put into motion?
 
Has anybody else experienced this? Is there any logical reason for it? I'm quite confused.
2013/12/13 21:35:38
bitflipper
Freezing will not reduce CPU usage if it's a straight audio track (as opposed to a synth or sampler) and you don't freeze effects as well. Even when it does reduce CPU usage, it may do so at the expense of disk I/O, e.g. when you freeze a synthesizer the resource load shifts from the CPU to the disks.
2013/12/13 21:47:31
grizwalter
bitflipper
Freezing will not reduce CPU usage if it's a straight audio track (as opposed to a synth or sampler) and you don't freeze effects as well. Even when it does reduce CPU usage, it may do so at the expense of disk I/O, e.g. when you freeze a synthesizer the resource load shifts from the CPU to the disks.



Hello bitflipper, and thanks for the info.
 
You mention freezing an audio track with the possibility of not freezing the effects. I thought freezing automatically did both; my effects were grayed out after the process. That's really what I thought the point of the whole thing was. So if I'm correct in that, then the problem goes to your note about freezing audio operating at the possible "expense of disk I/O...." It seems odd to me that freezing could have a net negative effect, but based on what happened, and what you say, I'm not sure there is any other logical explanation.
 
 
2013/12/13 22:32:46
chuckebaby
I was also under the impression that freezing a track freezed the effects in the state they were in to lessen the load.
2013/12/13 23:27:35
SuperG
It's in the right-click Freeze options dialog as Track FX, if it's not checked, FX are not baked in and are still live. You can tell if you've freezed with FX baked; plugins are greyed-out.
2013/12/14 03:11:54
Bristol_Jonesey
It's definitely not Span that's causing cpu problems - it's extremely lightweight
 
How about providing us with your system specs, including interface/driver/driver settings
2013/12/14 03:51:07
grizwalter
Hey Bristol. I was only kidding about the SPAN thing to illustrate that I couldn't for the life of me figure why my system would go to last gasps so quickly, AFTER freezing all those tracks, when really after that really all I added was SPAN and maybe one other plug-in.
 
My system is pretty standard. Runs mostly everything fine, but isn't breaking any records:
Windows 7 64-bit
Athlon Duo-Core 5500
Interface is an ART Dual Pre
Running ASIO driver mode in X3 Studio
24-bit depth (64-bit double precision engine disabled), 96K sampling
 
Does that cover it well enough?
 
2013/12/14 05:30:40
maltastudio
Yes like bitflipper said when you`re freezing your adding more audio files to the hardisk and i think that`s your problem.Your disk data rate is not enough for some reason.Just a guess.
Peace
2013/12/14 06:28:07
equality
It supprises me that your able yo play a project with 48 tracks but not freezing the individually. If fx:s and synths are included, would freeze the tracks with the least load i e the tracks with minimum of fx:s and the ones with the 'lightest' synths. Don't start with Alicia Keyes for instance. With that done, you have freed memory (RAM?) enough to manage freezing the heavier tracks.
2013/12/14 08:19:09
grizwalter
Ok, well this is all very interesting stuff, and I greatly appreciate the help. I'm still, I must confess, a bit shocked that freezing tracks can in any way have a negative performance impact, but I'm very glad I posted, thus avoiding future calamities.
 
With that said, I got to thinking about the disk load issue that seems to be at the root of things with my issue after freezing perfectly good audio tracks. I read somewhere once that one should keep their vst and other project/audio files on a separate hard drive  when working with DAWs, but I never heeded that little tid-bit much. Now I'm wondering--would that be a good idea? If adding files to the hard drive can slow things down, is there any legitimacy to the concept of a separate location (either a separate drive or possibly a partition)?
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account