[Linuxsampler-devel] Polyphony, Was: MacOSX note release problem solved

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

Scrive Mark Knecht <mk...@co...>:
>
> Benno,
>     Will we have any imposed limitations on voice counts? Or will the
> only limitation be the capability of the hardware? How will we assess
> what number of voices a given machine can handle?

The limitation is given only by the speed of the hardware, (CPU,disk).

Keep in mind LS voices I gave are stereo and GST voices are mono.
so GSt's 160 voices equal to max 80 stereo voices.

The current defines in the latest LS CVS is 128 stereo voices which equals
to 256 GSt mono voices .. which GSt2 cannot deliver :)

>
>     I typically run 8-10 MIDI channels. The piano channel easily uses
> 40, but can peak at 80-100. (Divide by two in LS from GST???) The other
> channels are more modest using between 10-20 voices. Still that's 100 +
> 9*20=280 voices. Of course I can never get this from GSt because of
> imposed limitations so I have to record audio in multiple passes.


With LS it would be possible given a fast machine (athlon 2400 or P4 3GHz)
and a 7200rpm drive

>
>     OK, so this only goes to ask why is max voices set so low during
> development? Wouldn't we be better to set it very high in development
> and then lower it later when the code goes 1.0?


yes 64 was really low and you can hit the polyphony limits really quickly
especially because the pedal sustain algorithm is not optimized
yet and simply keeps adding voices if you repeat hitting the same keys.
The optimized version should hold only the last 2 voices on the key or so.
That way you never go up beyond a certain polyphony.
On the other hand each voice needs a streaming buffer which is currently
set to 256KByte.
So 128 voices use 32MByte of RAM, 256voices 64MByte of RAM.
I think for now 128 is a good value since it does not use that much memory
and  stresses the average machine's CPU/disk quite a bit.

The #define solution is only a temporary solution,
at a later stage it will possible to specify the voice count
 via LSCP.
Regarding the max number of voices that a machine can achieve.
It's hard to say.
If you push up the number too much you can choke even the fastest
machine on the planet.
Often the disk is the limitation but CPU is stressed heavily too
especially if you use cubic interpolation and filters.
The windows/mac softsamplers that can stream from disk all have this problem.
You have to deal with a shared, non real time device, the hard disk.

It's up to the user to find out the limits of the machine, although its hard
to define what reliable diskstreaming means in the softsampler context.
It's not like a harddisk recording app where you have the data streaming all
the time so a benchmark can give you a good estimate how many track
you can reliably
In the case of a softsampler the stream count is very dynamic with very high
peaks. Just watch the voice count in classical piano piece.
Lots of high polyphony peaks but usually the average is much lower.
Eg if the peak is 100 then the average will be 30-40.



What's the worst case for a disk based softsampler is starting lots of notes at
the same time and then holding them for a long time.
This puts an extreme stress on the engine and the disk becomes the bottleneck:
let's say you have 32k samples preload, which means 0.7sec.
If you fire up 50 notes at the same time, the softsampler will have
only 0.7secs available to fill up 50 buffers with data.
Its a very small time and the risk is high that data cannot be filled in time.
It's easy to construct a midi file that
makes any softsampler fail. (alias causing voice dropouts).

But normal music pieces don't stress the disk that much because we usually
have lots of notes but they are usally relatively short with some exceptions.
The first part of a note is always read from RAM and the first part
ofthe notes streamed from disk are often cached in the disk cache thus
do not put real stress on the disk (as long as you don't sustain them
by more than a few secs).

In conclusion: some automatic benchmark estimate could be incorporated into LS
but it would never give you a 100% guarantee that you don't overload the
streaming engine.
We could do a very conservative benchmark too (one that fires up all
the voices at the same time) but then numbers would way below the
 voice count achievable in practice. (eg the benchmark would say 60 voices
while in practice you would achieve 100-120 voices or more.


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



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