On Mon, Jan 25, 2010 at 11:01:53PM +0100, hollunder wrote: yup. its basically jack1 with a pretty big patch. no chance at all. jack1 is in almost feature frozen. the only update it will see is the new latency API this is also such a big change, that most experience with the old codebase is not valid for this one. jack1 is supposed to be rock-solid, based on several years of experience with this mechanism. ripping the guts out, and turning it upside down, and afterwards "selling" it to users as the "rock solid jack1" isnt fair. this is a new implementation, and it needs to gain trust by itself. that said, it survives bad treatment by the oom guys without xruns. i basically consider it more robust than jack1, but since we only have 2-3 days experience with it, we cant be sure that its bug-free. -- torben Hohn

--- On Tue, 1/26/10, Chris Cannam <cannam(a)all-day-breakfast.com> wrote: and would I assume correctly that one of the reasons to not let the jack1 codebase "die" (or freeze) is that it is written in C as opposed to jack2 ? J.

Torben, after the flurry of initial testing, and substantial updates, i've got a better view of tschack with a full day's testing, today. tschack, with the exception of the 3 updates you did, has been running solid all day. No xruns reports, or sudden spikes. I've been using it in real use case, with a large linuxsampler samplelib set, oom, a2jmidid, calf verb, jp1 patchbay, non-daw for some modest recording tryouts, and a lot of midi and audio ports (i mean hundreds) as if i were running a normal day. There's been a lot of starts and stops, as i edit midi, and kick large orchestral midi files into life, and kill em again. in this real use case (mine), i guess real numbers are as appropriate as they are going to get in this, the early stages. It's been a good day, and i've enjoyed the stability. I used jack1 before, because it gave me fewer challenges, xruns and occasional pops and spits, than jack2, which i ended up having to ease out to 48000/512/3, to reach near the same performance. (i'm on 48000/256/3 with jack1) Doing lots of midi editing, and starting large sample sets for orchestral work can be quickly problematic, and today i was able to sit on 48000/256/3 all day with trouble free performance. Subjective stuff i know, but it's been enjoyable and productive, and that's a criteria for me. I'll keep testing, and i'm somewhat rueful about jconvolver, but that aside, (and i hope i can use it again in the near future), the rest of the setup has been cruising along, and not getting in the way of me writing, with problems, or glitches. All in all, a good day, and looking forward to the next stage in the progress of tschack, and what else you might consider adding to this experimental version. As we're free of political constraints, and mainstream requirements, i have a "modest' list of suggestions you might want (or not) to have a look over. :) More to come... Alex. -- www.openoctave.org midi-subscribe(a)openoctave.org development-subscribe(a)openoctave.org

Le 27 janv. 2010 à 21:02, Jörn Nettingsmeier a écrit : 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. Stéphane

sorry about the previous bogus message, i fat-fingered the rewrap button... :( On 01/27/2010 09:11 PM, Stéphane Letz wrote: 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

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

On Wed, Jan 27, 2010 at 09:02:39PM +0100, Jörn Nettingsmeier wrote: That doesn't make much sense. You can instruct jconvolver to use a minimum period size that is larger than the one Jack* is running. -- FA O tu, che porte, correndo si ? E guerra e morte !

On Tue, Jan 26, 2010 at 12:38:53PM +0000, Chris Cannam wrote: i am not sure, but there a several users which report xruns with jack2, where jack1 still works. though i am not sure if they tested jack 1.9.4 which seem ok in sync mode at least. tschack still has most properties of jack1 -- torben Hohn

On Wed, 27 Jan 2010, Stéphane Letz wrote: I started playing with this -- and this is pretty cool. Great work! I had been avoid this because I figured it comes with a performance overhead (like -gprof does). Or, perhaps it only has overhead when you use it (like Sun's strace). What overhead does compiling with --profile introduce? Why not have it enabled by default? Suggestion/Issue: I have PDF issues with the TimingN.plot (gnuplot) files that it outputs. They always issue the command 'set terminal pdf' and try to output a PDF file. These create an error on my system and I have to manually delete them or change them to something like SVG or EPS. Apparently, there's a license issue with libpdflite (which gnuplot uses to generate PDFs)... so some distro's won't have it installed. Thanks, Gabriel

On Thu, 28 Jan 2010, Stéphane Letz wrote: Here's some ideas on how you might handle it: I don't know if gnuplot supports conditional structures or I/O... so that would be one way. Or possibly spit out all of: TimingN.plot, TimingN-pdf.plot, TimingN-svg.plot, etc. Another way would be to output a Python or Perl script to drive gnuplot (either by generating scripts or through something like popen2). What I'm about to do is patch my local jack2 to use SVG... which would be another option -- just pick a vectored format that is known to be portable. My preference: a single python script that allows me to plot any of the 5 graphs to the screen or to a file in any format that my installation of gnuplot supports. HTH, Gabriel