PulseAudio 7.0 Released, Adds More Flexible Jack Detection

[phoronix]

Phoronix: PulseAudio 7.0 Released, Adds More Flexible Jack Detection

PulseAudio 7.0 was released today as the once-controversial open-source sound server common to Linux systems...

http://www.phoronix.com/scan.php?page=news_item&px=PulseAudio-7.0-Released

[mdias]

Everyone get into your shelters, the haters are comming! </bait>

[Aeder]

"sysnthesis" should be synthesis

[BradN]

Everyone get into your shelters, the haters are comming! </bait>

I don't know, it was a bit wacky when it first came out, but I got better things to do than hate on something that makes networked sound streaming work on my LTSP X terminal.

[Daktyl198]

I think PulseAudio needs to be rewritten, but not completely. Most of it is pretty okay (though there's obviously technical problems that people have with it all the time), but I think it should not use ALSA as a backend, and instead plug directly into the lower-level stuff itself. I also think there should be ALSA emulation available in Pulse so that you can remove ALSA from your system and Pulse could take care of any application that requires ALSA and refuses to deal with Pulse.

This would dramatically simplify the audio system in Pulse distros, remove any ALSA bugs from possibly appearing when using Pulse, and remove any ALSA<>Pulse bugs as well.

[geearf]

Unless I am misunderstanding your point, there already is an ALSA "emulation" for apps that don't care about PA.
As for the " remove any ALSA<>Pulse bugs", you would do that, but introduce "Kernel<>Pulse bugs" instead, I'm not sure if the tradeoff would be worth it.
Also wouldn't removing ALSA lose us all the current soundcard drivers? That sounds like a pain.

[Delgarde]

I think it should not use ALSA as a backend, and instead plug directly into the lower-level stuff itself.

Given that ALSA includes the *drivers*, there is no lower-level stuff to plug into. Are you suggesting PA should start doing actual low-level hardware support too?

[magika]

Given that ALSA includes the *drivers*, there is no lower-level stuff to plug into. Are you suggesting PA should start doing actual low-level hardware support too?

I get both of you, but I'm with Daktyl198 here. As most of the sane developers link only to alsa, PA is being used as a emulated card in ALSA, why would I need middleman HW-ALSA-PA-user if a real card and ALSA can do the most of the jobs (HW-ALSA-user).

[Daktyl198]

I just don't see the point of having two audio systems (one of which is completely barebones, and the other which depends on the first). It makes everything way more complicated than it should be and probably introduces more bugs than it helps in the ease-of-development.

It doesn't have to be pulse, but I say we pick one audio system for general desktop usage and develop that with the features we need for desktops specifically (adding Pulse-like features to ALSA is also an option). Also, why the fuck are drivers built into the audio (sub?)system instead of merely being accessed by it... I don't understand. It sounds like me adding video drivers to a gstreamer, which obviously doesn't make sense.

[mdias]

I just don't see the point of having two audio systems (one of which is completely barebones, and the other which depends on the first). It makes everything way more complicated than it should be and probably introduces more bugs than it helps in the ease-of-development.

It doesn't have to be pulse, but I say we pick one audio system for general desktop usage and develop that with the features we need for desktops specifically (adding Pulse-like features to ALSA is also an option). Also, why the fuck are drivers built into the audio (sub?)system instead of merely being accessed by it... I don't understand. It sounds like me adding video drivers to a gstreamer, which obviously doesn't make sense.

I am not an expert on the ALSA architecture but this is what I believe:

ALSA has kernel components (the drivers) that expose a generic API for user space libraries to communicate with. It also has a user-space library that provides a higher level API that applications can use.

I think PulseAudio (user-space) interacts with ALSA (kernel-space) API directly, and re-implements the ALSA user-space higher level API to go through PA, so that alsa-only apps continue to work as expected. However this higher level API doesn't always a 1:1 equivalent on the PA API, and therefore some apps behave erroneously.