KLANG: A New Linux Audio System For The Kernel

[Wingfeather]

Analogue, sans disadvantages of low lifespan due to instability to "dust", has two serious advantages over digital:
1* ability to store much more information per state
2* "softness", which comes from (1)

This viewpoint is common and intuitive, but unfortunately is a complete fallacy, for the following reason.

While analogue appears at first glance to be of infinite resolution, it is susceptible to noise which, by definition, is unpredictable. The amount of real information present in an analogue signal is fundamentally limited by the amount of noise that is present. Analogue may be considered infinite-resolution in the sense that the noise will average out over a long period of time. So, say, if you record a continuous analogue sine wave over a huge number of cycles, and then average all those cycles into a single cycle, the sine component will remain while the noise will average out. Doing this over an infinite length of time will remove the noise entirely, and I think this is what you are alluding to.

But, this is true of digital signals too -- if they have been properly dithered. This is, indeed, the very purpose of dither, because it means that quantisation noise will become, for all practical purposes, random noise. Just like in an analogue system. Because of this, dithered digital processing is infinite-resolution in the same sense as analogue processing. At the same time, it retains all of its other advantages over analogue, such as error-free storage and transmission, the ability to be processed any number of times without adding any distortion, etc etc. Analogue has literally no advantages over digital if the digital is done correctly.

Which leads me to my point regarding fixed vs floating point. In my view, both Paul and Datenwolf make correct assertions. Floating-point's advantage over fixed is that it means the programmer never needs to worry about clipping during mixing. No disputing that. The exponent will just grow as it needs to. And, since x86 processors have already paid the cost of the extra silicon required, floating-point isn't even slower than fixed-point on x86. Also true. But what I think has been missed is that floating-point cannot be linearised with dither, and 32-bit floating-point doesn't have enough resolution to that we can simply ignore the nonlinearity. If you sum, say, 256 24-bit signals into a 32-bit float you are going to lose approximately the bottom 8 bits of the precision present in the originals. And not in a benign way - it will be of truncating form and manifest as distortion. It is probably acceptable insofar as it is probably inaudible -- but a single instance of 32-bit floating-point quantisation distortion is eminently measurable at the 24-bit level (I have measured it), so 256 lots of this is a quite scary proposition in my view for anything purporting to be "high-end audio".

FWIW, this is also the reason that the majority of professional DSP engineers (or, at least, all the ones I've spoken to) think that converting fixed-point to floating-point with anything other than an exact power-of-two multiplication is a dreadful hack.


In the end, 32-bit floating-point is a risky proposition for precision audio purposes. It is very definitely unsuitable for certain types of laboratory environment, is probably fine for things which will only be listened to, but in my opinion is somewhere in between for recording/mixing/mastering purposes which need a little bit extra performance. 64-bit floating-point would be fine, because the distortion will be at a vanishing level, and possibly on x86 not even that slow. 32-bit fixed-point is generally great for audio, but Paul has raised a real case where it won't have sufficient headroom.

[grok]

To me KLANG is just a really bad idea - if you want to improve the Linux audio stack, work on ALSA, PA and/or Jack ... OSS sucks and we don't need to revive it under some new name (klang) with some added features, while then trying to convince every developer to port his/her applications to it. ALSA has better hardware support than OSS (or KLANG) so unless DW plans to port and maintain every driver from ALSA - this just seems like a dumb idea, regardless of any argument of Float vs. fixed-point ...

anecdotal evidence, but OSSv4 once served me well. I had a low end C-media discrete board with terrible driver in ubuntu 10.04 and maybe 11.04. cracks, bursts of garbage into the speakers. OSS did support it much better (ALSA did too with a later kernel in a later distro)
the card itself was flawed maybe, decent output but "brittle", maybe drivers were of low quality both in ALSA and OSS.

it was convenient to have things in a single place (volumes and application mixing) though pulseaudio would be more powerful (I heard pulseaudio would be especially relevant when adding usb microphone, bluetooth audio etc. which I've never done yet)

now KLANG promises to be JACK compatible. this is interesting. the problem with JACK is, you install it with a few applications and nothing happens. dead silent. or Ardour complains things are'nt set up and shuts down when you launch it. so, how the hell do you set everything up, I don't know. I know my way around the command line and do a bit of network admin but don't know how to get started on this.

oh, there are THREE audio systems, somewhat overlapping on each other. well easy thing is getting rid of pulseaudio first (crippling a bit your computer) and see if you can understand something about your empty QjackCTL.
that's just a big barrier to entry, especially as I merely want to launch software and see if it works, in the remote hope I can get friends who tinker with music to use linux and Free software, Free plugins and synths and stuff etc.

I'm totally isolated, as everyone who uses a computer for music purpose is on Windows, where everything works by double-clicking setup.exe (or maybe use a Mac). time is wasted apt-getting non working or garbage quality software in the repository as well, even when they use ALSA and/or pulseaudio and thus should be easier to get working in theory. Actually I can't even play doom with a midi soundfont, on an OS which has doom and quake as the only games. (with timidity and prboom, a combination that worked on windows)

so, KLANG pretends it can do everything in a single place, be both OSS and JACK compatible, midi, do pulseaudio things. (route things into other things, so maybe I can have a software audio compressor that works, on my global output? something to prevent screaming ads or youtube from firefox, weird filter tricks, music player output to a second stereo output etc.

I don't know if KLANG is a real answer to that.
I'm not even trying to rant, this is what happens to me any time I want to have fun with sound in linux.

[cb88]

I've used one of those old c-media boards I bet it works perfectly under Windows and BSD :P .... same goes for the OPL2SA3 on my Tyan Thunder 2 ATX >:-)

[artivision]

1. KLANG is not OSS, it just connects on the same valves thats all.

2. KLANG is not user-space like others (pulse, jack), SUPERB!!!

3. It can replace almost everything, SUPERB!!!

4. If the development goes fast, then its a SUPERB idea.

[elanthis]

2. KLANG is not user-space like others (pulse, jack), SUPERB!!!

What the hell is with people thinking that putting large complex things in the kernel is a good idea? It both decreases stability and security. That's bad. It has almost zero measurable impact on performance in cases like this (microkernel's bad performance is due to every individual part needing to communicate over IPC 500 times to get anything done; putting each whole independent system into a userspace process does not require that kind of crap). It means you can't restart, upgrade, or modify the system without rebooting because it's tied to your kernel. That's bad. It has zero impact on userspace API, because everyone actually writing sound apps is using a library, not making syscalls.

[archibald]

It means you can't restart, upgrade, or modify the system without rebooting because it's tied to your kernel.

Couldn't it be implemented as a module for the kernel, and if so, wouldn't this allow it to be updated with bugfixes etc. provided the ABI was maintained?

[artivision]

What the hell is with people thinking that putting large complex things in the kernel is a good idea? It both decreases stability and security. That's bad. It has almost zero measurable impact on performance in cases like this (microkernel's bad performance is due to every individual part needing to communicate over IPC 500 times to get anything done; putting each whole independent system into a userspace process does not require that kind of crap). It means you can't restart, upgrade, or modify the system without rebooting because it's tied to your kernel. That's bad. It has zero impact on userspace API, because everyone actually writing sound apps is using a library, not making syscalls.

The opposite. Every thing on Userspace is potential threat, no exceptions. Kernel has """Policy""". As for the speed, I believe Kernel space has less latency.

[energyman]

Sounds good architecture decisions except for the use of OSS.
A company tried to blackmail Linux with OSS API, that's why it is being replaced by ALSA.


I hope I can switch an endpoint from source to sink and back while running.


Seems like ALSA needs some additions, since hardware could be doing this and thus must be able to organize this through ALSA. Ideally we want the audio hardware to take care of everything.

if your hardware supports hardware mixing, there is hwmixer for alsa....

[ShadowBane]

The opposite. Every thing on Userspace is potential threat, no exceptions. Kernel has """Policy""". As for the speed, I believe Kernel space has less latency.

Right, the part with unlimited permission and nothing below it to make sure that security policy is enforced is less of a threat than things that have limited access and a program that restricts and monitors them. That makes perfect sense...



And no, you can't get lower latencies by moving the audio server into the kernel. As the developer of Jack already explained, you would save a grand total of two context switches. For some reason I don't imagine that those two context switches are going to cause massive lag. :P

[RealNC]

what the hell is with people thinking that putting large complex things in the kernel is a good idea?

KMS anyone?