Hi,
you are raising some interesting points, and i am very
interested in everything about the sampler setup,
software or hardware.
1/ number of voices.
The first, and main, thing is that allowing more than
( approx ) 100 voices is nearly not audible, if not at
all ;-)
But, strictly, what is requested is 88 * 4: the main
channel ( the piano ), the hammers sounds, the release
( key abruptly off ) and the sustain ( pedal down ), a
fifth channel could also be used to add the low notes
of the Bosendorfer ( extra keys on the bass register
). Maybe 89 * 4 or 90 * 4 could make sense to ensure
dying notes on the voice-steal mechanism ? To be more
precise, 88 voices make sense for the main channel and
the sustain channel, 44 seem to be sufficient for
hammers and release ( those sounds are naturally dying
very quickly ). Please note that if Linuxsampler wants
to implement convolution ( in the manner of gigapulse
), another one or more channels will be necessary, and
quite surely with something like 88 * 1.5 or 2
concurrent voices.
In fact 120/128 voices seems to be more appropriated
with the Linuxsampler technology, because at 144 ( or
160 ) concurrent voices, the sustain channel (*) is
very often using 90 to 100 voices ( which is clearly
ridiculous for a piano, more, this doesn't produce
anything near sympathetic resonance ). I had hesitated
to ask for some modification of Linuxsampler to allow
a limitation of voices per channel, maybe this is the
good time to ask for it ?
(*) Here is a big advantage of Jsampler over Qsampler.
Jsampler display the global consumption of voice _and_
the exact consumption of individual channels. Qsampler
is displaying the global consumption for every
channels ( except for 1 to 5% of the time, when you
have briefly the real consumption of one of the
channels, a curious bug ), which is less informative.
2/ No problem for recording, but this will be from a
midi partition, because first i don't play piano,
second my son is 1600km away from me, and third i even
don't have a single keyboard ( except if three notes
on virtual keyboard could make you happy, but i can't
afford any guarantee on the musicality ;-) ). Either i
can choose one of my favorite track ( mostly blues
from www.trachtman.org www.rtpress.com www.midi4u.com
www.abcmusic.tk pop.mididb.com ), or you will give me
the url of the track you want to ear.
As transition to the third point, the recording will
be done on my computer ( my son's computer is not
available to me, due to the 1600km ). the
configuration are quite the same.
For the hardware: AC97 embedded sound chip, asus
P4P800se motherboard, processors are mmx, msse 1 and 2
capable. differences are the processor, a P4 versus a
Celeron ( do not laugh, the celeron is more powerful
for dsp than the pentium, i strongly suspect the usage
of hyperthreading on the pentium to produce click and
pop on context switching between the two - 'half'
false - cores ), and the memory, 233mhz on the Celeron
and 400Mhz on the pentium ( do not laugh, the Celeron
is still more powerful for dsp ). Anyway i need to
switch off the hyperthreading on the pentium to be
able to achieve the same dsp performance than the
Celeron, i will slow down the memory speed at the same
time, so hardware differences will really be minimal.
The last difference is the disks, but this doesn't
matter as Linuxsampler is configured to load
everything in memory.
For the software, differences are big. RHEL4 versus
RHEL5 on my computer, and i can't revert back to RHEL4
( too much time consuming ). Clearly RHEL5 puts more
stress on the machine ( far more interruptions ), this
is compensated by the availability of real time on
RHEL5 ( used only for Jack, useless for the rest ).
Another difference is the optimization done on RHEL4 (
shutting down all daemon and so on ), but i can
reproduce that on RHEL5. The last difference is
Linuxsampler itself, 0.4.CVS2007/04/16 versus 0.5.1.1,
but regarding sound quality and performance
Linuxsampler is like an English gentleman: unchanging.
Anyway i can downgrade to the 0.4 release in some
minutes. Jconv and IR libs are on the same level.
So, at this point you guess that there is some work to
do before the recording, if you only intend to ear
AC97 and/or Jconv, i can simplify it. Just tell me
your preference.
The last point is Jconv itself, i like very little
reverb "just to make the sound wet", but it can be set
to something like a guitar amplifier reverb knob on
eleven, true soup, or even more thanks to the
software: pure celestial voices.
3/ Here is the main point, configuration of
Linuxsampler.
Regarding the configuration ( not really overpowered
), the "killing factor" to make click and pop reduced
to nothing was to decrease eg-min-release-time from
0.0025 to 0.001. Please do not ask me why, i don't
know, and quite the contrary i will be interested by
any explanation.
The second factor was to preload the whole piano in
memory, rather than to rely on disk streaming on a
mono disk configuration, and worst a 5400 rpm one. So
preload-samples is 327680, which leads to 1.6 giga
used in ram for a 1 giga file. This setting is only
adapted to the live playing piano context, because of
a drawback, if i try to load another big channel,
Linuxsampler simply crash on memory allocation( out of
memory ). As the memory potentially open to
Linuxsampler is far superior than the real memory,
this setting also prevents the load of a second
Linuxsampler engine. Anyway i am not sure that the
configuration you had suggested on this point will be
accurate for a piano, regarding the work of the
voice-steal mechanism ?
A strange thing is the lack of linearity between the
setting of preload-samples and the real memory
allocated, for sample ( to avoid the out of memory
error, and with a dedicated disk ) i currently try
preload-samples between 163840 and 262144, which leads
( always for the same PMI Bosendorfer file, 1giga -
954Mb to be precise ) to a real memory consumption of
respectively 1.1 and 1.3 giga, not linear, and even
less linear when compared to the 327680 preload / 1.6G
real.
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.
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.
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.
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
