Page 5 of 21 FirstFirst ... 3456715 ... LastLast
Results 41 to 50 of 207

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

  1. #41
    Join Date
    Oct 2009
    Posts
    131

    Default

    I remember playing some songs on my old Pentium 100, 8 MB RAM and 1 GB HD...

  2. #42
    Join Date
    Jul 2012
    Posts
    9

    Default

    Quote Originally Posted by cb88 View Post
    You know...PulseAudio I despise the extra daemon running in the background. Oh.. *Idea* lets hide the whole shebang in the kernel! that way they can't see it right off... You know it really would be better if the parts that have to be running all the time got merged into the kernel and the parts that don't stayed in userspace. The problem with this is audio problems are now harder to fix as it increases the likelihood of requiring a kernel recompile.
    and yet , here on my lion mac mini ...

    % ps aux | grep coreaudio
    _coreaudiod 157 0.4 0.1 2517736 8168 ?? Ss 29Jun12 77:35.38 /usr/sbin/coreaudiod

    yeah, its certainly true that the OS X world is full of people who despise the extra daemon runnin gin the background.

    apparently, you're not familiar with the linux engineering dictum that the kernel provides mechanism not policy. putting mixing, sample rate conversion and sample format conversion into the kernel would completely violate that policy. and if you insist, like KLANG (and OSS) on using open/read/write/ioctl, then all those things MUST be in the kernel.

    Clearly you can use FP in the kernel http://www.linuxsmiths.com/blog/?p=253 I can see how there could be drawbacks however if you tried doing alot of FP in the kernel.
    modern digital audio is all floating point, at least until it has to be written to a device.

  3. #43
    Join Date
    Jan 2009
    Posts
    1,681

    Default

    @PaulDavis


    Thank you very much for the answer. The merging JACK and PA was mentioned not in term of project goal but rather as having a single stack.
    Last edited by 89c51; 07-31-2012 at 03:36 PM.

  4. #44
    Join Date
    Apr 2010
    Posts
    1,946

    Default

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

    Contribute to ALSA or PulseAudio (or both) instead, ya dolt!
    I think its more "traveling 500 miles" then finding things that are worth changing and traveling again.
    It don't think it will bring much improvement, but it will surely bring improvement.

    Completely agree with your VP on OSS & contribution targets.

  5. #45
    Join Date
    Apr 2010
    Posts
    1,946

    Default

    Quote Originally Posted by Khudsa View Post
    I remember playing some songs on my old Pentium 100, 8 MB RAM and 1 GB HD...
    8MIB of RAM is really really small for P 100... Consider upgrading.
    486 is ok with 8MiB, but Pentium and up need at least 16MiB.

    Also, the sound pretty much sucked. Cmmon 8bit, 8khz almost always mono. No wonder tracker was so favorite back then.

    So, I remember playing songs on my old 486sx with 4MiB RAM and 160 MB HDD and I don't want those times back.
    Last edited by crazycheese; 07-31-2012 at 04:09 PM.

  6. #46
    Join Date
    Oct 2009
    Posts
    131

    Default

    Quote Originally Posted by crazycheese View Post
    8MIB of RAM is really really small for P 100... Consider upgrading.
    486 is ok with 8MiB, but Pentium and up need at least 16MiB.

    Also, the sound pretty much sucked. Cmmon 8bit, 8khz almost always mono. No wonder tracker was so favorite back then.

    So, I remember playing songs on my old 486sx with 4MiB RAM and 160 MB HDD and I don't want those times back.
    Has 8 MB when I bought it, later upgraded to 16 MB. And sorry the message was a response to Ferdinand about playing songs in mp3. But... I had make a mistake, i'm recalling that that mp3 songs was on a newer PC, an AMD Athlon 500 MHZ. Sorry.

  7. #47
    Join Date
    Oct 2007
    Posts
    285

    Default

    I always saw OSS as superior to ALSA so i'm not surprised that he reuses the OSS API. Very smart move! We'll see how this plays out. I'm having high hopes

  8. #48
    Join Date
    Jul 2012
    Posts
    6

    Default

    On the DLL based position estimation of CoreAudio
    Quote Originally Posted by PaulDavis View Post
    (…) Now, there is nothing fundamental stopping ALSA from adopting this kind of design. But nothing stopping it isn't the same as making it happen - that would require a significant engineering effort.
    This is in tune what I do in KLANG, only that I don't use a DLL but a PLL which is used as a frequency scaler from buffer interval interrupts to sample position. I come from experimental physics and whenever we have to synchronize high frequency delay counters to low frequency triggers the PLL module gets put into the NIM rack.

    Also our sample rates in physics are several orders of magnitudes higher of that found in audio. Right now I got that task (at my work I get paid for) to process 2GS/s with 16 bits/S. Oh, and I have to rescale that with varying target sample distances, with lowest possible harmonic distortion. That's the kind of signal processing I usually deal with, and this is to be happen on a 8 cores Ivy Bridge, so…

    Quote Originally Posted by PaulDavis View Post
    In addition, even without this, you still have to decide where sample rate conversion and sample format conversion will take place - in user space, or in the kernel.
    In the kernel of course, because for one, sample format conversion is a no brainer, the biggest problem is being nice to the cache lines. Sample rate conversion is the tricky beast, but can be done with fixed point just as well, if not even better. A lot of people, especially those coming from PC programming, have a rather low regard for fixed point stuff, for some reason I can't fathom. But if you look around in the high performance, high precision DSP business, most signal processing is done in fixed point there. And that's for good reasons; avoiding loss of precision is one of them. Actually if you need very high precision and performance, you end up doing things fixed point very soon.

    Quote Originally Posted by PaulDavis View Post
    OS X does not have a prohibition on floating point in kernel space (which is contributes a teeny bit to why their kernel is slower than linux for many things).
    You can do floating point in the Linux kernel, it's just frowned upon. kernel_fpu_begin and kernel_fpu_end allow for FPU register save, restore. But KLANG doesn't need it, because it does everything fixed point.

  9. #49
    Join Date
    Jan 2010
    Location
    Portugal
    Posts
    945

    Default

    Quote Originally Posted by Ferdinand View Post
    Shouldn't a pentium 133Mhz be able to play an mp3 fluently?
    I know, from personal experience, that a Pentium 200 MMX can play mp3 fluently (192Kbps, 44KHz, 16-bit, Damn Small Linux, a couple of years ago) but a 486DX2 66MHz can't. Of course this was with a distro tweaked for low resources machines. Considering that the 486-66MHz played the mp3 with lots of stuttering, but it would still output about 500ms of clean sound each 1-2 seconds, the Pentium 133MHz probably would be able to play a 128Kbps mp3 fluently (albeit with 100% cpu usage or very close).

    I'm sure this post has a relevance of 0...

  10. #50
    Join Date
    Dec 2011
    Posts
    38

    Default

    i don't get it.

    good quality sound mixing requires floating point operation, but this is not allowed in kernel currently.
    How can fixed-point operation achieving good quality

    However, if compare to Windows/FreeBSD, they does sound mixing in kernel for low latency.
    i don't think that linux developers are so "superior" to be able to achieve the goal in userspace.
    As long as Linus bans floating point operation in kernel, he is banning Linux kernel to achieve low-latency audio in a cpu cycle effective/power effective way.

    KLANG seems to be a small step in the correct direction, but this is unrealistic to reinvent the wheel (how many years will it take?)
    either enhancing in ALSA with floating point or improving OSS4 and push it mainline.
    Last edited by unknown2; 07-31-2012 at 07:50 PM.

Posting Permissions

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