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
