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

[Mark K. <mk...@co...>]

be...@ga... wrote:
> 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 :)

True - GSt3 was supposed to do unlimited in May, 2004. I see this 
morning it's been pushed back to the end of June, 2004. That might mean 
Sept, 2005.

I THINK THERE IS A HUGE OPPORTUNITY HERE TO BRING PEOPLE TO LINUX IF 
THIS TOOL JUST REALLY EXISTED IN A FORMAT THAT USERS COULD USE!

Too bad we haven't gotten that far.

> 
> 
>>    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

My machines are:

1) 3GHz P4 laptop (512MB) - disk gives about 26MB/S + 1394 or USB 2.0 
external drives. This machine will nominally be running Pro Tools, but 
it runs Linux most of the day and is what I'm doing quick LS tests on 
right now.

2) Athlon XP 2500+ (512MB) with fast drive

3) Athlon XP 1600+ (512MB) with fast drive. (Used to run Pro Tools)

4) P3 500MHz (768MB) running GSt 96. No problems at all hitting maximum 
polyphony.

Gst doesn;t really require a high powered machine.

<SNIP>
> 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.

Sounds pretty reasonable to me...

> 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.

OK, but here's what I'm more concerned about. If I load multiple gig 
files, then I need to preload more samples into memory than when I load 
a single gig file. How will LS use memory in this case?

1) A piano - 88 notes, 16 samples per note
2) Drums
3) Strings
4) Brass 1
5) Brass 2
6) Brass 3
7) Woodwinds
8) Drones
9) Loops
10) Etc.
11) Etc.
12) Etc.

I'm most curious (and concerned really) in how we decide to partition 
memory between all the different gig files I want to load and how many 
samples we need to preload.

How does this trade off against disk speed? If the piano and the loops 
are at very different locations on the disk, and they are played at the 
same time, then even a very fast disk will have trouble keeping up.

Clearly spreading the samples across multiple disks can  help some.

I'm just concerned that we're not yet doing enough work with multiple 
gig files to learn how to do this right.

(And I'm just a worrier by nature!) ;-)

<SNIP>
> 
> 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.

In the end, yes, BUT it's up to us to be able to optimize LS to do a 
very good job wit the hardware available, isn't it? At least as good as 
GSt would do on the same machine?


> 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

Hard disk recording isn't a good measure anyway since it's a very linear 
and predictable thing that happens with the data on disk. Audio playback 
by a sampler is more random in terms of any key on the controller can be 
played and the sampler must respond without fail. The sampler has no 
idea where it's going in 3 seconds. The hard disk recorder does.

> 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.

Yes, I agree. (Please explain what you mean by 'stream count' though...) 
Thanks.

> 
> 
> 
> 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).

<LOL!> Pretty much ALL of my MIDI files make GSt fail at times. That's a 
part of why I eventually have to record audio in multiple passes at the 
end. I live with clicks and pops while I'm writing.

<SNIP>
> 
> 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.
> 

I don't think any of that will be that useful. More useful in my mind is 
to set the voice count high enough to be better than GSt3 (when it comes 
out) on the same machine. GSt3 allows unlimited notes, but obviously it 
will fail at some point. I just want LS to be that good or better. Set 
the voice count at unlimted and then prove we can do better on the same 
hardware.