13 Dec
2010
13 Dec
'10
10:04 p.m.
On Mon, Dec 13, 2010 at 03:25:44PM +0100, Robin Gareus wrote:
On 12/13/2010 02:28 PM, Raffaele Morelli wrote:
The max. system-latency determines the audio-latency at which you will
never have any x-runs. (The minimal and avg. latency determines the
speed and reactivity of your Desktop.)
Without the RT-linux patch you may be good at 99.9% of the time, but
since there is no guarantee for system-latency: there may be drop-outs.
And Murphy says that this 0.1% chance will always become real when
you're on stage in the middle of a performance. The resulting click will
not only kill the PA but half the audience will sue you for becoming
deaf ;-)
I don't get clicks, but with my latest bass setup (using LinuxSampler instead of
FluidSynth), I occasionally get moments where all audio just stops for a second or two,
then whatever notes have been played suddenly rush out in a thundering-herd kind of
situation. I suspect this may be a LinuxSampler issue since I've heard it happen
before with other gigs, and it may possibly be related to slow seek times on my SSD on my
EEE.
I've also in the past had fluidsynth cause nasty stuttering (like a DJ snare-rush kind
of sound), particularly with a grand piano soundfont when I get kind of violent with it,
hammering a chord or interval repeatedly Jerry-Lee-Lewis-style with varying velocities.
I'm going to be using this new setup (using LinuxSampler for bass instead of
FluidSynth) for the first time live on the 29th, it will be interesting to see how it
goes.
-ken
2010/12/13 Robin Gareus <robin(a)gareus.org>
Lucky you :) The information on the alsa-wiki is very good, but not
every user is diligently following instructions as you do.
It is also much easier to make a custom kernel that runs on one (your)
system only, than tackling the task of compiling one that can be
distributed.
On 12/13/2010 01:13 PM, Paul Davis wrote:
I really hoped that :)
I am now sure that RT patchset is something for kernel folks to deal with,
but neverthless that it's something good to apply for me.
2010/12/13 Raffaele Morelli
<raffaele.morelli(a)gmail.com>om>:
> Hi you all,
>
> what do you think about that? Have you got some personal experience?
> http://ck-hack.blogspot.com/2010/10/bfs-in-real-time.html
yes. In short: Desktop performance: amazing, Desktop-audio-performance:
good, pro-audio performance: deficient.
This quote:
"If you were doing semi-professional audio recording you might, and
then you'd need to understand the inner workings of the software and
the -rt patchset to make the most of it. Just patching it in and
expecting it to work for you will not really give you any advantage."
is not really true. It is true that there are quite a few complexities
to using the RT patchset's full capabilities. Most people probably do
not use them. But this doesn't mean that a general claim that the
patchset offers them no benefits is wrong.
quite, but it is true in the sense that it is
much easier to screw up a
kernel by blindly applying patches and generating a .config if you don't
know what you're doing (and sometimes even if you know what you're
doing). Also, one needs additional tools (like rtirq) to make good use
of RT-linux, while -bfs runs OOTB.
However these days most distributions do that setup for the users.
well, I always followed
http://www.alsa-project.org/main/index.php/Low_latency_howto and never
screwed up a kernel I
don't care so much about speed. The important issue in pro-audio is
reliability. It's not the smallest possible latency that counts, but the
max. latency of the system.
I really did not understand this statement and anyway I would not agree...
why anybody should be safe knowing that his box max latency is 20ms instead
of 50ms or 70ms?