Hello once again. As an opener to your mail I will point out that at no point to you refer to any of the technical reasons as to why PA adoption is a good thing. All you do is point out the fact that you've had a few problems (and as someone at the front line of PA support and distro roll out, I can certainly say you've had many more problems than most users and I sympathise with that). 'Twas brillig, and Markus Rechberger at 21/12/09 00:14 did gyre and gimble: > I was using PA for around 1 1/2 years now. My feedback: > 1. I asked for some help which worked out fine at the beginning > 2. problems grew and are still growing .. I'd still get some help but > I just want to have my stuff work and I'm not interested in playing > debugger with Ubuntu anymore. Well sadly without feedback for bugs there is very little we can do to improve the situation. You quite frequently pop by on #pulseaudio IRC and basically dish out rhetoric about xyz being broken. I don't doubt you for a second, but all the times I've asked you for test cases, debug output coredumps and backtraces you've just ignored the request and carried on complaining (in fairness there is one "test case" on the mailing list you posted but it's just code snippets, not a running app, so I'll have to find time to code it up into an app to test it). I don't want to be rude, but without proper feedback, complaining and moaning does precisely nothing - other than generally annoy the people who give up their own time to try and help you (which IIRC is a commercial endevour - so people are quite literally giving up their personal time to help you and your company do well - please keep this in mind!) > 3. We use to sell devices which are supposed to play back some Audio. > It was a nightmare to add proper support for it! (we got alot negative > feedback from customers regarding audio - it now works but other > issues are still remaining). > > 4. I use Skype-out with my notebook, finally I thought everything is > working BUT .. no. People I called complained about the audio quality. > 5. simply running apt-get remove pulseaudio -- hey it solved all the > issues I had? How comes? Alsa is working fine? I've said this to you many times before, but here is the situation: 1. PA is an invasive technology. By it's nature a *lot* of things change and there are obviously areas where bugs will be introduced. This situation is needed from time to time and yes it's a pain, but such is life. More people using it means more bug reports and faster fixes. 2. PA is using a very new part of the ALSA API that not all drivers have proper support for. This area has been overhauled significantly in the last year or so and many fixes and implementation of the necessary logic has followed. Comparing this new part of ALSA to the old ALSA is invalid. PA now gets the defacto blame for the bugs in this code, because "aptget remove pulseaudio" makes everything "work", but that's not to say the problem is always at PA's door. 3. ALSA is very flexible but it has several quirks. The API is very complex and due to the organic nature of it's evolution. Some time ago Lennart wrote the guide to audio APIs[1] which (I believe) coined the phrase "Safe ALSA Subset" which basically spelled out which parts of the ALSA API app developers should limit themselves to in order to create portable code. This guide doesn't just apply to PA, but it certainly affects PA hardest as it's probably the most prolific use case for the ioplug system in ALSA in which the ALSA->Pulse compatibility layer relies. So add the above problems together and add in the obvious possibility of bugs in PA itself, sensitivity to kernel options regarding scheduling and latency and you get more or less the perfect storm for potential bugs. Add to this some pretty poor adoption strategies at the distro rollout end and you've got yourself a hotpot of issues showing up. It's certainly not an ideal situation, but it's totally unfair to level all the problems squarely at PA's door. Maybe rollout could have been handled better, maybe distros switched too early, maybe. But as with quite literally *every* project, users will complain that it's "too early" etc. etc. There is a massive expectation that users have that things should be tested to the n'th degree and viciously QA'ed before release - this does happen but it's certainly not on the same scale as a commercial product - this is Free software and with Free software we need wider QA and testing feedback from the general populace in order to drive the development. So as with all new things (KDE 4, Amarok 2, PulseAudio, Firefox 3 etc. etc.) you'll get a backlash from users expecting everything to be hunky dory on day 0. That is an unrealistic expectation from this type of development IMO. As anyone involved with Linux audio will testify, we need something with the featureset that PA offers to take us through to the next level - ALSA on it's own is not enough (without significant re-engineering). I have written myself about this in the past several times[2] with regard to the actual need of a modern, multiuser desktop system. > So what is the idea behind pulseaudio? > Also pulseaudio breaks the alsa support (eg. if root wants to access > audio it does not work root will get permission denied!) No it doesn't. Even tho' we discussed this until I was ready to explode, you still don't seem to understand the problem properly. 1. Root login via tty: audio works fine. 2. Root login via X: audio works fine. 3. Root login via su under X with PA running already: works fine (due to access to the root X11 window for cookie+socket information) The problem you have is that you want root to have audio at all times. I agree this is not supported by PA which implements a proper user-based access policy dictated by consolekit and does not deal with the root user getting access at all times. This is something not supported by the PA design. It would need rather a large rethink to support this, but it's likely not something that is going to get any focus for the short term - it's a rather niche use case for typical desktop computing even if it does affect users of e.g. mpd which is rather popular. > So how should this be solved now: > > Skype needs to work, the software is good even if it is closed source, > right now 11 Million people are signed up (according to the list, > don't know if skype fakes it or not) I've been working with the Skype dev who is implementing PA support to try and help get a good implementation. Skype works pretty good right now. I can make a call have it work on my internal laptop speakers, fumble about in my bag to find my BT headset, open it, have PA detects it perfectly, realises there are "phone" streams active and then moves them over to my headset. It's pretty damn good right now! This is how VoIP should work!! Things are not perfect. There are some UI issues to resolve to prevent unrealistic requests from users, and the AGC will probably not work perfectly for this release with PA, but I'm sure the next update will see that working again. > Personally I do not like pulseaudio, it never worked correctly (an > example with Ubuntu 9.10: http://sundtek.de/support/pulseaudio.wav .. > after killing pulseaudio it worked) Again, saying "after killing pulseaudio it worked" has little to no merit. The audio paths are completely different, it avoids about four different layers of potential issues. I'm not saying that there are no bugs in PA (of course there are), but we need proper metrics and bug reports to deal with problems, not "it sounds funny" or "it's broke" rhetoric. > Comments? My main comment is that you do not provide any technical arguments at all. You are just complaining because you hit some problems. Yes, this is annoying and frustrating, but you cannot simply abandon an architecture because of some bugs - you have to think about the components and mechanisms that make up that architecture and why it's there. I've writen about this in the past[2] so I wont regurgitate this information here, but if you care to use the points I raise and reasons I give for why some kind of userspace audio system is essential for a modern linux desktop and then argue either against my opinion or suggest an existing alternative or promise to write your own alternative then this discussion can become exactly that - a proper discussion. Not actually discussing any of the architecture in an email with this subject is certainly doomed to end up in the bit bucket. Col [1] http://0pointer.de/blog/projects/guide-to-sound-apis.html [2] http://colin.guthr.ie/2009/08/sound-on-linux-anti-fud-calm-certainty-and-confidence/ -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
