31 Jul
2008
31 Jul
'08
12:13 a.m.
Hi Folks
After a long (15 years) break in music making/recording, I have just set
myself up with a new virtual studio - bit of a culture shock when all my
previous experience was analogue plus Notator on an Atari.
I'm running Gentoo Linux (x86_64) on a dual-core ThinkPad with 1.5Gb
RAM. To save unnecessary processing overhead and because I like a
'clean' desktop, I am using the Fluxbox window manager.
My current studio consists of:
* Jack
* Rosegarden
* Zynaddsubfx
* Xsynth
* Fluidsynth
* Hydrogen
* Samson C01U USB microphone
* Behringer UCA202 audio adapter
* Roland/Edirol PC-300 MIDI controller
In an attempt to fix any latency issues, I have used the RT-modified
ketchup to get myself a kernel 2.6.25.8-rt7. RT profile is selected,
timer at 1kHz. I have stripped much of my day-to-day stuff out of the
kernel configuration so that I have a dual-boot configuration, one for
'normal' work, the other just for audio. I have also created a separate
profile for the RT kernel so that only essential services are started.
Whilst going from the 'low-latency desktop' of my standard kernel to the
RT kernel has made a huge difference in the number of xruns that I am
seeing on Jack, it hasn't cured them completely.
My test configuration routes my MIDI keyboard through Jack, to
Rosegarden to Jack, to Zynaddsubfx to Jack, to ALSA out. I find that
whilst playing - even when pushing down an unreasonable number of keys
very quickly - I don't get any clicks or pops. I do, however, get the
occasional xrun. Weird thing is that sometimes I get them when I'm
hardly doing anything at all.
Jack connection parameters are priority=9, Frames/Period=512, Sample
Rate=44100, Periods/Buffer=3.
At the end of dmesg, there seem to be a lot of errors or warnings -
don't know if they're significant. I've put them here:
<http://www.smiffysplace.com/files/dmesg_rt_20080731>
(For some reason, the top bit of dmesg got lost - hope this doesn't
matter. Can re-create if required.)
Kernel config is here:
<http://www.smiffysplace.com/files/kconfig_rt_20080731>
PAM is configured for the audio group (yes I am in it!):
@audio - rtprio 99
@audio - memlock 250000
@audio - nice -10
I've now pretty well exhausted the results of my Googling but am still
not sure what I'm doing wrong or if these xruns may be safely ignored
(I'm assuming they can't be). Any suggestions would be greatly appreciated!
Cheers
M
--
Matthew Smith
Smiffytech - Technology Consulting & Web Application Development
Business: http://www.smiffytech.com/
Personal: http://www.smiffysplace.com/
LinkedIn: http://www.linkedin.com/in/smiffy
31 Jul
31 Jul
2:22 a.m.
On Wed, Jul 30, 2008 at 7:13 PM, Matthew Smith <matt(a)smiffytech.com> wrote:
<SNIP
> At the end of dmesg, there seem to be a lot of errors or warnings -
> don't know if they're significant. I've put them here:
> <http://www.smiffysplace.com/files/dmesg_rt_20080731
> (For some reason, the top bit of dmesg got lost - hope this doesn't
> matter. Can re-create if required.)
> Kernel config is here:
> <http://www.smiffysplace.com/files/kconfig_rt_20080731
These are *absolutely* an issue and must be solved before you can
really move forward on the xrun problem. Solving this issue may
eliminate your xruns. Won't know until we get there.
I would look into joining the linux-rt-users email list and post the
bugs there. One of those folks will have a good idea what's going on
and what kernel config options are probably kicking it off. Even if
you find it yourself and eliminate it they will still want the info.
Good luck,
Mark
Hi Folks
After a long (15 years) break in music making/recording, I have just set
myself up with a new virtual studio - bit of a culture shock when all my
previous experience was analogue plus Notator on an Atari.
Welcome back!
I'm running Gentoo Linux (x86_64) on a dual-core ThinkPad with 1.5Gb
RAM. To save unnecessary processing overhead and because I like a
'clean' desktop, I am using the Fluxbox window manager.
Good choices.
9:24 a.m.
Matthew Smith wrote:
After a long (15 years) break in music
making/recording, I have just set
myself up with a new virtual studio - bit of a culture shock when all my
previous experience was analogue plus Notator on an Atari.
Well, my music making was pen and paper, an acoustic piano, classical
and electric guitars, and a portable cassette tape recorder ... I still
have that recording!
I'm running Gentoo Linux (x86_64) on a dual-core
ThinkPad with 1.5Gb
RAM. To save unnecessary processing overhead and because I like a
'clean' desktop, I am using the Fluxbox window manager.
I like it, too. Reminds me a bit of the design philosophy of the Targa
TIPS video painting program AT&T made for use with their line of Targa
video capture and editing cards ...
My guess about your xruns problem is ... do you have hardware on this
Thinkpad that perhaps is sharing interrupts with your audio hardware?
People on the list have mentioned getting xruns when a laptop had audio
and video hardware sharing the same interrupt and the system had to
update the display at the same time the audio hardware was in use.
Another source was unused wireless networking hardware - the system
would keep checking for a network connection even though there was none.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
3 Aug
3 Aug
9:25 p.m.
Quoth Matthew Smith at 2008-07-31 11:43...
<snip/>
In an attempt to fix any latency issues, I have used
the RT-modified
ketchup to get myself a kernel 2.6.25.8-rt7.
<snip/>
Whilst going from the 'low-latency desktop' of
my standard kernel to the
RT kernel has made a huge difference in the number of xruns that I am
seeing on Jack, it hasn't cured them completely.
Many thanks to those who responded on this issue - suggestions have been
taken on board and this is where we are now.
Having enquired of the linux-rt-users list, I was advised to use
2.6.24.7-rt17, being the "latest and greatest". It appears that my
issue with 2.6.25.8-rt7 is a know issue and that there are patches
available.
So, I duly built the recommended kernel and the errors in dmesg have
gone away.
I have looked at my /proc/interrupts and can't see any obvious conflicts.
However, I am now getting an almost constant stream of xruns - far worse
than when I was using a standard kernel. I tried disconnecting all my
external USB devices but the xruns continued to show up in a
never-ending stream.
Looking at the output of top and ps, there seem to be a lot of kernel
processes that weren't there before which makes me wonder if I haven't
stuffed up the configuration of the RT kernel. (I was having to guess
at the configuration values that were unfamiliar to me.)
For completeness, I should probably state that my fglrx (video) driver
no longer shows up in /proc/interrupts - the driver is incompatible with
RT kernels so I simply didn't install it. (The driver is a
closed-source one [with no available open source alternative] and the
installation process tells me to go away because it doesn't like RT or
low-latency kernels.) My X session looks fine without it, so I question
exactly what good it was doing...
Here's my /proc/interrupts:
CPU0 CPU1
0: 104035013 12175 IO-APIC-edge timer
1: 18 0 IO-APIC-edge i8042
8: 1 0 IO-APIC-edge rtc
9: 96344 17 IO-APIC-fasteoi acpi
12: 4280 0 IO-APIC-edge i8042
14: 37 0 IO-APIC-edge ide0
16: 146819 160 IO-APIC-fasteoi ahci, uhci_hcd:usb2, eth0
17: 82562 0 IO-APIC-fasteoi uhci_hcd:usb3, HDA Intel
18: 26 0 IO-APIC-fasteoi uhci_hcd:usb4
19: 81102 265 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb5
NMI: 0 0 Non-maskable interrupts
LOC: 33916179 83674441 Local timer interrupts
RES: 37665467 38976190 Rescheduling interrupts
CAL: 40 35 function call interrupts
TLB: 247574 257703 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
SPU: 0 0 Spurious interrupts
ERR: 0
I've posted the relevant kernel .config here:
<http://www.smiffysplace.com/files/kconfig_rt_20080803>
1) Does anyone have any idea what's going wrong?
2) Does anyone have a .config for a 2.6.24 kernel with the RT patch that
is working well with Jack that they would be willing to share? I guess
that starting from a known-good configuration would be my next logical
step unless anyone can just spot the error.
Cheers
M
--
Matthew Smith
Smiffytech - Technology Consulting & Web Application Development
Business: http://www.smiffytech.com/
Personal: http://www.smiffysplace.com/
LinkedIn: http://www.linkedin.com/in/smiffy
4 Aug
4 Aug
7:08 p.m.
Matthew Smith wrote:
<snip/>
In an attempt to fix any latency issues, I have
used the RT-modified
ketchup to get myself a kernel 2.6.25.8-rt7.
<snip/>
> Whilst going from the 'low-latency desktop' of my standard kernel to the
> RT kernel has made a huge difference in the number of xruns that I am
> seeing on Jack, it hasn't cured them completely. <snip>
1) Does anyone have any idea what's going wrong?
2) Does anyone have a .config for a 2.6.24 kernel with the RT patch that
is working well with Jack that they would be willing to share? I guess
that starting from a known-good configuration would be my next logical
step unless anyone can just spot the error.
Cheers
M
Hi, Matthew.
Looking at your /proc/interrupts it appears that your sound card
( HDA intel ? ) is sharing an interrupt with a usb port.
It really it needs one to itself.
Assuming your system uses grub bootloader, as root-user edit the file
/boot/grub/menu.lst and add the following to the kernel line ( try one
at a time and then both ) :
acpi=off
noapic
so that the boot entry looks something like this ( my system ) :
title Debian GNU/Linux, kernel 2.6.24.3-rt3
root (hd0,4)
kernel /boot/vmlinuz-2.6.24.3-rt3 root=/dev/hda5 ro acpi=off noapic
initrd /boot/initrd.img-2.6.24.3-rt3
be aware that this may effect the power management facilities of your
box. for example my desktop box no longer turns itself off on shutdown,
i have to switch it off.
hope this helps, best wishes G.
8 p.m.
Oh, nearly forgot!
if you try the stuff in my previous post and you succeed in getting your
soundcard set up with an interrupt of its own, then you can assign a
realtime priority to that interrupt:
chrt -f -p 97 `pidof IRQ-4`
assuming IRQ-4 is the interrupt of your soundcard: get this from
cat /proc/interrupts; on my system, ice1712 sound:
CPU0
<snip>
4: 962 XT-PIC-XT ICE1712
<snip>
if you do this on your current setup the usb3 port will also get the
high rt priority which is not good.
you can set the rt priority as high as 99, but i found that this
made my box sluggish and unresponsive ( but not the soundcard!).
again, i hope this helps, G.
8:27 p.m.
On Mon, Aug 04, 2008 at 10:57:28PM +0100, garryo wrote:
you can set the rt priority as high as 99, but i found
that this
made my box sluggish and unresponsive ( but not the soundcard!).
Isn't that kind of strange ? Assuming the soundcard interrupt
takes a tiny fraction of the available CPU time, it shouldn't
slow down your system even at the highest priority.
If this happens, and it does not happen with your current
(lower) setting, wouldn't that mean that
1. it takes a more than trivial time to execute,
2. with the current setting it's still being
pre-empted, and not just occasianally, but
in a systematic way.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
O tu, che porte, correndo si ?
E guerra e morte !
9:23 p.m.
Fons Adriaensen wrote:
On Mon, Aug 04, 2008 at 10:57:28PM +0100, garryo
wrote:
yes, kind of strange, i see your point.
nevertheless this was the observed behaviour with ardour playing back a
project of 16 stereo tracks. the ardour gui was very jerky and slow to
update. reducing the rt priority of soundcard improved UI response,
BUT i must admit that i was not very systematic in my efforts to improve
latency on my box, often twiddling several knobs at once.
regards, G.
you can set the rt priority as high as 99, but i
found that this
made my box sluggish and unresponsive ( but not the soundcard!).
Isn't that kind of strange ? Assuming the soundcard interrupt
takes a tiny fraction of the available CPU time, it shouldn't
slow down your system even at the highest priority.
If this happens, and it does not happen with your current
(lower) setting, wouldn't that mean that
1. it takes a more than trivial time to execute,
2. with the current setting it's still being
pre-empted, and not just occasianally, but
in a systematic way.
Ciao,
8:37 p.m.
Quoth garryo at 2008-08-05 07:27...
if you try the stuff in my previous post and you
succeed in getting your
soundcard set up with an interrupt of its own, then you can assign a
realtime priority to that interrupt:
If turning off ACPI is the only way to be able to change interrupts, I'm
pretty well stuffed there due to my fan control/overheating problem. Is
there any other way to change them? I was told a couple of days ago
that laptop interrupts can't be changed anyway, but this may be incorrect.
I would, however, regard all this as fine-tuning. What's getting me is
that moving to the RT kernel is getting me more - and I mean lots more -
xruns. I *must* have something wrong in my kernel configuration, but
until I can get my hands on a known good .config to compare with I won't
know what.
Once the kernel issue are sorted, I'll start looking at this interrupts
thing - I really don't need that internal sound card, so disabling it
should free up some resources.
Thanks again for your help.
Cheers
M
--
Matthew Smith
Smiffytech - Technology Consulting & Web Application Development
Business: http://www.smiffytech.com/
Personal: http://www.smiffysplace.com/
LinkedIn: http://www.linkedin.com/in/smiffy
8:36 p.m.
Hi
Thanks for your response.
Looking at your /proc/interrupts it appears that your
sound card
( HDA intel ? ) is sharing an interrupt with a usb port.
It really it needs one to itself.
Yep, that's HDA Intel. I only use the internal card as somewhere to
plug in my headphones - think I might take the driver out of the kernel
and just use my external Behringer USB card.
Assuming your system uses grub bootloader, as
root-user edit the file
/boot/grub/menu.lst and add the following to the kernel line ( try one
at a time and then both ) :
acpi=off
This, unfortunately, is not an option for me :( I have to run ACPI in
able to get the system fan to run at full speed - if it doesn't, the
whole machine freezes up after about 20 minutes (or less) run time due
to what I suspect is the GPU overheating. I'm beginning to seriously
regret getting this ThinkPad - Lenovo is ruining them; should have stuck
to Toshiba...
Cheers
M
--
Matthew Smith
Smiffytech - Technology Consulting & Web Application Development
Business: http://www.smiffytech.com/
Personal: http://www.smiffysplace.com/
LinkedIn: http://www.linkedin.com/in/smiffy
5959
days inactive
5964
days old
linux-audio-user@lists.linuxaudio.org
9 comments
5 participants
participants (5)
-
david -
Fons Adriaensen -
garryo -
Mark Knecht -
Matthew Smith