I can gladly generate the profiling for you guys, as I really wish for this
problem to be solved as soon as possible. Do you have some suggestions for how
to go about the profiling?
In the linuxsampler configuration there are some arguments for detailed logging
and debugging. Should I activate them? I am not very handy with Linux, but I am
learning it. By that, I mean I have never done profiling for a software, but
I'll be happy if LS would be the first :)
Is there some links/code suggestions I can use to make sure I can deliver the
results straight on?
Cheers,
Ebad
On Thursday, April 9, 2020, 03:53:53 PM GMT+2, Christian Schoenebeck
<schoeneb...@linuxsampler.org> wrote:
On Donnerstag, 9. April 2020 15:05:40 CEST joo bian wrote:
> GIGA Engine------------------
> I had no problem at all with the GIGA instrument. No X-RUN, no unusual CPU
> activity, everything was perfect. JACK2 DSP load also was quite low during
> the performance, which is often associated with X-RUNS. Also my CPU did not
> have sudden picks inits activity, but rather a smooth activity behavior.
> SFZ Engine----------------
> There seem to be some problems in the SFZ engine that generates unusual CPU
> activity. There were frequent sudden spikes (compared to smoothness of
> GIGA). The activity also seems to be higher than GIGA engine, regardless of
> the setting. The high amount of JACK DSP load was noticeable for the SFZ
> engine. And as you can guess, I had frequent X-Runs in the SFZ tests.
> Conclusion=========
> First, I must say that this is based on my test and my system. I cannot be
> sure about this conclusion unless other developers reproduce my tests to
> see if they get the same results. But based on my results, I can conclude
> that it is likely that the SFZ engine has a subprocess that requires high
> CPU runtime and it occurs not very frequent in a normal playing. It can be
> something related to voice stealing or something that is not triggered with
> a simple nice and slow piano playing.
So you identified some of the SFZ engine's individual code portion to be the
cause of the high CPU load there (i.e. unlike with the gig engine), good!
Next step would be profiling the sampler while reproducing that high CPU load
there. The profiling data would give us all insight where exactly the SFZ code
is spending too much CPU time on in your case.
CU
Christian
_______________________________________________
Linuxsampler-devel mailing list
Linuxsampler-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
_______________________________________________
Linuxsampler-devel mailing list
Linuxsampler-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
