27 Jan
2010
27 Jan
'10
4:27 p.m.
sorry about the previous bogus message, i fat-fingered the rewrap
button... :(
On 01/27/2010 09:11 PM, Stéphane Letz wrote:
Le 27 janv. 2010 à 21:02, Jörn Nettingsmeier a écrit :
> i didn't think too much about jack2's
apparent overhead, since it
> has the benefit of scaling to smp, which usually affects the
> single-processor case (my box is a single-core amd64). it would be
> interesting to see if torben's approach is able to deliver the same
> latencies as jack1, while adding smp support.
Well "jack2's apparent overhead," is
something new for me, and would
require some deeper test/feedback to understand better. Moreover
without more precise description of xruns occurrence (at what DSP CPU
does it start to happen.. etc..) , what kind of setup (jack2 version,
jack configuration, applications used....), it is again hard to
understand/correct things.
well, as i said, it was nothing really conclusive (i'm not going to
waste much time to go from 128/2 to 64/2, diminishing returns...), and
my box is generally under-powered for what i do with it.
in short, i figured it's not significant really. i merely added this
here in case there's a general picture emerging... it wasn't even
intended as criticism.
and even if it turned out jack2 would be one step worse than jack1,
that's not at all a big price to pay for smp imho. same with the kernel:
an smp build does degrade performance on an up box, but who cares,
really? you can't even buy up workstations any more, and nature dictates
that single-core performance has hit its limit...
luck has it that my mobo just got fried, so chances are i'll be
contributing some nice quad-core data in the near future - if only my
customers paid their bills on time...
best,
jörn