3 Oct
2004
3 Oct
'04
3:27 p.m.
Hi,
As usual, this is a bit long as it's a difficult subject to explain
completely. Sorry. Read only if you are interested in xrun problems
under 2.6 kernels.
I'm on a quest to get my low latency kernel situation handled
better then it has been in the past. On my Planet box, which is an
older 500MHz P3 box, I still run a 2.4 series kernel supplied by
Fernando and it works well. On my Gentoo laptop, which in the past has
been more of an email/soft-synth machine, latency didn't matter as
much, but with Ardour approaching 1.0, and with jack_fst working very
will with some Native Instrument VSTs, I'd like to get my Gentoo box
up to world class. The hard part, however, is that the chipset in my
laptop requires the use of >=2.6.3 kernels to get hard drive DMA
support. The machine under test is a Compaq Presario R3070us laptop -
3GHz P4, 512MB, 80GB, ATI Radeon Mobility, CD-RW/DVD+RW with on-board
ATI sound built in. It has three operating systems - Win XP Pro for
remote Pro Tools recording, Gentoo Linux and FC2/PlanetCCRMA.
First the good news. On my PlanetCCRMA installation, and using a
custom 2.6.9 kernel that I built with significant help from Fernando,
Lee Revell and Ingo Molnar, I am getting absolutely phenominal
results. As a user I am running Jack using QJC with settings of 64/2,
alsaplayer using realtime access playing CDs through Jack, while also
running Mozilla doing GMail, gkrellm, and to top it off running
glxgears and getting 1700FPS, all while getting ZERO xruns. I am able
to change workspaces in fluxbox as well as drop down to the console
without causing a single xrun. (This was done under fluxbox. My
initial tests under KDE/Planet were not quite so good.) While this is
a leading edge and fairly untested kernel, the results for the future
of Linux audio kernels looks really bright.
Now, unfortunately my results under Gentoo have not been so good.
To make the test as fair as possible I've copied the Planet
/usr/src/linux directory to my Gentoo /usr/src directory. I then saved
the .config file, did a make mrproper, and then replaced the .config
file back in /usr/src/linux. I did a cursory check of the config using
make menuconfig and then the kernel was built and installed using the
command
make bzImage modules modules_install
and then copyed the kernel to /boot and modified grub.conf. The kernel
boots, apparently cleanly, although a few strange things happen with
fonts in the boot console. I log in, do startx to get fluxbox up and
going, and at this point start setting up the same sort of
environment. It doesn't take long before problems show up. The
following is the message screen from qjackctl.
08:10:14.157 Statistics reset.
08:10:14.275 MIDI connection graph change.
08:10:43.246 JACK is starting...
08:10:43.247 /usr/bin/jackd -R -dalsa -dhw:0 -r44100 -p64 -n2
08:10:43.252 JACK was started with PID=14453 (0x3875).
cannot write to jackstart sync pipe 4 (Bad file descriptor)
jackd: wait for startup process exit failed
jackd 0.98.1
Copyright 2001-2003 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
loading driver ..
apparent rate = 44100
creating alsa driver ... hw:0|hw:0|64|2|44100|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 44100Hz, period = 64 frames, buffer = 2 periods
08:10:45.345 Server configuration saved to "/root/.jackdrc".
08:10:45.346 Statistics reset.
08:10:45.356 Client activated.
08:10:45.357 Audio connection change.
08:10:45.359 Audio connection graph change.
08:10:57.023 Audio connection graph change.
08:10:57.216 Audio connection change.
(At this point Jack is up and running under Gentoo. Everything from
here on starts with I start alsaplayer)
delay of 29045.000 usecs exceeds estimated spare time of 1333.000; restart ...
08:11:03.764 XRUN callback (1).
delay of 14368.000 usecs exceeds estimated spare time of 1333.000; restart ...
08:11:04.040 XRUN callback (2).
delay of 14602.000 usecs exceeds estimated spare time of 1333.000; restart ...
08:14:13.147 XRUN callback (3).
delay of 14369.000 usecs exceeds estimated spare time of 1333.000; restart ...
08:16:38.493 XRUN callback (4).
delay of 13441.000 usecs exceeds estimated spare time of 1331.000; restart ...
(At this point I stop alsaplayer.)
08:20:17.335 XRUN callback (5).
**** alsa_pcm: xrun of at least 0.030 msecs
08:20:39.830 XRUN callback (6).
08:20:39.831 XRUN callback (7).
08:20:39.831 XRUN callback (8).
**** alsa_pcm: xrun of at least 0.034 msecs
**** alsa_pcm: xrun of at least 0.023 msecs
08:20:40.010 Audio connection graph change.
**** alsa_pcm: xrun of at least 0.023 msecs
08:21:46.441 XRUN callback (9).
08:21:46.442 XRUN callback (10).
Looking above there were 4 very large timing misses in Jack. Nothing
like this has occurred when I run the Planet version of the same
kernel. While the xruns at the end, when alsaplayer is turned off, are
bothersome, I'm not overly concerned about those. That said those do
not happen on my Planet version either.
There are f ew, apparently unrelated, messages in dmesg about USB problems.
I've tried a number of things like rebuilding Jack and rebuilding
alsaplayer. They have not helped. There appeared to be far more
warning messages about the kernel when I built it under Gentoo. I
presume my c compiler and glibc are newer under Gentoo. Here's the
info:
flash root # emerge info
Portage 2.0.50-r11 (default-x86-2004.0, gcc-3.3.4,
glibc-2.3.3.20040420-r1, 2.6.9-rc2-mm4-VP-S7)
=================================================================
System uname: 2.6.9-rc2-mm4-VP-S7 i686 Mobile Intel(R) Pentium(R) 4
CPU 3.06GHz
Gentoo Base System version 1.4.16
Autoconf: sys-devel/autoconf-2.59-r4
Automake: sys-devel/automake-1.8.5-r1
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
COMPILER=""
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config
/usr/kde/3.3/shutdown /usr/kde/3/share/config
/usr/lib/mozilla/defaults/pref /usr/share/config
/usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/
/usr/share/texmf/tex/generic/config/
/usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/
/var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache sandbox"
GENTOO_MIRRORS="http://mirror.tucdemonic.org/gentoo/
ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo http://mirror.gentoo.gr.jp
http://www.zentek-international.com/mirrors/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X aalib alsa apm audiofile avi berkdb bitmap-fonts caps cdr crypt
cups dvd dvdr encode esd fluidsynth foomaticdb gdbm gif gimp gimpprint
gphoto2 gpm gtk gtk2 guile imlib jack jack-tmpfs java jpeg ladcca
libg++ libwww mad mikmod mmx motif mozcalendar mozilla mpeg ncurses
nls oggvorbis opengl oss pam pdflib perl png ppds python qt quicktime
readline sdl slang spell sse ssl svga tcltk tcpd tetex truetype usb
video_cards_radeon x86 xml2 xmms xprint xv zlib"
So, the question at hand is why should the same kernel, built under
two different distro's, but run on the same machine, produce different
results. It's likely either what the compiler flags were, or what the
libraries were, or what was running in the background. (So I think...)
Any ideas on how I can get to the botom of this?
Thanks,
Mark
3 Oct
3 Oct
4:46 p.m.
On Sun, Oct 03, 2004 at 10:09:41 -0700, Mark Knecht wrote:
So, the question at hand is why should the same
kernel, built under
two different distro's, but run on the same machine, produce different
results. It's likely either what the compiler flags were, or what the
libraries were, or what was running in the background. (So I think...)
Have you tried just booting the planet built kernel under gentoo?
- Steve
5:08 p.m.
On Sun, 3 Oct 2004 19:28:41 +0100, Steve Harris
<s.w.harris(a)ecs.soton.ac.uk> wrote:
On Sun, Oct 03, 2004 at 10:09:41 -0700, Mark Knecht
wrote:
Steve,
I have not been that bold. would it work? At a minimum I'm fairly
sure that glibc and gcc itself are different versions. Right or wrong
my Gentoo box is updated almost daily to whatever the Gentoo gods
consider 'stable', which is not as stable as you and I would
necessarily call stable. Still, it's an interesting idea. Whatwoudl I
drage over? The kernel binary and all of /lib/modules/this-kernel?
Cheers & a happy Sunday to you,
Mark
So, the question at hand is why should the
same kernel, built under
two different distro's, but run on the same machine, produce different
results. It's likely either what the compiler flags were, or what the
libraries were, or what was running in the background. (So I think...)
Have you tried just booting the planet built kernel under gentoo?
- Steve
5:41 p.m.
On Sun, Oct 03, 2004 at 11:51:29 -0700, Mark Knecht wrote:
On Sun, 3 Oct 2004 19:28:41 +0100, Steve Harris
<s.w.harris(a)ecs.soton.ac.uk> wrote:
I /think/ it might work, yes, the kernel doesnt link against libc (or
anything else for that matter), so I dont think compatibility is an issue.
The /boot/* stuff would be needed and /lib/modules, but I think thats
enough.
Whats the worst that could happen ;)
On Sun, Oct 03, 2004 at 10:09:41 -0700, Mark
Knecht wrote:
Steve,
I have not been that bold. would it work? At a minimum I'm fairly
sure that glibc and gcc itself are different versions. Right or wrong
my Gentoo box is updated almost daily to whatever the Gentoo gods
consider 'stable', which is not as stable as you and I would
necessarily call stable. Still, it's an interesting idea. Whatwoudl I
drage over? The kernel binary and all of /lib/modules/this-kernel? So, the question at hand is why should the
same kernel, built under
two different distro's, but run on the same machine, produce different
results. It's likely either what the compiler flags were, or what the
libraries were, or what was running in the background. (So I think...)
Have you tried just booting the planet built kernel under gentoo?
- Steve
Cheers & a happy Sunday to you,
Happy sunday to you too, and good luck if you try it :)
- Steve
5:50 p.m.
On Sun, 3 Oct 2004 20:24:19 +0100, Steve Harris
<s.w.harris(a)ecs.soton.ac.uk> wrote:
I /think/ it might work, yes, the kernel doesnt link
against libc (or
anything else for that matter), so I dont think compatibility is an issue.
The /boot/* stuff would be needed and /lib/modules, but I think thats
enough.
Whats the worst that could happen ;)
Humm...I don't know what the worst is that could happen. Probably
nothing bad and it really wouldn't be that difficult to try. However,
let's say I do it and it works, or I do it and it doesn't work. At
that point what have I learned and how would it help me?
I'm not against trying - I'm just not sure where it's leading? Toward
a compiler issue? Toward a glibc issue? Something else?
It would be funny to end up running Gentoo but *having* to build my
kernels on a Fedora box! ;-)
- Mark
Cheers & a happy Sunday to you,
Happy sunday to you too, and good luck if you try it :)
- Steve
6:39 p.m.
On Sun, Oct 03, 2004 at 12:33:13 -0700, Mark Knecht wrote:
Humm...I don't know what the worst is that could
happen. Probably
nothing bad and it really wouldn't be that difficult to try. However,
let's say I do it and it works, or I do it and it doesn't work. At
that point what have I learned and how would it help me?
Well, I think the only difference is the compiler, so it would tell us
that the compiler is making a differece. If the plant kernel still gives
you xruns it tells you that some of the system stuff in gentoo is causing
you problems.
One thing that occurs is the filesystems, I think only ext[23] has been RT
tuned in 2.6, so if your gentoo system is using something else that could
be your problem.
It would be funny to end up running Gentoo but
*having* to build my
kernels on a Fedora box! ;-)
Funny, or very anoying :)
- Steve
6:55 p.m.
On Sun, 3 Oct 2004 21:21:43 +0100, Steve Harris
<s.w.harris(a)ecs.soton.ac.uk> wrote:
Yep! OK, I'll give this a try and see what happens. the way I see it I need to:
1) Move /lib/modules out of the way
2) Copy over the 2.6.9 directory from FC2
3) Copy over the 2.6.9-FC2 kernel
4) Edit grub.conf
5) Reboot, as Fernando says, with finges crossed.
Wish I had some backups! ;-)
- Mark
On Sun, Oct 03, 2004 at 12:33:13 -0700, Mark Knecht
wrote:
OK, so no one else has raised a warning, but traffic is slow on
Sundays. I guess I'm brave enough to try it. I'll make the copy and
see what happens.
Humm...I don't know what the worst is that
could happen. Probably
nothing bad and it really wouldn't be that difficult to try. However,
let's say I do it and it works, or I do it and it doesn't work. At
that point what have I learned and how would it help me?
Well, I think the only difference is the compiler, so it would tell us
that the compiler is making a differece. If the plant kernel still gives
you xruns it tells you that some of the system stuff in gentoo is causing
you problems.
One thing that occurs is the filesystems, I think only ext[23] has been RT
tuned in 2.6, so if your gentoo system is using something else that could
be your problem.
No, they are both 2.6.8 or higher. Gentoo has been 2.6.8.1 for a
while. FC2 customized is now 2.6.9 + features. That part should be OK.
(I hope.)
It would be funny to end up running Gentoo but
*having* to build my
kernels on a Fedora box! ;-)
Funny, or very anoying :) 
7:25 p.m.
Your not being bitten by the ntpl issue are you?
Dave
On Sunday 03 October 2004 21:37, Mark Knecht wrote:
On Sun, 3 Oct 2004 21:21:43 +0100, Steve Harris
<s.w.harris(a)ecs.soton.ac.uk> wrote:
Yep! OK, I'll give this a try and see what happens. the way I see it I need
to:
1) Move /lib/modules out of the way
2) Copy over the 2.6.9 directory from FC2
3) Copy over the 2.6.9-FC2 kernel
4) Edit grub.conf
5) Reboot, as Fernando says, with finges crossed.
Wish I had some backups! ;-)
- Mark
On Sun, Oct 03, 2004 at 12:33:13 -0700, Mark
Knecht wrote:
OK, so no one else has raised a warning, but traffic is slow on
Sundays. I guess I'm brave enough to try it. I'll make the copy and
see what happens.
Humm...I don't know what the worst is that
could happen. Probably
nothing bad and it really wouldn't be that difficult to try. However,
let's say I do it and it works, or I do it and it doesn't work. At
that point what have I learned and how would it help me?
Well, I think the only difference is the compiler, so it would tell us
that the compiler is making a differece. If the plant kernel still gives
you xruns it tells you that some of the system stuff in gentoo is causing
you problems. One thing that occurs is the filesystems, I think
only ext[23] has been
RT tuned in 2.6, so if your gentoo system is using something else that
could be your problem.
No, they are both 2.6.8 or higher. Gentoo has been 2.6.8.1 for a
while. FC2 customized is now 2.6.9 + features. That part should be OK.
(I hope.)
It would
be funny to end up running Gentoo but *having* to build my
kernels on a Fedora box! ;-)
Funny, or very anoying :)
8:40 p.m.
On Sun, 3 Oct 2004 21:21:43 +0100, Steve Harris
<s.w.harris(a)ecs.soton.ac.uk> wrote:
On Sun, Oct 03, 2004 at 12:33:13 -0700, Mark Knecht
wrote:
Steve,
Hi. Well, I'm now talkign to you from a Planet kernel booted in a
Gentoo environment. It took mea few tries to get things in the right
place before it would boot. I'm sort of surprised it worked, but the
time onthe kernel is correct:
flash root # uname -a
Linux flash 2.6.9-rc2-mm4-VP-S7 #3 SMP Sat Oct 2 06:08:41 PDT 2004
i686 Mobile Intel(R) Pentium(R) 4 CPU 3.06GHz GenuineIntel
GNU/Linux
flash root #
Unfortunately (or furtunately maybe) the xruns continue with this
kernel when booted under Gentoo. The number of xruns seems similar
whether I use the FC2/Planet version or the one I built under Gentoo.
Now --- what does this tell me?
1) That there is nothign wrong with the Gentoo kernel build process? I
think that's the case, and that's good.
2) That there is something else about the setup of the system under
Gentoo that's causing this to happen? I guess - maybe this is true.
What now? I'm not at all sure what to do next. Compare ps -aux stacks
from both sides? I've already tried the simple things that were
different, like turning off xsceensavers which I had under Gentoo but
not under FC2 since I'd just set it up.
Any ideas??????
Cheers,
Mark
Cheers,
Mark
Humm...I don't know what the worst is that
could happen. Probably
nothing bad and it really wouldn't be that difficult to try. However,
let's say I do it and it works, or I do it and it doesn't work. At
that point what have I learned and how would it help me?
Well, I think the only difference is the compiler, so it would tell us
that the compiler is making a differece. If the plant kernel still gives
you xruns it tells you that some of the system stuff in gentoo is causing
you problems.
One thing that occurs is the filesystems, I think only ext[23] has been RT
tuned in 2.6, so if your gentoo system is using something else that could
be your problem.
8:57 p.m.
On Sun, Oct 03, 2004 at 03:23:11 -0700, Mark Knecht wrote:
Unfortunately (or furtunately maybe) the xruns
continue with this
kernel when booted under Gentoo. The number of xruns seems similar
whether I use the FC2/Planet version or the one I built under Gentoo.
Now --- what does this tell me?
1) That there is nothign wrong with the Gentoo kernel build process? I
think that's the case, and that's good.
2) That there is something else about the setup of the system under
Gentoo that's causing this to happen? I guess - maybe this is true.
Yep.
If you've allready checked the threading library versions (someone
allready metioned that) I would look at filesystems and mount options.
X drivers are a possbilitlity, but most of the other drivers should be the
same as youre running the same kernel, so it reduces the number of
variables a lot.
- Steve
9:11 p.m.
<SNIP>
Yep.
If you've allready checked the threading library versions (someone
allready metioned that) I would look at filesystems and mount options.
X drivers are a possbilitlity, but most of the other drivers should be the
same as youre running the same kernel, so it reduces the number of
variables a lot.
- Steve
SO I guess it could also be a problem of some sort with the Gentoo
ebuilds for Jack or Jack apps. Another possibility I almost called
attention to earlier is this little bit of text when Jack starts up:
(It was in the initial email)
<SNIP>
08:10:43.247 /usr/bin/jackd -R -dalsa -dhw:0 -r44100 -p64 -n2
08:10:43.252 JACK was started with PID=14453 (0x3875).
cannot write to jackstart sync pipe 4 (Bad file descriptor)
jackd: wait for startup process exit failed
jackd 0.98.1
Copyright 2001-2003 Paul Davis and others.
<SNIP>
What is a 'jackstart sync pipe 4'? Could this error be part of the
problem? I have to boot back to FC2 to see if it's there, but from
memory I thought maybe it wasn't...
- Mark
10:06 p.m.
On Sun, 2004-10-03 at 15:54, Mark Knecht wrote:
<SNIP>
Yes, that may be the problem, my guess would be that jack may not be
getting realtime priority. I would check that all processes involved
(jackd and the clients as well) are really running SCHED_FIFO (ie: with
realtime priority).
The program to use is chrt (/usr/bin/chrt, part of the schedutils
package, don't know where you would find it on gentoo).
/usr/bin/chrt -p PID
(where PID is the process id of the process you want to check)
A ps -auxw will list all processes, but if you are running nptl it will
not list all threads (I think there is also an option for ps to show
them, can't remember it now), you can find the pid of all the threads
for a given process in /proc/PID/task/*
-- Fernando
Yep.
If you've allready checked the threading library versions (someone
allready metioned that) I would look at filesystems and mount options.
X drivers are a possbilitlity, but most of the other drivers should be the
same as youre running the same kernel, so it reduces the number of
variables a lot.
- Steve
SO I guess it could also be a problem of some sort with the Gentoo
ebuilds for Jack or Jack apps. Another possibility I almost called
attention to earlier is this little bit of text when Jack starts up:
(It was in the initial email)
<SNIP>
08:10:43.247 /usr/bin/jackd -R -dalsa -dhw:0 -r44100 -p64 -n2
08:10:43.252 JACK was started with PID=14453 (0x3875).
cannot write to jackstart sync pipe 4 (Bad file descriptor)
jackd: wait for startup process exit failed
jackd 0.98.1
Copyright 2001-2003 Paul Davis and others.
<SNIP>
What is a 'jackstart sync pipe 4'? Could this error be part of the
problem? I have to boot back to FC2 to see if it's there, but from
memory I thought maybe it wasn't... 
10:45 p.m.
On Sun, 2004-10-03 at 19:48, Fernando Pablo Lopez-Lezcano wrote:
On Sun, 2004-10-03 at 15:54, Mark Knecht wrote:
As a test, you could try building JACK from source (IOW, bypassing the
Gentoo ebuild process) and see if the problem persists. I agree with
Fernando that this looks like a problem with the Gentoo ebuild. I have
never seen that 'jackstart sync' message before. On 2.6 jackstart is
completely unnecessary. It looks like on Gentoo jackd might be a
wrapper script that exec's jackstart or something, which fails because
it can't get allcaps. Just a guess, I don't have access to a Gentoo
system.
The problem is that until recently, it was a safe assumption that anyone
using JACK would be on 2.4. Audio on 2.6 is a pretty recent
development, I would not be surprised if more bugs like this turn up.
Lee
<SNIP>
Yes, that may be the problem, my guess would be that jack may not be
getting realtime priority. I would check that all processes involved
(jackd and the clients as well) are really running SCHED_FIFO (ie: with
realtime priority).
Yep.
If you've allready checked the threading library versions (someone
allready metioned that) I would look at filesystems and mount options.
X drivers are a possbilitlity, but most of the other drivers should be the
same as youre running the same kernel, so it reduces the number of
variables a lot.
- Steve
SO I guess it could also be a problem of some sort with the Gentoo
ebuilds for Jack or Jack apps. Another possibility I almost called
attention to earlier is this little bit of text when Jack starts up:
(It was in the initial email)
<SNIP>
08:10:43.247 /usr/bin/jackd -R -dalsa -dhw:0 -r44100 -p64 -n2
08:10:43.252 JACK was started with PID=14453 (0x3875).
cannot write to jackstart sync pipe 4 (Bad file descriptor)
jackd: wait for startup process exit failed
jackd 0.98.1
Copyright 2001-2003 Paul Davis and others.
<SNIP>
What is a 'jackstart sync pipe 4'? Could this error be part of the
problem? I have to boot back to FC2 to see if it's there, but from
memory I thought maybe it wasn't...
11:16 p.m.
Lee & Fernando,
Thanks for the pointers. I've emerged schedutils and will see what
it tells me.
I'm actually makig some good headway on the Gentoo side. Being that
Gentoo is a system I use everyday it was of course set up to do far
more things than the Fedora partition which I set up to get a low
latency kernel. In looking at differences between the two I found a a
number of things:
1) Fedora Jack was 0.99, Gentoo was 0.98.1
2) Gentoo was running a whole host of processes at boot time - ntpd,
ntp-client, cupsd, and about 10 others of which I am not sure of their
reason for being there
3) I was running gkrellm, bbkeys and xscreensaver in my .xinitrc file
The I had previously tried turning off the 3 in #3 without much
effect. However, after updating to Jack 0.99.0 turning off the 3 in #3
has made a big difference. I have now been running 20 minutes at 64/2
with only 7 xruns total. Two come when alsaplayer starts playing the
CD. The other 5 have come while the CD is being played. These 5 are a
big improvement from the 50-100 I was getting earlier, but still not
good enough.
Also, the Fedora test has never cause an xrun when I press play in
alsaplayer, but under Gentoo it gives me two xruns every time.
Anyway, I think I'm making progress, but it's still not good enough.
Looking at X is another good thing to do. The Fedora build gives me
1700FPS running glxgears using 25% CPU while my Gentoo setup gives me
200FPS using 100% CPU. Clearly I'm accessing the graphics hardware
differently. This could certainly account for an odd time delay once
in awhile I'd think and may be part of why turning off gkrellm is
helping.
I'm wondering if the way that Fernando builds Jack is different than
the Gentoo ebuild? ?If so then I should try buildign by hand and, I
guess, placing that code someplace that is found before the
/usr/bin/jackd version. That may help if there is a difference. None
the less I think PlanetCCRMA users are in for a treat when this all
gets sorted out.
I'll let you more later in the week.
thanks,
Mark
On Sun, 03 Oct 2004 20:28:19 -0400, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Sun, 2004-10-03 at 19:48, Fernando Pablo
Lopez-Lezcano wrote:
On Sun, 2004-10-03 at 15:54, Mark Knecht wrote:
As a test, you could try building JACK from source (IOW, bypassing the
Gentoo ebuild process) and see if the problem persists. I agree with
Fernando that this looks like a problem with the Gentoo ebuild. I have
never seen that 'jackstart sync' message before. On 2.6 jackstart is
completely unnecessary. It looks like on Gentoo jackd might be a
wrapper script that exec's jackstart or something, which fails because
it can't get allcaps. Just a guess, I don't have access to a Gentoo
system.
The problem is that until recently, it was a safe assumption that anyone
using JACK would be on 2.4. Audio on 2.6 is a pretty recent
development, I would not be surprised if more bugs like this turn up.
Lee
<SNIP>
Yes, that may be the problem, my guess would be that jack may not be
getting realtime priority. I would check that all processes involved
(jackd and the clients as well) are really running SCHED_FIFO (ie: with
realtime priority).
Yep.
If you've allready checked the threading library versions (someone
allready metioned that) I would look at filesystems and mount options.
X drivers are a possbilitlity, but most of the other drivers should be the
same as youre running the same kernel, so it reduces the number of
variables a lot.
- Steve
SO I guess it could also be a problem of some sort with the Gentoo
ebuilds for Jack or Jack apps. Another possibility I almost called
attention to earlier is this little bit of text when Jack starts up:
(It was in the initial email)
<SNIP>
08:10:43.247 /usr/bin/jackd -R -dalsa -dhw:0 -r44100 -p64 -n2
08:10:43.252 JACK was started with PID=14453 (0x3875).
cannot write to jackstart sync pipe 4 (Bad file descriptor)
jackd: wait for startup process exit failed
jackd 0.98.1
Copyright 2001-2003 Paul Davis and others.
<SNIP>
What is a 'jackstart sync pipe 4'? Could this error be part of the
problem? I have to boot back to FC2 to see if it's there, but from
memory I thought maybe it wasn't...
7404
days inactive
7404
days old
linux-audio-user@lists.linuxaudio.org
13 comments
5 participants
participants (5)
-
Dave -
Fernando Pablo Lopez-Lezcano -
Lee Revell -
Mark Knecht -
Steve Harris