KLANG: A New Linux Audio System For The Kernel

[Khudsa]

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

[PaulDavis]

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.

[89c51]

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

[crazycheese]

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.

[crazycheese]

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.

[Khudsa]

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.

[markg85]

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

[datenwolf]

On the DLL based position estimation of CoreAudio

(?) 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?

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.

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.

[devius]

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

[unknown2]

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.