OK. Here goes my fresh and newly jack_test4.1 test suite. It might be still rough, as usual ;)
(Jack: this post is an new edited version of the same I sent you last weekend; sorry for the noise:) The main difference against jack_test3.2 goes into the specific test client (jack_test4_client.c). That is, the client chain now tries to resemble a real audio chain. The first client runs as a signal generator, pumping ou a pure sinusoidal 1Khz tone into all its ouput ports. The second and all following clients connect their input ports to the outputs of the preceding one. Each one of these clients work exactly as before, mixing all input into each output. Finally the last client of the chain, connects its output ports to the available terminal/physical inputs (e.g. alsa_pcm). This way the tone signal feeding can actually be heard on your speakers--but please take care of the effective output volume for not to hurt your precious ears :) The tone signal is specially in phase-sync along all client nodes, provided a sync pulse is propagated along the chain, but suppressed on that last node (the one which feeds the speakers). Each client, other than the first generator one, compares every single input frame against a self-generated one, checking for any extraneous noise/artifact. This difference is detected and exposed as a "Delta Maximum" value on the summary results--it should be always 0.00000, if not something really bad has occurred during the test. A fifth argument to the jack_test4_run.sh main script is also featured, giving the number of consecutive runs the whole test-chain-cycle is performed for the same jackd service session. The sixth argument is now the number of extra playback ports to be acquainted by jackd. Now the bad news . This new test-suite exposes a very nasty jackd behavior, which was rarely seen with the previous jack_test3.2 but now is pretty reproducible, at least on my laptop ([EMAIL PROTECTED]/UP) under Ingo's 2.6.11-rc1-RT-V0.7.35-01 (PREEMPT_RT). This phenomenon, so to speak, shows up as a sudden full increase of DSP/CPU load after a few minutes running jackd while perfectly normal and stable until that moment. Once that occurs, and it does now everytime I run jack_test4_run.sh with default parameters (14 clients, 4x4 ports), you end under a horrible XRUN storm--see attached chart--you can even hear it perfectly as the 1KHz audible tone burps and stutters, resembling radioactivity morse pulses. So it seems that this showstopper is an issue only under extreme loads, and is probably relative to the hardware you're running into. On my other [EMAIL PROTECTED]/HT desktop I could not reproduce this. Instead, I hit a rather older issue, which comes like the magic 14 client limit. As it seems, I now find trouble when starting more than 14 connected clients, as the jack_watchdog kills everything in sight beyhond that point. This wasn't happening with the jack_test3.2 suite, suspectedly because those clients weren't being connected to each other. Please check this out, and would you try at least to reproduce the naughty behavior such as the pictured on the attached chart? Now back on-topic :) Just some last lines about the iso2 patch. I know some of you will laught at me, but I've just gave it a try on merging it with Ingo's realtime-preempt. After some changes to Con's original (2.6.11-rc1-iso2.diff) I've reached a clean build, and the attached patch is the proof, which applies in the following sequence: linux-2.6.11-rc1.tar.bz2 + realtime-preempt-2.6.11-rc1-V0.7.35-01 + linux-2.6.11-rc1-RT-V0.7.35-iso2.patch.gz But... even though it booted fine, the resulting kernel just crashes immediately as soon as one remembers to run jackd -R :( If just someone finds this interesting... ;) So no joy no fun, eheheh. Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED]
jack_test4.1.tar.gz
Description: application/gzip-compressed
<<attachment: jack_test4-2.6.11-rc1-RT-V0.7.35-01.0-200501201044.png>>
linux-2.6.11-rc1-RT-V0.7.35-iso2.patch.gz
Description: application/gzip-compressed
