If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

KLANG: A New Linux Audio System For The Kernel

07-31-2012, 07:40 AM

Phoronix: KLANG: A New Linux Audio System For The Kernel

A developer has begun working on a new audio sub-system for the Linux kernel, which he is referring to as KLANG, the Kernel Level Audio Next Generation. KLANG was conceived after the developer became frustrated by ALSA, OSS4, and PulseAudio...

Comment

I was beginning to worry that I am the only one in this world with disappointed feelings about existing Linux audio subsystems. Now there's finally someone who has the time to set things right. I just hope the developer will implement it correctly, or else we'll have the 6th or so failed attempt at an audio subsystem. The goals do seem to be right thought, IMHO.

Comment

Even if his chances of seeing the community accept broadly yet another sound system are thin IMHO, if this guy could manage to create a sound system that is

1) simple in its architecture (no self-sentient userspace daemon required);
2) simple in its usage (zero configuration required at least to put the audio hardware in a sane state);
3) moderate in its requirements (a pentium 4 should be able to play an mp3 without suffering at all);

then it might be a good thing.

Comment

What I wonder is whether this'll be able to manage the jungle that is HD Audio. I kinda have my doubts about that. Because if you look at the ALSA driver, it's basically one quirks list after another, because every vendor wires the thing differently. If KLANG can manage that, it could gain traction. Especially because no adjustments to existing apps are necessary, due to the use of the OSS API.

Comment

1. Unless he wants to only support integer sample formats, this will never be allowed in the kernel, because Linus doesn't allow floating point in the kernel. I guess he'd have to resample any inbound floating point audio from programs in userspace before passing it to the kernel. But since the proposal is for directly accessing a character device, that sounds impossible. Good luck with that.

2. The OSS API? Seriously? It's not even an API; it's just a character based interface. That's not very portable, you know. Even ALSA is more portable than that (you could in principle implement libasound2 backend on Windows and compile it and it should work). Also, OSS is a terrible API from the 90s that has no concept of modern ideas like power savings. The problem is that a "character device" is a concept unique to *NIX operating systems, so any OS that doesn't implement that concept is kinda screwed. A "C" API is pretty much a universal concept; all but 1 or 2 exotic OSes support that. So you can't talk about portability while saying "forget all OSes that don't derive their core design from UNIX".

3. We don't need another solution. Period. We have too many already. It's way past the point where introducing new solutions is even remotely plausible. All this can possibly do is bring further fragmentation and brokenness to the Linux desktop, and add more headaches for application developers trying to support every system. Hopefully it does not gain any traction whatsoever.

4. Using the justification of being "annoyed" at PulseAudio is not a reason for starting a completely new project. Instead, improve on the things about PulseAudio that annoy you. Although I can't imagine what; I haven't even thought about sound infrastructure on my system for more than a year. I start up apps and they play sound. I don't see what there is to be annoyed about. Everything "just works" with no glitches/dropouts/etc, exactly like it was promised when PA started back in '06 / '07.

5. It'll take you a decade to develop all the hardware support needed to be even competitive with OSS4, let alone ALSA. Audio drivers can't ever be pure and simple; they necessarily have to come with tons of ASIC-specific hacks and workarounds, because hardware manufacturers like to add little tweaks to break your driver, like changing pinouts, etc. It's part of the territory. It takes a ridiculous amount of manpower to develop and maintain all those workarounds. One person isn't going to cut it. All the traction is already with ALSA. All the success is already with ALSA.

This thing is just stupid. It's like going on a 500 mile trip in the car, traveling 498 miles to your destination, then say "oh $@(# I meant to take a train, not a car, this sucks", then drive all the way back home and get on a train to go there again. What a terrible waste of manpower.