Page 10 of 21 FirstFirst ... 8910111220 ... LastLast
Results 91 to 100 of 207

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

  1. #91
    Join Date
    Aug 2011
    Posts
    62

    Default

    Quote Originally Posted by ninez View Post
    To me KLANG is just a really bad idea - if you want to improve the Linux audio stack, work on ALSA, PA and/or Jack ... OSS sucks and we don't need to revive it under some new name (klang) with some added features, while then trying to convince every developer to port his/her applications to it. ALSA has better hardware support than OSS (or KLANG) so unless DW plans to port and maintain every driver from ALSA - this just seems like a dumb idea, regardless of any argument of Float vs. fixed-point ...
    anecdotal evidence, but OSSv4 once served me well. I had a low end C-media discrete board with terrible driver in ubuntu 10.04 and maybe 11.04. cracks, bursts of garbage into the speakers. OSS did support it much better (ALSA did too with a later kernel in a later distro)
    the card itself was flawed maybe, decent output but "brittle", maybe drivers were of low quality both in ALSA and OSS.

    it was convenient to have things in a single place (volumes and application mixing) though pulseaudio would be more powerful (I heard pulseaudio would be especially relevant when adding usb microphone, bluetooth audio etc. which I've never done yet)

    now KLANG promises to be JACK compatible. this is interesting. the problem with JACK is, you install it with a few applications and nothing happens. dead silent. or Ardour complains things are'nt set up and shuts down when you launch it. so, how the hell do you set everything up, I don't know. I know my way around the command line and do a bit of network admin but don't know how to get started on this.

    oh, there are THREE audio systems, somewhat overlapping on each other. well easy thing is getting rid of pulseaudio first (crippling a bit your computer) and see if you can understand something about your empty QjackCTL.
    that's just a big barrier to entry, especially as I merely want to launch software and see if it works, in the remote hope I can get friends who tinker with music to use linux and Free software, Free plugins and synths and stuff etc.

    I'm totally isolated, as everyone who uses a computer for music purpose is on Windows, where everything works by double-clicking setup.exe (or maybe use a Mac). time is wasted apt-getting non working or garbage quality software in the repository as well, even when they use ALSA and/or pulseaudio and thus should be easier to get working in theory. Actually I can't even play doom with a midi soundfont, on an OS which has doom and quake as the only games. (with timidity and prboom, a combination that worked on windows)

    so, KLANG pretends it can do everything in a single place, be both OSS and JACK compatible, midi, do pulseaudio things. (route things into other things, so maybe I can have a software audio compressor that works, on my global output? something to prevent screaming ads or youtube from firefox, weird filter tricks, music player output to a second stereo output etc.

    I don't know if KLANG is a real answer to that.
    I'm not even trying to rant, this is what happens to me any time I want to have fun with sound in linux.
    Last edited by grok; 08-11-2012 at 09:38 AM.

  2. #92
    Join Date
    Jan 2009
    Posts
    288

    Default

    I've used one of those old c-media boards I bet it works perfectly under Windows and BSD :P .... same goes for the OPL2SA3 on my Tyan Thunder 2 ATX >:-)

  3. #93
    Join Date
    Apr 2011
    Posts
    302

    Default

    1. KLANG is not OSS, it just connects on the same valves thats all.

    2. KLANG is not user-space like others (pulse, jack), SUPERB!!!

    3. It can replace almost everything, SUPERB!!!

    4. If the development goes fast, then its a SUPERB idea.

  4. #94
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Quote Originally Posted by artivision View Post
    2. KLANG is not user-space like others (pulse, jack), SUPERB!!!
    What the hell is with people thinking that putting large complex things in the kernel is a good idea? It both decreases stability and security. That's bad. It has almost zero measurable impact on performance in cases like this (microkernel's bad performance is due to every individual part needing to communicate over IPC 500 times to get anything done; putting each whole independent system into a userspace process does not require that kind of crap). It means you can't restart, upgrade, or modify the system without rebooting because it's tied to your kernel. That's bad. It has zero impact on userspace API, because everyone actually writing sound apps is using a library, not making syscalls.

  5. #95
    Join Date
    Jul 2010
    Posts
    449

    Default

    Quote Originally Posted by elanthis View Post
    It means you can't restart, upgrade, or modify the system without rebooting because it's tied to your kernel.
    Couldn't it be implemented as a module for the kernel, and if so, wouldn't this allow it to be updated with bugfixes etc. provided the ABI was maintained?

  6. #96
    Join Date
    Apr 2011
    Posts
    302

    Default

    Quote Originally Posted by elanthis View Post
    What the hell is with people thinking that putting large complex things in the kernel is a good idea? It both decreases stability and security. That's bad. It has almost zero measurable impact on performance in cases like this (microkernel's bad performance is due to every individual part needing to communicate over IPC 500 times to get anything done; putting each whole independent system into a userspace process does not require that kind of crap). It means you can't restart, upgrade, or modify the system without rebooting because it's tied to your kernel. That's bad. It has zero impact on userspace API, because everyone actually writing sound apps is using a library, not making syscalls.
    The opposite. Every thing on Userspace is potential threat, no exceptions. Kernel has """Policy""". As for the speed, I believe Kernel space has less latency.

  7. #97
    Join Date
    Jul 2008
    Posts
    1,718

    Default

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


    I hope I can switch an endpoint from source to sink and back while running.


    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.

    if your hardware supports hardware mixing, there is hwmixer for alsa....

  8. #98
    Join Date
    Jun 2012
    Posts
    119

    Default

    Quote Originally Posted by artivision View Post
    The opposite. Every thing on Userspace is potential threat, no exceptions. Kernel has """Policy""". As for the speed, I believe Kernel space has less latency.
    Right, the part with unlimited permission and nothing below it to make sure that security policy is enforced is less of a threat than things that have limited access and a program that restricts and monitors them. That makes perfect sense...



    And no, you can't get lower latencies by moving the audio server into the kernel. As the developer of Jack already explained, you would save a grand total of two context switches. For some reason I don't imagine that those two context switches are going to cause massive lag. :P

  9. #99
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,778

    Default

    Quote Originally Posted by elanthis View Post
    what the hell is with people thinking that putting large complex things in the kernel is a good idea?
    KMS anyone?

  10. #100
    Join Date
    Apr 2011
    Posts
    302

    Default

    Quote Originally Posted by ShadowBane View Post
    Right, the part with unlimited permission and nothing below it to make sure that security policy is enforced is less of a threat than things that have limited access and a program that restricts and monitors them. That makes perfect sense...



    And no, you can't get lower latencies by moving the audio server into the kernel. As the developer of Jack already explained, you would save a grand total of two context switches. For some reason I don't imagine that those two context switches are going to cause massive lag. :P
    Only KLANG is on Kernel space, not the programs using it (hierarchy). Also Audio is a stream not a Virus.

Posting Permissions

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