2008/2/19, hilare <[EMAIL PROTECTED]>:
>
>
>
> The relation between processor power and number of
> concurrent voices is clear, but surprising. For sample
> the Celeron stands for 144 concurrent voices ( approx
> 70% cpu load ), and the pentium stands for 160
> concurrent voices ( same load ), which is a 10%
> increase for a cpu rated with 50% of raw power over
> the Celeron ( some marketing border effect i guess ;-)
> ). The other surprise is one more time the lack of
> linearity. For sample 160 concurrent voices are always
> accepted by the pentium ( on the context of music
> playing, aka no extra process ), 176 also ( always
> with 70% cpu load ) but time to times there is a peek
> to 100% ( so click and pop but no crash ), and 200
> concurrent voices is a crash guaranteed in less than 2
> second, the cpu load jumping to 100%. What is beyond
> any explanation is why the average load is not 80/85%
> at 176 voices. To generate the load i always use the
> same midi file.
I think hyperthreading could be the cause of some problems as the speedup is
marginal
and since LS needs fast response times the scheduler could cause some mess,
but it is hard to tell.
As for Celeron , P4 difference, LS is mostly memory bound so probably if you
push the polyphony up
the RAM access speed will be the limiting factor.
About the multi-core, i will be interested by clear
> reports on success. My main surprise was to see the
> Celeron producing no xruns ( so click and pop ), while
> the pentium produces a lot of them. Ok, hyperthreading
> is far from a true multi-core, but this seems to be a
> little too short for an explanation.
Yes it is strange, LS runs stably on a slow 1GHz VIA although with lower
polyphony.
but keep in mind that an RT kernel is mandatory for low latencies.
And often the sound card driver is important too. On some boxes with
integrated audio chip with the default
settings under linux performance sucks, you get droputs in jack even at 1024
frames.
I have not investigated the issue, probably one needs to pass some
parameters to the drivers in order
to achieve lower latencies. (I am not sure but I heard some consumer chips
only support 48kHz in hw
while 44.1kHz is emulated which is the cause of worse latencies, correct me
if I am wrong).
Maybe the lack of power of the sound chip is the
> answer, especially when requesting 5ms of latency, in
> particular xruns are never generated on a "dynamic"
> partition ( staccato and things like that ) but very
> often on a quiet piece ( Gymnopédie ), just on the
> middle of a long note whithout anything to do other
> than "finishing the key". Another fact pointing in
> this direction, is that any attempt to increase
> Linuxsampler priority ( useless anyway ) always leads
> to an increase of xruns.
During slow passages you have lots of sustained notes and probably the disk
is not
able to keep up with the amount of data that needs to be streamed.
solutions are: a faster disk, larger sample preload sizes.
about the memory usage keep in mind that besides memory for preloading
samples
you need memory for the streaming buffers (one per voice).
and as I already told some time ago, the streaming buffersizes are rounded
up to a power of two.
so a streaming buffer size of 35000 samples allocates 3 (24bit) x 35000 =
1050000 bytes rounded up to
the next power of 2 = 2MBytes. so keep streaming bufffer size x 3 always a
bit below of the next
power of 2 in order to optimize memory usage.
About multi core, Alex Stone will certainly be able to explain the benefits
he is getting on his dual core.
(he told he will get a quad core soon so the numbers he will get out of his
new box will be even more interesting
as the quad has to share the memory amongst 4 cores)
cheers,
Benno
Best regards
>
>
>
>
> --- Benno Senoner <[EMAIL PROTECTED]>
> wrote:
>
> > 2008/2/18, hilare <[EMAIL PROTECTED]>:
> > >
> > >
> > >
> > > The setup is simple, a celeron processor with
> > 2giga of
> > > ram ( no dedicated disk, the disk is even a 5400
> > rpm
> > > one ), RHEL4 ( no real time ) and Linuxsampler
> > 0.4.x,
> > > PMI grandioso Bosendorfer with PMI 'holy grail
> > piano'
> > > add-on ( hammers sounds, release and sustain ),
> > and
> > > Pori Concert Hall IR for convolution reverb (
> > > www.acoustics.hut.fi/projects/poririrs , i
> > recommend
> > > this one, particularly the binaural release, which
> > is
> > > free for non commercial usage ) via Jconv ( 0.1.0
> > ).
> > > The 'sound card' is the embedded Intel AC97 which
> > > delivers 5ms latency at 48Khz/16bits. Latency is
> > the
> > > main point for live playing, and clearly you must
> > be
> > > under 8ms for this kind of usage, 10/11ms is too
> > slow,
> > > you can feel/ear the delay. What is amazing is the
> > > sound produced by the AC97 ( something like a 1$
> > chip
> > > for a motherboard factory ), plug an electric
> > guitar
> > > in it and you will be surprised how much the
> > 'little'
> > > thing could act as a warm amplifier, and i mean
> > _warm_
> >
> >
> >
> > Hi, interesting setup. Would be cool if you could
> > record some piece
> > to an ogg/mp3 file (with convolution reverb) either
> > played live or some
> > rendered midi file.
> >
> > The only 'limitation' is 144 concurrent voices,
> > going
> > > over 80% CPU produces clicks and pops, and Jconv
> > eats
> > > a permanent 10% of CPU ( which is very good ).
> > >
> >
> >
> > Well that's unavoidable, for higher polyphony a
> > faster CPU is needed or
> > wait until we optimize the code with SSE
> > instructions or gcc vector
> > extensions but with
> > the advent of multi core CPUs it will become of
> > secondary importance as you
> > can already now
> > create multiple audio devices in LS which will run
> > on different cores thus
> > allowing for higher polyphony.
> > (you need to use jack-dmp instead of the normal
> > jackd).
> > this works ok for multiple instruments but for a
> > single piano one would need
> > to apply some tricks eg
> > building a midi filter which routes the lower pitch
> > notes to sample1
> > connected to audio device1 and
> > the others to sample2 conneted to audio device2.
> > sample 1 is the same as sample2 (the piano sample).
> > or alternatively for a better load balancing one
> > could try to route even
> > numbered midi notes to
> > sample1 and odd midi notes to sample2.
> > or use some round robin midi filter which simply
> > routes the first note to
> > sample1 the next one to
> > sample2 etc.
> >
> > the question what kind of polyphony still makes
> > sense for a piano ?
> > 88 notes assume 2 notes per key (with stustain)
> > gives 172 notes.
> > does a higher polyphony really bring any advantage ?
> > I am not a pianist so I cannot comment on the matter
> > but others are invited
> > to chime in :)
> >
> > cheers,
> > Benno
> >
>
>
>
>
>
> ____________________________________________________________________________________
> Never miss a thing. Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linuxsampler-devel mailing list
Linuxsampler-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
