30 Sep
2007
30 Sep
'07
12:02 p.m.
On Debian Etch, using kernel 2.6.18-5-686, which I presume is a realtime one,
as when I start jack with qjackctl, and with the realtime box checked, jack
doesn't complain.
Looking at messages though, shows lots of xruns, although no music apps are
being used.
I had this problem on Fedora 7. I'd installed the low latency kernel, and
associated packages from planetccrma, and again jacks messages were showing
lots of xruns. There was an updated pam that came with the kernel download,
which left an /etc/security/limits.conf.rpmnew, and Fernando suggested adding
the changes to the existing file, as the default setup for
jack-audio-connection-kit in the limits.conf file set rtprio at 20.
That resolved the problem on Fedora 7. No more messages about xruns.
I tried the same few lines, as below, in the limits.conf file in Etch, but to
no success, and there are no default priorities for jack there anyway.
# limit realtime and memory locking access to users in the group audio
# there is no way to say "allow locking all memory", 4G should be enough
#
#* - rtprio 0
#* - nice 0
#
#@audio - rtprio 99
#@audio - nice -10
#@audio - memlock 4000000
# or (default) allow everyone access
* - rtprio 99
* - nice -10
* - memlock 4000000
I don't have the realtime-lsm package installed on Etch yet, as I wanted to
get opinions from the list first.
Thanks for any help/suggestions.
Nigel.
jackd is version 0.101.1-2 on Etch
qjackctl is version 0.2.21-1
30 Sep
30 Sep
12:10 p.m.
On Sun, 2007-09-30 at 16:02 +0200, Nigel Henry wrote:
On Debian Etch, using kernel 2.6.18-5-686, which I
presume is a realtime one,
as when I start jack with qjackctl, and with the realtime box checked, jack
doesn't complain.
You presume incorrectly. There are no realtime kernels in the main
Debian repositories, and a patched kernel would have the version suffix
-rtX. I don't know when jackd was changed to refuse to start with -R
unless it could actually get realtime scheduling, but it was fairly
recent - if you're using 0.101.1 it will probably start anyway.
--ll
12:13 p.m.
On Sun, 2007-09-30 at 16:09 +0200, Lars Luthman wrote:
On Sun, 2007-09-30 at 16:02 +0200, Nigel Henry wrote:
Sorry for confusing things - you can of course get realtime scheduling
without having an RT-patched kernel. It's hard to get jackd to run
xrun-free without it though.
--ll
On Debian Etch, using kernel 2.6.18-5-686, which
I presume is a realtime one,
as when I start jack with qjackctl, and with the realtime box checked, jack
doesn't complain.
You presume incorrectly. There are no realtime kernels in the main
Debian repositories, and a patched kernel would have the version suffix
-rtX. I don't know when jackd was changed to refuse to start with -R
unless it could actually get realtime scheduling, but it was fairly
recent - if you're using 0.101.1 it will probably start anyway.
12:37 p.m.
On Sunday 30 September 2007 16:11, Lars Luthman wrote:
On Sun, 2007-09-30 at 16:09 +0200, Lars Luthman
wrote:
> On Sun, 2007-09-30 at 16:02 +0200, Nigel Henry wrote:
> > On Debian Etch, using kernel 2.6.18-5-686, which I presume is a
> > realtime one, as when I start jack with qjackctl, and with the realtime
> > box checked, jack doesn't complain.
>
> You presume incorrectly. There are no realtime kernels in the main
> Debian repositories, and a patched kernel would have the version suffix
> -rtX. I don't know when jackd was changed to refuse to start with -R
> unless it could actually get realtime scheduling, but it was fairly
> recent - if you're using 0.101.1 it will probably start anyway.
I'd got so used to jack complaining when trying to use realtime, when it
wasn't available, that I presumed it was still the same, and the kernel was
realtime. I should have got used to the rt suffix by now, having used the
patched kernels from planetccrma for so long.
Sorry for confusing things - you can of course get realtime scheduling
without having an RT-patched kernel. It's hard to get jackd to run
xrun-free without it though.
So what your saying, is that the realtime-lsm package of scripts may not be
too successful.
Do you know if there are any debian rt patched kernels available for other
debian based distros, that might work on Etch, or Lenny?
--ll
Thanks for the reply.
Nigel.
12:48 p.m.
On Sun, 2007-09-30 at 16:37 +0200, Nigel Henry wrote:
So what your saying, is that the realtime-lsm package
of scripts may not be
too successful.
realtime-lsm is not needed on recent kernels, it does the same thing as
the PAM rlimits. It just lets you run processes with realtime scheduling
and lock memory as a normal user, it will not remove the long code paths
in the kernel that block the CPU when JACK might need it. For that you
need the RT-patch.
Do you know if there are any debian rt patched kernels
available for other
debian based distros, that might work on Etch, or Lenny?
Sorry, no idea. I just download the latest kernel from kernel.org, patch
it, and build it with the .config file from the latest Debian kernel
package (modified to turn on full preemption and threaded IRQ handlers)
using make-kpkg.
--ll
2:15 p.m.
On Sun, 30 Sep 2007 16:37:35 +0200
Nigel Henry <cave.dnb(a)tiscali.fr> wrote:
On Sunday 30 September 2007 16:11, Lars Luthman
wrote:
64studio (V2) is based on debian etch and comes in 64 & 32 bit
versions. It is fully RT patched.
--
Will J Godfrey
http://www.musically.me.uk
On Sun, 2007-09-30 at 16:09 +0200, Lars Luthman
wrote:
> On Sun, 2007-09-30 at 16:02 +0200, Nigel Henry wrote:
> > On Debian Etch, using kernel 2.6.18-5-686, which I presume is a
> > realtime one, as when I start jack with qjackctl, and with the realtime
> > box checked, jack doesn't complain.
>
> You presume incorrectly. There are no realtime kernels in the main
> Debian repositories, and a patched kernel would have the version suffix
> -rtX. I don't know when jackd was changed to refuse to start with -R
> unless it could actually get realtime scheduling, but it was fairly
> recent - if you're using 0.101.1 it will probably start anyway.
I'd got so used to jack complaining when trying to use realtime, when it
wasn't available, that I presumed it was still the same, and the kernel was
realtime. I should have got used to the rt suffix by now, having used the
patched kernels from planetccrma for so long.
Sorry for confusing things - you can of course get realtime scheduling
without having an RT-patched kernel. It's hard to get jackd to run
xrun-free without it though.
So what your saying, is that the realtime-lsm package of scripts may not be
too successful.
Do you know if there are any debian rt patched kernels available for other
debian based distros, that might work on Etch, or Lenny?
--ll
Thanks for the reply.
Nigel.
2:57 p.m.
On Sunday 30 September 2007 18:14, Folderol wrote:
On Sun, 30 Sep 2007 16:37:35 +0200
Nigel Henry <cave.dnb(a)tiscali.fr> wrote:
Hi Will. I thought you were going to plug 64studio before I looked at your
reply. I really wanted to resolve the problem on Debian Etch, and Lenny, but
will have to give 64studio a try.
iso.linuxquestions.org list it, but only the x86_64 version, and only v1.0.
Thankfully there are only 2 cd iso's, and shouldn't take too long on dialup.
I've just been to the 64studio site, but doh, it's only available as a dvd
download for 32bit, and I have a problem with dvd's, like no dvd writer.
Thanks for the reply. I'll keep looking for cd iso's.
Nigel.
On Sunday 30 September 2007 16:11, Lars Luthman
wrote:
64studio (V2) is based on debian etch and comes in 64 & 32 bit
versions. It is fully RT patched. On Sun, 2007-09-30 at 16:09 +0200, Lars Luthman
wrote:
> On Sun, 2007-09-30 at 16:02 +0200, Nigel Henry wrote:
> > On Debian Etch, using kernel 2.6.18-5-686, which I presume is a
> > realtime one, as when I start jack with qjackctl, and with the
> > realtime box checked, jack doesn't complain.
>
> You presume incorrectly. There are no realtime kernels in the main
> Debian repositories, and a patched kernel would have the version
> suffix -rtX. I don't know when jackd was changed to refuse to start
> with -R unless it could actually get realtime scheduling, but it was
> fairly recent - if you're using 0.101.1 it will probably start
> anyway.
I'd got so used to jack complaining when trying to use realtime, when it
wasn't available, that I presumed it was still the same, and the kernel
was realtime. I should have got used to the rt suffix by now, having used
the patched kernels from planetccrma for so long.
Sorry for confusing things - you can of course
get realtime scheduling
without having an RT-patched kernel. It's hard to get jackd to run
xrun-free without it though.
So what your saying, is that the realtime-lsm package of scripts may not
be too successful.
Do you know if there are any debian rt patched kernels available for
other debian based distros, that might work on Etch, or Lenny?
--ll
Thanks for the reply.
Nigel. 
1 Oct
1 Oct
2:45 a.m.
El Domingo, 30 de Septiembre de 2007 18:57, Nigel Henry escribió:
| On Sunday 30 September 2007 18:14, Folderol wrote:
| > On Sun, 30 Sep 2007 16:37:35 +0200
| >
| > Nigel Henry <cave.dnb(a)tiscali.fr> wrote:
| > > On Sunday 30 September 2007 16:11, Lars Luthman wrote:
| > > > On Sun, 2007-09-30 at 16:09 +0200, Lars Luthman wrote:
| > > > > On Sun, 2007-09-30 at 16:02 +0200, Nigel Henry wrote:
| > > > > > On Debian Etch, using kernel 2.6.18-5-686, which I presume is
a
| > > > > > realtime one, as when I start jack with qjackctl, and with
the
| > > > > > realtime box checked, jack doesn't complain.
| > > > >
| > > > > You presume incorrectly. There are no realtime kernels in the main
| > > > > Debian repositories, and a patched kernel would have the version
| > > > > suffix -rtX. I don't know when jackd was changed to refuse to
| > > > > start with -R unless it could actually get realtime scheduling,
| > > > > but it was fairly recent - if you're using 0.101.1 it will
| > > > > probably start anyway.
| > >
| > > I'd got so used to jack complaining when trying to use realtime, when
| > > it wasn't available, that I presumed it was still the same, and the
| > > kernel was realtime. I should have got used to the rt suffix by now,
| > > having used the patched kernels from planetccrma for so long.
| > >
| > > > Sorry for confusing things - you can of course get realtime
| > > > scheduling without having an RT-patched kernel. It's hard to get
| > > > jackd to run xrun-free without it though.
| > >
| > > So what your saying, is that the realtime-lsm package of scripts may
| > > not be too successful.
| > >
| > > Do you know if there are any debian rt patched kernels available for
| > > other debian based distros, that might work on Etch, or Lenny?
| > >
| > > > --ll
| > >
| > > Thanks for the reply.
| > >
| > > Nigel.
| >
| > 64studio (V2) is based on debian etch and comes in 64 & 32 bit
| > versions. It is fully RT patched.
|
| Hi Will. I thought you were going to plug 64studio before I looked at your
| reply. I really wanted to resolve the problem on Debian Etch, and Lenny,
| but will have to give 64studio a try.
|
| iso.linuxquestions.org list it, but only the x86_64 version, and only
| v1.0. Thankfully there are only 2 cd iso's, and shouldn't take too long on
| dialup.
|
| I've just been to the 64studio site, but doh, it's only available as a dvd
| download for 32bit, and I have a problem with dvd's, like no dvd writer.
|
| Thanks for the reply. I'll keep looking for cd iso's.
|
| Nigel.
|
Hi, also you can add Musix GNU/Linux's repositories (debian/etch compatible)
# /etc/apt/sources.list Musix GNU+Linux
deb ftp://musix.ourproject.org/pub/musix/deb/ ./
So you can install rt kernels on you Debian/ECTH, and upgrade Ardour to 2.1,
jackd to 0.103...
regards
--
Marcos Guglielmetti, co-director de Musix GNU+Linux, 100% Software Libre
Sitio Web: http://www.musix.org.ar
+ Archivos: ftp://musix.ourproject.org/pub/musix
Ecología: http://autosus.wordpress.com
Personal: http://marcospcmusica.wordpress.com
Noticias: http://www.mastermagazine.info
11:48 a.m.
On Monday 01 October 2007 01:42, Marcos Guglielmetti wrote:
El Domingo, 30 de Septiembre de 2007 18:57, Nigel
Henry escribió:
| On Sunday 30 September 2007 18:14, Folderol wrote:
| > On Sun, 30 Sep 2007 16:37:35 +0200
| >
| > Nigel Henry <cave.dnb(a)tiscali.fr> wrote:
| > > Do you know if there are any debian rt
patched kernels available for
| > > other debian based distros, that might work on Etch, or Lenny?
| Nigel.
Hi, also you can add Musix GNU/Linux's repositories (debian/etch
compatible)
# /etc/apt/sources.list Musix GNU+Linux
deb ftp://musix.ourproject.org/pub/musix/deb/ ./
So you can install rt kernels on you Debian/ECTH, and upgrade Ardour to
2.1, jackd to 0.103...
regards
Hi Marcos. I'm about to download one of your kernels at the moment. I presume
that I also need rtirq, as I do with planetccrma, and will need to
edit /etc/security/limits.conf.
Thanks for making the rt kernels available.
Nigel.
7:46 p.m.
On Monday 01 October 2007 01:42, Marcos Guglielmetti wrote:
Hi, also you can add Musix GNU/Linux's
repositories (debian/etch
compatible)
# /etc/apt/sources.list Musix GNU+Linux
deb ftp://musix.ourproject.org/pub/musix/deb/ ./
So you can install rt kernels on you Debian/ECTH, and upgrade Ardour to
2.1, jackd to 0.103...
regards
Sorry for replying to my previous reply with everything now snipped.
I've downloaded, and installed kernel 2.6.21rt4, 2.6.21.5rt18, and rtirq, but
am still getting xruns when starting jackd in qjackctl. An xrun about every 3
secs, and that's with no music apps being used.
Is there anything else I need to do to get zero xruns when starting jackd?
Do I need to edit /etc/security/limits.conf for example, as I had to do for
Fedora 7? As default this file has everything commented out in Etch, but this
file in Fedora 7 already had some lines for jack-audio-connection-kit set up
as default, but only with a rtprio of 20. The updated pam that came down when
installing the planetccrma low latency kernel, left a limits.conf.rpmnew with
higher priorities. I added these to the existing limits.conf file, commenting
out the defaults, and now when starting jack on Fedora 7, I have zero xruns.
I still get the odd xrun when running a music app, but nothing when jack is
started with no music apps being used. I've put a bit of jack's messages
output below.
23:41:07.577 Audio connection change.
23:41:07.585 Audio connection graph change.
delay of 26942.000 usecs exceeds estimated spare time of 11397.000;
restart ...
23:41:09.026 XRUN callback (1).
delay of 65588.000 usecs exceeds estimated spare time of 11397.000;
restart ...
delay of 12403.000 usecs exceeds estimated spare time of 11397.000;
restart ...
23:41:09.632 XRUN callback (2 skipped).
delay of 20107.000 usecs exceeds estimated spare time of 11349.000;
restart ...
**** alsa_pcm: xrun of at least 0.044 msecs
23:41:12.320 XRUN callback (4).
23:41:13.728 XRUN callback (1 skipped).
delay of 70451.000 usecs exceeds estimated spare time of 11326.000;
restart ...
23:41:14.276 XRUN callback (6).
delay of 66210.000 usecs exceeds estimated spare time of 11417.000;
restart ...
23:41:19.406 XRUN callback (7).
delay of 66172.000 usecs exceeds estimated spare time of 11330.000;
restart ...
23:41:24.513 XRUN callback (8).
23:41:29.614 XRUN callback (9).
delay of 69610.000 usecs exceeds estimated spare time of 11400.000;
restart ...
23:41:34.724 XRUN callback (10).
delay of 69546.000 usecs exceeds estimated spare time of 11390.000;
restart ...
23:41:37.612 Client deactivated.
23:41:37.650 JACK is stopping...
jack main caught signal 15
no message buffer overruns
23:41:37.736 JACK was stopped successfully.
Any suggestions welcome as usual.
Nigel.
8:34 p.m.
El Lunes, 1 de Octubre de 2007 23:45, Nigel Henry escribió:
| On Monday 01 October 2007 01:42, Marcos Guglielmetti wrote:
| > Hi, also you can add Musix GNU/Linux's repositories (debian/etch
| > compatible)
| >
| > # /etc/apt/sources.list Musix GNU+Linux
| > deb ftp://musix.ourproject.org/pub/musix/deb/ ./
| >
| > So you can install rt kernels on you Debian/ECTH, and upgrade Ardour to
| > 2.1, jackd to 0.103...
| >
| > regards
|
| Sorry for replying to my previous reply with everything now snipped.
|
| I've downloaded, and installed kernel 2.6.21rt4, 2.6.21.5rt18, and rtirq,
| but am still getting xruns when starting jackd in qjackctl. An xrun about
| every 3 secs, and that's with no music apps being used.
|
| Is there anything else I need to do to get zero xruns when starting jackd?
|
| Do I need to edit /etc/security/limits.conf for example, as I had to do
| for Fedora 7?
Yes: sure!
@audio - rtprio 99
@audio - nice -10
@audio - memlock 4000000
| As default this file has everything commented out in Etch,
Bad for jackd...
| but this file in Fedora 7 already had some lines for
| jack-audio-connection-kit set up as default, but only with a rtprio of 20.
| The updated pam that came down when installing the planetccrma low latency
| kernel, left a limits.conf.rpmnew with higher priorities. I added these to
| the existing limits.conf file, commenting out the defaults, and now when
| starting jack on Fedora 7, I have zero xruns.
Fine
| I still get the odd xrun when running a music app, but nothing when jack
| is started with no music apps being used. I've put a bit of jack's
| messages output below.
|
| 23:41:07.577 Audio connection change.
| 23:41:07.585 Audio connection graph change.
| delay of 26942.000 usecs exceeds estimated spare time of 11397.000;
| restart ...
| 23:41:09.026 XRUN callback (1).
| delay of 65588.000 usecs exceeds estimated spare time of 11397.000;
| restart ...
| delay of 12403.000 usecs exceeds estimated spare time of 11397.000;
| restart ...
| 23:41:09.632 XRUN callback (2 skipped).
| delay of 20107.000 usecs exceeds estimated spare time of 11349.000;
| restart ...
| **** alsa_pcm: xrun of at least 0.044 msecs
| 23:41:12.320 XRUN callback (4).
| 23:41:13.728 XRUN callback (1 skipped).
| delay of 70451.000 usecs exceeds estimated spare time of 11326.000;
| restart ...
| 23:41:14.276 XRUN callback (6).
| delay of 66210.000 usecs exceeds estimated spare time of 11417.000;
| restart ...
| 23:41:19.406 XRUN callback (7).
| delay of 66172.000 usecs exceeds estimated spare time of 11330.000;
| restart ...
| 23:41:24.513 XRUN callback (8).
| 23:41:29.614 XRUN callback (9).
| delay of 69610.000 usecs exceeds estimated spare time of 11400.000;
| restart ...
| 23:41:34.724 XRUN callback (10).
| delay of 69546.000 usecs exceeds estimated spare time of 11390.000;
| restart ...
| 23:41:37.612 Client deactivated.
| 23:41:37.650 JACK is stopping...
| jack main caught signal 15
| no message buffer overruns
| 23:41:37.736 JACK was stopped successfully.
|
| Any suggestions welcome as usual.
|
| Nigel.
--
`&'
# Marcos Guglielmetti, co-director de
# Musix GNU+Linux, 100% Software Libre para artistas
_#_ http://www.musix.org.ar
(#)
/ O \ + archivos: ftp://musix.ourproject.org/pub/musix
( === ) Ecología: http://autosus.wordpress.com
`---' Personal: http://marcospcmusica.wordpress.com
"Los hamsters no pueden volar"
http://es.wikiquote.org/wiki/Los_Simpson_pizarra
8:49 p.m.
On Monday 01 October 2007 19:30, Marcos Guglielmetti wrote:
El Lunes, 1 de Octubre de 2007 23:45, Nigel Henry
escribió:
| On Monday 01 October 2007 01:42, Marcos Guglielmetti wrote:
| > Hi, also you can add Musix GNU/Linux's repositories (debian/etch
| > compatible)
| >
| > # /etc/apt/sources.list Musix GNU+Linux
| > deb ftp://musix.ourproject.org/pub/musix/deb/ ./
| >
| > So you can install rt kernels on you Debian/ECTH, and upgrade Ardour
| > to 2.1, jackd to 0.103...
| >
| > regards
|
| Sorry for replying to my previous reply with everything now snipped.
|
| I've downloaded, and installed kernel 2.6.21rt4, 2.6.21.5rt18, and
| rtirq, but am still getting xruns when starting jackd in qjackctl. An
| xrun about every 3 secs, and that's with no music apps being used.
|
| Is there anything else I need to do to get zero xruns when starting
| jackd?
|
| Do I need to edit /etc/security/limits.conf for example, as I had to do
| for Fedora 7?
Yes: sure!
@audio - rtprio 99
@audio - nice -10
@audio - memlock 4000000
| As default this file has everything commented out in Etch,
Bad for jackd...
| but this file in Fedora 7 already had some lines for
| jack-audio-connection-kit set up as default, but only with a rtprio of
| 20. The updated pam that came down when installing the planetccrma low
| latency kernel, left a limits.conf.rpmnew with higher priorities. I
| added these to the existing limits.conf file, commenting out the
| defaults, and now when starting jack on Fedora 7, I have zero xruns.
Fine
| Nigel.
Thanks Marcos. I'll add those lines to limits.conf
btw: Do you have a GPG key for your repo? If so, where do I find it. I looked
on your main site, but couldn't find it.
Nigel.
3 Oct
3 Oct
10:19 a.m.
Montag, 1. Oktober 2007 Marcos Guglielmetti:
@audio - rtprio 99
@audio - nice -10
@audio - memlock 4000000
Marcos, looking at these numbers (and variations of these on various netpages)
I always wonder whether they are such a good idea: Wouldn't rtprio 99 allow
for banzai processes to almost lock down the machine? Wouldn't memlock
4000000 (4GB) be like begging for a swapfest on standard 1GB/2GB machines?
Isn't the whole point about limits.conf to effectively prevent processes from
sucking in all resources? So that when realtime processes go havoc you'll be
left with cycles and memory to survive the situation?
Wolfgang
11:05 a.m.
On Wednesday 03 October 2007, Wolfgang Woehl wrote:
Montag, 1. Oktober 2007 Marcos Guglielmetti:
Yes,
one always assumes with settings like this, that the programs which are run
are nicely behaved (e.g. jackd has a watchdog to kill its clients when they
run havok)..
But whether you give one process RT prio 1 or 99 doesn't matter. It can always
keep all SCHED_OTHER threads [the rest of your system, X, xterms, whatnot]
from running at all effectively freezing the box (though in reality this is
expected behaviout).
A typical method to counter this scenario would be to limit user processes to
prio 98 and have another watchdog process runnning at prio 99. That watchdog
would have another thread running at SCHED_OTHER and checks at regular
intervals whether this thread got to run at all. If not -> take action and
make e.g. all SCHED_FIFO threads in the system SCHED_OTHER so the user is
able to recover from the situation.. There are several watchdogs available
(including one from yours truly which needs an overhaul though)..
And yes, of course, you wouldn't want to give all system memory away to
mlocking. You need some reserve..
Nice -10 otoh is pretty uncritical i guess.
Regards,
FLo
--
Palimm Palimm!
http://tapas.affenbande.org
@audio - rtprio 99
@audio - nice -10
@audio - memlock 4000000
Marcos, looking at these numbers (and variations of these on various
netpages) I always wonder whether they are such a good idea: Wouldn't
rtprio 99 allow for banzai processes to almost lock down the machine?
Wouldn't memlock 4000000 (4GB) be like begging for a swapfest on standard
1GB/2GB machines? Isn't the whole point about limits.conf to effectively
prevent processes from sucking in all resources? So that when realtime
processes go havoc you'll be left with cycles and memory to survive the
situation?
4:03 p.m.
On Wednesday 03 October 2007 15:05, Florian Schmidt wrote:
On Wednesday 03 October 2007, Wolfgang Woehl wrote:
I started this thread, but at the moment I'm not having much success at
getting realtime to work on Debian Etch, and that's before I start on Lenny.
Realtime works fine on Fedora 7, using the realtime low latency kernel from
planetccrma, plus rtirq, and a pam update from planetccrma that gave me a
limits.conf.rpmnew file, as below.
# limit realtime and memory locking access to users in the group audio
# there is no way to say "allow locking all memory", 4G should be enough
#
#* - rtprio 0
#* - nice 0
#
#@audio - rtprio 99
#@audio - nice -10
#@audio - memlock 4000000
# or (default) allow everyone access
* - rtprio 99
* - nice -10
* - memlock 4000000
Editing the existing limits.conf, adding the above, and commenting out the
default entries for jack, works fine. When starting jackd in qjackctl, I'm
getting one xrun every 6m 25secs on average, and the largest xrun over the
time I tested was about 0.325 msecs. I tested over about 2 1/2 hours, and the
only other apps open on the desktop were Xawtv, and Gkrellm.
On Debian Etch, after adding Marcos's repo to /atc/apt.sources.list, I
installed the 2.6.21-rt4, and 2.5.21.5-rt18 kernel, along with rtirq version
20070101. I edited limits.conf, and added the part above that I received from
planetccrma. That didn't work, with xruns every 2-3secs. I commented out the
default uncommented lines, and uncommented the audio lines, which are at the
top of this post. Still I get xruns every 2-3 secs, and if I reboot and try a
non rt kernel, xruns every 2-3 secs again. It appears that there is still
something missing to get realtime working on Etch.
I may have to download Musix again, and see how realtime runs on it. I DL'd
before, but that was when there was a problem with it booting with some
hardware. As I'm on dialup, I'd put off DL'ing it again, since the booting
problem has been resolved.
Marcos. If your reading this. Could you provide the link to download Musix
again please.
Thanks for all the replies to this thread.
Nigel.
Montag, 1. Oktober 2007 Marcos Guglielmetti:
Yes,
one always assumes with settings like this, that the programs which are run
are nicely behaved (e.g. jackd has a watchdog to kill its clients when they
run havok)..
But whether you give one process RT prio 1 or 99 doesn't matter. It can
always keep all SCHED_OTHER threads [the rest of your system, X, xterms,
whatnot] from running at all effectively freezing the box (though in
reality this is expected behaviout).
A typical method to counter this scenario would be to limit user processes
to prio 98 and have another watchdog process runnning at prio 99. That
watchdog would have another thread running at SCHED_OTHER and checks at
regular intervals whether this thread got to run at all. If not -> take
action and make e.g. all SCHED_FIFO threads in the system SCHED_OTHER so
the user is able to recover from the situation.. There are several
watchdogs available (including one from yours truly which needs an overhaul
though)..
And yes, of course, you wouldn't want to give all system memory away to
mlocking. You need some reserve..
Nice -10 otoh is pretty uncritical i guess.
Regards,
FLo @audio - rtprio 99
@audio - nice -10
@audio - memlock 4000000
Marcos, looking at these numbers (and variations of these on various
netpages) I always wonder whether they are such a good idea: Wouldn't
rtprio 99 allow for banzai processes to almost lock down the machine?
Wouldn't memlock 4000000 (4GB) be like begging for a swapfest on standard
1GB/2GB machines? Isn't the whole point about limits.conf to effectively
prevent processes from sucking in all resources? So that when realtime
processes go havoc you'll be left with cycles and memory to survive the
situation? 
5:58 p.m.
May be you have some shared IRQ's? Just guessing...
I wonder what could be the problem here, since I'm using realtime on
Debian Etch with no xruns... and the card is an infamous intel-hda on an
nvidia ck804 motherboard.
I'm not really doing serious audio work (I'm not a musician) but worked
for a music school willing to change from Microsotf. They use Audigy
(and some usb m-audio) cards, and they look like being quite happy. They
used to be Windows-only people until June. Yes, they are using Etch now.
So I would say that Etch works fine with realtime.
We made a live-cd for that music school. We are not advertising nor
promoting it as a multimedia distro, it is simply what we made in order
to get a system installed and configured quickly, then the music school
came to us and we added the realtime stuff, etc. It worked for them
rigth after installing and setting qjackctl for their card (frames,
sample rate & period, no more). Anyway, you can download it as a Debian
Etch-based livecd, with some (quite few) packages added from testing,
musix, kiberpipa and debian-multimedia:
http://gisa-elkartea.org/gisalivecd-012.iso
kernel is 2.6.21.6-rt21, also available to download separatedly:
http://gisa-elkartea.org/linux-image-2.6.21.6-rt21-gisa-686_03_i386.deb
To install it, you should log in as root with password gisanagusia. On
root's desktop you will find icons for install instructions, gparted and
install script.
However, install instructions and script are spanish-only at this
moment, sorry. It asks for devices where /, swap, /home and /multimedia
partitions are (you can leave /home and /multimedia blank if not used),
username, user password (twice), root password (twice). grub
destination, and finally, it asks if /home and multimedia contents (if
any) should be preserved.
Hope this helps,
Roman
PS: no rtirq on this livecd, but a script /usr/sbin/rtprio_snd is
called at qjackctl's start. Still, rtirq is probably much better...
PS2: Many thanks to all the people that worked/wrote on/about linux
audio. They made it easy for us to go now to the music school and see so
many smiles. Thank you all very much.
Nigel Henry escribió:
On Wednesday 03 October 2007 15:05, Florian Schmidt
wrote:
On Wednesday 03 October 2007, Wolfgang Woehl
wrote:
I started this thread, but at the moment I'm not having much success at
getting realtime to work on Debian Etch, and that's before I start on Lenny.
Realtime works fine on Fedora 7, using the realtime low latency kernel from
planetccrma, plus rtirq, and a pam update from planetccrma that gave me a
limits.conf.rpmnew file, as below.
# limit realtime and memory locking access to users in the group audio
# there is no way to say "allow locking all memory", 4G should be enough
#
#* - rtprio 0
#* - nice 0
#
#@audio - rtprio 99
#@audio - nice -10
#@audio - memlock 4000000
# or (default) allow everyone access
* - rtprio 99
* - nice -10
* - memlock 4000000
Editing the existing limits.conf, adding the above, and commenting out the
default entries for jack, works fine. When starting jackd in qjackctl, I'm
getting one xrun every 6m 25secs on average, and the largest xrun over the
time I tested was about 0.325 msecs. I tested over about 2 1/2 hours, and the
only other apps open on the desktop were Xawtv, and Gkrellm.
On Debian Etch, after adding Marcos's repo to /atc/apt.sources.list, I
installed the 2.6.21-rt4, and 2.5.21.5-rt18 kernel, along with rtirq version
20070101. I edited limits.conf, and added the part above that I received from
planetccrma. That didn't work, with xruns every 2-3secs. I commented out the
default uncommented lines, and uncommented the audio lines, which are at the
top of this post. Still I get xruns every 2-3 secs, and if I reboot and try a
non rt kernel, xruns every 2-3 secs again. It appears that there is still
something missing to get realtime working on Etch.
I may have to download Musix again, and see how realtime runs on it. I DL'd
before, but that was when there was a problem with it booting with some
hardware. As I'm on dialup, I'd put off DL'ing it again, since the booting
problem has been resolved.
Marcos. If your reading this. Could you provide the link to download Musix
again please.
Thanks for all the replies to this thread.
Nigel.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
Montag, 1. Oktober 2007 Marcos Guglielmetti:
Yes,
one always assumes with settings like this, that the programs which are run
are nicely behaved (e.g. jackd has a watchdog to kill its clients when they
run havok)..
But whether you give one process RT prio 1 or 99 doesn't matter. It can
always keep all SCHED_OTHER threads [the rest of your system, X, xterms,
whatnot] from running at all effectively freezing the box (though in
reality this is expected behaviout).
A typical method to counter this scenario would be to limit user processes
to prio 98 and have another watchdog process runnning at prio 99. That
watchdog would have another thread running at SCHED_OTHER and checks at
regular intervals whether this thread got to run at all. If not -> take
action and make e.g. all SCHED_FIFO threads in the system SCHED_OTHER so
the user is able to recover from the situation.. There are several
watchdogs available (including one from yours truly which needs an overhaul
though)..
And yes, of course, you wouldn't want to give all system memory away to
mlocking. You need some reserve..
Nice -10 otoh is pretty uncritical i guess.
Regards,
FLo @audio - rtprio 99
@audio - nice -10
@audio - memlock 4000000
Marcos, looking at these numbers (and
variations of these on various
netpages) I always wonder whether they are such a good idea: Wouldn't
rtprio 99 allow for banzai processes to almost lock down the machine?
Wouldn't memlock 4000000 (4GB) be like begging for a swapfest on standard
1GB/2GB machines? Isn't the whole point about limits.conf to effectively
prevent processes from sucking in all resources? So that when realtime
processes go havoc you'll be left with cycles and memory to survive the
situation?
6:49 p.m.
On Wednesday 03 October 2007 21:57, Roman Muñoz wrote:
May be you have some shared IRQ's? Just
guessing...
Hi Roman. Thanks for your reply. Normally sound cards don't have any problems
sharing IRQ's, and as realtime is working with Fedora 7 on the same machine
as Etch with my audigy2 soundblaster card, I think that there is something
else going on here on Etch, that I havn't quite figured out.
I wonder what could be the problem here, since I'm using realtime on
Debian Etch with no xruns... and the card is an infamous intel-hda on an
nvidia ck804 motherboard.
The fact that you've got the intel-hda card to even work deserves 10 out of 10
full marks. I've seen so many problems with the infinite variations of it.
I'm not really doing serious audio work (I'm not a musician) but worked
for a music school willing to change from Microsotf. They use Audigy
(and some usb m-audio) cards, and they look like being quite happy. They
used to be Windows-only people until June. Yes, they are using Etch now.
So I would say that Etch works fine with realtime.
We made a live-cd for that music school. We are not advertising nor
promoting it as a multimedia distro, it is simply what we made in order
to get a system installed and configured quickly, then the music school
came to us and we added the realtime stuff, etc. It worked for them
rigth after installing and setting qjackctl for their card (frames,
sample rate & period, no more). Anyway, you can download it as a Debian
Etch-based livecd, with some (quite few) packages added from testing,
musix, kiberpipa and debian-multimedia:
http://gisa-elkartea.org/gisalivecd-012.iso
kernel is 2.6.21.6-rt21, also available to download separatedly:
http://gisa-elkartea.org/linux-image-2.6.21.6-rt21-gisa-686_03_i386.deb
I don't think the kernel version is the problem. There's some other problem,
but your kernel is later than Marcos's, so I'll install that as well. I'm on
dialup so downloading iso's takes some time, but I'll look at your distro.
I think first I'll download the latest version of Musix. This way I can see if
realtime is working ok on it, and may get some clues as to why realtime is
not working on Etch.
To install it, you should log in as root with password gisanagusia. On
root's desktop you will find icons for install instructions, gparted and
install script.
However, install instructions and script are spanish-only at this
moment, sorry. It asks for devices where /, swap, /home and /multimedia
partitions are (you can leave /home and /multimedia blank if not used),
username, user password (twice), root password (twice). grub
destination, and finally, it asks if /home and multimedia contents (if
any) should be preserved.
Hope this helps,
Roman
Many thanks for your reply.
Nigel.
PS: no rtirq on this livecd, but a script /usr/sbin/rtprio_snd is
called at qjackctl's start. Still, rtirq is probably much better...
PS2: Many thanks to all the people that worked/wrote on/about linux
audio. They made it easy for us to go now to the music school and see so
many smiles. Thank you all very much.
Nigel Henry escribió:
On Wednesday 03 October 2007 15:05, Florian
Schmidt wrote:
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user On Wednesday 03 October 2007, Wolfgang Woehl
wrote:
I started this thread, but at the moment I'm not having much success at
getting realtime to work on Debian Etch, and that's before I start on
Lenny.
Realtime works fine on Fedora 7, using the realtime low latency kernel
from planetccrma, plus rtirq, and a pam update from planetccrma that gave
me a limits.conf.rpmnew file, as below.
# limit realtime and memory locking access to users in the group audio
# there is no way to say "allow locking all memory", 4G should be enough
#
#* - rtprio 0
#* - nice 0
#
#@audio - rtprio 99
#@audio - nice -10
#@audio - memlock 4000000
# or (default) allow everyone access
* - rtprio 99
* - nice -10
* - memlock 4000000
Editing the existing limits.conf, adding the above, and commenting out
the default entries for jack, works fine. When starting jackd in
qjackctl, I'm getting one xrun every 6m 25secs on average, and the
largest xrun over the time I tested was about 0.325 msecs. I tested over
about 2 1/2 hours, and the only other apps open on the desktop were
Xawtv, and Gkrellm.
On Debian Etch, after adding Marcos's repo to /atc/apt.sources.list, I
installed the 2.6.21-rt4, and 2.5.21.5-rt18 kernel, along with rtirq
version 20070101. I edited limits.conf, and added the part above that I
received from planetccrma. That didn't work, with xruns every 2-3secs. I
commented out the default uncommented lines, and uncommented the audio
lines, which are at the top of this post. Still I get xruns every 2-3
secs, and if I reboot and try a non rt kernel, xruns every 2-3 secs
again. It appears that there is still something missing to get realtime
working on Etch.
I may have to download Musix again, and see how realtime runs on it. I
DL'd before, but that was when there was a problem with it booting with
some hardware. As I'm on dialup, I'd put off DL'ing it again, since the
booting problem has been resolved.
Marcos. If your reading this. Could you provide the link to download
Musix again please.
Thanks for all the replies to this thread.
Nigel.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user Montag, 1. Oktober 2007 Marcos Guglielmetti:
> @audio - rtprio 99
> @audio - nice -10
> @audio - memlock 4000000
Marcos, looking at these numbers (and variations of these on various
netpages) I always wonder whether they are such a good idea: Wouldn't
rtprio 99 allow for banzai processes to almost lock down the machine?
Wouldn't memlock 4000000 (4GB) be like begging for a swapfest on
standard 1GB/2GB machines? Isn't the whole point about limits.conf to
effectively prevent processes from sucking in all resources? So that
when realtime processes go havoc you'll be left with cycles and memory
to survive the situation?
Yes,
one always assumes with settings like this, that the programs which are
run are nicely behaved (e.g. jackd has a watchdog to kill its clients
when they run havok)..
But whether you give one process RT prio 1 or 99 doesn't matter. It can
always keep all SCHED_OTHER threads [the rest of your system, X, xterms,
whatnot] from running at all effectively freezing the box (though in
reality this is expected behaviout).
A typical method to counter this scenario would be to limit user
processes to prio 98 and have another watchdog process runnning at prio
99. That watchdog would have another thread running at SCHED_OTHER and
checks at regular intervals whether this thread got to run at all. If
not -> take action and make e.g. all SCHED_FIFO threads in the system
SCHED_OTHER so the user is able to recover from the situation.. There
are several watchdogs available (including one from yours truly which
needs an overhaul though)..
And yes, of course, you wouldn't want to give all system memory away to
mlocking. You need some reserve..
Nice -10 otoh is pretty uncritical i guess.
Regards,
FLo
6:51 p.m.
On Wednesday 03 October 2007, Nigel Henry wrote:
I started this thread, but at the moment I'm not
having much success at
getting realtime to work on Debian Etch, and that's before I start on
Lenny.
Please run this script and post its output into your reply mail:
http://tapas.affenbande.org/rt-setup-report.sh
Thanks,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
8:33 p.m.
On Wednesday 03 October 2007 22:51, Florian Schmidt wrote:
On Wednesday 03 October 2007, Nigel Henry wrote:
Output below:
djmons@debian:~$ cd Realtime-setup-script
djmons@debian:~/Realtime-setup-script$ ./rt-setup-report.sh
hostname:
debian
kernel release info:
Linux debian 2.6.21-rt4 #1 SMP PREEMPT Fri May 18 18:15:11 EEST 2007 i686
GNU/Linux
00:00.0 Host bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia] (rev 05)
Subsystem: VIA Technologies, Inc. VT8601 [Apollo ProMedia]
Flags: bus master, medium devsel, latency 0
Memory at e0000000 (32-bit, prefetchable) [size=64M]
Capabilities: <access denied>
00:01.0 PCI bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia AGP]
(prog-if 00 [Normal decode])
Flags: bus master, 66MHz, medium devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: e4000000-e6ffffff
Prefetchable memory behind bridge: 50000000-500fffff
Capabilities: <access denied>
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev
40)
Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
Flags: bus master, stepping, medium devsel, latency 0
Capabilities: <access denied>
00:07.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a
[Master SecP PriP])
Subsystem: VIA Technologies, Inc.
VT82C586/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE
Flags: bus master, medium devsel, latency 32
[virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1]
[virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 00000370 (type 3, non-prefetchable) [size=1]
I/O ports at c000 [size=16]
Capabilities: <access denied>
00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 1a) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
Flags: bus master, medium devsel, latency 32, IRQ 11
I/O ports at c400 [size=32]
Capabilities: <access denied>
00:07.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 1a) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
Flags: bus master, medium devsel, latency 32, IRQ 11
I/O ports at c800 [size=32]
Capabilities: <access denied>
00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
Subsystem: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
Flags: medium devsel, IRQ 11
Capabilities: <access denied>
00:09.0 Multimedia audio controller: Creative Labs SB Audigy (rev 04)
Subsystem: Creative Labs Unknown device 1002
Flags: bus master, medium devsel, latency 32, IRQ 10
I/O ports at d800 [size=64]
Capabilities: <access denied>
00:09.1 Input device controller: Creative Labs SB Audigy Game Port (rev 04)
Subsystem: Creative Labs Unknown device 0060
Flags: bus master, medium devsel, latency 32
I/O ports at dc00 [size=8]
Capabilities: <access denied>
00:09.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port (rev 04)
(prog-if 10 [OHCI])
Subsystem: Creative Labs SB Audigy FireWire Port
Flags: bus master, medium devsel, latency 32, IRQ 9
Memory at e7004000 (32-bit, non-prefetchable) [size=2K]
Memory at e7000000 (32-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture
(rev 11)
Subsystem: Hauppauge computer works Inc. WinTV Series
Flags: bus master, medium devsel, latency 32, IRQ 9
Memory at e7005000 (32-bit, prefetchable) [size=4K]
Capabilities: <access denied>
00:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev
11)
Subsystem: Hauppauge computer works Inc. WinTV Series
Flags: bus master, medium devsel, latency 32, IRQ 9
Memory at e7006000 (32-bit, prefetchable) [size=4K]
Capabilities: <access denied>
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139
Flags: bus master, medium devsel, latency 32, IRQ 11
I/O ports at e000 [size=256]
Memory at e7007000 (32-bit, non-prefetchable) [size=256]
Capabilities: <access denied>
01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 (rev 6a)
(prog-if 00 [VGA])
Subsystem: Trident Microsystems CyberBlade/i1
Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 10
Memory at e5800000 (32-bit, non-prefetchable) [size=8M]
Memory at e6000000 (32-bit, non-prefetchable) [size=128K]
Memory at e5000000 (32-bit, non-prefetchable) [size=8M]
[virtual] Expansion ROM at 50000000 [disabled] [size=64K]
Capabilities: <access denied>
CPU0
0: 738818 XT-PIC-XT timer
1: 134 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
6: 5 XT-PIC-XT floppy
7: 0 XT-PIC-XT parport0
8: 1 XT-PIC-XT rtc
9: 63521 XT-PIC-XT bttv0, ohci1394, Bt87x audio
10: 0 XT-PIC-XT EMU10K1
11: 4914 XT-PIC-XT uhci_hcd:usb1, uhci_hcd:usb2, eth0
12: 6258 XT-PIC-XT i8042
14: 23875 XT-PIC-XT ide0
15: 11047 XT-PIC-XT ide1
NMI: 0
LOC: 0
ERR: 0
MIS: 0
irq handler priorities:
4 root -51 0 0 0 0 S 0.0 0.0 0:00.00 softirq-high/0
5 root -51 0 0 0 0 S 0.0 0.0 0:00.03 softirq-timer/0
6 root -51 0 0 0 0 S 0.0 0.0 0:00.00 softirq-net-tx/
7 root -51 0 0 0 0 S 0.0 0.0 0:00.00 softirq-net-rx/
8 root -51 0 0 0 0 S 0.0 0.0 0:00.00 softirq-block/0
9 root -51 0 0 0 0 S 0.0 0.0 0:00.00 softirq-tasklet
10 root -51 0 0 0 0 S 0.0 0.0 0:00.03 softirq-sched/0
11 root -51 0 0 0 0 S 0.0 0.0 0:00.00 softirq-hrtimer
12 root -51 0 0 0 0 S 0.0 0.0 0:00.00 softirq-rcu/0
184 root -51 -5 0 0 0 S 0.0 0.0 0:00.00 IRQ-8
207 root -51 -5 0 0 0 S 0.0 0.0 1:23.59 IRQ-14
210 root -51 -5 0 0 0 S 0.0 0.0 0:00.34 IRQ-15
287 root -51 -5 0 0 0 S 0.0 0.0 0:00.16 IRQ-12
288 root -51 -5 0 0 0 S 0.0 0.0 0:00.00 IRQ-1
605 root -51 -5 0 0 0 S 0.0 0.0 0:00.27 IRQ-11
813 root -51 -5 0 0 0 S 0.0 0.0 0:01.17 IRQ-9
815 root -51 -5 0 0 0 S 0.0 0.0 0:00.00 IRQ-6
847 root -51 -5 0 0 0 S 0.0 0.0 0:00.00 IRQ-7
883 root -51 -5 0 0 0 S 0.0 0.0 0:00.00 IRQ-10
jackd priorities:
sound cards:
0 [Audigy2 ]: Audigy2 - Audigy 2 Platinum [SB0240P]
Audigy 2 Platinum [SB0240P] (rev.4, serial:0x10021102)
at 0xd800, irq 10
1 [Bt878 ]: Bt87x - Brooktree Bt878
Brooktree Bt878 at 0xe7006000, irq 9
2 [keyboard ]: USB-Audio - MK-225C USB MIDI keyboard
Evolution Electronics Ltd. MK-225C USB MIDI keyboard at
usb-0000:00:07.2-1, ful
sound devices:
2: : timer
3: [ 2- 0]: raw midi
4: [ 2] : control
5: [ 0- 0]: hardware dependent
6: [ 0- 1]: raw midi
7: [ 0- 0]: raw midi
8: [ 0- 4]: digital audio playback
9: [ 0- 4]: digital audio capture
10: [ 0- 3]: digital audio playback
11: [ 0- 2]: digital audio playback
12: [ 0- 2]: digital audio capture
13: [ 0- 1]: digital audio capture
14: [ 0- 0]: digital audio playback
15: [ 0- 0]: digital audio capture
16: [ 0] : control
17: [ 1- 1]: digital audio capture
18: [ 1- 0]: digital audio capture
19: [ 1] : control
20: : sequencer
21: [ 0- 2]: hardware dependent
22: [ 0- 2]: raw midi
23: [ 0- 3]: raw midi
djmons@debian:~/Realtime-setup-script$
Nigel.
I started this thread, but at the moment I'm
not having much success at
getting realtime to work on Debian Etch, and that's before I start on
Lenny.
Please run this script and post its output into your reply mail:
http://tapas.affenbande.org/rt-setup-report.sh
Thanks,
Flo
10:05 p.m.
On Thursday 04 October 2007, Nigel Henry wrote:
irq handler priorities:
4 root -51 0 0 0 0 S 0.0 0.0 0:00.00 softirq-high/0
5 root -51 0 0 0 0 S 0.0 0.0 0:00.03
softirq-timer/0 6 root -51 0 0 0 0 S 0.0 0.0 0:00.00
softirq-net-tx/ 7 root -51 0 0 0 0 S 0.0 0.0 0:00.00
softirq-net-rx/ 8 root -51 0 0 0 0 S 0.0 0.0 0:00.00
softirq-block/0 9 root -51 0 0 0 0 S 0.0 0.0 0:00.00
softirq-tasklet 10 root -51 0 0 0 0 S 0.0 0.0 0:00.03
softirq-sched/0 11 root -51 0 0 0 0 S 0.0 0.0 0:00.00
softirq-hrtimer 12 root -51 0 0 0 0 S 0.0 0.0 0:00.00
softirq-rcu/0 184 root -51 -5 0 0 0 S 0.0 0.0 0:00.00
IRQ-8 207 root -51 -5 0 0 0 S 0.0 0.0 1:23.59 IRQ-14 210
root -51 -5 0 0 0 S 0.0 0.0 0:00.34 IRQ-15 287 root
-51 -5 0 0 0 S 0.0 0.0 0:00.16 IRQ-12 288 root -51 -5
0 0 0 S 0.0 0.0 0:00.00 IRQ-1 605 root -51 -5 0 0
0 S 0.0 0.0 0:00.27 IRQ-11 813 root -51 -5 0 0 0 S 0.0
0.0 0:01.17 IRQ-9 815 root -51 -5 0 0 0 S 0.0 0.0
0:00.00 IRQ-6 847 root -51 -5 0 0 0 S 0.0 0.0 0:00.00
IRQ-7 883 root -51 -5 0 0 0 S 0.0 0.0 0:00.00 IRQ-10
Ok, you have not done any irq priority tuning.. Try setting the IRQ-10 process
[your emu10k1] to prio 90..
jackd priorities:
Please run jackd at a prio higher than 51 [for example 70].
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
4 Oct
4 Oct
12:39 p.m.
On Thursday 04 October 2007 02:05, Florian Schmidt wrote:
On Thursday 04 October 2007, Nigel Henry wrote:
I'm not sure what I'm doing here. I presume I need to use chrt to change the
priority, but am not sure of the correct syntax. The current pid for IRQ10 is
940.
Could you give me a line that will work for this pid, as the man page is
pretty hopeless with no examples, and about 3 hrs of googling turned up
virtually nothing.
Many thanks.
Nigel.
irq handler priorities:
4 root -51 0 0 0 0 S 0.0 0.0 0:00.00
softirq-high/0 5 root -51 0 0 0 0 S 0.0 0.0 0:00.03
softirq-timer/0 6 root -51 0 0 0 0 S 0.0 0.0 0:00.00
softirq-net-tx/ 7 root -51 0 0 0 0 S 0.0 0.0 0:00.00
softirq-net-rx/ 8 root -51 0 0 0 0 S 0.0 0.0 0:00.00
softirq-block/0 9 root -51 0 0 0 0 S 0.0 0.0 0:00.00
softirq-tasklet 10 root -51 0 0 0 0 S 0.0 0.0 0:00.03
softirq-sched/0 11 root -51 0 0 0 0 S 0.0 0.0 0:00.00
softirq-hrtimer 12 root -51 0 0 0 0 S 0.0 0.0 0:00.00
softirq-rcu/0 184 root -51 -5 0 0 0 S 0.0 0.0 0:00.00
IRQ-8 207 root -51 -5 0 0 0 S 0.0 0.0 1:23.59 IRQ-14
210 root -51 -5 0 0 0 S 0.0 0.0 0:00.34 IRQ-15 287
root -51 -5 0 0 0 S 0.0 0.0 0:00.16 IRQ-12 288 root
-51 -5 0 0 0 S 0.0 0.0 0:00.00 IRQ-1 605 root -51 -5
0 0 0 S 0.0 0.0 0:00.27 IRQ-11 813 root -51 -5 0 0
0 S 0.0 0.0 0:01.17 IRQ-9 815 root -51 -5 0 0 0 S 0.0
0.0 0:00.00 IRQ-6 847 root -51 -5 0 0 0 S 0.0 0.0
0:00.00 IRQ-7 883 root -51 -5 0 0 0 S 0.0 0.0 0:00.00
IRQ-10
Ok, you have not done any irq priority tuning.. Try setting the IRQ-10
process [your emu10k1] to prio 90.. Flo
1:07 p.m.
On Thursday 04 October 2007 16:39, Nigel Henry wrote:
On Thursday 04 October 2007 02:05, Florian Schmidt
wrote:
Bad to reply to my own post, but I've resolved the problem.
I think I must have done my head in with all that googling. Another look at
the man page for chrt, and the process was so simple.
One xrun after 6m 33secs of 0.253 msecs, which is what I'm getting on Fedora
7.
Will that change of priority I've made for the soundcard on the current pid,
hold after a reboot?
Nigel.
On Thursday 04 October 2007, Nigel Henry wrote:
I'm not sure what I'm doing here. I presume I need to use chrt to change
the priority, but am not sure of the correct syntax. The current pid for
IRQ10 is 940.
Could you give me a line that will work for this pid, as the man page is
pretty hopeless with no examples, and about 3 hrs of googling turned up
virtually nothing.
Many thanks.
Nigel.
> Flo irq handler priorities:
4 root -51 0 0 0 0 S 0.0 0.0 0:00.00
softirq-high/0 5 root -51 0 0 0 0 S 0.0 0.0 0:00.03
softirq-timer/0 6 root -51 0 0 0 0 S 0.0 0.0
0:00.00 softirq-net-tx/ 7 root -51 0 0 0 0 S 0.0 0.0
0:00.00 softirq-net-rx/ 8 root -51 0 0 0 0 S 0.0 0.0
0:00.00 softirq-block/0 9 root -51 0 0 0 0 S 0.0
0.0 0:00.00 softirq-tasklet 10 root -51 0 0 0 0 S
0.0 0.0 0:00.03 softirq-sched/0 11 root -51 0 0 0 0
S 0.0 0.0 0:00.00 softirq-hrtimer 12 root -51 0 0 0
0 S 0.0 0.0 0:00.00 softirq-rcu/0 184 root -51 -5 0 0
0 S 0.0 0.0 0:00.00 IRQ-8 207 root -51 -5 0 0 0 S
0.0 0.0 1:23.59 IRQ-14 210 root -51 -5 0 0 0 S 0.0
0.0 0:00.34 IRQ-15 287 root -51 -5 0 0 0 S 0.0 0.0
0:00.16 IRQ-12 288 root -51 -5 0 0 0 S 0.0 0.0 0:00.00 IRQ-1
605 root -51 -5 0 0 0 S 0.0 0.0 0:00.27 IRQ-11 813 root
-51 -5 0 0 0 S 0.0 0.0 0:01.17 IRQ-9 815 root -51 -5
0 0 0 S 0.0 0.0 0:00.00 IRQ-6 847 root -51 -5 0 0
0 S 0.0 0.0 0:00.00 IRQ-7 883 root -51 -5 0 0 0 S
0.0 0.0 0:00.00 IRQ-10
Ok, you have not done any irq priority tuning.. Try setting the IRQ-10
process [your emu10k1] to prio 90..
2:10 p.m.
On Thursday 04 October 2007, Nigel Henry wrote:
Bad to reply to my own post, but I've resolved the problem.
I never quite understood what was supposed to be bad about replying to one's
own post.. :)
Ok, you have not done any irq priority tuning.. Try
setting the IRQ-10
process [your emu10k1] to prio 90..
I'm not sure what I'm doing here. I presume I need to use chrt to change
the priority, but am not sure of the correct syntax. The current pid for
IRQ10 is 940.
Could you give me a line that will work for this pid, as the man page is
pretty hopeless with no examples, and about 3 hrs of googling turned up
virtually nothing.
Many thanks.
Nigel.
> Flo One xrun after 6m 33secs of 0.253 msecs, which is what
I'm getting on
Fedora 7.
With soundcard irq prio at 90 [not shared with any other device], Jack prio at
70 and all other irq prios at default 51?
Then it's either an application bug [are you running any applications]? Or a
bug in the emu10k1 driver. Or in jackd, though i suppose that's rather
unlikely..
Will that change of priority I've made for the soundcard on the current
pid, hold after a reboot?
Nope.. It will be started with the default prio again. Have a look at the
rtirq script or fiddle your own initscript. Most distros have some "local"
init script where you put that command..
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
2:42 p.m.
Hi Nigel,
see below
Florian Schmidt wrote:
On Thursday 04 October 2007, Nigel Henry wrote:
Bad to reply to my own post, but I've resolved the problem.
I never quite understood what was supposed to be bad about replying to one's
own post.. :)
Nigel,
This will tell you which IRQ your sound card is on:
cat /proc/interrupts | grep -i emu10k1
Then use this line to set the rtprio value (90 in this example) of that
IRQ (obviously, replace the xx with your actual IRQ value). Assuming
this IRQ is stable across reboots, put this line in /etc/rc.local on
Fedora systems. Been working well here for a long time.
chrt -f -p 90 `pidof "IRQ-xx"`
If some shell scripting guru wants to jump in, I'm sure there is a way
to connect these two lines so that the emu10k IRQ is found at boot time
(so this removes the requirement that your sound card always gets the
same IRQ).
HTH,
Rick
Ok, you have not done any irq priority tuning.. Try
setting the IRQ-10
process [your emu10k1] to prio 90..
I'm not sure what I'm doing here. I presume I need to use chrt to change
the priority, but am not sure of the correct syntax. The current pid for
IRQ10 is 940.
Could you give me a line that will work for this pid, as the man page is
pretty hopeless with no examples, and about 3 hrs of googling turned up
virtually nothing.
Many thanks.
Nigel.
>Flo
>
> One xrun after 6m 33secs of 0.253 msecs, which is
what I'm getting on
Fedora 7.
With soundcard irq prio at 90 [not shared with any other device], Jack prio at
70 and all other irq prios at default 51?
Then it's either an application bug [are you running any applications]? Or a
bug in the emu10k1 driver. Or in jackd, though i suppose that's rather
unlikely..
Will that change of priority I've made for the
soundcard on the current
pid, hold after a reboot?
Nope.. It will be started with the default prio again. Have a look at the
rtirq script or fiddle your own initscript. Most distros have some "local"
init script where you put that command..
Flo
4:01 p.m.
On Thursday 04 October 2007 18:41, Rick Wright wrote:
Hi Nigel,
see below
Florian Schmidt wrote:
Hey, that looks promising. All the more so, as it works for you. I'll try it
in rc.local on Etch. The IRQ of the soundcard is constant, so hopefully it'll
work ok.
On Thursday 04 October 2007, Nigel Henry wrote:
I never quite understood what was supposed to be bad about replying to
one's own post.. :)
Nigel,
This will tell you which IRQ your sound card is on:
cat /proc/interrupts | grep -i emu10k1
Then use this line to set the rtprio value (90 in this example) of that
IRQ (obviously, replace the xx with your actual IRQ value). Assuming
this IRQ is stable across reboots, put this line in /etc/rc.local on
Fedora systems. Been working well here for a long time.
chrt -f -p 90 `pidof "IRQ-xx"` >Ok,
you have not done any irq priority tuning.. Try setting the IRQ-10
>process [your emu10k1] to prio 90..
I'm not sure what I'm doing here. I presume I need to use chrt to change
the priority, but am not sure of the correct syntax. The current pid for
IRQ10 is 940.
Could you give me a line that will work for this pid, as the man page is
pretty hopeless with no examples, and about 3 hrs of googling turned up
virtually nothing.
Many thanks.
Nigel.
>Flo
Bad to reply to my own post, but I've resolved the problem. One xrun after 6m 33secs of 0.253 msecs, which is
what I'm getting on
Fedora 7.
With soundcard irq prio at 90 [not shared with any other device], Jack
prio at 70 and all other irq prios at default 51?
Then it's either an application bug [are you running any applications]? Or
a bug in the emu10k1 driver. Or in jackd, though i suppose that's rather
unlikely..
Will that change of priority I've made for the
soundcard on the current
pid, hold after a reboot?
Nope.. It will be started with the default prio again. Have a look at the
rtirq script or fiddle your own initscript. Most distros have some "local"
init script where you put that command..
Flo
If some shell scripting guru wants to jump in, I'm sure there is a way
to connect these two lines so that the emu10k IRQ is found at boot time
(so this removes the requirement that your sound card always gets the
same IRQ).
HTH,
Rick
Thanks for the bit of script.
Nigel.
5:29 p.m.
Hi Nigel,
Is rtirq working four you? If yes, I think that your soundcard IRQ
should be at prio 85 at startup... and it was not.
See this:
http://mggmail.blogspot.com/2007/07/re-rtirq-fixed.html
I downloaded it, untarred, as root copied rtirq.conf to
/etc/default/rtirq, then ./rtirq.sh and it worked
To get it working at startup you should copy rtirq.sh as
/etc/init.d/rtirq, then
update-rc.d rtirq start 99 2 3 4 5 . stop 01 0 1 6 .
BTW, It is the first time that i read this script. Could somebody
elaborate on rtc and snd services "non threaded" as shown in rtirq.conf?
It seems that it does not change RTC frequency as recommended on
Florian's site?
Best regards,
Roman
Nigel Henry escribió:
On Thursday 04 October 2007 18:41, Rick Wright wrote:
Hi Nigel,
see below
Florian Schmidt wrote:
Hey, that looks promising. All the more so, as it works for you. I'll try it
in rc.local on Etch. The IRQ of the soundcard is constant, so hopefully it'll
work ok.
On Thursday 04 October 2007, Nigel Henry wrote:
Nigel,
This will tell you which IRQ your sound card is on:
cat /proc/interrupts | grep -i emu10k1
Then use this line to set the rtprio value (90 in this example) of that
IRQ (obviously, replace the xx with your actual IRQ value). Assuming
this IRQ is stable across reboots, put this line in /etc/rc.local on
Fedora systems. Been working well here for a long time.
chrt -f -p 90 `pidof "IRQ-xx"` >> Ok, you have not done any irq priority
tuning.. Try setting the IRQ-10
>> process [your emu10k1] to prio 90..
> I'm not sure what I'm doing here. I presume I need to use chrt to change
> the priority, but am not sure of the correct syntax. The current pid for
> IRQ10 is 940.
>
> Could you give me a line that will work for this pid, as the man page is
> pretty hopeless with no examples, and about 3 hrs of googling turned up
> virtually nothing.
>
> Many thanks.
>
> Nigel.
>
>> Flo
Bad to reply to my own post, but I've resolved the problem.
I never quite
understood what was supposed to be bad about replying to
one's own post.. :)
One xrun after 6m 33secs of 0.253 msecs, which is
what I'm getting on
Fedora 7.
With soundcard irq prio at 90 [not shared with any other device], Jack
prio at 70 and all other irq prios at default 51?
Then it's either an application bug [are you running any applications]? Or
a bug in the emu10k1 driver. Or in jackd, though i suppose that's rather
unlikely..
Will that change of priority I've made for
the soundcard on the current
pid, hold after a reboot?
Nope.. It will be started with the default prio again.
Have a look at the
rtirq script or fiddle your own initscript. Most distros have some "local"
init script where you put that command..
Flo If some shell scripting guru wants to jump in,
I'm sure there is a way
to connect these two lines so that the emu10k IRQ is found at boot time
(so this removes the requirement that your sound card always gets the
same IRQ).
HTH,
Rick
Thanks for the bit of script.
Nigel.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
5 Oct
5 Oct
2:15 p.m.
On Thursday 04 October 2007 21:29, Roman Muñoz wrote:
Hi Nigel,
Is rtirq working four you? If yes, I think that your soundcard IRQ
should be at prio 85 at startup... and it was not.
See this:
http://mggmail.blogspot.com/2007/07/re-rtirq-fixed.html
Well I've got realtime working ok on Debian Etch, and Rick Wright's one liner
in rc.local is changing the prio to 90 for the soundcard on bootup. But,
rtirq is something different. The version installed is the same as on the
blog above (20070101), and the 2 files are installed, one
in /etc/init.d/rtirq, and the other in /etc/sysconfig/rtirq. I believe
the /etc/sysconfig directory was created when installing rtirq, as I don't
rmember it being there before. I say this because with Fedora the sysconfig
directory exists, and there is a bunch of files in it, and I remember looking
in Debian for this directory, and couldn't find it.
I also ran sysv-rc-conf as root on Etch. The rtirq entry is there, but
runlevels 2,3,4,and5 are unchecked, so something isn't quite right here. I
see also on the blog above that rtirq should be in /etc/default, but in the
case of Etch it isn't. As I say. Realtime on Etch is working ok, but I'll go
through the same procedure on Debian Lenny (testing), and try and fix the
rtirq problem without using Rick Wright's one liner, although it's much
appreciated, and works like clockwork.
I'll post back after I've played around with realtime on Lenny a bit.
Best regards,
Roman
Thanks for all the replies to this interesting subject.
Nigel.
6 Oct
6 Oct
1:34 a.m.
Nigel Henry escribió:
The version installed is the same as on the
blog above (20070101), and the 2 files are installed, one
in /etc/init.d/rtirq, and the other in /etc/sysconfig/rtirq. I believe
the /etc/sysconfig directory was created when installing rtirq, as I don't
rmember it being there before. I say this because with Fedora the sysconfig
directory exists, and there is a bunch of files in it, and I remember looking
in Debian for this directory, and couldn't find it.
Well that is probably the matter. I never cared about an /etc/sysconfig
directory on debian (I changed to Debian after trying to migrate from
Red Hat 6.2 to Red Hat 7). Now I am on a powerbook g3 system and
/etc/sysconfig does not exist. I would bet a lot of money that we will
not find it on a debian i386 system neither. I think it does not exist
on debian. Actually, I got a complain about /etc/default/rtirq being not
found the first time i tried to execute rtirq.sh linked from the blog
above...
I think that boot directories are the main difference between debian and
red-hat based systems. So if package you installed (did you installed a
package? just guessing again) is not placing anything on /etc/default,
it is not surprising that rtirq does not work for you on a debian system.
I also ran sysv-rc-conf as root on Etch. The rtirq
entry is there, but
runlevels 2,3,4,and5 are unchecked, so something isn't quite right here.
? I can't remember anything about sysv-rc-conf. On debian you need
update-rc.d to set bootscripts to be executed. On red hat-based systems
i think chkconfig (or so) takes care of this. If used as explained,
update-rc.d will create symbolic links to start rtirq (it may be
rtirq.sh) on runlevels 2-3-4-5 and to stop it on runlevels 0-1-6. You'll
find a directory /etc/rcX.d for each runlevel where a symbolic link
S99rtirq (or K01rtirq) will be pointing to /etc/init.d/rtirq.
/etc/init.d/rtirq must exist before creating symbolic links with update-rc.d
I
see also on the blog above that rtirq should be in /etc/default, but in the
case of Etch it isn't.
I think this is why rtirq is not working for you. It worked for me after
copying rtirq.conf file on /etc/default/rtirq, not in
/etc/sysconfig/rtirq. It seems that you somehow managed to get a red
hat/fedora package installed on a debian system? It could be wrong, even
if versions are the same... All I can say is that rtirq.sh from tarball
linked from musix blog complained about /etc/default/rtirq being not
found on my debian etch system... and that debian is not fedora. You'll
find no /etc/sysconfig directory on debian.
As I say. Realtime on Etch is working ok, but I'll
go
through the same procedure on Debian Lenny (testing), and try and fix the
rtirq problem without using Rick Wright's one liner, although it's much
appreciated, and works like clockwork.
I'll post back after I've played around with realtime on Lenny a bit.
So you are getting no more xruns now? That is the real point... After
reading it, I would say that rtirq is a much more polished script than
ours. However it does not look as setting the rtc irq frequency as
explained on Florian's website.
In short:
a) please download tarball linked from musix blog.
b) untar it.
c) mv rtirq.sh /etc/init.d/rtirq
d) mv rtirq.conf /etc/default/rtirq
e) update-rc.d rtirq start 99 2 3 4 5 . stop 0 1 6 .
f) it should work at startup on any debian distro
Best regards,
Roman
4:05 p.m.
Roman Muñoz wrote:
So you are getting no more xruns now? That is the real
point... After
reading it, I would say that rtirq is a much more polished script than
ours. However it does not look as setting the rtc irq frequency as
explained on Florian's website.
In short:
a) please download tarball linked from musix blog.
b) untar it.
c) mv rtirq.sh /etc/init.d/rtirq
d) mv rtirq.conf /etc/default/rtirq
e) update-rc.d rtirq start 99 2 3 4 5 . stop 0 1 6 .
f) it should work at startup on any debian distro
all of the above is probably correct, but there's one important thing
missing: as the configuration file is there located in
/etc/sdefault/rtirq instead of the original /etc/sysconfig/rtirq,
one has to edit the /etc/init.d/rtirq script and, somewhere near line
42, where it reads:
RTIRQ_CONFIG=/etc/sysconfig/rtirq
please change to
RTIRQ_CONFIG=/etc/default/rtirq
now it should work as advertised (not:)
ah, yet another thingie; it has been noted from some folks, specially
found dealing with ubuntu, that the very first line of the same script
should be tweaked, where it reads:
#!/bin/sh
should be
#!/bin/bash
finally, the rtirq script is just about tunning the irq threading
priorities as found on PREEMPT_RT patched karnels (aka Ingo Molnar's -rt
patchset). it does not have any regard to the rtc frequency setting (but
would be handy, nevertheless:)
moreover, rtirq has also some legacy support for PREEMPT_DESKTOP
configured kernels, where one has the option of having some of the irqs
non-threaded (thus RTIRQ_NON_THREADED configuration purpose), iirc. this
is not a option on PREEMPT_RT (aka full complete real-time)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
5:10 p.m.
Rui Nuno Capela escribió:
Roman Muñoz wrote:
Oops... I downloaded it again and found that you're of course right. Sorry.
So you are getting no more xruns now? That is the
real point... After
reading it, I would say that rtirq is a much more polished script than
ours. However it does not look as setting the rtc irq frequency as
explained on Florian's website.
In short:
a) please download tarball linked from musix blog.
b) untar it.
c) mv rtirq.sh /etc/init.d/rtirq
d) mv rtirq.conf /etc/default/rtirq
e) update-rc.d rtirq start 99 2 3 4 5 . stop 0 1 6 .
f) it should work at startup on any debian distro
all of the above is probably correct, but there's one important thing
missing: as the configuration file is there located in
/etc/sdefault/rtirq instead of the original /etc/sysconfig/rtirq,
one has to edit the /etc/init.d/rtirq script and, somewhere near line
42, where it reads:
RTIRQ_CONFIG=/etc/sysconfig/rtirq
please change to
RTIRQ_CONFIG=/etc/default/rtirq
now it should work as advertised (not:)
ah, yet another thingie; it has been noted from some
folks, specially
found dealing with ubuntu, that the very first line of the same script
should be tweaked, where it reads:
#!/bin/sh
should be
#!/bin/bash
No problem with /bin/sh here (debian etch)
finally, the rtirq script is just about tunning the
irq threading
priorities as found on PREEMPT_RT patched karnels (aka Ingo Molnar's -rt
patchset). it does not have any regard to the rtc frequency setting (but
would be handy, nevertheless:
moreover, rtirq has also some legacy support for PREEMPT_DESKTOP
configured kernels, where one has the option of having some of the irqs
non-threaded (thus RTIRQ_NON_THREADED configuration purpose), iirc. this
is not a option on PREEMPT_RT (aka full complete real-time)
OK, many thanks for this last point that I was not getting right.
Best regards,
Roman
7 Oct
7 Oct
12:23 p.m.
On Friday 05 October 2007 18:14, Nigel Henry wrote:
On Thursday 04 October 2007 21:29, Roman Muñoz wrote:
As promised, an update on realtime on Debian Lenny. That is after having
installed from the musix repo, kernel 2.6.21-rt4, and 2.6.21.5-rt18.
First I had to update util-linux from the unstable repo, as the version on
Lenny was the Etch one, and still thought that schedutils was available. The
Sid (unstable) version installed ok, and chrt is available now.
Then added the lines below to /etc/security/limits.conf.
@audio - rtprio 99
@audio - nice -10
@audio - memlock 4000000
Now the fun started with installing rtirq (the version from the musix repo).
It installed, but refused to start. I was confused, as both scripts, the one
in /etc/init.d, and /etc/sysconfig seemed to be the same, so I booted up
Fedora 7, and checked the 2 rtirq scripts there, and sure enough the one
in /etc/sysconfig was a very short one, compared to the start script
in /etc/init.d.
Downloaded the rtirq tarball from the blog that Roman posted.
http://www.rncbc.org/jack/rtirq-20070101.tar.gz
Unpacked it, deleted the duplicated startup script in Lenny's /etc/sysconfig,
pasted the correct config script in /etc/sysconfig, renaming it from
rtirq.conf to rtirq.
Rebooted, and ran /etc/init.d/rtirq status, and got the following output.
/etc/init.d/rtirq status
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
184 FF 90 - 130 0.0 S< IRQ-8 rtc
666 FF 85 - 125 0.0 S< IRQ-9 ohci1394, bttv0, Bt87x audio
1770 FF 84 - 124 0.1 S< IRQ-10 EMU10K1
631 FF 80 - 120 0.0 S< IRQ-11 uhci_hcd:usb1, uhci_hcd:usb2,
eth0
288 FF 75 - 115 0.0 S< IRQ-1 i8042
287 FF 74 - 114 0.0 S< IRQ-12 i8042
4 FF 50 - 90 0.0 S softirq-high/0
5 FF 50 - 90 0.0 S softirq-timer/0
6 FF 50 - 90 0.0 S softirq-net-tx/
7 FF 50 - 90 0.0 S softirq-net-rx/
8 FF 50 - 90 0.0 S softirq-block/0
9 FF 50 - 90 0.0 S softirq-tasklet
10 FF 50 - 90 0.0 S softirq-sched/0
11 FF 50 - 90 0.0 S softirq-hrtimer
12 FF 50 - 90 0.0 S softirq-rcu/0
207 FF 50 - 90 3.2 S< IRQ-14 ide0
210 FF 50 - 90 0.0 S< IRQ-15 ide1
785 FF 50 - 90 0.0 S< IRQ-6 floppy
1581 FF 50 - 90 0.0 S< IRQ-7 parport0
3078 FF 50 - 90 0.0 S< IRQ-3
Jackd has a prio of 70, and just with jackd started, only one xrun up to now
after 58mins of 0.118 msecs duration.
Job done. Realtime on Etch, and Lenny. The above makes it look dead easy, but
there was a lot of frustration along the way, and it took longer than it
appears.
Many thanks to all those who offered help on this list, and the debian-user
list.
One question regarding the rtirq status output above.
IRQ-9 has a slightly higher rtprio than that for the soundcard on IRQ-10.
ohci1394 is tied in with the firewire port on the audigy2 soundblaster, but I
can probably stop that being loaded, as I don't use firewire. bttv0 is the TV
card, and BT87x audio is for the audio capture part of the TVcard.
What would I need to do to swap these around, so that IRQ-9 has a prio of 84,
and IRQ-10, a prio of 85?
It's probably a bit of an academic question, as your unlikely to be doing
serious audio work while watching TV.
Nigel.
Hi Nigel,
Is rtirq working four you? If yes, I think that your soundcard IRQ
should be at prio 85 at startup... and it was not.
See this:
http://mggmail.blogspot.com/2007/07/re-rtirq-fixed.html
Well I've got realtime working ok on Debian Etch, and Rick Wright's one
liner in rc.local is changing the prio to 90 for the soundcard on bootup.
But, rtirq is something different. The version installed is the same as on
the blog above (20070101), and the 2 files are installed, one
in /etc/init.d/rtirq, and the other in /etc/sysconfig/rtirq. I believe
the /etc/sysconfig directory was created when installing rtirq, as I don't
rmember it being there before. I say this because with Fedora the sysconfig
directory exists, and there is a bunch of files in it, and I remember
looking in Debian for this directory, and couldn't find it.
I also ran sysv-rc-conf as root on Etch. The rtirq entry is there, but
runlevels 2,3,4,and5 are unchecked, so something isn't quite right here. I
see also on the blog above that rtirq should be in /etc/default, but in the
case of Etch it isn't. As I say. Realtime on Etch is working ok, but I'll
go through the same procedure on Debian Lenny (testing), and try and fix
the rtirq problem without using Rick Wright's one liner, although it's much
appreciated, and works like clockwork.
I'll post back after I've played around with realtime on Lenny a bit.
Best regards,
Roman
Thanks for all the replies to this interesting subject.
Nigel.
1:37 p.m.
Nigel Henry wrote:
On Friday 05 October 2007 18:14, Nigel Henry wrote:
you can switch pci slots around, that is between the tvcard and the
audigy2 on the mainboard
or
you can tweak the alsa modules loading order, like opted in
/etc/modprobe.conf (or the equivalent in your distro), giving an
explicit options ... index= line for each module, for example, i believe
these are the ones to write down:
options snd-bt87x index=0 # tvcard
options snd-emu10k1 index=1 # audigy
or
you can hack the rtirq script for doing priorities in reverse order:
edit /etc/init.d/rtirq near line 211, where it reads
IRQS=`grep irq /proc/asound/cards | tac | sed 's/.* irq \(.*\)/\1/'`
change that line to:
IRQS=`grep irq /proc/asound/cards | sed 's/.* irq \(.*\)/\1/'`
however I recommend doing it the second way, that is making it all
deterministic and independent from the booting order resolution, which
might change when you less expect with the weather ;)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On Thursday 04 October 2007 21:29, Roman Muñoz
wrote:
As promised, an update on realtime on Debian Lenny. That is after having
installed from the musix repo, kernel 2.6.21-rt4, and 2.6.21.5-rt18.
First I had to update util-linux from the unstable repo, as the version on
Lenny was the Etch one, and still thought that schedutils was available. The
Sid (unstable) version installed ok, and chrt is available now.
Then added the lines below to /etc/security/limits.conf.
@audio - rtprio 99
@audio - nice -10
@audio - memlock 4000000
Now the fun started with installing rtirq (the version from the musix repo).
It installed, but refused to start. I was confused, as both scripts, the one
in /etc/init.d, and /etc/sysconfig seemed to be the same, so I booted up
Fedora 7, and checked the 2 rtirq scripts there, and sure enough the one
in /etc/sysconfig was a very short one, compared to the start script
in /etc/init.d.
Downloaded the rtirq tarball from the blog that Roman posted.
http://www.rncbc.org/jack/rtirq-20070101.tar.gz
Unpacked it, deleted the duplicated startup script in Lenny's /etc/sysconfig,
pasted the correct config script in /etc/sysconfig, renaming it from
rtirq.conf to rtirq.
Rebooted, and ran /etc/init.d/rtirq status, and got the following output.
/etc/init.d/rtirq status
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
184 FF 90 - 130 0.0 S< IRQ-8 rtc
666 FF 85 - 125 0.0 S< IRQ-9 ohci1394, bttv0, Bt87x audio
1770 FF 84 - 124 0.1 S< IRQ-10 EMU10K1
631 FF 80 - 120 0.0 S< IRQ-11 uhci_hcd:usb1, uhci_hcd:usb2,
eth0
288 FF 75 - 115 0.0 S< IRQ-1 i8042
287 FF 74 - 114 0.0 S< IRQ-12 i8042
4 FF 50 - 90 0.0 S softirq-high/0
5 FF 50 - 90 0.0 S softirq-timer/0
6 FF 50 - 90 0.0 S softirq-net-tx/
7 FF 50 - 90 0.0 S softirq-net-rx/
8 FF 50 - 90 0.0 S softirq-block/0
9 FF 50 - 90 0.0 S softirq-tasklet
10 FF 50 - 90 0.0 S softirq-sched/0
11 FF 50 - 90 0.0 S softirq-hrtimer
12 FF 50 - 90 0.0 S softirq-rcu/0
207 FF 50 - 90 3.2 S< IRQ-14 ide0
210 FF 50 - 90 0.0 S< IRQ-15 ide1
785 FF 50 - 90 0.0 S< IRQ-6 floppy
1581 FF 50 - 90 0.0 S< IRQ-7 parport0
3078 FF 50 - 90 0.0 S< IRQ-3
Jackd has a prio of 70, and just with jackd started, only one xrun up to now
after 58mins of 0.118 msecs duration.
Job done. Realtime on Etch, and Lenny. The above makes it look dead easy, but
there was a lot of frustration along the way, and it took longer than it
appears.
Many thanks to all those who offered help on this list, and the debian-user
list.
One question regarding the rtirq status output above.
IRQ-9 has a slightly higher rtprio than that for the soundcard on IRQ-10.
ohci1394 is tied in with the firewire port on the audigy2 soundblaster, but I
can probably stop that being loaded, as I don't use firewire. bttv0 is the TV
card, and BT87x audio is for the audio capture part of the TVcard.
What would I need to do to swap these around, so that IRQ-9 has a prio of 84,
and IRQ-10, a prio of 85?
It's probably a bit of an academic question, as your unlikely to be doing
serious audio work while watching TV.
Hi Nigel,
Is rtirq working four you? If yes, I think that your soundcard IRQ
should be at prio 85 at startup... and it was not.
See this:
http://mggmail.blogspot.com/2007/07/re-rtirq-fixed.html
Well I've got realtime
working ok on Debian Etch, and Rick Wright's one
liner in rc.local is changing the prio to 90 for the soundcard on bootup.
But, rtirq is something different. The version installed is the same as on
the blog above (20070101), and the 2 files are installed, one
in /etc/init.d/rtirq, and the other in /etc/sysconfig/rtirq. I believe
the /etc/sysconfig directory was created when installing rtirq, as I don't
rmember it being there before. I say this because with Fedora the sysconfig
directory exists, and there is a bunch of files in it, and I remember
looking in Debian for this directory, and couldn't find it.
I also ran sysv-rc-conf as root on Etch. The rtirq entry is there, but
runlevels 2,3,4,and5 are unchecked, so something isn't quite right here. I
see also on the blog above that rtirq should be in /etc/default, but in the
case of Etch it isn't. As I say. Realtime on Etch is working ok, but I'll
go through the same procedure on Debian Lenny (testing), and try and fix
the rtirq problem without using Rick Wright's one liner, although it's much
appreciated, and works like clockwork.
I'll post back after I've played around with realtime on Lenny a bit.
Best regards,
Roman
Thanks for all the replies to this interesting subject.
Nigel.
3:12 p.m.
On Sunday 07 October 2007 17:37, Rui Nuno Capela wrote:
Nigel Henry wrote:
Unfortunately that option is a no go, as I've got about 14 distros that run on
this machine, and don't want to mess with the placement of the cards, just in
case.
On Friday 05 October 2007 18:14, Nigel Henry
wrote:
you can switch pci slots around, that is between the tvcard and the
audigy2 on the mainboard On Thursday 04 October 2007 21:29, Roman Muñoz
wrote:
As promised, an update on realtime on Debian Lenny. That is after having
installed from the musix repo, kernel 2.6.21-rt4, and 2.6.21.5-rt18.
First I had to update util-linux from the unstable repo, as the version
on Lenny was the Etch one, and still thought that schedutils was
available. The Sid (unstable) version installed ok, and chrt is available
now.
Then added the lines below to /etc/security/limits.conf.
@audio - rtprio 99
@audio - nice -10
@audio - memlock 4000000
Now the fun started with installing rtirq (the version from the musix
repo). It installed, but refused to start. I was confused, as both
scripts, the one in /etc/init.d, and /etc/sysconfig seemed to be the
same, so I booted up Fedora 7, and checked the 2 rtirq scripts there, and
sure enough the one in /etc/sysconfig was a very short one, compared to
the start script in /etc/init.d.
Downloaded the rtirq tarball from the blog that Roman posted.
http://www.rncbc.org/jack/rtirq-20070101.tar.gz
Unpacked it, deleted the duplicated startup script in Lenny's
/etc/sysconfig, pasted the correct config script in /etc/sysconfig,
renaming it from rtirq.conf to rtirq.
Rebooted, and ran /etc/init.d/rtirq status, and got the following output.
/etc/init.d/rtirq status
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
184 FF 90 - 130 0.0 S< IRQ-8 rtc
666 FF 85 - 125 0.0 S< IRQ-9 ohci1394, bttv0, Bt87x
audio 1770 FF 84 - 124 0.1 S< IRQ-10 EMU10K1
631 FF 80 - 120 0.0 S< IRQ-11 uhci_hcd:usb1,
uhci_hcd:usb2, eth0
288 FF 75 - 115 0.0 S< IRQ-1 i8042
287 FF 74 - 114 0.0 S< IRQ-12 i8042
4 FF 50 - 90 0.0 S softirq-high/0
5 FF 50 - 90 0.0 S softirq-timer/0
6 FF 50 - 90 0.0 S softirq-net-tx/
7 FF 50 - 90 0.0 S softirq-net-rx/
8 FF 50 - 90 0.0 S softirq-block/0
9 FF 50 - 90 0.0 S softirq-tasklet
10 FF 50 - 90 0.0 S softirq-sched/0
11 FF 50 - 90 0.0 S softirq-hrtimer
12 FF 50 - 90 0.0 S softirq-rcu/0
207 FF 50 - 90 3.2 S< IRQ-14 ide0
210 FF 50 - 90 0.0 S< IRQ-15 ide1
785 FF 50 - 90 0.0 S< IRQ-6 floppy
1581 FF 50 - 90 0.0 S< IRQ-7 parport0
3078 FF 50 - 90 0.0 S< IRQ-3
Jackd has a prio of 70, and just with jackd started, only one xrun up to
now after 58mins of 0.118 msecs duration.
Job done. Realtime on Etch, and Lenny. The above makes it look dead easy,
but there was a lot of frustration along the way, and it took longer than
it appears.
Many thanks to all those who offered help on this list, and the
debian-user list.
One question regarding the rtirq status output above.
IRQ-9 has a slightly higher rtprio than that for the soundcard on IRQ-10.
ohci1394 is tied in with the firewire port on the audigy2 soundblaster,
but I can probably stop that being loaded, as I don't use firewire. bttv0
is the TV card, and BT87x audio is for the audio capture part of the
TVcard.
What would I need to do to swap these around, so that IRQ-9 has a prio of
84, and IRQ-10, a prio of 85?
It's probably a bit of an academic question, as your unlikely to be doing
serious audio work while watching TV. Hi Nigel,
Is rtirq working four you? If yes, I think that your soundcard IRQ
should be at prio 85 at startup... and it was not.
See this:
http://mggmail.blogspot.com/2007/07/re-rtirq-fixed.html
Well I've got realtime working ok on Debian Etch, and Rick Wright's one
liner in rc.local is changing the prio to 90 for the soundcard on
bootup. But, rtirq is something different. The version installed is the
same as on the blog above (20070101), and the 2 files are installed, one
in /etc/init.d/rtirq, and the other in /etc/sysconfig/rtirq. I believe
the /etc/sysconfig directory was created when installing rtirq, as I
don't rmember it being there before. I say this because with Fedora the
sysconfig directory exists, and there is a bunch of files in it, and I
remember looking in Debian for this directory, and couldn't find it.
I also ran sysv-rc-conf as root on Etch. The rtirq entry is there, but
runlevels 2,3,4,and5 are unchecked, so something isn't quite right here.
I see also on the blog above that rtirq should be in /etc/default, but
in the case of Etch it isn't. As I say. Realtime on Etch is working ok,
but I'll go through the same procedure on Debian Lenny (testing), and
try and fix the rtirq problem without using Rick Wright's one liner,
although it's much appreciated, and works like clockwork.
I'll post back after I've played around with realtime on Lenny a bit.
Best regards,
Roman
Thanks for all the replies to this interesting subject.
Nigel.
or
you can tweak the alsa modules loading order, like opted in
/etc/modprobe.conf (or the equivalent in your distro), giving an
explicit options ... index= line for each module, for example, i believe
these are the ones to write down:
options snd-bt87x index=0 # tvcard
options snd-emu10k1 index=1 # audigy
That's not ideal either, as it's better for me that snd-emu10k1 is indexed as
0. snd-bt87x is already notorious for grabbing card0, along with some other
uncooperative drivers, and as I don't need audio capture from the TV card, I
could send it to /bin/true, along with ohci1394, as.
install snd-bt87x /bin/true
install ohci1394 /bin/true
That still leaves bttv0 though, and as it is using /dev/video0, I cannot set
an indexing option for it.
or
you can hack the rtirq script for doing priorities in reverse order:
edit /etc/init.d/rtirq near line 211, where it reads
IRQS=`grep irq /proc/asound/cards | tac | sed 's/.* irq \(.*\)/\1/'`
change that line to:
IRQS=`grep irq /proc/asound/cards | sed 's/.* irq \(.*\)/\1/'`
however I recommend doing it the second way, that is making it all
deterministic and independent from the booting order resolution, which
might change when you less expect with the weather ;)
As I've had so many problems getting realtime setup, I think I'll go for the
rtirq script hack, and will probably learn a bit more on how the script
works.
cheers
btw: Running /etc/rc.d/init.d/rtirq status on Fedora 7 shows IRQ-10 sharing
the stuff from IRQ-9 above, with emu10k1, and I'm getting xruns about every
6m 25secs with jackd started.
/etc/rc.d/init.d/rtirq status
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
890 FF 80 - 120 0.0 S< IRQ-8 rtc0
920 FF 75 - 115 0.1 S< IRQ-10 ohci1394, bttv0, Bt87x audio,
EMU10K1
60 FF 70 - 110 0.0 S< IRQ-11 acpi, uhci_hcd:usb1,
uhci_hcd:usb2, eth0
285 FF 65 - 105 0.0 S< IRQ-1 i8042
284 FF 64 - 104 0.0 S< IRQ-12 i8042
5 FF 50 - 90 0.0 S< softirq-high/0
6 FF 50 - 90 0.3 S< softirq-timer/0
7 FF 50 - 90 0.0 S< softirq-net-tx/
8 FF 50 - 90 0.0 S< softirq-net-rx/
9 FF 50 - 90 0.0 S< softirq-block/0
10 FF 50 - 90 0.0 S< softirq-tasklet
11 FF 50 - 90 0.0 S< softirq-sched/0
12 FF 50 - 90 0.0 S< softirq-hrtimer
13 FF 50 - 90 0.0 S< softirq-rcu/0
324 FF 50 - 90 0.0 S< IRQ-14 libata
325 FF 50 - 90 0.0 S< IRQ-15 libata
674 FF 50 - 90 0.0 S< IRQ-6 floppy
895 FF 50 - 90 0.0 S< IRQ-7 parport0
The TV card using bttv has been very hit and miss on which IRQ is used. On
some distros it is IRQ-10, on others IRQ-9. A bit confusing, but once set up
it appears to use the same IRQ everytime on the different distros.
Thanks for your reply Rui.
Nigel.
8 Oct
8 Oct
5:13 a.m.
if it were me, and the only problem left is one irq priority setting, i
would add a chrt line in the startup options manually (after rtirq). that
way you aren't messing with anything else.
porl
On 08/10/2007, Nigel Henry <cave.dnb(a)tiscali.fr> wrote:
On Sunday 07 October 2007 17:37, Rui Nuno Capela wrote:
Unfortunately that option is a no go, as I've got about 14 distros that
run on
this machine, and don't want to mess with the placement of the cards, just
in
case.
Nigel Henry wrote:
> On Friday 05 October 2007 18:14, Nigel Henry wrote:
>> On Thursday 04 October 2007 21:29, Roman Muñoz wrote:
>>> Hi Nigel,
>>>
>>> Is rtirq working four you? If yes, I think that your soundcard IRQ
>>> should be at prio 85 at startup... and it was not.
>>>
>>> See this:
>>> http://mggmail.blogspot.com/2007/07/re-rtirq-fixed.html
>>
>> Well I've got realtime working ok on Debian Etch, and Rick Wright's
one
>> liner in rc.local is changing the prio
to 90 for the soundcard on
>> bootup. But, rtirq is something different. The version installed is
the
>> same as on the blog above (20070101),
and the 2 files are installed,
one
>> in /etc/init.d/rtirq, and the other in
/etc/sysconfig/rtirq. I
believe
>> the /etc/sysconfig directory was created
when installing rtirq, as I
>> don't rmember it being there before. I say this because with Fedora
the
>> sysconfig directory exists, and there is
a bunch of files in it, and
I
>> remember looking in Debian for this
directory, and couldn't find it.
>>
>> I also ran sysv-rc-conf as root on Etch. The rtirq entry is there,
but
>> runlevels 2,3,4,and5 are unchecked, so
something isn't quite right
here.
>> I see also on the blog above that rtirq
should be in /etc/default,
but
>> in the case of Etch it isn't. As I
say. Realtime on Etch is working
ok,
>> but I'll go through the same
procedure on Debian Lenny (testing), and
>> try and fix the rtirq problem without using Rick Wright's one liner,
>> although it's much appreciated, and works like clockwork.
>>
>> I'll post back after I've played around with realtime on Lenny a bit.
>>
>>> Best regards,
>>> Roman
>>
>> Thanks for all the replies to this interesting subject.
>>
>> Nigel.
>
> As promised, an update on realtime on Debian Lenny. That is after
having
> installed from the musix repo, kernel
2.6.21-rt4, and 2.6.21.5-rt18.
>
> First I had to update util-linux from the unstable repo, as the
version
> on Lenny was the Etch one, and still thought
that schedutils was
> available. The Sid (unstable) version installed ok, and chrt is
available
> now.
>
> Then added the lines below to /etc/security/limits.conf.
> @audio - rtprio 99
> @audio - nice -10
> @audio - memlock 4000000
>
> Now the fun started with installing rtirq (the version from the musix
> repo). It installed, but refused to start. I was confused, as both
> scripts, the one in /etc/init.d, and /etc/sysconfig seemed to be the
> same, so I booted up Fedora 7, and checked the 2 rtirq scripts there,
and
> sure enough the one in /etc/sysconfig was a
very short one, compared
to
> the start script in /etc/init.d.
>
> Downloaded the rtirq tarball from the blog that Roman posted.
> http://www.rncbc.org/jack/rtirq-20070101.tar.gz
>
> Unpacked it, deleted the duplicated startup script in Lenny's
> /etc/sysconfig, pasted the correct config script in /etc/sysconfig,
> renaming it from rtirq.conf to rtirq.
>
> Rebooted, and ran /etc/init.d/rtirq status, and got the following
output.
>
> /etc/init.d/rtirq status
>
> PID CLS RTPRIO NI PRI %CPU STAT COMMAND
> 184 FF 90 - 130 0.0 S< IRQ-8 rtc
> 666 FF 85 - 125 0.0 S< IRQ-9 ohci1394, bttv0, Bt87x
> audio 1770 FF 84 - 124 0.1 S< IRQ-10 EMU10K1
> 631 FF 80 - 120 0.0 S< IRQ-11 uhci_hcd:usb1,
> uhci_hcd:usb2, eth0
> 288 FF 75 - 115 0.0 S< IRQ-1 i8042
> 287 FF 74 - 114 0.0 S< IRQ-12 i8042
> 4 FF 50 - 90 0.0 S softirq-high/0
> 5 FF 50 - 90 0.0 S softirq-timer/0
> 6 FF 50 - 90 0.0 S softirq-net-tx/
> 7 FF 50 - 90 0.0 S softirq-net-rx/
> 8 FF 50 - 90 0.0 S softirq-block/0
> 9 FF 50 - 90 0.0 S softirq-tasklet
> 10 FF 50 - 90 0.0 S softirq-sched/0
> 11 FF 50 - 90 0.0 S softirq-hrtimer
> 12 FF 50 - 90 0.0 S softirq-rcu/0
> 207 FF 50 - 90 3.2 S< IRQ-14 ide0
> 210 FF 50 - 90 0.0 S< IRQ-15 ide1
> 785 FF 50 - 90 0.0 S< IRQ-6 floppy
> 1581 FF 50 - 90 0.0 S< IRQ-7 parport0
> 3078 FF 50 - 90 0.0 S< IRQ-3
>
> Jackd has a prio of 70, and just with jackd started, only one xrun up
to
> now after 58mins of 0.118 msecs duration.
>
> Job done. Realtime on Etch, and Lenny. The above makes it look dead
easy,
> but there was a lot of frustration along the
way, and it took longer
than
> it appears.
>
> Many thanks to all those who offered help on this list, and the
> debian-user list.
>
> One question regarding the rtirq status output above.
>
> IRQ-9 has a slightly higher rtprio than that for the soundcard on
IRQ-10.
> ohci1394 is tied in with the firewire port
on the audigy2
soundblaster,
> but I can probably stop that being loaded,
as I don't use firewire.
bttv0
> is the TV card, and BT87x audio is for the
audio capture part of the
> TVcard.
>
> What would I need to do to swap these around, so that IRQ-9 has a prio
of
> 84, and IRQ-10, a prio of 85?
>
> It's probably a bit of an academic question, as your unlikely to be
doing
serious
audio work while watching TV.
you can switch pci slots around, that is between the tvcard and the
audigy2 on the mainboard
or
you can tweak the alsa modules loading order, like opted in
/etc/modprobe.conf (or the equivalent in your distro), giving an
explicit options ... index= line for each module, for example, i believe
these are the ones to write down:
options snd-bt87x index=0 # tvcard
options snd-emu10k1 index=1 # audigy
That's not ideal either, as it's better for me that snd-emu10k1 is indexed
as
0. snd-bt87x is already notorious for grabbing card0, along with some
other
uncooperative drivers, and as I don't need audio capture from the TV card,
I
could send it to /bin/true, along with ohci1394, as.
install snd-bt87x /bin/true
install ohci1394 /bin/true
That still leaves bttv0 though, and as it is using /dev/video0, I cannot
set
an indexing option for it.
or
you can hack the rtirq script for doing priorities in reverse order:
edit /etc/init.d/rtirq near line 211, where it reads
IRQS=`grep irq /proc/asound/cards | tac | sed 's/.* irq \(.*\)/\1/'`
change that line to:
IRQS=`grep irq /proc/asound/cards | sed 's/.* irq \(.*\)/\1/'`
however I recommend doing it the second way, that is making it all
deterministic and independent from the booting order resolution, which
might change when you less expect with the weather ;)
As I've had so many problems getting realtime setup, I think I'll go for
the
rtirq script hack, and will probably learn a bit more on how the script
works.
cheers
btw: Running /etc/rc.d/init.d/rtirq status on Fedora 7 shows IRQ-10
sharing
the stuff from IRQ-9 above, with emu10k1, and I'm getting xruns about
every
6m 25secs with jackd started.
/etc/rc.d/init.d/rtirq status
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
890 FF 80 - 120 0.0 S< IRQ-8 rtc0
920 FF 75 - 115 0.1 S< IRQ-10 ohci1394, bttv0, Bt87x
audio,
EMU10K1
60 FF 70 - 110 0.0 S< IRQ-11 acpi, uhci_hcd:usb1,
uhci_hcd:usb2, eth0
285 FF 65 - 105 0.0 S< IRQ-1 i8042
284 FF 64 - 104 0.0 S< IRQ-12 i8042
5 FF 50 - 90 0.0 S< softirq-high/0
6 FF 50 - 90 0.3 S< softirq-timer/0
7 FF 50 - 90 0.0 S< softirq-net-tx/
8 FF 50 - 90 0.0 S< softirq-net-rx/
9 FF 50 - 90 0.0 S< softirq-block/0
10 FF 50 - 90 0.0 S< softirq-tasklet
11 FF 50 - 90 0.0 S< softirq-sched/0
12 FF 50 - 90 0.0 S< softirq-hrtimer
13 FF 50 - 90 0.0 S< softirq-rcu/0
324 FF 50 - 90 0.0 S< IRQ-14 libata
325 FF 50 - 90 0.0 S< IRQ-15 libata
674 FF 50 - 90 0.0 S< IRQ-6 floppy
895 FF 50 - 90 0.0 S< IRQ-7 parport0
The TV card using bttv has been very hit and miss on which IRQ is used. On
some distros it is IRQ-10, on others IRQ-9. A bit confusing, but once set
up
it appears to use the same IRQ everytime on the different distros.
Thanks for your reply Rui.
Nigel.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
1:40 p.m.
On Monday 08 October 2007 09:13, porl sheean wrote:
if it were me, and the only problem left is one irq
priority setting, i
would add a chrt line in the startup options manually (after rtirq). that
way you aren't messing with anything else.
porl
Yes. That might be the easiest thing to do. I'll leave it as is at the moment,
but if I see any problems, I'll use Rick Wrights one liner in rc.local.
chrt -p -f 86 `pidof "IRQ-10"`
Thanks.
Nigel.
3:04 p.m.
Nigel Henry wrote:
On Monday 08 October 2007 09:13, porl sheean wrote:
Nigel,
I appreciate the recognition for pointing you at this one line bit of RT
magic. However, this little gem was not my cleverness, but rather
something contributed by one of the other LAU members ~2 years back (the
proof is surely in the archives). The real credit goes to this
community for the vast collection of knowledge, experience, and
willingness to help!
Anyhow, I'm glad it's working for you and I agree with Porl's idea that
you simply use it to patch up any remaining issues after rtirq does it's
configuring.
Good luck,
Rick
if it were me, and the only problem left is one
irq priority setting, i
would add a chrt line in the startup options manually (after rtirq). that
way you aren't messing with anything else.
porl
Yes. That might be the easiest thing to do. I'll leave it as is at the moment,
but if I see any problems, I'll use Rick Wrights one liner in rc.local.
chrt -p -f 86 `pidof "IRQ-10"`
6:18 p.m.
On Monday 08 October 2007 19:03, Rick Wright wrote:
Nigel Henry wrote:
Sorry. I didn't wish to give you undeserved praise for the one liner. I too
pass on the odd bit of script that I've received from others on various
lists, and don't wish to take the credit for it.
My bash scripting knowledge is virtually nill, and have always been gratefull
for the help provided by folks more knowledgeable than me.
I installed the abs-guide a while back, but shame on me, it's sitting there
in /usr/share/doc, and nobody's prodding me in the back saying "Come on man,
get your act together, and learn some scripting".
I'll have to google a bit, and see if there's some on-line bash scripting
course, with example scripts to try out, and help if there are problems with
them.
Perhaps I'm just getting a bit old, but it would be nice to understand how
this stuff works.
Nigel.
On Monday 08 October 2007 09:13, porl sheean
wrote:
Nigel,
I appreciate the recognition for pointing you at this one line bit of RT
magic. However, this little gem was not my cleverness, but rather
something contributed by one of the other LAU members ~2 years back (the
proof is surely in the archives). The real credit goes to this
community for the vast collection of knowledge, experience, and
willingness to help!
Anyhow, I'm glad it's working for you and I agree with Porl's idea that
you simply use it to patch up any remaining issues after rtirq does it's
configuring.
Good luck,
Rick if it were me, and the only problem left is one
irq priority setting, i
would add a chrt line in the startup options manually (after rtirq). that
way you aren't messing with anything else.
porl
Yes. That might be the easiest thing to do. I'll leave it as is at the
moment, but if I see any problems, I'll use Rick Wrights one liner in
rc.local.
chrt -p -f 86 `pidof "IRQ-10"`
4 Oct
4 Oct
3:34 p.m.
On Thursday 04 October 2007 18:10, Florian Schmidt wrote:
Yes.
I'll run your rt-setup-report script on Fedora 7 first I think. I didn't have
to change soundcard prio's on that. Not sure how to progress from there at
the moment. Perhaps I'll ask Fernando, and find out whats what, if running
your script shows a high prio for the soundcard on Fedora 7, with planetccrma
lowlatency rt kernel, and rtirq installed.
On Thursday 04 October 2007, Nigel Henry wrote:
Bad to reply to my own post, but I've resolved the problem.
I never quite understood what was supposed to be bad about replying to
one's own post.. :)
Me neither, but I've seen so many folks saying it, that I said it. That's 2
times I've said it now, for the first time, and the last time.
Ok, you have not done any irq priority tuning.. Try
setting the
IRQ-10 process [your emu10k1] to prio 90..
I'm not sure what I'm doing here. I presume I need to use chrt to
change the priority, but am not sure of the correct syntax. The current
pid for IRQ10 is 940.
Could you give me a line that will work for this pid, as the man page
is pretty hopeless with no examples, and about 3 hrs of googling turned
up virtually nothing.
Many thanks.
Nigel.
> Flo One xrun after 6m 33secs of 0.253 msecs, which is
what I'm getting on
Fedora 7.
With soundcard irq prio at 90 [not shared with any other device], Jack prio
at 70 and all other irq prios at default 51?
Then it's either an application bug [are you running any applications]? Or
a bug in the emu10k1 driver. Or in jackd, though i suppose that's rather
unlikely..
Xawtv is running, and also Gkrellm. Ntpd is getting it's time from
the other
machine, but the 6m 25sec xrun intervals don't match with ntpd's polling.
Freshclam is running, but I'm not sure how often that checks for updates.
Saying that though, The first xrun occurs about 6m 25secs after starting
jackd, which is on both Debian Etch, and Fedora 7 on the same machine. If an
app was responsible for the xruns I'd have thought that the first xrun after
starting jackd would be logged at xm xsecs, and after that, at 6m 25sec
intervals. Is an xrun of 0.250 msecs, at 6m 25sec intervals going to be
noticeable on a piece of music?
Will that change of priority I've made for
the soundcard on the current
pid, hold after a reboot?
Nope.. It will be started with the default prio again. Have a look at the
rtirq script or fiddle your own initscript. Most distros have some "local"
init script where you put that command..
Flo
Thank you for all your help.
Nigel.
30 Nov
30 Nov
7:15 a.m.
Nigel Henry wrote:
Hi Will. I thought you were going to plug 64studio
before I looked at your
reply. I really wanted to resolve the problem on Debian Etch, and Lenny, but
will have to give 64studio a try.
Yup, so did we. :)
Hence 64studio.com and debian-multimedia.org
All this work is cycled back into the main Debian repositories, but
because Debian is slow on the uptake as packages have to build on
several obscure architectures before they can be accepted it's better to
track the above directly.
I've just been to the 64studio site, but doh,
it's only available as a dvd
download for 32bit, and I have a problem with dvd's, like no dvd writer.
Why don't you just apt-get it?
cheers,
tim
/|\
7:53 a.m.
New subject: 65 Studio and debian-multimedia.org
tim hall wrote:
Hence 64studio.com and debian-multimedia.org
Hi Tim,
I have a quick question: Can the packages found at debian-multimedia be
safely installed over the packages from 64 Studio's repos ? I need
mencoder (or its equivalent) on the 64-bit box, and it looks like the
necessary packages are available from debian-multimedia. But I thought I
should check with someone first ...
Best,
dp
8:18 a.m.
New subject: 65 Studio and debian-multimedia.org
Hi,
well i'm a Debian user, but since 64s is debian based, there's no
problem with the two repositories, so you can have both and download
the packages you need. I usually do that with an even worse case:
mixing lenny and sid repositories. I cross my fingers, and i only do
install ONE package i need, and after that i comment out the sid
repositories in sources.list.
Anyway you have to take care if some library is going to be
"overridden". In this case some apps looking for the old library could
not find the right library version, though i've never had that
problem.
Best,
Juan.
8:28 a.m.
New subject: 65 Studio and debian-multimedia.org
On Fri, 2007-11-30 at 13:18 +0100, Diseño treees wrote:
Hi,
well i'm a Debian user, but since 64s is debian based, there's no
problem with the two repositories, so you can have both and download
the packages you need. I usually do that with an even worse case:
mixing lenny and sid repositories. I cross my fingers, and i only do
install ONE package i need, and after that i comment out the sid
repositories in sources.list.
No need to edit the files everytime, just give the Sid repositories a
negative priority in /etc/apt/preferences and 'apt-get install -t
unstable package' when you want to get something from the unstable
repositories.
--ll
8:49 a.m.
New subject: 65 Studio and debian-multimedia.org
On 2007-11-30 12:40, Diseño treees wrote:
well i'm a Debian user, but since 64s is debian
based, there's no
problem with the two repositories, so you can have both and download
the packages you need. I usually do that with an even worse case:
mixing lenny and sid repositories. I cross my fingers, and i only do
install ONE package i need, and after that i comment out the sid
repositories in sources.list.
Examples are always good so here is what works for me...
# cat /etc/apt/preferences
Package: *
Pin: release a=stable
Pin-Priority: 700
Package: *
Pin: release a=testing
Pin-Priority: 650
Package: *
Pin: release a=unstable
Pin-Priority: 600
and I have multiple stable/testing/unstable entries in my
/etc/apt/sources.list which then allows me to install any
package with a...
apt-get -t unstable install amarok
and not have to worry about editing files. If a package
seems to have trouble starting then use "ldd /path/to/proggie"
and see if any libs are missing. Overall one of the best
strategies I find is to have a few "spare" 5Gb to 10Gb
partitions available for various system installs and use
a common large /home partition. This way you can have
32bit/64bit 64studio, ubuntustudio and any other distros
all just a boot away (or a kvm/virtualbox invocation away).
--markc
4 Oct
4 Oct
6:46 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Folderol wrote:
64studio (V2) is based on debian etch and comes in 64
& 32 bit
versions. It is fully RT patched.
The latest ubuntu (gutsy) also has a realtime
kernel you can install
from the repos. It's probably the default for ubuntustudio if you do a
clean install.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHBVE1yQ3sfGecJBIRAtDYAKCUTuhVevXpdii0LnNoI9QOpgA6IwCghmGo
CCARFhLitv73AeQBRMji0qA=
=QZIA
-----END PGP SIGNATURE-----
6 Oct
6 Oct
7:09 p.m.
i have had no end of trouble with this one. always get glitchy audio and
*hundreds* of xruns. when i downloaded and used the kernel from 64studio
(still running ubuntu though) they went away. i did a diff of the kernel
configs and couldn't see anything that explains it (although it has been a
long time since i played around in kernel config land, so some options may
have eluded me... good old gentoo days :). i can only assume that some
patches are in one of the kernel that are causing the issue, or maybe the
fact that gutsy's rt kernel has more drivers is causing conflict.
i will try the script mentioned earlier (rt-setup-report.sh) on each and
compare the difference. maybe it is as simple as an irq priority or
something.
still, it might not hurt to do what i did and try the 64studio kernel. (need
to find an smp version though, the one i got from the apt pool doesn't seem
to have it).
porl
On 05/10/2007, Robert Persson <ireneshusband(a)gmail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Folderol wrote:
64studio (V2) is based on debian etch and comes
in 64 & 32 bit
versions. It is fully RT patched.
The latest ubuntu (gutsy) also has a realtime
kernel you can install
from the repos. It's probably the default for ubuntustudio if you do a
clean install.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHBVE1yQ3sfGecJBIRAtDYAKCUTuhVevXpdii0LnNoI9QOpgA6IwCghmGo
CCARFhLitv73AeQBRMji0qA=
=QZIA
-----END PGP SIGNATURE-----
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
17 Oct
17 Oct
6:37 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I started having some problems with xruns recently (once I started
going beyond working only with soundfonts in the soundcard) and it
turned out that jack was failing to acquire realtime privileges. This
turns out to be a known issue with Ubuntustudio. It can be remedied by
making sure you have lines such as the following somewhere in
/etc/security/limits.conf :
@audio - rtprio 99
@audio - memlock 512000
@audio - nice -10
Robert
porl sheean wrote:
i have had no end of trouble with this one. always get
glitchy
audio and *hundreds* of xruns. when i downloaded and used the
kernel from 64studio (still running ubuntu though) they went away.
i did a diff of the kernel configs and couldn't see anything that
explains it (although it has been a long time since i played around
in kernel config land, so some options may have eluded me... good
old gentoo days :). i can only assume that some patches are in one
of the kernel that are causing the issue, or maybe the fact that
gutsy's rt kernel has more drivers is causing conflict.
i will try the script mentioned earlier (rt-setup-report.sh) on
each and compare the difference. maybe it is as simple as an irq
priority or something.
- --
Robert Persson
ireneshusband(a)gmail.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHFnJzyQ3sfGecJBIRAszHAJ44ShATcZghts3BKOrpm83EKWMl2gCgk2w3
LLlSpdWuxpGMo0rEKVutgaI=
=RroX
-----END PGP SIGNATURE-----
30 Nov
30 Nov
7:11 a.m.
Nigel Henry wrote:
Do you know if there are any debian rt patched kernels
available for other
debian based distros, that might work on Etch, or Lenny?
The 64 Studio kernels work with Debian based systems.
Slightly worrying to notice I haven't read LAU for two whole months
cheers,
tim
/|\
2:36 p.m.
On Friday 30 November 2007 12:10, tim hall wrote:
Nigel Henry wrote:
Have you got a URL I can use to access 64 studio repo
from /etc/apt/sources.list
Do you know if there are any debian rt patched
kernels available for
other debian based distros, that might work on Etch, or Lenny?
The 64 Studio kernels work with Debian based systems.
Slightly worrying to notice I haven't read LAU for two whole months
Shame on you.
cheers,
tim
Cordialement.
Nigel.
30 Sep
30 Sep
2:24 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, Sep 30, 2007 at 04:02:47PM +0200, Nigel Henry wrote:
On Debian Etch, using kernel 2.6.18-5-686, which I
presume is a realtime one,
as when I start jack with qjackctl, and with the realtime box checked, jack
doesn't complain.
Looking at messages though, shows lots of xruns, although no music apps are
being used.
I had this problem on Fedora 7. I'd installed the low latency kernel, and
associated packages from planetccrma, and again jacks messages were showing
lots of xruns. There was an updated pam that came with the kernel download,
which left an /etc/security/limits.conf.rpmnew, and Fernando suggested adding
the changes to the existing file, as the default setup for
jack-audio-connection-kit in the limits.conf file set rtprio at 20.
That resolved the problem on Fedora 7. No more messages about xruns.
I tried the same few lines, as below, in the limits.conf file in Etch, but to
no success, and there are no default priorities for jack there anyway.
I advise running sid, or testing, not etch.
My notes from the experience are here:
http://www.restivo.org/blog/archives/119
http://www.restivo.org/blog/archives/113
I've been told that testing is a reasonable alternative to sid, now that it has
usefully-current versions of many of the key audio packages.
- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG/813e8HF+6xeOIcRAkXkAJ0aIWeftM/rRQFjEIQlzxaoKQJGDwCg9tFK
vYdx9LmdIa+a5OITQdbShRw=
=aTrv
-----END PGP SIGNATURE-----
2:56 p.m.
On Sunday 30 September 2007 18:23, Ken Restivo wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, Sep 30, 2007 at 04:02:47PM +0200, Nigel Henry wrote:
Hi Ken. I do run Lenny as well, but am trying to resolve the realtime problem
on both Etch, and Lenny.
Nigel.
btw: I will check out your blogs.
On Debian Etch, using kernel 2.6.18-5-686, which
I presume is a realtime
one, as when I start jack with qjackctl, and with the realtime box
checked, jack doesn't complain.
Looking at messages though, shows lots of xruns, although no music apps
are being used.
I had this problem on Fedora 7. I'd installed the low latency kernel, and
associated packages from planetccrma, and again jacks messages were
showing lots of xruns. There was an updated pam that came with the kernel
download, which left an /etc/security/limits.conf.rpmnew, and Fernando
suggested adding the changes to the existing file, as the default setup
for
jack-audio-connection-kit in the limits.conf file set rtprio at 20.
That resolved the problem on Fedora 7. No more messages about xruns.
I tried the same few lines, as below, in the limits.conf file in Etch,
but to no success, and there are no default priorities for jack there
anyway.
I advise running sid, or testing, not etch.
My notes from the experience are here:
http://www.restivo.org/blog/archives/119
http://www.restivo.org/blog/archives/113
I've been told that testing is a reasonable alternative to sid, now that it
has usefully-current versions of many of the key audio packages.
- -ken
6204
days inactive
6265
days old
linux-audio-user@lists.linuxaudio.org
49 comments
16 participants
participants (16)
-
Dave Phillips -
Diseño treees -
Florian Schmidt -
Folderol -
Ken Restivo -
Lars Luthman -
Marcos Guglielmetti -
Mark Constable -
Nigel Henry -
porl sheean -
Rick Wright -
Robert Persson -
Roman Muñoz -
Rui Nuno Capela -
tim hall -
Wolfgang Woehl