I didn't save anything. I just helped out with maintenance and tried to rally the other developers already on board. Lennart's code and knowledge of the audio stuff far, far outweighs my own here. It was Lennart's dogged determination to carry on in the face of unhelpful criticism from the peanut gallery that helped get PulseAudio to its current state of relative stability - including the pushing and poking needed to get the other stuff in the stack fixed too.

Myself and other contributors (more so than me) had a big hand in this too, but credit where credit is due!

You can always try Mageia. There are several people working on both the GNOME and KDE side of things and you should be in very familiar territory if you have previously become accustomed to Mandriva.

It seems the wording is interesting. Of course they will give up the names if "Legally required" to do so. Otherwise they are breaking the law.... it's not a hard concept to understand.

That said the current action being taken against Twitter is basically just asking nicely. It would be a *lot* more complicated for that "asking nicely" to be come a legal requirement. It would require that a US court issues the request and thus cross continent legal corporation which is a) expensive and b) time consuming and c) subject to calif. priviacy laws. If things don't line up correctly, there will be no "legal requirement" and thus the names will not be given up.

That's my interpretation of it at any rate.

.... Sink and Source?

I think you're confused. Alt+SysRq+K is one of the Linux "Magic Keys" http://en.wikipedia.org/wiki/Magic_SysRq_key it kills all processes on the current VT, not just X. Most modern X implementations will still work with Ctrl+Alt+BkSp but you now need to do it twice and the first time it makes a rather ominous "beeeeeeeeeep" at you to warn you that you maybe about to make a bad decision....

So this is hardly an "Ubuntu decision" (like most distros they just package up what's already there, mix it up with a few good and a few bad ideas of their own and paint it nicely).

Well IMO both the Gnome and KDE flavours of Mandriva are very well put together, maintained and supported. I tend to jump between DEs (and run apps from both when running either too), and I can't say I've ever found either lacking!

Well no one is forcing users to upgrade! People can stick about for a while and see how it goes for others.

Also we just released Mandriva 2010.0 (release notes and Errata). The mirrors are currently syncing and the main download page is waiting for that to complete before offering direct downloads but the torrents are out now..

IMO Mandriva offers excellent Gnome and KDE flavours, so feel free to take the most appropriate "Mandriva One" live CD for a spin.

Yes consolekit is the bit to work on when dealing with multi-seat systems. Udev and consolekit very recently were changed to support seats a little better but there is more work needed in that area. Pulseaudio already integrates to consolekit, so using this system is the way to go.

In the mean time, if you have tow sounds cards (e.g. one for each of you) you can do a "poor mans" setup but each logging in once, and then being nice ot the other but loading pavucontrol and choosing the "Off" profile for the card not meant for you. This doesn't work if you swap seats tho', but for this kind of setup, I'm guessing that doesn't happen too often anyway. Like I say support in consolekit is coming.

NAS and ESD are both obsolete, so are no longer developed and should not be used.

PulseAudio does not have it's own SSH piggy back implementation like X11 but we do piggy back on to the X11 one. Really openssh needs to be refactored to make the X11 forwarding modular and we can then write a PulseAudio module for SSH so that it can all be done properly.

OSX support is also underway but it's done by those people who are interested and only two people are really interested right now, so the progress is a little slow, but getting there.

The routing policy you describe (when you see it, use it) is now implemented in PA git master with module-device-manager, although currently only a KDE gui for this is available (it's not the way Gnome want to work, but it is the way KDE want to work, so I accommodated that).

And the disto I do packaging for is certainly not backed by a wealthy individual. It just takes someone who actually cares to get the distro integration right, not money :)

Well straight away, you're trying to do some kind of specialist setup, which is always going to mean you're going to have to look into things firther.

Also, PulseAudio is not something that is generally targeted at end users, it's targeted at distros who have the experience and knowledge to tie together all of the components.

You are also the first and only person who has complained that PulseAudio offers (for the most part) a drop in replacement for pure alsa via the use of an alsa plugin. This is *only* way that pulse could get any kind of acceptance at all. It's not expected that applications should need to write direct pulseaudio support, they should go through some kind of abstraction library. For the most part, libasound can serve that role well, provided you stick to the Safe ALSA API Subset that has been documented.

If all you want is per-app volume control, then I don't think it's all worth it for you, but if you want a proper multi-user desktop experience, where the sound follows the *active* user, not the inactive one (i.e. a standard desktop), reduced power consumption, bluetooth support, Apple Airtunes support, UPnP support etc. then PulseAudio is the way to go.

But free software is about choice. If it's not right for you, that's fine, don't use it, but there's no need to bitch about it either.

Do you care to elaborate on which parts of the implementation "sucks"? Is it the client/server model? The fact it uses a fully asynchronous, zero-copy, lock free core? Or something else?

I'd be interested to have a technical discussion about this, but obviously I'd need to more more than the equivalent of playground banter: "girls smell". :p

Do I think pulse has a sane design? Yes I do for the most part, tho' I wont pretend to know it inside out.

The article you quote there (which was covered in /. before) has so many glaring errors I just don't know where to begin! If you're genuinely interested (and it sounds like you are), then I'd strongly recommend reading the comments on that thread, particularly the ones made by "dawhead" who I believe is actually Paul Davis who wrote Jack and Ardour and is about as much of an expert as you'd want on this stuff. He shows the patience of a saint in explaining (repeatedly) to the blog author where his analysis, opinions and criticisms are just plain wrong, providing very solid background as to why.

Paul is not a PulseAudio fanboi by any stretch of the imagination - he's clearly Mr Jack, but even he openly admits that some of the things going into pulseaudio are pretty smart. He doesn't believe it's necessarily the final ultimate solution, but certainly reckons that some parts of it could very well be used. With Linux it is all about evolution. Pulseaudio today is quite different to what it was a couple years ago, and I'm certain that it will continue to evolve and ensure that those good bits are matured and nurtured, and the missing bits are incubated.

The second or third last comment ("Executive Summary" on page 2 of the comments) also wraps things up nicely IMO.

Everything you've said is working FINE for me with PA. So whatever problem you're having, I can only assume it is outwith PA. As for "unmanaged" complexity... that's the problem right there? Did you just run "make install" or did you run a disto that managed the complexity for you? You should be doing the latter. If you distro doesn't manage that complexity for you, complain to them.

And for what it's worth UPnP and Bluetooth were very much plugged in later. The architecture allowed that to work with minimal hassle. For me that's good design, not over architecting.

Yup, just see the "About" page on my site. Some of the articles under the "KDE" tag have more info about the specific patches needed to make this all work. Feel free to comment etc. on the site and I'll try and get back to you.

Nicely said :)