Protect reads to SampleBuffer with read locks

[jasp00]

This fixes #2833.

[Umcaruje]

I don't think something like this can be accepted to the code base, since we want RT-safety in the core, and avoid adding any more locks. Please read up #1744 #1747 for a PR that was rejected and then redone in an RT-safe way.

[tresf]

If my vote counts, Stability > RT but I'm interested in seeing this conversation mature as I'm not an expert on the topic.

[jasp00]

SampleBuffer already relies on read and write locks, see SampleBuffer::play. The proposed fix is in line with the current implementation.
If lockless operation is desired, SampleBuffer should work like the mixer deleting tracks in #2822. Adding notes, handling MIDI events, loading settings, etc. should work like that: signal the mixer and wait until changes in the model are allowed.

[Spekular]

@jasp00

already relies on read and write locks

This might be true, but

[we want to] avoid adding any more locks

[jasp00]

So, should I change the current operation of SampleBuffer and remove present locks?

[jasp00]

I have removed some locks, some more could be removed. Besides fixing #2833, some freezing introduced with #2822 is fixed. I will merge this soon (less than 24 hours), since projects cannot be loaded in the master branch.

[grejppi]

(Sorry for the noise; that was my phone thinking I pressed something instead of scrolling)