bb.linuxsampler.org

This is my attempt at calculating how much RAM a specific instrument require to be loaded. Here's the formula:

n samples * sample bit depth * 32768 / 8388608 = MiB RAM

To find out the values to plug into it you need to open the gig in gigedit and select the instrument. At the bottom below the virtual keyboard you will see the sample channels and any keyswitches and/or velocity layers. Above the keys you will see the regions. Now count the number of regions, multiply it with the number of keyswitches, velocity layers and sample channels, you now have found the n samples value.

The sample bit depth is either 16 or 24 and always 16 in the GS2 format.

(Can someone check if I got the above right. My calculated value doesn't match what the manual to a gig tell me it should be, but I guess LinuxSampler cache less than GigaSampler 2.0??)

Hmm.. I guess it's easier to use gigdump on the file to find out the true number of samples. Of course not all of them might be used by the instrument you trying to load, but on one instrument (using the method described above) I estimated a whopping 688 samples (8 keyswitches, 2 velocity layers and 43 key regions) used by the instrument when in fact the the whole gig only contained 325 stereo samples giving me:

325 * 16 * 2 * 32768 / 8388608 = 40 MiB

I wish it was possible to query LinuxSampler to get the amound of actual RAM consumed by a loaded instrument.

Yes an LSCP command to query instrument RAM usage would be very handy (and not relatively easy to implement)
since power users are likely to use all the available RAM resources and if you overstep the maximum you run into
troubles like crashes (in linux it can be that the kernel kills applications in case of out of memory situations)
or slow downs, ie swapping which can kill the performance of real time audio apps.

Keep in mind that streaming buffers do need lots of RAM too.
The calculation is as follows: assume you have 100 streams (the number of streams should be a bit larger than voices, eg 10% more).

If the streaming buffer is ie 300000 samples you have to multiply them with 3 (streaming buffers are always 24bit).
= 900k bytes and then this numbers gets rounded up to the next power of two for efficiency reasons.
this means 1024k = 1MB. so 100 streams eat 100MB.
this is why CONFIG_STREAM_SIZE * 3 should always be a bit smaller than the next power of two,
otherwise lots of memory get wasted.

for example 1MB = 1048576 bytes
if you set CONFIG_STREAM_SIZE to ie 350000 you get a buffer size of
350000 * 3 = 1050000 which is bigger than 1048576.
this means the buffer size would get rounded up to 2097152.
in this case you waste almost 50% of RAM. If you need to set CONFIG_STREAM SIZE > 349525 (which multiplied with 3 gives 1MB)
it is better to set it to a value so that you make full use of the full 2MB ( 699050 x 3).
Larger streaming buffers means that you can achieve better polyphony when you play lots of sustained notes at the same time.

sbenno wrote:Yes an LSCP command to query instrument RAM usage would be very handy

Just came to think about it, but just having the ability for the front end to show a global RAM usage and other statistics would probably be more useful than a per-instrument dito. My current orchestral MIDI Instrument Map have about 30 banks and 500 programs, so I tend to think about these things alot.