Announcement

Collapse
No announcement yet.

KLANG: A New Linux Audio System For The Kernel

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by 89c51 View Post
    Anyone cares to explain how the Mac people do that [...]?
    I'd like to know that too.

    Comment


    • #17

      Comment


      • #18
        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?

        Originally posted by allquixotic View Post
        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.


        Originally posted by allquixotic View Post
        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;
        Originally posted by http://klang.eudyptula.org
        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.

        Originally posted by allquixotic View Post
        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?)


        Originally posted by allquixotic View Post
        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.


        Originally posted by allquixotic View Post
        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.


        Originally posted by allquixotic View Post
        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?


        Originally posted by allquixotic View Post
        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.


        Originally posted by allquixotic View Post
        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?

        Comment


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

          Comment


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

            Comment


            • #21
              Remarks from the creator of JACK

              http://ardour.org/pd_on_klang

              Comment


              • #22
                Originally posted by RealNC View Post
                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.
                Explain whats wrong then.

                Comment


                • #23
                  From experience I know that a task like this can not be taken lightly. I've been developing a lightweight 3D audio library for years and only recently it got in a state I find acceptable (but maybe I've got too high standards). It's called AeonWave and is available for Linux and Windows now: http://www.adalin.com
                  Although it is not Freeware, it is cheap and a royalty free (but limited) version of the library is available.

                  I am a fan of Free and Open Source software though (hence the many open source side projects and more to come).
                  This project was started out of frustration for the state of OpenAL-Sample years ago (and in some ways still today with OpenAL-Soft) and renders about 6 times faster than both. As time passed proper stereo mixing and effects supports has been added as well as support for audio-frames which can be used for sub-mixing and to move multiple sound emitters around simultaneously in a 3d environment.

                  This library however is not meant to be a replacement for ALSA, PulseAudio or OSS but instead it simply uses one of them as a backend. I really wouldn't want to think of this much code added the the kernel..

                  Personally I think the library fills a gap that both OS-X and Windows already have a solution for and the fact that it can render (3d) audio up to 7 times faster (and I see some room for more improvement) and can be setup for latencies as low as 2 msec means it is well thought out in my honest opinion.

                  Comment


                  • #24
                    another greatest latest front end

                    is exactly what we need...

                    being happy alsa user for years. didnt have any issues with it for quite a while.
                    Let me remind you principle that ANY engineer follows, IF IT'S AINT BROKEN - DON'T FIX IT!

                    Comment


                    • #25
                      Originally posted by dimko View Post
                      Let me remind you principle that ANY engineer follows, IF IT'S AINT BROKEN - DON'T FIX IT!

                      Any engineer that believes in or follows that principle is a moron and should be shot.

                      Comment


                      • #26
                        Originally posted by plonoma View Post
                        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.
                        The company simply did not release some improvements. People were free to implement those on their own. The creation of ALSA was far more than was necessary and wasted resources that could have went into making other things better.

                        Comment


                        • #27
                          Originally posted by 89c51 View Post
                          Explain whats wrong then.
                          NASA launches a rocket carrying a satellite. The rocket explodes 10 seconds after liftoff. 1 billion dollars wasted. Someone says: "It exploded, something went wrong!" 89c51 says: "Explain what's wrong then." Someone answers: "I've no idea!" 89c51 says: "See? Nothing's wrong. Everything is OK."

                          89c51 was fired soon after.

                          Comment


                          • #28
                            Originally posted by RealNC View Post
                            NASA launches a rocket carrying a satellite. The rocket explodes 10 seconds after liftoff. 1 billion dollars wasted. Someone says: "It exploded, something went wrong!" 89c51 says: "Explain what's wrong then." Someone answers: "I've no idea!" 89c51 says: "See? Nothing's wrong. Everything is OK."

                            89c51 was fired soon after.

                            Comment


                            • #29
                              Originally posted by RealNC View Post
                              NASA launches a rocket carrying a satellite. The rocket explodes 10 seconds after liftoff. 1 billion dollars wasted. Someone says: "It exploded, something went wrong!" 89c51 says: "Explain what's wrong then." Someone answers: "I've no idea!" 89c51 says: "See? Nothing's wrong. Everything is OK."

                              89c51 was fired soon after.
                              The differrence is that the audio stack doesn't explode or destroy 1 billion dollars of stuff. You dodged the question because you actually know what the answer is: there is nothing wrong with the linux audio stack. Having Real Time priority will allow any type of process to get more done in a given time frame, so it naturally helps audio stuff which has a strict deadline. That being said, it is prefectly possible to do audio stuff on a stock kernel. I generally have between 8 and 32ms latency, depending on how much processor intensive stuff I am doing. I use the stock kernel as I can't be bothered to install a RT one. Judging from the conversations that I have seen on #opensourcemusicians on freenode (people who have some idea how audio works under linux :P) using a RT kernel isn't even the most common approach.

                              Next time you say something is broken at least be able to tell why you believe this (the rocket because it exploded, a car because it crashed, etc.)

                              Comment


                              • #30
                                "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.
                                Isn't this what ALL the other sound systems have been trying to do? They have all failed.

                                ALSA has worked fine for me for as long as I can remember. I don't want another square wheel.

                                Comment

                                Working...
                                X