Yeah, and honestly the setup in early versions was horrible. I tried so many times to make it work and gave up in the end. They shouldn't have released it so early back then when it was obviously not production ready.
I have heard that most of the trouble everyone had with PulseAudio had less to do with PulseAudio itself and more to do with terrible audio drivers that did all sorts of awful things when commanded to do relatively basic tasks by anything more complicated than Alsa.
Not for me. ALSA was fantastic for me, I had custom routing set up with LADSPA processing, very low latency, and multi-stream mixing. Pulse doesn't do nearly as much for me.
At least one of the PulseAudio features that's enabled by default - flat volumes - also expects audio hardware to behave in ways that wasn't in any spec and in some cases probably wasn't even physically possible, and even on hardware that behaves perfectly it causes annoying volume glitches all the time.
Why does PulseAudio have anything to do with Ubuntu? AFAIK, there is no relation between the two, other than the fact that Ubuntu offers PulseAudio (along with almost every other distro).
I must admit that, more than once, an Ubuntu upgrade killed my audio and I had to go and fix it myself. It's really painful that a distro that wants to be number 1 is so broken at times.
I don't think it's more that they push non-prod ready packages (yes, they do) but the fact that their update model doesn't easily allow them to fix bugs from upstream.
The vast majority of the packages in Ubuntu (more notably in the LTS releases) are all custom patched by Ubu-devs. Rather than taking the raw package and pushing it through, they have a semi-opaque method of testing, patching, and then releasing to the greater community.
I've tried several times to get an 'in' so that I could help with the process, but it seems to me like a 'club hangout' where outsiders are slightly discouraged. :(
> I've tried several times to get an 'in' so that I could help with the process, but it seems to me like a 'club hangout' where outsiders are slightly discouraged. :(
I think this is an unfortunate perception. There's an active sponsorship queue, and nominated people run shifts to review and accept outside contributions. All contributors need to do is submit a suitable diff, and subscribe the sponsorship team to the bug. See https://wiki.ubuntu.com/SponsorshipProcess for details.
If you are willing, please help!
Where outside contributions tend to fall down (IMHO) is understanding and thus compliance with existing processes. For example, outside contributors tend (again, IMHO) to underestimate the consequence of regression in stable releases. Or they contribute patches that should really go upstream, and underestimate the extra overhead and community harm of independently maintaining these patches just in Ubuntu.
> Rather than taking the raw package and pushing it through...
Where upstreams have sufficient QA and release process to sufficiently minimize the regression risk to existing users of a stable release, an exception can be granted so that the updates can just be pushed through: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExc...
I suppose I misspoke- I wouldn't say it's discouraged, but as another comment said; it's painfully bureaucratic- it's almost too difficult for an 'average joe' developer to hop in and help patch/test their own software.
I'll share my story:
I help maintain a 3,000+ node Puppet config for a school district, running Ubuntu 12.04 on various laptops/desktops. Part of our config used XFCE's weather widget on a panel.
A few months back, the widget stopped working, as the API's url had changed. I had tracked down the issue independently, and even found that newer versions were released for 13.10+, but alas- no backport for 12.04.
I tried to investigate how to test and sponsor the package to get it backported for the LTS, but after nearly a day's worth of digging, I gave up.
Conversely, on my Arch tech station, the XFCE widget was updated many times in between, with many bugfixes and other updates.
> The reason is the risk of regression.
I can appreciate it. It makes sense that one would want the software to be as tested and stable as possible.
However, it seems a bit disingenuous to me that the developers of the various software packages are not the 'final say' in the development.
Sure, the patches might only affect a specific version of Ubuntu, but as a Developer- I would prefer to fix the issues myself.
I hope that makes sense- I'm not trying to paint Ubuntu's update method in a poor light, I just can't quite grasp the full scope of why it's done that way.
Two things: one, the quality of "developer released" packages varies wildly, so it's hard to make a global policy. Two, a distro means integrating many packages. An upstream package change might be 100% reasonable and at the same time break existing users because (e.g.) of a feature removal that went through a normal deprecation policy for that package, that distro users are obviously not aware of.
Ubuntu is supposed to integrate and add a QA layer on top of upstream packages. Just pushing any so-called stable release of upstream packages isn't going to improve the situation, even if it might in specific cases.
Personally, I don't see a way out. The very fact that a distro is an agglomeration of independently released packages means that there will be breakages like the ones you describe, because every package has its own concept of stable release, development cycle, feature deprecation, old version support, and so on.
In the case of PulseAudio, there are no stable upstream releases, so distros basically have to backport fixes themselves in order to get working audio. Red Hat (who fund most of the development) do the same. New upstream versions come with new features and can be expected to break as many things as they fix.
My impression wasn't so much "opaque" as it was "dreadfully, soul-suckingly bureaucratic". It's been a long time since I looked, so this may have improved since, but it was really hard to figure out what the first step towards helping with packaging is (aside from the triage/testing side).
We release a new version of an operating system that is used by millions of users around the world - twice a year. So there's definitely some rules to ensured quality. And if anything end-users want more quality, as seen from some of the complaints about bugs in this thread!
So there's definitely a community and it takes time to learn the rules. But there's lots of ways to get involved and if you take the time to understand the issues and then have ideas on how to improve the processes you'll be listened to - Ubuntu is ultimately a community.
Ubuntu pushed pulse before it was production ready -- I like that they did that, because it accelerated the production-readiness of a great idea with buggy implementation, and I'm using debian where stability matters anyway :P
