On Wed, Apr 16, 2014 at 9:53 PM, Jonathan E. Brickman <jeb@ponderworthy.com> wrote:

Thought the below might be of interest to some. The last is the best :-) Hardware and clients identical, octo 4GHz, test load is one yoshimi with jack_keyboard driving by way of a passthrough mididings.

-------------------------------

Item two is jack1-git, compiled with Zita libraries engaged, run like this:

nohup schedtool -R -p 50 -e /usr/bin/jackd -A SB -R -c h -X alsa_midi -d dummy -r 48000 -p 32 &

Reported latency is 2ms. Load-less, usage rating is 1.3% through 29%, usually hanging in at 1.4% or so. With the test load, it sits at 31.2% at silence. No xruns. But no actual sound came out :-)

Why are you using schedtool to run jackd ? In addition, I don't understand what this test is supposed to do. Why would you run jackd on the dummy device while using the zita bridge(s) to access an actual device? There is also no need to specify -R to jackd since it is the default.

Where would you expect sound to come from? What is connected to the ports represented by the zita bridges?

DSP load variance between1.3% and 29% under static conditions indicate problems with the setup. The value will never be precisely static but it should not vary by this much.

Running 3 yoshimi instances at once is specifically a good test for the multi-processor abilities of jack2, since it can run them all in parallel (which jack1 does not do). It is one of the scenarios in which jack2's capabilities in this area are a real benefit.

I really don't understand the goal here. Why not just run jack -d alsa -d hw:SB -r 48000 -p 32 ?