[vlc-devel] Flamebait: PulseAudio removal

[salsaman]

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




On Sat, Dec 4, 2010 at 9:44 PM, salsaman <salsaman at gmail.com> wrote:
> A runtime check can be done by forking and calling pa_context_get_server_info().
>

Sorry, I meant pa_context_connect().

  pa_threaded_mainloop *pa_mloop=pa_threaded_mainloop_new();

    pa_context *pcon=pa_context_new(pa_threaded_mainloop_get_api(pa_mloop),"VLC");
  pa_context_connect(pcon,NULL,0,NULL);
  pa_threaded_mainloop_start(pa_mloop);

  pa_context_state_t pa_state=pa_context_get_state(pcon);

Then keep checking pa_state until you get either PA_CONTEXT_READY or
you time out.


Salsaman.


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