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%). But I managed to compile it with -o3
optimization. Since the optimization arguments are mainly passed to the
compiler, I could also give them directly to the compiler. So for installing
the SVN version of the LinuxSampler on Arch Linux, I applied the following
commands after navigating to the source directory:
```make -f Makefile.cvs./configure --disable-sf2-engine
--disable-instruments-db
make CXXFLAGS='-march=x86-64 -mtune=generic -O3 -msse -ffast-math
-funroll-loops -fomit-frame-pointer -fpermissive -mfpmath=sse'
```
Then in the compilation, these arguments also appear (for 64bit computers, both
"-march=x86-64 -mtune=generic " are the default. also the "-ffast-math" was in
the default settings and "-msse" is also by default is turned on for 64bit. But
I kept them anyway).
The problem is that the issue was unaffected. I also started to doubt my RME
AIO soundcard which I know is partially supported for Linux but based on my
research it should work fine.
Then I tried the same MIDI piano files that I am using for testing the
instrument and the setup on Carla and Liquidsfz and surprisingly, I did not get
any of the X-Runs for identical JACK settings, instrument, and MIDI files. So I
will start doing a general torture tests on LS SFZ engine (and compare it to
GIGA) to see if I can figure out what is going on.
But for now, I have one important question. Is there a way to load the entire
sample library in RAM? In the source code of LS I saw that the ./configure
command can take several arguments to change the behavior of LinuxSampler. But
the help file was not very detailed and I was not sure how such a configuration
would work. Would you be kind and suggest me such a configuration that takes
advantage of a lot of RAM and very fast M2.0 SSD? I assume I need a hint
regarding:
1. --enable-stream-min-refill=2. --enable-refill-streams=3.
--enable-stream-size=4. --enable-max-streams=
5. --enable-max-events=6. --enable-subfragment-size=
7. --enable-preload-samples=
and possibly the following? I was not sure if I should enable this, because I
am running real-time kernel.
8. --enable-rt-exceptions=
With the settings above, I assumed if I increase the size of the each stream or
somehow preload the entire library, then I can be sure there won't be any other
issue with streams and I can afford up to 30 GB of sample library to be loaded.
The sample libraries I am currently using are about 15-20GB each, so I can
afford loading the entire SFZ instrument into RAM.
Both Carla and Liquidsfz use much more RAM than LinuxSampler (but they don't
load the entire instrument into RAM. they load about 70% of it, it seems).
LinuxSampler, can work with any hardware it seems, which is incredible! But I
am trying to get the maximum out of my hardware before carry out the torture
tests.
Thank you again for the awesome community support.
Cheers,
Ebad
On Tuesday, April 7, 2020, 3:11:35 PM GMT+2, Christian Schoenebeck
<schoeneb...@linuxsampler.org> wrote:
On Montag, 6. April 2020 17:24:08 CEST joo bian wrote:
> 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
Not JACK, use ALSA! Like I mentioned before, start with a simple setup by
using ALSA. If it works for you (without dropouts) with ALSA, go ahead with
JACK.
If you still get dropouts with ALSA, name the concrete parameters that you
were using for a) sample rate, b) buffer size, c) max. voices, d) max. streams
and e) precise sound device being used.
What file format are your samples in (wav, ogg vorbis, flac, ...)?
Have you tried a .gig file instead for comparison?
What about trying to install an OS that is already preconfigured for low
latency like Ubuntu Studio for instance?
> 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.
That's OK. It is probably not the root of your problem there. -O in general
means optimization and the number after it means the level of optimization
where 3 is usually the maximum optimization level.
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
