Separate pitch bending processes/threads per deck

[PatrickJosh]

Feature Description

Hi,

I've noticed that all pitch bending happens in the same process for all decks – at least that's what I deducted from my htop readings when enabling/disabling pitch bending/keylock. Please correct me on that if that's not the case.

In case it is correct, I'd like to propose creating different threads or processes for pitch bending the different decks since it seems to be the bottleneck for lowering my audio latency even further than it currently is (at least with Rubberband R3). I hope that this would cause lower latency spikes when starting/stopping a deck or using a hotcue since I do sometimes have audio drop-outs in these cases.

I don't know if that is even feasible or sensible or if it has some side effects that I don't see at the moment, so feel free to correct me on that.

Thanks!

[PatrickJosh]

I've just tried processing stereo with separate threads using the option provided in the settings, and this definitely reduced the number of audio drop-outs that I have. In case of applying this to the different decks (but processing the stereo channels together due to the issues explained in the warning when enabling stereo multithreading), this should improve performance similarly. Could the infrastructure for the stereo multithreading be used for that, without major changes?

[acolombier]

Hi @PatrickJosh , you might want to have a look at some of the conversation in #13143 - there was discussion around some engine rework to allow multi threading across channels, mostly starting from here.
The main thing to be aware of the real-time requirement here, meaning the need to rely synchronization mechanism that have consistent performance (atomic ops instead of mutex for example)