On Mittwoch, 8. April 2020 14:03:38 CEST joo bian 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.
That's exactly why I was asking you for this, because it makes a huge difference regarding max. polyphony whether you are playing e.g. uncompressed vs. compressed sample data, since the CPU overhead involved is multiplied by the amount of active voices. And no, you did not mention it before. > 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 You might have a look at method CacheInitialSamples() in source file src/engines/InstrumentManagerBase.h to understand what's going on. There is some overhead, yes, at the end of each cached sample, artificial silence is added. The precise length of that silence is dependent to CONFIG_MAX_PITCH (a compile time user setting), that is the maximum pitch setting ever allowed/desired/expected by the user (which is IIRC 3 octaves by default). If we would not add silence to the end of each (cached) sample then the sampler's audio core would have to be much more complex just to deal with the end of samples without crashing; which is not developer lazyness; the price would simply be higher CPU load which we can avoid this way. > 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. I already explained you the details of this before. Each stream must use a FIFO buffer. Every streaming algorithm works this way. No matter if its an audio sampler or a Netflix video player. I can't stress you enough: start with ALSA (since it is directly dumping to the sound card) instead of JACK (since it requires inter-process communication and adds siginficant complexity for user options & potential mistakes). Only start to proceed with JACK once it is working for you with ALSA. I would also still recommend you to test with the gig engine. I am personally almost not using the sfz engine at all. So a substantial amount of my fixes, optimizations etc. is spent on the gig engine. All engines though share a substantial amount of code though. CU Christian _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
