Page 7 of 21 FirstFirst ... 5678917 ... LastLast
Results 61 to 70 of 207

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

  1. #61
    Join Date
    Jul 2012
    Posts
    9

    Default

    Quote 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?

  2. #62
    Join Date
    Jul 2012
    Posts
    6

    Default

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

  3. #63
    Join Date
    Jun 2011
    Posts
    59

    Default

    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.

  4. #64
    Join Date
    Jul 2012
    Posts
    9

    Default

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

  5. #65
    Join Date
    Aug 2012
    Posts
    2

    Default Shame

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

  6. #66
    Join Date
    Jan 2011
    Posts
    219

    Default

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

  7. #67
    Join Date
    Jun 2011
    Posts
    826

    Default

    Quote 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;

    http://www.harrisonconsoles.com/joom...tpage&Itemid=1

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

    http://www.harrisonconsoles.com/joom...d=23&Itemid=57

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

    http://www.3daudioinc.com/3db/showth...00-bands-of-EQ

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

  8. #68
    Join Date
    Mar 2012
    Posts
    81

    Default A remark on inter-process communication

    A remark on inter-process communication, you said:

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

  9. #69
    Join Date
    Jan 2010
    Location
    Portugal
    Posts
    944

    Default

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

  10. #70
    Join Date
    Jan 2011
    Posts
    58

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •