I subscribe to the dream. I think a lot of features PulseAudio brings to the table are long overdue and very welcome. I even manage to be amused at Lennart’s abrasiveness when it comes to defending the software he writes (though it might help that I know the guy). So I have the right mind set, which is why I persevere.
But one thing PulseAudio definitely lacks is transparency. Too much of it feels like black magic. I certainly pretend to know more about Linux audio than the average user, and even then I’m mystified by simple things as ‘why does pulseaudio sometimes not seem to be running ? What is responsible for starting it at login time ? Why doesn’t it get started when some app starts playing sound ? How do I figure out why sound doesn’t work for this application ?’
Today I was reminded again as I ran into some problems with skype (bug filed). PulseAudio asserts and goes away probably because of something Skype does wrong (although one could argue that PulseAudio shouldn’t break down completely because of one bad client).
The bug itself is not the point of this post. What I’m lacking in PulseAudio is a way in to understand problems and help create good bug reports. A PulseAudio debugging guide would be excellent to have; one that would tell me ‘set up pulseaudio like this to get more info when the crash happens’. Googling doesn’t find me a guide, and PulseAudio’s website doesn’t have one either.
Lennart, if you can give me some starter tips to provide better bug reports I’ll volunteer to write up a Trac wiki guide to do the debugging and bug reporting.
No need for the haters to comment on this post – whether it’s hate against Skype or PulseAudio :)