2012/06/13 10:29:16
g_randybrown
40 seconds of 2 tracks (one audio and one Real LPC VSTi) rendering out from 24/48 to 16/44 with triangular dithering takes almost 1 minute. As you can see by my specs below I'm not lacking in horsepower and in fact only 3-7 % cpu is used during the process (according to task manager).
What is this speed (or lack thereof) dependent on in X1...HD video with color correction and other fx rendered out in my NLE would take less than 20 seconds...but then it's using all cores and at about 90%.
Thanks very much,
Randy
2012/06/13 11:05:15
peregrine
Your audio is on your hard drive, not in memory, so your cpu is not the limiting factor. It has to do with how SONAR architects the processing of I/O coming from and going to your hard drive. I didn't get the calculator out,  but the amount of data you're working with is up in the tens of millions of bytes. It takes a while. Are your audio files on the SSD or one of your other HDDs? You might try moving the audio to the SSD and see if that lets your cpu work closer to its max capacity. If there's no difference, you might want to drop a formal request to improve efficiency into the development hopper, although I'm not sure they would try to change system architecture to save all of us 30-40 seconds.
Have a good day.
2012/06/13 11:29:45
MondoArt
I had a similar symptom a while back, but the solution may not apply.  I had used audiosnap on a few clips and didn't render the clips down before exporting, so Sonar had to re-do the audiosnap processing every time I exported the project, making the process very slow.  Once I bounced down the audiosnap'd clips, exporting sped up again.

I think the same thing applies to v-vocal clips.

Good luck!
2012/06/13 11:33:06
g_randybrown
Your audio is on your hard drive, not in memory, so your cpu is not the limiting factor. 
I don't recall even mentioning memory but okay... and obviously I don't think the limitation is on the cpu since I mentioned it's showing less than 7%


I didn't get the calculator out,  but the amount of data you're working with is up in the tens of millions of bytes. It takes a while. 


It's one short audio track and one soft synth, it doesn't seem like it should "take a while" to me.

Are your audio files on the SSD or one of your other HDDs? You might try moving the audio to the SSD and see if that lets your cpu work closer to its max capacity. 
If there's no difference, you might want to drop a formal request to improve efficiency into the development hopper, 


I'll keep that in mind

although I'm not sure they would try to change system architecture to save all of us 30-40 seconds. 


Well this must be due to something else because if people were having to wait this long (relatively speaking) for a full song with a lot of audio tracks it would be taking hours...and I would think CW would want and have had to change the architecture to have the CPU take the load.


Have a good day.



you too
2012/06/13 11:37:19
g_randybrown
MondoArt


I had a similar symptom a while back, but the solution may not apply.  I had used audiosnap on a few clips and didn't render the clips down before exporting, so Sonar had to re-do the audiosnap processing every time I exported the project, making the process very slow.  Once I bounced down the audiosnap'd clips, exporting sped up again.

I think the same thing applies to v-vocal clips.

Good luck!
Thanks very much MondoArt...come to think of it I did have some reverb and compression on the audio track but it seems like that task would be directed to the cpu.

Thanks again,
Randy
2012/06/13 11:57:45
FastBikerBoy
Randy

Have you already changed the BounceBufSizeMsec found in Preferences-->Audio-->Configuration File?

It is at 0 by default and will use your audio interface buffer settings. Changing it to 100 may well help with slow bouncing.

HTH

Karl
2012/06/13 14:32:10
Bristol_Jonesey
How long does it take if you do a real time bounce?
2012/06/13 14:51:35
peregrine
I thought Karl might be on to something, so I bounced a 4:46 audio clip with a mastering effects chain with param values of 0 and 100.
At the 0 default value, the file processed in 43 seconds. With the value set at 100 it processed in 39 seconds. Not quite enough of an improvement to sneak out for a latte but it did make a measurable difference. I also ran the same file and fx chain in Cubase and got a time only a few seconds less than either of the above, so it appears to be a single thread process there as well. There's probably some streamlining CW could do to take advantage of multi-core processing. Or maybe someone else will come up with a magic bullet.
2012/06/13 15:07:21
pwal
hi, wrt multi-core processing the core spread is done in some hosts (dunno about sonar, but certainly in live and i think s1) on a per-channel/track basis, so if you have many tracks with plugs you will get better cpu usage than, say, a single "mastering" track with many cpu-expensive plugs, hth
2012/06/14 12:49:22
g_randybrown
Sorry it took so long ...so I was going to test Karl's suggestion but wanted to render it out again and time it exactly to see what kind of improvement I got after doing the buffer tweak...I got my timer ready and hit export and it took maybe 3 seconds. I checked the file to see if all the data was there...it was...I went to the file I rendered yesterday that took so long and it was the same...I dunno...I reckon I'll chalk it up as user error or just computer weirdness.
Anyway, I applied the tweak and rendered again and it was like 2 seconds so I'll just leave it there.
Thanks very much everyone,
Randy
12
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account