• SONAR
  • Freezing tracks doesn't do what I think it is supposed to? (p.2)
2013/12/14 08:30:23
Paul P
grizwalter
 
My system is pretty standard. Runs mostly everything fine, but isn't breaking any records:
Windows 7 64-bit
Athlon Duo-Core 5500

 
How much ram do you have ?   Free disk space ?  Defragged ?
 
 
2013/12/14 08:59:03
Blades
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.
 
2013/12/14 09:36:04
scook
Try a lower sample rate. Your experiment @ 96K is not going well.
2013/12/14 12:05:08
bitflipper
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.
2013/12/14 19:10:43
grizwalter
Paul P
grizwalter
 
My system is pretty standard. Runs mostly everything fine, but isn't breaking any records:
Windows 7 64-bit
Athlon Duo-Core 5500

 
How much ram do you have ?   Free disk space ?  Defragged ?



4 GB RAM. 100 GB free space (I'm constantly moving things back and forth to a backup driver, but that's my general working range. If I get down to 60GB I generally take stuff off the main driver to get her back up to 100. I defrag pretty regularly, at a minimum once a month, but usually more often. Fact is, I have my system set to do it automatically, but since my computer on/off is pretty random and I don't think about it, I do a manual one at least that often.
2013/12/15 07:30:06
rontarrant
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.
2013/12/15 10:45:16
maltastudio
Yes for those kind of projects you need alot of ram and an ssd.
Peace
2013/12/15 11:43:13
bitflipper
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.
2013/12/15 12:30:56
grizwalter
Rontarrant and bitflipper, thank you both for the responses.
 
While I think both sides of any RAM debate could have valid points, my first thought after reading your reply Ron (I read yours first ) was something flipper said as well--how much RAM I have, even if it was an issue, wouldn't explain why the hang-ups would only show up AFTER freezing the tracks, which is where my confusion rests. Sure, my computer is being pushed a bit with this one, but overall, it plays through and I don't have too many problems. That is, until freezing tracks. There are simple solutions I could employ, like doing a drum and bass bounce for the purpose of mixing in vocals (other benefits to this include not effing with stuff too much! lol), but primarily I was just wondering why this phenomenon was occurring.
 
Also, it should be noted that the biggest/largest amount of tracks mix I've done is 66 tracks, and that was using Reaper (before I had X3, I'd use that for mixing only and when tracks exceeded my limitation of 32), and had no problems whatsoever, using the same driver setup, and without ever freezing anything.
 
Maltastudio, what is ssd? For whatever reason, that is escaping me right now, even though I absolutely know what it is somewhere in my wandering brain, and when you tell me I'm going to say, "duh!"
2013/12/15 13:38:32
drewfx1
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.
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account