On Tue, 30.06.09 11:58, Valent Turkovic (valent.turkovic at gmail.com) wrote: > segedunum said... > "You know, I really, really worry about Lennart more than any > developer I have yet seen. Once again he goes on the offensive but > addresses nothing of what is written in the article. He keeps posting > back to that rather inadequate article he did about the state of audio > on Linux where he bludgeons the need for PulseAudio in. I cannot > believe the mental gymnastics people go to to justify it, and no, per > application volumes and mixing is not enough. So, you are asking me to respond to this? This is just fud, or uninformed at best. Also, I am not sure which article he actually speaks of. It can only be this one: http://0pointer.de/blog/projects/guide-to-sound-apis.html But that has nothing to do with the "state" of audio. It's just a onverview over the current APIs. The guy who wrote this says I am "bludgeoning" in the need for PA into that. Which is just not true. It is prety clear from my article actually that only for the fewest cases it is really good idea right now to link directly to PA, everything else should be done with other APIs. (only mixers should be linked directly against PA, nothing else). I tried to be a nice guy, and made the dependencies on PA only very very soft in the audio stack. It is very easy to rip it out, if you don't like it. You can switch to another backend in Gst, in libcanberra, all over the place, and PA is gone. I designed it that way in an attempt to satisfy the folks who think PA is an abomination. But of course, this was a pointless excercise, people who want to complain, just complain anyway, regardless how all of this is handled. Also words like "mental gymnastics" certainly don't help to make this sound like a particular fair comment. If you think that PA is a good idea, then use it. If you don't, then don't, but please don't constantly complain if others do. I am not forcing anything on anyone. I made it particularly easy to rip it out if you think I am evil and my code is too. And this is Free Software. So you get my stuff for free, and you have the complete freedom what to do with it. Also, mixing/per-stream volumes is certainly not what PA is about. Try googling for why it actually is good. The biggest benefit still is the gitch-free playback mode, even though that might not be directly visible or even understandable by the users. > It is totally obvious if you look at the architecture that if you put > in layers between the application and the sound card you will add > latency. Jack at least seems to have been made with a particular use > case and set of benchmarks in mind. When it does processing as Pulse > does, as well as various other things Lennart deemed necessary, then > it will add *a lot* of latency and even worse the latency will not be > predictable at all. You have to be incredibly stupid or totally blind > not to understand that. Having been through the experience I will > *never* make a Skype call with Pulse in the middle ever again. This is just so wrong. Of course every layer you put into your stack makes things a bit slower. But "*a lot*" is certainly wrong. A context switch or two is slower than no context switch, but it is still in the ns range, and completely irrelevant on the desktop. In fact PA is much more flexible with latency and fulfilling what applications ask for than any other system, because we schedule audio by system timers instead of sound card timers. Much like PA, JACK also requires a couple of context switches before the data from the apps are written to the hw playback buffer. So in this respect there isn't much of a difference. In fact, since PA actually does zero-copy data transfer via SHM, and by never having to convert/copy/touch the PCM data the cache pressure and CPU load of PA can be considerably lower than JACK's. And the usual Skype "argument" doesn't cut it. Skype is closed source, it hasn't done a release for Linux in years. I cannot fix it, and it is seriously broken in many ways, and the vendor doesn't care. The right place to complain is skype, not PA. > In addition, we've got all sorts of silly side-issues such as how > one volume slider should be enough for anyone in Fedora. Want to > adjust any other volume levels, and heaven forbid, line-in? > Tough. It's not a use case for Lennart. Keep in mind that there's > nothing unusual in this. That's all we're talking about here. Using > the volume controls you have always been able to use on any system: PA is happy to record from the Line-In. However, driving one sepaker set with two PCs is exotic. And I am not planning to support that. If you want to, then bypass PA and use a low-level alsamixer. There's nothing wrong with that. The guy who wrote this seems to suggest I was taking away his freedom by not designing my stuff so that driving one speaker set with two PCs is just one click away. But that's just nonsense. The full ALSA mixer is here to stay. You will always be able to install some ALSA mixer and control input feedback if you feel the need for it. However, I really see no reason to expose this in the UI by default, because stuff like *driving one speaker set from two PCs* is NOT A STANDARD USE CASE. Make the common things easy, and the uncommon things possible. Which is what I am doing. And the other "arguments" usually raised when folks talk about the mixer are even more exotic. e.g. supporting the "analog path" for CD audio playback. Which is completely obsolete, and we don't even ship any application on Fedora by default that could still do that. --- Please don't forward comments like these anymore on the ML. If I'd respond to everyone posting comments on PA I couldn't do anything useful anymore. I have no problem with not having convinced everyone of PA. As long as I managed to convince the technical folks who build today's operating systems I am happy. Also, the information why PA is useful is out there already. You can find it with Google, I don't need to repeat myself every second day. All discussins have already been had. About the mixer situation just read on fedora-devel. On the benefits of PA we had a couple of discussions on GNOME's desktop-devel a while back. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
