[vlc-devel] Flamebait: PulseAudio removal

Colin Guthrie gmane at colin.guthr.ie
Tue Nov 30 16:12:10 CET 2010


'Twas brillig, and Rémi Denis-Courmont at 29/11/10 16:25 did gyre and
> 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.

Perhaps. I'm going on comments from some time ago now. Perhaps things
have changed or perhaps I just misunderstood. Who knows.

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

I guess you could look at it that way, but I would have thought it made
sense for a developer to pick one stack and stick with it and try to
make it the best possible stack. That doesn't preclude anyone with a
competing solution trying to better that stack or a part of that stack.

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

Perhaps, but this whole argument that PA is in any way "gnome specific"
is just bullshit (not saying that's what you said, it's just a general
statement). It specifically doesn't use glib in it's core, although does
integrate nicely with glib loop based apps and has a convenience gconf
module (although that is just a glorified module loader/config system,
so hardly of any importance in the overall scheme of things and
something I do intend to factor out at any rate).

I've developed for KDE for a while (not massively, just poking in here
and there as time permits) and the biggest thing that pisses me of
generally about KDE is the cry of "why were we not consulted on $X", and
"we were not involved in $Y". This is complete mince. If people want to
be involved in a project they have to *want* to be involved, they have
to see something and decide, "right, I'm going to research and get
involved in $X and then work out the best way to integrate that to KDE".
That's what I did with the PA support in KDE (a large part because I was
getting highly pissed off at people with that kind of attitude). The few
times Lennart has tried to post to KDE lists to make them aware of
something, it just gets thrown in his face - sure he likes to be
antagonistic at times, but that's just his personality - I don't agree
with all the things he says either, but I can separate these things
pragmatically (and take a light hearted view of it too).

And don't think for a second there is any particular anti-VLC slant here
that warrants some kind of retaliation by avoiding PA. He has this
opinion of just about everything that isn't his install on his systems.
If you use Gentoo you're smoking crack, if you don't use rpm you're
insane, if you try to do your own media decoding then you should be
wearing a jacket that buckles at the back etc. etc. (I've made them all
up, but I'm sure they could be attributed to him!). This is just his way
and how he focuses on the jobs important to him. It's not personal and
it shouldn't be taken that way. I certainly don't when he's critical of
things I've done or said.

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

To avoid something because of personality issues is a real shame. In a
corporate environment people have to do work for people higher up the
chain of command that they can't stand. They do it ultimately because
they are paid and perhaps want to further their career, but ultimately
the overall strategy of doing a body of work is determined because it's
the best route forward, and pretty much factors out micro-management

Is the entire open source community one big happy family? No. Are there
political arguments about trivial things all the time? Yes. Are
technical decisions based on personalities? Sadly, it seems so. I'd have
hoped people were more interested in the FOSS part rather than
individual personalities but I guess everyone has their own reasons for
contributing to the FOSS movement and not everyone is able to be quite
as pragmatic about these things.

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

Oh, I thought VLC could play audio too. I've certainly run e.g. Amarok
or Rhythmbox etc. via X11 protocol on several occasions. I regularly run
VirtualBox on a bigger iron machine than I run for testing purposes.
Having sound is often essential in those circumstances.

And whether something is important to VLC or not is not the only thing
to consider. If the *system* that VLC runs on has a need for these
things, then VLC has to fit in with that and be respectful of the stack
rather than unilaterally imposing policy.

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

Yeah I fully appreciate the need for this just now due to the way things
work. I'd far rather see Linux+PA+raop, OSX+airofoil/general RA stuff
and Windows+$RAOPSYSTEM work such that the stack itself supports these
things rather than having to reinvent the wheel in $APP. It makes much
more logical sense, but I appreciate why this isn't quite there yet on
all platforms.

The power point still stands too. If you want to use VLC on tablets and
and mobile environments for playing audio, then this is something to
really look into. You want to push 2s+ of audio decode into PA and then
just sleep for 2s if at all possible.

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

I'd say there would be less Linux+PA users that would be pissed off than
any other users would be if it were removed. But that's beside the point
really. I think the point still stands that if I pair my bluetooth
headphones with my computer, I want a quick and easy way to direct audio
to them regardless of individual application configuration. Having a
central place of config is still a very desirable goal.

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

I can appreciate the frustration this causes. I'll try and do my best to
help alleviate these problems. Please feel free to ping me directly with
anything that I could help with as I don't keep up-to-date with these
lists all the time.

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

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

Ahh cool. I guess the problem remains that VLC could be compiled against
0.9,22 but still run against 0.9.21 which was my main concern with a
compile-time option (there is no libpulse lib-major difference as the
API is the same).

A runtime check should be fairly simple. Do you want me to take a look
still or do you think the current approach will catch enough of the
problem cases (most users should upgrade all their distro packages
together after all and if you self compile it should be caught too).

Take care



Colin Guthrie

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/]

More information about the vlc-devel mailing list