6 Sep
2005
6 Sep
'05
9:36 p.m.
I bought an RME Digi96/8 PST because it was said to have good Linux support
and very low latency, therefore perfectly suitable for hd-recording and
the like.
It's driven by the alsa rme96 driver, and right now I'm configuring it for
use with jack. Only to realize that it can only be set to either 1024
frames and 8 periods or 256 frames and 32 periods, resulting in a
calculated latency of 186 msec either way (displayed by qjackctl). Strikes
me. Isn't that absolutely unacceptable for hd-recording use?
This information is confirmed by the corresponding alsa documentation at
http://alsa.opensrc.org/rme96 .
There is a small note on that page that leaves some hope; it's
basically saying that in jack versions > 0.99.0, I could "create" e.g. 32
periods, but "use" much less, "resulting in much lower latency".
Therefore
I'm now using jack 0.100.1 with Kernel 2.6.12 and alsa 1.0.9b. Still the
only two working configurations are 1024/8 and 256/32; when I try to
reduce periods, I get lots of errors like this (detailed output attached
at the end of the mail):
delay of 139318.000 usecs exceeds estimated spare time of 5769.000;
restart ...
Any ideas about how to obtain a working low latency configuration? Or do I
have to dump the card? Anyone here using that card in a hd-recording
setup?
Cheers
Michael
Detailed output (-p 256 -n 32 works):
$ jackd -R -P 5 -t 2000 -u -d alsa -P -r 44100 -p 256 -n 8 -m -H -M
jackd 0.100.1
[snipped copyright notice]
JACK compiled with System V SHM support.
loading driver ..
apparent rate = 44100
creating alsa driver ... hw:0|-|256|8|44100|0|0|hwmon|hwmeter|-|32bit
control device hw:0
configuring for 44100Hz, period = 256 frames, buffer = 8 periods
nperiods = 32 for playback
too many consecutive interrupt delays ... engine pausing
cycle execution failure, exiting
DRIVER NT: could not run driver cycle
delay of 139318.000 usecs exceeds estimated spare time of 5769.000;
restart ...
delay of 139318.000 usecs exceeds estimated spare time of 5769.000;
restart ...
6 Sep
6 Sep
10:50 p.m.
On Wed, 2005-09-07 at 01:36 +0200, Michael Rudolf wrote:
I bought an RME Digi96/8 PST because it was said to
have good Linux support
and very low latency, therefore perfectly suitable for hd-recording and
the like.
where does it say this? the digi96/8 is an entirely different product
(different h/w design, different chipset, different interactions with
the host CPU) from the digi9652, HDSP and HDSP9652 systems. this latter
range is well supported and works exceedingly well on almost all
systems. the digi96/8 has support, but it does not work particularly
well, especially not for low latency work (this is not because of the
driver design (other than the overall way that ALSA works), but because
of the h/w design).
as for issues with xruns and delays, you need to tell us what kernel,
what distribution, and what version of ALSA.
--p
7 Sep
7 Sep
2:34 a.m.
On Tue, 2005-09-06 at 20:51 -0400, Paul Davis wrote:
On Wed, 2005-09-07 at 01:36 +0200, Michael Rudolf
wrote:
He probably just got the impression that all non-firewire RME stuff was
well supported under Linux. That's what I thought...
How exactly does the hardware design not play nice with ALSA? Does it
need variable period sizes to do low latency? It seems like the ASIO
drivers must be able to do < 3-5 ms on Windows or it would not be
marketable...
Lee
I bought an RME Digi96/8 PST because it was said
to have good Linux support
and very low latency, therefore perfectly suitable for hd-recording and
the like.
where does it say this? the digi96/8 is an entirely different product
(different h/w design, different chipset, different interactions with
the host CPU) from the digi9652, HDSP and HDSP9652 systems. this latter
range is well supported and works exceedingly well on almost all
systems. the digi96/8 has support, but it does not work particularly
well, especially not for low latency work (this is not because of the
driver design (other than the overall way that ALSA works), but because
of the h/w design). 
8 Sep
8 Sep
7:51 a.m.
Lee Revell wrote:
On Tue, 2005-09-06 at 20:51 -0400, Paul Davis wrote:
HI
I too thought this of RME, their website is a bit ambiguous to say the
least.
I can say the cheap(!?) Hammerfall lite I have works on all the Linux
system I have used, with very low latencies.
He should contact RME direct and let us know the outcome, they seem to
be a Linux friendly company.
Bob
On Wed, 2005-09-07 at 01:36 +0200, Michael Rudolf
wrote:
He probably just got the impression that all non-firewire RME stuff was
well supported under Linux. That's what I thought...
I bought an RME Digi96/8 PST because it was said
to have good Linux support
and very low latency, therefore perfectly suitable for hd-recording and
the like.
where does it say this? the digi96/8 is an entirely different product
(different h/w design, different chipset, different interactions with
the host CPU) from the digi9652, HDSP and HDSP9652 systems. this latter
range is well supported and works exceedingly well on almost all
systems. the digi96/8 has support, but it does not work particularly
well, especially not for low latency work (this is not because of the
driver design (other than the overall way that ALSA works), but because
of the h/w design). How exactly does the hardware design not play nice
with ALSA? Does it
need variable period sizes to do low latency? It seems like the ASIO
drivers must be able to do < 3-5 ms on Windows or it would not be
marketable...
Lee
--
Bearmusic
hearmymusic.co.uk <http:www.hearmymusic.co.uk>
3:20 p.m.
On Thu, Sep 08, 2005 at 10:50:53AM +0100, studio-64 wrote:
Lee Revell wrote:
>On Tue, 2005-09-06 at 20:51 -0400, Paul Davis wrote:
>>On Wed, 2005-09-07 at 01:36 +0200, Michael Rudolf wrote:
>>>I bought an RME Digi96/8 PST because it was said to have good Linux
>>>support and very low latency, therefore perfectly suitable for
>>>hd-recording and the like.
>>where does it say this? the digi96/8 is an entirely different product
>>(different h/w design, different chipset, different interactions with
>>the host CPU) from the digi9652, HDSP and HDSP9652 systems. this latter
>>range is well supported and works exceedingly well on almost all
>>systems. the digi96/8 has support, but it does not work particularly
>>well, especially not for low latency work (this is not because of the
>>driver design (other than the overall way that ALSA works), but because
>>of the h/w design).
We have a boatload of RME Digi96/8 PADs here at RFA. We're starting to
use them in linux boxes. I'm not sure what exactly the differences
between the PSTs and PADs are, but so far it appears the PAD supports
only 1024 x 2 or 256 x 2. At least, those are the only two combinations
I can start jack with when using one of these cards.
--
Eric Dantan Rzewnicki | Systems Administrator
Technical Operations Division | Radio Free Asia
2025 M Street, NW | Washington, DC 20036 | 202-530-4900
CONFIDENTIAL COMMUNICATION
This e-mail message is intended only for the use of the addressee and
may contain information that is privileged and confidential. Any
unauthorized dissemination, distribution, or copying is strictly
prohibited. If you receive this transmission in error, please contact
network(a)rfa.org.
10:02 p.m.
Eric Dantan Rzewnicki wrote:
We have a boatload of RME Digi96/8 PADs here at RFA.
We're starting to
use them in linux boxes. I'm not sure what exactly the differences
between the PSTs and PADs are, but so far it appears the PAD supports
only 1024 x 2 or 256 x 2. At least, those are the only two combinations
I can start jack with when using one of these cards.
PAD has AES/EBU as XLR, otherwise they are the same. What do you mean by "x
2"? For me, it's 1024 x 8 or 256 x 32 as in frames x periods.
Btw, I got the latency down to 85.3 ms by increasing the sample rate to 96
kHz. Still no luck with lowering periods.
Michael
10:37 p.m.
On Fri, 2005-09-09 at 02:02 +0200, Michael Rudolf wrote:
Eric Dantan Rzewnicki wrote:
Yes, 1024 or 256 frames at 2 periods per buffer. Did you try this at
every sample rate?
Lee
We have a boatload of RME Digi96/8 PADs here at
RFA. We're starting to
use them in linux boxes. I'm not sure what exactly the differences
between the PSTs and PADs are, but so far it appears the PAD supports
only 1024 x 2 or 256 x 2. At least, those are the only two combinations
I can start jack with when using one of these cards.
PAD has AES/EBU as XLR, otherwise they are the same. What do you mean by "x
2"? For me, it's 1024 x 8 or 256 x 32 as in frames x periods.
Btw, I got the latency down to 85.3 ms by increasing the sample rate to 96
kHz. Still no luck with lowering periods.
10:51 p.m.
On Thu, Sep 08, 2005 at 08:37:19PM -0400, Lee Revell wrote:
On Fri, 2005-09-09 at 02:02 +0200, Michael Rudolf
wrote:
I've only tried at 48KHz
Eric Dantan Rzewnicki wrote:
Yes, 1024 or 256 frames at 2 periods per
buffer. Did you try this at
every sample rate? We have a boatload of RME Digi96/8 PADs here at
RFA. We're starting to
use them in linux boxes. I'm not sure what exactly the differences
between the PSTs and PADs are, but so far it appears the PAD supports
only 1024 x 2 or 256 x 2. At least, those are the only two combinations
I can start jack with when using one of these cards.
PAD has AES/EBU as XLR,
otherwise they are the same. What do you mean by "x
2"? For me, it's 1024 x 8 or 256 x 32 as in frames x periods.
Btw, I got the latency down to 85.3 ms by increasing the sample rate to 96
kHz. Still no luck with lowering periods.
10:49 p.m.
On Fri, Sep 09, 2005 at 02:02:07AM +0200, Michael Rudolf wrote:
Eric Dantan Rzewnicki wrote:
interesting. i meant 1024 frames, 2 periods and 256 frames, 2 periods.
sorry for the excessive terseness. What versions of alsa and jackd?
kernel 2.6.13, alsa-1.0.9, jack 0.100.0
debian sarge (mostly) with a few things (alsa, jack, libsndfile, etc.)
backported from etch.
We have a boatload of RME Digi96/8 PADs here at
RFA. We're starting to
use them in linux boxes. I'm not sure what exactly the differences
between the PSTs and PADs are, but so far it appears the PAD supports
only 1024 x 2 or 256 x 2. At least, those are the only two combinations
I can start jack with when using one of these cards.
PAD has AES/EBU as XLR,
otherwise they are the same. What do you mean by "x
2"? For me, it's 1024 x 8 or 256 x 32 as in frames x periods.
Btw, I got the latency down to 85.3 ms by increasing the sample rate to 96
kHz. Still no luck with lowering periods.
9:55 p.m.
studio-64 wrote:
Lee Revell wrote:
Well yes, they are not very clear as to the differentiation of their cards,
i.e. what card is good for what kind of use. I even got a printed ad here
where they're marketing the digi96/8 series as "the all-in-one tool for
professional harddisk recording".
He probably just got the impression that all
non-firewire RME stuff
was well supported under Linux. That's what I thought...
HI
I too thought this of RME, their website is a bit ambiguous to say the
least. I can say the cheap(!?) Hammerfall lite I have works
on all the Linux
system I have used, with very low latencies.
Still digital I/O only, right?
He should contact RME direct and let us know the
outcome, they seem to
be a Linux friendly company.
I'm not quite sure what I should expect from them. They won't trade in my
card since I bought it used, and I'm not too positive they will supply me
with a low latency driver for Linux ;)
Lee Revell wrote:
> How exactly does the hardware design not play nice with ALSA? Does it
> need variable period sizes to do low latency? It seems like the ASIO
> drivers must be able to do < 3-5 ms on Windows or it would not be
> marketable...
I've found several usenet articles suggesting the Digi96/8 is capable of
latencies < 10 ms at least on Windows.
Michael
10:45 p.m.
On Fri, Sep 09, 2005 at 01:54:50AM +0200, Michael Rudolf wrote:
studio-64 wrote:
I'm able to run the digi96/8 pad at 2 periods of 256 frames at 48kHz. I
think that corresponds to ~10 ms for playback latency and ~5ms for
capture latency. That is, if I'm understanding the jackd manpage
correctly ...
Lee Revell wrote:
Well yes, they are not very clear as to the differentiation of their cards,
i.e. what card is good for what kind of use. I even got a printed ad here
where they're marketing the digi96/8 series as "the all-in-one tool for
professional harddisk recording".
He probably just got the impression that all
non-firewire RME stuff
was well supported under Linux. That's what I thought...
HI
I too thought this of RME, their website is a bit ambiguous to say the
least. I can say the cheap(!?) Hammerfall lite I have
works on all the Linux
system I have used, with very low latencies.
Still digital I/O only, right?
He should contact RME direct and let us know the
outcome, they seem to
be a Linux friendly company.
I'm not quite sure what I should expect from
them. They won't trade in my
card since I bought it used, and I'm not too positive they will supply me
with a low latency driver for Linux ;)
> Lee Revell wrote:
> > How exactly does the hardware design not play nice with ALSA? Does it
> > need variable period sizes to do low latency? It seems like the ASIO
> > drivers must be able to do < 3-5 ms on Windows or it would not be
> > marketable...
6:24 p.m.
Paul Davis wrote:
On Wed, 2005-09-07 at 01:36 +0200, Michael Rudolf
wrote:
Thanks for the info Paul. So do you say the digi96/8 is significantly less
well supported on Linux than the Hammerfall/HDSP? If so, shouldn't that
info be on alsa soundcard matrix?
Since the Hammerfall series didn't seem appropriate for my needs (digital
I/O only, high cost), it seemed that the digi96/8 and the M-Audio Delta
1010 LT would be good alternatives. Would the 1010 LT have been the better
choice? What other alternatives are there for hd recording on Linux when
Hammerfall/HDSP is not an option?
I bought an RME Digi96/8 PST because it was said
to have good Linux
support and very low latency, therefore perfectly suitable for
hd-recording and the like.
where does it say this? the digi96/8 is an entirely different product
(different h/w design, different chipset, different interactions with
the host CPU) from the digi9652, HDSP and HDSP9652 systems. this latter
range is well supported and works exceedingly well on almost all
systems. the digi96/8 has support, but it does not work particularly
well, especially not for low latency work (this is not because of the
driver design (other than the overall way that ALSA works), but because
of the h/w design). as for issues with xruns and delays, you need to tell
us what kernel,
what distribution, and what version of ALSA.
Sound Driver:3.8.1a-980706 (ALSA v1.0.9b emulation code)
Kernel: Linux neurose 2.6.12-oci2.mdk with realtime lsm module and
PREEMPT/PREEMPT_BKL enabled. Distribution is PCLinuxOS P91 fully updated
and with the Jack packages from thac
(jackit-0.100.1-050708.1.pclo2005.thac).
Thanks
Michael
6:51 p.m.
On Thu, 2005-09-08 at 22:23 +0200, Michael Rudolf wrote:
Thanks for the info Paul. So do you say the digi96/8
is significantly
less well supported on Linux than the Hammerfall/HDSP? If so,
shouldn't that info be on alsa soundcard matrix?
People should really know by now to NEVER EVER just buy hardware based
only on consulting the soundcard matrix. At least google for it and
find some reports from users.
Lee
10:32 p.m.
Lee Revell wrote:
People should really know by now to NEVER EVER just
buy hardware based
only on consulting the soundcard matrix. At least google for it and
find some reports from users.
I tried to leave a note with what I have learned by now on
http://www.alsa-project.org/alsa-doc/doc-php/template.php?company=RME&c…
but I'm not sure it will show up since I received some kind of error
message in the browser. I already informed the webmaster about this.
10:44 p.m.
On Fri, 2005-09-09 at 02:32 +0200, Michael Rudolf wrote:
Lee Revell wrote:
I'm not even sure what that is. Does the soundcard matrix have a
mechanism to submit a change?
The recommended way to submit a correction for the soundcard matrix is
the ALSA bug tracker:
https://bugtrack.alsa-project.org/alsa-bug/main_page.php
Lee
People should really know by now to NEVER EVER
just buy hardware based
only on consulting the soundcard matrix. At least google for it and
find some reports from users.
I tried to leave a note with what I have learned by now on
http://www.alsa-project.org/alsa-doc/doc-php/template.php?company=RME&c…
but I'm not sure it will show up since I received some kind of error
message in the browser. I already informed the webmaster about this.
10:50 p.m.
On Thu, Sep 08, 2005 at 08:44:20PM -0400, Lee Revell wrote:
On Fri, 2005-09-09 at 02:32 +0200, Michael Rudolf
wrote:
There's a thing at the bottom of each soundcard page that's supposed to
let people add notes about a given card. Some people had added stuff
like alternative .asoundrc's for various cards.
Lee Revell wrote:
I'm not
even sure what that is. Does the soundcard matrix have a
mechanism to submit a change? People should really know by now to NEVER EVER
just buy hardware based
only on consulting the soundcard matrix. At least google for it and
find some reports from users.
I tried to leave a note with what I have learned by
now on
http://www.alsa-project.org/alsa-doc/doc-php/template.php?company=RME&c…
but I'm not sure it will show up since I received some kind of error
message in the browser. I already informed the webmaster about this. The recommended way to submit a correction for the
soundcard matrix is
the ALSA bug tracker:
https://bugtrack.alsa-project.org/alsa-bug/main_page.php
11:01 p.m.
On 9/6/05, Michael Rudolf <mich.rudolf(a)gmx.de> wrote:
I bought an RME Digi96/8 PST because it was said to
have good Linux support
and very low latency, therefore perfectly suitable for hd-recording and
the like.
It's driven by the alsa rme96 driver, and right now I'm configuring it for
use with jack. Only to realize that it can only be set to either 1024
frames and 8 periods or 256 frames and 32 periods, resulting in a
calculated latency of 186 msec either way (displayed by qjackctl). Strikes
me. Isn't that absolutely unacceptable for hd-recording use?
This information is confirmed by the corresponding alsa documentation at
http://alsa.opensrc.org/rme96 .
There is a small note on that page that leaves some hope; it's
basically saying that in jack versions > 0.99.0, I could "create" e.g. 32
periods, but "use" much less, "resulting in much lower latency".
Therefore
I'm now using jack 0.100.1 with Kernel 2.6.12 and alsa 1.0.9b. Still the
only two working configurations are 1024/8 and 256/32; when I try to
reduce periods, I get lots of errors like this (detailed output attached
at the end of the mail):
delay of 139318.000 usecs exceeds estimated spare time of 5769.000;
restart ...
Any ideas about how to obtain a working low latency configuration? Or do I
have to dump the card? Anyone here using that card in a hd-recording
setup?
Cheers
Michael
Hi,
I'm the guy who tries to keep that page up-to-date. I use the Digi 96/8 PAD.
I've found the card to work quite well. While it may not have as many
bells and whistles as the Hammerfall series, I've not run into any
problems with it for quite some time. Most issues I had with it have
been fixed for almost 2 years now.
I've run jack with reduced number of periods without any problem.
You're output lookes like you have issues elsewhere though to fix
before worrying about the numer of periods you use. The xruns,
messages about interrupt delays, and driver messages suggest you have
problems that need fixed berfore jack will ever work well, reguardelss
of the number of periods you use.
Paul Davis wrote:
where does it say this? the digi96/8 is an entirely
different product
(different h/w design, different chipset, different interactions with
the host CPU) from the digi9652, HDSP and HDSP9652 systems. this latter
range is well supported and works exceedingly well on almost all
systems. the digi96/8 has support, but it does not work particularly
well, especially not for low latency work (this is not because of the
driver design (other than the overall way that ALSA works), but because
of the h/w design
I don't know enough to comment on h/w design or driver design, I just
know I've been able to use JACK with this driver at very low latencies
without X-Runs.
If I can help in providing specific info, let me know. :)
-Reuben
11:10 p.m.
On Thu, Sep 08, 2005 at 08:01:16PM -0500, Reuben Martin wrote:
On 9/6/05, Michael Rudolf <mich.rudolf(a)gmx.de>
wrote:
I'm the guy who tries to keep that page up-to-date. I use the Digi 96/8 PAD.
I've found the card to work quite well. While it may not have as many
bells and whistles as the Hammerfall series, I've not run into any
problems with it for quite some time. Most issues I had with it have
been fixed for almost 2 years now.
I've run jack with reduced number of periods without any problem.
You're output lookes like you have issues elsewhere though to fix
before worrying about the numer of periods you use. The xruns,
messages about interrupt delays, and driver messages suggest you have
problems that need fixed berfore jack will ever work well, reguardelss
of the number of periods you use.
Paul Davis wrote:
And if there are any specific problems with the drivers, let me know as
we have so many I'm sure management could be persuaded to let us spend
some time testing, debugging and fixing stuff.
where does it say this? the digi96/8 is an
entirely different product
(different h/w design, different chipset, different interactions with
the host CPU) from the digi9652, HDSP and HDSP9652 systems. this latter
range is well supported and works exceedingly well on almost all
systems. the digi96/8 has support, but it does not work particularly
well, especially not for low latency work (this is not because of the
driver design (other than the overall way that ALSA works), but because
of the h/w design
I don't know enough to comment on h/w design or driver
design, I just
know I've been able to use JACK with this driver at very low latencies
without X-Runs.
If I can help in providing specific info, let me know. :)
11 Sep
11 Sep
1:11 a.m.
On Friday 09 September 2005 03:10, Eric Dantan Rzewnicki wrote:
This mailing list is amazing. Thanks for all the info; it sounds promising.
This is my configuration again:
Sound Driver:3.8.1a-980706 (ALSA v1.0.9b emulation code)
Kernel: 2.6.12-oci2.mdk with realtime lsm module and
PREEMPT/PREEMPT_BKL enabled. Distribution is PCLinuxOS P91 fully updated
and with the Jack packages from thac
(jackit-0.100.1-050708.1.pclo2005.thac).
On Thu, Sep 08, 2005 at 08:01:16PM -0500, Reuben
Martin wrote:
[..]
> I've run jack with reduced number of periods
without any problem.
> You're output lookes like you have issues elsewhere though to fix
> before worrying about the numer of periods you use. The xruns,
> messages about interrupt delays, and driver messages suggest you have
> problems that need fixed berfore jack will ever work well, reguardelss
> of the number of periods you use.
[..]
I don't
know enough to comment on h/w design or driver design, I just
know I've been able to use JACK with this driver at very low latencies
without X-Runs.
If I can help in providing specific info, let me know. :)
And if there are any specific problems with the drivers, let me know as
we have so many I'm sure management could be persuaded to let us spend
some time testing, debugging and fixing stuff. From what I have read by now, it seems that preempt and
realtime is not
enough; what I'd need would be "realtime preemption",
as in a single patch
by Ingo Molnar (http://people.redhat.com/mingo/realtime-preempt/). I also
seem to be missing the "chrt" tool to change interrupt priorities, and
don't know yet where to obtain that.
Eric and Reuben, are you both running 2.6.13 with said patch and the chrt
tool?
Another point is shared memory; I have that enabled in the kernel, I have a
tmpfs mounted on /dev/shm, and Jack is compiled with support ("JACK
compiled with System V SHM support."), but I have read that Jack uses /tmp
for pipes per default, and I can in fact see some
in /tmp/jack-[uid]/default/. Now /tmp is a normal ext3 file system here,
not a tmpfs. Could that alone be the problem?
Michael
2:18 a.m.
On Sun, 2005-09-11 at 05:11 +0200, Michael Rudolf wrote:
Another point is shared memory; I have that enabled in
the kernel, I
have a
tmpfs mounted on /dev/shm, and Jack is compiled with support ("JACK
compiled with System V SHM support."), but I have read that Jack
uses /tmp
for pipes per default, and I can in fact see some
in /tmp/jack-[uid]/default/. Now /tmp is a normal ext3 file system
here,
not a tmpfs. Could that alone be the problem?
Yes, that is almost certainly the problem.
The /tmp entry in /etc/fstab should look like this:
tmpfs /tmp tmpfs defaults 0 0
Any decent distro should do this by default.
Lee
12:10 p.m.
Lee Revell wrote:
Yes, that is almost certainly the problem.
The /tmp entry in /etc/fstab should look like this:
tmpfs /tmp tmpfs defaults 0
0
Unfortunately, that didn't seem to help - I get the same symptoms as before
(attached below).
I'm heading for a 2.6.13 kernel with realtime-preempt patch now. I'm afraid
this is going to get complicated because of rtlimits/PAM setup. Still
don't know where to get the "chrt" tool from.
Michael
This is a typical verbose output of qjackctl, in this case running as root:
16:05:44.901 /usr/bin/jackd -v -R -P60 -p64 -t10000 -dalsa -dhw:0,0 -r48000
-p1024 -n2 -P -o2
16:05:44.908 JACK was started with PID=14435 (0x3863).
getting driver descriptor from /usr/lib/jack/jack_alsa.so
getting driver descriptor from /usr/lib/jack/jack_dummy.so
getting driver descriptor from /usr/lib/jack/jack_oss.so
getting driver descriptor from /usr/lib/jack/jack_portaudio.so
jackd 0.100.1
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
server `default' registered
registered builtin port type 32 bit float mono audio
running with uid=0 and euid=0, will not try to use capabilites
loading driver ..
new client: alsa_pcm, id = 1 type 1 @ 0x8059780 fd = -1
apparent rate = 48000
creating alsa driver ... hw:0,0|-|1024|2|48000|0|2|nomon|swmeter|-|32bit
control device hw:0
configuring for 48000Hz, period = 1024 frames, buffer = 2 periods
nperiods = 8 for playback
new buffer size 1024
registered port alsa_pcm:playback_1, offset = 0
registered port alsa_pcm:playback_2, offset = 0
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
-- jack_rechain_graph()
14435 waiting for signals
late driver wakeup: nframes to process = 7168.
late driver wakeup: nframes to process = 7168.
late driver wakeup: nframes to process = 7168.
late driver wakeup: nframes to process = 7168.
late driver wakeup: nframes to process = 7168.
late driver wakeup: nframes to process = 7168.
late driver wakeup: nframes to process = 7168.
load = 0.1031 max usecs: 44.000, spare = 21289.000
delay of 127940.000 usecs exceeds estimated spare time of 21289.000;
restart ...
late driver wakeup: nframes to process = 7168.
delay of 106612.000 usecs exceeds estimated spare time of 21289.000;
restart ...
delay of 106612.000 usecs exceeds estimated spare time of 21289.000;
restart ...
delay of 106612.000 usecs exceeds estimated spare time of 21289.000;
restart ...
delay of 106612.000 usecs exceeds estimated spare time of 21289.000;
restart ...
5 p.m.
On Sun, 2005-09-11 at 16:10 +0200, Michael Rudolf wrote:
Lee Revell wrote:
Just use the realtime LSM. The rtlimits/PAM stuff is not ready yet
(glibc needs to catch up, until then it's just a hack).
Lee
Yes, that is almost certainly the problem.
The /tmp entry in /etc/fstab should look like this:
tmpfs /tmp tmpfs defaults 0
0
Unfortunately, that didn't seem to help - I get the same symptoms as before
(attached below).
I'm heading for a 2.6.13 kernel with realtime-preempt patch now. I'm afraid
this is going to get complicated because of rtlimits/PAM setup.
8:16 p.m.
Lee Revell wrote:
On Sun, 2005-09-11 at 16:10 +0200, Michael Rudolf
wrote:
> I'm heading for a 2.6.13 kernel with realtime-preempt patch now. I'm
> afraid this is going to get complicated because of rtlimits/PAM setup.
Vanilla 2.6.13.1 kernel + Ingo Molnar realtime preemption patch did not
help either. Still only 1024/8 and 256/32 work. Very strange. Still have
to check "chrt", but I'm beginning to suspect the problem lies somewhere
else. Maybe I should try to build jack from source, too.
Just use the realtime LSM. The rtlimits/PAM stuff is
not ready yet
(glibc needs to catch up, until then it's just a hack).
Is there a realtime lsm patch for 2.6.13? I thought rtlimits was standard
with 2.6.13. For testing I just ran Jack as root.
Eric, Reuben, would be nice to hear some more details about your working
setups.
Michael
8:32 p.m.
On Mon, 2005-09-12 at 00:16 +0200, Michael Rudolf wrote:
Lee Revell wrote:
Yes the same realtime LSM patch for 2.6.12 and 2.6.11 works with 2.6.13.
And rtlimits is standard with 2.6.13 but none of the distros that ship
2.6.13 have updated their userspace yet so it's very difficult to use
for now.
Yes this is a bug and should be reported as such.
Lee
Just use the realtime LSM. The rtlimits/PAM
stuff is not ready yet
(glibc needs to catch up, until then it's just a hack).
Is there a realtime lsm patch for 2.6.13? I thought rtlimits was standard
with 2.6.13. For testing I just ran Jack as root.
11:10 p.m.
Eric, Reuben, would be nice to hear some more details about your working
setups.
My current setup is kernel 2.6.12.6 with the gentoo-sources patchset
plus the realtime-preemption patch. I have both realtime-LSM and
rtlimits. (With PAM patched for rtlimits) I'm using Jack 0.100.4.
I doubt chrt will do much for you, although you're welcome to try it.
I've never needed to use it.
Messages like "late driver wakeup" would lead me to think this an alsa
driver problem, or possible an IRQ problem.
I would start by looking at your alsa driver and how it is set up. Do
you have more than I sound device? If so, are you sure that the RME
96/32 is hw:0 ? Is the alsa driver loaded as a module or built into
the kernel? For that matter, are you sure you have your kernel
configured correctly? You patched it, but what settings did you use?
Do non jack apps give you problems when playing back audio? How are
IRQs set up in your kernel? (Are you using APIC?) Is the sound card
sharing IRQs?
Right now I think your kernel config is highly suspect since it seems
you're somewhat new to kernel configs. Secondary suspect is your
system setup. (I know nothing of how the PCLinuxOS distro is
configured)
Maybe I should try to build jack from source, too.
I always build mine by hand. That way I know for sure how it's been
configured, and there are a lot of build options with Jack that can
drastically change how it behaves.
-Reuben
12 Sep
12 Sep
4:52 p.m.
On Sun, Sep 11, 2005 at 03:00:53PM -0400, Lee Revell wrote:
On Sun, 2005-09-11 at 16:10 +0200, Michael Rudolf
wrote:
I thought it was just pam that needed changing to use the rt rlimits.
What needs to be done in glibc?
I have patched pam packages for debian sarge on techweb.rfa.org/debrfa/
which seem to be working fine for me with 2.6.13.
--
Eric Dantan Rzewnicki | Systems Administrator
Technical Operations Division | Radio Free Asia
2025 M Street, NW | Washington, DC 20036 | 202-530-4900
CONFIDENTIAL COMMUNICATION
This e-mail message is intended only for the use of the addressee and
may contain information that is privileged and confidential. Any
unauthorized dissemination, distribution, or copying is strictly
prohibited. If you receive this transmission in error, please contact
network(a)rfa.org.
Lee Revell wrote:
Just use the
realtime LSM. The rtlimits/PAM stuff is not ready yet
(glibc needs to catch up, until then it's just a hack). Yes, that is almost certainly the problem.
The /tmp entry in /etc/fstab should look like this:
tmpfs /tmp tmpfs defaults 0
0
Unfortunately, that didn't seem to help - I get the same symptoms as before
(attached below).
I'm heading for a 2.6.13 kernel with realtime-preempt patch now. I'm afraid
this is going to get complicated because of rtlimits/PAM setup.
5:06 p.m.
On Mon, 2005-09-12 at 14:51 -0400, Eric Dantan Rzewnicki wrote:
On Sun, Sep 11, 2005 at 03:00:53PM -0400, Lee Revell
wrote:
Check the glibc development mailing list for details. The new rlimits
are supported in their development branch IIRC.
On Sun, 2005-09-11 at 16:10 +0200, Michael Rudolf
wrote:
I thought it was just pam that needed changing to use the rt rlimits.
What needs to be done in glibc?
Lee Revell wrote:
Just use the
realtime LSM. The rtlimits/PAM stuff is not ready yet
(glibc needs to catch up, until then it's just a hack). Yes, that is almost certainly the problem.
The /tmp entry in /etc/fstab should look like this:
tmpfs /tmp tmpfs defaults 0
0
Unfortunately, that didn't seem to help - I get the same symptoms as before
(attached below).
I'm heading for a 2.6.13 kernel with realtime-preempt patch now. I'm afraid
this is going to get complicated because of rtlimits/PAM setup. I have patched pam packages for debian sarge on
techweb.rfa.org/debrfa/
which seem to be working fine for me with 2.6.13.
PAM is supposed to get the list of rlimits from glibc. Patching PAM
directly is just a hack/workaround.
Lee
11:49 p.m.
On Mon, 2005-09-12 at 14:51 -0400, Eric Dantan
Rzewnicki wrote:
> I thought it was just pam that needed changing to use the rt rlimits.
> What needs to be done in glibc?
Lee Revell <rlrevell(a)joe-job.com> writes:
Check the glibc development mailing list for details.
The new rlimits
are supported in their development branch IIRC.
And don't forget all the shells. The `ulimits' command is a shell
built-in. For full support all new resources need to be added there,
as well. I wonder if they get it from glibc, too? Sigh!
--
joq
I have patched pam packages for debian sarge on
techweb.rfa.org/debrfa/
which seem to be working fine for me with 2.6.13.
PAM is supposed to get the list of rlimits from glibc. Patching PAM
directly is just a hack/workaround.
14 Sep
14 Sep
4:01 p.m.
On Mon, Sep 12, 2005 at 03:06:09PM -0400, Lee Revell wrote:
I see. At the moment it seems to be a useable workaround. But, it's good
to know that it is not a permament solution.
--
Eric Dantan Rzewnicki | Systems Administrator
Technical Operations Division | Radio Free Asia
2025 M Street, NW | Washington, DC 20036 | 202-530-4900
CONFIDENTIAL COMMUNICATION
This e-mail message is intended only for the use of the addressee and
may contain information that is privileged and confidential. Any
unauthorized dissemination, distribution, or copying is strictly
prohibited. If you receive this transmission in error, please contact
network(a)rfa.org.
On Mon, 2005-09-12 at 14:51 -0400, Eric Dantan
Rzewnicki wrote:
ok. I'll try to find some time to look at the glibc list archive.
On Sun, Sep 11, 2005 at 03:00:53PM -0400, Lee
Revell wrote:
Check the glibc development mailing list for
details. The new rlimits
are supported in their development branch IIRC. On Sun, 2005-09-11 at 16:10 +0200, Michael Rudolf
wrote:
I thought it was just
pam that needed changing to use the rt rlimits.
What needs to be done in glibc? Lee Revell wrote:
> Yes, that is almost certainly the problem.
> The /tmp entry in /etc/fstab should look like this:
> tmpfs /tmp tmpfs defaults 0
> 0
Unfortunately, that didn't seem to help - I get the same symptoms as before
(attached below).
I'm heading for a 2.6.13 kernel with realtime-preempt patch now. I'm afraid
this is going to get complicated because of rtlimits/PAM setup.
Just use the
realtime LSM. The rtlimits/PAM stuff is not ready yet
(glibc needs to catch up, until then it's just a hack). I have patched
pam packages for debian sarge on techweb.rfa.org/debrfa/
which seem to be working fine for me with 2.6.13.
PAM is supposed to get the list
of rlimits from glibc. Patching PAM
directly is just a hack/workaround. 
12 Sep
12 Sep
5:54 p.m.
On 9/11/05, Michael Rudolf <mich.rudolf(a)gmx.de> wrote:
late driver wakeup: nframes to process = 7168.
delay of 106612.000 usecs exceeds estimated spare time of 21289.000;
restart ...
delay of 106612.000 usecs exceeds estimated spare time of 21289.000;
restart ...
delay of 106612.000 usecs exceeds estimated spare time of 21289.000;
restart ...
delay of 106612.000 usecs exceeds estimated spare time of 21289.000;
restart ...
Sorry, didn't read the whole thread, so apologies if this comment is useless ;-)
I also run a rme96 Soundcard (The DIGI96/8 PST... got it for free ^_^)
and also had the problem, that I got xruns all the time. It turned
out, that I needed to activate the Analog Input in Alsa, when nothing
is connected to the digital Inputs!:
$ amixer cset numid=5 3
Well, my latency is still bad, but I didn't have enough time yet to
resolve it, and haven't done any recording with it yet... but at
least, this solved my xrun-Problem...
HTH,
-Michael
13 Sep
13 Sep
6:35 p.m.
On Mon, Sep 12, 2005 at 09:53:59PM +0200, Michael Wagner wrote:
On 9/11/05, Michael Rudolf <mich.rudolf(a)gmx.de>
wrote:
I can confirm this as well. It seems if the card is set to digital input
and no external digital device is connected it doesn't know what sample
rate it's supposed to use. Thanks for mentioning it Michael. I had
forgotten this detail.
You can set the control with alsamixer or rmedigicontrol from alsa-tools
as well as with the amixer command Michael posted.
--
Eric Dantan Rzewnicki | Systems Administrator
Technical Operations Division | Radio Free Asia
2025 M Street, NW | Washington, DC 20036 | 202-530-4900
CONFIDENTIAL COMMUNICATION
This e-mail message is intended only for the use of the addressee and
may contain information that is privileged and confidential. Any
unauthorized dissemination, distribution, or copying is strictly
prohibited. If you receive this transmission in error, please contact
network(a)rfa.org.
late driver wakeup: nframes to process = 7168.
delay of 106612.000 usecs exceeds estimated spare time of 21289.000;
restart ...
delay of 106612.000 usecs exceeds estimated spare time of 21289.000;
restart ...
delay of 106612.000 usecs exceeds estimated spare time of 21289.000;
restart ...
delay of 106612.000 usecs exceeds estimated spare time of 21289.000;
restart ...
Sorry, didn't read the whole thread, so apologies if this comment
is useless ;-)
I also run a rme96 Soundcard (The DIGI96/8 PST... got it for free ^_^)
and also had the problem, that I got xruns all the time. It turned
out, that I needed to activate the Analog Input in Alsa, when nothing
is connected to the digital Inputs!:
$ amixer cset numid=5 3
Well, my latency is still bad, but I didn't have enough time yet to
resolve it, and haven't done any recording with it yet... but at
least, this solved my xrun-Problem... 
14 Sep
14 Sep
4:51 p.m.
Lee Revell wrote:
On Sun, 2005-09-11 at 05:11 +0200, Michael Rudolf
wrote:
These discussions makes me think and before I guess too much, I'ld
better ask:
When enabling in ardour 0.9beta29 Display -> Show waveforms while
recording I see a steady increase in memory occupation during recording
(10 channels) 'till my ram is exhausted: ardour/jack are crashing. I run
a patched 2.6.13-rc7 kernel. But:
Now, I think, could it be, that ardour needs for the wave-forms display
proportional to the recording memory in /dev/shm (which is limited to
half the physical ram). At long recordings, this will crash. Could it
be, that jack should not be compiled to run with tmpfs, but instead
should be compiled to run with a tmp file system on ext2. ext2 I have
already for the wave data.
Will a DAW need miminum two partitions with different file systems, one
journalling for everything and an ext2 for the critical audio data? Is
this the way to go in future?
Or is this linear memory increase during recording/displaying wave forms
something for the ardour list?
BTW: ardour is great,
Regards,
Georg
Another point is shared memory; I have that
enabled in the kernel, I
have a
tmpfs mounted on /dev/shm, and Jack is compiled with support ("JACK
compiled with System V SHM support."), but I have read that Jack
uses /tmp
for pipes per default, and I can in fact see some
in /tmp/jack-[uid]/default/. Now /tmp is a normal ext3 file system
here,
not a tmpfs. Could that alone be the problem?
Yes, that is almost certainly the problem.
The /tmp entry in /etc/fstab should look like this:
tmpfs /tmp tmpfs defaults 0 0
Any decent distro should do this by default.
Lee
6:19 p.m.
On Wed, 2005-09-14 at 20:51 +0200, Georg Rudolph wrote:
When enabling in ardour 0.9beta29 Display -> Show
waveforms while
recording I see a steady increase in memory occupation during recording
(10 channels) 'till my ram is exhausted: ardour/jack are crashing. I run
a patched 2.6.13-rc7 kernel. But:
i believe this was fixed in beta30.
Now, I think, could it be, that ardour needs for the
wave-forms display
proportional to the recording memory in /dev/shm (which is limited to
half the physical ram).
absolutely not. every waveform display object on the screen uses a cache
of pixel data that is twice the width of the X display, or the length of
the audio region, whichever is smaller. the requirements for waveform
display do not increase linearly with duration.
be, that jack should not be compiled to run with
tmpfs, but instead
should be compiled to run with a tmp file system on ext2. ext2 I have
already for the wave data.
you are missing the entire reason for using tmpfs. it has nothing to do
with wave display or audio. JACK uses FIFO's to wake up clients; it does
so by writing single bytes to these FIFO's. if they are placed in a
regular filesystem, this requires going through the code for (say) ext2
filesystem access, which has locks and other nasty non-RT friendly
components. using tmpfs means that i/o to FIFOs like this does not cause
xruns.
11 Sep
11 Sep
11:59 a.m.
Michael Rudolf <mich.rudolf(a)gmx.de>de>:
missing the "chrt" tool to change interrupt
priorities, and don't
know yet where to obtain that.
chrt is part of Robert Love's "schedutils" which became part of
"util-linux" (ftp://ftp.kernel.org/pub/linux/utils/util-linux/)
12:11 p.m.
Wolfgang Woehl wrote:
chrt is part of Robert Love's
"schedutils" which became part of
"util-linux" (ftp://ftp.kernel.org/pub/linux/utils/util-linux/)
Ah thanks! I will look into it.
Michael
12 Sep
12 Sep
4:50 p.m.
On Sun, Sep 11, 2005 at 05:11:19AM +0200, Michael Rudolf wrote:
On Friday 09 September 2005 03:10, Eric Dantan
Rzewnicki wrote:
I'm using 2.6.13 without additional patches. PREEMPT and PREEMPT_BKL
seem to be sufficient.
in debian the chrt tool is in the schedutils package. But, I only use it
to check the priorities. I haven't had a need to change them in a
properly configured system. jackd gets SCHED_FIFO just fine here without
me needing to manually adjust anything with chrt.
On Thu, Sep 08, 2005 at 08:01:16PM -0500, Reuben
Martin wrote:
This mailing list is amazing.
Thanks for all the info; it sounds promising.
This is my configuration again:
Sound Driver:3.8.1a-980706 (ALSA v1.0.9b emulation code)
Kernel: 2.6.12-oci2.mdk with realtime lsm module and
PREEMPT/PREEMPT_BKL enabled. Distribution is PCLinuxOS P91 fully updated
and with the Jack packages from thac
(jackit-0.100.1-050708.1.pclo2005.thac).
I've run jack with reduced number of periods
without any problem.
You're output lookes like you have issues elsewhere though to fix
before worrying about the numer of periods you use. The xruns,
messages about interrupt delays, and driver messages suggest you have
problems that need fixed berfore jack will ever work well, reguardelss
of the number of periods you use.
I don't know enough to comment on h/w design or driver design, I just
know I've been able to use JACK with this driver at very low latencies
without X-Runs.
If I can help in providing specific info, let me know. :)
And if there are any
specific problems with the drivers, let me know as
we have so many I'm sure management could be persuaded to let us spend
some time testing, debugging and fixing stuff. From what I have read by now, it seems that
preempt and realtime is not
enough; what I'd need would be "realtime
preemption", as in a single patch
by Ingo Molnar (http://people.redhat.com/mingo/realtime-preempt/). I also
seem to be missing the "chrt" tool to change interrupt priorities, and
don't know yet where to obtain that.
Eric and Reuben, are you both running 2.6.13 with said patch and the chrt
tool? Another point is shared memory; I have that enabled in
the kernel, I have a
tmpfs mounted on /dev/shm, and Jack is compiled with support ("JACK
compiled with System V SHM support."), but I have read that Jack uses /tmp
for pipes per default, and I can in fact see some
in /tmp/jack-[uid]/default/. Now /tmp is a normal ext3 file system here,
not a tmpfs. Could that alone be the problem?
I compile jack --with-default-tmpdir=/dev/shm since /dev/shm gets
automatically mounted as tmpfs when tmpfs is enabled in the kernel
config. As Lee has said, having your jackd tmpdir on ext3 is sure to
cause you latency problems.
--
Eric Dantan Rzewnicki | Systems Administrator
Technical Operations Division | Radio Free Asia
2025 M Street, NW | Washington, DC 20036 | 202-530-4900
CONFIDENTIAL COMMUNICATION
This e-mail message is intended only for the use of the addressee and
may contain information that is privileged and confidential. Any
unauthorized dissemination, distribution, or copying is strictly
prohibited. If you receive this transmission in error, please contact
network(a)rfa.org.
8 Sep
8 Sep
11:16 p.m.
I forgot to include, for the sake of reference, a reference to the
mailing list to show when this functionality became available.
http://sourceforge.net/mailarchive/message.php?msg_id=10078162
-Reuben
7015
days inactive
7023
days old
linux-audio-user@lists.linuxaudio.org
36 comments
10 participants
participants (10)
-
Eric Dantan Rzewnicki -
Georg Rudolph -
Jack O'Quin -
Lee Revell -
Michael Rudolf -
Michael Wagner -
Paul Davis -
Reuben Martin -
studio-64 -
Wolfgang Woehl