As an opening note, I find it a bit odd that this announcement of KLANG is so anonymous. No name, no email addresses. Of course, we do know who the author is, its just strange that this page has no contact information, no links, nothing.

Just in case nobody realized audio is in already done in the kernel. That's where device drivers live, and device drivers are how all I/O with audio interfaces takes place (theoretically, it might be possible to do user-space I/O with USB, but in practice, it doesn't work well).

Dropouts ("xruns") are not really caused by being in user space. They arise from two different types of events: poor kernel scheduling incorrect application implementation You can't solve the first without just doing everything in an interrupt handler. This is 2012, and this is not how you write general purpose operating systems anymore. You can't solve the second with a kernel framework, and incorrect application implementation will remain an issue with any audio API. Remember: most of what an audio app does happens in user space regardless of how the kernel side of things operates.

You can't solve the first without just doing in an interrupt handler. This is 2012, and this is not how you write general purpose operating systems anymore. You can't solve the second with a kernel framework, and incorrect application implementation will remain an issue with any audio API. Remember: most of what an audio app does happens in user space regardless of how the kernel side of things operates. The unix calls (they are not "OSS calls") open/read/write/ioctl are NOT the right API for streaming media, not because they don't work but because they allow sloppy developers to write code with the wrong design. Every piece of software on Linux that does audio i/o ultimately calls these functions, but they are wrapped in ways that (gently) encourage developers to structure their software in the right way(s) to avoid dropouts and other issues.

are NOT the right API for streaming media, not because they don't work but because they allow sloppy developers to write code with the wrong design. Every piece of software on Linux that does audio i/o ultimately calls these functions, but they are wrapped in ways that (gently) encourage developers to structure their software in the right way(s) to avoid dropouts and other issues. KLANG as documented does not appear to offer any approach to inter-application audio, which JACK does in a way that is completely seamless with actual device audio i/o. This is not a small thing.

open/read/write/ioctl are also the wrong API because no interposition is possible without using grotesque hacks like LD_PREOPEN. By using system calls, you basically mandate that everything on the other side of them is done in the kernel. This makes it very inefficient to implement inter-application audio, since everything has to make extra transfers across the kernel/user space boundary.

are also the wrong API because no interposition is possible without using grotesque hacks like LD_PREOPEN. By using system calls, you basically mandate that everything on the other side of them is done in the kernel. This makes it very inefficient to implement inter-application audio, since everything has to make extra transfers across the kernel/user space boundary. KLANG is talking about putting mixing (and possibly some other kinds of processing) into the kernel. Since such processing is almost always done in floating point format by almost every piece of software on the planet, this is problematic, since there is no floating point allowed in the kernel.

JACK consumes barely any more CPU than an in-kernel design would. If you don't understand why this is true, then you don't understand enough to be crafting a replacement.

JACK's impact on power consumption is a function of low latency realtime audio, not JACK (i.e. there is no way to do low latency realtime without affecting pwoer consumption). If a user or an application wants to handle audio data with 1msec of latency, you cannot avoid the CPU staying active. You cannot buffer you way out of the requirement to handle very frequent interrupts from the audio interface.

The KLANG "documentation" suggests the need to reimplement kernel side drivers for every audio interface, which is just an absurd effort.

Finally, I would note that ESD is irrelevant and has been for nearly a decade - I don't know why anyone would even mention it.

Recently this page surfaced with a description of KLANG which aims/claims to be a new framework for audio on Linux. It contains a number of troubling errors, mistakes and wrong-headed thinking.