Re: Pulseaudio

[Olav Vitters <olav bkor dhs org>]

[ 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 libgnome<something> 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, but makes it annoying to have them installed at the
same time.

> Gustavo repeatedly brought up the compatibility with current
> (closed-source) stuff: PA is also "the compatible sound server". We
> provide compatibility with OSS, ALSA, ESD, GST, LIBAO, Xine, MPlayer,

MPlayer is via a non-standard patch. What is the status of getting this
upstream? I hope it should be easy as the patch only seems to (quickly
looking) use 'pulse' instead of the old 'polypaudio'.

Same for libao. Will pulse go into AO?

> Then, Gustavo played the stability card: Yepp, sure, PA is relatively
> new code. But I mean, esd is more than ten years old these days. And
> you'd call it stable? Come on! PA is stable enough for inclusion in
> F8, and it is actively maintained. And that should be all that
> counts. Oh, and sound is not really life-depending, is it? If you
> lose audio on your desktop all you lose is a bit of background music,
> it's not that PA eats all your files for breakfast. The "stability"
> argument is just a trick to disallow innovation.

This is a weak argument. First you say 'esd' is not stable to support
that Pulseaudio is good enough. I never saw esd crashing. Then you say
it doesn't matter if Pulseaudio crashes.
IMO it is *very* important that apps/libs don't crash.

Your 'is stable enough for F8 and actively maintained': That is all what
you should be saying. The rest makes me wonder.

> Gustavo, PA in F8 is very much different then PA 0.9.6. As suggested
> by Matthias, please try it in F8. You know, Gustavo, that RH did a lot
> of work on PA before we included it in F8, to make it seamless and as
> bug-free as possible? Sure there might be an issue left here and
> there. But that's in every software.

My distro has 0.9.6 and that is the latest I can download. Could you
release the F8 version? I am not prepared to switch distros.

> 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 don't like that setup. It goes from:
 arts -> esd -> pulseaudio -> hw

Would be nice if arts could talk directly to pulseaudio, otherwise I'd
still have a libesd.so forever.

I also have a question about the ALSA setup.
It goes ALSA -> pulseaudio -> ALSA 'hw:0' -> hw

What is that 'hw:0' that is specified in default.pa? Will this always
force plain ALSA using apps to the first ALSA soundcard? Or makes it all
sound go via the first ALSA soundcard?

[..]
> 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". Then, doing all this kind

Is this doable now? How?

Related, say I have 'audacious' running and I start up a movie. Ideally
I want audacious to pause (once had a script around mplayer for that).
However, with Pulseaudio could you also just 'mute' audacious when
mplayer is running? How?

> of "compiz for audio" stuff. For example, what I will probably make
> available in PA pretty soon is the ability to do "spacial" event
> sounds, i.e. if you press a button on the left side of your screen its
> event sound goes out of the left speaker, and vice versa. Or stuff
> like automatically sliding down the volume of all windows that are
> currently not in the foreground. (i.e. you start two totems and only
> the one in the foreground is at 100% volume, the other one at 30% or
> so. And when you switch windows the volumes automatically slided to
> the opposite). Right now, PA basically just provides the
> infrastructure for these kind of things, but after the groundwork is
> now done, I can now focus on the "earcandy" part.

So above question is not available yet? When do you guess it will be and
all the other stuff (e.g. ready for 2.22)?

> 2. Sound events are generated directly via libesd from libgnome. This
>   hard dep sucks as well. What I propose instead is this: I will
>   introduce a new sound event API called "libcanberra", which is
>   intended to be cross-platform, cross-toolkit and well-supported on
>   PA. It basically exports just a single variadic function:
> 
>   cbr_play(c, id,
>            CBR_META_ROLE, "event",
>            CBR_META_NAME, "click-event",
>            CBR_META_SOUND_FILE_WAV, "/usr/share/sounds/foo.wav",
>            CBR_META_DESCRIPTION, "Button has been clicked",
>            CBR_META_ICON_NAME, "clicked",
>            CBR_META_X11_DISPLAY, ":0",
>            CBR_META_X11_XID, "4711",
>            CBR_META_POINTER_X, "46",
>            CBR_META_POINTER_Y, "766",
>            CBR_META_LANGUAGE, "de_DE",
>            -1);
> 
>   If that function is called, the caller should pass as many
>   properites as possible. Then, libcanberra will try to find the right
>   sound file for this event, and contact the sound server for
>   playback. The meta information is passed: to do transparent i18n, for
>   a11y, for sound effects (i.e. the spacial sound effects I mentioned
>   earlier with the POINTER_X and POINTER_Y props).
> 
>   (In reality the API will probably have a couple of more functions,
>   for cacheing, and for predefining properties so that you don't have
>   to specify them for each event again. So maybe 5 functions or so.)
> 
>   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.
> 
>   Advantages: suddenly sound events work for non-gnome apps (i.e. only
>   gtk-using apps) too. We can remove yet another part from libgnome,
>   and last but not least, yet another hard dep on ESD is gone, and
>   not even replaced by one on PA. Not even libcanberra becomes a hard
>   dep of Gtk. Gustavo, Ronald, this is where should rejoice, again.

Interesting. Didn't see this before due to email length.

I do wonder how it will work in practice. Can an app depend on a module
that is only loaded in runtime?

-- 
Regards,
Olav