No announcement yet.

KLANG: A New Linux Audio System For The Kernel

  • Filter
  • Time
  • Show
Clear All
new posts

  • KLANG: A New Linux Audio System For The Kernel

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

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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...


    • #3
      I say: About fscking time! I really hope this project succeeds. I don't think it will though, since the ALSA lobby is very strong. But one can always hope.


      • #4
        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.


        • #5
          Sounds good to me: If it can be pulled off, it sounds like it might be a nice way to simplify the linux audio system.

          I'm glad he's targeting the FreeBSD kernel too.


          • #6
            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.

            Each endpoint is either a signal source or a sink, allowing for versatile signal routing topoligies.
            I hope I can switch an endpoint from source to sink and back while running.

            No proper mixing support in ALSA. No, dmix does not do the job. Also there's more to audio than just mixing.
            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.


            • #7
              Yet another one, but...

              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.


              • #8
                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.
                Last edited by Gusar; 31 July 2012, 08:46 AM.


                • #9
                  The page does not say why he creates a new framework (and new drivers!) instead of adding PM and midi to OSS4.

                  Indeed from a quick read I came out with OSS4 doing what he wants sans those two things. And it actually has some existing drivers


                  • #10
                    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.

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