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

[Pierre Ynard]

> To make matters worse, it is needlessly complicated. Even Lennart
> admits it, claiming backward compatibility as an excuse.

Do you mean that we should favor frameworks that have a less burdening
legacy, like, ALSA?

> I could not figure any official *and* stable way to either:
>  - find the play time (or delay till play time) of the buffer write
>    offset,
> or
>  - tell PulseAudio that I want a buffer played at a certain time.
> 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, and
it's not among its design goals to provide synchronized multimedia
playback. 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.

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

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

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

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

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

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

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."