Re: Pulseaudio

[Lennart Poettering <mztabzr 0pointer de>]

On Sat, 13.10.07 23:55, Olav Vitters (olav bkor dhs org) 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 libgnome<something> 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. 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?

Because Flash is broken. As it appears, it tries to open as many PCM
streams as possible, apparently in an attempt to make use of hw
mixing. However, unlike hw, PA allows you to create quite a bit of
streams before it refuses any further stream creation requests. At
that point PA refuses to take any further streams from any process and
thus becomes a bit unresponsive and OTOH Flash isn't really able to
handle so many streams and freezes.

So, basically, if you use Flash with the PA compat plugin for
libasound not just Flash doesn't work but everything else stops
playing music, too.

> 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."

This is the aforementioned issue. After 64 active connections PA
refuses to take any further.

> 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.

There's no rule that dlopen'ed modules have to be prefixed by "lib" in
the name (for example PA modules are not). But still you might have hit
a distro bug, since on my system those alsa-lib objects are prefixed
with "lib".

> > 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'.

The MPlayer guys didn't react to too reasonable on my last try,
complaning about the PA name change we had back then. To resubmit this
patch has been on my todo list for a while now, but not top priority.

> Same for libao. Will pulse go into AO?

I think it already did. But I am not sure.

> > 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.

I am not saying that it is not important if PA crashes. All I am
saying that there are other things that are a lot more important to
not crash than PA.

> 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.

Sure. The only reason I haven't done this yet is that some features of
0.9.6 haven't been ported over to the new lock-free core of 0.9.7 yet,
and I didn't want to release a new version with regressions in
functionality.

> > 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.

The problem with arts is that is is more a synthesizer than a simple
sound server. It's really hard to properly virtualize, because you'd
have to reimplement most of the synthesizer anew, or at least copy a
lot of code from arts over (C++ uahh!). Not really appealing.

As mentioned, I am not too much into KDE. My secret hope is that KDE4
is going to make arts obsolete for good (it has been practically
unmaintained for ages) and the whole discussion can go
away. Phonon/Xine is being used instead, where the compatibility with
PA is much less of an issue.

> 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?

hw:0 is not part of the default PA config. I am not sure what exactly
you want to know?

You can specify the sound card to use in the ALSA config for the
"pulse:" plugin as much as you can do it for "hw:". However, if you
don't specify anything (which is what I recommend, device
selection should preferably be done by policy in PA, not by the
application), then PA will choose for you. And you can use pavucontrol
to move all streams between devices using pavucontrol, and PA will
remember that setting for the next time.

> [..]
> > 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?

Partially. PA will remember the audio device you last used for an app for
the next invocation. However, it won't pull over existing streams on hotplug.

> 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?

PA cannot do that right now. It's on the todo list, will however
require special app support (of course).

> > 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)?

I don't want to give guarantees. But yes, I am planning to do the
spatial stuff in time to 2.22.

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

Why should it want to "depend" on a module? This stuff is just for the
event sounds generated by "click" events and suchlike, i.e. generic UI
events.For all other sounds, which are specific to the program being
used you'd need to link directly to libcanberra, of course and call
that variadic function wherever applicable.

Lennart

--
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4