KLANG: A New Linux Audio System For The Kernel

[archibald]

Audio is a stream not a Virus.

Justin Bieber. That is all.

[RealNC]

Also Audio is a stream not a Virus.

Justin Bieber. That is all.

Virulent stream of shit?

[ShadowBane]

Only KLANG is on Kernel space, not the programs using it (hierarchy). Also Audio is a stream not a Virus.

The audio server being in the kernel is a bad thing for the same reason that running the audio server as root is a bad thing. It isn't about the audio stream being a virus, but the fact that there could be a hole somewhere that allows code injection (among other things.) It does appear you don't know of the principle of least privilege (the kernel has authority to do anything and everything.) http://en.wikipedia.org/wiki/Princip...east_privilege

[grok]

I shall set up a linux distro installation (or a BSD) on a spare IDE hard drive, just so that I only run it as root. that would be funny.
I had suprisingly trouble running windows XP as root for over half a decade - that ended in 2009 with strong malware made by professionnal criminal teams.

[RealNC]

The audio server being in the kernel is a bad thing

Absolutely. Good thing then that KLANG isn't an audio server.

[ShadowBane]

Absolutely. Good thing then that KLANG isn't an audio server.

Except it really is. It will consist of (at least) two parts: the part that moves the audio around between applications and the hardware, mixes stuff, does processing, etc. and the part that actually manages the hardware. You don't expect each hardware driver to implement the first part from scratch, do you? Moving it all into the same process doesn't make it suddenly not a sound server.

[elanthis]

KMS anyone?

KMS is just mode setting. It is not the rest of the graphics stack. And it was only moved because the kernel actually needs modesetting for its own internal consumption. The kernel has no reason to internally consume the audio interface.

[Scias]

So here we start again for one yet another Audio API/System that will need new/rewritten drivers and waste a lot of manpower, years of development, more years for bugfixing, even more years for drivers to be ready and bug-free, some more years for the transition to occur(that will imply a lot of breakage and frustration of course), yet another years for the user software to bring back their ditched OSS output backend to life (as more and more abandoned it), and more for everything to maturate and get all the features, all this for what ? For what seems to be a kernel-sided version of ALSA+dmix plus a really few features from Pulseaudio...

Seriously, didn't we already suffer enough because of all the transitions that already occured ? (oss->dmix (alsa)->ess/arts->pulse)

I agree the current situation of the Linux sound stack is quite complicated at the moment but how is something that will surely re-break everything for one more decade at the very least make things better in short/middle-term ? Are the *promised* benefits worth it ?
More importantly : Is it really the best approach ? How is moving more complex code into the kernel supposed to reduce latency and security issues ? I see it as relevant as moving a X (or Wayland) Window Compositor whithin the kernel -> absurd.

Could we please stop reinventing the wheel and focus on what could be improved instead ?

What's wrong with Pulseaudio ? It seems to be the most advanced and intelligently designed audio backend noadays, offering a great abstraction layer between apps and the hardware, the most flexible, configurable and most user-friendly, compatible with old backends (oss, arts, eds, alsa...), neat features (per app control/routing/network etc...) - but its reputation got quite ruined because of bugged ALSA drivers not supporting all its features.
It might not be perfect like any software but could be improved instead of rebreaking everything and supposing that the very complex audio processing will perform better and be simpler on the kernel-side....

[Bruners]

What's wrong with Pulseaudio ? It seems to be the most advanced and intelligently designed audio backend noadays, offering a great abstraction layer between apps and the hardware, the most flexible, configurable and most user-friendly, compatible with old backends (oss, arts, eds, alsa...), neat features (per app control/routing/network etc...) - but its reputation got quite ruined because of bugged ALSA drivers not supporting all its features.
It might not be perfect like any software but could be improved instead of rebreaking everything and supposing that the very complex audio processing will perform better and be simpler on the kernel-side....

Last time i tested it (the release of v1.0) i had alsa+pulseaudio running for about a week and it was horrible.
I had hourly episodes of Pulseaudio crashing silently in the background for no reason,
the quality and punch in the sound when playing music was gone and i could hear a small but audible hissing noise from the hardware.

After that week i went back to OSSv4 and still haven't had any major issues since i first tried it.
The only issue, which haven't actually been an issue except, is finding apps that can use OSS/OSSv4 or even alsa with emulation instead of only pulseaudio.

[droste]

So instead of fixing the remaining problems with pulseaudio (which works fine for many people) one should start creating a new audio system, where other people will have problems with (I doubt it will be bug free for all people from day 1 on)?

It's a shame that people that have a fixed audio setup (two speakers, nothing else?) don't see that with pulseaudio the linux audio system is actually usable the first time. I used to boot back into windows to watch movies and not because of video acceleration, but because of audio problems with surround sound setup or to be able to switch the sound to a tv connected via HDMI.