There is some hatred for ALSA from some, but I think what the haters are really saying is they hate the quality of functionality provided by ALSA, not necessarily the API itself.
Originally Posted by unix_epoch
At the end of the day all anyone wants is their audio hardware to function correctly with the software they want to run. When using ALSA in the past, aside from any specific implementation problems such as driver bugs or bugs in higher level parts of ALSA, quite often an end user was required to hand edit config files in order to access certain functionality not to mention the debacle that was using bluetooth devices with ALSA.
I haven't yet been shown why the functionality provided by PulseAudio couldn't have been integrated into the ALSA stack directly as extensions to an already implemented standard, and if it could have would likely have caused a lot less pain than what was experienced in the shift to Pulse for various multimedia apps.
When it works, and dis-regarding implementation bugs in apps or Pulse as well as low-latency requirements for the moment, PulseAudio over ALSA seems to cover a lot of the use cases an end-user may have for a desktop environment, and I feel it would be a huge mistake to dump Pulse for some other, untested new and shiny thing that would only stall the path to a finished audio stack.
I will explain why I made the diagram that way:
- It's not an advertisement for PA. On a modern Linux system, this is how the situation is. You can still target any layer directly (except the hardware).
- I only displayed the arrows that went between adjacent layers, and not from or to deprecated APIs. If you want I can enable all the arrows, but that doesn't make it any clearer.
- OSS is deprecated, so that removed a lot of lines too.
- I only used the entities that were used in the original diagram. Obviously there are thousands of audio libraries. That doesn't make it messy though. It just makes it hard to fit into that upper layer.
Edit: The absence of Jack->ALSA is an oversight though.
What's the end result like for a Pulse->Jack->ALSA setup?
Originally Posted by Remco
Does this satisfactorily solve what some people are after, a Pulse layer for normal latency requirements from desktop apps, and a low-latency environment for audio editing apps without the need to be killing processes to switch from one to the other?
To speak to the issues with the Flash player Linux team, I too believe they're trying to completely over state the amount of complexity they actually need to deal with in order to mask their inability to provide a quality product. I wonder what special magical requirements they have in the audio area to go with the magical mystical special requirements they have in the video pipeline.
Sounds interesting. I'm no Linux audio expert though. Maybe JACK brings other problems. There must be a reason why a realtime kernel isn't default. Probably impacts kernel performance.
Originally Posted by mugginz
First, OSS is not deprecated. Unless you mean the version in the kernel. That one is deprecated of course. But people use a modern OSS version, not the ancient in-kernel one. People seem to forget that ALSA is not a cross-platform API. It's Linux-only (I thought Linux folks hated non-portable stuff). Unix in general uses OSS, so it's still relevant.
Second, ALSA is hated by developers because of it's brain damaged API. It provides thousands (literally) of routines. That has to be the most bloated and unnecessary sound API ever created by humans. Looking at it makes one reconsider all those conspiracy theories of M$ people infiltrating Linux kernel development and putting crap in it in order to hurt its popularity by desktop/multimedia users.
Third, ALSA's OSS emulation is not worse that it's native mode. Someone here claimed that this emulation has latency issues. The exact opposite is actually happening; ALSA has very high latencies in "ALSA mode", while the OSS emulation is very low latency. And I'm not talking here about latency that would be required only for arcane real time stuff: ALSA is *lagging* like crap compared to MS Windows or... OSS. But the most hated thing about ALSA is it's API that doesn't even work. Putting ALSA support in everything else than a "hello world" sound application is going to be a pain in the butt of every developer out there. It wasn't too long ago that the majority of applications out there said "OSS recommended" in their README files.
I don't see such a claim here. If you're talking about my post, I was listing general problems that people have run into when trying to run OSS apps on ALSA-based systems (including those caused by sound servers), not just problems with ALSA's OSS emulation specifically.
Originally Posted by RealNC
Actually that isn't really true. PulseAudio isn't really a requirement for KDE systems and is optional. openSUSE for example removed it from the default install on KDE desktops. Them having done that issues with audio dropped drastically from the versions that had it installed by default.
Originally Posted by Remco
Kubuntu also doesn't install it as a default but when it's time to use bluetooth headsets installing Pulse is about the only way to go.
Originally Posted by deanjo
/offtopic: i'm now a happy OSSv4 user since i tested it a while ago, i love to listen to glitch free music with MPD, while i don't have anything against ALSA per se, i can't be happy with skipping music when my CPU is at 50% or when i copy some files from a partition to another
oh, and this ( need for ALSA ) situation was created by 4 Front when they decided to stop support those kernel drivers so i kinda hate them for that but love them for what OSSv4 is now ( a viable alternative to my ALSA gripes )
/ontopic: my post on the Adobe blog showed up eventualy, what i don't understand is how is that the Flash team talks with nVidia Windows team only while the nVidia Linux and VDPAU teams are getting blamed for Flash issues ? baffling
Tags for this Thread