> > 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 > [email protected] > http://lists.linuxaudio.org/listinfo/linux-audio-dev > _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
