[vlc-devel] Issue with libVLC and pulse

[Rémi Denis-Courmont]

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.

> > 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.
> 
> I've not yet come across bug #799 (I must have missed it on the bugs
> mailing list) but since noticing it a couple days ago, I've made moves
> to specifically find out about it and ask some questions. So sorry for
> not being able to act sooner.
> 
> I have to say that I happened to notice the fix in vlc there myself the
> other day and it jumped out at me as being a potential problem. After
> all the bug report itself states that calling this in a libpulse is not
> recommended and the same logic would say that calling it in libvlc would
> be equally not recommended.

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.

And yes, I do imply that any Phonon application should call XInitThreads() 
before XOpenDisplay() anyway. So should web browsers. So should language 
bindings. I realize it's unfortunate - forcing the applications to call 
XInitThreads() early enough is tricky. But I see no way to untangle GLX from 
Xlib, by its design.

Similarly, any LibVLC application should set SIGPIPE to SIG_IGN (and SIGCHLD 
to SIG_DFL) before it "touches" LibVLC, otherwise we cannot warrant correct 
behaviour.

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

IIRC, the main problem is that PulseAudio is using Xlib in several places, so 
it's not difficult, but it's not fast either.

> > So in my opinion, I have to say, use ALSA.
> 
> 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.

> and all the major desktops are now using it by default.

You mean Ubuntu, Fedora...
Most VLC developers use Debian - without PA.

> Anything that really wants to deal with sound output on Linux these days
> needs to be very serious about PA support. I'll try and help as best I
> can as there are still several problems I spotted while reviewing the
> current VLC code (things that immediately spring to mind are the
> assumption that one loop wait will result in the state changes needed
> and also the writing of zeros when starved of buffer input, both of
> which I think *could* result in problems although I need to think about
> it a bit more carefully.

I wouldn't know. The PA plugin was not even written by "core" VLC devs.

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