What interface are you using? This usually down to usb not being isolated. Try different USB ports to see if it makes a difference. Other options are a usb card with isolated sockets or a usb isolater
Interestingly, the zippering is not present in exported audio when the fader changes are written as automation. On one hand, this might be considered a good thing. But on the other hand, whenever the rendered audio differs from what is monitored live, it is potentially very problematic, as it appears there is a different smoothing policy used live than when rendering.
The results are: the realtime export does exhibit the zippering, while the non-realtime does not. Here are some aligned spectrograms. The top is non-realtime and the bottom is realtime. You can clearly see the zippering in the realtime case.
Since changing the gain via other means (such as from within the TestGenerator plugin) does not exhibit the behavior, and it never occurs with a steady sine tone, it can’t really be a hardware issue. The zippering is only when changing gain with the Cubase mixer faders. Also, the fact that I do not hear the zippering when playing back the non-realtime exported audio must mean that the hardware is capable of outputting the audio correctly. Lastly, my audio interface is Thunderbolt and the analog IO is via optical ADAT, so USB noise is not a consideration. Not to mention that any kind of noise in the audio path that was hardware induced would be present at other times, not just when I happen to move the faders. Indeed, there is no analog involvement even when exporting realtime.
It seems pretty clear that Cubase, for whatever reason, is applying a different smoothing policy for fader changes that are realtime. Perhaps as an optimization for realtime performance, or perhaps it’s a bug.
Yes. This happens even if the sine tone source is an imported file, for example.
The issue occurs independent of hardware settings.
No.
To be clear, this is not an analog audio path noise issue. No audio is being captured from the audio interface (even in realtime export.) There is no issue playing any source audio. The only issue is while changing gain with moderate to fast velocity via the Cubase mixer faders.
“Smoothing policy” is something of your own invention. 32-bit floating has more dynamic range than any analog fader. No smoothing is needed.
If you are unwilling to even consider the debugging advice of others because you’ve decided in advance what your problem cannot be, you are likely to suffer from the problem longer than need be.
Can you post a copy of a Project exhibiting this behavior?
Gain ramp smoothing is definitely not something I’ve invented, it’s basic DSP. It’s needed since the UI events (e.g. the mouse, MIDI from MCU Pro, etc.) occur at a much slower rate than the audio sample rate. If no interpolation (smoothing) were applied to the UI events representing the “ramp”, then the gain would change in a quantized (i.e. stair-stepped) manner with respect to the audio sample rate. The result of that is undesired modulation. Therefore, the changes to gain must be interpolated such that the gain change is applied incrementally across all samples for the span of the ramp. There are many ways to do this interpolation. This is the smoothing policy. The sample format is irrelevant. Here is a link to a basic tutorial from Juce, although the issue is certainly not specific to Juce. See the section “Smoothing gain changes”, or the source for Juce’s juce::AudioSampleBuffer::applyGainRamp() for a C++ example (again, this is just an example from Juce).
Yet another way to think of it is that the quantized UI event ramp is essentially being convolved (in the frequency domain) with the source audio signal. Without interpolation, the time series of the ramp would have “corners” when converted to audio sample rate. The resultant convoltion operation would include all of the high frequencies of those “corners”. So the corners are smoothed away by essentially applying a low pass filter to the stepped ramp. This is the smoothing.
Here is a project that exhibit’s the behavior. zipper_noise.cpr (323.0 KB)
Is this the result of a realtime export? I’m guessing yes, because I can see the zippering in your file in the spectrogram (although it’s quieter than my realtime export.)
The top spectrogram below is from your file, and the bottom I generated from a non-realtime export (zero zippering).
The file you posted appears to be 44.1k, but the project is 48k. Some conversion has been made somewhere along the way here, so not quite an apples-to-apples.
No, not realtime. But it sounds the same as playing back realtime within Cubase.
11.0.41 & PC.
What exactly do you mean by zipper? I’ve been assuming you mean a non-smooth change of volume levels, but you seem to be looking at overtones or something else maybe…? Sorry at this point I don’t understand what you want to be fixed.
