Card: M-Audio Fast Track Ultra 8R (USB 2.0)
Ubuntu 11.04
Linux Kernel: 2.6.38-8-lowlatency
Problem:
All the audio works perfectly, except for a very predictable periodic xrun when running in duplex mode. Changing the sample rate/buffers/frames/periods only delays the inevitable.
Basically when rate is 44100k, an xrun occurs every 126 seconds. When I increase the sample rate, the time between goes up proportionately. When increasing the buffers/frames/periods, that just delays it a bit, but a xrun will happen eventually and then have a consistent interval.
Because I’m using USB audio, the periods/buffer are usually set at 3. The xruns occur with just jackd2 running, don’t need any audio patched or Ardour running. When in soft mode, the xruns pile up real fast after the first one occurs (driver not resetting?). I’ve tried turning off all scheduled system tasks and also tried disabling pulse audio.
This hardware works without a hitch in Windows 7 on the same machine, so I suspect it not a faulty timer, but I’m not too wise on this subject.
I can’t give you a definitive answer, however have you tried this device using a different -rt Kernel with and rtirq script to prioritize the IRQ your audio device uses at boot time? I find although recent desktop and lowlatency Kernels generally give very good performance with most hardware, many FireWire and USB devices still really need to be used with rtirq script.
I’m not well versed on Ubuntu to advise you where to get any of this for 11.04, it is my guess the Dream Studio or KX Studio repositories will have something available if not now then very soon. I see you are using Kernel 2.6.38, the next Linux Kernel 2.6.39 will actually have IRQ threading available (rtirq capable) without an -rt patch so that may be an option as well once it is released (It is in the Release Candidate stage right now but already works very well). I’m sure once it is out Ubuntu will have a PPA somewhere with it.
Because your issue is so predictably periodic it may well be IRQ related.
Thanks for responding GMaq!
I have tried this with 10.04 + RT and 10.10 Generic (2.6.28, 2.6.35) , however there were other issues with Alsa and the 8R then, which are now solved in 11.04.
I will wait a few days and keep an eye on 2.6.39. In the meantime, I have plenty of pre-production work I can keep myself busy with using other hardware.
I’ll keep you posted,
To clarify I think my answer was a bit vague, The -rt Kernel has the IRQ threading/prioritizing capabilities in the -rt patching however a separate ‘rtirq’ script package is necessary to actually use those capabilities and call them at boot. For anyone else reading it is important to note that the IRQ threading in Kernel 2.6.39 has to be ‘switched on’ by using a GRUB boot parameter of ‘threadirqs’ otherwise it will just behave as a regular Kernel does.
Forgive me if this thread has been put to rest. I too have been plagued with xruns on 2.6.38Generic , 2.6.38-8 #42 lowlatency and 2.6.39 generic. I haven’t rolled my own kernel in awhile since I have more machines with special needs than I have time to commit. But GMaq’s recommendation to look at KXStudio’s lowlatency kernel is on point.
I haven’t had a chance to do a complete acid test but I can attest that the kernel works 2.9 milliseconds no xruns so I am quite happy. By the by… this issue with the xruns was not just limited to my single core systems . My test system is a Dual Core AMD 5000+ my production systems are dual quad core AMD opterons with 8 and 16 gigs of ram respectively. and I was able to predict, down to the second when the xrun would happen. 2.6.39 was completely unusable lspci -v showed no conflicts and no apparent issues in my BOIS settings. I have not tried to edit grub when loading 2.6.39 so it is a good chance that the issue could have been resolved on all fronts. But if you are in dire need to get things running with little to no pain until you have time to poke around the inner workings of grub … go for the ppa if you are running ubuntu studio 11.04 … and yes the proprietary nVida drivers worked for me with no issues.
I vaguely recall I read about a similar issue due to a wireless mouse. It had something to do with measuring the power level of the battery in the wire less mouse at regular points in time… Can’t say more than that …
Update:
I’m still having the problem in the 2.6.39 kernel. Everything is set optimally for realtime audio.
Because of the insane predictability of the XRUNS and the reliance on the sample rate for their frequency, this maybe an issue with the ALSA driver dropping frames for the Fast Track Ultra 8R in full duplex mode. Discussed in some detail deep within this thread: http://forums.m-audio.com/showthread.php?714-Not-a-problem.-FastTrack-on-linux
I had xruns in duplex, capture and playback modes. I solved part of the problem by installing kernel 2.6.31-12 realtime from kxstudio. It was the only rt kernel I found that let me install nvidia drivers and alsa git without a problem.
Now I get no xruns in capture and playback mode. In duplex mode it just goes crazy with xruns after a while, but well, that may also be because of the card not being fully supported by alsa drivers I guess.
Sorry for “upping” this quite old topic, but I have same behaviour here. No xrun in playout mode only, but in duplex mode, I get one every 225 secs, no matter something is actually playing or not, no matter if I do something else at that time with the machine.
My config :
OpenSuse 11.4
Yast tells alsa is at 1.0.24, but a cat /proc/asound/version reports 1.0.23… which one should I believe ?
jackd --version tells jackdmp 1.9.6
Is there something new since may 2010 ? Where should I have a look ?
Tks for your help.
P.S. : to be fully functionning, I would also need to be able to manage the internal routing of the FTU8R since at power up, input 1 is routed to output 1, in2 on out2, etc, and that software return for output 4 is curiouly off. Workaround for the moment is to plug it to a Windows a few secs and then plug it back to the linux box… But that is something else, “non blocking”.
But everything runs perfectly smooth and with very low latency setings if I use only analog INS in full duplex mode, so I gave up with the digital INS. But the predictabilty (or banality if better) of that xrun is just insane, I have timed it and it is so precise I could run another nuclear world clock. Yes changing latency settings in qjackctl will just make it more or less continuous but with same precission.
I believe it must be something with the internal chipset of this devices, I believe it’s even the same one on both models.
I have tried so many things with no avail. If I ever find something out I’ll let you know. Maybe I should try NVIDIA drivers thing is that they are not well supported with RT kernels. The other thing is that I really don’t care anymore since I am totally independent and 2 analog inputs are more than enough for me at the moment, I just wanted to plug my BOSS GT-8 Guitar FX board through the digital so I had both frontal analogs free.
Hi,
I have the same matter with an M-Audio Fast Track Ultra 8R, on AVLinux6.0 and KXStudio, pluggin’ in a Desktop, or a Netbook pc.
Have you found any solution?
What is the difference between an RT kernel, a realtime kernel and a lowlatency kernel ?
I read from some of Paul Davis’s lecture slides that for an RT kernel, bottom half interrupt > RT threads > top half interrupt > other kernel thread > non-RT threads. Is similar scheduling used in the other kernels?
kubuntu 10.04, kernel 2.6.32.32,generic, preempt, rt…
But that is something else, “non blocking”.