18 Decan xrun (latency) killer: -S with jack2

Been playing with the newer Jack, jack2.  It’s available in Debian Experimental repos, complete with firewire drivers.  The default install gave me slight real advantage, although the CPU behavior under htop (like ‘top’, but reports individual CPUs) was intriguing.  Then Joakim Hernberg, on the Linux Audio Users‘ list, posted the following link:

http://www.grame.fr/~letz/Timing.pdf

I read it about five times, trying to ponder what my first step might be given its info. It discusses two major modes of jack2: the default, which is asynchronous, and another, which is synchronous. Under asynch, my stress-test yields zero xruns (or close) at 5.3 ms (as reported in Qjackctl); but under synch, I have found very good stability at a setting for 1.33 ms!  *grin* Quite shocking. That synch makes a whole lot of difference. I can just imagine jack2 jockeying all four CPUs to make that happen :-)  I praise the Lord, and I thank everyone for the help!

4 Responses to “an xrun (latency) killer: -S with jack2”

  1. Guru Prasad says:

    Jonathan, I completely concur with your observation. Jack2 is indeed an xrun killer. And the improved stability is also quite noticable on single core systems – I’m seeing stable performance using Linuxsampler on my old Celeron notebook! . Thanks for the heads-up!
    Cheers,
    Guru

  2. You are most welcome, Guru :-) And thanks for writing. I will be moving linuxlive to a new server very shortly, but all the pages should stay up. Not sure about URLs though.

  3. fitzhugh says:

    I think the following sheds some light on the reason for async/sync modes and, specifically, why async runs slower:

    http://orford.org/assets/jack.php – near the bottom under framedropping:
    …Stephane Letz has implemented this feature [framedropping to avoid booting slow clients when you want elegant degradation more than 100% perfection], ju as part of the
    alternative Jack implemtation, Jackdmp (jackd-multi-processor).
    Jackdmp calls this “asynchronous activation mode”.
    It adds an extra ‘process-cycle’ to allow for failed clients.
    http://www.grame.fr/Recherche/Publications/list/list.php?lang=fr contains
    a technical paper with the details. It works by timeslicing each period
    into multiple parts, and each cpu core is allocated all the nodes for one
    of the timeslices.

  4. admin says:

    Wow. Have you found anything interesting to adjust using this info? And do you use async, or sync? :-)

Place your comment

Please fill your data and comment below.
Name
Email
Website
Your comment