CPU usage overload peak when triggering Hotque's on 5.33 ms setting on 2.3 Ghz i7 quadcore OS X Mojave

[Tommy-Rutting]

Bug Description

When i trigger a hotque on opposite deck it creates a CPU spike on it's own deck and is audible on the other deck. I'm using Rubberband R3, when both tracks are playing CPU is at 40%, when using hotque or moving the platter then there is major CPU spiking. When doing it quick it extremly drops the tempo/processing on the other deck. Running Traktor and or Serato DJ with keylock and same latency runs perfectly on same machine Quadcore 2.3 Ghz i7 on Mojave. I also have Quadcore i7 2,6 Ghz on Catalina that is even worse. renice did not solve it etc. Problem is on internal audio and Traktor Audio 6 interface. Is R3 Rubberband usable, Rubberband is to low-fi?

Update 21.3 ms is the max i can get out of R3, that's unusable for live scratching and quick mixing.

Version

2.4

OS

macOS Mojave 10.14.5 Quadcore i7 2.3 Ghz

[ronso0]

Yes, R3 is demanding. You may check if this is a general issue or if you can avoid it with increased latency.

and is audible on the other deck.

buffer underruns mean Mixxx couldn't process the Main mix (or parts of it) in time, so they'll always be audible no matter the origin.

[Tommy-Rutting]

21.3 ms is the max i can get out of R3, that's unusable for live scratching and quick mixing. I like Mixxx (respect for the developers!), but i need around 5 ms latency for live performances.

I'm professional DJ using Serato Dj from 2005 on and want to switch to Mixxx.

Hope you will get it optimized/fixed.

[ronso0]

You don't like how R2 sounds?

[Tommy-Rutting]

Correction, sorry, i thought you where talking about V1 Rubberband. I don't get the option for R2 in settings only R3 on OS X Catalina and Mojave on a i7 quadcore 2.6 and 2.3 Ghz. On my Linux i7 maschine there is no option for R2 or R3. Are given options limited by hardware/CPU?

[daschuer]

When seeking through the track, we fade the new buffer into the old buffer and we need to settle of Rubber band with the samples form the new stream. This is to avoid clicks, but it requires also a momentary double CPU time. I your case we hunt one issue with another.

We may discuss other solutions, like fading to silence and than fade into the new buffer form silence.

[Tommy-Rutting]

Thanks for explaining the chosen process, it sounds like a non usable solution for R3 and probably the other algoritms that are less CPU intensive but not noticable. Just saying maybe it's a stupid thought, can't you do something with zero crossing editing the buffer.

[daschuer]

Without crossing we need to fade out and in to avoid clicks. This will be notable as a small loudness drop. We may mix the old buffer back to back which will introduce a click sound.

A solution that does the crossfader on the unstreched audio would help, but this will introduce a notable delay, because the Rubber and buffers are already filled with the sound stream without the jump.

Another issue is the way underflows are handled. If it happens the old buffer is played twice, and then the missed buffer is processed. It would be much better if the missed buffer is shipped. This will avoid that the crowd also talks out of rhythm.