27 Dec
2007
27 Dec
'07
7:23 p.m.
I'm using an M-Audio Transit usb soundcard with the kernel 2.6.22-rt,
as packaged by ubuntu. I'm running jack right now with -p 3 -n 512,
and I still get xruns, typically of values less than .03ms, every few
minutes. Increasing the jack latency reduces the rate of xruns, but I
can't eliminate them without using settings large enough to cause
noticeable delay. I've raised the priority of the IRQ-16 process (the
one controlling the usb bus with the sound card); I also tried to use
setpci to tweak pci latencies, but for some reason the settings
wouldn't apply (when I read the values back, they haven't changed).
I've posted the results of rt-setup-report.sh (plus lsusb) at
http://artdent.homelinux.net/~jacob/rt-setup-report . Is there
anything else I can try?
Thanks,
--
Jacob Lee
artdent(a)gmail.com
27 Dec
27 Dec
8:30 p.m.
do you use Rui's rtprio? that should help. Are the tickless & hpet timers
enabled in the kernel ?
g.
9:53 p.m.
On Dec 27, 2007 6:30 PM, Geoff Beasley <songshop(a)bizmedia.com.au> wrote:
do you use Rui's rtprio? that should help. Are
the tickless & hpet timers
enabled in the kernel ?
I hadn't run into rtprio before. It seems to be a relatively blunt
tool for invoking chrt -- in my case, it finds an internal sound card
that I don't care about and also a few other usb-related interrupts
that don't need to be on high priority. It does, though, also increase
the priority of the rtc and i8042 irqs, which I hadn't been doing. So
now I'm (manually) setting rtc highest, followed by the irq for the
usb bus my soundcard is on, followed by the two i8042 interrupts. It
hasn't seemed to help, though.
Here are my HPET and timer settings. They -look- correct to me, though
I'm not really sure what they all mean. Is there anything else I
should look at?
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_HPET=y
# CONFIG_HPET_RTC_IRQ is not set
CONFIG_NO_HZ=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_HIGH_RES_TIMERS=y
--
Jacob Lee
artdent(a)gmail.com
28 Dec
28 Dec
6:16 a.m.
Jacob Lee wrote:
I'm using an M-Audio Transit usb soundcard with
the kernel 2.6.22-rt,
as packaged by ubuntu. I'm running jack right now with -p 3 -n 512,
Just to
check, but do you really use '-p3 -n512' or do you use '-p 512
-n 3'. That would make more sense.
Greets,
Pieter
12:27 p.m.
Sorry, I of course meant -n 3 -p 512. My full command line is:
jackd -R -P 70 -d alsa -d usb -p 512 -n 3 .
On Dec 28, 2007 4:16 AM, Pieter Palmers <pieterp(a)joow.be> wrote:
Jacob Lee wrote:
--
Jacob Lee
artdent(a)gmail.com
I'm using an M-Audio Transit usb soundcard
with the kernel 2.6.22-rt,
as packaged by ubuntu. I'm running jack right now with -p 3 -n 512,
Just to
check, but do you really use '-p3 -n512' or do you use '-p 512
-n 3'. That would make more sense.
Greets,
Pieter
11:46 a.m.
Am Freitag, 28. Dezember 2007 schrieb Jacob Lee:
I'm using an M-Audio Transit usb soundcard with
the kernel 2.6.22-rt,
as packaged by ubuntu. I'm running jack right now with -p 3 -n 512,
and I still get xruns, typically of values less than .03ms, every few
minutes.
You can try increasing the client timeout, i.e:
$ jackd -R -P60 -t200 ...
helps here using kernel 2.6.24-rcx.
((
jackd calls poll() with a timeout value of a period's ms each time
it triggers the external clients. Linux's poll() call can timeout at
(specified timeout - jiffy). IMHO either linux needs to be fixed to
implement posix poll() timeout handling, or jackd has to supply
(a period's ms + a jiffy's ms) as parameter for the poll() call.
))
Karsten
1:08 p.m.
On Dec 28, 2007 9:46 AM, Karsten Wiese <annabellesgarden(a)yahoo.de> wrote:
Am Freitag, 28. Dezember 2007 schrieb Jacob Lee:
Interesting. The default timeout is 500; I've tried lowering it
slightly and raising it to 1000 or 2000 without effect.
I'm using an M-Audio Transit usb soundcard
with the kernel 2.6.22-rt,
as packaged by ubuntu. I'm running jack right now with -p 3 -n 512,
and I still get xruns, typically of values less than .03ms, every few
minutes.
You can try increasing the client timeout, i.e:
$ jackd -R -P60 -t200 ...
helps here using kernel 2.6.24-rcx.
((
jackd calls poll() with a timeout value of a period's ms each time
it triggers the external clients. Linux's poll() call can timeout at
(specified timeout - jiffy). IMHO either linux needs to be fixed to
implement posix poll() timeout handling, or jackd has to supply
(a period's ms + a jiffy's ms) as parameter for the poll() call.
))
Karsten
Ah. These xruns occur even with no jack clients running, so this
option might not change anything. Another interesting data point is
that changing the values for -p and -n increase or decrease how often
xruns appear, but they are always of extremely low values (.020-.050
ms). One would think that adding a few milliseconds of extra latency
would eliminate such small xruns; or, reducing the latency would cause
xruns of much longer duration. I should also mention that I
occasionally get the message "delay of 10698.000 usecs exceeds
estimated spare time of 10547.000; restart ..." (with varying values
for the delay), but I've assumed this is just a manifestation of the
same issue; at any rate, such messages happen far less often than the
xruns.
--
Jacob Lee
artdent(a)gmail.com
6178
days inactive
6179
days old
linux-audio-user@lists.linuxaudio.org
6 comments
5 participants
participants (5)
-
Geoff Beasley -
Jacob Lee -
Jacob Lee -
Karsten Wiese -
Pieter Palmers