Originally posted by unix_epoch
View Post
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.
Comment