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

[Colin Guthrie]

Hiya,

I've taken my time to reply to this. As you can imagine I'm very
disappointed by the tone and attitude in this message and I'll explain
why below.

I deliberately didn't reply immediate just in case I vented and was less
constructive than I usually am (or at least try to be).

'Twas brillig, and Rémi Denis-Courmont at 02/04/11 19:43 did gyre and
gimble:
> 	Hello,
> 
> So I spent much of the last 2 days trying to fix the PulseAudio output in VLC. 
> I have to say I am really fed up. PulseAudio simply does not work correctly, 
> and in any case, much worse than direct ALSA.

It's good that you are trying to take a look tho'. I've dropped several
hints to people over the last few months trying to push people into
looking at it, but no one has stepped up to the plate yet.

> While the libpulse documentation is much better than the bad joke that the 
> ALSA documentation is, it is still rather terse in many ways, so you have to 
> assume how things just work and that they won't change mysteriously at the 
> next release.

Can you please give some examples of where things have mysteriously
changed in a subsequent release? The only things I can think of are the
buffer metrics where initialising all values to -1 was added as a "try
to do things with the best power consumption in mind" indicator. This is
one of the things Lennart mentions as being a little complicated[1] but
in order to specifically NOT "change things mysteriously at the next
release"

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

OK, so on the one hand you complain about things "changing mysteriously
at the next release" and now you complain about the goal of maintaining
backwards compatibility... this has to be a new record for self
contradiction... it was only separated by one sentence!!

> What prevents adding nicer functions around the overly intricate ones? 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,

I would have thought that the Latency section of the documentation was
quite useful:

"Since updating the timing info structure usually requires a full
network round trip and some applications monitor the timing very often
PulseAudio offers a timing interpolation system. If
PA_STREAM_INTERPOLATE_TIMING is passed when connecting the stream,
pa_stream_get_time() and pa_stream_get_latency() will try to interpolate
the current playback time/latency by estimating the number of samples
that have been played back by the hardware since the last regular timing
update. It is especially useful to combine this option with
PA_STREAM_AUTO_TIMING_UPDATE, which will enable you to monitor the
current playback time/latency very precisely and very frequently without
requiring a network round trip every time."

If that is not sufficient for your needs, then the pa_timing_info struct
should provide all the info you need.

>  - tell PulseAudio that I want a buffer played at a certain time.

PulseAudio allows you to write data at any time using pa_stream_write.
You can use the seek offset and the seek flag to play data at any point
you like. Just use your sample spec and pa_usec_to_bytes() to work out
the byte offset and and then write your data.

If you want to go back and rewrite data (e.g. the user has triggered a
rewind/fastforward, track skip etc.) then you can throw away the data
you've already written and rewrite it. For low power situations (e.g. on
tablets, laptops etc.) using large buffers is a good thing (it saves
power) and thus the "uncommon" action of seeking/skipping can be dealt
with this way.

That said, I wasn't aware from the API, that VLC allows

> With neither of those, how the bloody heck am I supposed to synchronize audio 
> and video?! 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.

So why not ask for advice? Why not submit documentation patches after
getting advice?

And your comment about "subject to change" is misleading and FUDy. The
docs clearly state: "Please note that this structure can be *extended*
as part of evolutionary API updates at any time in any new release."

This does not mean it will be changed and break your code, it just means
that it might be *extended* to add even more information in there.

> 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? In my experience, developers of other 
> OSS system bricks are not so partial, say ALSA, D-Bus, XCB, etc developers are 
> so partial. "We have support from most Linux distributions" is so irrelevant.

Well asking is a good start. I'm very surprised that you, whom I have
respected as a major player and contributor in the FOSS movement, can be
so ignorant and deliberately obtuse in dealing with this issue.

Is the PA documentation perfect? No. Could it be improved? Sure. This is
the case with every open source project I know off. I doubt any project
will ever be considered "done" in that sense. Everything is about
evolution and, you more than anyone should appreciate that this process
of evolution requires engagement and collaboration.

You have deliberately tried to sit in a darkened corner, and work on
your own to solve a problem and failed. I don't know why you sat in
isolation like that. I have seen no posts to the PA mailing list asking
for advice, I have seen no comments on our IRC channel. It's almost like
you specifically *want* to fail just so you can badmouth PA and Lennart
some more.


> 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,
> 2/ take any measure to ensure VLC can access ALSA or OSS without interference 
> (this probably means killing session PulseAudio if present),
> 3/ when all else fails, tell the user how we feel about this and whom I think 
> to blame.

OK, so you basically saying you will cripple the user's system? You
specifically want to make VLC work separately from the audio device
preferences that the user has picked in their desktop environment's
sound preferences GUI. You specifically want to break the integrated
volume controls both with multimedia keys on laptops/keyboards and with
panel applets. You specifically want to make it nigh on impossible for
people to use Bluetooth headphones. You want to break the ability to
receive a VoIP call - did I mention that PA will automatically mute (or
if fully supported, actually pause) a properly tagged Music or Video
audio stream when a Skype call comes in? Neat huh... oh no, actually you
simply won't be able to receive any VoIP calls now if you implement your
change.

Yay for progress!

If you seriously go through with this action, you will create a much
larger problem for yourself than the one that is there currently with a
lacking implementation of the audio plugin. Just as with the actual
community engagement part of open source projects, applications have to
play nice with the environment they are in. If an app basically breaks
everything on a users setup, they will be seen as the cause of the
problem. This is especially so considering that a myriad of other media
players have no problem with PA output and indeed embrace it gladly. If
you can't see that then I seriously suspect you have a personal agenda
that is different from the one publicly presented.

> I am really sad that we had to come to threats and ultimatum. But what the 
> heck, this troll has been going on for 3 years in VLC. Enough is enough.

I can honestly say that I have lost a massive amount of respect for you
due to the attitude portrayed in this message. I thought you took a very
principled stand with regards to the GPL and VLC in the AppStore stuff.
I defended your actions via blog comments because I thought that you
were standing up for the copyleft principles behind the GPL.

Here I see that you really don't care about contributing back to other
projects or helping things evolve for the greater good, and that is a
real shame.

You complained about lacking documentation yet made zero effort to
engage with us upstream and try and provide some input into making the
documentation better. No emails to our list, no questions on our IRC
channel, and obviously no patches to update our documentation.

With regards to how this whole email was sent, you admit you resorted to
"threats and ultimatum" (ultimati?) This was your first port of call?
Seriously? OK, you had a previous flamebait email too in much the same
vein, but seriously? No call for support? Did you post on the VLC
mailing list saying "Please Help: Who is willing to rewrite the PA
support?" Did you put that out via your website or Facebook or to the
KDE community who is now using VLC via Phonon more and more? Put up GSoC
projects? No. Did you mail me and ask me if I was planning on getting
round to rewriting the pulse output code any time soon? No, you
deliberately antagonised the one person who has continually offered
help. Well done. There seems to be a serious misunderstanding of how to
leverage support in and engage with a community. I hope it's only on
this topic and not more generally.

I do this stuff as a hobby, it's not my day job and I'm not paid. I like
working in the FOSS movement because there is a great community spirit.
I like working with GNOME and KDE communities (while there are often
jibes and pokes between the communities I find the majority of people
get on rather well, with the jibes being much the same as the ones you
have between friends - I don't take things too seriously most of the
time!). But I get really pissed off when people have such backwards
attitudes to dealing with problems. You should be engaging people, not
pushing them away.

I was fully intending on looking into VLC pulse as part of the KDE Randa
sprint in June specifically because people are using VLC more and more
in KDE. I put that as one of my goals but I am seriously reconsidering
this now. I am not a petty man, so I suspect I will continue and take a
look at it, but I don't want to give any credence to the fact that it's
"threats and ultimatum" that is triggering this, hence why I have been
so clear and open above to explain all the things I think are wrong with
this approach.

I hope that Pierre who was so taken in by your previous FUD will
appreciate the situation in a better light now and make up his own mind.


Here's hoping to a more positive attitude going forward.

Col

1. http://pulseaudio.org/wiki/LatencyControl
-- 

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/]