Reason 11 Export Audible Crackling

[NMN]

I've had this issue on two separate laptops. Any time that I export a somewhat complex song, I get audible crackling in random places in the final .WAV export. I've confirmed that the noise is definitely part of the .WAV file. Both laptops are i7s running Windows 10 with 12-16 gigs of RAM. I can tolerate this at times during playback in the DAW when the DSP meter maxes out once in a while, but not in the final export.

To solve this, I have to go to Edit->Preferences->Audio and uncheck both "Use multi-core audio rendering" and "Use hyper-threading audio rendering" to get a good export without crackling. However, this slows down the export process significantly. Has anyone else had this issue?

[jam-s]

Imho "Use hyper-threading audio rendering" is the most likely culprit. There might be some bug in the thread scheduler which might lead to batches of processed samples to be combined out of order. In general hyper-threading (=simulating some fake cores) is not useful for any audio processing as the additional context switches just add overhead.

[Loque]

It could be related to the buffer size and buffer-size-rendering option. This can cause problems in some situations, especially with VSTs. Try to flip this setting or experiment with the buffer size.

[MrFigg]

It could be related to the buffer size and buffer-size-rendering option. This can cause problems in some situations, especially with VSTs. Try to flip this setting or experiment with the buffer size.

This

[NMN]

Thanks for the responses. I have the sample rate set to 48000 and the buffer set to 192, so it's not extremely low. It can go as low as 16 but 192 gives me 8ms of output latency which is basically undetectable to me. If I set the buffer higher than this, the latency starts to be audibly detectable while playing a MIDI keyboard. Also, switching the buffer sizes back and forth on this sound card can cause blue screens.

So either way, I currently have to change a setting (either buffer or CPU) before export.

[ScuzzyEye]

Thanks for the responses. I have the sample rate set to 48000 and the buffer set to 192, so it's not extremely low. It can go as low as 16 but 192 gives me 8ms of output latency which is basically undetectable to me. If I set the buffer higher than this, the latency starts to be audibly detectable while playing a MIDI keyboard. Also, switching the buffer sizes back and forth on this sound card can cause blue screens.

So either way, I currently have to change a setting (either buffer or CPU) before export.

192 is a not great number for computers. You should stick to powers of 2, so buffers will be easier to align, and many algorithms are able to run optimally. So, either go down to 128, or up to 256.

I've also found that Reason has the least problems at 64 samples, which it used to be hard coded to, but it does require quite a lot of CPU power to work in real time that way. What I wish is that Reason had an "off line" rendering mode. Where you could easily request a different buffer size for rendering vs. the you use when tracking.

[Loque]

Thanks for the responses. I have the sample rate set to 48000 and the buffer set to 192, so it's not extremely low. It can go as low as 16 but 192 gives me 8ms of output latency which is basically undetectable to me. If I set the buffer higher than this, the latency starts to be audibly detectable while playing a MIDI keyboard. Also, switching the buffer sizes back and forth on this sound card can cause blue screens.

So either way, I currently have to change a setting (either buffer or CPU) before export.

I just repeat myself:

It could be related to the buffer size and buffer-size-rendering option. This can cause problems in some situations, especially with VSTs. Try to flip this setting or experiment with the buffer size.

[NMN]

Thanks for the responses. I have the sample rate set to 48000 and the buffer set to 192, so it's not extremely low. It can go as low as 16 but 192 gives me 8ms of output latency which is basically undetectable to me. If I set the buffer higher than this, the latency starts to be audibly detectable while playing a MIDI keyboard. Also, switching the buffer sizes back and forth on this sound card can cause blue screens.

So either way, I currently have to change a setting (either buffer or CPU) before export.

192 is a not great number for computers. You should stick to powers of 2, so buffers will be easier to align, and many algorithms are able to run optimally. So, either go down to 128, or up to 256.

I've also found that Reason has the least problems at 64 samples, which it used to be hard coded to, but it does require quite a lot of CPU power to work in real time that way. What I wish is that Reason had an "off line" rendering mode. Where you could easily request a different buffer size for rendering vs. the you use when tracking.

Thanks for the responses, I have been trying 256 and 128 instead. Setting the buffer to 64 usually elevates the DSP meter into the red area unfortunately. I also tried to uncheck the Render audio using audio card buffer size setting checkbox. I am not sure what it does though. I sort of expected maybe a second buffer slider to appear for rendering if I unchecked that but it doesn't seem to change any of the options. I didn't like switching buffer sizes because I used to get blue screen errors if I did, but at some point a driver or software update must have fixed this, so I don't mind it as much now. I switch to 1024 for mixing and rendering and it seems to work better. I think I have a fast enough computer but I have a budget-level Focusrite, so that may be part of the problem too.

I guess my point is though is that during rendering-to-disk, it seems like there shouldn't be any reason why Reason couldn't slow itself down to compensate for any buffer glitches. It seems to be able to avoid the clicking and popping problem when only using one CPU.

[jam-s]

Make sure your power saving options are set to high performance. Otherwise the CPU clock will be reduced dynamically which can cause jumps in latency and thus buffer underruns.

[ScuzzyEye]

Thanks for the responses, I have been trying 256 and 128 instead. Setting the buffer to 64 usually elevates the DSP meter into the red area unfortunately. I also tried to uncheck the Render audio using audio card buffer size setting checkbox. I am not sure what it does though. I sort of expected maybe a second buffer slider to appear for rendering if I unchecked that but it doesn't seem to change any of the options. I didn't like switching buffer sizes because I used to get blue screen errors if I did, but at some point a driver or software update must have fixed this, so I don't mind it as much now. I switch to 1024 for mixing and rendering and it seems to work better. I think I have a fast enough computer but I have a budget-level Focusrite, so that may be part of the problem too.

I guess my point is though is that during rendering-to-disk, it seems like there shouldn't be any reason why Reason couldn't slow itself down to compensate for any buffer glitches. It seems to be able to avoid the clicking and popping problem when only using one CPU.

The render using audio card setting makes Reason pass a buffer of what ever size you've set above to VSTs, and also call a single RE multiple times in a row to fill up that buffer.

Maybe it'd be easier to describe how Reason worked before, or when that setting is off. Reason used to have an internal batch size of 64 samples. The audio interface buffer was only used to try to keep audio from dropping out during short DSP spikes. All the rendering work (both realtime and offline) was done in batches of 64 samples at a time.

With the way modern CPUs function the longer you can let them loop on one small bit of code the faster they can run. Or more precisely, asking the CPU to continually change to different bits of code hurts performance. VST plugins support many different buffer sizes. Most (especially those using FFTs) hit their peak performance at 512 samples and up. REs always work on batches of 64 samples at a time, but still, calling the same RE code a few times in a row to fill up that audio interface buffer (another reason to use powers of 2, because 64 will divide equally into any power of 2 that is 64 or greater) instead of calling different bits of code every 64 samples keep the CPU cache fresh.

So why would you not enable that setting? I've not verified for REs, but for sure with VSTs (at least version 2, it's no longer true for VST3) parameter changes only happen with each buffer batch. So if you're using 1024 sample buffers note-on/off events or automation changes only happen every 43ms. That's a noticeable amount of slack, and won't fall on the beat for most tempos. I run with huge buffers most of the time, because I don't do a lot of live recording, and the extra DSP headroom is nice. But I leave that setting off, which does lose a little the performance gain the big buffer allows, but it keeps the sequencer timing tight.

[NMN]

Thanks for the responses everyone. Here's what I've found so far:

• The performance bottleneck I have definitely seems to be the sound card. I found a utility to ensure max CPU turbo speed (no throttling) and at constant 75% CPU usage with a small buffer size (256 or less) there is significant stuttering during playback. This laptop has a solid state drive, Optane cache, plenty of RAM, and turbos at almost 4Ghz, so this tells me it's gotta be sound card and/or driver.

• I did confirm that the audible export crackling was rendered to the .wav file because I heard the crackling in the same spots on different devices during playback. I also can confirm that unchecking "Use multi-core audio rendering" and "Use hyper-threading audio rendering" fixed the problem at that time so I got into the habit of unchecking these options just in case.

• I could not recreate the issue with the current track that I am working on. I set the buffer to 64 and then to 192 and used multi-core/hyper-threading rendering and there was no audible crackling or popping in the exported .wav files. So it could be a flukey thing or dependent on a certain crappy VST or something. If I can recreate it again at some point I will try to narrow it down and update this thread.

• Thanks for the explanation ScuzzyEye of the Render audio using audio card buffer size setting option. It sort of makes sense to me. I can tell you that unchecking that option and then having a combination of a budget level sound card and using about a 25%:75% ratio of VSTs:REs for a Reason song makes smooth playback almost impossible, even at 1024 buffer size. I think this also further convinces me that the bottleneck is the sound card.

In summation, probably time to get a Thunderbolt card or something

[Ottostrom]

I also can confirm that unchecking "Use multi-core audio rendering" and "Use hyper-threading audio rendering" fixed the problem at that time so I got into the habit of unchecking these options just in case.

Thank you for pointing out this fix!
Been having a frustrating time today as I'm finally done with the mix for a particularly processor heavy project and couldn't get an export without random crackling throughout.
I completely understand getting these crackles while playing the song inside Reason since it has to do all the heavy work in real time but it feels very dumb that you get them in the export as well.