To Fast Bounce or not to... And geek questions

[winkpain]

These questions apply to a relatively modern PC setup with a quad-core 3.5gHz processor and at least 16g of RAM and a 64bit architecture. And my particular system is still on Windows 7...

I have read the corresponding info in the ref. manual (~ page 869 in the downloadable pdf ) on Fast Bounce. I have always simply assumed it appropriate to have FB chosen for bouncing/freezing operations, given a mix or track's status of not using any external processors or side chains. Is this the correct attitude to have? Are there other factors that may come into play even on a very simple mix or synth bounce/freeze operation that would make one want to prefer to not opt for a fast bounce?

Should final mixdowns always default to not using fast bounce to be "safe" ?? (I've only done this on large VST/synth/automation heavy projects)

 

AND, while we're at it (in case someone is feeling geeky-sharesy), what are the appropriate choices and pros and cons for:

 

1. choosing/not choosing 64bit "double precision" engine in Preferences/Audio/Driver Settings and or bouncing/exporting settings
2. choosing/not choosing MMCSS in Preferences/Audio/Playback and Recording
3. setting the correct Thread Scheduling setting (per the latest release)
4. setting Multiprocessing engine and load balancing
5. choosing the various dithering options
6. does the setting of any of the above affect the preferences for any of the others?

My approach has always been to choose the best or highest versions of any of these, in other words a choice for rather than against in binary choices and the "best" version of any multiple choice. Unless noticing a detriment, is this the correct way to approach it?

These questions are for any info over and above the provided reference info, which is not always thorough enough for those of us who are mere musicians before we are computer techs! ?

 

 

 

Edited March 4, 2020 by winkpain

[dcumpian]

Generally speaking, if Fast Bounce is going to have a problem, it's going to be with a plugin that doesn't support it. Most do. You'll know when it happens because there is usually really weird stuff that happens, especially if you are still using active VSTi's when you mixdown.

Here is my understanding of your numbered points:

1. 64bit precision is not necessary, but it shouldn't hurt anything either. There is no audible difference that I've ever found.
2. MMCSS gives Sonar higher CPU priority. Should have minimal effect during mixdowns, but is useful while tracking.
3. Yes, set it to whatever gives you the best results. Every system is different.
4. Yes
5. I don't use dithering until I am rendering the final mixdown to 16/44.1, and I usually do it in the last plugin in the signal chain rather than at the app level. You only use dithering when down-converting, like if you record at 24/48 and want a CD mixdown, which is 16/44.1
6. Not that I am aware of.

Regards,

Dan

 

[winkpain]

1 hour ago, dcumpian said:

Generally speaking, if Fast Bounce is going to have a problem, it's going to be with a plugin that doesn't support it. Most do. You'll know when it happens because there is usually really weird stuff that happens, especially if you are still using active VSTi's when you mixdown.

Here is my understanding of your numbered points:

1. 64bit precision is not necessary, but it shouldn't hurt anything either. There is no audible difference that I've ever found.
2. MMCSS gives Sonar higher CPU priority. Should have minimal effect during mixdowns, but is useful while tracking.
3. Yes, set it to whatever gives you the best results. Every system is different.
4. Yes
5. I don't use dithering until I am rendering the final mixdown to 16/44.1, and I usually do it in the last plugin in the signal chain rather than at the app level. You only use dithering when down-converting, like if you record at 24/48 and want a CD mixdown, which is 16/44.1
6. Not that I am aware of.

Regards,

Dan

 

Thanks for this response, @dcumpian !

These points match well with my findings and intuitions. I have indeed had issues with Fast Bounce and some VSTi's, notably Kontakt loaded with intensive sample libraries. I wonder, when you mention those VST's that don't "support" Fast Bounce, is this an aspect that is made explicit ever, or is it simply a fact to be discovered by rote and usage?

And I'm still a bit curious about the MMCSS setting and the current CbB architecture either on Win7 or if upgrading to Win10. I do remember reading somewhere about the wisdom of turning this to off for some reason, but can't now remember why or where I read it...

 

 

 

 

[David Baay]

As Dan mentioned, when a plugin has issues with Fast Bounce, it's usually not subtle at all, but it can be hard to know which plugin is having an issue when rendering a whole mix if you haven't been freezing/bouncing along the way.

Some plugins only have trouble when bouncing with a very small buffer size. By default, the current buffer size for real-time playback is used for offline (fast bounce) rendering. You can avoid problems related to rendering with a small buffer by setti a non-zero value for BounceBufSizeMsec in AUD.INI (Preferences > Audio > Configuration File). Values up to 200ms are reasonable, and may actually speed up rendering in some cases. I've had mine set at 20ms for a long time after discovering that Rapture had trouble with buffers under about 4ms.

Note, also, that some synths have a special 'offline rendering' mode that has to be enabled. This applies especially to VSTis that stream directly from disk.

[winkpain]

2 hours ago, David Baay said:

As Dan mentioned, when a plugin has issues with Fast Bounce, it's usually not subtle at all, but it can be hard to know which plugin is having an issue when rendering a whole mix if you haven't been freezing/bouncing along the way.

Some plugins only have trouble when bouncing with a very small buffer size. By default, the current buffer size for real-time playback is used for offline (fast bounce) rendering. You can avoid problems related to rendering with a small buffer by setti a non-zero value for BounceBufSizeMsec in AUD.INI (Preferences > Audio > Configuration File). Values up to 200ms are reasonable, and may actually speed up rendering in some cases. I've had mine set at 20ms for a long time after discovering that Rapture had trouble with buffers under about 4ms.

Note, also, that some synths have a special 'offline rendering' mode that has to be enabled. This applies especially to VSTis that stream directly from disk.

Thanks so much @David Baay

The playback buffer you speak of is, of course, the  buffer set on my ASIO panel under Mixing Latency in Preferences/Audio/Driver Settings.  I was not aware that this also was the default for the fast bounce buffer. So if I were to change that to a higher setting, as I frequently do after recording in real time (when mixing and working with synths/FX), this higher setting would also affect the Fast Bounce buffer? And otherwise, if I change the BounceBufSizeMsec entry as you mention it will default to this higher buffer no matter what I have set on my ASIO panel. Is this correct?

 

[winkpain]

...Thanks again @David Baay

I got my further answer by reading the dang reference page. Imagine that!
On the BounceBufSizeMsec setting in AUD.INI  it says like you said:

Quote

 

This is a line in the Wave section of the Aud.ini file that sets the buffer size for bouncing tracks. At a value of 0, the bounce buffer is the same size as the Mixing Latency value that you set in Edit > Preferences > Audio - Driver Settings. If you find that bouncing tracks, especially with certain soft synths, takes a very long time, you can set this value to 100, or some value between 0 and 350 so that the bounce buffer will use a more efficient size for bouncing, which has different requirements from normal playback latency.

Note: on larger projects, setting this variable to a large value can cause out-of-memory errors.

 

But thanks for leading me to it.

Always read the reference material ! 

(It's just so informative -and fun- to chat with you all !)

[David Baay]

Glad to help. I have no problem with people coming here first, or maybe after a quick search that didn't get them everything they needed to know.