Seriously, Craig, I'm a bit disappointed that you didn't stop to ask members of this perceived conspiracy how to disable PulseAudio before flaming away, but as you say, it is most definitely your "right" to flame away. And, as Jordan mentioned in your blog post's comments, it was (and is) hardly MOTU's decision to tie PulseAudio more tightly into the GNOME desktop. That decision was upstream GNOME's. Not Ubuntu's. Not Fedora's. Not openSUSE's. Not Gentoo's. Not Debian's. Not Mandriva's.
In other words, it would take a non-trivial amount of work to remove the PulseAudio dependency from GNOME, and then Ubuntu would get to carry the delta *and* respond to defect reports.
Let's put this in perspective: there are two people working on audio in Ubuntu. One of them is employed by Canonical, and he isn't 100% time on audio. The other one cares enough to trawl through vitriol and drivel to respond to requests, demands, rants, and apathy -- on his lunch breaks and spare time -- to unbreak a resounding mess. If it's insufficiently clear, you're preaching to the choir, and your ultimatum is pathetically misdirected.
Now let's be constructive:
Firstly, PulseAudio *can* be made to go away in Karmic. I've written about it before, but I guess the naysayers are too busy flailing about how much PA sucks. Some caveats with the approach given: you'll need to use one of alsamixer, amixer (both command line tools shipped by default in the alsa-utils package), alsamixer-gui, aumix, and so on. You'll lose live per-application (per-stream) migration. You'll lose per-application volumes. And you'll lose other things, but they're hardly consequential enough to list here.
Secondly, the loss of system sounds is not a PulseAudio issue. It's a window manager issue. There's even a defect report about it.
Thirdly, PulseAudio *has* to use ALSA. PulseAudio is not a replacement for ALSA and never will be, because one of ALSA's primary functions is enable hardware. It's a sound driver. PulseAudio is not a sound driver; it's a program that uses sound drivers. If you're expecting PulseAudio to replace ALSA, go ahead and throw that idea out the window.
Fourthly, where are your defect reports for PulseAudio and ALSA in Karmic?
Lastly, no one is forcing you to upgrade to the latest Ubuntu hotness. Some people still use Dapper; others, Hardy. A great many people don't use Ubuntu at all. If you don't enjoy Ubuntu's direction, why not attend the Lucid developer summit and work with people there to resolve some issues?
My use case:
ReplyDeleteMy sound was working great in Jaunty, upgraded to Karmic, and hey, someone changed the default latency of PA for whatever reason, now any app that uses alsa just chokes and gets no sound.
Who changed, why, what, where, how can I revert it - I have no idea. But so far, I've been having more success cooperating with developers of closed-source, commercial products than the 2 people working on *sound*, which is equally important to video, of the largest linux distribution.
Ubuntu has applied 0 (zero, zilch, none, nada) patches changing the default latency of PA. I recommend you take this battle upstream instead of shooting yourself in the foot by blaming Luke or me.
ReplyDeleteDan,
ReplyDeleteVadim did not mention it was someone from Ubuntu, he is asking who/why it was done. Please stop the blame game. Since you are one of the unbutu-audio guys why don't you try just to clarify his problem ?
The objective is to have proper sound working, your reply seems like audio on Ubuntu is on some kind of warzone, if there is a warzone the users are the victims.
João, from the perspective of the audio stack, Ubuntu has not diverged from upstream. I have yet to see a useful bug report emerge from this buffoonery, which makes me sad, since I, too, would rather fix the real culprit than engage in this silly call-and-response over "Ubuntu developers deliberately sabotage my user experience".
ReplyDeleteNever forget that I, too, am a user. The only difference is that I would rather fix problems than sit back and complain about them.
Not to hijack the PulseAudio subject, but on the topic of Ubuntu and audio specific changes I was surprised to find the audio in my laptop (running Ubuntu fine sine Gutsy) in a terrible state of crackling and popping after upgrading to Karmic, basically making it unusable (muting wouldn't help)
ReplyDeleteIt was related to this change:
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-May/008239.html
Which given that it was suspected would cause regressions was disappointing to see it not followed up and was included in the release. I suspect people affected did not report enough feedback during the alpha/beta stages but there are bugs reported during alpha on Launchpad still open:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/395208
Not to have a go at all, but it does seem a lot of changes in Ubuntu lately are quite experimental and more regressions are slipping in.
somewhat, I called for testing way back during the 9.04 development cycle and decided based on utter lack of feedback from anyone that it was hasty to enable power-saving, because *none* of the HDA codecs had decent support. For 9.10, at least the IDT/Sigmatel ones have decent support. For 10.04, if it's a major issue, i.e., at least the Realtek codecs being fixed, then rest assured it very likely will be reverted.
ReplyDeleteAlso, sadly, no amount of calling for testing will pull in the regression reports.
Dan, thanks for the response. Just to clarify (in case I'm a bit confused, highly possible...) it was deemed not a good idea to enable for 9.04 due to lack of testing and the understanding that HDA didn't really support it, but despite that it was then enabled in 9.10 because "IDT/Sigmatel ones have decent support"?
ReplyDeleteI'd like to think compatibility for the wider hardware base would take precedence over some experimental power savings for specific chipsets. This wasn't a minor issue on my laptop, it made it unusable (very loud pops every 10 secs) until I found the workaround in the previous bug report. Perhaps I over estimate the effect this had, as I only found a small amount of references to it on Launchpad and the forums.
Daniel, pushing changes with an high risk of refression into a releasse without having prior significant test is a very poor quality pratice.
ReplyDeleteDo you expect that such a process will enforce the frustrated users after a broken upgrade experience to help you identify the problems instead of complaining.
The "We didn't broke it, it was You which didn't tested" is not a very friendly attitude either.
somewhat, João, it was enabled precisely because IDT/Sigmatel make up a significant and nontrivial portion of HDA codecs. And, like I mentioned, it isn't "you didn't test it"; it's "we need lots of regression reports so this can be fixed across all platforms - not just Ubuntu".
ReplyDeleteObviously this is an unpopular stance, but:
1) I'm tired of no one taking responsibility to fix things in the long run. Fixing things in the long run means short-term breakage.
2) Yes, it's clearly my fault that this regression shipped in 9.10. It was not communicated clearly that 9.10 was a testbed for 10.04, and I'm certainly not the only one who has noted as much.
3) 10.04 will have this change reverted if at least the Realtek code isn't up to snuff.
Lastly, the impact is known: I have written before how to revert the change.
Hm,
ReplyDeleteI feel sorry for Dan here.
Craig's post was incredibly finger-pointing, extremely rantish, and almost downright offensive.
He didn't even bother to figure out how PulseAudio could be removed like he originally wanted, and that his 'choice' was never actually removed. That's a pretty unproductive way of interacting with his community.
If he wants all the benefits without having to deal with the change involved, he should be sticking with LTS releases.
Dan, my audio works pretty beautifully, so, thank you for all the hard work you've invested improving my experience. Some people do appreciate it.
Thanks
yeah, I certainly don't intend this as a "gang up on Dan" forum, it's just good to get to hear some rationalisation from the source of why things like this are done in Ubuntu.
ReplyDeleteI fully agree with needing to move forward, sometimes at a cost, but I don't necessarily agree that purposely breaking sound for some people is the best thing to do in a final release, especially without it mentioned in the release notes (apologies if it was, I don't religiously read them).
There def needs to be more communication to the users about the supposed beta status the non-LTS releases seem to be carrying now, discussion on the ubuntu-dev mailing list doesn't necessarily filter out. For me personally I'm happy with this kind of thing, but I don't think it's very good for Ubuntu's supposed target audience (everyone...) I like what Fedora has done and clarified it's more for technically minded users and pushing out changes knowing it's userbase kinda expects some hurt but are happy dealing with it. Just feel Ubuntu releases aren't the best platform for this kind of experimentation as all the noise with the recent release shows.
If you do need any testing/feedback on this chipset, please don't hesitate to ping me, keen to help out if I can.
cheers
I still find it funny that Craig has yet to actually respond to your requests for more information and considers having it pointed out that his original pointless rant about "I configured PulseAudio to do the wrong thing, and it did so, thus it is broken" was...well...pointless ranting...to be "flaming."
ReplyDeleteExecutive summary:
ReplyDeleteAll of the following, although cool in some ways, also suck in ways that give me trouble:
1. The ALSA ice1712 driver.
2. ALSA (most drivers rock, most APIs suck).
3. People who flame about how Ubuntu should dump PulseAudio.
4. The configuration files Ubuntu ships with PulseAudio.
Discussion:
I have an ice1712-based sound card, it happens to be an M-Audio Delta 1010LT. On my current desktop computer, it does fine at getting the audio bits in and out (though on another computer, it sucked at that too). But an ALSA hardware driver is also responsible for generating a sensible description of features, controls, and capabilities of the hardware to enable the rest of the audio stack (hardware-independent parts of ALSA, adapter layers like Pulse and Jack, and application programs) to use the sound card without needing additional knowledge about the card, such as special configuration files or hard-coded special handling base on the card type. At this responsibility the isc1712 driver fails spectacularly. The result is that the ice1712-based sound cards work great with a few specialized applications, but are useless with anything else unless an adapter layer is used and configured to work around the goofiness of the isc1712 driver.
PulseAudio would be a good solution for this problem, but in Ubuntu, year after year it ends up looking like part of the problem instead, because release after release, Ubuntu ships broken PulseAudio configuration files even though much better configuration files have been available for years (see launchpad bug #178442 and its 118 and counting comments). It really doesn't help that Pulse Audio haters keep demanding that Pulse be whacked when it could much more easily be fixed.