OSS is dead. Mixing in the kernel space is a bad idea, no power management, no Bluetooh, no USB audio and no modern application supporting it. OK, it has active development, but it was forgotten.
Why? This is your own opinion. Many developers actually think kernel mixing has less latency, leads to simpler implementation and allows smarter scheduling. Power management can still be implemented, OSS4 hasn't that feature in Linux
, simply because they didn't think OSS would have been adopted there, and they were right. Also most of OSS deadness
is related to its old Linux implementation, which was horrible and rightfully criticized and deprecated.
As explained here:
https://en.wikipedia.org/wiki/Open_Soun ... on_to_ALSA
(Doing "mixing" in kernel space (drivers) is evil)
In PulseAudio we have independent volume control per-application, switches on-the-fly between multiple outputs, better power consumption.
ALSA is onlye a sound architecture (Advanced Linux Sound Archtecture). Its function is working with the drivers and the kernel, but it's not intended for replacing a sound server or doing sound mixing. In the past, we had ESD and aRts because of this.
Latency: really, I didn't understand why. For general use, I don't see any problems with the latency. Low latency is only for the pros, and for this purpose, we have JACK.
Also, PulseAudio can be used by default by a lot of applications: KDE SC, GNOME, Skype, Steam, OpenAL...
I meant that the desktop oriented features, like per application volume and on the fly audio output switch, could be easily implemented with ALSA, or with external ALSA shared libraries, in a simpler fashion, having a single well focused project. Network audio streaming could be achieved much better with a dedicated multimedia oriented daemon, and there are lots of them. Such approach would lead to a more modular and more rational organization, that PulseAudio doesn't have in my opinion. PulseAudio actually does a lot of behind the scenes work to try to minimize its latency, in a way similar to Windows Vista, this makes it quite resource hungry with its memory, some applications (especially games and multimedia oriented applications) don't need that extra work and would be more efficient without it, since they already perform some kind of latency minimization (like game engines for example).
Look at a startup shell script and look at this:
Code: Select all
Description=CUPS Printing Service
Well, at this time, for example, Fedora and Arch don't invoke any shell scripts to start daemons. Other distros with systemd are doing the same (eg: Mageia 3)
In the startup, shell scripts are very fragile. A shell script for Gentoo won't work with Debian. In comparision, systemd units can be distributed by upstream mantainers.
Actually ArchLinux does exactly that, invoking shell script for many services, for example cpupower
. Anyway I didn't say it's better, I said it is debatable, you might want that or you might trade off some simplicity over flexibility. I meant that implementing many of the systemd
features is just a matter of implementing them, sysV style scripts aren't really a problem for that.
Actually there is even a standard for init scripts:
http://refspecs.linuxfoundation.org/LSB ... sinit.html
Agreeing to a standard for init scripts would make them portable, unfortunately, despite the existence of such standard, many sysV like init systems don't conform (I think even OpenRC dependencies aren't LSB standard).
Well, it is a bug dated: 2011-11-26, I actually use rc_parallel on a daily basis, and I have /etc/init.d/modules active and working, also in that report you can read:
Christian Ruppert wrote:
(In reply to comment #32)
> I think that the parallel feature is one of the indicator of healthy init
> layout implementation.
> A lot of effort was invested in making it happen.
> Giving it up is not the solution.
We're not going to give it up of course!
Maybe you don't, this is your opinion, in that video he states exactly my point "We are not the X consortium" and that X wasn't updated, but just patched up, for centuries
Maybe if they refined and updated X11, instead of endlessly working around it, it could have been better, but they didn't, so Wayland is born, which isn't a bad thing, this still doesn't explain Mir