8 Jul
2005
8 Jul
'05
10:45 a.m.
Hello LAU,
I've been battling with this problem for about a week now, have searched all
over the place and have still not found a solution. I'm hoping somebody on
this list can help me out...
Hardware is as follows:
Dell PE1800 Dual 2.8GHz EM64T w/1GB RAM
PERC4/SC RAID5 (configured with write-back caching - bonnie++ reports 50MB/s
block writes)
2x RME Multifaces (configured with Word clock sync/ADAT fiber cable for sync)
OS Specifics:
Gentoo Linux (fairly conservative CFLAGS=" -march=k8 -O3 -pipe")
Kernel version 2.6.12
XFS / filesystem
Goal:
Record 16 tracks using the 8 analogue inputs of the each of the two cards
simultaneously in ardour without any XRUNs.
Symptoms:
qjackctl reports hundreds of XRUNs when the system is sitting idle with
nothing more than the window manager (KDE 3.4.1) and Jack running. I can get
ardour to record if I tell it to ignore XRUNs, but that's obviously not what
I want. Strange thing is that jackd -v doesn't always report XRUNs that
ardour and qjackctl seem to complain about.
The different things I've tried:
1) Ingo Molnar's realtime-preempt-2.6.12-final-V0.7.51-06 patch (could only
get it to compile with full preempt on x86_64). I've tried this as well as
the standard Gentoo sources kernel without the patch - no apparent
difference.
2) With and without realtime-lsm (I tried using rtlimits too, but I'm not sure
that I had it setup correctly). The problem still occurs even if I run
everything as root - so I don't think it's a permissions/capabilities
problem. I've also tried various chrt -f priority levels for everything,
including using chrt -f -p 99 on the sound card IRQs. Strange thing is that
half of the KDE stuff (like kicker) also shows up with PR = RT in top, but
chrt reports SCHED_OTHER, priority 0 for all of these.
3) Synchronising the two multifaces with Word clock (at 48kHz) as well as ADAT
in (at both 48 and 96kHz). The problem is worse at 96kHz but it happens at
48kHz too - ultimately I would like to run a 96kHz configuration, but I
thought I'd try 48 too.
4) Various jackd settings (including various -R -P ? optional as well as all
-p options). Problem still occurs with -p 8192.
5) Various configurations in /etc/asound.conf for binding the two cards
together, but I must admit I don't really know what I'm doing here and
everything has been pieced together from examples on the web. I've attached
the current version of the file which has options for the 48 and 96kHz
configurations of the multifaces. I've also tried leaving the ADAT and SPDIF
channels out of the configuration, since I'm only interested in the analogue
inputs.
6) Tried jack and ardour without KDE running (under TWM) - no funny processes
with RT Priority in top, but problem still persists. I suspect it may only be
a bug in top tho', since chrt still shows sensible stuff.
7) I couldn't install Gentoo's media-sound/alsa-driver package against the
Ingo Molnar patched sources, but the problem is still there when I compile
alsa-driver separately (version 1.0.8 and 1.0.9b) using the standard gentoo
kernel sources.
8) With and without NPTL (I had NTPL enabled glibc installed until I read
about possible problems with it). I tried the LD_ASSUME_KERNEL work around
first and eventually even recompiled glibc with USE=-nptl.
9) Tried taking qjackctl out of the loop - running jackd manually - same
problem with ardour.
10) Recording all 18 channels with only one of the two multifaces configured
(tested both of them) works fine in all of the above configurations that I
tried it with - including without Ingo's RT patches.
I'm now totally lost. I've eliminated everything I can think of and don't know
what to try next. Any help would be greatly appreciated.
Thanks.
- Edwin
--
#include http://www.peer.co.za/~espeer/disclaimer.html
8 Jul
8 Jul
12:21 p.m.
New subject: [linux-audio-user] 2x RME Multifaces, ALSA, JACK & Ardour -> XRUNS?
Hi
I have only the RME Hammerfall and a DDX3216 desk.
I use 16 tracks on 2 adats into the PC running Fervent Software.
You may be able to borrow a Fervent CD and try this and see if you still
get the xruns.
This may be able to point you in the right direction.
I can record 16 tracks fine into ardour (when I configure the desk
correctly!!)
I was under the impression that the RME multi's were fully supported in
Linux.
Have you insured you have the RME drivers installed and loaded?
Are you running 64bit?
Your systems seems more than adequate for recording to Ardour.
Just a few thoughts
cheers
Bob
Edwin Peer wrote:
Hello LAU,
I've been battling with this problem for about a week now, have searched all
over the place and have still not found a solution. I'm hoping somebody on
this list can help me out...
Hardware is as follows:
Dell PE1800 Dual 2.8GHz EM64T w/1GB RAM
PERC4/SC RAID5 (configured with write-back caching - bonnie++ reports 50MB/s
block writes)
2x RME Multifaces (configured with Word clock sync/ADAT fiber cable for sync)
OS Specifics:
Gentoo Linux (fairly conservative CFLAGS=" -march=k8 -O3 -pipe")
Kernel version 2.6.12
XFS / filesystem
Goal:
Record 16 tracks using the 8 analogue inputs of the each of the two cards
simultaneously in ardour without any XRUNs.
Symptoms:
qjackctl reports hundreds of XRUNs when the system is sitting idle with
nothing more than the window manager (KDE 3.4.1) and Jack running. I can get
ardour to record if I tell it to ignore XRUNs, but that's obviously not what
I want. Strange thing is that jackd -v doesn't always report XRUNs that
ardour and qjackctl seem to complain about.
The different things I've tried:
1) Ingo Molnar's realtime-preempt-2.6.12-final-V0.7.51-06 patch (could only
get it to compile with full preempt on x86_64). I've tried this as well as
the standard Gentoo sources kernel without the patch - no apparent
difference.
2) With and without realtime-lsm (I tried using rtlimits too, but I'm not sure
that I had it setup correctly). The problem still occurs even if I run
everything as root - so I don't think it's a permissions/capabilities
problem. I've also tried various chrt -f priority levels for everything,
including using chrt -f -p 99 on the sound card IRQs. Strange thing is that
half of the KDE stuff (like kicker) also shows up with PR = RT in top, but
chrt reports SCHED_OTHER, priority 0 for all of these.
3) Synchronising the two multifaces with Word clock (at 48kHz) as well as ADAT
in (at both 48 and 96kHz). The problem is worse at 96kHz but it happens at
48kHz too - ultimately I would like to run a 96kHz configuration, but I
thought I'd try 48 too.
4) Various jackd settings (including various -R -P ? optional as well as all
-p options). Problem still occurs with -p 8192.
5) Various configurations in /etc/asound.conf for binding the two cards
together, but I must admit I don't really know what I'm doing here and
everything has been pieced together from examples on the web. I've attached
the current version of the file which has options for the 48 and 96kHz
configurations of the multifaces. I've also tried leaving the ADAT and SPDIF
channels out of the configuration, since I'm only interested in the analogue
inputs.
6) Tried jack and ardour without KDE running (under TWM) - no funny processes
with RT Priority in top, but problem still persists. I suspect it may only be
a bug in top tho', since chrt still shows sensible stuff.
7) I couldn't install Gentoo's media-sound/alsa-driver package against the
Ingo Molnar patched sources, but the problem is still there when I compile
alsa-driver separately (version 1.0.8 and 1.0.9b) using the standard gentoo
kernel sources.
8) With and without NPTL (I had NTPL enabled glibc installed until I read
about possible problems with it). I tried the LD_ASSUME_KERNEL work around
first and eventually even recompiled glibc with USE=-nptl.
9) Tried taking qjackctl out of the loop - running jackd manually - same
problem with ardour.
10) Recording all 18 channels with only one of the two multifaces configured
(tested both of them) works fine in all of the above configurations that I
tried it with - including without Ingo's RT patches.
I'm now totally lost. I've eliminated everything I can think of and don't know
what to try next. Any help would be greatly appreciated.
Thanks.
- Edwin
------------------------------------------------------------------------
pcm.hdsp_0 {
type hw;
card 0;
}
ctl.hdsp_0 {
type hw;
card 0;
}
pcm.hdsp_1 {
type hw;
card 1;
}
ctl.hdsp_1 {
type hw;
card 1;
}
# merged card - 96Hkz channel configuration
pcm.hdsp_96k {
type multi;
#analogue channels
slaves.a.pcm hdsp_0;
slaves.a.channels 14;
slaves.b.pcm hdsp_1;
slaves.b.channels 14;
bindings.0.slave a;
bindings.0.channel 0;
bindings.1.slave a;
bindings.1.channel 1;
bindings.2.slave a;
bindings.2.channel 2;
bindings.3.slave a;
bindings.3.channel 3;
bindings.4.slave a;
bindings.4.channel 4;
bindings.5.slave a;
bindings.5.channel 5;
bindings.6.slave a;
bindings.6.channel 6;
bindings.7.slave a;
bindings.7.channel 7;
bindings.8.slave b;
bindings.8.channel 0;
bindings.9.slave b;
bindings.9.channel 1;
bindings.10.slave b;
bindings.10.channel 2;
bindings.11.slave b;
bindings.11.channel 3;
bindings.12.slave b;
bindings.12.channel 4;
bindings.13.slave b;
bindings.13.channel 5;
bindings.14.slave b;
bindings.14.channel 6;
bindings.15.slave b;
bindings.15.channel 7;
#ADAT channels
bindings.16.slave a;
bindings.16.channel 8;
bindings.17.slave a;
bindings.17.channel 9;
bindings.18.slave a;
bindings.18.channel 10;
bindings.19.slave a;
bindings.19.channel 11;
bindings.20.slave b;
bindings.20.channel 8;
bindings.21.slave b;
bindings.21.channel 9;
bindings.22.slave b;
bindings.22.channel 10;
bindings.23.slave b;
bindings.23.channel 11;
#SPDIF channels
bindings.24.slave a;
bindings.24.channel 12;
bindings.25.slave a;
bindings.25.channel 13;
bindings.26.slave b;
bindings.26.channel 12;
bindings.27.slave b;
bindings.27.channel 13;
}
ctl.hdsp_96k {
type hw
card 0
}
# merged card - 48Hkz channel configuration
pcm.hdsp_48k {
type multi;
#analogue channels
slaves.a.pcm hdsp_0;
slaves.a.channels 18;
slaves.b.pcm hdsp_1;
slaves.b.channels 18;
bindings.0.slave a;
bindings.0.channel 0;
bindings.1.slave a;
bindings.1.channel 1;
bindings.2.slave a;
bindings.2.channel 2;
bindings.3.slave a;
bindings.3.channel 3;
bindings.4.slave a;
bindings.4.channel 4;
bindings.5.slave a;
bindings.5.channel 5;
bindings.6.slave a;
bindings.6.channel 6;
bindings.7.slave a;
bindings.7.channel 7;
bindings.8.slave b;
bindings.8.channel 0;
bindings.9.slave b;
bindings.9.channel 1;
bindings.10.slave b;
bindings.10.channel 2;
bindings.11.slave b;
bindings.11.channel 3;
bindings.12.slave b;
bindings.12.channel 4;
bindings.13.slave b;
bindings.13.channel 5;
bindings.14.slave b;
bindings.14.channel 6;
bindings.15.slave b;
bindings.15.channel 7;
#ADAT channels
bindings.16.slave a;
bindings.16.channel 8;
bindings.17.slave a;
bindings.17.channel 9;
bindings.18.slave a;
bindings.18.channel 10;
bindings.19.slave a;
bindings.19.channel 11;
bindings.20.slave a;
bindings.20.channel 12;
bindings.21.slave a;
bindings.21.channel 13;
bindings.22.slave a;
bindings.22.channel 14;
bindings.23.slave a;
bindings.23.channel 15;
bindings.24.slave b;
bindings.24.channel 8;
bindings.25.slave b;
bindings.25.channel 9;
bindings.26.slave b;
bindings.26.channel 10;
bindings.27.slave b;
bindings.27.channel 11;
bindings.28.slave b;
bindings.28.channel 12;
bindings.29.slave b;
bindings.29.channel 13;
bindings.30.slave b;
bindings.30.channel 14;
bindings.31.slave b;
bindings.31.channel 15;
#SPDIF channels
bindings.32.slave a;
bindings.32.channel 16;
bindings.33.slave a;
bindings.33.channel 17;
bindings.34.slave b;
bindings.34.channel 16;
bindings.35.slave b;
bindings.35.channel 17;
}
ctl.hdsp_48k {
type hw
card 0
}
pcm.ttable_96k {
type route;
slave.pcm "hdsp_96k";
ttable.0.0 1;
ttable.1.1 1;
ttable.2.2 1;
ttable.3.3 1;
ttable.4.4 1;
ttable.5.5 1;
ttable.6.6 1;
ttable.7.7 1;
ttable.8.8 1;
ttable.9.9 1;
ttable.10.10 1;
ttable.11.11 1;
ttable.12.12 1;
ttable.13.13 1;
ttable.14.14 1;
ttable.15.15 1;
ttable.16.16 1;
ttable.17.17 1;
ttable.18.18 1;
ttable.19.19 1;
ttable.20.20 1;
ttable.21.21 1;
ttable.22.22 1;
ttable.23.23 1;
ttable.24.24 1;
ttable.25.25 1;
ttable.26.26 1;
ttable.27.27 1;
}
ctl.ttable_96k {
type hw;
card = 0;
}
pcm.ttable_48k {
type route;
slave.pcm "hdsp_48k";
ttable.0.0 1;
ttable.1.1 1;
ttable.2.2 1;
ttable.3.3 1;
ttable.4.4 1;
ttable.5.5 1;
ttable.6.6 1;
ttable.7.7 1;
ttable.8.8 1;
ttable.9.9 1;
ttable.10.10 1;
ttable.11.11 1;
ttable.12.12 1;
ttable.13.13 1;
ttable.14.14 1;
ttable.15.15 1;
ttable.16.16 1;
ttable.17.17 1;
ttable.18.18 1;
ttable.19.19 1;
ttable.20.20 1;
ttable.21.21 1;
ttable.22.22 1;
ttable.23.23 1;
ttable.24.24 1;
ttable.25.25 1;
ttable.26.26 1;
ttable.27.27 1;
ttable.28.28 1;
ttable.29.29 1;
ttable.30.30 1;
ttable.31.31 1;
ttable.32.32 1;
ttable.33.33 1;
ttable.34.34 1;
ttable.35.35 1;
}
ctl.ttable_48k {
type hw;
card = 0;
}
--
F R Smith
Technical Admin
http://www.Rokpacardiff.com
1:38 p.m.
New subject: [linux-audio-user] 2x RME Multifaces, ALSA, JACK & Ardour -> XRUNS?
On Friday 08 July 2005 16:20, Frank smith wrote:
I use 16 tracks on 2 adats into the PC running Fervent
Software.
What is Fervent?
You may be able to borrow a Fervent CD and try this
and see if you still
get the xruns.
That sounds like a great idea, I've even been tempted to install Windows on
the box just to see if the Windows software can handle the hardware
configuration. But that's not an ideal solution - since I would have to trash
the existing data on the machine to do it.
I was under the impression that the RME multi's
were fully supported in
Linux.
They are. I think. Using only one of the two cards works fine.
Have you insured you have the RME drivers installed
and loaded?
I think so. HDSPConf see's both of them. I can also capture from both. The
only problem is the XRUNs.
Are you running 64bit?
Yes, is that a problem?
Your systems seems more than adequate for recording to
Ardour.
I thought so too, but I'm really struggling with this. :(
I've been doing some further investigating...
I gather there are two places where XRUNs happen:
1) ALSA <--> JACK
2) JACK <--> JACK client
From what I've been seeing when I play with the
IRQ, JACK and qjackctl
priorites with chrt and the realtime-preempt kernel, I can
cause the first
type by making the IRQ priority lower than JACK. jackd -v logs this as an
alsa XRUN. The second type is the problem I'm experiencing. Nothing shows in
the jackd -v output, but the client (qjackctl) sees XRUNs - usually a hundred
or so of them every few seconds.
:espeer:
--
#include http://www.peer.co.za/~espeer/disclaimer.html
5:28 p.m.
New subject: [linux-audio-user] 2x RME Multifaces, ALSA, JACK & Ardour -> XRUNS?
Hi Edwin
Give Fervent software.com a look:
http://www.ferventsoftware.com
I got a disk from them and you can run from the CD to check stuff out.
I then installed it to the HD and it's been running ever since.
I recorded the song below using it ( Ardour - jammin)
At least you may get some help from Chris
seems quick on the mails as support.
Cheers
Bob
Edwin Peer wrote:
On Friday 08 July 2005 16:20, Frank smith wrote:
--
F R Smith
Technical Admin
http://www.Rokpacardiff.com
I use 16 tracks on 2 adats into the PC running
Fervent Software.
What is Fervent?
You may be able to borrow a Fervent CD and try
this and see if you still
get the xruns.
That sounds like a great idea, I've even been tempted to install Windows on
the box just to see if the Windows software can handle the hardware
configuration. But that's not an ideal solution - since I would have to trash
the existing data on the machine to do it.
I was under the impression that the RME
multi's were fully supported in
Linux.
They are. I think. Using only one of the two cards works fine.
Have you insured you have the RME drivers
installed and loaded?
I think so. HDSPConf see's both of them. I can also capture from both. The
only problem is the XRUNs.
Are you running 64bit?
Yes, is that a problem?
Your systems seems more than adequate for
recording to Ardour.
I thought so too, but I'm really struggling with this. :(
I've been doing some further investigating...
I gather there are two places where XRUNs happen:
1) ALSA <--> JACK
2) JACK <--> JACK client
From what I've been seeing when I play with
the IRQ, JACK and qjackctl
priorites with chrt and the realtime-preempt kernel, I
can cause the first
type by making the IRQ priority lower than JACK. jackd -v logs this as an
alsa XRUN. The second type is the problem I'm experiencing. Nothing shows in
the jackd -v output, but the client (qjackctl) sees XRUNs - usually a hundred
or so of them every few seconds.
:espeer:
7081
days inactive
7081
days old
linux-audio-user@lists.linuxaudio.org
3 comments
2 participants
participants (2)
-
Edwin Peer -
Frank smith