Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace all buffer-sized fades and smoothing with constant time smoothing #11253

Open
robbert-vdh opened this issue Feb 6, 2023 · 1 comment

Comments

@robbert-vdh
Copy link
Contributor

Feature Description

This is more of a long term change that would require lots of changes within Mixxx, but I think it would be good to at some point change the way values are smoothed within Mixxx. The way many value changes are smoothed right now is fundamentally flawed as they get smoothed either over the course of a single audio buffer (applies to most things) or over a fixed number of buffers (applies to the jog wheel smoothing). Smoothing is used here to avoid zipper noises and clicks caused by discontinuous values being used for certain parameters, but implementing the smoothing as a function of the audio buffer's length is not a correct solution.

Take gain smoothing for instance. At a sample rate of 48 kHz, Mixxx's minimum buffer size becomes 64 samples. At this setting gain changes are smoothed over the course of 1.334 ms, which may not be enough to avoid zipper noises. Meanwhile if the buffer size is set to 1024 samples, the smoothing takes over 21 ms which makes gain changes sound very unresponsive (ignoring the elephant in the room that is the input latency you'd get at that buffer size). Replacing all buffer-sized fades with constant time smoothing would get rid of the differences in sound when changing between buffer sizes. This can be achieved with an interface similar to this: https://github.com/robbert-vdh/nih-plug/blob/master/src/params/smoothing.rs (from my Rust plugin framework project) The smoothing can be done linearly (which is good for most controls), logarithmically (which is good for frequency and linear gain controls where the underlying domain is logarithmic and that never reach 0), or exponentially (which is good for things like the jog control object where immediacy is important), all over a fixed amount of time.

Once this is resolved it will also become easier to split the audio processing up into smaller blocks so things like playback rate smoothing can be done more gradually regardless of buffer size.

@daschuer
Copy link
Member

daschuer commented Feb 7, 2023

This will also fix the sharp scratching issue #8899

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants