Freezing tracks doesn't do what I think it is supposed to?

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.

I was also under the impression that freezing a track freezed the effects in the state they were in to lessen the load.

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

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

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)?

Well - to address the disk load issues:  are you seeing a difference in the disk load between frozen and not?  What are those levels?  Are you sitting at 10% usage or 90%?  You are generally right that freezing tracks should help not hurt.  In the case of a plain old audio track without fx, I would expect a neutral result since the old track is effectively archived so as to not use any disk resources and the new one is using them in its place.  In the case of freezing fx, you should be seeing less cpu - unless you were on the brink of disk usage overage to begin with and somehow your disk controller is causing the cpu to spike with the extra load.  It sounds unlilkely, but you are obviously seeing a problem, so it has to be something.
 
Have you tried freezing one of those tracks at a time and seeing if there is any one of them that is pushing the CPU up that much or if it's just a little at a time as you add tracks?
 
As far as separating disk storage, it's a good idea in general to have the OS/programs on one physical disk and your project files on a different one so that different read heads are in use for project/wav loading and system files, swap (if there is any), etc.
 
Hope this helps.
 

scook
Try a lower sample rate. Your experiment @ 96K is not going well.

+1! 96KHz doubles the amount of data being read from and written to the disk drive, requiring double the bandwidth and making your 48-track project look like a 96-track project to the hard drives. Adding another drive and dedicating it exclusively to audio files will definitely improve I/O performance and might even make the higher sample rate practical, but switching to a lower sample rate is something you can do right now - for free.

The amount of RAM you have is another contributing factor. Four gigabytes just isn't enough for the size of project you're working on. Sixteen is (and anyone else can correct me if I'm wrong) pretty much the minimum for RAM if you want peace of mind while recording/mixing. With only four, Windows may be employing your swap file and that puts an extra load on your hard drive.
 
As for using more than one hard drive, it won't help much (if any) in your particular case. It's the fact that you're running out of RAM that's the biggest problem. I've read on this forum that some people are using only one hard drive and getting up to 160 tracks to playback flawlessly. I'm guessing those same people also have at least 16 gbs of RAM, maybe even 32.
 
So, if you're planning/thinking of throwing money at this problem, I'd suggest buying RAM, even if you have to toss/sell/whatever four one-gig sticks and buy four four-gig sticks.

Actually, 4GB is plenty for 44 tracks of audio. The insufficient-RAM theory would hold true only if the tracks in question were mostly samplers, which the OP has not said is the case. Even if it were, freezing those tracks would free up the RAM used by the sample libraries and sampler, reducing not only CPU usage but RAM usage as well. Disk I/O, however, might be either unchanged or increased.

What are you disk bit depths set to (found under Preferences > File - Audio Data)?
 
Having a setting that is too high adds additional I/O but offers no benefits.
 
Set the Record bit depth to no higher that 24 and the Render bit depth to no higher than 32.

I agree with Bitflipper (again!)
 
I've run a 75 track project in XP32 with only 4Gb of RAM and this played back effortlessly, with at least a hundred plugins, multiple unbounced V-Vocal clips and about a dozen or so soft synths.
 
I think your problem is elsewhere.

grizwalter
PS: Kinda curious on this issue, btw. 24 bit, 48K I'm told is really where one wants to be, eventually down to 16-bit, 44.1K for CD. Degredation can occur, I understand, but wondering realistically why anyone would need to go much higher than 24/24 frankly, 48K - 60ishK?

It's a little bit complicated and there is some controversy here.
 
As a playback medium:
 
Theoretically, in the modern world 44.1 is good enough. And with modern sample rate conversion (SRC) - and Sonar's is very good - converting between sample rates is transparent to the listener. In the real world, the higher frequencies available at higher sampling rates are unlikely to be audible or desirable - unless you are producing very high level, high frequency pure sine waves for young people playing things back through a system that can cleanly reproduce such frequencies. Double blind tests where sample rate changes down to 44.1kHz were introduced to the audio have resulted in people not being able to tell the difference.
 
HOWEVER, it has been stated that at least some digital to analog converters perform differently at different sample rates. This is most likely due to the specific design of the DAC rather than the sample rate alone. And note that you only have control over your own DAC, not other listeners.
 
 
For processing inside the DAW:
 
Some types of processing benefit from being done at higher sampling rates. In many cases, particularly for more modern plugins, the process is oversampled internally where desirable or necessary.
 
You can also achieve lower latency with a DAW using a higher sampling rate.
 
_________________________________________________________________
 
I would say that in the real world, the questions regarding degradation come down to not whether something is theoretically better, but whether the differences are audible.

If you run Sonar at 48 or 96kHz (or whatever) and want 44.1 kHz output then you need to do a SRC. That's all. 
 
Especially many years ago, SRC quality was a much bigger issue than it is today (and until recently - version 10? - Sound Forge's SRC still wasn't very good, but it is today). This leads some people to still be wary of doing SRC's, but Sonar's SRC is excellent and really is not something you need to worry about.

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.

Cool! Did not know! FYI, he means right-click the FREEZE button, go to OPTIONS and check/uncheck the TRACK FX box.