DaemonForums  

Go Back   DaemonForums > DaemonForums.org > News

News News regarding BSD and related.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 2nd August 2012
vermaden's Avatar
vermaden vermaden is offline
Administrator
 
Join Date: Apr 2008
Location: pl_PL.lodz
Posts: 1,051
Thanked 118 Times in 93 Posts
Default KLANG - Kernel Level Audio Next Generation

... do not confuse it with CLANG, its OSS4 on steroids

Quote:
Originally Posted by http://klang.eudyptula.org/

About KLANG

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.

Why a audio system in the kernel?

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.

Audio is a routing problem

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.

Great another API to replace them all. Now we got N+1 APIs...

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:
open(2) a endpoint
ioctl(2) the endpoint to configure it
write(2) to the endpoint to insert signal into the audio system
read(2) from the endpoint to retrieve signal from the audio system

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.

Wait, doesn't OSS4 already provide all this

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.
Sound's great! So where can I get it?

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 adaptors or may even lead development into an undesireable 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.

Yawn... sounds boring

If you say so. This project was started to scratch a few personal itches and pet peeves:
No proper mixing support in ALSA. No, dmix does not do the job. Also there's more to audio than just mixing.
User space audio systems are annoying
JACK has the right design, but consumes just to much CPU and kills power efficiency. Also it doesn't cope well with coarse scheduling.
PulseAudio... meh, but I'm hearing it's getting better recently. Does it still require RealtimeKit to work properly?
ESD? Yeah, makes for a great audio desintegrator effect synthesizer. Also can be abused as a networked tracker music backend. But not to glitchlessly play a continous stream of audio samples
OSS4 does not support sequencers and draws your battery in no time. But it has a great API

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.
KLANG is part of the Eudyptula project by Wolfgang 'datenwolf' Draxinger, eudyptula+klang (a) datenwolf _ net
__________________
religions, worst damnation of mankind
"If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus Torvalds

Linux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”.
vermaden's: links resources deviantart spreadbsd
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
azalia Intel SCH HD Audio strange audio issues tehsean OpenBSD General 3 26th August 2012 12:21 AM
TCP sequence number generation vulnerability patch for netbsd3.0 nagesh NetBSD Security 0 16th March 2012 05:43 PM
Determining patch level andrewm OpenBSD Installation and Upgrading 2 7th September 2010 04:05 PM
Automating patch generation and application for configuration files J65nko Guides 5 25th January 2010 03:58 AM
PF and kernel-level PPPoE(4) gezley OpenBSD Security 3 15th May 2009 06:56 PM


All times are GMT. The time now is 12:37 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick