On 11/10/2014 11:34 AM, Raine M. Ekman wrote: > If there are cores sitting around just twiddling their bits waiting > for something to process, the "one job per note" model won't run out > of CPU when the instrument has too much processing to do. It evens out > the peak demand in busy parts if using one of the multistream > instruments.
Theoretically yes. But then we get to the whole "stages" thing. Which is sort of intertwined with the "per-note jobs" thing. There's also the problem of thread-safety, when multiple notes have to access the same object, and if the problem can't be solved with atomics and such (tricky), then we get locking and then we get shitty RT. Think of this scenario: We have 4 threads. 3 notes are being rendered in instrument A, 1 note is being rendered in instrument B. The single note of instrument B is rendered quickly. Now we have 3 threads working on the notes of instrument A, with one thread waiting idle because it can't process to the next stage (audioports) before all notes have been rendered. If we don't have stages however: Thread 1 renders instrument A, thread 2 renders instrument B, and as soon as instrument B is rendered, thread 2 can proceed to process the audioport of instrument B. Meanwhile threads 3 and 4 can render instruments C and D. I'm thinking, the entire chain from reading notes (from pattern and midi-input), arranging them to an array, passing them to the instrument, the instrument rendering them, applying soundshaping, mixing, passing audio to audioport, fx chain processing - this all would be one job, processed serially. No stages, no waiting. There's added benefit of gained simplicity, less worrying about thread-safety, since each job is a self-contained unit without outside dependencies - less locking, better RT. > But if the mixing has to be "serial" I'll just > withdraw the suggestion. Mixing always has to be serial... there's no way to parallelize mixing of multiple sources -> single destination. That I know of. ------------------------------------------------------------------------------ _______________________________________________ LMMS-devel mailing list LMMS-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lmms-devel
