Friday, July 18, 2008

PulseAudio: My Last Post On The Topic?

I wasn't going to post anymore on PulseAudio now that Lennart has fixed the core issue that was breaking audio for me on my system (there was a deadlock condition in PulseAudio - my libesd and libgnome fixes were merely a fix to make those libs handle the PA deadlock more gracefully).

But, since Lennart has now attacked me, I guess I should respond:

A few comments:

1. Not directly related to PulseAudio itself. Also, finding errors in code that is related to esd is not exactly the most difficult thing in the world.

Considering that the GNOME desktop and many other applications speak to pulseaudio via libesd, it is still relevant. Until all applications are ported to use PulseAudio directly, libesd is still a part of the "PulseAudio stack".

OK, Jeffrey found a real bug, but I wouldn't say this is really enough to make all the fuss about. Or is it?

Actually, I believe you mean three in the PulseAudio code itself (granted, the pavucontrol bug was already fixed and in a public release - shame on my distro for shipping 0.9.5 instead of 0.9.6, but I don't remember even flaming you about this one - I only reported it as a bug to try and help you make PA better). Yes, the deadlock one was fixed a while ago (assuming the deadlock you fixed is the same one I am experiencing, which it probably is) but it is not in any released version of PA. Nor is the "won't play short sound clips" bug fix.

Hence, not mine nor my distro's fault.

You also completely fail to grasp how frustrating that deadlock bug (which was really the core of my issues) was for anyone using GNOME on a system where that deadlock occurs. Because when that deadlock happens, the entire system locks up! You cannot launch firefox, you cannot start any new GNOME apps, etc. You can't even close gnome-terminal.

Now, I will grant you that part of the blame certainly lies in libesd (hence why I fixed it), but to say it is completely unrelated is bologna. My ESD fixes were not random fixes so I could point fingers, they were fixes so that my system didn't hang whenever PA did.

5. A valid bug, but not really in PulseAudio. Mostly caused because the ALSA API and PA API don't really match 100%.

This seems like a design failure - if the plan is to make applications that use ALSA directly "Just Work(tm)" through PA, then shouldn't PA have been designed to map better to ALSA?

I still consider this to be a PA "bug" even if the fix was in ALSA(?).

Many people (like Jeffrey) wonder why have software mixing at all if you have hardware mixing?

Actually, that's not at all what I was wondering. I had wondered why PA was needed at all because ALSA already did mixing for me.

Now, I will admit to being naieve about the full list of goals that PA is trying to achieve (which are worthy goals), but I think they all take a backseat to having sound actually work reliably in a basic setup (apps playing audio through local speakers).

Jeffrey thinks that audio mixing is nothing for userspace. Which is basically what OSS4 tries to do: mixing in kernel space. However, the future of PCM audio is floating points. Mixing them in kernel space is problematic because (at least on Linux) FP in kernel space is a no-no. Also, the kernel people made clear more than once that maths/decoding/encoding like this should happen in userspace. Quite honestly, doing the mixing in kernel space is probably one of the primary reasons why I think that OSS4 is a bad idea. The fancier your mixing gets (i.e. including resampling, upmixing, downmixing, DRC, ...) the more difficulties you will have to move such a complex, time-intensive code into the kernel.

Fair enough.

I still don't like it (but I guess there's nothing you can do about it if the kernel folk are holding you back), but so long as it Just Works(tm), in the end I don't care.

Not every time your audio breaks it is alone PulseAudio's fault. For example, the original flame of Jeffrey's was about the low volume that he experienced when running PA. This is mostly due to the suckish way we initialize the default volumes of ALSA sound cards. Most distributions have simple scripts that initialize ALSA sound card volumes to fixed values like 75% of the available range, without understanding what the range or the controls actually mean. This is actually a very bad thing to do. Integrated USB speakers for example tend export the full amplification range via the mixer controls. 75% for them is incredibly loud. For other hardware (like apparently Jeffrey's) it is too low in volume. How to fix this has been discussed on the ALSA mailing list, but no final solution has been presented yet. Nonetheless, the fact that the volume was too low, is completely unrelated to PulseAudio.

This is actually partly also openSUSE's fault in 2 ways:

1. the volume control in the panel launches pavucontrol instead of gnome-volume-control. Since I need to use gnome-volume-control in order to adjust the master volume of the ALSA device, and the fact that the volume shown in pavucontrol was set to MAX, led me to be confused.

2. the keyboard volume controls do not properly adjust the master volume (I think I may have wrongly blamed this on PA in one of my posts, but don't feel like re-reading my posts to confirm - if I did, apologies).

OTOH Ubuntu didn't exactly do a stellar job. They didn't do their homework. Adopting PA in a distribution is a fair amount of work, given that it interfaces with so many different things at so many different places. The integration with other systems is crucial. The information was all out there, communicated on the wiki, the mailing lists and on the PA IRC channel. But if you join and hang around on neither, then you won't get the memo.

If distros are getting this wrong, then maybe there needs to be better communication so that things like what happened to Ubuntu don't keep happening.

FWIW, I have personally read over the "The Perfect PulseAudio Setup" wiki page and afaict, openSUSE 11 followed the recommended setup but there were still problems (obviously).

(Although the problems I experienced were bugs in code rather than bugs in setup...mostly)

[2] In fact, Flash 9 can not be made fully working on PulseAudio. This is because the way Flash destructs it's driver backends is racy. Unfixably racy, from external code. Jeffrey complained about Flash instability in his second post. This is unfair to PulseAudio, because I cannot fix this. This is like complaining that X crashes when you use binary-only fglrx.

Sort of like it's unfair that Evolution users complain when Evolution doesn't work with some broken server. But users don't care that it's a broken server if other clients work with it, so it's still on the Evolution developer's shoulders to work around those bugs.

Sort of like how historically, hardware makers haven't been giving Linux kernel devs the specifications to make their hardware work, and so it is left up to F/LOSS developers to bear the burden of making it work anyway.

No one ever said life was fair and unfortunately, a LOT of users are going to expect Flash to work. If/when it doesn't, they will complain and in a manner of speaking, it is PulseAudio's fault because it did work pre-PA.


Anonymous said...

Please note that libesd is no longer part of the PulseAudio stack. But I guess when your SUSE version was released it still was.

ALSA is an API for hardware sound cards. PulseAudio is a sound server. It is only natural that some problem with mapping each other's functionality happen here. It would be a design failure if they matched 100%.

You remember when applications still drew directly into the framebuffer? We don't do this anymore with X these days. It's the same with sound. Until recently applications wrote directly into the sound cards hardware buffer. But claiming that this is a good idea is bogus.

Maybe you should start hacking on lower-level audio stuff and then make you a picture of what makes sense and what doesn't? What belongs in the kernel and what doesn't?

There's a certain difference between your mail servers and Flash. The protocols of mail servers one can figure out and work around in your software. The fact that Flash is racy is not really fixable without binary patching Flash. I think your comparison hence is very much invalid.


Anonymous said...

Lennart hardly "attacked" you. He mostly just pointed out the difficulties of desktop audio and explained what his project intends to address. The remainder was more pointing out that flaming is hardly the most effective way to go about correcting software problems. After four posts, it seems fair of him to defend his project. He's done so, and I wish you would just let it go.


Anonymous said...


Now as a user i love pulseaudio and the things it lets me do.

However in relation to the flash problems. How can it be that flash is apparently doing something dirty which makes PA crash (or whatever happens, i just notice it by seeing my Firefox crash)
But the same flash plugin worked perfectly (from a user perspective) in the old way sound was handled?

I can understand you don't want to create special cases in the code for every application that is doing things wrong, but there is something to be said for at least making sure PA doesn't crash/hang when a application is doing something wrong.

Jeffrey Stedfast said...

All but my first post were follow-ups about what I was doing to solve the problems I was having. I think people appreciated that (and distros are taking my patches).

Anonymous said...

This whole thing reminds me of gaim/pidgin. The developers spend more time telling the users why they're wrong than they spend actually fixing the problems.

Everyone knows why having a software based sound server is a good idea and in some cases necessary. I don't think anyone wants to argue the point. What people are complaining about are the enormous number of regressions that pulse audio creates from an alsa setup.

Instead of explaining how bugs aren't actually pulse audios fault, why don't they just fix the bugs?

zeenix said...

However in relation to the flash problems. How can it be that flash is apparently doing something dirty which makes PA crash (or whatever happens, i just notice it by seeing my Firefox crash)
But the same flash plugin worked perfectly (from a user perspective) in the old way sound was handled?

How is Lennart going to debug a binary blob? Surely he can't be expected to do that. We need PulseAudio for the reasons explained by Lennart in his recent blog entry, now if some random proprietry app crashes because of PA, I really don't see why Lennart or any GNOME dev should care. I think the only people that can and should do something to improve the situation is Adobe. Do report this to Adobe and see how much they care about GNOME "users".

Max said...

I think Lennart and the PA people have to look at it from the users perspective.

If it doesn't work the same way or better than it used to, it's a bug in PA from the USERS point of view.

I don't care what backend handles my audio as long as I can get 2.1 sound out from my speakers I'm happy.

PA should provide setup instructions for distributions so that these errors doesn't have to happen...

BTW I'm out of sound in Intrepid atm... but that's probably Canonicals fault ;)

Anonymous said...

Flash got fixed (the Flash 10 betas work fine with PA). And you could/can install libflashsupport to get sound when using Flash < 10 and PA.

Jeffrey Stedfast said...

Zeenix: Depending on what the race condition (or whatever bug it is) that Adobe Flash has wrt its ALSA usage, there's still a good chance you can work around it.

Obviously you cannot patch Flash itself, but if it worked fine with the regular ALSA, there's a good chance it can work with PulseAudio's ALSA emulation if people cared enough to try.

If someone were so inclined, they could build ALSA (possibly with added printfs or other custom state-tracking), figure out what Flash is doing, and then try emulate ALSA more closely in that case.

Just because Flash itself is binary-only w/o debugging symbols doesn't mean your ALSA has to be treated like a binary blob.

I don't know enough about the problem Flash has with PA to do this, but I have no doubt it's doable - people have been doing this sort of thing for decades.

The good news is that supposedly Flash 10 has already fixed the problem, so it should be a non-issue once Flash 10 is released.

Jeffrey Stedfast said...

Lennart says that libflashsupport doesn't work around all of the issues in Flash, there are still a few left (is it a few or just one? I'm not sure).

Those are the one(s) that Lennart says can't be fixed (imho, they can, just that the PA devs don't care enough to fix them - I'm not sure I'd be any different if I was a PA dev).

Anonymous said...

The following article is a good read:

I find it amusing that this guy notes that Lennart posted a rant about ALSA (the page has since been taken down/moved) and yet Lennart was all upset that you bashed PulseAudio.

I guess it's ok if he rants about other people's software, but not ok if someone rants about his software.

Vlad said...

You remember when applications still drew directly into the framebuffer? We don't do this anymore with X these days.

If only we still did! Then X wouldn't be the performance and functionality disaster that it is, and the Linux desktop (any of them) would have a chance at competing with OS X and Vista.

Anonymous said...

I do not understand the extreme emo-ness going on here. I have opensuse installed and on two machines pulseaudio is just garbage. It is clear that it was never ready for opensuse, and maybe not other distributions. One day, maybe tomorrow or a few weeks from now, there will be a significant update to pulseaudio that will magically fix all the problems users have reported but until then lets all just remove the packages and get on with our lives :)

Anonymous said...

I'm tired of all this ideological bullshit ("no signal processing in the kernel", "it's a device driver", "it needs to be network transparent", etc.). Just deliver a working Linux audio system. KISS

Anonymous said...

Seems even Fedora 9 users are uninstalling PA to get much more functional audio from their Linux systems.

Anonymous said...

Slight observation? This doesn't seem very zen-like. Then again, I don't feel very zen-like when my audio hisses at me and my music sounds like it might be coming out of a tin can...

I think the sound developers are just too religious about their implementations. ... and frankly, I'm amazed that X-Windows turned out so well, given that implementing sound seems to be so difficult.

Code Snippet Licensing

All code posted to this blog is licensed under the MIT/X11 license unless otherwise stated in the post itself.