I will start with the reasons Ubuntu Studio desires a different kernel and the paths that lead to the current state.
Into My Own Thing
I would posit that most Ubuntu Studio users are mostly concerned with audio recording and as such they desire a stable, low latency. Let's break "stable, low latency" down for easy consumption.
- Latency can be simply defined as the time between when a sound is generated and it is heard
- Low latency is desired because higher latencies (i.e. delay) can be confusing and throw off any sense of rhythm if the sound is heard later than you expect it
- Lastly, we want a stable latency because we want to avoid xruns (underruns or overruns in the buffer) which can introduce pops, clicks, digital distortion, and other unwanted noise into your music
Additionally, numerous laptop users using Firewire audio interfaces have suffered from irq conflicts.
Explained more accessibly, the Firewire interfaces might share a bus with and compete against other devices for attention from the motherboard. These Interrupt Requests (irq's) are prioritized and sometimes other items are more highly prioritized than the audio interface. Not a completely correct analogy, but musicians would prefer that the audio was properly recorded over the mouse updating its position on the monitor.
Historically only the -rt (or -realtime) kernel would provide this functionality via Ingo's patch. However, code from the -rt patch has been integrated into the main kernel tree and this particular functionality is now available in the => 2.6.39 -generic kernel.
You Can Make It If You Try
Sometimes you can define your path by defining where you can't go, so let's explore our constraints to see where our true direction lies.
The largest constraint is that the process for building the Ubuntu Studio image is an automated process (or daemon called buildd, I believe) which can only use packages that are inside the official Ubuntu repository (also called archive). Again, using exclusion; we cannot use packages from PPA's (Personal Package Archives), or the kernel that guy made over there at another multimedia distro, or even a kernel from Debian. And even if Debian has a -rt kernel, Ubuntu will NOT sync that kernel into the repositories as Ubuntu rolls their own.
Therefore, our options are to use a kernel package from either the Main or Universe repository to build our image.
Next, the Ubuntu Kernel Team is NOT going to build and maintain an additional kernel. I don't blame them, this is a lot of additional work and responsibility, especially for a rather small niche of highly expectant users, and the kernel team does enough already. And since this kernel will be maintained by non-core-dev individuals, this package falls under the purview of MOTU and will reside in the Universe repository.
Therefore, this new kernel will be a community (i.e. Ubuntu Studio developers) supported kernel... in an Inception-like abstract, a community within a community.
Our path, in this context, is that the Ubuntu Studio developers are to build a kernel that will be archived in the Universe repository.
Dance to the Music
So the last movement of this piece is defining which kernel to built.
The -rt time kernel has some significant aspects, both good and bad.
GOOD - it can provide exceedingly good low latencies
BAD - it requires an invasive patch that isn't always available to align with Ubuntu's chosen kernel version, requires compiling some video drivers again
NEITHER - irq threading to prevent irq conflicts isn't an issue anymore as the -generic kernel now provides this functionality.
In my opinion, the -lowlatency kernel has exceedingly more positives than negatives.
GOOD - can be based on the Ubuntu kernel which keeps versions aligned, only requires compile time flag changes to build, doesn't require additional video driver building, provides good latencies
BAD - doesn't provide as good latencies as -rt
While we found that the -lowlatency kernel generally didn't perform quite as well as the -rt kernel we did establish that most testers found that latencies were more than acceptable. Some hardware sets will be the exception, but we believe we will be able to adequately support the majority of users with this kernel.
Therefore, it seems the most practical decision is to move towards the -lowlatency for its performance, availability, and longevity
And this leaves us with Professor Plum with the candlestick in the library. Kidding.
Hopefully, this post explains Ubuntu Studio's kernel considerations, the possible and tenable vectors for acquiring a kernel, and the decisions for choosing the -lowlatency kernel.