Fix RubberBand segafult when changing audio setting

[acolombier]

Fix a bug introduced by #13143 which would lead to segfault when updating the audio output setting (eg. sample rate, buffer length)

This solution is not ideal as it will simply ensure that the main thread does't free the stretcher while the engine thread is still processing, but the other rubberband instance will still be swapped, leading to the swapped stem channel to be offset-ed by one, and creating a weird desync.

I cannot found of a solution without introducing some heavy locking, which is a big no-go for the realtime thread.

Just to summarise the problem

• Edit the audio setting
• Trigger sent on keylock_engine CO (main thread)
• Slot EngineBuffer::slotKeylockEngineChanged is ran on main thread and cycle the RubberBand wrappers with new instances using the correct settings

Mainwhile:

• RubberBandTask::waitReady is likely blocked on the engine thread, waiting for buffer scaling

Due to the realtime aspect, the engine thread doesn't have a QEventLoop which could have been useful to schedule to stretcher setup slot.

Happy to go with an alternative solution, if you have a suggestion!

[acolombier]

This appears to be a duplicate (see line 114)

[JoergAtGithub]

With this PR I get DEBUG ASSERT: "m_rubberBand.isValid()" in function double __cdecl EngineBufferScaleRubberBand::scaleBuffer(float *,__int64) at D:\mixxx\src\engine\bufferscalers\enginebufferscalerubberband.cpp:288 when I change the buffer size.

[acolombier]

@JoergAtGithub I believe you would also get the assert on main, can you confirm?

[JoergAtGithub]

@JoergAtGithub I believe you would also get the assert on main, can you confirm?

Indeed, this also occurs with main!

[acolombier]

I'm not sure how to go about this. In the one hand, this quick fix should prevent the crash, but doesn't address the fundamental issue of RubberBand being recreated from another thread. I feel like we should probably get this fix in to mitigate the issue, and decide one what is going to be the approach to add some synchronisation with the audio engine thread

[JoergAtGithub]

If we change these settings, we will have a audio interruption/glitch anyway. Why not stop all these threads and restart them with the new parameters?

[acolombier]

I have tried another fix, using your suggestion @JoergAtGithub . Seems to work well, without any locks! Let me know if it works for you

[JoergAtGithub]

This works without segfault or assert for me!

[Swiftb0y]

@acolombier can you squash the two commits once this is ready? The latter one essentially undos the first one so there is not much value in keeping it.