On Monday, September 11, 2023 7:31:34 AM CEST Doug Gray wrote: > Hi Christian, > Thank you for looking at this. > > I commented out the code as suggested but this did not help other than > removing the Lambda function as a candidate cause.
Then it's a minor, unrelated issue. Should still be fixed, as it's apparently polling for SFZ file changes far too often. > BTW the sfz reload on > change behaviour is very useful indeed. > > Attached are two profiles taken after making this change, exampl3 is about > 15 seconds long spanning the onset and recovery of the fault event, the > second exampl4 captured during the failure event itself (~8 seconds). Looks like the heaviest part with 60% CPU is directly inside AbstractVoice::Synthesize(). Would make sense to profile which parts inside that specific method take how much of the CPU time. This method is shared with the gig engine, but some parts there are only used by the gig engine, and some parts only by the SFZ engine. > The most curious aspect of this issue for me is the way only one cpu core > hits 100% load during the event as if threads are not launching properly > beyond some threshold and become locked preventing them being killed on > say a keyoff event. Unfortunately this is just my hunch and so far I > haven't seen anything to support it withing the code. That's the expected behaviour. We don't have real SMP support. If you have exactly one audio output device instance, then there is exactly one audio thread doing all the heavy lifting of calculating the audio result for all voices. This behaviour applies to all formats, including SFZ and gig format. A workaround is creating additional audio output device instances with the sampler, then they could (depending on the audio driver) run in separate audio threads. But that's inconvenient for the user, as he would manually need to spread the setup over individual audio devices (threads). So I guess almost nobody uses that. We had discussions in the past many years ago with plans to implement real SMP support, that is automatically distributing voices to invidiual threads which in turn would deliver their result back to the main audio thread, however that never gained momentum. Simply because hardware development no longer made it necessary. With the gig engine you can run several hundred of voices with a single thread, without getting into any glitches - and that for like 12 years already if not even longer. /Christian _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
