Quick note: when I started using Phonon everything Just Worked(tm), including Skype and Firefox and mplayer and DragonPlayer and Amarok and ... everything cohabited and was beautiful.
I upgraded my operating system and was "blessed" with PulseAudio. Now nothing Just Works(tm).
This is the difference between a system well thought out (Phonon) and a system so convoluted and in search of a problem to solve that it simply messes it all up in the process.
I had no need for PulseAudio. I had Phonon + Xine and Phonon + GStreamer and life was wonderful. I hope, based on my personal experience with PulseAudio, that others wake up and realize that, no, it's not necessary and that yet, it does complicate things and that, why, we'd prefer things to Just Work(tm) versus become a mess.
I've seen the block diagrams, I've been to conference presentations explaining how it works. The insane complexity of it all horrifies me.
Regardless of what others say about PulseAudio, I will not drink that kool-aide.
Subscribe to:
Post Comments (Atom)
79 comments:
It may seem bad right now, but the direction it's going is great for all of us once the dust settles. Don't be so hard on it.
then someone needs to step up and do a much, much better job of sorting out the design.
what i saw of the design of PulsAudio makes me shudder. and i'm a "complex design is cool" guy.
now, i was willing to let those "omg, wtf"s subside until i tried it. it was even worse than i expected.
the design itself is too complicated and unpragmatic. when you get self-recursing graphs while trying to figure out how things fit into the multimedia stack, you've just stepped into a world of unnecessary hurt.
now, you can always fix an implementation, but you can't "fix" a design. you can only change it.
in this case, the design needs to be changed. better yet, it's not even necessary and should be forgotten about.
i base that on the fact that media was actually working 100% perfectly with a wonderful user interface and with zero configuration on my part for the first time since i started using linux .... until pulse stepped in with it's crazy design concepts and screwed it all up.
so yes, i will be hard on it.
I somehow managed to avoid PulseAudio until I got my Aspire One. I guess Fedora 8 had Pulse? Anyway, yeah, world of hurt. And trying to upgrade it (or programs foolish enough to use it) broke everything.
Now, what with it being new distro season and all, the first thing I do when I get a new distro up and running is tell Pulse to screw off. I use KDE4, and Phonon Just Works 95% of the time (the other five? Not sure if that's Phonon or the app messing things up, but they're minor issues at best)
i'm no programmer, but in terms of the user perspective...aaron is 100% right. pulse is confusing, over-complex, and seems to deliver fairly trivial results when it works. I am trying to drink the kool-aid but I can't figure out how to...
Good to hear from someone who has at least "some" knowledge about software design what we all poor users think.
But anyway, you worried me about something. When you say you upgraded, I guess it was to KDE trunk. Does that mean that KDE-4.3 will have Pulseaudio by default? Why???
With phonon, is the user able to configure the volume of each application ? It's something useful provided by pulseaudio that I don't find in kde.
I couldn't get rid of audio delay between time you started to play something and time when you could actually hear sound on your speakers.
So pulseaudio was uninstalled from my machine very quickly.
Phonon + xine = win for me.
the only reason for me to use pulseaudio is the RTP streaming.
To transparently stream f.ex. Last.fm synchronized to other computers.
I only wish pulseaudio wouldn't crash all the time when streaming.
"I guess it was to KDE trunk."
no, i always run KDE trunk. i upgraded to OpenSuse 11.1, which comes with PulseAudio.
"Does that mean that KDE-4.3 will have Pulseaudio by default?"
no.
Already said this a while ago in a blog post of similar thought:
PulseAudio has just no use-case. Honestly, for whatever reason does we need this one? Back in history, one or two years ago, I installed it when everybody did because it was cool and TheNewThing (tm). Now I still have it installed , this time because the (K)Ubuntu packagers force me to do so, for whatever reason there are dependencies on libpulse for OpenJDK and kdebase. Maybe I should file a bug on launchpad.net on it ...
You might be interested in another, more dangerous issue with Pulseaudio.. :
http://forums.opensuse.org/soapbox/402555-pulseaudio.html#post1912863
I haven't been bitten yet by the pulse audio issue, i don't know much about the design and implementation but what it tries to do is something that we all need on any desktop. I believe it has the same design goals (to some extent) of what he developer of aRts had. There's so many advantages offered by this framework - if only the implementation were to be done better.
Really hope something can be worked out, where Phonon would work better and more transparently with Pulseaudio
br
Sam
@Samuel Mukoti: that's kind of the issue .. Phonon, using whatever lays beneath it (be it gstreamer, xine, vlc, directshow, quicktime, whatever), it WORKS.
users can set per-semantic-type volumes, it reacts to hardware coming and going, developers get a beautiful API ...
PulseAudio just steps in and messes it up.
as such, i see NO advantages offered by this framework, and comparing it to aRts does it no favours.
Aaron, what is a "semantic-type" in this context?
PulseAudio has caused plenty of grief judging by the mailing list posts that I saw when searching for information about my sound card, but per-application sound controls in KMix would be pretty awesome.
"what is a "semantic-type" in this context?"
categories like "music", "video", "notifications", etc.
who cares if it is dragon, kaffeine, xineui or mplayer. ... i want all my video at the same levels =)
As far as I know one of pulse-audio's aims was to replace aRts (they didn't look into what was going on in kde4 development). And guess what:
They are doing a pretty good job with replacing aRts on the sucker-scale!
Hmm, I saw pulse audio a couple of times when doing a 'ps', and assumed I'd run some gnome programme at some point earlier. (Not trying to knock gnome - it's just that I tend to know what to expect with KDE as I'm more familiar with it, so if I see something unfamiliar I just assume it's part of gnome). Anyway, now I know what it is, can I get rid of it? I'll try when I get home.
I have had the same experience with openSUSE. Your blog post gave me hope that I could rip-out PulseAudio but apparently not :(
I thought PulseAudio was a sound server like AlSA but better. Now I find it's somewhere around the Xine/Phonon level. What does it do then?
Is it the reason why:
Audio just drops off on my PC? (reboot)
I can no longer mirror front and rear audio in KMix?
The starting sound in KDE4 only plays half a second?
Intrepid has been a most buggy release!
@behavedave:
What does PulseAudio do? A lot. Too much? Aaron mentioned the scary block diagrams.
The starting sound in KDE4 only plays half a second? - No that's not related to PulseAudio and has been fixed.
That is a complicated diagram but it appears that it:
Brings AlSA and OSS together so they don'y exclude each other from the hardware.
Uses Hal to detect new hardware - hot-pluggable USB gear I guess. (Phonon/Solid do this already though I thought leading to some compatibility issues)
Can broadcast the sounds through RTP/Tunnel and announced through Zeroconf. Not quite sure why you would want that although I have never come across desktop sharing on Linux where it works yet.
Provides compatibility for esound which was another method that Gnome used to address my first issue. Hazard a guess thats what lixine/libalsa and libao did as well.
It does seem complex but it handles so much legacy compatibility it was always going to end up that way. It seems a mystery to me that all those differing systems worked harmoniously without pulse not despite of it.
The only curious thing is what or where is the native protocol for pulse surely it would provide its own control layer so that eventually that would become the standard bringing together all the other applications as they left their legacy interfaces.
Well I know little of these things so tear apart my assumptions you knowledgeable types!
"what is a "semantic-type" in this context?"
categories like "music", "video", "notifications", etc.
who cares if it is dragon, kaffeine, xineui or mplayer. ... i want all my video at the same levels =)
So, why these categories are not listed in kmix ? (on ubuntu 8.10 kde4.2rc1)
Actually PulseAudio has a few good points, if you use the Gui-Client, which, for some unknown reason, doesn't have a tray icon per default.
With it you have a seperate volume control for every application using a sound device to output or input sound. As a usercase: I have Amarok running with random playlist in the Background, now I browse and stumble upon an annoyng ad with sound on the web, which I can't block because I need the service of the website(think megaupload). Now I can simply regulate the volume of firefox to not bother me anymore.
The problem with Pulse is that they neither are able to communicate the reason why we should use their stuff, nor do they have any idea about usability or real-world demands. Plus Fedora had to rewrite most of the PulseAudio-Core to stop it from randomly clipping(which is still happening btw.) which left me with a big WTF in my mouth. They need distributions to fix stuff that would be considered "basic" by 99% of all peole?
@Aaron,
I must agree with you that.. no one really cares to control audio from individual apps as such but more like audio, video, chat, phone, notifications, etc..
as for RTP streams, this was a life saver for me, on my LTSP setup that I'm running almost 300 KDE3 desktops. (aRts is configured to send audio to ESD)
The only problem is see is developers & users need a common & standard way of talking to audio hardware, and i noticed, libxine, gstreamer, mplayer, kaffeine and many others.. quickly pushed out plugins & audio sinks for pulse.
Either way, we need to work well with pulse, and sadly its been pushed on us by the distro packagers, and with the desktop agnostic approach where Gnome & KDE apps live well together...
the future looks like phono + pulse intergration :(
my 2cents
I think this explains it pretty well:
http://foss.in/2007/register/slides/The_PulseAudio_Sound_Server_353.pdf
...and I think distributions should stop shipping half-finished software.
I must admit that occasionally I find myself wishing I had a true per-application volume control, due to certain ill-behaved (non-KDE) apps. However, there have to be ways to do it other than PA.
The genuine problem with Pulseaudio right now, in reference to Behavedave's statement...
Is that unlike that block diagram, it really _doesn't_ have flawless legacy compability. Half of the old programs have serious problems, and it is definitely not a "drop-in-replacement" for any casual user. I also hear that it's absolutely a no-go with any of the JACK-using or audio-development software.
The central problem is that Pulseaudio, in addition to supporting a (somewhat flawed) legacy layer, is also trying to push a new platform/API for sound development. (Non-developer lay speak here). Essentially, proposing a new solution to the Linux sound problem -- while sending the old methods into deeper unreliability.
Unsurprisingly there are growing pains, and I wonder whether there really is enough developer momentum to finally bite-the-bullet and actually make such a good legacy layer that stuff Just Works again. I fear they may be preoccupied with other priorities (and in fact, the legacy layer is just one priority).
So perhaps Pulse will be good, very good, in time. But the growing period is quite painful, no doubt.
Out of curiosity, I wonder what distribution Aaron previously used. OpenSUSE 10.3, perhaps?
Hi Aaron, i had problems to with pulse audio, since i updated to kubuntu 9.04 to follow up the devel off kubuntu and kde4 in kubuntu, ive had the problem that kubuntu says blabla you device doesnt work, switching to pulseaudio, so i gues there will problem at pulseaudio.
Ow i have to ashame off myself naming me The Kerkraadse KDE user, but this is only my first comment.
I said this when the phonon/gstreamer argument occurred, the thing that needs fixing most urgently in Linux audio is the cooperation. Everyone sees the same house they want to build bu no-one agrees on how it should be put together.
The choice seems to be between cooperating on a best-compromise design or cooperating to make sure that parallel projects fit together in a somewhat rational way (and I mean actually sitting down and figuring out how the Linux desktop audio might look in 2 years time) or not cooperating at all and letting the distros and users try to make some sense of it.
I just wish there were the time and the money to get the various factions together for more than a day.
This is probably a naive understanding.
Shouldn't Phonon be able to use PulseAudio directly?
I have all my stuff working. Yes, it wasn't as painless as it should be, but PulseAudio has some cool abilities. The transition period isn't over, hence your pain. Good or bad, all the major distros are on board with PulseAudio. It's easier to go with the flow than fight upstream.
I currently have Xine using PulseAudio and Phonon using Xine. Works.
On a side-note, does Phonon support Bluetooth headsets?
If it does, will this support extend to Skype and Flash? (with pulseaudio it does)
*hugs his Gentoo with USE="gstreamer xine -arts -pulseaudio"
Completely agree, Pulseaudio is audio poison for Kubuntu (8.10)... I had beautifully working sound in 8.04 then nothing after the upgrade.
Reading through the comments around the web, the (K)Ubuntu implementation of PA seems to be broken by default, which means no sound server running at startup.
In fact, the only way I could get it working was by adding the various commands in an Autostart script to get PA running and the PA tray icon up (highly Gnome centric).
Once it was up, the GUI presented a dizzyingly silly array of menu options with cryptic messages and settings, none of which seemed to do anything at all useful. When the sound did work, it was inaudible and fiddling with the various options at times produced a deafening high pitched whine that could seriously cause deafness.
Finally, the great weakness of PA is that it tries to be everything to everybody. Basic audio on a computer is a matter of sound up, sound down, audio in, and mute with one sound control interface (keyboard, tray icon) for all applications -- altering sound levels should take a few seconds, not a trip through UI hell.
I can understand if people want all the tricks that PA can do but they are edge conditions. The distros should just ship a working sound system for the median user and provide advanced options.
My audio has now returned thanks to purging all PA packages except for libpulse0, which tries to remove:
dragonplayer
libasound2-plugins
libsdl1.2debian-all
libxine1
libxine1-all-plugins
libxine1-misc-plugins
libxine1-plugins
phonon-backend-xine
Sound never worked right for me until I setup PA. It fixed simultaneous access issues and issues with Flash mucking up the sound. At first it required some workarounds to work with all apps (or some had to bypass PA altogether), but now everything works automatically for me.
This should help too
PulseAudio Perfect Setup
Just wanted to say that I totally agree. I used to be able to solve this problem by removing every vestige of pulseaudio from my system, but upon upgrading to OpenSUSE 11.1, I find that this isn't an option anymore. Blef! =:(
Pulseaudio is unnecessary, and causes more problems than anything, I agree with Aaron.
Aaron-
Slackware still doesn't include PulseAudio, and in all likelihood won't. We're waiting for you. =)
Indeed; while some often criticize slackware for not managing packages, it's time like this when I'm thankful it doesn't make these decisions for me.
Yep, and I think I've even said around here that PulseAudio is a steaming pile of unnecessary crap. Does it make the life of a desktop developer easier? No, not at all. Does it make audio life easier for users? No.
http://lwn.net/Articles/299093/
There's an awful lot of use cases around PulseAudio that the vast majority of users simply don't care about, especially versus instability and stuff not working.
There's even more brain damage to be added such as libsydney, which is currently still vapourware as far as I know to try and stop this being a further pain to developers - and those developers already using PulseAudio will need to port again!
It's crack.
Quick comment : With Pulse Audio enabled in MandrivaCooker, amarok locks up whenever I try to play a song. Diasble Pulse, amarok works.
From some of the posts here, it does appear that I don't really need it, which is good for me.
Only problem I see so far is that my keyboard multimedia keys don't affect volume then amarok's playing.
Although I really enjoy reading your blog, I think you are too unfair this time.
You should do yourself a favor and upgrade to a recent distribution. But if you don't like PulseAudio, or if you don't use it, then just use something else, but don't complain.
Your attitude is going against your usual statement on how to behave with open-source. I find it a bit ironic and sad.
PulseAudio solves a lot of issue and is a great piece of code. It is somewhat a complex project, true, but it also have a wide range of capabilities that you surely didn't see. (I won't enumerate them, they are other posts for that).
Don't drink the kool-aide, but don't take it down, it's cool. If you don't need it, don't take it, and help your distribution or project to behave better with or without pulseaudio. In short: keep a positive attitude.
@elmarco: The funny thing is that pulseaudio's development started well after development of phonon started. And while phonon was learning from the past (1. users and developers need one interface for both audio and video on the desktop, 2. relying on a single structure/backend is doomed to fail, 3. trying to solve all problems at once is doomed to fail), pulseaudio did exactly the same mistakes as aRts did several years before. I even told lennard at the linux audio conference 2007 that his approach is not solving things. Still he went on...
And I predict that there will never be a good pa-backend for phonon simply because pa is not providing video.
@arnonym: I have a different understanding.
Phonon is offered to application developpers. PulseAudio is not (unless you really want something special).
Phonon solves it's own range of problems and I think it's good. As you said: one interface for both audio and video for desktop developers.
It's not the intent of PulseAudio to limit upper layer to use PulseAudio only (although, I, personally, would think it would make sense). But at it's own level, PulseAudio is not limited to a single backend neither. So your 2nd point is not clear or valid.
And lastly, PulseAudio is not trying to solve all problems :) PulseAudio try to bring coherence on the audio mess, and while offering flexibility and better user experience and features to the user.
I am glad there will never be a pa-backend, because I really don't see the point since both Xine and GStreamer (and other media framework) offers the backend already.
@elmarco: "You should do yourself a favor and upgrade to a recent distribution. "
i'm running a 1 month old distro. i think that's relatively recent, don't you? =)
"Your attitude is going against your usual statement on how to behave with open-source. I find it a bit ironic and sad.
"PulseAudio solves a lot of issue and is a great piece of code."
except that it still doesn't work and still causes more problems than it ends up solving.
either PA is too complex in design (i think it is), is too understaffed (probably also true, which is why when i see another audio stack spring up i get a little sadder) or is just plain misguided. i don't think it is the latter, but likely the first two.
my concern is that too much ends up relying on PA and we all tell each other happy fairy tales about how great it is and we end up wasting another couple years.
"It is somewhat a complex project, "
it's quite complex.
"true, but it also have a wide range of capabilities that you surely didn't see. (I won't enumerate them, they are other posts for that)."
oh, i'm aware of what it attempts to do and what it can already do. yes, it's an impressive set of features. but it comes with an amazing complexity price tag and .. well .. doesn't "just work".
"Don't drink the kool-aide, but don't take it down, it's cool."
i can't stand for things i feel are, by design, bad for the platform. and i don't come to that conclusion lightly. i watched it develop, was highly concerned with what i saw, but kept reserving judgement.
there's a lot of semi-questionable-but-mostly-works technology in our stack. they get free passes for being, well, Free software and actually here right now and, generally, improving things.
D-Bus, HAL and many other things in our stack aren't perfect and have lots of flaws. but ... they work well enough, serve important purposes and are generally useful.
heck, with all the annoyance of x.org and its drivers over the last 2 years, i'm still not bagging on it ;)
i can't say the same about PA, though. which is unfortunate.
Lennart is right that Linux audio *is* a mess. I'm just not sure PA is the answer. in fact, i'm fairly sure it isn't ...
PA needs to be re-thought. it's ok to try something and have it not work out, as long as we learn from it. that's what KDE did with aRts and our lesson was "don't build our own sound servers, let others do that". this makes me, however, care a whole lot more about the sound servers others are making.
Aaron: as someone perceptively mentioned in a blog response to this post: try doing s/PulseAudio/KDE 4/ on your post and you will a) appreciate what PulseAudio is doing and b) understand why people are so pissed off with KDE 4.
Either way, pot, meet kettle.
Pulse doesn't do the same stuff as Phonon, not remotely, so I don't really know why you're trying to compare them. It's a sound server, not a multimedia framework, and it's a damn sight better sound server than any of the alternatives (esd or arts, basically. Yes, arts. Which you guys stopped developing. Thankfully.)
A sound server is the right solution to any number of problems, such as..."how do we usefully deal with multiple sound devices?" and "What should applications that just want to play sound talk to?". It's the right answer to these questions, so we need one, and Pulse is by a long way the best game in town. Yes, if you have a problem with a sound server, a configuration with no sound server may work better. That doesn't mean not having a sound server is The Answer. It means you should file a bug so the sound server will get better.
Oh, and no, I don't think "I have a problem with Pulse! Let's write another fucking sound server!" is the right answer to the problem either. Pulse is the only sound server with a snowball's chance in hell of getting buy-in from all desktops and all distros. Please, for the love of cookies, don't fuck that up. The esound / arts mess was a five year nightmare for anyone who supported real users. If you start that up again I'm going to want to break something.
@AdamW: "try doing s/PulseAudio/KDE 4/ on your post and you will a) appreciate what PulseAudio is doing and b) understand why people are so pissed off with KDE 4."
there are some material differences between the two, however.
first, we very clearly stated exactly what we were doing, came out with a sound design, and within a year brought it a production point.
people who got pissed about "kde4" (aka plasma and printing) were just as often unknowingly pissed about nvidia or x.org and had ~0 understanding of the design being approached.
but hey, if you want, we can wait another 2 years and see where pulse leads us.
one of us will then eat their words.
"A sound server is the right solution to any number of problems,"
which really isn't particularly in question. i'm not talking about the concept of multimedia frameworks, but the implementation and design that is the server known as pulseaudio.
" such as..."how do we usefully deal with multiple sound devices?" and "What should applications that just want to play sound talk to?"."
you do realize that pragmatically speaing Phonon+[Xine|GStreamer] actually solves both of those already, right?
"It's the right answer to these questions, so we need one, and Pulse is by a long way the best game in town."
in that case, lord help us.
"Yes, if you have a problem with a sound server, a configuration with no sound server may work better."
call me crazy, but i'd rather run with a configuration that works than hold out hopes for an overly complex design that has a low chance of success.
when i saw the concept for how something like phonon and pulse audio would work together as it was sketched out on a whiteboard for me by one of the people involved, my head swam. and not in a good way.
"Pulse is the only sound server with a snowball's chance in hell of getting buy-in from all desktops and all distros."
this is precisely the wrong criterion to make these kinds of choices by. version control systems should be chosen based on a combination of technical minimums and popularity maximums. it's ok if the vcs is a bit crap if at least it has a huge acceptance rate. (hello cvs, then svn and now git)
but using that same equation for core services? braindamage defined.
"Please, for the love of cookies, don't fuck that up."
sorry, but i'm not a party-liner. i'm a pragmatist who cares about the ability for our platform to compete with the competition.
a cocked up mess of a sound server won't help.
"The esound / arts mess was a five year nightmare for anyone who supported real users."
agreed. i'm not suggesting going back to that. in fact, it's based on those experiences that allow me to be very skeptical about pulseaudo. the take away there was simple solutions don't cut it, but baroque systems of audio intrigue don't either.
"If you start that up again I'm going to want to break something."
i never suggested any such thing.
As someone who just recently had a lot of the same problems, I mostly agree with Aaron.
No matter what distribution I run, if I know it has pulseaudio the first thing I do is something to the effect of
"yum remove *pulse*" then I check to make sure it's not removing anything useful in the process and I go about my business.
It maybe "cool" but there are quite a few *serious* regressions. By *serious* I mean the kind the make you want to put your foot through the monitor (or speakers). I have wasted too much time troubleshooting audio issues only to realize in the end that the pulseaudio server was somehow not working.
One thing I will say in pulseaudio's defense is that it does seem to work slightly better on gnome than on kde. Though that maybe just my impression.
As everyone found out with aRts this is a non-trivial thing (making a high quality sound server) so in that respect I think this is something that needs to be thought out more. There needs to be more collaboration between various organizations and more thought to the end user experience. I as an end user (whose does not do any serious audio editing/mixing/etc.)should not need to know that something called pulseaudio exists.
I suspect that perhaps distros rushed too quickly to jump on the bandwagon and include pulseaudio as a default option. It should have been placed into repos. advertised, and requests for testing should have been made. Perhaps even setting it as the default only for people running the development versions of the distro, but it should not have been included until there were sufficient guarantees that these problems were not going to happen. For lack of a better example, I think this maybe similar to the "adoption" of kde 4.0 at an early stage by many distros. I thought kde 4.0 was cool at the time but looking back (after running kde4.2 for a few months now) it wasn't the BEST thing to include it by default. Perhaps it too should have been left in a development only version. Or provided via a separate/non-standard repository. But I'm going off-topic with that.
So I guess the short version of te thinghis is:
1.Something LIKE PA is needed (maybe PA maybe someone takes their work to a new level)
2.More collaboration/planning is needed by interested parties (gnome/kde/distros/freedesktop)
3.Pulseaudio shouldn't be used by default until sufficient testing can be made. If it's new compiz plugin that maybe unstable I say fine included it and hype it as a "feature", but not a sound server, that's asking for trouble.
On the issue (tangent) of "updating" distros. Aaron, is their any particular reason you use opensuse over other distros? I have largely "ignored" it as a distro, but I must replace one of my distros (I'm switching to x64) and I was thinking of opensuse as an option.
@AhmedG: i agree with pretty much everything you wrote there =)
as for "why opensuse", i'm really impressed by the build service, suse studio and the like. they have also returned to the solid engineering results i once knew them for back in the 8.x-9.x days in which i used SuSe a lot.
the pulseaudio thing has sort of shaken me a bit. who knows, i might try fedora or slack on a new machine if/when i get such a thing. but for now i'm happy with openSuse.
as a bare minimum, all the packages i ever wanted are there and i can apply updates without fear of system breakage.
@Aaron:
"i can apply updates without fear of system breakage."
Hopefully. I don't think you were using it yet, but earlier this year an update effectively broke 11.0 for laptop users. They somehow changed around the permissions somewhere in the NetworkManager stack, so that it had to be run as root. Took me a few days to figure out the workaround, and it took them a little over a week to post an update.
But, yeah, the Build Service is probably the greatest thing ever (after KDE4, of course), and it'll take a pretty big screw-up on the part of the openSUSE team to undo that.
I'm really starting to get worried about how this whole discussion is going. I have a great respect of the people and the comments that are coming through, but some comments seems less objective than others.
@Aaron, I understand the frustrations when we're trying to build a "Jusk Works(tm)" desktop and things like PA get in the way. The way i see it is since most distros are Gnome & KDE centric, their focus is getting a cross-desktop solution for audio - and judging from the way Gnome is going - pulseaudio is there to stay (on the Gnome enviroment)
I was so excited when i saw the first drafts of phonon, and what it envisioned to do - problem was none of the Gnome developers took-up the platform, they always b*tch & complain about it being C++ and Qt being GPL. Nonetheless, they didn't take-up the framework and if whats happens with (k)ubuntu is anything to go buy, it always seems technologies, frameworks, etc, are always dictated by the Gnome guys, then KDE plays catchup - NOT FAIR.
Examples are NetworkManager, PA, list goes on.. problem this has always hurt Kubuntu, to the point that i never recommend Kubuntu to users anymore, I've moved to Suse for KDE users & Ubuntu or Fedora for Gnome desktops.
Lastly, one thing for sure is we all need a sound server at some stage. I'm one of the few people who actually liked aRts - at-least what it tried to do - the design i loved, just the implementation wasn't up to scratch! It even catered for musicians with all the building blocks synthesizers etc.. (i digress..)
I just wonder how are other OSes dealing with this. I know windows had some Win32API for Midi & basic audio, but seemed to have been moving to directx last i used windows. The had directsound, directmusic, and direct3d for video - sounds to me like most of what we have in phonon. On the Mac it i only know of CoreAudio and OpenAL, and CoreVideo, QuickTime Kit on the video side..
I know we have/had OpenAL, and Qt put together with libxine (i.e. phonon) gives us all we really ever need for accelerated video.
The problem i see here is if we (KDE community) fail to play ball with PA, since users actually like the features the PA has to offer, we may have to scratch that itch, and go back to implement some sort of soundserver so that we can offer similar functionality with out having to have PA installed. Face it Gnome love PA because its solves thier problem where they had a dead ESD project, and now PA came to the rescue and with Gstreamer they have never looked back (it seems)
I really don't know what the solution is. I pray now we have Qt under a new license it might help the other camp accept some of out framework/libraries. At the end of the day, packagers might just have to accept that on a KDE centric desktop we don't want/need PA dependencies.
br
Sam
@Samuel Mukoti: "I was so excited when i saw the first drafts of phonon, and what it envisioned to do - problem was none of the Gnome developers took-up the platform"
thing is that Phonon isn't a platform that's really aimed to be taken up by others much outside the Qt toolkit using community of developers.
Phonon is actually a bridge for us to things below; things like GStreamer or xine or vlc or DirectShow or QuickTime.
it's a way for us to grease the development paths on top of these system level services so that we can move forward fast, with agility and with future proofed code.
i'm not miffed that GNOME didn't take up Phonon, because it wasn't really designed that way.
if we look at something like WebKit on the other hand, we do see uptake.
"if whats happens with (k)ubuntu is anything to go buy, it always seems technologies, frameworks, etc, are always dictated by the Gnome guys, then KDE plays catchup - NOT FAIR."
kubuntu really isn't indicative, no. Canonical give ubuntu first treatment and then allows kubuntu the version-after table scraps. it's a sad trend, but it doesn't really reflect what happens upstream.
"Examples are NetworkManager, PA, list goes on.. "
for a lot of infrastructural things (package kit, console kit, HAL, NM, etc) i actually see it as free development for KDE. while some spend their time on these middle layers, we toil away on the user interfaces, functionality bridges and applications.
we have people who keep in the loop and get involved, but our focus is very much on the layers above that.
it does mean that we need to at time veto things going on "down below". KDE needs to more often say "this is how we recommend this goes together; if you do it otherwise, good luck, but don't lay the results at our feet." instead of simply riding the tide of distributions where ever it may go.
downstream distributions may not like that, but it's part of the two way dialog.
thankfully a lot of the time we match up and can work together in agreement or at worst workable compromise. sometimes .. not so much.
and unless PA gets it act together in 2009 and really slots it into place, which i'll be very impressed with given the complexity of the design, the surrounding software and where PA is today, this will grow into one of those "not so much" category items.
Aaron: you seem to be suggesting writing a new sound server, because Pulse is crap. In practical terms, that will do *exactly* the same thing as re-inventing the esd / arts mess, because you're not going to get every app and distro which has adopted Pulse to drop it overnight. It'll just wind up with two competing servers again, and lots of bad blood between supporters of the two both as individuals, apps, and distros, problems making things work together...eesh.
And...you picked the wrong guy to tell about how great Phonon + Gstreamer is. :) Look up my bug reports on KDE Bugzilla. For things like, you can't play an audio CD with Phonon + Gstreamer. At all. There's more, not all reported yet, because it seems like no-one wants to care about Phonon + Gstreamer.
Phonon + Xine works better, yeah, but it's still nowhere near perfect.
@AdamW
a) appreciate what PulseAudio is doing
Yer. It's trying to invent a new sound server to do a lot of things that people don't readily care about, such as per-application volume settings (a totally overrated feature that could be implemented far more simply) and network distribution and in the process making a crapload of things not work. There has already been things like NMM that has been built to do multimedia over a network for some time.
A sound server should be extremely lightweight and make very simple decisions. PulseAudio isn't. The design is convoluted and will end in a great big pile of hurt and useless code.
understand why people are so pissed off with KDE 4. Either way, pot, meet kettle.
If you're feebly comparing KDE 4 to something which has caused the Linux sound system to destabilise totally then you're insane.
(esd or arts, basically. Yes, arts. Which you guys stopped developing. Thankfully.)
Ahhh, yes arts. That thing that the KDE people started when there was not much else around, decoupled it from KDE and the Gnome guys went off and wrote that crap that is ESD. Thanks for reminding us all.
A sound server is the right solution to any number of problems, such as..."how do we usefully deal with multiple sound devices?"
Yer, and it should be doing it with a far simpler architecture than what is currently on offer.
"What should applications that just want to play sound talk to?".
I assumed that's why Phonon was built ;-). Quite a few people still don't get it though, including Lennart.
By the way, where is the new libsidney API that every applications developer is now supposed to rewrite for, and exactly what subset of ALSA should they be targetting? :-)
It means you should file a bug so the sound server will get better.
You can't throw bug reports and code at a pile of turd. The architecture is just plain wrong as well as the way developers interface with it for a simple sound server, and that's what is being discussed.
Pulse is the only sound server with a snowball's chance in hell of getting buy-in from all desktops and all distros.
Why do you say that?
The esound / arts mess was a five year nightmare for anyone who supported real users.
Yer, and years later we've got it all over again. What gives?
you seem to be suggesting writing a new sound server, because Pulse is crap. In practical terms, that will do *exactly* the same thing as re-inventing the esd / arts mess
A sound server should be much, much simpler than PulseAudio and it should have a sane API before any distro starts bunging that into their repositories. Linux Hater was bang on about PulseAudio. It's a solution in search of a problem where it can squeeze its square peg in a round hole. Any distro who has included Pulse by default now has taken leave of their senses.
It won't do the same thing either, because with Pulse we've got the same things as arts, esd and GStreamer - ill-thought out software that people hack on for years with a mountain of bugs, no progress and yet more bugs.
....because you're not going to get every app and distro which has adopted Pulse to drop it overnight. It'll just wind up with two competing servers again, and lots of bad blood between supporters
Rough transalation: "Pulse is here, you're stuck with it, live with it." Thanks a bunch. Users really appreciate that.
Look up my bug reports on KDE Bugzilla. For things like, you can't play an audio CD with Phonon + Gstreamer. At all.
GStreamer has issues regardless of what you use it with after over ten years of development.
There's more, not all reported yet, because it seems like no-one wants to care about Phonon + Gstreamer.
Probably because after ten years of development people have lost faith in GStreamer and they've decided to use stuff that works now and has been mature for a few years. You know, stuff like Xine?
I can predict exactly what is going to happen. KDE's application developers will port to Phonon and Phonon will be stabilised to work with whatever actually works in a few years' time. Meanwhile, everyone else will be stuck with the shit that they hung their hat and coat on and they will still bitch about Phonon being the wrong approach ;-).
Phonon was developed because the open source multimedia landscape is unpredictable, unstable, constantly changing and full of people who like to screw users and developers in favour of their own bright ideas. PulseAudio is proving that approach to be right.
Let me as one of the Fedora KDE packagers clear a few things up. Note that I do not speak for Fedora or even Fedora's KDE Special Interest Group as a whole, any opinions expressed are my own. Also note that I am not a PulseAudio developer.
* PulseAudio does not come from Ubuntu, Fedora was the first distribution to use it by default, it has been the default in both GNOME and KDE since Fedora 8.
* PulseAudio works for me with no issues at all. Seriously.
* There are issues with PulseAudio on some hardware. Most often, the actual part as fault is the ALSA driver for your hardware, PulseAudio just exercises previously untested code paths. (Does that sound familiar? ;-) Still, it's the truth.) They should get reported to the PulseAudio and ALSA developers. As a workaround, you can try to disable timer-based scheduling, this can help in some cases.
* The only way to get people to actually test PulseAudio is to release it. Kinda like with KDE 4.0.
* PulseAudio tries hard to be compatible with all sorts of legacy applications:
- Several audio frameworks have native PulseAudio backends.
- PulseAudio emulates the ESD protocol.
- PulseAudio provides an ALSA plugin (similar to dmix). The limitation is that mmap is not supported (but that's also the case on some actual hardware, so applications assuming mmap to always be available are abusing the ALSA API).
- There's even an LD_PRELOAD hack to make OSS apps work (padsp).
* While there are still problem applications, they are gradually getting fixed. For the usual offenders, i.e. proprietary software:
- Flash 10 works natively with PulseAudio (through the ALSA plugin). (For Flash 9, there was a library called libflashsupport which made it work.)
- The latest version of Skype is also reported to work with PulseAudio (through ALSA).
As for Free Software:
- I fixed PortAudio (which is also what Audacity uses) to support non-mmap ALSA access and thus work with PulseAudio: portaudio-non-mmap-alsa.patch.
- JACK is one remaining issue. Most commonly, JACK should get the lowest latency, so the common solution is to run PulseAudio on top of JACK. But the other way round (JACK on top of PulseAudio) would make it easier to try out JACK apps on PulseAudio-using distributions. (The ideal solution would be to emulate the JACK protocol in PulseAudio, but some design differences make that difficult.) This should now be possible with my PortAudio patch because JACK can use PortAudio, but I haven't tested this yet.
- If you encounter other Free Software apps which don't work with PulseAudio, please let me know! I can try to fix them. Also talk to the developers of PulseAudio and the offending application or library.
* Phonon already works with PulseAudio, however to get the best results:
- use the xine-lib backend,
- apply these patches to phonon: phonon-4.2.96-pulseaudio.patch, phonon-4.2.96-xine-pulseaudio.patch,
- apply this patch to kdebase-runtime (Phonon KCM): kdebase-runtime-4.1.70-pulseaudio.patch.
Those patches tweak the priorities in Phonon so PulseAudio is the default.
* A Phonon backend using PulseAudio directly doesn't make sense, not only because PulseAudio (intentionally) doesn't handle video, but also because PulseAudio does not do decoding. It is a more modular approach than aRts was, it doesn't try to do decoding or video in the sound server, that's what xine-lib or GStreamer are for. PulseAudio expects a raw audio stream, you use one of the decoding libs to produce such a stream (and also video, which is sent to X11, not PulseAudio, usually through the Xv extension).
* The main problem PulseAudio solves is concurrent access to the same sound device from more than one application at a time on sound cards which do not support mixing in hardware (i.e. most of them). It is not the only solution to the problem, the alternatives:
- ESD, aRts: both have serious issues and are no longer maintained. Application compatibility is lackluster.
- dmix: The most serious alternative (and what Fedora 7 defaulted to). This is interesting because it is practically a sound server (some form of server is needed to solve the concurrent access problem), but it is hidden inside an ALSA plugin. But it also has its limitations when it comes to application compatibility (only ALSA works out of the box, if you need ESD compatibility, you have to run ESD or PulseAudio on top of dmix, which may or may not work (ESD had some trouble and I haven't tested how PulseAudio behaves on top of dmix, if it works at all), and the same offenders which have trouble with PulseAudio's ALSA plugin often choke on dmix as well), its idea of an ALSA plugin wrapping the sound server is also implemented by PulseAudio and PulseAudio offers more functionality (e.g. network transparency). Also note that Phonon uses dmix internally when it accesses devices through plughw: identifiers (but that way of doing it, without configuring dmix as the default device, means only KDE 4 apps will work properly).
Most often, the actual part as fault is the ALSA driver for your hardware, PulseAudio just exercises previously untested code paths.
Pfffffff. That's not what I understand is happening. Currently, if you want Pulse to actually work your application has to be using a specific subset of ALSA and not 'previously untested code paths' as you claim because..........there's no stable way to interface with Pulse yet which is why an ALSA interface is used.
ALSA isn't perfect, but stop trying to blame things that just about worked OK previously.
There are issues with PulseAudio on some hardware.
It's funny how that hardware has worked OK before.
(Does that sound familiar? ;-) Still, it's the truth.)
1. Nice try ;-).
2. Not true here anyway. We had something that did work, and now we don't. We're not using untapped functionality here nor anything new.
The only way to get people to actually test PulseAudio is to release it. Kinda like with KDE 4.0.
I'm afraid it's a pretty feeble attempt to compare it with KDE 4. KDE 4 has included new functionality that required a new base to work from. Pulse has broken sound in a way that is going to provide precious few benefits for the pain.
PulseAudio emulates the ESD protocol. PulseAudio provides an ALSA plugin
Hacking something to 'look' like somethign else to try and attain some form of compatibility is a sure fire way to break things, and ensure that things are broken for a very long time. This is especially true of trying to emulate something like ALSA. The only way you can sort this out is to leave things broken for a few years and wait for the bug reports to flood in until the emulation stabilises.
Are you people that insane?
A Phonon backend using PulseAudio directly doesn't make sense, not only because PulseAudio (intentionally) doesn't handle video, but also because PulseAudio does not do decoding. It is a more modular approach than aRts was, it doesn't try to do decoding or video in the sound server, that's what xine-lib or GStreamer are for.
You might as well use GStreamer or Xine directly as your back end. Seriously, what is PulseAudio for?
The main problem PulseAudio solves is concurrent access to the same sound device from more than one application at a time
There are far simpler and far more trouble-free ways for users and developers than creating a new sound server, getting it to emulate ALSA and watching everything break.
PulseAudio offers more functionality (e.g. network transparency).
No one cares when bugger all comes out of their speakers.
but that way of doing it, without configuring dmix as the default device, means only KDE 4 apps will work properly
Well at least something will work.
@Kevin Kofler
Yeah, I'll have my grandma get right on that. Now, um, what's a patch?
But seriously, even VMware Server works out of the box with Phonon. That never happened with PulseAudio, even with padsp. Don't bother replying to me with "did you try <X, Y or Z>?" I've tired A-Z and none of it was worth the effort. "libflashsupport" (what a f*ing ridiculous name for a _sound_ compatibility library) should of been called libmakeflash9crashalotandblameitonthepluginandnotourcode-2.
Like Aaron, PulseAudio has left a sour, sour taste in my mouth. Big promises, no delivery! No thank you!
Actually, come to think of it, I seem to remember coming into #kde on Freenode one day and actually *yelling* at Aaron that Phonon had solved *all* of my sound problems. Period. No buts.
That's still true, just FYI.
KDE4 - Be free[ of random sound problems, among other things].
-Downhill Games
PS: No, I'm not ignorant. I'm sure there are some bugs with Phonon, but at least it works for *most* people in *most* situations. PulseAudio can't say the same. Read blogs and PA bug reports. Seriously.
@segedunum: The "previously untested code paths" issue is with the PulseAudio->ALSA->hardware interface, not with the applications->ALSA->PulseAudio interface (which is what you're describing here as the issue, it actually isn't - those issues are hardware-specific, so they're at the output end of PulseAudio, not the input end of PulseAudio). The previously unexercised code paths in the hardware drivers are why that hardware has issues with PulseAudio. The issue with the applications->ALSA->PulseAudio interface is ALSA API abuse by some applications. For example, the ALSA spec clearly says that not all devices support mmap (and in fact even some hardware drivers don't). Why are some apps then expecting mmap to always work? (That's the bug I fixed in PortAudio.)
@downhillgames: Those patches are already applied out of the box in the Fedora packages. And I don't see how an app can "work out of the box with Phonon" when it doesn't even use Phonon. You must be actually using dmix or be one of the lucky few with hardware mixing. Phonon is just a high-level interface, it doesn't do anything by itself to allow multiple apps to concurrently access the sound card, it relies on the lower layers to do that.
It's awfully hard to use ALSA's dmix when VMware Server uses OSS *only* and alsa-oss (`aoss`) isn't even installed, let alone used. There were no LD_PRELOAD dirty hacks. I don't have hardware acceleration (in fact, my X-Fi barely is supported at all). It just plain works. I'm sure that's not due to Phonon 'cuz, *you* know... the force that's making it work out of the box is... magic... or something.
Nice try.
-Downhill Games
hardware mixing != hardware acceleration
And you say your sound "works" - what if you try to play some music in Amarok while VMware is running? If it works, you're using hardware mixing (which most cards do not support). If the answer is "device or resource busy", well, that's what I expected, and exactly the problem which needs to be solved.
I never understood how somebody can consider it acceptable that only one application can use the sound device at a time.
And of course the part at fault for VMware not working with PulseAudio is VMware, for only supporting the obsolete OSS API. We've had ALSA for years, why is OSS still being used?
@Kevin Kofler
And I don't see how an app can "work out of the box with Phonon" when it doesn't even use Phonon. You must be actually using dmix or be one of the lucky few with hardware mixing.
Typically a netbook has a low-powered processor with a Intel HD Audio supporting hardware mixing. This kind of device is barely able to play DVDs if you use the hardware mixer, but loses this ability completely (I've tried it) if software mixing is added to the equation. And even if you depend on software mixing, dmix is at least not a service/daemon (i.e. a separate process) but only a plugin. I'm not familiar with Phonon's codebase, but it seems it (or the Xine backend) uses hardware mixing if available and uses dmix only as a fallback. Is Pulseaudio able to do the same?
PulseAudio->ALSA->hardware interface, not with the applications->ALSA->PulseAudio interface
It's all part of the same layered system. Pulse is trying to fool the application into thinking it is talking to ALSA and then mapping on to ALSA lower down. It's always going to end in tears.
The issue with the applications->ALSA->PulseAudio interface is ALSA API abuse by some applications.
Talk to the hand. Seriously. If an application worked before and now it doesn't then users and developers simply don't care. Blaming it on API abuse is going to fall completely on deaf ears, and it's another reason why I can see PulseAudio failing and making life difficult for years to come.
For example, the ALSA spec clearly says that not all devices support mmap (and in fact even some hardware drivers don't). Why are some apps then expecting mmap to always work?
Because they do, that's why. If you don't understand this then you have a great deal to learn. Microsoft has had to jump through these hoops and Apple still doesn't understand it. If you make something available and then say "Don't use it" then don't be surprised if developers do use it if it works. You can't come along later and say "Tut, tut". It's not ideal, but that's the reality. The cock-ups you make today you have to support tomorrow, just remember that ;-).
If the answer is "device or resource busy", well, that's what I expected, and exactly the problem which needs to be solved.
This can almost certainly be done far more simply and reliably than creating a new sound server that looks like ALSA.
I never understood how somebody can consider it acceptable that only one application can use the sound device at a time.
It's an annoyance sometimes, but versus having that and sound being unreliable people will take the former.
And of course the part at fault for VMware not working with PulseAudio is VMware, for only supporting the obsolete OSS API. We've had ALSA for years, why is OSS still being used?
See above. Application developers have better things to do than faff about with your grand vision for how sound should work. They should just port to Phonon and then insulate themselves completely.
To Kevin Kofler:
Keep in mind that the OSS API is NOT the problem. ALSA itself supports the OSS API because many programmers prefer using it, and therefore such ALSA apps (that link to ALSA using the OSS interface) should still work with PulseAudio's ALSA layer just fine.
You must mean that the problem with VMWare Server is OSS's ABI, right?
_THAT_ is what PulseAudio has to wrap around using padsp, when a program is hardcoded to use OSS rather than the ALSA-OSS layer.
VMWare is more than welcome to use the API they prefer, though it would be nice indeed if they used ALSA's OSS layer instead of pure OSS (since you do seem to imply they don't). If PulseAudio were interesting in helping these programmers migrate, they'd do good to put API-compatibility with OSS in libsydney, or whatever it is for the native-Pulse support.
And VMWare may prefer that the their software works on more than just Linux. Coding to OSS means it works on OpenSolaris too.
(This doesn't mean to address the inconvenience of OSS3's obsoleteness or OSS4's peppered history, rather just the kindness to keep supporting a commonly-used API).
And you can't deny that there really is no solution to wrap existing pure OSS-only apps -- just hope they recode themselves for Pulse or ALSA-OSS. Or "port to Phonon". Having to toss them inside a "padsp" call does work, but isn't something a casual point-and-click user will ever, ever master.
But none of these solutions are optimal. It is impractical to expect continuous software support for any product -- and to expect programmers to suddenly just recode their old apps to use yet another new library, just to stay functional.
This inability to maintain legacy compatibility is not really Pulse's fault -- it's remarkable things haven't broken worse, honestly, and not really OSS's fault. That's really a Linux problem. And you see this in every area in Linux that depends on libraries. Everywhere.
Programmers just code what works. They don't want to recode to a new API later, and even re-compiling is a no-go solution for an end-user of a legacy program. The first problem can be saved with good library design, but the second just can't be fixed. When recompilation of any kind is enabled to keep a legacy app working, your compatibility has utterly failed for end-users.
But at least for the programmers, you could make life easier with better library design. And it does seem like Phonon tries to do that, and so does Pulse, with its own support (as best it can) for the legacy layers. But even these best-efforts simply aren't enough if recompilation of any kind is required.
The fact that Microsoft and Apple can renovate their audio systems for recent OSes and still manage to wrap relatively legacy apps in a way that is mostly unnoticeable to the user is proof that they really did a decent design job, binary-compatibility wise. There is nothing like this on Linux
Well one thing is clear, the sound server issue is a serious problem. This is a case where decentralization is really NOT helping Linux. I think it's going to take someone like RedHat throwing their weight behind something and helping with the redesign/reimplementation of something like pulseaudio. Or even the kde project as a whole becoming active in this by sending people to work directly with pulseaudio's developers. If Microsoft can get this right then certainly Linux can.
Also these arguments about minutia don't really fix much if all they are is arguments for the sake of making a point. I think that anyone who can help should go help now and anyone who is just a consumer of this technology should take these points directly to the vendors (the distros, or the pulseaudio developers).
Honestly though, the distros are to blame right now. I feel that way because after looking at the PA site they make it clear that it's not exactly well tested http://www.pulseaudio.org/wiki/AboutPulseAudio#CurrentStatus
Distros should offer users a choice at install time.
Having said that, I recently tried Opensuse 11.1 and I did not notice many problems regarding PA but then again, these problems that I have experienced didn't show up when I was looking for them. It was usually during an awkward situation, like while I was demoing a Linux laptop & the sound wouldn't work etc.
Yeah, so I typoed. I meant mixing.
Enjoy your soap box. Bye.
(Note: in all of this post, "OSS" refers to the Open Sound System. I'm using the term Free Software rather than Open Source Software.)
@segedunum:
> Because they do, that's why. If you don't understand this then you have a
> great deal to learn. Microsoft has had to jump through these hoops and Apple
> still doesn't understand it. If you make something available and then say
> "Don't use it" then don't be surprised if developers do use it if it works.
The problem is, it only "works" on some hardware! There are even hardware drivers which don't support mmap because of technical limitations.
> You can't come along later and say "Tut, tut". It's not ideal, but that's the
> reality. The cock-ups you make today you have to support tomorrow, just
> remember that ;-).
Sorry, but that's not how GNU/Linux works. Broken APIs will get dropped. It's up to applications to adapt. And for Free Software, somebody (often a distribution packager) will do the necessary changes. It's proprietary software which is the usual problem, but that just shows that proprietary software does not fit into the Free Software ecosystem. Proprietary OSes are primarily designed for proprietary software, so they keep ancient ABIs around forever. Free OSes are primarily designed for Free Software, so they don't.
And going back a paragraph:
> Talk to the hand. Seriously. If an application worked before and now it
> doesn't then users and developers simply don't care. Blaming it on API abuse
> is going to fall completely on deaf ears, and it's another reason why I can
> see PulseAudio failing and making life difficult for years to come.
That's what they said about NPTL as well. And where are we now? LinuxThreads has been dropped completely from glibc (since 2.4, we're at 2.9 now), NPTL is the only option now, and guess what, it works! And applications have been fixed. I guess the biggest obstacle to PulseAudio adoption is that it is so easy to disable/remove.
@Jud: The OSS API is the problem. ALSA's OSS emulation does not even work with dmix! Nor with the PulseAudio ALSA plugin (or we wouldn't have this problem in the first place). Ergo, there is no way to have sound "just work" in more than one application at a time on all sound hardware as long as the OSS API is being used. It's time for apps to get fixed, in fact it has been time for several years now! Application developers need to get with the times, and this includes proprietary software, which is the usual offender. IMHO proprietary software needs to go away, completely. It just cannot keep up with the times, and third parties, including distributors, cannot fix it.
And offering higher OSS API compatibility is not easily possible: the OSS "API" is not a library you could easily provide a drop-in replacement for, it is direct access to a special device file called /dev/dsp. That's why LD_PRELOAD hacks (the *dsp wrappers) are being used. (They hack the file opening functions to treat /dev/dsp specially.) The only way to do without is a kernel driver, and the only such driver currently available is ALSA's built-in OSS emulation with all its limitations. There is work ongoing on adapting FUSE to also allow simulating devices in userspace, which would allow a better /dev/dsp emulation. But it is hard to get such an emulation to work with all apps (in fact, the *dsp wrappers don't work with all OSS-using apps either) because apps are doing all sorts of strange things to /dev/dsp, including mmap. That's why I'm saying the OSS API is broken by design.
@AhmedG:
> I think it's going to take someone like RedHat throwing their weight behind
> something and helping with the redesign/reimplementation of something like
> pulseaudio.
Uh, that's what they're doing, Lennart has been hired by Red Hat and Red Hat is pushing PulseAudio (e.g. by making it the default in Fedora since Fedora 8). (Disclaimer: I don't work or speak for Red Hat, I'm just a community volunteer in Fedora.)
On distributions: Fedora adopted Pulse by default first. Then Mandriva. Then Ubuntu. Then SUSE. By my count, every major distribution uses Pulse by default in its latest release. That's a lot of distributions that are, by Aaron's standards, 'insane'.
Aaron, I don't have many problems using gstreamer in other applications - like Totem or Elisa. Certainly nothing on the level of "audio CDs don't play. At all." The crappy code is phonon-gstreamer, not gstreamer.
@AdamW: everyone making the same poor decision doesn't make it not a poor decision.
as for gstreamer, i'm talking about pulse here, not gstreamer. others went off on that tangent, not me. i really don't have problems with gstreamer per se. it has never gotten in the way of using media on my system, and that's the bare minimum requirement of any media stack imho.
which is why the silly "directly access /dev/dsp and don't let anything else near it" strategy, oss and now pulse all fail.
and i'm not sure why that's hard to understand, nor why people will come to the defense of a system that is so evidently broken, has been so evidently broken and which has a design so complex and design goals so all-encompassingly broad that the odds of that changing in the near term and not exactly terrific.
My track record of fun with pulseaudio comes from its "completely asyncronous API", which, while a cool idea in theory, causes quite a messup even if you're using condition variables and signals provided by the pulse itself. Hey, every call in initialization sequence, while a perfectly syncronous thing by nature (do this, this and that and if something fails, give me an RC to just fail gracefully or try something else), becomes a bunch of waits on a condition in hope that the right source will fire this event and tell me what the hell is going on.
Not gonna fly.
Lennart Poettering, the primary author of PulseAudio, just posted a reply to a similar complaint. You'll notice a lot of the stuff he points out is stuff I also wrote. ;-)
I've had very few issues with PulseAudio, and fixed several sound issues I was having in Ubuntu (audio skipping, hickups etc.). The only app that didn't play nice was Skype. I do agree that it shouldn't be included in any distro until it is stable. That's why Skype hasn't supported it. According to them, it's been a moving target, so why waste resources until it's stable? Fair enough. That said, I've now change my sound settings to use ALSA instead. Which at least lets me make my Skype calls, but audio hickups are back :-( So far, I'm really impressed with KDE4. So much cleaner than 3. KDE3 was a complete mess IMO, but I digress... I might just move to the blue team when Jaunty is released...
And hopefully PA will be stable by then... wishful thinking? ;-)
Personally, I must agree with Aaron's original statement in this blog entry regarding PulseAudio. It's pretty much never given me ANY benefit, and has in actual fact caused me nothing but grief regarding audio in general. What particularly annoys me about it is that attempting to uninstall it tries to take out half my system along WITH it. Too many apps HAVE "drank (drunk, are drinking?) the koolaid" on this one and too many distros and developers are putting entirely too much faith in PulseAudio when just plain ALSA used to work BETTER all by itself without Pulse, or ARTS or anything else inbetween (at least for me on my hardware it did). I would happily uninstall PulseAudio in a heartbeat if I could, but sadly, the best I can do at the moment is "disable" it (and 'killall pulseaudio' whenever some stupid application starts it against my will even AFTER it's been "disabled"). Very frustrating development to say the least.
It is interesting. I now have KDE 4.3 working with Pulseaudio (I have 3 sound sources and 2 sound cards, I need to route my TV card to my sound card Line In, replicate the signal for an additional headphone jack, and Phonon really helps, but I need Pulseaudio), and the only thing I'm asking for is a) a Pulseaudio aware KMix, and b) paman, pavucontrol and such, KDE versions.
Maybe the only thing that we needed was some time. Just like KDE 4.
Post a Comment