Idea for an article.

[Thetargos]

Michael, one of the things that many of us users consider to be flaky on Linux still is sound. With the immense availability of non-hardware mixing capable sound chips (or at least not with ALSA), especially embedded into motherboards. This might not be considered as "infrastructural" as it actually is, because since the release of kernel 2.6 ALSA became the "backend" for sound in Linux, but Pulse Audio brings to Linux what the Windows Sound System does in Windows or what Core Audio does for Mac. Or at least it tries to. What about a review article of the progress made in Pulse Audio and what can we expect from it in the coming releases of this sound system for Linux? From the start it does look like a more promising sound system than ESD and aRTs have ever been for a number of reasons: Destkop Independent, it could be made to run in text mode (and actually that should be the default behavior), real-time scheduling capabilities, full Policy Kit compliance, small CPU time fingerprint, small memory fingerprint, fast mixing of different sound streams, etc. It looks awesome in paper, but its implementations (on the distros that have actually adopted it) leave some times much to be desired.

Still I think that an article on it and how its progress has been (especially now that Fedora 9 is coming out, and Ubuntu 8.04 has already been released) it would be a good idea to see its evolution in the distributions that have actually incorporated it (Fedora, since 8 and Ubuntu, since 8.04 IIRC) and compare its implementations. What do you think?

One key aspect that still seems to be a problem with PA is sound capture and recording. I'm not aware of any "Pulse Audio compatible" sound recorder, and even direct manipulation of ALSA devices doesn't seem to work when Pulse is running. Maybe you could get word on when can we expect these to work with Pulse from the devs?

[deanjo]

opensuse has jumped on the pulseaudio bandwagen as well

http://dev.compiz-fusion.org/~cyberorg/2007/11/22/pulseaudio-compiz-for-sound-on-opensuse/

[Thetargos]

More than compiz for sound I tend to call it the equivalent to the X server for Sound. Not exactly the low level stuff of the drivers, but sure enough the basic infrastructure for all you "see" in an X session

[givemesugarr]

pulseaudio is far better than esd and arts (which by the way has been dropped) and is the only possible alternative to jack, that is still the best choice.

anyway if i were to place my bet it would be over another system: phonon.
phonon isn't just a sound server but a multimedia framework. if you try to look at the phonon features you'll see that it handles not just the sound or video stream but also the engine itself. with phonon you could dramatically decrease developing of multimedia apps since the only thing that you have to do is to use the phonon controls inside your app.
surely phonon in the near future will integrate directly also pulseaudio (if it doesn't support it already) as now has support for xine-lib (kde4-phonon) and gstreamer (qt-phonon), that support pulseaudio themselves. but integrating pulseaudio directly would remove a good piece of code from this mm libs and centralize more the apps integration.

[deanjo]

pulseaudio is far better than esd and arts (which by the way has been dropped) and is the only possible alternative to jack, that is still the best choice.

anyway if i were to place my bet it would be over another system: phonon.
phonon isn't just a sound server but a multimedia framework. if you try to look at the phonon features you'll see that it handles not just the sound or video stream but also the engine itself. with phonon you could dramatically decrease developing of multimedia apps since the only thing that you have to do is to use the phonon controls inside your app.
surely phonon in the near future will integrate directly also pulseaudio (if it doesn't support it already) as now has support for xine-lib (kde4-phonon) and gstreamer (qt-phonon), that support pulseaudio themselves. but integrating pulseaudio directly would remove a good piece of code from this mm libs and centralize more the apps integration.

And there lies the current problem with sound in linux today, we have soooooo many projects that overlap in what they function as that they become a dependency/conflict hell. While I agree that phonon & solid are a step in the right direction, the political side of linux will never allow it to become a standard (/glares at gnome devs).

[givemesugarr]

And there lies the current problem with sound in linux today, we have soooooo many projects that overlap in what they function as that they become a dependency/conflict hell. While I agree that phonon & solid are a step in the right direction, the political side of linux will never allow it to become a standard (/glares at gnome devs).

well, i think that gnome would devs would came out with something similar. the thing is that firefox devs have decided to go with qt4 and webkit for the next firefox 4 and they're really sorry that they haven't took this decision for the v3. also yast has now completely switched to qt4, nokia will switch its future apps on qtopia from gtk and i would see more and more projects switching to it, since now qt is really superior to gtk. in the past qt has been less performant and had a lesser quality gui renderer but now this has chaged and its integration is far better than gtk one. so i could finally get rid of the whole apps that use gnome and gtk forever. i hate having installed a lot of gnome crap just to have one program using it and to have problems with qt styles not going in the right way in gtk apps.

[deanjo]

well, i think that gnome would devs would came out with something similar. the thing is that firefox devs have decided to go with qt4 and webkit for the next firefox 4 and they're really sorry that they haven't took this decision for the v3. also yast has now completely switched to qt4, nokia will switch its future apps on qtopia from gtk and i would see more and more projects switching to it, since now qt is really superior to gtk. in the past qt has been less performant and had a lesser quality gui renderer but now this has chaged and its integration is far better than gtk one. so i could finally get rid of the whole apps that use gnome and gtk forever. i hate having installed a lot of gnome crap just to have one program using it and to have problems with qt styles not going in the right way in gtk apps.

I do hear your pain reguarding gtk. I long abandoned gtk for my own development projects (sorry, I'm not a GTK masochist). I totally 100% agree that qt4 has left GTK in the dust. Now if only those Gnome devs would lick their wounds and adapt. I doubt it would ever happen, not because of a technical POV, but because of blind pride and stubborness. More dev groups in linux have to start getting unified. Beryl / Compiz learned that lesson and did the smart thing by re-unifying.

As far as FF goes I think John Lilly's comment on keeping Gecko alive until now was the "biggest mistake since U.S. Navy?s decision to install Windows NT on a warship which had to tow the crippled ship back to port" pretty much is bang on.

[givemesugarr]

I do hear your pain reguarding gtk. I long abandoned gtk for my own development projects (sorry, I'm not a GTK masochist). I totally 100% agree that qt4 has left GTK in the dust. Now if only those Gnome devs would lick their wounds and adapt. I doubt it would ever happen, not because of a technical POV, but because of blind pride and stubborness. More dev groups in linux have to start getting unified. Beryl / Compiz learned that lesson and did the smart thing by re-unifying.

As far as FF goes I think John Lilly's comment on keeping Gecko alive until now was the "biggest mistake since U.S. Navy?s decision to install Windows NT on a warship which had to tow the crippled ship back to port" pretty much is bang on.

that declaration makes me to think that the release time between firefox 3 and 4 will be quite reduced when compared to the one between 2 and 3. the fact that still drives me mad is the fact that firefox 3 will not have a qt toolkit build but only a gtk+ and a cairo-gtk one. and until this and the other main gtk project (openoffice) will not give the opportunity to switch to qt gtk will still live. the only thing that i'd like is the availability for certain high level projects like gimp, openoffice, gimp, pan and truecrypt to build on qt instead of gtk.

[Thetargos]

Err... GTK stands for GIMP Tool Kit

At any rate, I didn't see this turning into a GTK Vs QT debate

If phonon is such as a good framework, I'm sure it will displace GStreamer and there would be only one common framework. One of the many problems with Linux and open source in general is that there are more than way to do it ALL, which when pulling in different directions only get things stalled. Just like there are many X11 implementations, thank God there is only ONE being used in Linux distributions, and they all decided to settle in Xorg! imagine if we had Xorg and XFree86 concomitant and NOT compatible with one another? Well THAT'S precisely what happens with stuff like sound. The bare metal infrastructure is (mostly) the same: ALSA, the next part in the stack, though is highly variable. The "how do applications get their streams to ALSA" part. That is why I see Pulse Audio not exactly as the X11 for sound, but the X Server for sound, which in conjunction with the drivers, could be call the X11 of sound (regardless of if they are binary blob drivers, Open Sound System drivers or ALSA drivers). Once the infrastructure is in place, you can have whatever you want on top (just like with X) be it GTK and GNOME/XFCE or QT and KDE.

I won't feed the flamewar over QT and GTK, we all have sides. Provided things work well at the infrastructure level, nothing else should matter for stuff like this. GNOME and KDE have to use the very same basic infrastructure of X to do their "magic".

[givemesugarr]

Err... GTK stands for GIMP Tool Kit

At any rate, I didn't see this turning into a GTK Vs QT debate

If phonon is such as a good framework, I'm sure it will displace GStreamer and there would be only one common framework. One of the many problems with Linux and open source in general is that there are more than way to do it ALL, which when pulling in different directions only get things stalled. Just like there are many X11 implementations, thank God there is only ONE being used in Linux distributions, and they all decided to settle in Xorg! imagine if we had Xorg and XFree86 concomitant and NOT compatible with one another? Well THAT'S precisely what happens with stuff like sound. The bare metal infrastructure is (mostly) the same: ALSA, the next part in the stack, though is highly variable. The "how do applications get their streams to ALSA" part. That is why I see Pulse Audio not exactly as the X11 for sound, but the X Server for sound, which in conjunction with the drivers, could be call the X11 of sound (regardless of if they are binary blob drivers, Open Sound System drivers or ALSA drivers). Once the infrastructure is in place, you can have whatever you want on top (just like with X) be it GTK and GNOME/XFCE or QT and KDE.

I won't feed the flamewar over QT and GTK, we all have sides. Provided things work well at the infrastructure level, nothing else should matter for stuff like this. GNOME and KDE have to use the very same basic infrastructure of X to do their "magic".

well, alsa won over oss and now it has replaced it in the kernel, pulseaudio is likely to win over esd and arts and be only one to compete with jack for some time. jack is still a little better for some kind of features for what i know. as for multimedia frameworks, i think that the good point is that both can run on the same machine, but still, i'd prefer the option to be able to build an app with my favourite toolkit instead of being absolutely bound to one of them. it's a fact that if you only need pan you'll need a bunch of gnome pacakges, even if there are libraries in qt and kde that can be used to replace some features. this happens because of the lack of scalability.
the new qt has reached a good point of scalability when compared to gtk and with the new version the developing process has been really sped up.
i think that gtk devs would come with something to get back (actually some time ago gnome+gtk was a real winner over kde in terms of scalability and ease of developing), but now, it's quite evident that it is has lost its lead.

the best thing, in my opinion, would be an abstraction layer to be built on top of xorg that gtk or qt could use and devs could build something over that layer that compiles not only on gtk (without qt bother) or only on qt (without gtk bother). this would need the 2 parts to sit around a table and start thinking of a common abstraction layer. this would put a certain order not only in the distro war (every distro has a quite some differences when compared with another one) but also for software houses (like oracle that is a real pain to install on non officially supported distros) and for overall user experience. the linux certification at the moment is still bounded to single distros for this reason. if, instead, there would be a certain layer to be used as it happens for the kernel, that it is more or less the same in all distros, and some real core pacakges like gcc, glibc and libtool, this gap would start to be filled in and this would just come in help for the user experience. obviously this base abstraction layer could be used or not used by users and distros, but it would help the apps integration and interoperation, as well as the overall system scalability.