[vlc-devel] [PACKAGERS] [RFCv2] PulseAudio removal

[Rémi Denis-Courmont]

Le samedi 2 avril 2011 23:53:45 Pierre Ynard, vous avez écrit :
> > With neither of those, how the bloody heck am I supposed to
> > synchronize audio and video?!
> 
> Maybe it's just that PulseAudio is meant for pure audio foremost,

Uh? PulseAudio is -to simplify- an audio router and mixer. Of course it does 
not care about video as such. But it still tries to provide simple 
synchronization ("latency") as well as intricate and unstable synchronization 
("timing infos"). That wouldn't make much sense if not for lip sync.

> and it's not among its design goals to provide synchronized
> multimedia playback.

I trust mainstream Linux distributionss wouldn't have adopted it then.

> Indeed, I couldn't find on their website any mention
> of "video" or "multimedia". I guess that's fine for audio player
> applications anyway. So we could use it when the input is audio-only,
> but revert to ALSA if there is video too.

How do you revert to ALSA within the boundaries set by PulseAudio?
Keep in mind, PulseAudio owns the ALSA devices. What if an audio player (such 
as another VLC instance w/o video) is using PulseAudio while "we" want to 
render a non-silent movie?

> > Oh yeah, there are the "raw" time infos, but they are explicitly
> > subject to changes, and barely intelligible if you are not a
> > PulseAudio developer.
> 
> Wow. And I guess that's what gstreamer uses?

Yes.

> Sounds like there
> is a deliberate intent to obfuscate the API to deter efforts of
> interoperability with frameworks other than the "preferred" one
> supported by the developers.

To be fair, it sounds more like giving room for future improvements. (Those 
are unlikely to happen if Lennart keeps focused on systemd, but I digress.)

> > Colin, you said it was Lennart right to favor gstreamer. Sure. But if
> > only a few PulseAudio developers understand how this thing work, then
> > his arrogant attitude and dismissal of anything other than gstreamer
> > is just totally intolerable. How else is the "competition" supposed to
> > output audio correctly if only gstreamer gets proper support?
> 
> That's shocking, but given the above, I guess that the conclusion is
> that "competition" is not supposed to be at all!

When I met him in Amsterdam in 2009, he did tell me "Yeah, I should check what 
the other players do... but then again... I don't care about anything but 
gstreamer." or something very much along those lines.

So I wouldn't take it quite as far as "not supposed to [exist]". Still we (and 
Xine, MPlayer, etc) are supposed to not matter such that it is OK if we are 
buggy, I guess.

> > In my experience, developers of other OSS system bricks are not so
> > partial, say ALSA, D-Bus, XCB, etc. "We have support from most Linux
> > distributions" is so irrelevant.
> 
> What is this supposed to be, a gstreamer-PulseAudio trust? Oh we're like
> the only platform out there, let's just laugh at and dismiss the few
> nerds who use something else, it would just be simpler if everybody used
> the real thing. Well then guess what, we have support from most users,
> who use Windows and will be all the happier if we ditch PulseAudio
> support to focus on fixing Windows bugs. And there are more Windows user
> than Linux distributions.

Yeah. If PulseAudio refuses to support us, then it should/might loose what 
might be the most popular OSS media player across desktops. I don't think it 
would affect the PulseAudio project much though.

This would suck for users who get broken audio on VLC et al. And it would suck 
for distributions who loose users (back) to Windows. The distributions are 
stuck for lack of an alternative to PulseAudio, so I don't see them dropping 
it for the time being. Neither JACK nor ALSA can fully replace it. And OSSv4 
is unlikely to come back to the Linux kernel ever.

> > Mind you, just like Lennart, I don't like to be blamed for other
> > people's issues. So if this stuff is not resolved by VLC 1.2.0
> > release, I will:
> > 1/ disable the VLC PulseAudio plugin that never worked correctly,
> 
> Is it necessary to disable it? It could still be useful for users who
> have only PulseAudio available. Although quite frankly, I'm not sure
> that a project that is trying to drive off other players deserves our
> good will.

In VLC 1.1, the PulseAudio output is known under not completely clear 
circumstances, to make VLC leak infinitely until it or the whole system 
crashes. Not too good...

I hope it is fixed by my rewrite, but I couldn't confirm that this far.

> > 2/ take any measure to ensure VLC can access ALSA or OSS without
> > interference (this probably means killing session PulseAudio if
> > present),
> 
> How and why would it interfere exactly? Well, besides agenda.

It reserves the ALSA devices for itself.

> > 3/ when all else fails, tell the user how we feel about this and whom
> > I think to blame.
> 
> Sure. It wouldn't be the first time.

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