Announcement

Collapse
No announcement yet.

KLANG: A New Linux Audio System For The Kernel

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

  • #61
    Originally posted by datenwolf View Post
    So what does this mean for KLANG? KLANG can be compiled with either 40 bits or 48 bits per sample processing, with a footroom of 8 bits (this is for reversible attenuation of up to 48dB, which is plenty).
    Apparently you don't follow any of the trends in digital audio. Just as almost everybody else (except Avid/Digidesign) has adopted floating point as THE standard format for computer-based digital audio, you want to revert Linux to fixed point. This is supposed to be smart?

    You're going to explain to all the developers of every pro-audio and music creation software who might consider Linux as a platform for their work that their samples will be converted twice, once from the floating point format that their code uses into fixed point and then again into integer format before it hits the audio hardware? And that when they share audio data between applications, which will both be using floating point format, it will be converted to and then from fixed point as an intermediate?

    Could you at least spend several months hanging out with audio developers before you try to redesign the kernel subsystems that we rely on?

    Comment


    • #62
      Originally posted by Khudsa View Post
      Is this post on Steam: Steam Linux thread, a new audio project, from a developer of your group?
      This is indeed the case.

      Comment


      • #63
        Looking at it from an end-user perspective, what will change?

        I use ALSA + PulsaAudio and I have never experienced any latency on native programs...
        Heck, PulseAudio even got my "Windows-only" headphone (USB one, which without "special" software, doesn't even work on Windows) working via. software mixing, and it also got the microphone and the Dolby feature working flawlessly!

        Linux Audio isn't as bad as everyone says it is, at least not for me, but then again, the World doesn't revolve around me.

        I have never written any Linux-specific software which requires audio, therefore it would be nice if someone could give their insight about writing software for our current sound system on Linux.

        Comment


        • #64
          Originally posted by datenwolf View Post
          You'll hardly find 256 audio sources playing at the same time. So we can in practice mix even more stuff, without problems.
          BTW, you might want to check out: http://www.3daudioinc.com/3db/showth...00-bands-of-EQ Notice that the URL alone refers to the 384 inputs on this puppy.

          I don't want to advocate that every system API needs to be designed to handle the most extreme possible use cases, but seriously - 200+ channels is really fairly typical in a major movie post-production environment. If we were discussing PulseAudio, this kind of thing would just be "not part of the problem space". But you want to replace the entire kernel side system, not just the consumer/desktop audio server.

          You'll note that the above-referenced mixing console runs Linux, though full disclosure requires me to note that it does not use ALSA.

          Comment


          • #65
            Shame

            I guess you embarrassed datenwolf to the point he will not respond.
            That's the end of KLANG then!

            Comment


            • #66
              Originally posted by PaulDavis View Post
              BTW, you might want to check out: http://www.3daudioinc.com/3db/showth...00-bands-of-EQ Notice that the URL alone refers to the 384 inputs on this puppy.

              I don't want to advocate that every system API needs to be designed to handle the most extreme possible use cases, but seriously - 200+ channels is really fairly typical in a major movie post-production environment. If we were discussing PulseAudio, this kind of thing would just be "not part of the problem space". But you want to replace the entire kernel side system, not just the consumer/desktop audio server.

              You'll note that the above-referenced mixing console runs Linux, though full disclosure requires me to note that it does not use ALSA.

              While I think its absolutely fabulous your mixing, with hardware, that being controlled by software.

              Whats your real soft roundtrip latency if you use all software monitoring, cuase frankly., 8 samples smells like bullshit to me.and I've been around pro audio since the 486 was a twinkle in Intels eye.

              Comment


              • #67
                Originally posted by Thatguy View Post
                While I think its absolutely fabulous your mixing, with hardware, that being controlled by software.

                Whats your real soft roundtrip latency if you use all software monitoring, cuase frankly., 8 samples smells like bullshit to me.and I've been around pro audio since the 486 was a twinkle in Intels eye.
                It's not bullshit. While you may think that it is impressive that you have been around proaudio since the 486 was a twinkle in Intel's eye(which i find funny..lol), i find it far more interesting that Harrison Consoles has been an industry leader (for both Analog/digital Consoles) for decades. Maybe you should have a look at some of their products or whitepapers. here is a link to their website;



                the product in question using 8 samples, which you think is BS, is very likely xdubber, found here;



                You should also take a look at the link Paul provided (scroll halfway down the page), so you can see the physical hardware and how much 'muscle' their is. It makes your proaudio setup look like you are still running a 486 (and i don't even need to know what your hardware is to draw that conclusion).



                if you google "harrison consoles 8 samples" - you should turn up some whitepapers on the subject as well.
                Last edited by ninez; 02 August 2012, 12:30 AM.

                Comment


                • #68
                  A remark on inter-process communication

                  A remark on inter-process communication, you said:

                  Originally posted by PaulDavis View Post
                  You cannot be serious. Its hard to take anyone seriously who would claim such a thing. You think that two processes both touching an mmap'ed region in user space causes some kind of kernel hell? this is just ridiculous - you make it appear that you don't know how shared memory works at all! the address spaces have the region mapped. when each process touches part of the region NOTHING HAPPENS - its a memory access.
                  His point was indeed incorrect but shared memory in itself is not enough: for several processes to cooperate there must use IPCs to synchronize these access, and these IPC have the "two context switches" latency, so I'm not sure that putting a bigger part of the audio stack in the kernel couldnot reduce the average latency..

                  Also about the push/pull design, IMHO (I'm not an audio programmer) both are important and having low latency push (with low CPU usage) is important too: I'm thinking about a game which wants to have fast audio feedback when a player press a button, so I'm not sure that a push buffer over a pull mechanism is "good enough" for this use case.

                  Best regards.

                  Comment


                  • #69
                    Originally posted by bug! View Post
                    I use ALSA + PulsaAudio and I have never experienced any latency on native programs...
                    Of course not. PulseAudio and ALSA work just fine for the typical consumer workload. Even if you had an audio latency of 150ms or more you would probably only notice it if you were playing a very intense FPS, where there could be a very slight delay in the sounds coming from the game compared to the image you were seeing. Even then it probably wouldn't make much of a difference to you. This all changes when you need to (e.g.) synchronize a playback and a recording track in a DAW, or apply real-time effects to audio on a live concert. You can't have a delay of 100ms between two tracks (unless it's intencional of course) and you can't send the audio mix back to the musicians (on a live concert) with such a delay. It has to be as close as possible to real-time.

                    Comment


                    • #70
                      Originally posted by MickStep View Post
                      I guess you embarrassed datenwolf to the point he will not respond.
                      That's the end of KLANG then!
                      That sounds like Deutschlisch. The correct version of the statement would be: Das is die Ende der Klang Not that I support this kind of comments though.

                      Comment

                      Working...
                      X