Thank you Christian for the detailed reply, I kept changing the JACK and LS buffer, polyphony, etc, but I am still getting the X-Runs. So at this point, I think it's time to go back to your previous comment whether LinuxSampler was compiled with optimization flag turned on. I had never came across the optimization requirement until you mentioned it. - I checked the building files on AUR for installing LinuxSampler within Pamac. They only apply './configure && make' as the README says. Therefore, if the optimization flag is not turned on by default (which I think it is not), none of them is built with optimization.
Optimizing LinuxSampler installation------------------------------------------------ - I googled about optimizing LinuxSampler and I landed on a document for compiling for Debian http://www.linuxsampler.org/debian.html#build_backend. I edited the "./debian/rules" file and added the arguments relevant to my machine: "CXXFLAGS="-O3 -march=x86-64 -mtune=native -msse -march=x86-64 -mfpmath=sse -ffast-math -fomit-frame-pointer -funroll-loops" ./configure " ./configure --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info" But from now on, I couldn't figure out what happens on my Arch Linux (Manjaro 18). I saved the file but after compiling, it seems it is compiling it with "-o2" optimization. I can't figure it out how to make the compilation take these changes into account. I also noticed that in the "./debian/rules" file, there are two occasions where the CXXFLAGS are mentioned, one under "configure-stamp" and the other under "clean:" sections. The file does not give a hint how to progress here. Could you please help me get this setting to run for compiling LS? Disk streams usage---------------------------------- As a general question, if I have 32GB of DDR4 2133 RAM which is much faster than my M2.0 SSD. I wish to dedicate all of this RAM (as long as my computer is functioning) to LinuxSampler. Is this something recommended by you? I am preparing my instrument for playing live on stage and this is why I am trying to push the limits as much as possible. Would it be alright to load the entire sample library in RAM, if I have enough RAM to do so? And would that help me to optimize the performance for very rapid melodies with sustain pedal on? My understanding was that it is preferable to make use of the RAM as much as possible, which is why I invested in hardware with capacity of 32GB of RAM... Thank you again for your time | | | | LinuxSampler for Debian | | | On Saturday, April 4, 2020, 12:52:18 PM GMT+2, Christian Schoenebeck <schoeneb...@linuxsampler.org> wrote: On Freitag, 3. April 2020 20:23:00 CEST joo bian wrote: > Thank you Christian, > You pointed out several things. I will focus in this reply on disc stream > and polyphony in the LinuxSampler setting and will touch on the other, when > I am sure I am getting the settings right. > > So I use Arch linux because I can install LinuxSampler (stable and svn > releases) from Pamac. I recently switched to SVN development releases and I > am currently using the SVN version (r3751-1) from <AUR (en) - > linuxsampler-svn>. That said, I did not compile LinuxSampler with any > additional argument. Everything should have been the default installation. You can certainly check whether you see -O3 in the output while the sampler is compiling. The sampler must be compiled with optimization turned on, which only happens if the compiler flags (which you see on the console) include "-O3". > I also note that I only use the SFZ engine. > > Based on what you wrote, it seems I should not really mention my Hardware > (for reference: I am using Linux Manjaro 18 with a 3500mb/s M2.0 ssd, 16GB > Ram, RME soundcard, and 2.2 Ghz quadcore CPU. > > I get xruns when playing intricate piano solos with sustain pedal down when > I reach the polyphony limit (I believe). I never get x-runs with simpler > piano solos. The SFZ pianos I am developing for SFZ have multiple sounds > per key so I reach the limit much faster than basic piano sound libraries. It would make sense to start with a simple setup first, i.e. start by using ALSA as audio output instead of JACK. Another important thing is the actual latency setting (i.e. buffer size setting). Start with higher latencies first (e.g. 50ms), and if you don't get dropouts, lower the latency setting step by step. If you are running with an extreme low latency setting of e.g. <1ms then it is not as simple as buying the most powerful and most expensive hardware on the market, you also have to tweak the system to actually being able to deliver within that small time frame (at least on Linux). Keep in mind Linux' default environment were servers, and many default settings are hence not suitable for low latency / a.k.a. realtime applications by default. > > X-Runs > ====== > I have tried to figure out why these x-runs happen. Interestingly, the disk > streams do not seem to have any role on my x-runs. I get the X-runs > "frequently" with the default settings of "64" polyphony and "90" disk > streams. As a rule of thumb: the most important setting here is the max. voices, which you have to balance accordingly with your audio driver's buffer size (latency setting). For the amount of max. streams setting you would usually simply always choose a value approximately 30% higher than your max. voices setting. > The only way I could completely avoid x-runs is to reduce the > polyphony to 48 voices. Anything above this number would cause me x-runs. I > get the x-runs with higher disk streams (as high as 9000 and as low as 64 > streams). If I understand it correctly, disk streams load more data on the > Ram? I see that because when I increase the disk stream LinuxSampler begins > to take much more Ram in the system. But I am not sure what is actually > happening. Disk streaming is used to read as much sample data as possible in real-time from the underlying HD/SSD on demand. Without disk streaming, entire sample data would need to be preloaded into RAM. So without disk streaming, if you'd load a sample library being 20 GB in size, you would accordingly need >20 GB RAM just for loading the sound. With disk streaming enable, only a small portion of the sample data needs to be preloaded into RAM, the rest is directly read from disk whenever required. By increasing the max. streams setting, RAM usage will increase, yes, because each disk stream uses a buffer (in RAM) which is used for reading sample data from disk, while the voice is reading from the other end of that buffer. > In anyway, unfortunately, 48 voice polyphony is relatively low > for a complex instrument where each key has several layers of voices. > > I am not quite sure what is going on. I have a real-time kernel, JACK2 runs > without a problem in real-time, and I even tried running LinuxSampler with > real-time priority but basically nothing could help with x-runs but > reducing polyphony. Well, depends on what you mean with "JACK2 runs without a problem". Obviously you get xruns when system load increases. So the question is whether your JACK use cases so far ever involved high system loads. 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
