Re: [Linuxsampler-devel] LinuxSampler BUGS to fix (Christian & others)

[<be...@ga...>]

Scrive Mark Knecht <mar...@co...>:

The SustainedKeysPool FULL message is due to
audiothread.cpp: line 40:
   SustainedKeyPool = new RTELMemoryPool<sustained_key_t>(200);
you must replace 200 with MAX_AUDIO_VOICES.
There can be as much sustaned voices as there are voices.
Download the latest CVS where Christian made some fixes that avoid
crashes and apply the above change.
Then set MAX_AUDIO_VOICES/STREAMS to 256, recompile and try to
drive LS to 240-250 voices and look at the 'top' command how much
CPU LS consumes. I'm curious :-)



> On Sat, 2003-11-15 at 18:03, Christian Schoenebeck wrote:
> > Es geschah am Sonntag, 16. November 2003 00:15 als Mark Knecht schrieb:
> > > Sitting idle, on my Athlon-XP 2600+ with 512MB, LS is using 0.7%. Even
> > > banging away on it, but being careful not to use too many notes, it
> > > never gets above 5% on my machine. I don't think this means much, but
> > > it's a data point.
> > 
> > Benno is using a compressed gig whereas you most probably are using a
> normal 
> > one. That's the reason for the cpu usage difference.

Yes, plus the problems is even more visibile in my case because my CPU
is a bit slow.
Anyway LS currently uses a method to stream crompressed .GIG files which
is a bit suboptimal. Basically no caching of the decompressed stream is
performed so the decompressing is performed all the time (in the
low priority disk thread).
Anyway I'm unsure if caching would buy us anything because those samples are
so large that you could only cache small parts and playing dynamic pieces
you trigger a large number of the samples contained in the GIG so I guess
caching would be only a big coding work with maybe gaining only a few % in
terms of absolute performance.
Keep in mind that the decompression is performed in the low priority thread
which means the audio engine does not get slow down by the streaming task.
As long as the CPU is being able to keep up with the load things will be 
perfectly fine.
As said above when playing a real, dynamic (in terms of MIDI velocity) piece
even the optimized engine would probably make little use of the caching.


> 
> This only popped up when trying to allow 256 voices on 512MB. I will
> grant you that my GSt machine has 768MB and is only allowed to do 96
> voices, so I'm not overly concerned, but I am curious what's driving
> this. What's the equation for how much memory is required by LS right
> now?

The equation is simple:
audiothread.h: #define NUM_RAM_PRELOAD_SAMPLES 32768

when you have mono samples, each sample contained in the GIG lib consumes
64KB (32768 x 16bit) in memory. In case of stereo samples its 128KB.

diskthread.h:#define STREAM_BUFFER_SIZE 131072
When you define the max number of voices
(MAX_AUDIO_VOICES) you consume
MAX_AUDIO_VOICES*STREAM_BUFFER_SIZE*2 (2 because samples are 16bit).
So in case of 256 voices and the default STREAM_BUFFER_SIZE of 131072

256*131072*2 = 64MB

So perhaps these additional 64MB did not fit in your RAM anymore.
Keep in mind that the voice buffers are not that big, most of the RAM
is consumed by the sample beginnings preloaded in RAM.
The number to tweak is NUM_RAM_PRELOAD_SAMPLES (you increased it to 65536,
thus experienced the mlockall problems).
Try to lower it to 50k, 40k or even 32k. (although 32k is a bit low when
streaming that much voices).
Keep in mind NI Kontakt users reported being forced to use 150k samples of 
preload in some case in order to achieve stable operation.
Of course this means you need a tons of RAM.
Our numbers are actually quite good.

> 
> And can't one simply allocate less memory and take a risk of drop outs
> because we have less of the sample in memory? 

Yes this is the NUM_RAM_PRELOAD_SAMPLES value.
The smaller this value the bigger the risk of dropouts during high 
polyphony passages.
But as you have seen even with 32k (GSt uses 32k samples too) we can
achieve a polyphony of 100+ voices ( = 200 in GSt's termionology) quite
reliably. The chopin demo as run with 4msec latency and did not show a single
dropout. And I rendered it to disk while surfing the net with Mozilla while
 my box was swapping nicely :-)

Or are there hints in the
> gig file that are telling you what to do? I should try some smaller
> libraries and see what happens.

No the hints are not in the GIG file, each disk based samples uses his
own settings (and GSt is still the best windows sampler in terms of streaming
because of its releatively efficient engine due to the kernel based engine).
From reading various forums, the GSt's competition (Halion,Kontakt etc) is not
able to deliver the same numbers because using the Windows APIs is slower
than using the iron directly so they must compensate the inefficiencies
by using large sample preload sizes. But this means being able to load
less samples in RAM.
64bit is still an illusion on Windows so the upper RAM limits are 1-1.5GB.
see here: http://www.pcworld.com/news/article/0,aid,112749,pg,6,00.asp
This is why with GSt you can preload more samples on the same box than
using the other windows softsamplers (which are better in terms of VSTi
integration, more flexible, more effects etc).
So for those needing many sample libraries preloaded (for large orchestral
stuff) GSt still have some advantages.

PS: saw an interview with Hans Zimmer on the german ZDF TV channel.
They did show his studio (but not the GSt farm :-) ), kinda cool guy.

We must all work hard so that LS lands in his studio too,
you know we all need to fuel our personal egos :-))

cheers,
Benno
http://www.linuxsampler.org



-------------------------------------------------
This mail sent through http://www.gardena.net