[vlc-devel] Flamebait: PulseAudio removal

[Colin Guthrie]

'Twas brillig, and Rémi Denis-Courmont at 27/11/10 18:24 did gyre and
gimble:
> 	Hello,
> 
> The VLC PulseAudio output is known to cause huge memory leaks in some 
> circumstances, that have appaled a number of Linux VLC users. I don't know if 
> it is a VLC, a PulseAudio, or more likely a plugin bug.

The only memory leak that I've come across is when using PA on top of
Jack with module-jack-sink (a fairly uncommon setup). This tends to leak
SHM segments. I doubt that's the problem here (if people are clever
enough to setup Jack, they'll probably point VLC directly at jack in
some capacity). Have you got a specific reference to this problem (bug
report etc.) so that I can take a look.

> But this may be a moot issue because:
> 
> * The VLC PulseAudio plugin seems(?) unmaintained.

I've not been following it but I'll try and set some time aside to
rewrite it. I'm very busy at work just now but as the nights daw in,
perhaps I will fine more time. Who knows.

I do know that any rewrite will require changes to how the VLC volume
code works to properly integrate the volume logic (currently when used
with Phonon, the volume control logic will totally bypass libvlc anyway
and control the volumes directly in PA, so it's not an issue there, just
for all other VLC clients).

> * PulseAudio itself is largelly unmaintained. Lennart Poettering decided to 
> reinvent a more interesting wheel, in the form of systemd. And instead of 
> naming a co-release manager for PulseAudio, he let the thing bit rot. I have 
> to guess that RedHat does not really care about PulseAudio, or how could they 
> let such a "critical" piece of Linux so poorly maintained.

I disagree overall. Lennart has been focusing on systemd and I will
agree that that has been a bit of a pain at times, but it doesn't mean
that PA itself has been abandoned, nor that interest from various
parties is not providing plenty interesting commits being merged.

Look at the git tree on both master and stable-queue branches to see
that activity has continued quite happily when Lennart has been away.
I've been shepherding various commits by both Intel and Nokia employees,
as well as people adding specific h/w quirks from Canonical (with access
to more audio hardware) and other contributors (such as Collabora).

While there are various new things we want to add to PA, the core
functionality has stabilised for the time being. The numerous changes in
alsa-drivers and alsa-lib needed to allow PA to work with the latest
features has mostly stabilised now and with each alsa release,
integration with PA becomes smoother. People very rarely appreciate
where bugs really lie. While PA has had numerous bugs (as with any
software), many of the actual problems were simply those it exposed due
to utilising parts of alsa that no other alsa client (including VLC)
made use of. These were not PA bugs, but alsa bugs even if the
"solution" chosen by the ignorant was to "disable PA" rather than
addressing the real cause and reporting bugs. This does not help the
free software ecosystem nor audio on linux one jot.


It has long been stated, and all distribution maintainers know, that
anything that goes into the stable-queue branch in git are patches that
we'd generally recommend for anyone using PA. I regularly push these
changes as packages to stable distros and the development distro alike.
Many distributions have a policy of not backporting new version and by
using a recommended patch list, this was a convenient way to ensure
distro maintainers were able to push the latest fixes to older distros.

That said, I do feel it would have been more useful to do more bugfix
releases and let the distro guys just pull the patches if that's
ultimately what helps (and they can just skip the version and .so bump
commits). I will try to push this policy going forward, to have at least
one release every six months to vaguely fit in with most distro release
cycles (although this policy would have only resulted in one extra PA
release about 6 months ago had it been in place earlier).


> * Lennart pretends that the future of audio on open-source is gstreamer in 
> front of PulseAudio. By enabling PulseAudio, we give him more credits than he 
> deserves.

Lennart has his own priorities here, but he fully accepts that gst is
not appropriate for several use cases (e.g. voip). But that said, are
you saying that any software developer must be
all-other-project-agnostic? That's like saying that any government civil
servant is not allowed to vote or hold a political opinion. There is
absolutely nothing in PA that ties it in any way to GST. Do you expect
the XCB people to write all your XCB Support, do you expect the Qt
people to write your Qt frontend, do you expect the ALSA people to write
your ALSA output?

> * Much of what PulseAudio does, VLC and/or alsa-lib can do, notably 
> resampling, sample format conversion and software mixing. I am yet to find any 
> practical justification for PulseAudio.

This is a tiny part of what PA does. Support for network transparency
(e.g. thin clients or simply SSH'ing to another machine), support for
timer-based scheduling for use in low-power environments (e.g. mobile
phones, tablets etc. - why do you think Nokia and Intel are so
involved?), (proper) support for bluetooth devices, support for network
devices such as UPnP and Apple Airtunes etc. etc. While some of these
can be done outwith PA, they are generally not properly integrated and
require manual configuration and don't deal properly with hotswapping etc.

With each application and framework doing their own thing, they each
individually have to provide audio configuration GUIs leading to poorly
integrated HCI rules and novice users really not having the first clue
what to do with their audio when using $APPLICATION. By providing a
central GUI in the desktop environment for controlling audio devices,
users can have a clearly defined method of making adjustments, which is
much better overall for Linux adoption by the non-l337.


Really, the software mixing and resampling isn't the primary reason to
use PA and if you think that's all it is, I'm not surprised you doubt
it. But to make such bold statements while clearly lacking (or
withholding) knowledge on a given topic does not seem fair.


> * alsa-lib is horrible, but so is libpulse.

I don't disagree, but by the same token libpulse really does make people
think about the realtime nature of audio programming. To try and avoid
such issues will ultimately lead to failure.

But the API is certainly not perfect, the way the buffer metrics are
populates is a primary example of where it sucks. The justification
there is to maintain backwards compatibility which I think is a
reasonable excuse in that case.

> In any case, none of the PulseAudio guys tried to fix the VLC PulseAudio output.

Sorry, but real life gets in the way sometimes. I'm trying my best to
fit in all the things I want to do, but my time is finite. Seeing as
it's obviously a sticking point for you, I'll try and dedicate some time
to this task in particular sometime soon.

> Of course, if we remove PulseAudio, we have to make sure we don't end up using 
> it through OSS or ALSA, as the PulseAudio emulation of those is complete crap 
> and not going to be fixed. Not to worry, this is pretty trivial as long as 
> PulseAudio is run by the user session:
> 
> 	/* PulseAudio hijacks ALSA and OSS defaults. Kill it. */
> 	system("killall pulseaudio");
> 

That wont work and it will be incredibly arrogant (in terms of the
*application* that does this would be considered an "arrogant
application") as to assume that's what the user wants.

I think many PA haters these days are still stuck in their bubble of
hatred. All the major distros ship PA by default and the vast majority
of users are all blissfully ignorant to the fact PA even exists. Only
those in the minority who have a problem or a grudge even really care
about such topics these days.


That said, I do see the need to get more people working on your PA
support. I'll try and help but really you should have just asked for
more help with the PA plugin in vlc rather than make such a post. It
would have been far more productive and positive rather than the
negative light it has currently painted.


Col.


PS FWIW, I will submit a patch to disable, at runtime, the calls to the
xlib stuff in the VLC plugin in the next couple days. I don't remember
getting a reply about how the blacklist stuff you were going to write
would work but hopefully each module will blacklist itself indirectly
when running the vlc_xlib_init() function in which case the patch will
work fine... if the blacklist is higher level (e.g. a static list of
evil modules), please let me know.



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]