this is what I got when I put sudo apt-get install linux-rt in the terminal and this is what I got,
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following packages were automatically installed and are no longer required:
libsox-fmt-base libsox-fmt-alsa celestia-common libsox0 gnuchess-book
libsdl-image1.2 sox liblua5.1-0 xaw3dg gnuchess
Use ‘apt-get autoremove’ to remove them.
The following extra packages will be installed:
linux-image-2.6.27-3-rt linux-image-rt linux-restricted-modules-2.6.27-3-rt
linux-restricted-modules-rt
Suggested packages:
fdutils linux-doc-2.6.27 linux-source-2.6.27
The following NEW packages will be installed:
linux-image-2.6.27-3-rt linux-image-rt linux-restricted-modules-2.6.27-3-rt
linux-restricted-modules-rt linux-rt
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 23.3MB of archives.
After this operation, 95.0MB of additional disk space will be used.
Do you want to continue [Y/n]? y
Get:1 http://us.archive.ubuntu.com intrepid/universe linux-image-2.6.27-3-rt 2.6.27-3.8 [22.5MB]
Get:2 http://us.archive.ubuntu.com intrepid/multiverse linux-restricted-modules-2.6.27-3-rt 2.6.27-3.7 [754kB]
Get:3 http://us.archive.ubuntu.com intrepid/universe linux-image-rt 2.6.27.3.4 [2078B]
Get:4 http://us.archive.ubuntu.com intrepid/multiverse linux-restricted-modules-rt 2.6.27.3.4 [2108B]
Get:5 http://us.archive.ubuntu.com intrepid/multiverse linux-rt 2.6.27.3.4 [2096B]
Fetched 23.3MB in 1min11s (326kB/s)
Selecting previously deselected package linux-image-2.6.27-3-rt.
(Reading database … 154536 files and directories currently installed.)
Unpacking linux-image-2.6.27-3-rt (from …/linux-image-2.6.27-3-rt_2.6.27-3.8_amd64.deb) …
Done.
Selecting previously deselected package linux-restricted-modules-2.6.27-3-rt.
Unpacking linux-restricted-modules-2.6.27-3-rt (from …/linux-restricted-modules-2.6.27-3-rt_2.6.27-3.7_amd64.deb) …
Selecting previously deselected package linux-image-rt.
Unpacking linux-image-rt (from …/linux-image-rt_2.6.27.3.4_amd64.deb) …
Selecting previously deselected package linux-restricted-modules-rt.
Unpacking linux-restricted-modules-rt (from …/linux-restricted-modules-rt_2.6.27.3.4_amd64.deb) …
Selecting previously deselected package linux-rt.
Unpacking linux-rt (from …/linux-rt_2.6.27.3.4_amd64.deb) …
Setting up linux-image-2.6.27-3-rt (2.6.27-3.8) …
Running depmod.
update-initramfs: Generating /boot/initrd.img-2.6.27-3-rt
Running postinst hook script /sbin/update-grub.
Searching for GRUB installation directory … found: /boot/grub
Searching for default file … found: /boot/grub/default
Testing for an existing GRUB menu.lst file … found: /boot/grub/menu.lst
Searching for splash image … none found, skipping …
Found kernel: /boot/vmlinuz-2.6.27-11-generic
Found kernel: /boot/vmlinuz-2.6.27-9-generic
Found kernel: /boot/vmlinuz-2.6.27-7-generic
Found kernel: /boot/vmlinuz-2.6.27-3-rt
Found kernel: /boot/memtest86+.bin
Replacing config file /var/run/grub/menu.lst with new version
Updating /boot/grub/menu.lst … done
can spambot talk to a single forum member ? spamming algorithms are improving
Anyway, on the xrun front, I got the best setup ever achieved on my PC:
vanilla kernel 2.6.31 (no RT patch)
installed nvidia graphics card GeForce 9500 GT (PCI express) and compiled the latest official binary driver
enabled all the compositing stuff (useless but I wanted to try this out)
updated jack2 svn, xorg, KDE 4.3
I stress-tested the machine:
rosegarden, 2 VSTis, ardour, jamin + mplayer playing a movie streamed over my LAN from a samba server, using the nvidia vdpau output (PureVideo API for unix). I was playing with the 3D cube thing, Alt+TAB window switching in slide mode, wobbling windows for fun. All this in twinview mode (dual monitor). It’s real fun to see ardour’s track level display and transport shuttle still working while moving the cube
The whole thing was at < 1ms latency, I have not seen a single xrun in 3 days. And my system uses a Core 2Duo 2x2.4 GHz, 4GB RAM and debian sid (32bit).
I repeat: no RT patch at all. Plain vanilla. Giving up on the intel graphics IGP was a very good move indeed. And the desktop feels a lot snappier, and it is a real pleasure to focus again on the music rather than system crap.
Sounds like a great setup you’ve got running there… as usual you’ve done your homework, to deviate a little from the original topic, how did you get along with Xorg 7.4? On several Virtualbox tests and my laptop I can’t boot into a working system without modifying the xorg.conf outside of X with nano. A little reading told me that hal is handling input devices (mice touchpads etc.) and that if your input device doesn’t work you will need to manually write the new hal config file? Conversely you have to add some lines to xorg.conf to tell it not to let hal manage input devices, - WTF!?? How is the end-user supposed to figure that one out?
My laptop is a DELL with a synaptics touchpad - common as dirt. If the new Xorg couldn’t even figure that one out on reboot than I pity people with less common input hardware. I realize 7.4 is a development version of Xorg but it is a tall order to expect that to be a smooth transition!
From a distribution standpoint this is a real showstopper : (
@linuxdsp - I found that disabling Ubuntu’s Network Manager helped eliminate various system errors, e.g. hung-up shutdowns. I wrote a little overview of my experience with Ubuntu, it details what I did to tame that system:
It’s not a pretty story, but it all worked out. I’m now using Jaunty on my 2nd production box, I’m liking it a lot. However, unless UStudio has ironed out its rt problems I can’t recommend it to a novice.
Btw, the un-fixed system produced xruns from HAL polling. And Ubuntu has the nasty habit of re-writing limits.conf after system updates. Grrr…
there are many things that can cause xruns but what Dave is saying reminds me of these particular problems:
between 2.6.26 and 2.6.29, RT kernels are not to be trusted
the HAL polling means you have the hald daemon running. Xorg 7.4+ relies on hald running at X startup for keyboard and mouse detection. While this may be an interesting development for normal desktop usage, hald has often been a PITA for us RT kernel users.
Since I use KDE (4.3), I added a ‘/etc/init.d/hal stop’ in $HOME/.kde/Autostart/some-startup-script.sh. Do not remove it from the boot services (with e.g. sysv-rc-conf) because gdm (or X in fact) would screw up if hal is not running at login time …
the rtirq script needs some update (I think it is already updated by its author but it might not have made it into official package repos). I find rtirq to be quite important on my system. If all IRQ threads that the RT kernel creates run at the same priority, there can be some issues. rtirq aims at prioritizing some threads rather than other. Remember what the RT kernel does: it creates a process thread for every IRQ, and you can them check with
ps -Leo comm,class,rtprio | grep -i irq
and tune them with the ‘chrt’ command line utility (that the rtirq script is using internally).
These are issue candidates when I update the software side of my system:
startup daemons
X and WMs
IRQ threads
From RT patch to RT patch, some changes may break a previously valid config. For example, the process threads related to timers are now called sirq-xxxx. They were called softirq-xxxx. The new 2.6.31-rt kernel names them even more slightly differently: what used to be called ‘IRQ-xx’ (for example, the process thread of my soundcard at IRQ 22 was called IRQ-22) is now called ‘irq/xx’ (irq/22 for my soundcard).
The linux distros have to do with these differences and this will continue like this until the whole RT “hack” makes it into the mainline kernel. It is getting there but who knows when the whole patch is integrated …
Further to what linuxDSP said above regarding M-Audio 1010LT there is real performance variability in Kernels. I have built several -rt Kernels from 2.6.28 to 2.6.29.4 and only 2.6.29-rt1 will run my M-Audio 1010LT at less than 256 fpp reliably with no xruns and without further system tweaks, in fact my current low-latency Kernel will run my 1010LT as quickly as any other -rt Kernel other than 2.6.29-rt1. If I hadn’t built several Kernels and tested them I wouldn’t have even noticed there was a difference so how is the end user supposed to have a chance.
I’m starting to think that Linux having the Kernel core itself as the main source of hardware support is not a good thing at all, Kernel versions blip by so fast that specialized hardware support for tasks like -rt Audio are routinely broken or degraded without anyone even knowing, I’ve certainly learned that all -rt Kernels aren’t created equal just because they have the -rt patch, certainly newer is not always better!
I think there are some hardware manufacturers that don’t quite ‘get’ what full duplex is in the context of pro-audio, speaking from experience (when I’m not writing plugins I design various bits of audio hardware…) There are some audio codec chips that can ‘technically’ do full duplex in that they can play and capture audio streams at the same time - but they don’t always do it in perfect sync. Typically the worst offenders are devices that need a seperate IRQ for capture and playback or which share an IRQ between playback and capture e.g the IRQ handler has to go and read a register in the chip to find out which half of the chip caused the interrupt (ICE1712 IIRC) - This can cause problems in a synchronous system such as JACK if the two channels are running at slightly different rates. What I saw happening was the interrupts for play back and capture moving relative to each other with the result that the input and output buffer pointers drift and the end result is an x-run when one under or overruns. If there is a single IRQ that indicates that the hardware has some data that has been captured and requires a similar amount of data for output then the I/O channels cannot drift and you normally get rock solid performance irrespective of subtle kernel variations. The critical thing seems to be that the kernel IRQ latency can affect whether the two halves of the card are able to stay in sync or not - the reasons for this can be complex and I won’t expand on it here (probably a discussion for the JACK devs) but I just thought I’d share a bit of knowledge in case its useful to anyone.
Did the issues you saw using duplex mode cause audible glitches and/or ALSA (as opposed to JACK) xruns?
Given that my troubleshooting post didn’t generate any discussion on how to separate JACK issues from Ardour issues, I think it might just be appropriate to discuss this a little more in depth here.
Is there a JACK forum, or is all the JACK stuff on mailing lists?
@lowen: The issues I saw only caused problems with JACK. This is not because JACK was at fault, but because if I played back and recorded simultaneously using just ALSA it wasn’t really full duplex in the proper synchronous sense. e.g. I had two processes running, one taking audio in from ALSA and putting it on disk and one playing back another file to ALSA. This meant the processes were completely independent and therefore free to run at their own rates - However (and this is important) that would have been no good for duplex recording e.g. overdubs etc since the recorded / playback tracks would be drifting relative to each other. This is why JACK needs to be able to record a buffer full of samples (optionally pass it round any other applications) and then output a buffer synchronously. If the two halves of the sound card are running at different rates then eventually one or the other buffer (input or output) will over / under run and you will get an x-run. My experience so far has been that Ardour on modern PC hardware seldom generates xruns, the CPU load is normally low enough and disk access quick enough for this not to be a problem, jack is very solid if you have good hardware and apply the realtime (permissions) tweaks. The only problems I have had with xruns have come from using jack with badly designed hardware (in my opinion) and without the realtime (e.g. permissions) tweaks. I have seldom found the need for a real-time kernel (in some cases the rt kernel has caused problems with bad hardware that the normal kernel did not. I think the key thing about the real time kernel is that it tries to make various realtime issues more deterministic e.g. more likely to be constant rather than specifically faster (correct me if I’m wrong…) but the problems I had with the x-runs seemed to be related to the IRQ latency being too long which may still have happened with a realtime kernel. Unfortunately when audio misbehaves on PCs (windows or linux) it is seldom one thing that is ‘wrong’ or at fault but a combination of soundcard chipset, motherboard, kernel (windows or linux) etc etc. Sorry I can’t be more specific. In the end I got rid of my EWS88 and put in an EMU0404 card (the EWS88 is working fine in another PC using ubuntu now so I’m told…) I will say I’ve had far fewer problems with linux / JACK etc than I did with windows (many years ago) though.
The number of xruns seems to vary. Sometimes I won’t get any for a while and then 1 or 2 will pop up. Sometimes they just keep coming one after another. It seems very random, although we know it really can’t be.
Setting the mode to capture or playback only seems to eliminate xruns, but it would be a very tedious process to set it to capture, record (without the benefit of hearing existing tracks!), then switch to playback.
Changing anything doesn’t seem to affect the frequency of xruns. Literally, anything. As far as sampling rate goes, my only options are 41khz and 48khz. Above that and the qjackctl message window goes nuts and I have to kill jack and switch it back to 41 or 48.
And like I’ve said, changing the buffer size does nothing either.
I am truly stumped and confused. Is is possible to have hardware that can handle audio just fine under one OS (Windows) and not under another? That doesn’t make sense to me, given that I see that many other folks here have Linux systems where they never get xruns - some of whom have processors a step or two under the one I have.
Interesting… I’ve heard of problems with sound / network interface ‘conflicts’ on other systems (with a variety of different hardware) but it is rare - the possible reasons are many and varied. There are differences between operating systems and their drivers obviously so that may explain why windows works and linux is more troublesome. I’ve had problems with duplex mode in the past, with a PCI card (ICE1712 chipset) - with my motherboard / kernel / driver combination it would only work in half duplex mode else I got xruns after a while depending upon buffer sizes, but on a different PC it worked fine. In my case the problem could be traced to the playback and capture halves of the card running at slightly different sample rates (I did lengthy investigations into the cause and it wasn’t a simple config issue… Seemed to be related to interrupt latency in the kernel e.g. the time taken between the hardware saying it had data and the kernel processing it) It wasn’t a fault with JACK either - jack needs to get / send buffers of samples synchronously for full duplex mode to work or you eventually get x-runs but I could clearly see the IRQs from the two parts of the sound card (via ALSA) happening at varying times relative to each other as the timing slipped. Performance under windows was varied too.
If you have realtime permissions set up, then it sounds like you likely have a much deeper problem, either a faulty driver for your NIC, not unheard of, or possibly a hardware problem. Is your NIC and Audio Card by chance sharing IRQs?
I seem to have stumbled on a possible solution, but only time and testing will tell.
Disabling my NIC seems to have completely eliminated xruns while running Ardour. Not in the 20 minutes I was running it just now did I get nary an xrun. Invariably, in this amount of time in the past, at least a few would pop up. And this is with duplex.
I’ll keep playing with it and see if I’ve indeed nabbed it this way.
How many xruns do you get? Is it a lot or just one or two after running for a long time? Does changing the buffer sizes (or sample rate) affect the frequency of the xruns? Also, I’ve had some problems with other types of interface that were related to running in duplex mode. Is it possible to run your interface in playback or capture only and does this affect the number of xruns?
I’m having a REAL hard time getting rid of xruns. The maddening part of this is that this same computer running Windows and Sonar has no trouble with latency at all.
Here’s my specs:
HW:
2 Mackie Onyx firewire mixers (1640 and 1620)
Pentium D (dual core) in a Dell Dimension 5510
4 GB ram
Jack:
jackd, realtime
priority: 70
f/p: 1024
rate: 48000
p/b: 3
port max: 512
timeout: 500
interace: hw:0
audio: duplex
Desktop: Fluxbox. Kernel: rt-sources.
I have been tweaking settings for a few weeks now with no luck whatsoever. It seems like no matter what I do I eventually get xruns while playing back or recording. I don’t run anything else while running Ardour. I’ve moved the f/p all the way up and back to no avail. Incidentally, a p/b of 4 turns my audio into garbage. So it’s either 2 or 3, neither of which changes the fact that I still get xruns.
/etc/security/limits.conf is set according to advice given in these forums.
I’ve apparently done all the right things, but still no cigar. I will shine your boots if you say something that fixes it.
Hi, this topic is old, but very interesting to me : )
I was searching about xruns before start a new thread.
I have a system similar to your´s, but I get a lot of XRUNS. I´m running pulseaudio trough Jack.
How do you manage to get Jack aplications (Ardour,jamin, etc) and other audio aplications running at the same time?
