[vlc-devel] Flamebait: PulseAudio removal

Sun Dec 5 01:44:17 CET 2010

A runtime check can be done by forking and calling pa_context_get_server_info().

Salsaman.

http://lives.sourceforge.net
https://www.ohloh.net/accounts/salsaman

On Tue, Nov 30, 2010 at 12:12 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> Hi,
>
> 'Twas brillig, and Rémi Denis-Courmont at 29/11/10 16:25 did gyre and
> gimble:
>> 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
> personalities.
>
> 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
>
> Col
>
>
>
> --
>
> 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/]
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel
>