[vlc-devel] Flamebait: PulseAudio removal

[Rémi Denis-Courmont]

	Hello,

Le lundi 29 novembre 2010 17:51:20 Colin Guthrie, vous avez écrit :
> > * 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).

I am afraid you couldn't have put it worse. I consider VoIP features (low-
latency, symmetric RTP...) to be one of gstreamer largest if not the largest 
purely technical advantages over LibVLC.

> But that said, are you saying that any software developer must be
> all-other-project-agnostic?

Oh no. Lennart has freedom of opinion. I'm just saying that if he intends to 
make gstreamer/PulseAudio the only 'one' multimedia back-end for Linux/OSS, 
then the VideoLAN project should exert its freedom to avoid PulseAudio.

To put it another way, I am saying that people who pretend to provide system 
features should externally be more agnostic. I doubt D-Bus or upstart would 
have enjoyed the support they now have if they had been, say GNOME/GTK/glib-
specific.

I did consider (re)writing the PA output and adding the input. But I got so 
annoyed with his attitude over time.

> > * 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),

VLC couldn't care less. It cannot do network transparency due to video.

> 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

VLC has to support ROAP natively because PulseAudio is not running on most 
systems that VLC runs on. But you probably know that since both PA and VLC 
reverse-engineered and implemented it at the same time.

As a Linux user, I would be totally fine ditching the VLC implementation. But 
guess what happens then?

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

And the end result is that VLC gets complaints about having its own things, 
never mind that it has to. That's not really an improvement from my VLC 
developer's perspective. Not to mention that many even Linux+PulseAudio users 
would be quite pissed off if VLC stopped providing its own UI controls for 
itself. I mean, I doubt users would be very happy if the VLC user interface 
would reconfigure the whole system through PulseAudio, instead of just the VLC 
instance media.

In all due fairness, the fact that ALSA, Windows and MacOS are more limited is 
not at all PulseAudio's fault, and most of PulseAudio's goals are technically 
good. But unfortunately, this has brought more problems than solutions to us.

> 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.
> 
> 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 think this is already done in 1.2.0-git, but it is static. In other words, 
VLC 1.2.0 requires libpulse 0.9.22 or later. I am not very keen on backporting 
this as we will get a flood of "you suckers, VLC 1.1.6 bugfix releases 
requires a new version of PulseAudio that my distro does not have" messages.

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

This is a run-time check. The plugin probe function is still called, and 
expected to fail before it calls XOpenDisplay().

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis