KLANG is a new open source audio system in development. Its target platforms are the Linux and the FreeBSD kernel. KLANG offers professional grade audio, that means lowest possible latency, latency compensation and bit exact precision at a very low CPU load.
KLANG has been designed as a signal routing system, supporting seamless and transparent signal transport between all endpoints. In practice this means that there's no distinction between hardware and process endpoints. Each endpoint is either a signal source or a sink, allowing for versatile signal routing topoligies.
All connections are fully latency compensated. A metronome system synchronizes the signal processing to a configurable set of system internal and external clock sources. This greatly simplifies tasks like audio/video synchronization.
Because it's the only reasonable thing to do. Audio is one of the few applications, where time is of the essence and things can not wait. Audio samples may not glitch. If they do, this results in a very noticeable "pop". Latency is of the essence. Our visual system permits latencies up to 20ms without noticing. In contrast to this latencies as low as 4ms are very noticeable.
Low latencies mean short buffer length. But the shorter a buffer, the more critical the scheduling of a process gets. Current userspace based audio systems put audio processes into realtime or near realtime priority. This works fine, as long there are only a few audio processes involved and the system is under little CPU load. Placing the audio system in the kernel instantly resolves this problem, since processes can be easily rescheduled.
Also one must not forget, that the OS kernel is the ultimate Hardware Abstraction Layer. Ideally a process running in user space is liberated from taking care about all the gritty details. Nobody would expect a networking program to manually implement TCP or taking care of the buffer status of the network interface. Nobody would expect to implement the details of a filesystem to write a file.
Yet the audio APIs like ALSA merely expose the hardware to the user space. Imaging a network driver implemented like this: Exposing the raw network packets to user space and having some daemon taking care of them rerouting to other processes. Or asingle processes taking exclusive use of a network interface.
If a network system was implemented that way, you'd ditch it immediately. However with current open source audio systems, this inane approach is accepted as perfectly normal.
Back in the good old days of analog audio, one would jokey around patch cabled between signal sources and sinks. Matrix mixers would take in the signal and redistribute it to their destinations. In a well equipped and set up studio any audio source could be routed by the press of a button or the turn of a knob.
This kind of signal handling is matched by the design of audio systems like JACK. However JACK is ultimately flawed by running in the user space. XRuns are the haunt of and dreaded by every JACK user.
A new audio system is worth nothing without a base of applications that can make use of it. It is hence not interfaced by a entirely new API. Instead it builds on an existing API, that provides audio the right way:
If this reminds you of OSS, well, yes: KLANG exposes a fully OSS compatible API to user space. Where it comes to configure flexible signal routing and synchronization, the OSS API is expanded upon. However only very few applications will actually require to tap into the extended API. So if a program speaks OSS, it also speaks KLANG.
There will be no entirely new API. Actually KLANG reuses an existing API and extends it.
OSS4 provides mixing, resampling and splicing a signal from a source to a process. But OSS4 still treats audio HW and client processes accessing it as different kinds of citizens. In addition to that OSS4 has no support for power management and sequencer data (=MIDI)
KLANG is different. KLANG has full support for the available power management primitives. KLANG provides transport for non-sample data, like MIDI. And KLANG will integrate into the kernel's namespacing/container primitives.
So far KLANG is in a very unstable and experimental state, at which it simply is not yet ready for a initial release. There are just too much in-situ crufts in it, that may be either misleading to early adopters may even lead development into an undesirable direction, if released to early.
The first release of KLANG sources will happen, as soon as both the routing system are stable and a functional native driver for Intel HD-Audio chipsets has been finished.
If you say so. This project was started to scratch a few personal itches and pet peeves:
If you don't like the idea of KLANG, then don't use it. Maybe it ends up in a mainline kernel's source tree. If not, it's not much of a big deal either, though it would be rather cool to have it there.