Race condition in arpeggio processing

[Fastigium]

For instruments that use both NotePlayHandles and an InstrumentPlayHandle (like LB302 and Sf2 Player), this code in InstrumentPlayHandle.h ensures that all NotePlayHandles are processed before the InstrumentPlayHandle. To do so, it just processes any unfinished NotePlayHandle jobs itself. This often results in NotePlayHandles being processed twice simultanously, wreaking havoc with the internal frame counters. This causes random note skipping in the second part of this test file by zonkmachine, and probably causes other strange behaviors as well. It may, for example, be the cause of #2565.

At any rate, it's something to fix. However, I'd like some opinions on how to fix it best. As far as I know, the mixer can't give any guarantees on order and overlapping when processing PlayHandles. Neither can a PlayHandle delay its execution and allow a different one to be processed instead. Therefore, I see the following solutions to this problem:

1. Implement PlayHandle dependency support in the mixer, allowing the InstrumentPlayHandle to depend on the corresponding NotePlayHandles. This seems like a lot of work and extra code to maintain to fix such a small issue, but it may come in handy for other PlayHandle types that have dependencies. If anyone knows other PlayHandles that could use it, please mention it.
2. Implement a yield mechanism, allowing threads to pause execution and return to the job queue, making room for a different thread. This would allow the InstrumentPlayHandle to yield when one or more of its NotePlayHandles are not finished yet. Probably easier/smaller to implement, if a bit less elegant.
3. Make the InstrumentPlayHandle busy-wait until the NotePlayHandles are ready. This wastes time and CPU cycles, but is ridiculously easy to implement.

Number 3 is a no-go as far as I'm concerned, but the choice between 1 and 2 depends on how many other uses 1 has or may have in the future. @LMMS/developers Feedback welcome! What do you think of the solutions? Do you know alternative solutions?

[Fastigium]

Credits go to @zonkmachine for uncovering this issue and suggesting the link with #2565!

[zonkmachine]

Closed #340 as a duplicate of this one.

[zonkmachine]

3. Make the InstrumentPlayHandle busy-wait until the NotePlayHandles are ready. This wastes time and CPU cycles, but is ridiculously easy to implement.

A simple fix would be good actually. Just for the sake of helping to trouble shoot the arpeggiator, so we can take this one out of the equation. I don't mean merging something that wastes unnecessary cpu cycles.

[PhysSong]

1. Implement PlayHandle dependency support in the mixer, allowing the InstrumentPlayHandle to depend on the corresponding NotePlayHandles. This seems like a lot of work and extra code to maintain to fix such a small issue, but it may come in handy for other PlayHandle types that have dependencies. If anyone knows other PlayHandles that could use it, please mention it.

Good idea. I think we may apply this for whole ThreadablJobs, including FX channels.

3. Make the InstrumentPlayHandle busy-wait until the NotePlayHandles are ready. This wastes time and CPU cycles, but is ridiculously easy to implement.

Looks not so good, but not too bad. Sounds better than double processing at least.

[zonkmachine]

Looks not so good, but not too bad. Sounds better than double processing at least.

I meant this just to help trouble shoot the arpeggiator. For now at least if it's noticeably wasteful with cpu cycles.

[PhysSong]

And I have one more solution:

4. Add something into NotePlayHandle to check whether it is processing(or have processed) or not.

[zonkmachine]

I added this: qDebug() << "cnphv.size(): " << cnphv.size(); after

lmms/src/core/InstrumentFunctions.cpp

Line 355 in 2d583db

ConstNotePlayHandleList cnphv = NotePlayHandle::nphsOfInstrumentTrack( _n->instrumentTrack() );

Playing 3 note chords in a loop I got some instances that got the count wrong. This was pretty much expected. I think the issues we see in the arpeggiator mostly relates to #2606.

cnphv.size():  3 
cnphv.size():  5 
cnphv.size():  3 
cnphv.size():  3 
cnphv.size():  3 
cnphv.size():  4 
cnphv.size():  3 
cnphv.size():  3