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

Tue Apr 5 12:13:52 CEST 2011

Hello Pierre,

'Twas brillig, and Pierre Ynard at 02/04/11 21:53 did gyre and gimble:
>> 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?

ALSA has a much more burdening legacy. Not at the kernel side but very
much so at the user-space side. Rémi alluded to such in his previous
email, but decided not to correct you in his reply for some reason.

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

No this is completely untrue.

PA specifically goes out of it's way to provide both accurate (with a
penalty for retrieval) and very well interpolated timing information
specifically for the needs of applications that need to synchronise
sound with other things, such as video. This is one of the specific uses
of this information.

PA is also specifically designed to use lower power in mobile
environments - e.g. tablets, phones, laptops etc. by encouraging the use
of large buffers and disabling interrupts. We specifically do things in
a way that is friendly for the environment in which it's used. This
includes power consumption and timing information.

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

I'm sorry but this is complete bullshit. I don't blame you for assuming
this from Rémi's initial email, but I have to correct it.

The documentation is very clear.
http://0pointer.de/lennart/projects/pulseaudio/doxygen/structpa__buffer__attr.html
http://0pointer.de/lennart/projects/pulseaudio/doxygen/structpa__timing__info.html

If this is a deliberate attempt to obfuscate then it's a pretty damn
poor attempt!

Please do not make such statements flippantly without researching them a
little first. It's a common courtesy to the people putting in the effort
on such projects.

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

Again, this is Rémi's own stance but one which I firmly refute.

As an upstream developer, it's impractical to be involved in every
downstream project. It's like Rémi actually being responsible for
maintaining VLC packages in Gentoo, RedHat, Mandriva, Mageia, Debian,
Ubuntu, Arch, Suse etc. etc. It's totally impractical.

Lennart focuses on GST because that's the framework most closely aligned
to his daily usage. He is perfectly within his rights to do so and I
would go as far as to say that's a sensible approach for an upstream
developer.

The GST code is fully open and viewable for reference. It's not like
it's hidden away. While Lennart may have helped out a bit with the GST
implementation, the vast majority of it was written by third parties,
just like in VLC's pulse support.

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

Again, you're taking Rémi's viewpoint here without any evidence. Please
point out where we are "driv[ing] off other players"? I have continually
pushed PulseAudio support in various corners of FOSS development.

Every single major Linux distribution uses PulseAudio by default. Do you
think they have done that because it's what the cool kids are doing or
do you think they've evaluated the whole audio stack and believe that
PulseAudio is a best approach and does things sensibly? Trust me, when I
say it's the latter.

I have written extensively about PulseAudio over the years, both as a
separate entity and with regards to using it under KDE.

In the beginning KDE people seemed to think they were being ignored too,
but it's simply that no-one stepped up to the plate to do the
integration work. It doesn't happen magically by itself, it needs people
to do the work. I really cannot understand peoples attitudes (and this
goes for some KDE people too) who just expect things to magically
happen. You have to engage with the community and you have to embrace
things if you want them to be supported. It's really not that complex.

Here are some articles you are welcome to read:
http://colin.guthr.ie/2009/08/sound-on-linux-anti-fud-calm-certainty-and-confidence/
http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/
 plus anything else on there with a pulseaudio tag...

Rémi's bubble of intolerance is not the only way. Make up your own mind.

All the best

Col

-- 

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

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]