[linux-audio-user] Re: x86_64 and ingo's realtime patches, works?

[Mike Taht]

Over the last 3 days I conducted the most intense test of Ingo's
realtime patches I've
conducted to date.

Running 2.6.15-rt5 I have simultaneously running on a 1.8Ghz x86_64
Emachines laptop (1GB of memory), w 2displays enabled at 16 bit...
kernel compiled for no kernel debugging except CONFIG_DEBUG_DEADLOCKS:

Jackd (some version post .100)
Linuxsampler (from cvs about 2 months ago)
Rosegarden (also from cvs about 2 months ago)
HDSP sound interface configured at 96khz/128 frames
FC3 std apps:
KDE
Konqueror
Mozilla
Kopete
About 30 ssh tabs in various shell windows
mplayer playing directly from dvd to the laptop's sound card

Rosegarden playing multiple fairly complex midi hour+ long files into
linuxsampler with
the Bardstown 96khz 24  bit piano. The HDSP audio card is configured
for 96Khz 1.9 ms 128 frames...

480MB are out on swap as I write.

Linuxsampler is pulling it's samples from an ext3 formatted firewire drive

The dvd is coming from /dev/hdc.

The dvd's sound is perfect, except when the window is moved, and it
occasionally drops video frames under this workload.

92-100% of cpu is in use and has been in use for 8-16 hrs a day for
the last 3 days 4 hrs.

Linuxsampler's as perfect as it ever gets (I have some sections in
this piece that exaust the available voices and my (older) version of
linuxsampler doesn't  quite do voice stealing right)

Rosegarden's timing seems to be dead on, no matter what.

About the only weirdnesses I have are:

my typing (although perfectly interactive!) tends to make the frame
rate on mplayer much more jumpy.

Also, most of my USB devices disappeared early on, and won't come
back.  I doubt that's an RT related problem however. (If they were
still here, I'd try a few more devices - at the moment I'm going for a
workload that will crash the machine - with, so far, no luck)

mplayer occasionally gets hung upon looping a few frames for a few
seconds (no dvd access during that time), then continues. I don't
normally run video apps (me: audio biggot), but I'll twiddle with some
things on that after I post this mail... (boost /dev/hdc's irq? try a
different dvd? maybe try it on a less loaded box would be a start. :))

scp performance is dismal - less than a MB/sec on a 100Mbit network (I
have NO cpu left over, so this makes sense). Since most of my SCP's
over over the internet, this doesn't bother me.

Interactive (e.g. typing) performance is excellent. I have been
hacking all day for days without really noticing (aside from the
cacaphony!) that I have been running with a flatlined cpu. I do have
problems under this workload with marking text for copy and paste with
my touchpad. My guess on that one is that X could use a RT thread in
this case for device input...

The only tuning I did was to force jackd, rosegardensequencer, and the
RME IRQ to be realtime (-65,-64,-66 prios respectively)

Over these nearly 3 days of constant operation I've had about 41 xruns (as
best as I can tell, related to major program startup (things like
openoffice) and heavy
swapping). The maximum scheduling latency was 31.177 msec. Finding out
what caused it strikes me as an intensive exercise... and I don't
think anyone in their right mind would run a workload like this.

I'm going to keep it going for as long as I can...

My hat's off to Ingo. I am delighted to see some of this code
(mutexes/HRT) migrating into 2.6.16 mainline.


--
Mike Taht
PostCards From the Bleeding Edge
http://the-edge.blogspot.com