[vlc-devel] Issue with libVLC and pulse

[Colin Guthrie]

'Twas brillig, and Rémi Denis-Courmont at 29/05/10 16:09 did gyre and
gimble:
> Le samedi 29 mai 2010 17:44:57 Colin Guthrie, vous avez écrit :
>>> It's not particularly difficult to add. But given the very dismissive
>>> attitude of anything not gstreamer from PulseAudio upstream, I couldn't
>>> bother.
>>
>> I wouldn't say that. I've tried very hard to integrate pulse into many
>> things and I put a lot of effort into answering the questions or find
>> out the answers I don't yet know for people when they approach me on
>> either the mailing list or the IRC channel.
> 
> Sorry, I was referring to Lennart's attitude both in real life and on his 
> blog, not yours. IMHO, that's doing PulseAudio a major disservice.
> 
> I'm sure he meant no offense but telling me several times roughly "I should 
> take care of other multimedia framework but I only care about gst anyway", is 
> not very pleasant nor encouraging.

Yeah, not ideal I agree. On a social level, I'll see what I can do to
try and change this.

>>> Not to mention that I am getting quite annoyed with PulseAudio bug #799
>>> on the one hand, and the Gentoo guys complaining about the VLC
>>> workaround for it on the other side.


> Calling XInitThreads() is a problem if:
>  - you don't want to link against Xlib at all (Gentoo), or
>  - you call XOpenDisplay() in some other code paths in the same process
>    before you hit the XInitThreads() code path.
> 
> Now, I would assume that the latter issue makes calling XInitThreads() from 
> libpulse a complete non-starter. It would probably break a bunch of non-thread 
> graphical applications.
> 
> Calling XInitThreads() in LibVLC is not such a big deal. An application that 
> uses LibVLC is totally hosed if it uses Xlib without threads in general. If it 
> fails to do so, it could crash if LibVLC selects the GLX video output, which 
> also depends on Xlib. In older VLC versions, also XVideo output, plain X11 
> output and X11 screen capture depended on Xlib, though not anymore.

Ahh cool. That makes more sense to me then :) Thanks for the clarification.

>> I'll try and take a look and see if I can patch libpulse to use XCB
>> rather than XLIB which should work around the issue (according to the
>> bug report). I doubt it will be too much effort, although I don't
>> currently know much about either XLIB or XCB so I'll have to get into
>> that zone first.

OK, I think I've done the necessary stuff to get XLib out of the client
side. I've attached the patch to the ticket upstream for some further
review. I'm just consulting with another guy who did some changes here
in the past to see if he can comment on something not really directly
related before I push it to master.

Just for convenience:
http://pulseaudio.org/ticket/799

>> Not really practical considering pretty much every mobile environment is
>> using PA due to it's power savings
> 
> Oh sure. And audio policy enforcement too.
> But no mobile device vendor cares about VLC that I know.

Maybe an LGPL relicense will help change this in the future?

>> and all the major desktops are now using it by default.
> 
> You mean Ubuntu, Fedora...
> Most VLC developers use Debian - without PA.

Developers maybe, but where are the users? :) (and don't say on Windows! :D)

Col

-- 

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

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]