[lkml]   [2005]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling
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
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 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 (P4@2.5Ghz/UP) under Ingo's 2.6.11-rc1-RT-V0.7.35-01

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 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
P4@3.3Ghz/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:

+ 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.

rncbc aka Rui Nuno Capela

[unhandled content-type:application/x-gzip-compressed][unhandled content-type:image/x-png][unhandled content-type:application/x-gzip-compressed]
 \ /
  Last update: 2005-03-22 14:09    [W:0.245 / U:7.488 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site