Thank you for your explanation Christian.
I will give it a try with ALSA as you recommended. But I did a big test the
next three days, which might be interesting to the development team here.
So I finished my torture tests on both LinuxSampler SFZ and GIGA engines.
Luckily, I had a single microphone Piano library of about 5.5 GB with several
velocity layers and key releases in both SFZ and GIGA samples to run this test
(normally I only use SFZ). For this test, I put the polyphony on 128 and voices
on 180 (double the default). I also executed the test with a default
installation, o3 optimization, and o3 optimization with large instrument
preloading to load the instrument in RAM. But the results were NOT really
affected, meaning the voice streaming procedure is working just fine.
To torture LS, I created a MIDI file with 3 channels. each channel had a piano
solo by Chopin (it was not nice to listen to the output of the torture test). I
created one channel in LS and configured it to play all MIDI channels. This
would guarantee some troubling piano playing, enough for this test.
I repeated my tests with different settings, 44.1KHz, all the way to 192KHz
sample rates. I tuned it in a way that the GIGA sample would not give any
X-Runs and then tested the SFZ for identical settings. The instruments were
created with 24bit 44.1KHz Wav files.
Hardware-------------
AMD quad-core 2.1 Ghz CPU, tuned to run at its maximum clock speed of 2.1Ghz
with turbo boost available. RME AIO sound cardJACK2 for enabling multicore
audio processing3500mb/s M2.0 SSD DDR4 2133 RAM
Results======
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.
On Wednesday, April 8, 2020, 02:05:53 PM GMT+2, joo bian via
Linuxsampler-devel <[email protected]> wrote:
I thought I mentioned that somewhere in the thread. I only use uncompressed
Wav files to avoid any unnecessary encoding. Most of my samples are 24bit
44.1khz or 24bit 48khz and they are all Wav.
Regarding Jacek's comment, I am recompiling LS with different configurations
and it seems the behavior of --enable-preload-samples= argument is a little bit
unpredictable (well, to me). The default value is 32768, which in practice (for
180 max voice) it loads 730MB out of a 8.5GB sample library.
I recompiled it with setting it 10 times larger,
--enable-preload-samples=327680 and it loaded 2.6 GB. Recompiled it with 100
times larger and it loaded 5.3GB. Recompiled it with 1000 time larger value of
32768000 and the amount of preloaded samples did not go anything above 5.3GB
Side note------------
I saw some unusual behavior here as well. Surprisingly, when I increased the
"max voices" LS can actually by far surpass the size of the library. For the
8.5GB sample library, LS could require 12GB if I increase the max voices. I
only did this for testing (no other reasons to apply such a setting). it seems
each stream can also occur independent of pre-loaded samples or at least its
allocated RAM memory is independent of pre-loaded sample? I'm not sure. I
thought the streams should take the preloaded data into account.
On Wednesday, April 8, 2020, 12:18:01 PM GMT+2, Christian Schoenebeck
<[email protected]> wrote:
On Dienstag, 7. April 2020 16:36:48 CEST joo bian wrote:
> Dear Christian, Jacek,
>
> Thanks for your kind replies. As Christian pointed out, I also don't think
> that a little bit of optimization plays a significant role, giving my
> hardware (and the fact that I get the dropouts even while my CPU usage is
> less than 25% and memory usage is less than 10%).
File format of samples being used (wav, flac, ogg vorbis)?
CU
Christian
_______________________________________________
Linuxsampler-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
_______________________________________________
Linuxsampler-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
_______________________________________________
Linuxsampler-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
