2.6.26 and 2.6.29 are known good versions for -rt last I checked. I believe 2.6.31 is also one to look at but am not so sure.
The other versions you will get varying results with, if you are using an -rt kernel, you should probably try to use one of the above versions.
Thanks, everyone, for these super responses. I'm going to spend the day digesting this info and checking things out and will post back what works.
This is a great board for a great DAW. Glad I found all this. :-)
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.
We were on the same problem lotone. I was on my way solving this problem that I experience now.Anyone could help?It is much appreciated.
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 :D
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.
I will stick to this config for a while :)
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 : (
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?
what's your h/w and s/w setup ?
PS: @GMaq, I never saw your question from last year! But to reply quickly: the HAL takeover of input device detection was a real pain and simply broken on debian for a while ... I had to disable that in xorg.conf for a while. Then things got sorted out with xorg 7.5 and better HAL integration. I had to create a file for my keyboard "/etc/default/keyboard" (I believe it's in this dir) with the xorg options. They are the same I used to have in xorg.conf but now put into what looks like env variables for HAL. Without this file, I had my kbd default set to some unexpected layout, etc. In the end,I removed ALL input device entries from my xorg.conf.
Don't know how distros are shipping these things nowadays, since I keep maintaining and updating my debian sid install from 2007 :)
My system: Intel core 2 duo 2700. 2gb ram, gforce 8600 gt
Ubuntu 10.04 32 bits, a couple of kernels (vanilla, RT), Gnome. Jack control with a script to run pulse audio trough Jack.
My actual Jack configuration:
46.4 mseg latency
How you get 0 xruns with a vanilla kernel???
you did not mention what your audio device is.
Well, no xrun at all has a lot to do with your h/w and s/w configuration, not so much CPU and RAM (unless you are doing a lot of s/w effect processing, loads tons of audio samples to RAM, etc). Anyways, things to be looked into are :
- use preferably a PCI, PCIe or firewire audio card which can cope with the load (onboard chips are usually crappy, both for the sound quality and their meager capabilities)
- IRQ assignment (isolate your audio card on a single IRQ line)
- IRQ process priority level (SCHED_FIFO prio) if running the RT-patched kernel (I do not so I do not care too much here, and the recent vanilla is good enough if preemption is enabled)
- maybe of relevance in some systems: PCI latency timer of some devices (see setpci command, and google around the PCI latency timer concept - usually you'll want to decrease the VGA latency_timer often set to the max, and increase a bit the more relevant ones, i.e. audio and hard disk controller most likely)
- power management: forget about it on a DAW PC
- no network interference if possible (WIFI in particular)
- good hard disk throughput and fast seek time preferably (mounting with the 'noatime' option is also helping or use a RAID setup)
- filesystem that can keep up (ext3 should be OK, alternatively XFS, which I use and did not crap a single time in ~ 3 years of operation)
- remove all background services (aka daemons) that you do not need
- dedicate your PC to audio only, meaning that fancy desktop effects, 3D or composite graphical performance, etc are not exactly important
- use a lightweight windows manager (I use KDE4, not lightweight but no problem either)
- compile some of the apps yourself. The prepackaged ones may not be compiled as you would like them to be.
- ... and other things I might have forgotten
My soundcard is onboard : (
But I want to achieve the same performance that I have in Windows or OS X with the same hardware. Indeed, the latency is ok (I think better than in the other OS!) But sometimes I hear a noise XRUN. I´m trying another kernel now and the xruns are fewer (1-3 in a session)
I use Gnome, ext4 filesystem, no fancy desktop
so what's the chip model ?
and what jack setting do you apply ?
HDA-Intel - HDA Intel
HDA Intel at 0xfb000000 irq 22
/usr/bin/jackd -R -t1000 -dalsa -dhw:0 -r44100 -p1024 -n2
@capitanmission: Have you tried starting jack in playback only? I have an Intel HDA chipset on one of my machines that jack won't work with unless I use playback only ( I get Xruns and eventually JACK bombs with some timeout message - maybe one day I'll have time to look at the problem properly and see why that happens but for the moment I just use playback only).
@linuxdsp: you probably don't have the capture source set "correctly". this causes the precise behaviour you describe with quite a few HDA chipsets".
@Paul: Thanks, I think I have that set right, but I'll check again. It could be I've overlooked something in the setup. It's on a machine I was just using for testing so I wasn't too worried that I couldn't record - I just needed to hear audio. I just assumed it was something less than ideal about the HDA chipset / ALSA driver combination..
I don't know if this is still relevant for the HDA, but it used to work much better with n=3 for the number of periods per buffer.
@thorgal: I used to have to set n=3 on the machine I was having HDA related problems on (cheap Dell notebook...) but subsequent revisions of ALSA drivers seem to have made it work (in playback only) without xruns using more normal settings. As Paul mentioned, I may have misconfigured something that is causing it to only work for me in playback-only - I'm going to check that again...
...I had indeed managed to accidentally disable the mic input, which seems to be the cause of the playback-only problem I was having... :)
Thanks to Paul for pointing out the likely cause of that problem, however, starting jack in playback only is still quite a useful way to track down some x-run problems..
I can record my guitar, I have good latency, I work with soft synts, a lot of samples, etc, no problems. But the xruns are there (in one session, a lot with vanilla kernel, 3 or 7 in the rt kernel).
@capitanmission: Are you saying that normally you don't get x-run problems, but its just one session that is much worse?
Hi i noticed something intersesting.
When i'm recording i get xruns only when the cursor arrive near the end marker and then no xrun . apparently the xrun "for me" only appears just before or just after the END marker.
Your subscriptions & donations are critical help that make it possible for full-time development of Ardour to continue. Your support is critical and much appreciated.
August goal US$6200 (US$74.4k/yr)
Subscribers 1690 US$4876.00/month
Support Ardour, get free upgrades: pay $1, $4, $10 or $50/month: