Re: PulseAudio dependency raised to 0.9.15
On Sun, 2009-06-14 at 22:37 +0300, Marc-André Lureau wrote: Hi, Most of the recent gnome-volume-control work by Bastien and Lennart is using PulseAudio API = 0.9.15. However, 0.9.14 is the current min dependency version (http://live.gnome.org/TwoPointTwentyseven/ExternalDependencies). I'd like to update the minimum required version to 0.9.15 and the recommended version to 0.9.16 for GNOME. Bastien, Lennart, would you agree on that dependency version? Sure thing, that's already what we're shipping for our 2.26-based distro, and it will be needed for gnome-bluetooth's Bluetooth audio support which should get into 2.28. Can we remove the old code to support 0.9.14 please? :) Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
cd . Le mardi 16 octobre 2007 à 22:14 +0200, Lennart Poettering a écrit : On Sat, 13.10.07 23:55, Olav Vitters ([EMAIL PROTECTED]) wrote: On Fri, Oct 12, 2007 at 09:20:36PM +0200, Lennart Poettering wrote: I am not sure that PA should become part of GNOME. A blessed dependency sure, but really a new module of GNOME? Probably not. Regarding replacing esd. Currently a lot of apps link to libesd.so.0. Pulseaudio doesn't seem to provide a replacement for that lib. Correct. Until libcanberra comes into place, we have to rely on libesd. I assume this is because of libgnomesomething linking against libesd? So if those functions are replaced the apps (after recompiling) would link against libpulse instead? No. The primary reason libgnome pulls in libesd is event sounds. And for those event sounds we'll have libcanberra -- which however becomes a gtk module that is only loaded if necessary. So basically, the libesd dep would go away and not being replace. How is the memory usage of those libs? The on-disk size (not memory) of libesd seems small with 34KB, while libpulse is 236KB. Is there a comparison between these libs regarding memory usage? The difference in memory usage should be minor. But I haven't checked that. Is/will there be some compatibility layer for ESD apps? I know that you can make libesd talk to Pulseaudio. I mean something that you could compile an ESD app against Pulseaudio (using some -devel package that would make it use Pulseaudio functions instead). No. I am not planning this. For the time being people can use our esd compatbility protocol. and everything is fine. Hopefully people are going to switch to other APIs eventually anyway. And for those apps which require libesd they should be using it and use our compat module. Reimplementing libesd seems like major work to me, that isn't really rewarding since we already have the esd compat module for PA, and also the number of apps actuallly using libesd functions (and not supporting multiple backends anyway), are limited. So, for the time being until we can replace the esd-specific code in libgnome libesd will continue to be shiped, although the rest of ESD is not. Hmm, unless I'm mistaken, I think we have a problem here : esound is part of the GNOME platform, which means we are committed to API and ABI stability. So, even if we drop esound from libgnome, we still need to provide libesd compat wrapper for applications which uses it directly. I mean, if we switch to PA, I don't think we still want to keep esound around, just to have libesd.. -- Frederic Crozat [EMAIL PROTECTED] Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Asking for hw mixing in PA is like asking for support for MPEG decoder cards in GST. GStreamer actually has support for dxr3 cards :) My sound cards at home all have hardware mixing; it's in my experience only embedded sound cards (laptops, dell boards, the crap-in-many-ways ICH series...) that only have one hardware channel. My 2 cents, Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Sat, 13.10.07 23:55, Olav Vitters ([EMAIL PROTECTED]) wrote: On Fri, Oct 12, 2007 at 09:20:36PM +0200, Lennart Poettering wrote: I am not sure that PA should become part of GNOME. A blessed dependency sure, but really a new module of GNOME? Probably not. Regarding replacing esd. Currently a lot of apps link to libesd.so.0. Pulseaudio doesn't seem to provide a replacement for that lib. Correct. Until libcanberra comes into place, we have to rely on libesd. I assume this is because of libgnomesomething linking against libesd? So if those functions are replaced the apps (after recompiling) would link against libpulse instead? No. The primary reason libgnome pulls in libesd is event sounds. And for those event sounds we'll have libcanberra -- which however becomes a gtk module that is only loaded if necessary. So basically, the libesd dep would go away and not being replace. How is the memory usage of those libs? The on-disk size (not memory) of libesd seems small with 34KB, while libpulse is 236KB. Is there a comparison between these libs regarding memory usage? The difference in memory usage should be minor. But I haven't checked that. Is/will there be some compatibility layer for ESD apps? I know that you can make libesd talk to Pulseaudio. I mean something that you could compile an ESD app against Pulseaudio (using some -devel package that would make it use Pulseaudio functions instead). No. I am not planning this. For the time being people can use our esd compatbility protocol. and everything is fine. Hopefully people are going to switch to other APIs eventually anyway. And for those apps which require libesd they should be using it and use our compat module. Reimplementing libesd seems like major work to me, that isn't really rewarding since we already have the esd compat module for PA, and also the number of apps actuallly using libesd functions (and not supporting multiple backends anyway), are limited. So, for the time being until we can replace the esd-specific code in libgnome libesd will continue to be shiped, although the rest of ESD is not. For GStreamer, the wiki page says you have to specifically set it as the default sink/src. Why can't it just autodetect it? It is being autodetected these days. support; automatic saving/restoring of per-application devices, volumes; sensible hotplug support; rescueing streams to another audio device, if you accidentaly pull your usb cable; network support; ... the list goes on and on and on. Also, ALSA is Linux specific (though personally I think this doesn't really matter) I the ALSA is Linux specific statement interesting. How would Pulseaudio help port stuff to Windows for example? Wouldn't you still have: app - Pulseaudio - Windows sound server - hardware? Yes. PA runs fine on Windows, but since Vista has a userspace sound system anyway it doesn't really make any sense to actually do so -- unless you want network audio. But PA is still useful on *BSD, Solaris, where ALSA isn't. Yes, it would be good to have a good cross-platform PCM API that would not require any additional sound servers running but would still offer a lof of integration for desktopish stuff. We don't have that right now, but I am working on a (no really announced yet) project called libsydney which is intended to be exactly this. But that's another story and totally irrelevant for the PA discussion right now Gustavo brought up the issue that PA hogs the sound device. Sure we do. The idea is having everything go through PA, so that we can treat everything the same. However, since there are some APIs that are It makes setting up PulseAudio a real pain though. The idea is that your distribution does this for you. Nobody should be setting up audio up anyway, that's really something the system should do for you without manual intervention. And we're getting there. The hotplug part in PA is one part of the solution, then Takashi wants to add some code to ALSA to allow initialization of the mixer controls to some more sane values by default, and hopefully we'll get some support for detecting what cables are plugged in (which modern HDA chips support) and can also do the configuration for surround sound more automatically. The way we have set up PA in F8 most things should work fine out-of-the-box already. You only get stereo by default, but that should be good enough for most cases. Sensible surround support by default is another item on my list. notoriously hard to virtualize (e.g. OSS with mmap) and some areas where you don't want the extra context-switching PA adds (pro audio, for now), there's now a tool called pasuspender which when passed a command line it will execute that, but before doing so suspend PA's sound card access and afterwards resume it again. So, prefix your quake2 invocation with pasuspender and everything should be fine. Also, we now close all audio devices after 1s of idle time by default.
Re: Pulseaudio
Hi, Le mardi 16 octobre 2007 à 22:14 +0200, Lennart Poettering a écrit : Gustavo brought up the issue that PA hogs the sound device. Sure we do. The idea is having everything go through PA, so that we can treat everything the same. However, since there are some APIs that are It makes setting up PulseAudio a real pain though. The idea is that your distribution does this for you. So, if I get it, one day the whole distribution is using ALSA, and the day after it should start using PA instead? How do you expect people to achieve such a miracle without a transition that is made impossible by PA locking the sound device? -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Mon, 15.10.07 02:24, Federico Mena Quintero ([EMAIL PROTECTED]) wrote: As soon as I have a version of this library I will write a small module for gtk (the kind of you can load into every gtk app with --gtk-module) which will basically do what libgnome currently does: hooking into a couple of signals -- but instead of direct calls to libesd it will call the aforementioned libcanberra function with the appropriate parameters. Right now this happens through a rather baroque combination of * libgnomeui/gnome-ui-init.c - sets up the signal hooks, reads the configuration file (which lives in libgnome!). Monitors GConf for changes to the which sound should be played for which event keys. Calls into gnome_triggers_vdo(), an evil API which... * libgnome/gnome-triggers.c - ... was intended to be a generic hook into GNOME to do things when interesting stuff happens, which was never used outside of the event sounds. Calls directly into ESD to play the sounds. Please kill this completely :) * libgnome/gnome-sound.c - Just initializes the sound connection, I think, though it also has ultra-simple APIs to play sound files. If you use a GTK+ module, how will it have the necessary contextual knowledge to generate all the parameters you want to pass into libcanberra? [Is that all contextual information needed?] The current code in libgnome[ui] doesn't have that contextual info, either... It just knows a GtkButton was clicked. The basic idea was to just copy libgnome's behaviour. Seemed good enough for me, for now. Of course, there's always room for improvement, but I didn't want to get side-tracked too much. The nice thing is that since this is just a gtk module not many people will ever see how baroque it actually is ;-) If an app wants to give libcanberra more specific information, and so needs to call cbr_play() directly, how will it keep your GTK+ module from also playing its own sound? This is a good question. Maybe we can add some kind of property to attach to widgets which tells my libcanberra-gtk-bridge-as-gtk-modul thing to not do its thing for this widget, possibly even with a bitmask to disable specific event sounds, but not all. From yourexample, what are things like CBR_META_DESCRIPTION and CBR_META_ICON_NAME for? If the event sounds are shown in the volume control, they should be shown with what they actually mean. Also, besides each stream a small icon should be shown to help identifying the event sound in question. This might also be useful a11y, i.e. to show a textual notification instead of a sound. Admitedly I don't have too much insight into a11y, but at least for stuff like event sounds for completion of long running actions (i.e. CD burning completed, Download completed) it might make sense to disable event sounds and use a notification window instead for a11y. Of course, this somewhat plays into the area libnotify is being used for already -- without the need for anything like libcanberra. The basic idea of that snippet was to show just a few random properties that might be useful to attach to an event sound. Definining which ones actually make sense, and which ones don't is a different issue. And more a policy decision then a technical decision. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Wed, 2007-10-17 at 00:17 +0200, Josselin Mouette wrote: Hi, Le mardi 16 octobre 2007 à 22:14 +0200, Lennart Poettering a écrit : Gustavo brought up the issue that PA hogs the sound device. Sure we do. The idea is having everything go through PA, so that we can treat everything the same. However, since there are some APIs that are It makes setting up PulseAudio a real pain though. The idea is that your distribution does this for you. So, if I get it, one day the whole distribution is using ALSA, and the day after it should start using PA instead? How do you expect people to achieve such a miracle without a transition that is made impossible by PA locking the sound device? It worked pretty well for us in Fedora from 7 to (yet unreleased) 8. Besides, as Lennart already stated, recent PA actually release the sound device if no-one is using it. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Wed, 17.10.07 00:17, Josselin Mouette ([EMAIL PROTECTED]) wrote: Hi, Le mardi 16 octobre 2007 à 22:14 +0200, Lennart Poettering a écrit : Gustavo brought up the issue that PA hogs the sound device. Sure we do. The idea is having everything go through PA, so that we can treat everything the same. However, since there are some APIs that are It makes setting up PulseAudio a real pain though. The idea is that your distribution does this for you. So, if I get it, one day the whole distribution is using ALSA, and the day after it should start using PA instead? How do you expect people to achieve such a miracle without a transition that is made impossible by PA locking the sound device? The transition is perfectly doable with the pulse plugin for libasound. Works fine with most applications. Applications that hardcode the alsa device to use will break, but they are broken already anyway. I spent a lot of time to make the transition with most sound systems we have on Linux right now as smooth as possible - and we have a lot of sound APIS and systems. Most things should work fine out of box if the distribution packages everything properly. And in the worst thing you can use pasuspender like I suggested before. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Fri, 2007-10-12 at 21:20 +0200, Lennart Poettering wrote: [on sounds generated by user events] As soon as I have a version of this library I will write a small module for gtk (the kind of you can load into every gtk app with --gtk-module) which will basically do what libgnome currently does: hooking into a couple of signals -- but instead of direct calls to libesd it will call the aforementioned libcanberra function with the appropriate parameters. Right now this happens through a rather baroque combination of * libgnomeui/gnome-ui-init.c - sets up the signal hooks, reads the configuration file (which lives in libgnome!). Monitors GConf for changes to the which sound should be played for which event keys. Calls into gnome_triggers_vdo(), an evil API which... * libgnome/gnome-triggers.c - ... was intended to be a generic hook into GNOME to do things when interesting stuff happens, which was never used outside of the event sounds. Calls directly into ESD to play the sounds. Please kill this completely :) * libgnome/gnome-sound.c - Just initializes the sound connection, I think, though it also has ultra-simple APIs to play sound files. If you use a GTK+ module, how will it have the necessary contextual knowledge to generate all the parameters you want to pass into libcanberra? [Is that all contextual information needed?] The current code in libgnome[ui] doesn't have that contextual info, either... It just knows a GtkButton was clicked. If an app wants to give libcanberra more specific information, and so needs to call cbr_play() directly, how will it keep your GTK+ module from also playing its own sound? From yourexample, what are things like CBR_META_DESCRIPTION and CBR_META_ICON_NAME for? Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Le vendredi 12 octobre 2007 à 21:20 +0200, Lennart Poettering a écrit : Hi Lennart, I'm sorry I couldn't grab a lock on you at last GUADEC to discuss about using PA in our distribution (Mandriva).. Frederic still loves ESD. ESD is bad, in latency, in features, in code, in everything. I am not sure if you, Frederic, noticed that ESD only supports 2ch, 16bit, 44khz audio. Have you noticed all those 5.1 sound systems popping all around you? Have you noticed that everyone hates esd? And that the most well known trick to get your audio working on your Linux desktop is called killall esd? Noone wants to maintain ESD -- do you? There are just so many reasons why ESD should be obsoleted... Dude, the next one who seriously suggests ESD as our path to the future in desktop I audio I will personally buy a ticket for a time machine, so he can fast-forward for 10 years or so and join the rest of us in 2007! I guess you didn't noticed smiley on my initial remark ;) hat vendor=Mandriva I wasn't criticizing PA itself but the real need for a sound server, inside GNOME itself, from a distribution point of view. Currently, under GNOME, need for a sound server is only for stuff like sound events and I guess most distro are configuring esd to release sound device after a short period of inactivity so most other applications can deal with sound devices without having much. For this particular example, esd is enough and it doesn't scramble the rest of the distro. Of course, we all having our various hacks to deal with cross desktop stuff (like soundwrapper which is wrapping calls to esddsp / artsdsp / aoss ..) but you get the idea. /hat I'm not sure it is up to GNOME (as a project) to jump from one sound server to another. I see this kind of choice as a vendor/distro choice, more than GNOME project choice (if we can get rid of the hard dependency on esound, of course). Regarding cross-desktop support: I personally don't care too much about KDE, but apparently you can set it up just fine like described here: http://pulseaudio.org/wiki/PerfectSetup Xine (which I think is what amarock -- or whatever that awful media player everyone but me loves so much is called -- uses for the hard stuff) also ships a native PA driver. I know it isn't the perfect place to discuss about this, but I still think I should add my comments about this. I'm a little sad you don't care that much about cross-desktop :( I do care, because, even if I'm a GNOME person, I work on a distribution which deeply care about cross desktop, and in this context, we would prefer to have one sound server to rule them all than a myriad of separate solutions, each incompatible with another (moreover, when we see nice cross desktops solutions being used more or more, like dbus or HAL). And we could not seriously ship something like route all sounds from KDE/arts to PA esd wrapper as a real solution, right ? ;) I hope you will release PA 0.9.7 soon so everybody can check the various progress PA team did on it in order to integrate it on soon to be released Fedora. hat vendor=Mandriva As a side note, there are discussions about using PA by default on next MandrivaLinux release but I'm not sold to the idea yet, for the reasons stated above. Maybe PA 0.9.7 will make me change my mind, who knows :) /hat -- Frederic Crozat [EMAIL PROTECTED] Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Sat, 2007-10-13 at 08:28 +1000, Jeff Waugh wrote: quote who=Lennart Poettering (Of the big distros only that spaceboy distro doesn't love us anymore as it seems, as I haven't heard from them in a while) I imagine they're still a bit raw about the last time they tried (I probably pushed for it too early), but that was before Avahi. PulseAudio improved *massively* after you took the Avahi vacation. ;-) It's on the list again for 8.04 -- though I don't suppose you're able to get to FOSSCamp to chat about it? (Having you tell us how Avahi should be done was very useful g) Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Frederic Crozat wrote: hat vendor=Mandriva As a side note, there are discussions about using PA by default on next MandrivaLinux release but I'm not sold to the idea yet, for the reasons stated above. Maybe PA 0.9.7 will make me change my mind, who knows :) /hat Fred, Lennart's 0.9.7 branch is coming soon to cooker. Since Christiaan Welvaart applied my patch to update our libtool it actually works on my machine now! I'll commit it shortly :) (pa 0.9.7 needs libtool 1.5.24 it seems as Lennart pointed out to me!) Col ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Le lundi 15 octobre 2007 à 13:23 +0100, Colin Guthrie a écrit : Frederic Crozat wrote: hat vendor=Mandriva As a side note, there are discussions about using PA by default on next MandrivaLinux release but I'm not sold to the idea yet, for the reasons stated above. Maybe PA 0.9.7 will make me change my mind, who knows :) /hat Fred, Lennart's 0.9.7 branch is coming soon to cooker. Since Christiaan Welvaart applied my patch to update our libtool it actually works on my machine now! I'll commit it shortly :) (pa 0.9.7 needs libtool 1.5.24 it seems as Lennart pointed out to me!) Sorry to play devil advocate here but you can't expect people to judge software quality based on svn branch snapshot. -- Frederic Crozat [EMAIL PROTECTED] Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Mon, 15.10.07 15:57, Frederic Crozat ([EMAIL PROTECTED]) wrote: Le lundi 15 octobre 2007 à 13:23 +0100, Colin Guthrie a écrit : Frederic Crozat wrote: hat vendor=Mandriva As a side note, there are discussions about using PA by default on next MandrivaLinux release but I'm not sold to the idea yet, for the reasons stated above. Maybe PA 0.9.7 will make me change my mind, who knows :) /hat Fred, Lennart's 0.9.7 branch is coming soon to cooker. Since Christiaan Welvaart applied my patch to update our libtool it actually works on my machine now! I'll commit it shortly :) (pa 0.9.7 needs libtool 1.5.24 it seems as Lennart pointed out to me!) Sorry to play devil advocate here but you can't expect people to judge software quality based on svn branch snapshot. Oh, the current lennart branch in PA SVN is pretty much stable. Stable enough for us to push it into F8. The only reason I didn't release this as 0.9.7 yet, is that the core of PA received some non-trivial changes since 0.9.6 and two more exotic modules are not ported over yet. And I wanted to make sure that PA 0.9.7 is no regression in functionality. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Lennart Poettering wrote: On Mon, 15.10.07 15:57, Frederic Crozat ([EMAIL PROTECTED]) wrote: Le lundi 15 octobre 2007 à 13:23 +0100, Colin Guthrie a écrit : Frederic Crozat wrote: hat vendor=Mandriva As a side note, there are discussions about using PA by default on next MandrivaLinux release but I'm not sold to the idea yet, for the reasons stated above. Maybe PA 0.9.7 will make me change my mind, who knows :) /hat Fred, Lennart's 0.9.7 branch is coming soon to cooker. Since Christiaan Welvaart applied my patch to update our libtool it actually works on my machine now! I'll commit it shortly :) (pa 0.9.7 needs libtool 1.5.24 it seems as Lennart pointed out to me!) Sorry to play devil advocate here but you can't expect people to judge software quality based on svn branch snapshot. Oh, the current lennart branch in PA SVN is pretty much stable. Stable enough for us to push it into F8. The only reason I didn't release this as 0.9.7 yet, is that the core of PA received some non-trivial changes since 0.9.6 and two more exotic modules are not ported over yet. And I wanted to make sure that PA 0.9.7 is no regression in functionality. Yup sorry Fred, this is the same version as F8 is using, which I could have made clearer rather than just calling it lennart branch :s Sorry. Col ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
[ Currently trying pulseaudio... ]
On Fri, Oct 12, 2007 at 09:20:36PM +0200, Lennart Poettering wrote:
I am not sure that PA should become part of GNOME. A blessed
dependency sure, but really a new module of GNOME? Probably not.
Regarding replacing esd. Currently a lot of apps link to libesd.so.0.
Pulseaudio doesn't seem to provide a replacement for that lib.
I assume this is because of libgnomesomething linking against libesd?
So if those functions are replaced the apps (after recompiling) would
link against libpulse instead?
How is the memory usage of those libs? The on-disk size (not memory) of
libesd seems small with 34KB, while libpulse is 236KB. Is there a
comparison between these libs regarding memory usage?
Is/will there be some compatibility layer for ESD apps? I know that you
can make libesd talk to Pulseaudio. I mean something that you could
compile an ESD app against Pulseaudio (using some -devel package that
would make it use Pulseaudio functions instead).
For GStreamer, the wiki page says you have to specifically set it as the
default sink/src. Why can't it just autodetect it?
Regarding the PA vs dmix issue, Sven Neumann brought up. Yes, if you
only care about the simplest form of mixing, then dmix is sufficient
for you. However, if we want to provide anything that remotely comes
near to what Vista or MacOS X provides -- then we need some kind of
sound server, just like they are shipping one. (MS likes to call the
sound server a userspace sound system, though, but that's just the
terminology. The imporant fact is that they have a real-time process
which serializes access to the PCM devices). So what does PA offer you
beyond dmix right now? From a user perspective this is: moving streams
on-the-fly between devices; distributing audio on multiple audio
devices at the same time; per-stream volumes; fast-user-switching
support; automatic saving/restoring of per-application devices,
volumes; sensible hotplug support; rescueing streams to another
audio device, if you accidentaly pull your usb cable; network support;
... the list goes on and on and on. Also, ALSA is Linux specific
(though personally I think this doesn't really matter)
I the ALSA is Linux specific statement interesting. How would
Pulseaudio help port stuff to Windows for example? Wouldn't you still
have: app - Pulseaudio - Windows sound server - hardware?
Gustavo brought up the issue that PA hogs the sound device. Sure we
do. The idea is having everything go through PA, so that we can treat
everything the same. However, since there are some APIs that are
It makes setting up PulseAudio a real pain though.
notoriously hard to virtualize (e.g. OSS with mmap) and some areas
where you don't want the extra context-switching PA adds (pro audio,
for now), there's now a tool called pasuspender which when passed a
command line it will execute that, but before doing so suspend PA's
sound card access and afterwards resume it again. So, prefix your
quake2 invocation with pasuspender and everything should be
fine. Also, we now close all audio devices after 1s of idle time by
default. We do this mostly to save power. However this also has the
side effect of releasing the audio device quickly for other apps. The
drawback of course is that many sound cards generate pops and clicks
everytime you open/close the device (some intel hda for example), but
that can probably be worked around in the drivers (according to
Takashi) and I guess you cannot have everything at the same time, so
power saving is more important for now. In practice you probably
shouldn't notice PA's presence at all -- unless you try to play a ALSA
stream to hw:0 and a PA stream at the same time. And last but not
least, we have been shipping a PA plugin for libasound for a while
now. It's enabled by default in F8 and redirects all ALSA audio to
PA -- unless some borked app hard codes hw:0 as device name.
Regarding Flash and PA: As Bastien pointed out, in F8 we ship a plugin
for the flash player which makes it compatible with PA. With that
plugin Flash and PA are perfectly compatible.
My distro doesn't have that library. I hoped the use of the 'perfect
setup' would allow pulseaudio to work (via the alsa-pulseaudio-alsa
method). It doesn't however. Do you know why this is?
I wonder if it is because the flashplugin hardcodes the alsa device.
That or it is because the flashplugin uses the i586 alsa lib (+pulse
plugin), while I run all other pulseaudio apps as x86_64.
Pulseaudio shows the following (many times):
W: sink-input.c: Failed to create sink input: too many inputs per
sink.
W: protocol-native.c: Warning! Too many connections (64), dropping incoming
connection.
and after a while:
E: module-gconf.c: Unable to read or parse data from client.
I think it quits after that.
alsa-plugins is weirdly packaged on my distro; it installs stuff in
/usr/lib{64,}/alsa-lib/, but doesn't make use use the normal 'lib*'.
Probably distro bug,
Re: pulseaudio
David Schleef wrote: On Fri, Oct 12, 2007 at 01:33:29AM +1000, Robert Moonen wrote: But to get back to the original point of allowing hardware mixing if it exists on the sound card, I for one want this, it would definitely be abysmal if I couldn't use the hardware mixer on my au8830 and alsa does a wonderful job of supporting it. How, exactly, would it be abysmal? Because I would lose my hardware graphic equalizer. ;-) -- regards Robert G. Moonen registered Linux user number 298132 All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. Arthur Schopenhauer - German philosopher (1788 - 1860) signature.asc Description: PGP signature signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Mon, 08.10.07 20:02, Matteo Settenvini ([EMAIL PROTECTED]) wrote: Hi! Ok, a little bit late because I was travelling, but here's my reply to the whole PA thread on desktop-devel (as the maintainer of PA). This is a long reply, so you might to want to grab yourself of a cup of coffee (or mango lassi?) before you start reading through it. I'd like to thank davidz, matteo, haddess, jan for jumping in the discussion for PA's defense and replying more quickly than I did. Thanks, dudes! It has been a while since esound has received some attention - releases are almost stalled. Looking at the GNOME wiki, it seems that Pulseaudio is the stronger candidate between alternatives, and that it allows for quite a lot of nifty things. I'm running pulseaudio since four or five months now on two of my desktop systems, both x86 and PPC, and I must say that I'm really satisfied by it. It's quite stable and has very few compelling bugs for the normal user (e.g. when using it as an esound replacement on a machine with more than a logged in user it doesn't share the esd socket, or similar). It also seems to be actively developed, and is shipped by default with Fedora 8. Can it be eligible for inclusion in GNOME 2.22? Coincidentally we discussed just this during the GNOME Summit on sunday. Here are my 10¢ on this and all the issues raised in the whole thread following Matteos proposal. I am not sure that PA should become part of GNOME. A blessed dependency sure, but really a new module of GNOME? Probably not. Fedora now ships PA by default, and SuSE is moving to PA as well. (Of the big distros only that spaceboy distro doesn't love us anymore as it seems, as I haven't heard from them in a while) There are still a couple of rough edges, like that we ship two volume controls: one being the native PA volume control, which can do all kinds of nifty things like per-stream volumes and moving streams between devices. And gnome-volume-control which is much sexier UI-wise (i18n, ...), but exposes a lot of cruft we'd prefer to get rid of (i.e. all kinds of stupid alsa mixer tracks and checkboxes nobody really understands, shows every devices thrice, ...) Resolving this duplication probably needs a little bit tighter integration of PA and GNOME: either the volume control tool in GNOME would need to link directly against PA -- or we'd have to wrap all the special PA features in GST's mixer interfaces -- which I think doesn't make that much sense. Too many abstraction layers are bad, especially if there'd only be a single backend driver which would implement most of it. A couple of direct replies to what people brought up in their emails: Martin Meyer suggested that PA was heavy-weight. This is quite frankly bullshit. It depends how you compile PA. Sure, PA is a little bit bigger than ESD, but not that much. It of course becomes bigger, if you compile *all* the modules we ship. But you don't have to do this -- if you just want the core, then just compile the core and PA is tiny. A lot of embedded people now start to adopt PA -- people which a lot stronger constraints that we generally have on GNOME as a desktop for a PC. So, the bloat, heavy-weight issue is nonsense. You can compile the SVN PA fine with just two external dependencies (ALSA and liboil -- both libraries are nowadays installed on all distros anyway -- so they don't really count) and it works fine. Everything else is optional, and can be split off in seperate packages. And even without those extra modules PA is still very useful. Regarding GST vs. PulseAudio: there is just no vs.! Gstreamer does muxing/demuxing/decoding/encoding of media streams. PA is a low-level PCM-only sound server. They're too different things. You could compare this to X11 and GTK: X11 just does a bit of windowing and drawing for you; GTK does all those UI things on top. PA does just a bit of buffering, mixing, filtering for you; GST does all those nice decoding/encoding/muxing/demuxing things on top. Regarding the PA vs dmix issue, Sven Neumann brought up. Yes, if you only care about the simplest form of mixing, then dmix is sufficient for you. However, if we want to provide anything that remotely comes near to what Vista or MacOS X provides -- then we need some kind of sound server, just like they are shipping one. (MS likes to call the sound server a userspace sound system, though, but that's just the terminology. The imporant fact is that they have a real-time process which serializes access to the PCM devices). So what does PA offer you beyond dmix right now? From a user perspective this is: moving streams on-the-fly between devices; distributing audio on multiple audio devices at the same time; per-stream volumes; fast-user-switching support; automatic saving/restoring of per-application devices, volumes; sensible hotplug support; rescueing streams to another audio device, if you accidentaly pull your usb cable; network support; ... the list goes on and on and on.
Re: Pulseaudio
Hi, On 10/12/07, Lennart Poetering wrote: Ronald, you claim: sound daemon is the right solution _only_ for networked audio. This is also bogus. There's a lot of stuff you want to do in a sound server. For example: policy decisions like everytime I plug in my USB headset in I want all voip playback streams to automcatically switch to it, and everytime i start my voip app i want its stream to go through the usb headset. No, you're confusing one possible solution with it being the only solution (as you do everywhere else in your email and probably more in general when you created PA as well). There's better solutions possible and available, and we should use those. Other than that, you really think I'm going to read over 10% of this email? Ronald ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Hi, On 10/12/07, Lennart Poettering [EMAIL PROTECTED] wrote: I am not sure what I should make of this. Do you want to tell me to go to hell because you know everything better without even reading my response to your FUD? Or maybe just that you don't want to take part on this discussion anymore? I tend to take it as the latter. Dude, what's wrong with you? It's simply too long. I'm not going to pick out what's important or relevant in the discussion. Let me re-phrase it: if you can't make it clear in ~10 lines why PA is a must-have, it probably isn't. How you phrase it is a matter of philosophy. Ronald ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Fri, 12.10.07 17:46, Ronald S. Bultje ([EMAIL PROTECTED]) wrote: On 10/12/07, Lennart Poettering wrote: Ronald, you claim: sound daemon is the right solution _only_ for networked audio. This is also bogus. There's a lot of stuff you want to do in a sound server. For example: policy decisions like everytime I plug in my USB headset in I want all voip playback streams to automcatically switch to it, and everytime i start my voip app i want its stream to go through the usb headset. No, you're confusing one possible solution with it being the only solution (as you do everywhere else in your email and probably more in general when you created PA as well). There's better solutions possible and available, and we should use those. Hmm, there is a better *solution possible and available*? Did I miss something? Could you please point me to the sound system that does at least 10% of what PA does right now? Other than that, you really think I'm going to read over 10% of this email? I am not sure what I should make of this. Do you want to tell me to go to hell because you know everything better without even reading my response to your FUD? Or maybe just that you don't want to take part on this discussion anymore? I tend to take it as the latter. Dude, what's wrong with you? The solution I presented allows you to run GNOME without PA, and even removes the hard ESD dependency. You should be happy with such a solution, and not insulting me. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
quote who=Lennart Poettering (Of the big distros only that spaceboy distro doesn't love us anymore as it seems, as I haven't heard from them in a while) I imagine they're still a bit raw about the last time they tried (I probably pushed for it too early), but that was before Avahi. PulseAudio improved *massively* after you took the Avahi vacation. ;-) - Jeff -- GNOME.conf.au 2008: Melbourne, Australia http://live.gnome.org/Melbourne2008 Do you know what [television news ownership] means to me? It gives me the political muscle I need. - Kerry Packer ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Fri, 2007-10-12 at 18:21 -0400, Ronald S. Bultje wrote: It's simply too long. I'm not going to pick out what's important or relevant in the discussion. Let me re-phrase it: if you can't make it clear in ~10 lines why PA is a must-have, it probably isn't. How you phrase it is a matter of philosophy. I'm really just a lurker of this list but i got too frustrated by your writing to not end my silence. Your two last posts have been highly arrogant and trollish. Lennart was, as he said himself, away during most of the conversation in this thread. Considering all the questions asked and general concerns brought up in this thread and how technical in nature they have been the reply was bound to be long. You are, of course, free to not read it. I bet Lennart could write less then 10 lines to describe why PulseAudio is a must-have, that was however not at all the meaning of that post. He was mearly answering questions and concerns brought up in this thread. Mattias signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
quote who=Lennart Poettering Dude, what's wrong with you? The solution I presented allows you to run GNOME without PA, and even removes the hard ESD dependency. You should be happy with such a solution, and not insulting me. At this point Lennart, I think there's a pretty clear consensus emerging, and you have the option to ignore the statistical (and emotional) outliers. :-) - Jeff -- GNOME.conf.au 2008: Melbourne, Australia http://live.gnome.org/Melbourne2008 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
2007/10/12, Ronald S. Bultje [EMAIL PROTECTED]: Hi, On 10/12/07, Lennart Poettering [EMAIL PROTECTED] wrote: I am not sure what I should make of this. Do you want to tell me to go to hell because you know everything better without even reading my response to your FUD? Or maybe just that you don't want to take part on this discussion anymore? I tend to take it as the latter. Dude, what's wrong with you? It's simply too long. I'm not going to pick out what's important or relevant in the discussion. Let me re-phrase it: if you can't make it clear in ~10 lines why PA is a must-have, it probably isn't. How you phrase it is a matter of philosophy. Anyway, Ronald, I don´t think it´s fair to blame the effort someone does to answer all the points even if its late, it doesn´t encourage people to discuss quitely if you know what I mean. How would you feel if you try to explain your position as good as you can and the people you are talking to don´t even bother to listen at you? On the other hand Lennart, saying someone´s argument is bullshit is not a very good choice either. Let's keep the discussion sane and avoid to turn this into a flame. Ronald ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Un saludo, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Fri, 12.10.07 18:21, Ronald S. Bultje ([EMAIL PROTECTED]) wrote: I am not sure what I should make of this. Do you want to tell me to go to hell because you know everything better without even reading my response to your FUD? Or maybe just that you don't want to take part on this discussion anymore? I tend to take it as the latter. Dude, what's wrong with you? It's simply too long. I'm not going to pick out what's important or relevant in the discussion. The least you could do is grep for Ronald in my email, because I explicitly added your name everytime I was replying to one of the points you raised in one of your emails. Let me re-phrase it: if you can't make it clear in ~10 lines why PA is a must-have, it probably isn't. How you phrase it is a matter of philosophy. ??? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Hi, Thanks for the explanations, but I still have one doubt. But I would be interested to know why PA hogs the sound device. No one explained this yet, and is the #1 question in my mind. As far as I can tell, though I admit I'm no expert and could be wrong, PA should be able to access the sound device without locking it, like any normal application. To put it simply, PA over ALSA/dmix. If dmix was underneath PA, couldn't you still keep doing all those neat things anyway? The way I see it, only applications using ALSA directly don't benefit from PA's features, but at least it would work. Every time I bring this issue the reply is usually but you don't need to do that because of this and that, not an actual explanation of why it can't be done. One use case for the above would be (non-free) flash plugin running as 32-bit program with nspluginwrapper attached to an amd64 epiphany/firefox. Unless you have also PA libraries and alsa plugin replicated in /usr/lib32, audio won't work if you are redirecting everything from ALSA to PA... Yes, I know non-free flash plugin is evil, but you can't easily escape it these days... :-( Thanks in advance. On Fri, 2007-10-12 at 21:20 +0200, Lennart Poettering wrote: On Mon, 08.10.07 20:02, Matteo Settenvini ([EMAIL PROTECTED]) wrote: Hi! Ok, a little bit late because I was travelling, but here's my reply to the whole PA thread on desktop-devel (as the maintainer of PA). This is a long reply, so you might to want to grab yourself of a cup of coffee (or mango lassi?) before you start reading through it. I'd like to thank davidz, matteo, haddess, jan for jumping in the discussion for PA's defense and replying more quickly than I did. Thanks, dudes! It has been a while since esound has received some attention - releases are almost stalled. Looking at the GNOME wiki, it seems that Pulseaudio is the stronger candidate between alternatives, and that it allows for quite a lot of nifty things. I'm running pulseaudio since four or five months now on two of my desktop systems, both x86 and PPC, and I must say that I'm really satisfied by it. It's quite stable and has very few compelling bugs for the normal user (e.g. when using it as an esound replacement on a machine with more than a logged in user it doesn't share the esd socket, or similar). It also seems to be actively developed, and is shipped by default with Fedora 8. Can it be eligible for inclusion in GNOME 2.22? Coincidentally we discussed just this during the GNOME Summit on sunday. Here are my 10¢ on this and all the issues raised in the whole thread following Matteos proposal. I am not sure that PA should become part of GNOME. A blessed dependency sure, but really a new module of GNOME? Probably not. Fedora now ships PA by default, and SuSE is moving to PA as well. (Of the big distros only that spaceboy distro doesn't love us anymore as it seems, as I haven't heard from them in a while) There are still a couple of rough edges, like that we ship two volume controls: one being the native PA volume control, which can do all kinds of nifty things like per-stream volumes and moving streams between devices. And gnome-volume-control which is much sexier UI-wise (i18n, ...), but exposes a lot of cruft we'd prefer to get rid of (i.e. all kinds of stupid alsa mixer tracks and checkboxes nobody really understands, shows every devices thrice, ...) Resolving this duplication probably needs a little bit tighter integration of PA and GNOME: either the volume control tool in GNOME would need to link directly against PA -- or we'd have to wrap all the special PA features in GST's mixer interfaces -- which I think doesn't make that much sense. Too many abstraction layers are bad, especially if there'd only be a single backend driver which would implement most of it. A couple of direct replies to what people brought up in their emails: Martin Meyer suggested that PA was heavy-weight. This is quite frankly bullshit. It depends how you compile PA. Sure, PA is a little bit bigger than ESD, but not that much. It of course becomes bigger, if you compile *all* the modules we ship. But you don't have to do this -- if you just want the core, then just compile the core and PA is tiny. A lot of embedded people now start to adopt PA -- people which a lot stronger constraints that we generally have on GNOME as a desktop for a PC. So, the bloat, heavy-weight issue is nonsense. You can compile the SVN PA fine with just two external dependencies (ALSA and liboil -- both libraries are nowadays installed on all distros anyway -- so they don't really count) and it works fine. Everything else is optional, and can be split off in seperate packages. And even without those extra modules PA is still very useful. Regarding GST vs. PulseAudio: there is just no vs.! Gstreamer does muxing/demuxing/decoding/encoding of media streams. PA is a
Re: Pulseaudio
On Sat, 13.10.07 00:23, Gustavo J. A. M. Carneiro ([EMAIL PROTECTED]) wrote: Hi! But I would be interested to know why PA hogs the sound device. No one explained this yet, and is the #1 question in my mind. As far as I can tell, though I admit I'm no expert and could be wrong, PA should be able to access the sound device without locking it, like any normal application. To put it simply, PA over ALSA/dmix. If dmix was Uh? dmix locks the device too. snip $ aplay -D dmix /dev/urandom $ aplay -D hw:0 aplay: main:545: audio open error: Device or resource busy /snip underneath PA, couldn't you still keep doing all those neat things anyway? The way I see it, only applications using ALSA directly don't benefit from PA's features, but at least it would work. PA is about latency. To get the lowest latency possible, you want to sit as near as possible to the hardware, do as little copies as necessary and because we are a real-time system we also want to take as little locks as necessary. Thus we mmap() the hw buffer of the sound card if possible. However, dmix requires multiple buffers (hw, saturation), i.e. copies, we cannot really mmap it, needs locking (on smp) and is just yet another layer between PA and the hw. Also dmix forces a fixed fragment setting to PA. Also nothing we really want. But you know what? You're welcome to configure PA so that it goes through dmix for playback. It's not what I'd recommend, because i'd recommend to do it the other way round, redirecting output of all alsa apps to PA, but you're welcome to configure it in every way you want. Every time I bring this issue the reply is usually but you don't need to do that because of this and that, not an actual explanation of why it can't be done. It *can* be done. But as explained above, it's not what is good for latency. To keep your latencies low you want only a single RT thread accessing your audio devices, and not one system stacked on the other stacked on the other stacked on the other. One use case for the above would be (non-free) flash plugin running as 32-bit program with nspluginwrapper attached to an amd64 epiphany/firefox. Unless you have also PA libraries and alsa plugin replicated in /usr/lib32, audio won't work if you are redirecting everything from ALSA to PA... Yes, I know non-free flash plugin is evil, but you can't easily escape it these days... :-( As mentioned in my long email we ship a pa plugin for flash in F8, that even works with multilib. This is a non-issue. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Am Samstag, den 13.10.2007, 00:23 +0100 schrieb Gustavo J. A. M. Carneiro: But I would be interested to know why PA hogs the sound device. No one explained this yet, and is the #1 question in my mind. As far as I can tell, though I admit I'm no expert and could be wrong, PA should be able to access the sound device without locking it, like any normal application. To put it simply, PA over ALSA/dmix. If dmix was underneath PA, couldn't you still keep doing all those neat things anyway? The way I see it, only applications using ALSA directly don't benefit from PA's features, but at least it would work. Yes, it is indeed possible. This is exactly how I set up own system, incidentally for the same reason: running 32-bit apps on amd64. Although hopefully 32-bit packages of libpulse and alsa-plugins will arrive in Ubuntu soon. (Perhaps I should have a go at it if I find the time.) Of course dmix adds yet another layer of latency but the most important thing to me for now is that it works. By the way, Lennart: I think PulseAudio kicks ass. With all the bad experiences with ESD we had to endure for years, it is just hard to believe that a user-space piece of software is actually able to deliver audio smoothly, without cracks and pops andwhatnot. But deliver it does. Cheers, --Daniel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Am Dienstag, den 09.10.2007, 10:45 + schrieb Sam Morris: It still hasn't happened. Proprietary games all still use OSS... even Teamspeak, which you would think would be designed to function at the same time as other sound-using programs, uses OSS... meaning that it's impossible to actually use it while playing a game. This is not true. At least id software has switched to ALSA. In fact Quake 4 seems to no longer support OSS at all. --Daniel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
quote who=Nickolay V. Shmyrev I also don't like Pulseaudio for exactly same reasons as Gustavo and Ronald. I don't see how this will improve our desktop or will help our users. I'd like our music or video players to turn down and/or pause when I receive a VoIP call. I'd like delicious plug and play experience with audio hardware (be it USB, bluetooth, whatever). PulseAudio provides a solid infrastructure to provide those features to our users. It's not *just* about audio mixing. - Jeff -- GNOME.conf.au 2008: Melbourne, Australia http://live.gnome.org/Melbourne2008 We've got a great drummer and a great singer. Those are the key positions. When you find a singer and a drummer this good, you don't leave them. - Stone Gossard, Pearl Jam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Thu, 2007-10-11 at 07:34 +1000, Jeff Waugh wrote: quote who=Nickolay V. Shmyrev I also don't like Pulseaudio for exactly same reasons as Gustavo and Ronald. I don't see how this will improve our desktop or will help our users. I'd like our music or video players to turn down and/or pause when I receive a VoIP call. I'd like delicious plug and play experience with audio hardware (be it USB, bluetooth, whatever). PulseAudio provides a solid infrastructure to provide those features to our users. It's not *just* about audio mixing. It's also about power saving (especially with the ongoing work in ALSA's hrtimer support), legacy applications support (ie. all the GNOME apps), pure bug fixing (esound has architectural issues that are unfixable), actually working for video playback (synchronisation actually works). And it has fun bits like simultaneous multiple sound cards output (output to both your streaming device and your actual speakers), on-the-fly output switching (try that with esd...), and remote output integration with avahi (select the other outputs on your local network easily). It also works on FreeBSD, and Solaris. -- Bastien Nocera [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
quote who=Ronald S. Bultje Daemons for sound routing are not just suboptimal, they are wrong. We have better ways (at least on Linux) nowadays. Any solution based on the idea of a userspace daemon is wrong. Not just suboptimal (which is unacceptable, because ALSA directly is - for Linux users - very much so optimal, and that's 90% of your userbase), not just still somewhat acceptable (because it isn't, we've ditched esound for that very reason) and definitely not required because a small subgroup of your user population needs it (crippling for the sake of network users - yeah right). I get so sick of people saying but I don't *want* a sound daemon, ALSA can do it all!. It's so irritating because ALSA's solution for mixing on the vast majority of modern sound hardware is to have to use dmix, and *dmix is a sound daemon* - it's fundamentally doing *exactly* the same thing that pulseaudio does, except that it forks whichever process happens to open the audio device first instead of being an explicit separate binary. Plus, it traditionally hasn't even done a very good job of being a sound mixer. It does crappy resampling, gives poor feedback on the number of unplayed samples and drops out just as much as a normal sound daemon because it's just a process with normal privileges - all problems that PulseAudio doesn't have when configured correctly (configured so that it can obtain realtime privs, that is). And of course there's the things the PA can do that bare ALSA never will: * Sample caching * Low latency per-process volume control. * Graceful handling and policy for on-the-fly device removal and insertion * Decent OSS emulation that doesn't cut software-mixing out of the loop * Drop in esd replacement for backwards compatibility. And last, and actually one of the minor features: networked audio. Jan. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Wed, 2007-10-10 at 15:46 +0200, Matteo Settenvini wrote: Anyway, even if PA isn't *THE* answer, ALSA isn't, either, for the reasons already expressed in this thread. So, what do you purpose? IMHO Helge Bahmann got it right: he designed an AUDIO extension for X Window: http://www.chaoticmind.net/~hcb/murx/xaudio Being in the X server, you gain network transparency and A/V sync. There's no reason PA or gstreamer couldn't have a sink for that. Xav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Thu, 2007-10-11 at 20:31 +1000, Jan Schmidt wrote: quote who=Ronald S. Bultje Daemons for sound routing are not just suboptimal, they are wrong. We have better ways (at least on Linux) nowadays. Any solution based on the idea of a userspace daemon is wrong. Not just suboptimal (which is unacceptable, because ALSA directly is - for Linux users - very much so optimal, and that's 90% of your userbase), not just still somewhat acceptable (because it isn't, we've ditched esound for that very reason) and definitely not required because a small subgroup of your user population needs it (crippling for the sake of network users - yeah right). I get so sick of people saying but I don't *want* a sound daemon, ALSA can do it all!. It's so irritating because ALSA's solution for mixing on the vast majority of modern sound hardware is to have to use dmix, and *dmix is a sound daemon* - it's fundamentally doing *exactly* the same thing that pulseaudio does, except that it forks whichever process happens to open the audio device first instead of being an explicit separate binary. You are mistaken. ALSA dmix does not require any daemon. I suspect it uses SYSV IPC to make all processes do some kind of distributed mixing, with no daemon required. Plus, it traditionally hasn't even done a very good job of being a sound mixer. It does crappy resampling, gives poor feedback on the number of unplayed samples and drops out just as much as a normal sound daemon because it's just a process with normal privileges - all problems that PulseAudio doesn't have when configured correctly (configured so that it can obtain realtime privs, that is). Even if dmix is buggy, why can't it be fixed instead. And not to mention that even my desktop PC with ultra cheap motherboard has builtin sound which supports hardware mixing. I am pretty sure I'm not using any kind of software mixing at the moment: neither dmix nor esd nor pulseaudio. I just think that, by default, users should be given a chance to experience audio with hardware mixing, if the hardware supports it. But most importantly, I wouldn't mind PulseAudio too much *if it worked correctly*. As it is now, maybe it isn't PA's fault, maybe it's the linux kernel's fault for not having a good enough process scheduler, but the sad truth is that PA's sound skips (I mean I hear audio clicks when switching workspaces). I believe when people say it doesn't skip for their hardware, but I expect people to believe me when I say it does skip for me. And of course there's the things the PA can do that bare ALSA never will: * Sample caching * Low latency per-process volume control. * Graceful handling and policy for on-the-fly device removal and insertion Those are nice features, but all summed together they don't come near to skipless sound that raw ALSA provides. * Decent OSS emulation that doesn't cut software-mixing out of the loop OSS is deprecated. * Drop in esd replacement for backwards compatibility. I already do not use esd. And last, and actually one of the minor features: networked audio. That should be an extra layer *on top of* basic sound, not a replacement layer. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pulseaudio
Hi Jeff, On 10/11/07, Jeff Waugh wrote: quote who=Nickolay V. Shmyrev I also don't like Pulseaudio for exactly same reasons as Gustavo and Ronald. I don't see how this will improve our desktop or will help our users. I'd like our music or video players to turn down and/or pause when I receive a VoIP call. I'd like delicious plug and play experience with audio hardware (be it USB, bluetooth, whatever). PulseAudio provides a solid infrastructure to provide those features to our users. It's not *just* about audio mixing. I know most people don't read emails (I got this same reply like 10 times over private email), but like I said in my earlier email, I like all these too, they are very cool, and should be integrated into GNOME, rather today than tomorrow, but without the sound daemon part. The original GNOME SoC project (GSmartMix) did that the right way, and could be used as a basis for this part. Sound daemons are old-fashioned, unnecessary and unwanted. We have better solutions and should use them instead. Ronald ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
quote who=Gustavo J. A. M. Carneiro On Thu, 2007-10-11 at 20:31 +1000, Jan Schmidt wrote: I get so sick of people saying but I don't *want* a sound daemon, ALSA can do it all!. It's so irritating because ALSA's solution for mixing on the vast majority of modern sound hardware is to have to use dmix, and *dmix is a sound daemon* - it's fundamentally doing *exactly* the same thing that pulseaudio does, except that it forks whichever process happens to open the audio device first instead of being an explicit separate binary. You are mistaken. ALSA dmix does not require any daemon. I suspect it uses SYSV IPC to make all processes do some kind of distributed mixing, with no daemon required. The first process to open the sound device is forked in alsalib and *becomes* the dmix mixing daemon. Check it out in your ps listings. All the other programs requiring access to mixing services then deliver their streams to that process via a shared memory mapping. It ends up being fundamentally the same as pulseaudio or esd with autolaunching. Plus, it traditionally hasn't even done a very good job of being a sound mixer. It does crappy resampling, gives poor feedback on the number of unplayed samples and drops out just as much as a normal sound daemon because it's just a process with normal privileges - all problems that PulseAudio doesn't have when configured correctly (configured so that it can obtain realtime privs, that is). Even if dmix is buggy, why can't it be fixed instead. By separating the dmix piece from alsalib, I believe we can do better and provide more. And not to mention that even my desktop PC with ultra cheap motherboard has builtin sound which supports hardware mixing. I am pretty sure I'm not using any kind of software mixing at the moment: neither dmix nor esd nor pulseaudio. I just think that, by default, users should be given a chance to experience audio with hardware mixing, if the hardware supports it. I think you are most likely wrong here. Every motherboard I've seen in the past 4 years with built-in sound has used AC97 with a codec chip, and none of them have provided hardware mixing support. You're probably using dmix and just don't realise. But most importantly, I wouldn't mind PulseAudio too much *if it worked correctly*. As it is now, maybe it isn't PA's fault, maybe it's the linux kernel's fault for not having a good enough process scheduler, but the sad truth is that PA's sound skips (I mean I hear audio clicks when switching workspaces). I believe when people say it doesn't skip for their hardware, but I expect people to believe me when I say it does skip for me. The most likely reason is that you need to give pulseaudio the ability to acquire real-time scheduling privileges, like you do for jackd, because it operates with smaller hardware buffers to achieve lower latency. On a distro that provides PulseAudio integrated, this should happen by default. And of course there's the things the PA can do that bare ALSA never will: * Sample caching * Low latency per-process volume control. * Graceful handling and policy for on-the-fly device removal and insertion Those are nice features, but all summed together they don't come near to skipless sound that raw ALSA provides. See the real-time privs point above, or modify the PA config to have bigger buffers. * Decent OSS emulation that doesn't cut software-mixing out of the loop OSS is deprecated. There are plenty of apps that use it though. That may not matter to you, but backward compatibility is important. * Drop in esd replacement for backwards compatibility. I already do not use esd. You must have the Gnome desktop sounds turned off then. And last, and actually one of the minor features: networked audio. That should be an extra layer *on top of* basic sound, not a replacement layer. If you want to do it so that the apps don't have to know about it, it has to integrate underneath them somewhere. But again, I don't see this as PA's major appeal, it's just a neat side-benefit of building things this way. Jan. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
correctly*. As it is now, maybe it isn't PA's fault, maybe it's the linux kernel's fault for not having a good enough process scheduler, but the sad truth is that PA's sound skips (I mean I hear audio clicks when switching workspaces). I believe when people say it doesn't skip for their hardware, but I expect people to believe me when I say it does skip for me. If you've got VIA video I bet it does. But thats a VIA X problem. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
quote who=Gustavo J. A. M. Carneiro On Thu, 2007-10-11 at 23:28 +1000, Jan Schmidt wrote: quote who=Gustavo J. A. M. Carneiro The first process to open the sound device is forked in alsalib and *becomes* the dmix mixing daemon. Check it out in your ps listings. All the other programs requiring access to mixing services then deliver their streams to that process via a shared memory mapping. It ends up being fundamentally the same as pulseaudio or esd with autolaunching. OK, I see a fork() call in the source code. You're right. There's only one minor difference here which is that dmix uses shared memory, while esd uses unix socket. No idea about PA. PA uses shared memory segments by default. Plus, it traditionally hasn't even done a very good job of being a sound mixer. It does crappy resampling, gives poor feedback on the number of unplayed samples and drops out just as much as a normal sound daemon because it's just a process with normal privileges - all problems that PulseAudio doesn't have when configured correctly (configured so that it can obtain realtime privs, that is). Even if dmix is buggy, why can't it be fixed instead. By separating the dmix piece from alsalib, I believe we can do better and provide more. Except hardware mixing. Except clickless audio. PA currently doesn't pass streams through to hardware that supports mixing, I think. There has been talk about having it do so though, and there's no reason why a separate daemon can't provide that. Are you still unclear on the 2 options for making PulseAudio click-free? Either increase the hardware buffers it uses so that it acts like ALSA, or set it up so it can get real-time privs. And not to mention that even my desktop PC with ultra cheap motherboard has builtin sound which supports hardware mixing. I am pretty sure I'm not using any kind of software mixing at the moment: neither dmix nor esd nor pulseaudio. I just think that, by default, users should be given a chance to experience audio with hardware mixing, if the hardware supports it. I think you are most likely wrong here. Every motherboard I've seen in the past 4 years with built-in sound has used AC97 with a codec chip, and none of them have provided hardware mixing support. You're probably using dmix and just don't realise. If what you say above about forking is true, then I definitely am using hardware mixing (VIA High Definition Audio Controller (rev 10), though this is not the same harware I tried PA on, the one that produced audio clicks). That may be (regarding hardware mixing). Google isn't being helpful in finding me information about that controller and how many input streams it supports. See the real-time privs point above, or modify the PA config to have bigger buffers. I thought real-time required root privs or a suid root daemon... Yes, that's the general case, and the way (for example) Jack does it too. Both Jackd and PA are very careful to drop the root privilege first thing on startup. Nevertheless, even that is no longer necessary - on recent kernels, non-root daemons can be configured to be allowed RT privileges using rtlimits/PAM [1] I already do not use esd. You must have the Gnome desktop sounds turned off then. I do. Yet another feature I don't need and which was getting in the way of perfect sound, so I just disabled it. I turn it off because I find most of the desktop sounds annoying, but I still want the feature to work with whatever solution we end up with, and as you point out - it doesn't at the moment. Jan [1] http://lau.linuxaudio.org/faq/index.php/Capabilities ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pulseaudio
quote who=Gustavo J. A. M. Carneiro On Thu, 2007-10-11 at 20:31 +1000, Jan Schmidt wrote: I get so sick of people saying but I don't *want* a sound daemon, ALSA can do it all!. It's so irritating because ALSA's solution for mixing on the vast majority of modern sound hardware is to have to use dmix, and *dmix is a sound daemon* - it's fundamentally doing *exactly* the same thing that pulseaudio does, except that it forks whichever process happens to open the audio device first instead of being an explicit separate binary. You are mistaken. ALSA dmix does not require any daemon. I suspect it uses SYSV IPC to make all processes do some kind of distributed mixing, with no daemon required. The first process to open the sound device is forked in alsalib and *becomes* the dmix mixing daemon. Check it out in your ps listings. All the other programs requiring access to mixing services then deliver their streams to that process via a shared memory mapping. It ends up being fundamentally the same as pulseaudio or esd with autolaunching. Unless you have hardware mixing. Plus, it traditionally hasn't even done a very good job of being a sound mixer. It does crappy resampling, gives poor feedback on the number of unplayed samples and drops out just as much as a normal sound daemon because it's just a process with normal privileges - all problems that PulseAudio doesn't have when configured correctly (configured so that it can obtain realtime privs, that is). Even if dmix is buggy, why can't it be fixed instead. By separating the dmix piece from alsalib, I believe we can do better and provide more. Get hardware mixing and don't use dmix at all. And not to mention that even my desktop PC with ultra cheap motherboard has builtin sound which supports hardware mixing. I am pretty sure I'm not using any kind of software mixing at the moment: neither dmix nor esd nor pulseaudio. I just think that, by default, users should be given a chance to experience audio with hardware mixing, if the hardware supports it. I think you are most likely wrong here. Every motherboard I've seen in the past 4 years with built-in sound has used AC97 with a codec chip, and none of them have provided hardware mixing support. You're probably using dmix and just don't realise. Which means dmix isn't all that bad after all. But to get back to the original point of allowing hardware mixing if it exists on the sound card, I for one want this, it would definitely be abysmal if I couldn't use the hardware mixer on my au8830 and alsa does a wonderful job of supporting it. But most importantly, I wouldn't mind PulseAudio too much *if it worked correctly*. As it is now, maybe it isn't PA's fault, maybe it's the linux kernel's fault for not having a good enough process scheduler, but the sad truth is that PA's sound skips (I mean I hear audio clicks when switching workspaces). I believe when people say it doesn't skip for their hardware, but I expect people to believe me when I say it does skip for me. The most likely reason is that you need to give pulseaudio the ability to acquire real-time scheduling privileges, like you do for jackd, because it operates with smaller hardware buffers to achieve lower latency. On a distro that provides PulseAudio integrated, this should happen by default. Yes, there also are specific distributions finetuned for realtime work, but they are not always useful for normal work. And of course there's the things the PA can do that bare ALSA never will: * Sample caching * Low latency per-process volume control. * Graceful handling and policy for on-the-fly device removal and insertion Those are nice features, but all summed together they don't come near to skipless sound that raw ALSA provides. See the real-time privs point above, or modify the PA config to have bigger buffers. * Decent OSS emulation that doesn't cut software-mixing out of the loop OSS is deprecated. There are plenty of apps that use it though. That may not matter to you, but backward compatibility is important. * Drop in esd replacement for backwards compatibility. I already do not use esd. You must have the Gnome desktop sounds turned off then. Who wants to hear all those sounds while listening to your favourite music anyway, I for one never have the desktop sounds turned on. And last, and actually one of the minor features: networked audio. That should be an extra layer *on top of* basic sound, not a replacement layer. If you want to do it so that the apps don't have to know about it, it has to integrate underneath them somewhere. But again, I don't see this as PA's major appeal, it's just a neat side-benefit of building things this way. -- regards Robert G. Moonen registered Linux user number 298132 All truth passes through
Re: Pulseaudio
On Fri, 2007-10-12 at 01:20 +1000, Jan Schmidt wrote: Yes, that's the general case, and the way (for example) Jack does it too. Both Jackd and PA are very careful to drop the root privilege first thing on startup. Nevertheless, even that is no longer necessary - on recent kernels, non-root daemons can be configured to be allowed RT privileges using rtlimits/PAM [1] There's also the thing that a real-time process needs to be written in an extremely careful way; basically if it spins it's game over for your system. I know Lennart is doing this the right way in PA by having a baby sitter process (also RT, higher priority) looking after PA. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Thu, 2007-10-11 at 23:28 +1000, Jan Schmidt wrote: The first process to open the sound device is forked in alsalib and *becomes* the dmix mixing daemon. Check it out in your ps listings. All the other programs requiring access to mixing services then deliver their streams to that process via a shared memory mapping. It ends up being fundamentally the same as pulseaudio or esd with autolaunching. AFAIK this deamon doesn't do mixing. It only manages connection to alsa device. dmix uses one shared buffer and each application writes their own samples to buffer using lock free algorithm and is fundamentally different as pulseaudio or esd. http://lkml.org/lkml/2006/1/8/81 Peter Zubaj ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pulseaudio
On Fri, Oct 12, 2007 at 01:33:29AM +1000, Robert Moonen wrote: But to get back to the original point of allowing hardware mixing if it exists on the sound card, I for one want this, it would definitely be abysmal if I couldn't use the hardware mixer on my au8830 and alsa does a wonderful job of supporting it. How, exactly, would it be abysmal? dave... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pulseaudio
On Thu, 2007-10-11 at 10:47 -0400, David Zeuthen wrote: I'm not sure you want to build your case of PA is not right for GNOME based on Pro audio users. This came up during the PulseAudio session at Boston Summit, and it was notable that the conversation went something like: Person B: This should be proposed for 2.22 Person A: Someone objected last time Person C: Well I was the one who objected, and my concern has largely been addressed by the discussion we've had already This was followed by a fairly widespread discussion about pro needs and how basically the people doing the hacking are trying to focus on the baseline case for most desktop users' needs first, and after a few goes around pretty much everyone agreed that this made sense. I know nothing of audio issues, but it seemed to me a very positive meeting, and I hope that GNOME will be able to leverage the hard work these hackers are putting in. Cheers, AfC Sydney signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Tue, Oct 09, 2007 at 10:52:14AM +0100, Gustavo J. A. M. Carneiro wrote: Is there any good reason why Pulse Audio explicitly locks the audio device, unlike any other normal ALSA client? And no, making every app use Pulse Audio by force, just because you can, is not a good reason. If you use hal-autodetect module, PA attaches directly to hardware, which locks the device. I've disabled hal-autodetect and now PA uses default ALSA sink, which comes to be routed through dmix. Now non-pulse ALSA clients work along PA. Of course outputing from PA to dmix will bring tha wrath of PA developers upon your head. Solution blessed as correct is to configure ALSA (alsalib) output to PA, but for me it feels little hacky. It's first thing described on http://www.pulseaudio.org/wiki/PerfectSetup#ALSAApplications -- Tomasz TorczThere exists no separation between gods and men: [EMAIL PROTECTED] one blends softly casual into the other. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Ter, 2007-10-09 at 09:49 -0400, Matthias Clasen wrote: On 10/9/07, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: I am not saying Pulse Audio has these problems. I simply don't know That can easily be helped. Just try gnome 2.20 with pulseaudio in Fedora 8. It works beautifully. I just tried pulseaudio 0.9.6 on Ubuntu Gutsy, and: - Audio stuttering increased dramatically. Most of the time, when I hide/show the rhythmbox window, or when I switch to another workspace (metacity), I hear a very annoying gap in audio. The same thing with ALSA direct hardware access works perfectly with no audio gap; - I noticed when trying to switch RB back to use direct ALSA that the pulse audio server is still using the annoying behaviour of locking the sound device. I had to do killall pulseaudio before I could switch back to direct ALSA sound. And once you tried, you don't have to spread FUD anymore... I tried and I'm still not convinced. Unless there are some special kernel patches in fedora making a big difference, I still hate sound routed through a userspace daemon. I would willingly tolerate it for sound coming from network applications, but it's not a price I want to pay for simple local applications when I don't care about PNP or network sound. IMHO Pulse Audio developers are just being stubborn; I have not yet any good reason why PA and direct ALSA access cannot get along. I'm sorry for being the bad guy here, but someone has to say these things... -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit The universe is always one step beyond logic. -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Il giorno mer, 10/10/2007 alle 14.00 +0100, Gustavo J. A. M. Carneiro ha scritto: I tried and I'm still not convinced. Unless there are some special kernel patches in fedora making a big difference, I still hate sound routed through a userspace daemon. I would willingly tolerate it for sound coming from network applications, but it's not a price I want to pay for simple local applications when I don't care about PNP or network sound. IMHO Pulse Audio developers are just being stubborn; I have not yet any good reason why PA and direct ALSA access cannot get along. You tried and you found it doesn't work for you, and that's fine -- I'm happy to hear your opinion, _expecially_ because it is different than mine. I can say only that passing from ALSA to Pulseaudio *for me*: - decreased overall latency - meant I didn't have to configure it at all, except modifying my asound.conf a little, when I wanted full ALSA apps support. - now I can play two or more totem instances without gaps, and also have other desktop sounds playing in the meantime - has many other benefits, even from a developer point of view (it's easier to code with Pulseaudio APIs). - esd was perfectly replaced, which is the main point. Esound apps works for me out of the box. This is a big win, imho. As for the interrupts sent to the soundcard, a module has been already included in the upcoming 0.9.7 version that should fix that. AFAIK it's because Pulseaudio plays silence when nobody uses it, to avoid popping when a stream starts again, and due to something about the HAL module, too. The only thing I must criticize is you saying that PA devs are stubborn. It seems to me they're really trying to innovate a stagnating and non-homogeneous field, and they should at least be treated with some respect. Stubborn isn't the word I'd have chosen to describe them. Anyway, even if PA isn't *THE* answer, ALSA isn't, either, for the reasons already expressed in this thread. So, what do you purpose? I think that fixing PA is easier than starting it again all over. Else, do we need a Phonon-substitute for GNOME? I'm sorry for being the bad guy here, but someone has to say these things... You're not the bad guy. The point is: are you the *only* guy, even if very vocal? I'd like to hear some more opinions from other people that *don't* like Pulseaudio. C'mon, there ought to be some more on this list. Don't be shy. We need the opinion of everybody (I'm talking serious, no sarcasm meant). Thanks, -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?++ L+++$ E W+++ N++ o? w--- O- M++ PS++ PE- Y+++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Hi, On 10/10/07, Gustavo J. A. M. Carneiro wrote: I tried and I'm still not convinced. Unless there are some special kernel patches in fedora making a big difference, I still hate sound routed through a userspace daemon. I would willingly tolerate it for sound coming from network applications, but it's not a price I want to pay for simple local applications when I don't care about PNP or network sound. And bingo, thanks for voicing this so clearly. Daemons for sound routing are not just suboptimal, they are wrong. We have better ways (at least on Linux) nowadays. Any solution based on the idea of a userspace daemon is wrong. Not just suboptimal (which is unacceptable, because ALSA directly is - for Linux users - very much so optimal, and that's 90% of your userbase), not just still somewhat acceptable (because it isn't, we've ditched esound for that very reason) and definitely not required because a small subgroup of your user population needs it (crippling for the sake of network users - yeah right). Userspace daemons are out. Think of a better solution. Sorry PA devs, you've got some very nifty technology in there, the per-app volume control (which GNOME had a SoC project for, what happened to that?) is very cool and should definitely go in, sound caching is definitely needed, but this is just the wrong solution in the end. Those technologies should go in in some other way, the right[tm] way, and a sound daemon just isn't that. A sound daemon is the right solution _only_ for networked audio. Most GNOME users just don't use networked audio. Here's an alternative, crazy idea that some may consider, just for the sake of the argument. If Linux really is 90% of our userbase, which it most likely is, and people are doing all this effort to make sound daemons with configurable backends and all that, then why not just shift focus and add an OSS backend to ALSA such that it works on Solaris, BSDs etc, and then use ALSA directly? you will say no, but no consider the reverse argument of PA again. It's just as silly. Ronald ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Em Ter, 2007-10-09 às 15:47 +0100, Bastien Nocera escreveu: On Tue, 2007-10-09 at 10:09 +0200, Sven Neumann wrote: Hi, On Tue, 2007-10-09 at 10:04 +0200, Dave Neary wrote: GNOME seems like it's far too high in the stack to include a sound server API - shouldn't we simply depend on it, rather than integrating it into the GNOME platform? Could you perhaps consider to integrate it nicely but not to depend on it? The majority of users doesn't need a sound server. While it would of course be nice to have one that nicely interoperates with the GNOME desktop, it would be a shame if you couldn't run GNOME without running a sound server. It's already a dependency, as it's used in libgnomeui and exported from that API. You can already run GNOME without esound or Pulseaudio, and that's not changing. Given that libgnomeui is on it's way out, where does PulseAudio fit in? I thought the plan was to move apps using libgnomeui to use gstreamer instead. Is that correct? []'s, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Hi! On 10/10/07, Ronald S. Bultje [EMAIL PROTECTED] wrote: Here's an alternative, crazy idea that some may consider, just for the sake of the argument. If Linux really is 90% of our userbase, which it most likely is, and people are doing all this effort to make sound daemons with configurable backends and all that, then why not just shift focus and add an OSS backend to ALSA such that it works on Solaris, BSDs etc, and then use ALSA directly? you will say no, but no consider the reverse argument of PA again. It's just as silly. If I understand correctly, this project exists and is called SALSA (ironically, another ALSA library for embedded environment exists, with the same name). see http://www.4front-tech.com/forum/viewtopic.php?t=1887 IMHO, I would rather just drop the mandatory GNOME esound dependency instead of trying to add PulseAudio as a dependency for 2.22. See live.gnome.org/PulseAudio. The idea of GSmartMix SoC project is not dead.. In some ways, it exists in PulseAudio, but with some noticeable differences. There are just other things to do in other places before that really happen. cheers, -- Marc-André Lureau Ronald ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
You're not the bad guy. The point is: are you the *only* guy, even if very vocal? I'd like to hear some more opinions from other people that *don't* like Pulseaudio. Others are too patient and avoid /me too but if you like, let me state that I also don't like Pulseaudio for exactly same reasons as Gustavo and Ronald. I don't see how this will improve our desktop or will help our users. signature.asc Description: Эта часть сообщения подписана цифровой подписью ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
I disagree with your assertion that userspace audio services are wrong. How about userspace USB drivers or scanner drivers? Is SANE completely the wrong approach to scanning? Gnome has ambitions of being cross-desktop. It can NEVER do that if apps are connecting directly to Alsa, just like apps righting directly to the Windows audio API will never[1] work on Linux. It might be possible to port Alsa to other platforms, but that's still a wrong solution. The sound service allows for abstraction on top of the sound sink. There's nothing wrong with writing to an abstraction layer. Whether Pulse is the right one is not my point here, in case you're thinking that. My point is, don't let apps talk to the low-level sound API. That removes significant flexibility from our users. Martin [1] I'm ignoring Wine for the sake of this argument. On 10/10/07, Ronald S. Bultje [EMAIL PROTECTED] wrote: Hi, On 10/10/07, Gustavo J. A. M. Carneiro wrote: I tried and I'm still not convinced. Unless there are some special kernel patches in fedora making a big difference, I still hate sound routed through a userspace daemon. I would willingly tolerate it for sound coming from network applications, but it's not a price I want to pay for simple local applications when I don't care about PNP or network sound. And bingo, thanks for voicing this so clearly. Daemons for sound routing are not just suboptimal, they are wrong. We have better ways (at least on Linux) nowadays. Any solution based on the idea of a userspace daemon is wrong. Not just suboptimal (which is unacceptable, because ALSA directly is - for Linux users - very much so optimal, and that's 90% of your userbase), not just still somewhat acceptable (because it isn't, we've ditched esound for that very reason) and definitely not required because a small subgroup of your user population needs it (crippling for the sake of network users - yeah right). Userspace daemons are out. Think of a better solution. Sorry PA devs, you've got some very nifty technology in there, the per-app volume control (which GNOME had a SoC project for, what happened to that?) is very cool and should definitely go in, sound caching is definitely needed, but this is just the wrong solution in the end. Those technologies should go in in some other way, the right[tm] way, and a sound daemon just isn't that. A sound daemon is the right solution _only_ for networked audio. Most GNOME users just don't use networked audio. Here's an alternative, crazy idea that some may consider, just for the sake of the argument. If Linux really is 90% of our userbase, which it most likely is, and people are doing all this effort to make sound daemons with configurable backends and all that, then why not just shift focus and add an OSS backend to ALSA such that it works on Solaris, BSDs etc, and then use ALSA directly? you will say no, but no consider the reverse argument of PA again. It's just as silly. Ronald ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Hi, Matteo Settenvini wrote: I'm running pulseaudio since four or five months now on two of my desktop systems, both x86 and PPC, and I must say that I'm really satisfied by it. ... Can it be eligible for inclusion in GNOME 2.22? GNOME seems like it's far too high in the stack to include a sound server API - shouldn't we simply depend on it, rather than integrating it into the GNOME platform? After all, we don't think of dbus or fontconfig as being part of GNOME, but we use them. Cheers, Dave. -- Dave Neary GNOME Foundation member [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Hi, On Tue, 2007-10-09 at 10:04 +0200, Dave Neary wrote: GNOME seems like it's far too high in the stack to include a sound server API - shouldn't we simply depend on it, rather than integrating it into the GNOME platform? Could you perhaps consider to integrate it nicely but not to depend on it? The majority of users doesn't need a sound server. While it would of course be nice to have one that nicely interoperates with the GNOME desktop, it would be a shame if you couldn't run GNOME without running a sound server. Sven ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Ter, 2007-10-09 at 01:17 +0200, Matteo Settenvini wrote: Il giorno lun, 08/10/2007 alle 23.19 +0100, Gustavo J. A. M. Carneiro ha scritto: Last time I tried PulseAudio (over a year ago) it hogged the sound device and did not let any other ALSA client produce sound. Can someone confirm the bug is still there? Just (e.g.) play some music with PulseAudio and then start an ALSA client, check that mixing is being done. If the bug is still there then I would not recommend anyone using PulseAudio. Unless you want to see for example your flash plugin sound to stop working, like it didn't usually work in the old days when it used OSS API. Pulseaudio can do much better than dmix in my opinion. The only thing you need is to tell alsa to use pulse as pcm.!default and ctl.!default, after having installed the relative ALSA plugin. The ALSA plugin is quite stable and works well for me. As for Macromedia Flash 9, it is well known it is a buggy proprietary software with quite a lot of problems. People jumped at it, anyway, and now Pulseaudio has an extra library you can install to have Flash working seamlessly. Much better than with ESD, imho. I don't care only about proprietary applications. You think for example that Second Life Linux client (which is open source) will use Pulse Audio API directly? It will take years before that happens. I remember perfectly well how much time it took for applications to switch from OSS to ALSA, after Linux declared ALSA the official blessed Linux sound API. I loved Pulse Audio when I tried it, but when I noticed it blocked the audio device I immediately had to stop using it. It's good that there's an ALSA plugin to redirect sounds to the Pulse Audio daemon, although I must confess it doesn't sound entirely satisfactory. Why be forced to use a userspace mixing program when hardware mixing would work equally well (or better) in most situations? Non-network audio should not need to be mixed by Pulse Audio on Linux, IMHO. Is there any good reason why Pulse Audio explicitly locks the audio device, unlike any other normal ALSA client? And no, making every app use Pulse Audio by force, just because you can, is not a good reason. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit The universe is always one step beyond logic. -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Tue, 2007-10-09 at 11:52, Gustavo J. A. M. Carneiro wrote: I don't care only about proprietary applications. You think for example that Second Life Linux client (which is open source) will use Pulse Audio API directly? It will take years before that happens. I remember perfectly well how much time it took for applications to switch from OSS to ALSA, after Linux declared ALSA the official blessed Linux sound API. Pulseaudio does enable also to use applications still tied to OSS, btw. It's good that there's an ALSA plugin to redirect sounds to the Pulse Audio daemon, although I must confess it doesn't sound entirely satisfactory. Why be forced to use a userspace mixing program when hardware mixing would work equally well (or better) in most situations? Non-network audio should not need to be mixed by Pulse Audio on Linux, IMHO. I'm not entirely sure, but I guess that software mixing is done only when needed, using hw mixing where available. I may be wrong though. Then PA could be fixed. Is there any good reason why Pulse Audio explicitly locks the audio device, unlike any other normal ALSA client? And no, making every app use Pulse Audio by force, just because you can, is not a good reason. It may be, but not just because you can. Having a unified interface for GNOME would improve stability and uniformity. After all, why telling people to use DBus and porting old applications to a new system, when they could continue using ORBit? Why taking the pain to rework over old apps to use GVFS and not continuing linking to GnomeVFS? More, what if we want to port some GNOME app to a system that doesn't have ALSA? dmix also has not so good latency support, and no sample caching afaik. Also, it cannot control separately volume for different applications (try adjusting your volume for a Totem movie to the maximum and have Evolution ring the X11 bell or in a terminal and if you don't become deaf you'll understand why this makes sense, but it's not just that -- think about having foreground windows having higher volume and bg ones lower, enabling for spacial sound effects). Of course, switching to Pulseaudio is feasible just if it works 99% of times, which it quite does for me (until now, I had only problems with Wesnoth). Writing a plugin or adapting pulseaudio to chew away that last 1% of non-working apps isn't impossible, and we've time until 2.22 to fix it quite well. After all, I had *much more* trouble with esound than not with Pulseaudio, and esound is still shipped by default in a lot of distros. Then there is the point that Fedora and Ubuntu are pushing for PA. Pulseaudio allows quite a lot of things that dmix doesn't. See also http://0pointer.de/public/pulseaudio-presentation-lca2007.pdf. Anyway, if you think Pulseaudio is bad, then GNOME libraries shouldn't even try to link to libesd like they're doing as per now. Cheers, m. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
quote who=Gustavo J. A. M. Carneiro Why be forced to use a userspace mixing program when hardware mixing would work equally well (or better) in most situations? Because the vast majority of audio hardware available today does not *do* hardware mixing, *and* PulseAudio provides many more features and benefits to users than just audio mixing, particularly with regards to programmatic volume control and plug-n-play hardware integration. Audio mixing is *NOT* the #1 feature opportunity here by a long shot! - Jeff -- GNOME.conf.au 2008: Melbourne, Australia http://live.gnome.org/Melbourne2008 For the record, I've not eaten a lot of babies. - Mark Shuttleworth ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Tue, 2007-10-09 at 10:45 +, Sam Morris wrote: On Tue, 09 Oct 2007 10:52:14 +0100, Gustavo J. A. M. Carneiro wrote: I don't care only about proprietary applications. You think for example that Second Life Linux client (which is open source) will use Pulse Audio API directly? It will take years before that happens. I remember perfectly well how much time it took for applications to switch from OSS to ALSA, after Linux declared ALSA the official blessed Linux sound API. It still hasn't happened. Proprietary games all still use OSS... even Teamspeak, which you would think would be designed to function at the same time as other sound-using programs, uses OSS... meaning that it's impossible to actually use it while playing a game. And OpenSolaris is only just *starting* to use OSS :) http://www.opensolaris.org/jive/thread.jspa?threadID=32401tstart=0 Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]GNOME Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On 10/9/07, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: I am not saying Pulse Audio has these problems. I simply don't know That can easily be helped. Just try gnome 2.20 with pulseaudio in Fedora 8. It works beautifully. And once you tried, you don't have to spread FUD anymore... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
El lun, 08-10-2007 a las 22:26 +0200, Matteo Settenvini escribió: It also seems to be actively developed, and is shipped by default with Fedora 8. Also will be the default in upcoming Mandriva 2008 Can it be eligible for inclusion in GNOME 2.22? +1 Thanks a lot :-) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Tue, 2007-10-09 at 10:09 +0200, Sven Neumann wrote: Hi, On Tue, 2007-10-09 at 10:04 +0200, Dave Neary wrote: GNOME seems like it's far too high in the stack to include a sound server API - shouldn't we simply depend on it, rather than integrating it into the GNOME platform? Could you perhaps consider to integrate it nicely but not to depend on it? The majority of users doesn't need a sound server. While it would of course be nice to have one that nicely interoperates with the GNOME desktop, it would be a shame if you couldn't run GNOME without running a sound server. It's already a dependency, as it's used in libgnomeui and exported from that API. You can already run GNOME without esound or Pulseaudio, and that's not changing. -- Bastien Nocera [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Mon, 2007-10-08 at 19:20 -0500, Travis Watkins wrote: On 10/8/07, Bastien Nocera [EMAIL PROTECTED] wrote: That's a bug in ALSA, and it's getting fixed (in ALSA) for when playing sounds, and more recent Pulseaudio will release the device when no streams are playing (thus avoiding ALSA generating all those interrupts). Exact same problem would happen with esound... But esound only causes 40 or so and raises my CPU temp about 2C. The hardware generates the interrupts when the device is opened, because it's the only way ALSA knows to get decent timers (for now). I have a hard time seeing how esound would generate less interrupts than Pulseaudio in the same situation. -- Bastien Nocera [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
El mar, 09-10-2007 a las 16:41 +0200, Frederic Crozat escribió: Le mardi 09 octobre 2007 à 16:17 +0200, Pacho Ramos a écrit : El lun, 08-10-2007 a las 22:26 +0200, Matteo Settenvini escribió: It also seems to be actively developed, and is shipped by default with Fedora 8. Also will be the default in upcoming Mandriva 2008 This is absolutely false. We have not changed sound servers for Mandriva 2008.0, simply because, from a cross desktop distribution point of view, just replacing esound by PulseAudio wouldn't fix the entire problem (we would still have to deal with Arts for KDE). Moreover, esound isn't that bad ;) Sorry, I read it in some place some months ago... Sorry :'( ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Mon, 2007-10-08 at 22:26 +0200, Matteo Settenvini wrote: Hi, I'm new to this list, so sorry if I ask something already discussed. It has been a while since esound has received some attention - releases are almost stalled. Looking at the GNOME wiki, it seems that Pulseaudio is the stronger candidate between alternatives, and that it allows for quite a lot of nifty things. I'm running pulseaudio since four or five months now on two of my desktop systems, both x86 and PPC, and I must say that I'm really satisfied by it. It's quite stable and has very few compelling bugs for the normal user (e.g. when using it as an esound replacement on a machine with more than a logged in user it doesn't share the esd socket, or similar). It also seems to be actively developed, and is shipped by default with Fedora 8. Can it be eligible for inclusion in GNOME 2.22? it looks pretty neat from what was shown at the Boston summit, so yes, I'd vote for its inclusion, although some more integration work needs to be done, but I think it's perfectly doable for 2.22. -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
I agree that PulseAudio is quite nice, I use it on my amd64 system. It has some GTK gui config tools which are nice, but I feel like they would need to be a little simpler if they were going to be included in Gnome. It's pretty powerful and flexible from what I've seen. That part aside... I would love to be able to ditch esound, but I don't know if PulseAudio is something I would want to see tied into the desktop. It's a pretty heavy-weight audio server, full of features and everything, but it's not the simplest thing to configure and some people just won't want it. It also eliminates a certain about of choice that I feel should be left to the distro and/or user. Has anyone asked the Pulse devs if they even want it to be considered for inclusion? Gstreamer seems like the right thing to do here, and I remember this conversation coming up last year. I don't recall what the end decision was, if any. I'm wondering this: what if someone were to re-implement the esound API to simply pipe the sound into gstreamer? Is that possible? Martin On 10/8/07, Matteo Settenvini [EMAIL PROTECTED] wrote: Hi, I'm new to this list, so sorry if I ask something already discussed. It has been a while since esound has received some attention - releases are almost stalled. Looking at the GNOME wiki, it seems that Pulseaudio is the stronger candidate between alternatives, and that it allows for quite a lot of nifty things. I'm running pulseaudio since four or five months now on two of my desktop systems, both x86 and PPC, and I must say that I'm really satisfied by it. It's quite stable and has very few compelling bugs for the normal user (e.g. when using it as an esound replacement on a machine with more than a logged in user it doesn't share the esd socket, or similar). It also seems to be actively developed, and is shipped by default with Fedora 8. Can it be eligible for inclusion in GNOME 2.22? Thanks for any answer, -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?++ L+++$ E W+++ N++ o? w--- O- M++ PS++ PE- Y+++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?++ L+++$ E W+++ N++ o? w--- O- M++ PS++ PE- Y+++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Hi, is a sound server such as esd or pulseaudio still needed at all? As far as I understand, ALSA allows access from multiple applications. It supports hardware mixing and provides dmix as a fallback on systems where hardware mixing is not available. For the casual user, this should be sufficient. Or is it not? Sven ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Hi, On Mon, 2007-10-08 at 22:26 +0200, Matteo Settenvini wrote: Hi, I'm new to this list, so sorry if I ask something already discussed. It has been a while since esound has received some attention - releases are almost stalled. Looking at the GNOME wiki, it seems that Pulseaudio is the stronger candidate between alternatives, and that it allows for quite a lot of nifty things. I'm running pulseaudio since four or five months now on two of my desktop systems, both x86 and PPC, and I must say that I'm really satisfied by it. It's quite stable and has very few compelling bugs for the normal user (e.g. when using it as an esound replacement on a machine with more than a logged in user it doesn't share the esd socket, or similar). It also seems to be actively developed, and is shipped by default with Fedora 8. Can it be eligible for inclusion in GNOME 2.22? I think you really need the maintainer to propose it. Having said that, PulseAudio has been proposed before (IIRC). If you check the archives, I'm sure there are a few threads about it. is a sound server such as esd or pulseaudio still needed at all? As far as I understand, ALSA allows access from multiple applications. It supports hardware mixing and provides dmix as a fallback on systems where hardware mixing is not available. For the casual user, this should be sufficient. Or is it not? ALSA = Advanced *Linux* sound architecture. What about other platforms? Do they have something similar to ALSA (or has ALSA expanded to other platforms and if so, why has the acronym not changed)? Don ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Last time I tried PulseAudio (over a year ago) it hogged the sound device and did not let any other ALSA client produce sound. Can someone confirm the bug is still there? Just (e.g.) play some music with PulseAudio and then start an ALSA client, check that mixing is being done. If the bug is still there then I would not recommend anyone using PulseAudio. Unless you want to see for example your flash plugin sound to stop working, like it didn't usually work in the old days when it used OSS API. On Mon, 2007-10-08 at 22:26 +0200, Matteo Settenvini wrote: Hi, I'm new to this list, so sorry if I ask something already discussed. It has been a while since esound has received some attention - releases are almost stalled. Looking at the GNOME wiki, it seems that Pulseaudio is the stronger candidate between alternatives, and that it allows for quite a lot of nifty things. I'm running pulseaudio since four or five months now on two of my desktop systems, both x86 and PPC, and I must say that I'm really satisfied by it. It's quite stable and has very few compelling bugs for the normal user (e.g. when using it as an esound replacement on a machine with more than a logged in user it doesn't share the esd socket, or similar). It also seems to be actively developed, and is shipped by default with Fedora 8. Can it be eligible for inclusion in GNOME 2.22? Thanks for any answer, -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?++ L+++$ E W+++ N++ o? w--- O- M++ PS++ PE- Y+++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Il giorno lun, 08/10/2007 alle 17.49 -0400, Martin Meyer ha scritto: [...] Gstreamer seems like the right thing to do here, and I remember this conversation coming up last year. I don't recall what the end decision was, if any. I'm wondering this: what if someone were to re-implement the esound API to simply pipe the sound into gstreamer? Is that possible? Pulseaudio isn't a GStreamer contender. In fact, it exists a pulsesink component for gstreamer, very much like there exist a alsasink, an osssink, a esdsink... If I understand correctly, you'd like to have esound be a wrapper around some sort of GStreamer pipeline, that finishes into... into what? A sink, certain. Why not a Pulseaudio sink? And so, why not just eliminate the intermediary? Pulseaudio does want to do some things that pertain to a sound server, like have network transparency capabilities, controlling hardware, and doing low-level resampling and mixing. Since esound is almost dead, Pulseaudio is a viable alternative. Cheers, -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?++ L+++$ E W+++ N++ o? w--- O- M++ PS++ PE- Y+++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?++ L+++$ E W+++ N++ o? w--- O- M++ PS++ PE- Y+++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Mon, 2007-10-08 at 23:55 +0200, Sven Neumann wrote: Hi, is a sound server such as esd or pulseaudio still needed at all? As far as I understand, ALSA allows access from multiple applications. It supports hardware mixing and provides dmix as a fallback on systems where hardware mixing is not available. For the casual user, this should be sufficient. Or is it not? It doesn't allow for samples caching which would be needed if we want decent sound effects for games, or clicks in the UI. Also, esound's API is in the platform, and Pulseaudio has run-time compatibility for those programs that still use it (that's all our games, and applications above libgnomeui). -- Bastien Nocera [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Il giorno lun, 08/10/2007 alle 23.19 +0100, Gustavo J. A. M. Carneiro ha scritto: Last time I tried PulseAudio (over a year ago) it hogged the sound device and did not let any other ALSA client produce sound. Can someone confirm the bug is still there? Just (e.g.) play some music with PulseAudio and then start an ALSA client, check that mixing is being done. If the bug is still there then I would not recommend anyone using PulseAudio. Unless you want to see for example your flash plugin sound to stop working, like it didn't usually work in the old days when it used OSS API. Pulseaudio can do much better than dmix in my opinion. The only thing you need is to tell alsa to use pulse as pcm.!default and ctl.!default, after having installed the relative ALSA plugin. The ALSA plugin is quite stable and works well for me. As for Macromedia Flash 9, it is well known it is a buggy proprietary software with quite a lot of problems. People jumped at it, anyway, and now Pulseaudio has an extra library you can install to have Flash working seamlessly. Much better than with ESD, imho. Regards, -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?++ L+++$ E W+++ N++ o? w--- O- M++ PS++ PE- Y+++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?++ L+++$ E W+++ N++ o? w--- O- M++ PS++ PE- Y+++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On 10/8/07, Matteo Settenvini [EMAIL PROTECTED] wrote: Hi, I'm new to this list, so sorry if I ask something already discussed. It has been a while since esound has received some attention - releases are almost stalled. Looking at the GNOME wiki, it seems that Pulseaudio is the stronger candidate between alternatives, and that it allows for quite a lot of nifty things. I'm running pulseaudio since four or five months now on two of my desktop systems, both x86 and PPC, and I must say that I'm really satisfied by it. It's quite stable and has very few compelling bugs for the normal user (e.g. when using it as an esound replacement on a machine with more than a logged in user it doesn't share the esd socket, or similar). It also seems to be actively developed, and is shipped by default with Fedora 8. Can it be eligible for inclusion in GNOME 2.22? Does it still beat the hell out of your sound card? With the version I have installed it raises my CPU temp about 8C because it's causing like 300 interrupts a second talking to the sound card. Not good for a laptop. -- Travis Watkins http://www.realistanew.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Mon, 2007-10-08 at 23:55 +0200, Sven Neumann wrote: Hi, is a sound server such as esd or pulseaudio still needed at all? As far as I understand, ALSA allows access from multiple applications. It supports hardware mixing and provides dmix as a fallback on systems where hardware mixing is not available. For the casual user, this should be sufficient. Or is it not? IIRC dmix doesn't really work well with fast-user-switching. OTOH, Pulse works just fine with that. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Does it still beat the hell out of your sound card? With the version I have installed it raises my CPU temp about 8C because it's causing like 300 interrupts a second talking to the sound card. Not good for a laptop. Takes 0.7% CPU on average, raises to 2% when playing multiple sounds, on a IBM Thinkpad four-years-old 2.4Ghz P4 laptop. I don't know what version you use, or if it is an issue specific of your system, but I never noticed slowdowns due to pulseaudio. Moreover, a lot of videos lagging with esd now play fine. Cheers, -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?++ L+++$ E W+++ N++ o? w--- O- M++ PS++ PE- Y+++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?++ L+++$ E W+++ N++ o? w--- O- M++ PS++ PE- Y+++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On 10/8/07, Bastien Nocera [EMAIL PROTECTED] wrote: That's a bug in ALSA, and it's getting fixed (in ALSA) for when playing sounds, and more recent Pulseaudio will release the device when no streams are playing (thus avoiding ALSA generating all those interrupts). Exact same problem would happen with esound... But esound only causes 40 or so and raises my CPU temp about 2C. -- Travis Watkins http://www.realistanew.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pulseaudio vs gnome
On 1/20/07, Marc-André Lureau [EMAIL PROTECTED] wrote: On 1/20/07, Ronald S. Bultje [EMAIL PROTECTED] wrote: On Sat, 2007-01-20, Damon chaplin wrote: Before it goes in I'd like to see a clear roadmap for audio in GNOME, with support for things from simple beeps up to pro-audio apps. I guess this means gstreamer, PulseAudio and JACK. Is that the plan? esd is in the platform because it already is. Realistically, it doesn't belong here. Any replacement technology _to have complete feature equiality with esd_ should be completely optional and a user should be snip! That probably means something like GStreamer to make it bearable for applications that really don't care and just want to play song.mp3 or beeps. And that should suffice. This remark pops up an interesting question: do we really want gnome apps linked to GStreamer to play bling? Furthermore, is GStreamer API suitable for a simple desktop applications (nautilus, mozilla, notify, bling API...) ? I have posted a proposal to define an API for desktop sound on freedesktop/dapi/gnome-media mailing lists (without much success) - but once again, we don't care about implementation at this stage (wether it uses a daemon or not, if it use GStreamer or Pulse or anything else). I really think we need to discuss such idea to replace the libgnome sound API. Of course, it would be good to have people from GStreamer/DBus/PulseAudio discuss such idea also. Just an fyi, but In embedded systems running Gtk+, you don't want to have to spend the time to initialize/start up Gstreamer just to play bling. The time lag is far too great. You limit Gstreamer use to items like movie and music playback - not system pings. Sean If you look at the code that use esd directly, its only because libgnome doesn't provide a simple/complete sound API. And now its time to fix libgnome sound to get rid of esd. At the same time, lets bring some new cool things like theming/positionning/introspection control... But that is probably not the good place to discuss this in detail. After FOMS and DAM3, one has said that new mailing lists will be created to discuss desktop audio API. I would like to define also a *sound desktop* API. Where are those mailing lists? anyone? enough for now, best regards, -- Marc-André Lureau, GSmartMix ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pulseaudio vs gnome
Just an fyi, but In embedded systems running Gtk+, you don't want to have to spend the time to initialize/start up Gstreamer just to play bling. The time lag is far too great. You limit Gstreamer use to items like movie and music playback - not system pings. But on systems that will want to do more impressive audio/visual stuff sometimes anyway, such as the Nokia N770/N800, wouldn't you want gstreamer to be loaded and initialized already anyway? Then there shouldn't (theoretically) be any delay in playing a system beep. Obviously, for very simple systems even this would be excessive. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pulseaudio vs gnome
On Sex, 2007-02-02 at 14:19 +0100, Murray Cumming wrote: Just an fyi, but In embedded systems running Gtk+, you don't want to have to spend the time to initialize/start up Gstreamer just to play bling. The time lag is far too great. You limit Gstreamer use to items like movie and music playback - not system pings. But on systems that will want to do more impressive audio/visual stuff sometimes anyway, such as the Nokia N770/N800, wouldn't you want gstreamer to be loaded and initialized already anyway? Then there shouldn't (theoretically) be any delay in playing a system beep. Systems do not want to do impressive audio/visual stuff; it's applications that want that. It makes no sense for all applications to initialize GStreamer if only one or two of them need to do audio or multimedia stuff. If you want to avoid delay when playing a beep, then all apps will have to initialize GStreamer and precache an audio sample. Startup time and memory costs pile up. It's much better to have a simple sound server (which can use GStreamer) and a simple client API; a full fledged GStreamer library is overkill for most apps IMHO. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pulseaudio vs gnome
On Fri, 2007-02-02 at 13:40 +, Gustavo J. A. M. Carneiro wrote: On Sex, 2007-02-02 at 14:19 +0100, Murray Cumming wrote: Just an fyi, but In embedded systems running Gtk+, you don't want to have to spend the time to initialize/start up Gstreamer just to play bling. The time lag is far too great. You limit Gstreamer use to items like movie and music playback - not system pings. But on systems that will want to do more impressive audio/visual stuff sometimes anyway, such as the Nokia N770/N800, wouldn't you want gstreamer to be loaded and initialized already anyway? Then there shouldn't (theoretically) be any delay in playing a system beep. Systems do not want to do impressive audio/visual stuff; it's applications that want that. It makes no sense for all applications to initialize GStreamer if only one or two of them need to do audio or multimedia stuff. If _even one_ of them wants to do it then it may make sense to have it pre-initialized, just as you'd expect esd to be initialized after logging into GNOME now. Assuming that initialization is actually slow. I had not considered per-application memory costs, which is indeed worth worrying about. If you want to avoid delay when playing a beep, then all apps will have to initialize GStreamer and precache an audio sample. Startup time and memory costs pile up. It's much better to have a simple sound server (which can use GStreamer) and a simple client API; a full fledged GStreamer library is overkill for most apps IMHO. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pulseaudio vs gnome
If you want to avoid delay when playing a beep, then all apps will have to initialize GStreamer and precache an audio sample. Startup time and memory costs pile up. It's much better to have a simple sound server (which can use GStreamer) and a simple client API; a full fledged GStreamer library is overkill for most apps IMHO. There is a patch to notification-daemon to play sound on events with gstreamer. Of course it needs support for caching right now and for selection of different sounds, but it can be considered already as a sound server. Thanks a lot to lack for writing the patch. http://trac.galago-project.org/ticket/111 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pulseaudio vs gnome
On Wed, 2007-01-24 at 21:48 +0900, Davyd Madeley wrote: On Fri, 2007-01-19 at 23:36 +, Damon Chaplin wrote: On Fri, 2007-01-19 at 11:36 -0500, Matthias Clasen wrote: Hey, I just wondered what the current state of affairs is in the esound - pulseaudio transition. I found a wiki page (http://live.gnome.org/PulseAudio?highlight=%28pulse%29), but I'm not sure how uptodate it is. Is this something that we can still complete for 2.18 ? Is anybody working on this ? Before it goes in I'd like to see a clear roadmap for audio in GNOME, with support for things from simple beeps up to pro-audio apps. I guess this means gstreamer, PulseAudio and JACK. Is that the plan? Lennart, who develops PulseAudio, recently spoke about it at linux.conf.au: http://mirror.linux.org.au/pub/linux.conf.au/2007/video/talks/211.ogg (disclaimer, I don't know what the video quality is like) He speaks about what PulseAudio can do, why you'd chose it over technology X and how it might integrate with specific problem domain technologies, such as Jack. Might clear some things up. Yes, thanks. It's a very good talk. Lennart agrees that JACK is still needed for pro-audio apps, and that PulseAudio should work alongside it in some way (or possibly even merge with it in the future). Though the details were a bit sketchy. Hopefully we can get him to clarify it a bit more at some point. Damon ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pulseaudio vs gnome
On Sat, 2007-01-20 at 16:26 -0500, Ronald S. Bultje wrote: On Sat, 2007-01-20, Damon chaplin wrote: Before it goes in I'd like to see a clear roadmap for audio in GNOME, with support for things from simple beeps up to pro-audio apps. I guess this means gstreamer, PulseAudio and JACK. Is that the plan? Wait wait wait wait wait. Are you suggesting that all this will be GNOME technology? I thought the whole idea was to say that audio is a system thing? Because it is! On Linux, there is alsa, and if you need software-mixing, then there is dmix, and I'm sure stuff doesn't work for non-Linux, thin clients and some hardcore dudes and those that apparently can't even get their audio working (and then they blame dmix), so there's jack or pulse (and/or both?) for them. So GNOME should include all of that? Please no! I just want it to be possible to use develop audio applications on top of GNOME (without fiddling about to make it all work). I'm not saying JACK should be part of GNOME, though maybe it should become a dependency - it does seem to be used by most audio apps. We have all the technology to produce a decent audio platform. Why not just connect it all together and get it to work out-of-the-box? Damon ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pulseaudio vs gnome
On Sat, 2007-01-20, Damon chaplin wrote: Before it goes in I'd like to see a clear roadmap for audio in GNOME, with support for things from simple beeps up to pro-audio apps. I guess this means gstreamer, PulseAudio and JACK. Is that the plan? Wait wait wait wait wait. Are you suggesting that all this will be GNOME technology? I thought the whole idea was to say that audio is a system thing? Because it is! On Linux, there is alsa, and if you need software-mixing, then there is dmix, and I'm sure stuff doesn't work for non-Linux, thin clients and some hardcore dudes and those that apparently can't even get their audio working (and then they blame dmix), so there's jack or pulse (and/or both?) for them. So GNOME should include all of that? Please no! esd is in the platform because it already is. Realistically, it doesn't belong here. Any replacement technology _to have complete feature equiality with esd_ should be completely optional and a user should be able to use GNOME without needing to use it and without needing to even have it installed. Why? Because the whole soundserver for mixing concept is pointless for many people with a decent soundcard, and for the majority of the remainder, alsa/dmix should suffice. Pulse / jack are undoubtedly really cool techniques on which a whole lot of effort was spent, but they don't belong in GNOME, as part of GNOME or anything like that. We're not networked thin clients, most of us run GNOME on a desktop or laptop, and most of us run a recent Linux distro with a 2.6 kernel. The audience requiring alternate technologies is too small and too varied to justify putting all those technologies in GNOME. They would, at best, be recommended technologies to get audio working in some specific situations (e.g. thin clients, or audio applications with certain low-latency requirements) in a howto or in the GNOME documentation. Other than that, it really isn't our problem. That probably means something like GStreamer to make it bearable for applications that really don't care and just want to play song.mp3 or beeps. And that should suffice. Ronald ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pulseaudio vs gnome
I think that bells and whistles belong in a model similar to Freedesktop Notifications, but all other multimedia functionality should be done with GStreamer directly. On Sun, 2007-01-21 at 00:17 +0200, Marc-André Lureau wrote: On 1/20/07, Ronald S. Bultje [EMAIL PROTECTED] wrote: On Sat, 2007-01-20, Damon chaplin wrote: Before it goes in I'd like to see a clear roadmap for audio in GNOME, with support for things from simple beeps up to pro-audio apps. I guess this means gstreamer, PulseAudio and JACK. Is that the plan? esd is in the platform because it already is. Realistically, it doesn't belong here. Any replacement technology _to have complete feature equiality with esd_ should be completely optional and a user should be I started to write the l.g.o/PulseAudio page just to track the progress and see who is interested to make this happen. Now, its getting interesting and hopefully good thing will happen soon. I agree with what Ronald wrote. Those are technologies that should not be *part of* GNOME. And unfortunately, the dependency GNOME have on esd (which is not really that important btw) is due to the broken API of libgnome. Straight to the point, that is clear that no application should use directly PulseAudio/Jack if they want to be *GNOME compliant* (even if I don't really know what *compliant* mean :). But note that PulseAudio is a bit more than a esd replacement. And we probably have to think how we will provide/export its goodness internal state/parameters/configuration to GNOME. Just take a look at all the cool apps that comes with PulseAudio. Of course, they are a bit complicated, but we can write a simplified preference applet. That makes me slightly think that PulseAudio *might* be part of GNOME anyway, but this should be discussed in the future. Make the sound server choosable/transparent is enough for now. That probably means something like GStreamer to make it bearable for applications that really don't care and just want to play song.mp3 or beeps. And that should suffice. This remark pops up an interesting question: do we really want gnome apps linked to GStreamer to play bling? Furthermore, is GStreamer API suitable for a simple desktop applications (nautilus, mozilla, notify, bling API...) ? I have posted a proposal to define an API for desktop sound on freedesktop/dapi/gnome-media mailing lists (without much success) - but once again, we don't care about implementation at this stage (wether it uses a daemon or not, if it use GStreamer or Pulse or anything else). I really think we need to discuss such idea to replace the libgnome sound API. Of course, it would be good to have people from GStreamer/DBus/PulseAudio discuss such idea also. If you look at the code that use esd directly, its only because libgnome doesn't provide a simple/complete sound API. And now its time to fix libgnome sound to get rid of esd. At the same time, lets bring some new cool things like theming/positionning/introspection control... But that is probably not the good place to discuss this in detail. After FOMS and DAM3, one has said that new mailing lists will be created to discuss desktop audio API. I would like to define also a *sound desktop* API. Where are those mailing lists? anyone? enough for now, best regards, -- Marc-André Lureau, GSmartMix ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pulseaudio vs gnome
On Fri, 2007-01-19 at 11:36 -0500, Matthias Clasen wrote: Hey, I just wondered what the current state of affairs is in the esound - pulseaudio transition. I found a wiki page (http://live.gnome.org/PulseAudio?highlight=%28pulse%29), but I'm not sure how uptodate it is. Is this something that we can still complete for 2.18 ? Is anybody working on this ? Before it goes in I'd like to see a clear roadmap for audio in GNOME, with support for things from simple beeps up to pro-audio apps. I guess this means gstreamer, PulseAudio and JACK. Is that the plan? Damon ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
