KLANG - 1 more Linux audio disaster waiting for slashdot/reddit
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.
- 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
- The unix calls (they are not "OSS calls")
open/read/write/ioctlare 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/ioctlare 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.