KLANG: A New Linux Audio System For The Kernel

[Awesomeness]

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.

ALSA to this day supports the OSS API. No one was blackmailing. 4Front Technologies, the owner of Open Sound System?s source code, just made it proprietary, hoping to license newer versions to (then still relatively strong) proprietary UNIX vendors.

Better get you facts straight before posting BS again?

[Teho]

Considering the fact that this is from Datenwolf I wouldn't really get my hopes up. To me it seems that the guy doesn't know much if anything about audio on Linux...

[bug!]

I hope KLANG for FreeBSD would be a fork of sound(4) until API is stable to be finally merged upstream. FreeBSD OSS implementation is quite good: it doesn't produce interrupts when you pause a player and seems to be better maintained than 4Front OSS.

[89c51]

Seems like something worth trying.

Right now I can have Jack without Xruns or fancy desktop effects and working power management, never both.

Best solution for me so far has been a dual install: One with RT or Low Latency kernel, no desktop effects and Jack and one "normal" fancy desktop with decent power management.

I heard the Mac guys can do both in one system/install...

Anyone cares to explain how the Mac people do that and why we cant match it in linux? I don't think mac os x has a RT kernel.

[RealNC]

anyone cares to explain how the Mac people do that and why we cant match it in linux? I don't think mac os x has a RT kernel.

The OS X kernel has RT facilities. But you're missing the point: you don't need RT for this. The reason why RT is used in Linux for audio just shows the problems the audio stack has. RT is not needed, unless you're doing something wrong in the audio infrastructure.

[ariendj]

Anyone cares to explain how the Mac people do that [...]?

I'd like to know that too.

[Weegee]

[Zorael]

While duplication of effort is generally a bad thing, I like judging by merit. If this ends up being superior to ALSA and PA, then rejoice; progress to the audio stack. Elsewise this implementation will simply remain niche and/or die out, and it may have taken manhours that could otherwise have been spent on existing systems (but that's not guaranteed).

I wonder, to what extent can existing drivers be ported to this?

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.

Yeah, chances of mainlining this is slim at best, and cards are really stacked against it if it wants to gain traction when being an out-of-tree system.

Also, OSS is a terrible API from the 90s that has no concept of modern ideas like power savings.

Well, the page does say that KLANG API is a superset of OSS API, with its extensions including power management support. From the page;

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.

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".

Is this that big a problem? In its defense, it does mention being targeted toward Linux and FreeBSD kernels. (Moreover, to sate my curiosity, what open source OS nowadays isn't nix-like, or at least supports char devices?)

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.

My pragmatic self concedes to this, but my idealistic self just nods its head and says 'bring it.' Much like extraordinary claims demand extraordinary evidence, if this project can show that it's a better solution across the board, then I'm all for it. Until such time I'll stick with PA, but my door will stay open to new ideas. Moreover I imagine most applications will still use abstraction layers (SDL, gstreamer, etc), excepting stuff where realtime-level latencies are simply crucial.

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.

Can't argue here. My main gripe with PA is just that KDE doesn't implement its controls better, which isn't PA's fault at all. PA is great for my use-cases.

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 is an interesting problem. Can ALSA drivers be ported to KLANG, keeping the hardware interface but changing what it exposes to the kernel?

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.

Well, to be a bit more fair, it's more like seeing everyone else taking long trips in their gasoline-powered cars, and thinking "hm, can't we use this new cheap diesel I'm envisioning and cut costs?". New car engines would have to be developed, but assuming ALSA drivers can be ported with reasonable effort, the rest of the car can stay the same.

Contribute to ALSA or PulseAudio (or both) instead, ya dolt!

He's scratching his own itch. :3 And if he really thinks that the basic workings of ALSA are that flawed, what's left but to start from scratch?

[droidhacker]

This is just a protest project, not even newsworthy.

DO NOT pollute my kernel with stupid audio crap that doesn't belong in the kernel. ALSA+Pulse is a MUCH better approach to sound.


Some people get freaked out when things actually ADVANCE. They are very small people.

[Awesomeness]

If you understand German, check http://www.heise.de/open/news/foren/.../showthread-1/
Wolfgang explains a bit more about KLANG and his arguments sound valid.