[vlc-devel] [PACKAGERS] [RFCv2] PulseAudio removal
remi at remlab.net
Sat Apr 2 23:31:30 CEST 2011
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?
> 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.
More information about the vlc-devel