KLANG: A New Linux Audio System For The Kernel

[PaulDavis]

Paul could you also answer why mac os x does a better job with a single "stack", why we can't have the same in linux and also why there is no effort trying to merge jack and PA (lack of manpower was the reason last time i heard about it).

Its complicated. OS X does a better job with a single stack because it has very clever design that we unfortunately missed (read: didn't know about) back in the early days of ALSA. i don't feel so bad about this - windows didn't get anything remotely resembling this idea till years later either. The crux of the matter is that CoreAudio is NOT dependent on the flow of interrupts from the device to be able to know with fairly high precision where the current audio interface read and write locations are in memory. This means that applications with entirely different latency requirements can write into a shared memory buffer without requiring that they all do so synchronously (the way that JACK requires). An application that wants to write 8 samples at a time can do so, and at the same time, another application that wants to deliver 4096 or even 64k samples at a time can also do so - CoreAudio can ensure that both of them end up putting audio in the "right" place in the mix buffer so as to match their latency requirements. It does this using an engineering design called a delay locked loop (DLL), which actually makes the latency slightly worse than on Linux - CoreAudio drivers have a "safety buffer" to account for possible errors in the estimates that the DLL provides for the current read/write pointer locations, and this adds to the overall latency. Its fairly small though - typically 8-32 samples. 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.

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. 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). So historically, they have done some of this in the kernel. they won't talk much about the details, but it appears that in recent OS X releases (Lion & Mountain Lion) they have moved away from this and now have a user space daemon that is conceptually similar to Pulse and/or JACK through which all audio flows. this is slight speculation - you can see the server running with ps(1) but apple have never said anything about it. Its also not clear whether the shared memory buffer into which applications ultimately write their audio data is in user space or kernel space, and this may also have changed recently. The key point is that even with the DLL-driven design in the kernel, there are still tricky, fundamental aspects of API design that you have to tackle, and that even on OS X, the answers are not fixed in stone.

interestingly note that PulseAudio has (or was going to have) this DLL-driven design too - lennart calls it "glitch free" - but adding to pulseaudio (or JACK) doesn't do anything what goes on at the ALSA layer.

as for merging JACK + PulseAudio, manpower remains an issue, but more importantly, the goals of the two projects are not really that similar even though to the many idiot-savants who post to reddit and slashdot, they sound as if they should be. there are ways that it could happen, but it would require a huge level of desire on the part of all involved, and given the difficulties we have internally with two different jack implementations, it just seems unlikely.

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