Adobe's Linux Video API Rant Extended

[Remco]

What's the end result like for a Pulse->Jack->ALSA setup?

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?

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.

[mugginz]

Edit: The absence of Jack->ALSA is an oversight though.

What's the end result like for a Pulse->Jack->ALSA setup?

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.

[Remco]

Edit: The absence of Jack->ALSA is an oversight though.

[Remco]

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.

[mugginz]

What's with the hatred toward ALSA?

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.

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.

[Ex-Cyber]

What's with the hatred toward ALSA? It's a decent low-level API on which someone could implement a user-friendly GUI.

I don't think most people hate ALSA per se, but rather that ALSA turned into a practical requirement when neither the in-kernel OSS emulation nor the major DEs' sound servers provided decent support for OSS apps (e.g. noticeable latency, only one OSS app at a time, requiring OSS apps to be launched with a wrapper program, etc.).

[unix_epoch]

What's with the hatred toward ALSA? It's a decent low-level API on which someone could implement a user-friendly GUI.

My main complaints with the current state of things:

PulseAudio and JACK are completely separate projects, so I have to kill pulse and start jackd when I want to have low-latency audio.

PulseAudio keeps screwing up the low-level mixer settings on my emu10k1 without exposing those settings through the GUI.

PulseAudio doesn't appear to take advantage of hardware mixing on cards that support it.

[mugginz]

Pulse is a great idea, just poorly implemented. Their efforts IMHO would have been better off put towards improving ALSA's weak points on a low level implementation

Must agree with you there. When I heard what they were doing with Pulse instead of fixing ALSA I was a bit disappointed but now we're here with respect to PulseAudio over ALSA as the chosen one, I guess I'm just hoping they will eventually correct the flaws in the current implementation and then maybe people can worry less about Linux audio and focus on areas that are yet to be solved.

[deanjo]

It's the feature set of PulseAudio I want, not necessarily the current implementation. If it is to be re-factored, it needs to be done in a digestible way that doesn't go and rebreak everything again. I think that would be the last straw for a lot of Linux users.

Pulse is a great idea, just poorly implemented. Their efforts IMHO would have been better off put towards improving ALSA's weak points on a low level implementation

[deanjo]

There's nothing wrong with *some* of the current API's (with ALSA being the ugly exception). Instead of re-inventing something again, you should whine about the broken implementations instead. For example, the OSS4 and PulseAudio APIs are just fine. Problem is, they're anything but rock-solid software. Instead of coming up with yet another API that looks sweet and nice but comes with a sucks-ass implementation of it, better fix what's there.

And somebody please kill ALSA. Thanks.

Well I have to respectfully disagree on you there, ALSA has been kind to me over the years where as OSS has not. Although I do admit that OSS has a simplicity about it development wise but once it starts to get into the advanced specific features of a card it leaves much to be desired.