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...
As a point of reference I just recorded 10 hours of data this past
weekend on my quad core and was having several issues with jackeq +
jack1 prior to starting that were solved by moving to jack2. However I
didn't test with latest svn of jack1 so it may just be the Fedora 12
package of jack1 that was causing me headaches.
Patrick Shirkey
Boost Hardware Ltd
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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev