how to use jackd without x-runs while using unity?

There is an on-going discussion about an issue very similar to this one on the ffado-user mailing list (the poster there pointed me to this report). It's early days so we don't currently have a solution. However, given the information reported I can make the following observations.

1) I understand that you don't see the xruns when running xfce. This suggests that the problem may be caused by the video subsystem which is worked a lot harder by Unity and gnome3. This may in turn be caused by the proprietory Nvidia drivers; we've seen them create problems in the past.

2) I have no idea what kernel is in use in Ubuntu 12.04. To run ffado successfully without xruns, a kernel configured for preemption (aka low latency desktop) is usually required.

3) Perhaps there's some configuration being done by Ubuntu that for some reason is affecting jack and/or ffado's ability to run reliably. For example, when control groups first appeared their use was sufficient to cause problems (see http://trac.jackaudio.org/wiki/Cgroups). Not being familiar with Ubuntu at all myself I have no idea whether something list this is likely to be an issue with Unbuntu 12.04.

It would be interesting to see the output of the ffado-diag command as run on your system.

It is possibly going to be most efficient if you join the discussion of this on ffado-user (see the "contact" page on www.ffado.org). While all the ffado developers (and many users) read that list, very few actively monitor distribution-specific forums like launchpad due to time constraints. The relevant thread is "My MOTU Ultralite only works after rebooting" which was recently renamed to "MOTU Ultralite xruns in Ubuntu 12.04 / Unity" when the connection with Unity was noticed.

Thanks jwoithe, that solved my question.

It may be solving my problem, it is still sad. The non open source operating systems (Windows, Mac) are handling rt-audio perfectly well. Linux still needs a customized kernel. This should have been fixed years ago. I'm also sad that I cannot help in that department, because I'm not a kernel developer, I only know php, and understand python a little bit. If there's another way, I will help of course.

I'm happy to hear that the Ubuntu low latency kernel resolved your issue.

> The non open source operating systems ... are handling rt-audio perfectly well.

This is not necessarily true. Certainly the popular perception is that this is the case, and for some people it may appear that way. However, the reality is that I know of many people who have to hand-tune their systems to get click-free performance. Having said that, MacOSX seems to have the edge in the closed-source market at the moment.

> Linux still needs a customized kernel.

This is not true and I apologise if my statements lead to this conclusion. The low latency kernel is not a customised kernel; it is exactly the same kernel as the generic kernel at the source code level. It is simply a kernel that's been compiled with different options turned on. The "generic" kernel happens to work for most people and is optimised to give most people a near-optimal performance, but the needs of low-latency audio are quite different to those of the general user (as many users of closed-source systems have discovered over the years). Linux gives the option to have the kernel compiled with optimisations directed at users who require low latency performance; the low latency kernel is the result of one of these options.

> This should have been fixed years ago.

I guess it's a question of perception. To many people the problem *was* fixed years ago. For instance, four or so years ago it was necessary to run a patched kernel (using the so-called realtime patches) to get sufficient reliability for low latency tasks like audio work. This truly was a "customised kernel" - it was quite different at the source level to the stock mainline kernels released by Linus. However, about 2 years ago things changed as more and more of the realtime patch set was merged into the mainline kernel. At that point we had the situation where a mainline kernel was fine for almost all audio workflows, so long as was been compiled with the "low latency" configuration option turned on.

The "low latency" configuration option is just one of many hundreds of options provided in the kernel. The decision as to which ones to turn on comes down to the people making the distributions. They will tend to choose an option set which results in a kernel optimised for their target users. A distribution targetting servers will have quite different options activated than one directed towards desktop users. The strength of Linux is that this is possible: people can have a kernel optimised for their purposes, rather than having to put up with an approximate "one size fits all" kernel. As a result, distributions like Fedora - targetting the desktop - will not usually have the low latency option activated. However, 64studio - a distribution targetting multimedia authoring - does have it turned on in their default kernels (so for their users it's certainly not a "custom kernel"). Ubuntu ships a generic kernel by default, but they make a low latency kernel available for those users who need it.

I can understand why some people may view this as needing "custom kernels". I certainly don't view it that way (to me a custom kernel is one that's been changed at the source level), but everyone's entitled to their own opinions. In any case, I hope the above goes some way to explaining the background and the situation.