I assume you "buffer indicator" the the "Audio Latency Usage Meter".
By the selected Audio Buffer in hardware preferences, you define the 100 % lets say 23 ms.
For a non crackling sound, Mixxx has to process chunks of 23 ms samples in time < 23 ms.
If it takes 11 ms the "Audio Latency Usage Meter" is at 50 %. If it takes 24 ms, one chunk is skipped.
I guess you use a non SSE build. I had exactly the same issues on Linux.
You should use at least
scons optimize=portable
or just
scons
Even if a Deck is paused the silence stream is processed. If the samples are not exactly 0 but near, the CPU uses a lot of extra cycles to still produce scientific exact results. https://en.wikipedia.org/wiki/Denormal_number
I assume you "buffer indicator" the the "Audio Latency Usage Meter".
By the selected Audio Buffer in hardware preferences, you define the 100 % lets say 23 ms.
For a non crackling sound, Mixxx has to process chunks of 23 ms samples in time < 23 ms.
If it takes 11 ms the "Audio Latency Usage Meter" is at 50 %. If it takes 24 ms, one chunk is skipped.
I guess you use a non SSE build. I had exactly the same issues on Linux.
You should use at least
scons optimize=portable
or just
scons
Even if a Deck is paused the silence stream is processed. If the samples are not exactly 0 but near, the CPU uses a lot of extra cycles to still produce scientific exact results. /en.wikipedia. org/wiki/ Denormal_ number
https:/
We have to bes sure that the de-normals are treated as 0, to prevent this issue on Windows as well. /github. com/mixxxdj/ mixxx/blob/ 3f854c167408460 9497036ba92e160 5a43fb492f/ src/sounddevice portaudio. cpp#L772
This should happen here
https:/
do you see the
"SSE: Enabling denormals to zero mode"
log message?