|
From: <be...@ga...> - 2003-11-17 11:03:02
|
A few notes:
Marks said he gets the SustainedKeyPool full message
I know the reason of the bug:
audiothread.cpp, line 41:
SustainedKeyPool=new RTELMemoryPool<sustained_key_t>(200);
Actually it should be
SustainedKeyPool=new RTELMemoryPool<sustained_key_t>(MAX_AUDIO_VOICES);
Scrive Mark Knecht <mar...@co...>:
Because there can be as much as sustained voices as there are voices.
Mark I suggest you to check out the latest CVS where Christian made
some fixes like deleting the voice from the on/sustained voice list and
other other bug fixed that caused crashed.
Then add the above fix, increase the MAX VOICE/STREAMS defines and
drive it up to 240 voices and show the CPU usage with 'top'.
I'm curious :-)
> >
> > 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 my CPU is dog slow. So the difference is even more visible.
Actually LS uses a bit a suboptimal method when streaming compressed .GIG files.
Basically the streaming engine decompressed the streams in real time and
is not caching them if you play the same notes.
Perhaps caching would be
>
> OK.
>
> >
> > > > You could try to load up LS to 256 voices and see how much CPU
> > > > it uses.
> > > > but in that case increase the preload size too
> > > > audiothread.h:#define NUM_RAM_PRELOAD_SAMPLES 65536
> > >
> > > Tried it. The program dies somewhere around 120-140 voices complaining:
> > >
> > > Wizard root # linuxsampler --numfragments 2 --gig
> > > /mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\ Bosendorfer\ Imperial\
> > > Grand\ Version\ 2.2.gig
> > > Loading gig file...OK
> > > WARNING, can't mlockall() memory!: Cannot allocate memory
> > > WARNING, can't mlockall() memory!: Cannot allocate memory
> >
> > That's a sign of low free memory when it's unable to lock it.
>
> 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?
>
> And can't one simply allocate less memory and take a risk of drop outs
> because we have less of the sample in memory? 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.
>
> - Mark
>
>
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
-------------------------------------------------
This mail sent through http://www.gardena.net
|