Discussion:
Flamebait: PulseAudio removal
(too old to reply)
Rémi Denis-Courmont
2010-11-27 18:24:48 UTC
Permalink
Hello,

The VLC PulseAudio output is known to cause huge memory leaks in some
circumstances, that have appaled a number of Linux VLC users. I don't know if
it is a VLC, a PulseAudio, or more likely a plugin bug.

But this may be a moot issue because:

* The VLC PulseAudio plugin seems(?) unmaintained.

* PulseAudio itself is largelly unmaintained. Lennart Poettering decided to
reinvent a more interesting wheel, in the form of systemd. And instead of
naming a co-release manager for PulseAudio, he let the thing bit rot. I have
to guess that RedHat does not really care about PulseAudio, or how could they
let such a "critical" piece of Linux so poorly maintained.

* Lennart pretends that the future of audio on open-source is gstreamer in
front of PulseAudio. By enabling PulseAudio, we give him more credits than he
deserves.

* Much of what PulseAudio does, VLC and/or alsa-lib can do, notably
resampling, sample format conversion and software mixing. I am yet to find any
practical justification for PulseAudio.

* alsa-lib is horrible, but so is libpulse.

* Lennart literally said to me (IRL) that he should fix the other (i.e. than
gstreamer) media framework, but then again he couldn't care less. Colin
Guthrie has tried to apologize but clearly failed to convince Lennart. In any
case, none of the PulseAudio guys tried to fix the VLC PulseAudio output.

Of course, if we remove PulseAudio, we have to make sure we don't end up using
it through OSS or ALSA, as the PulseAudio emulation of those is complete crap
and not going to be fixed. Not to worry, this is pretty trivial as long as
PulseAudio is run by the user session:

/* PulseAudio hijacks ALSA and OSS defaults. Kill it. */
system("killall pulseaudio");
--
R?mi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
Rémi Denis-Courmont
2010-11-27 18:34:19 UTC
Permalink
Post by Rémi Denis-Courmont
* Lennart literally said to me (IRL) that he should fix the other (i.e.
than gstreamer) media framework
...integration with libpulse, that is to say.
--
R?mi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
Mathieu SCHROETER
2010-11-28 12:02:39 UTC
Permalink
Post by Rémi Denis-Courmont
Of course, if we remove PulseAudio, we have to make sure we don't end up using
it through OSS or ALSA, as the PulseAudio emulation of those is complete crap
and not going to be fixed. Not to worry, this is pretty trivial as long as
/* PulseAudio hijacks ALSA and OSS defaults. Kill it. */
system("killall pulseaudio");
and...

$ echo "autospawn = no" >> ~/.pulse/client.conf
--
Mathieu SCHROETER
ogg.k.ogg.k
2010-11-28 12:34:40 UTC
Permalink
Post by Mathieu SCHROETER
$ echo "autospawn = no" >> ~/.pulse/client.conf
I'd much rather something that checks if pulseaudio is running, and
moans at the user. Modifying user configuration files that are not
yours is just wrong.
Rémi Denis-Courmont
2010-11-28 13:01:06 UTC
Permalink
Le dimanche 28 novembre 2010 14:34:40 ogg.k.ogg.k at googlemail.com, vous avez
Post by ogg.k.ogg.k
Post by Mathieu SCHROETER
$ echo "autospawn = no" >> ~/.pulse/client.conf
I'd much rather something that checks if pulseaudio is running, and
moans at the user. Modifying user configuration files that are not
yours is just wrong.
Then again, tell the PulseAudio guys to stop modifying the ALSA configuration
files that aren't theirs...
--
R?mi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
Colin Guthrie
2010-11-29 15:51:26 UTC
Permalink
'Twas brillig, and R?mi Denis-Courmont at 28/11/10 13:01 did gyre and
Post by Rémi Denis-Courmont
Le dimanche 28 novembre 2010 14:34:40 ogg.k.ogg.k at googlemail.com, vous avez
Post by ogg.k.ogg.k
Post by Mathieu SCHROETER
$ echo "autospawn = no" >> ~/.pulse/client.conf
I'd much rather something that checks if pulseaudio is running, and
moans at the user. Modifying user configuration files that are not
yours is just wrong.
Then again, tell the PulseAudio guys to stop modifying the ALSA configuration
files that aren't theirs...
Please point out the lines in PA code that do this and I'll remove them.

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/]
Rafaël Carré
2010-11-28 20:21:58 UTC
Permalink
On Sat, 27 Nov 2010 20:24:48 +0200
Post by Rémi Denis-Courmont
Hello,
The VLC PulseAudio output is known to cause huge memory leaks in some
circumstances, that have appaled a number of Linux VLC users. I don't
https://bugs.launchpad.net/ubuntu/karmic/+source/pulseaudio/+bug/424655 ?
Post by Rémi Denis-Courmont
* The VLC PulseAudio plugin seems(?) unmaintained.
That's my impression too
Post by Rémi Denis-Courmont
* PulseAudio itself is largelly unmaintained. Lennart Poettering
decided to reinvent a more interesting wheel, in the form of systemd.
in
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-November/008286.html
which marks the 0.9.22 release he "hope[s] to do more PA work again" so
we could wait a bit and see how it goes
Post by Rémi Denis-Courmont
Of course, if we remove PulseAudio, we have to make sure we don't end
up using it through OSS or ALSA, as the PulseAudio emulation of those
is complete crap and not going to be fixed. Not to worry, this is
/* PulseAudio hijacks ALSA and OSS defaults. Kill it. */
system("killall pulseaudio");
I think it's quite evil but OTOH i don't know how else to bypass PA
emulation
--
Rafa?l Carr?
Colin Guthrie
2010-11-29 15:51:20 UTC
Permalink
'Twas brillig, and R?mi Denis-Courmont at 27/11/10 18:24 did gyre and
Post by Rémi Denis-Courmont
Hello,
The VLC PulseAudio output is known to cause huge memory leaks in some
circumstances, that have appaled a number of Linux VLC users. I don't know if
it is a VLC, a PulseAudio, or more likely a plugin bug.
The only memory leak that I've come across is when using PA on top of
Jack with module-jack-sink (a fairly uncommon setup). This tends to leak
SHM segments. I doubt that's the problem here (if people are clever
enough to setup Jack, they'll probably point VLC directly at jack in
some capacity). Have you got a specific reference to this problem (bug
report etc.) so that I can take a look.
Post by Rémi Denis-Courmont
* The VLC PulseAudio plugin seems(?) unmaintained.
I've not been following it but I'll try and set some time aside to
rewrite it. I'm very busy at work just now but as the nights daw in,
perhaps I will fine more time. Who knows.

I do know that any rewrite will require changes to how the VLC volume
code works to properly integrate the volume logic (currently when used
with Phonon, the volume control logic will totally bypass libvlc anyway
and control the volumes directly in PA, so it's not an issue there, just
for all other VLC clients).
Post by Rémi Denis-Courmont
* PulseAudio itself is largelly unmaintained. Lennart Poettering decided to
reinvent a more interesting wheel, in the form of systemd. And instead of
naming a co-release manager for PulseAudio, he let the thing bit rot. I have
to guess that RedHat does not really care about PulseAudio, or how could they
let such a "critical" piece of Linux so poorly maintained.
I disagree overall. Lennart has been focusing on systemd and I will
agree that that has been a bit of a pain at times, but it doesn't mean
that PA itself has been abandoned, nor that interest from various
parties is not providing plenty interesting commits being merged.

Look at the git tree on both master and stable-queue branches to see
that activity has continued quite happily when Lennart has been away.
I've been shepherding various commits by both Intel and Nokia employees,
as well as people adding specific h/w quirks from Canonical (with access
to more audio hardware) and other contributors (such as Collabora).

While there are various new things we want to add to PA, the core
functionality has stabilised for the time being. The numerous changes in
alsa-drivers and alsa-lib needed to allow PA to work with the latest
features has mostly stabilised now and with each alsa release,
integration with PA becomes smoother. People very rarely appreciate
where bugs really lie. While PA has had numerous bugs (as with any
software), many of the actual problems were simply those it exposed due
to utilising parts of alsa that no other alsa client (including VLC)
made use of. These were not PA bugs, but alsa bugs even if the
"solution" chosen by the ignorant was to "disable PA" rather than
addressing the real cause and reporting bugs. This does not help the
free software ecosystem nor audio on linux one jot.


It has long been stated, and all distribution maintainers know, that
anything that goes into the stable-queue branch in git are patches that
we'd generally recommend for anyone using PA. I regularly push these
changes as packages to stable distros and the development distro alike.
Many distributions have a policy of not backporting new version and by
using a recommended patch list, this was a convenient way to ensure
distro maintainers were able to push the latest fixes to older distros.

That said, I do feel it would have been more useful to do more bugfix
releases and let the distro guys just pull the patches if that's
ultimately what helps (and they can just skip the version and .so bump
commits). I will try to push this policy going forward, to have at least
one release every six months to vaguely fit in with most distro release
cycles (although this policy would have only resulted in one extra PA
release about 6 months ago had it been in place earlier).
Post by Rémi Denis-Courmont
* Lennart pretends that the future of audio on open-source is gstreamer in
front of PulseAudio. By enabling PulseAudio, we give him more credits than he
deserves.
Lennart has his own priorities here, but he fully accepts that gst is
not appropriate for several use cases (e.g. voip). But that said, are
you saying that any software developer must be
all-other-project-agnostic? That's like saying that any government civil
servant is not allowed to vote or hold a political opinion. There is
absolutely nothing in PA that ties it in any way to GST. Do you expect
the XCB people to write all your XCB Support, do you expect the Qt
people to write your Qt frontend, do you expect the ALSA people to write
your ALSA output?
Post by Rémi Denis-Courmont
* Much of what PulseAudio does, VLC and/or alsa-lib can do, notably
resampling, sample format conversion and software mixing. I am yet to find any
practical justification for PulseAudio.
This is a tiny part of what PA does. Support for network transparency
(e.g. thin clients or simply SSH'ing to another machine), support for
timer-based scheduling for use in low-power environments (e.g. mobile
phones, tablets etc. - why do you think Nokia and Intel are so
involved?), (proper) support for bluetooth devices, support for network
devices such as UPnP and Apple Airtunes etc. etc. While some of these
can be done outwith PA, they are generally not properly integrated and
require manual configuration and don't deal properly with hotswapping etc.

With each application and framework doing their own thing, they each
individually have to provide audio configuration GUIs leading to poorly
integrated HCI rules and novice users really not having the first clue
what to do with their audio when using $APPLICATION. By providing a
central GUI in the desktop environment for controlling audio devices,
users can have a clearly defined method of making adjustments, which is
much better overall for Linux adoption by the non-l337.


Really, the software mixing and resampling isn't the primary reason to
use PA and if you think that's all it is, I'm not surprised you doubt
it. But to make such bold statements while clearly lacking (or
withholding) knowledge on a given topic does not seem fair.
Post by Rémi Denis-Courmont
* alsa-lib is horrible, but so is libpulse.
I don't disagree, but by the same token libpulse really does make people
think about the realtime nature of audio programming. To try and avoid
such issues will ultimately lead to failure.

But the API is certainly not perfect, the way the buffer metrics are
populates is a primary example of where it sucks. The justification
there is to maintain backwards compatibility which I think is a
reasonable excuse in that case.
Post by Rémi Denis-Courmont
In any case, none of the PulseAudio guys tried to fix the VLC PulseAudio output.
Sorry, but real life gets in the way sometimes. I'm trying my best to
fit in all the things I want to do, but my time is finite. Seeing as
it's obviously a sticking point for you, I'll try and dedicate some time
to this task in particular sometime soon.
Post by Rémi Denis-Courmont
Of course, if we remove PulseAudio, we have to make sure we don't end up using
it through OSS or ALSA, as the PulseAudio emulation of those is complete crap
and not going to be fixed. Not to worry, this is pretty trivial as long as
/* PulseAudio hijacks ALSA and OSS defaults. Kill it. */
system("killall pulseaudio");
That wont work and it will be incredibly arrogant (in terms of the
*application* that does this would be considered an "arrogant
application") as to assume that's what the user wants.

I think many PA haters these days are still stuck in their bubble of
hatred. All the major distros ship PA by default and the vast majority
of users are all blissfully ignorant to the fact PA even exists. Only
those in the minority who have a problem or a grudge even really care
about such topics these days.


That said, I do see the need to get more people working on your PA
support. I'll try and help but really you should have just asked for
more help with the PA plugin in vlc rather than make such a post. It
would have been far more productive and positive rather than the
negative light it has currently painted.


Col.


PS FWIW, I will submit a patch to disable, at runtime, the calls to the
xlib stuff in the VLC plugin in the next couple days. I don't remember
getting a reply about how the blacklist stuff you were going to write
would work but hopefully each module will blacklist itself indirectly
when running the vlc_xlib_init() function in which case the patch will
work fine... if the blacklist is higher level (e.g. a static list of
evil modules), please let me know.
--
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/]
Rémi Denis-Courmont
2010-11-29 16:25:17 UTC
Permalink
Hello,
Post by Colin Guthrie
Post by Rémi Denis-Courmont
* Lennart pretends that the future of audio on open-source is gstreamer
in front of PulseAudio. By enabling PulseAudio, we give him more credits
than he deserves.
Lennart has his own priorities here, but he fully accepts that gst is
not appropriate for several use cases (e.g. voip).
I am afraid you couldn't have put it worse. I consider VoIP features (low-
latency, symmetric RTP...) to be one of gstreamer largest if not the largest
purely technical advantages over LibVLC.
Post by Colin Guthrie
But that said, are you saying that any software developer must be
all-other-project-agnostic?
Oh no. Lennart has freedom of opinion. I'm just saying that if he intends to
make gstreamer/PulseAudio the only 'one' multimedia back-end for Linux/OSS,
then the VideoLAN project should exert its freedom to avoid PulseAudio.

To put it another way, I am saying that people who pretend to provide system
features should externally be more agnostic. I doubt D-Bus or upstart would
have enjoyed the support they now have if they had been, say GNOME/GTK/glib-
specific.

I did consider (re)writing the PA output and adding the input. But I got so
annoyed with his attitude over time.
Post by Colin Guthrie
Post by Rémi Denis-Courmont
* Much of what PulseAudio does, VLC and/or alsa-lib can do, notably
resampling, sample format conversion and software mixing. I am yet to
find any practical justification for PulseAudio.
This is a tiny part of what PA does. Support for network transparency
(e.g. thin clients or simply SSH'ing to another machine),
VLC couldn't care less. It cannot do network transparency due to video.
Post by Colin Guthrie
support for timer-based scheduling for use in low-power environments
(e.g. mobile phones, tablets etc. - why do you think Nokia and Intel are so
involved?), (proper) support for bluetooth devices,
support for network devices such as UPnP and Apple Airtunes
VLC has to support ROAP natively because PulseAudio is not running on most
systems that VLC runs on. But you probably know that since both PA and VLC
reverse-engineered and implemented it at the same time.

As a Linux user, I would be totally fine ditching the VLC implementation. But
guess what happens then?
Post by Colin Guthrie
etc. etc. While some of these
can be done outwith PA, they are generally not properly integrated and
require manual configuration and don't deal properly with hotswapping etc.
With each application and framework doing their own thing, they each
individually have to provide audio configuration GUIs leading to poorly
integrated HCI rules and novice users really not having the first clue
what to do with their audio when using $APPLICATION. By providing a
central GUI in the desktop environment for controlling audio devices,
users can have a clearly defined method of making adjustments, which is
much better overall for Linux adoption by the non-l337.
And the end result is that VLC gets complaints about having its own things,
never mind that it has to. That's not really an improvement from my VLC
developer's perspective. Not to mention that many even Linux+PulseAudio users
would be quite pissed off if VLC stopped providing its own UI controls for
itself. I mean, I doubt users would be very happy if the VLC user interface
would reconfigure the whole system through PulseAudio, instead of just the VLC
instance media.

In all due fairness, the fact that ALSA, Windows and MacOS are more limited is
not at all PulseAudio's fault, and most of PulseAudio's goals are technically
good. But unfortunately, this has brought more problems than solutions to us.
Post by Colin Guthrie
Really, the software mixing and resampling isn't the primary reason to
use PA and if you think that's all it is, I'm not surprised you doubt
it. But to make such bold statements while clearly lacking (or
withholding) knowledge on a given topic does not seem fair.
PS FWIW, I will submit a patch to disable, at runtime, the calls to the
xlib stuff in the VLC plugin in the next couple days.
I think this is already done in 1.2.0-git, but it is static. In other words,
VLC 1.2.0 requires libpulse 0.9.22 or later. I am not very keen on backporting
this as we will get a flood of "you suckers, VLC 1.1.6 bugfix releases
requires a new version of PulseAudio that my distro does not have" messages.
Post by Colin Guthrie
I don't remember
getting a reply about how the blacklist stuff you were going to write
would work but hopefully each module will blacklist itself indirectly
when running the vlc_xlib_init() function in which case the patch will
work fine... if the blacklist is higher level (e.g. a static list of
evil modules), please let me know.
This is a run-time check. The plugin probe function is still called, and
expected to fail before it calls XOpenDisplay().
--
R?mi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
Colin Guthrie
2010-11-30 15:12:10 UTC
Permalink
Hi,

'Twas brillig, and R?mi Denis-Courmont at 29/11/10 16:25 did gyre and
Post by Rémi Denis-Courmont
Post by Colin Guthrie
Post by Rémi Denis-Courmont
* Lennart pretends that the future of audio on open-source is gstreamer
in front of PulseAudio. By enabling PulseAudio, we give him more credits
than he deserves.
Lennart has his own priorities here, but he fully accepts that gst is
not appropriate for several use cases (e.g. voip).
I am afraid you couldn't have put it worse. I consider VoIP features (low-
latency, symmetric RTP...) to be one of gstreamer largest if not the largest
purely technical advantages over LibVLC.
Perhaps. I'm going on comments from some time ago now. Perhaps things
have changed or perhaps I just misunderstood. Who knows.
Post by Rémi Denis-Courmont
Post by Colin Guthrie
But that said, are you saying that any software developer must be
all-other-project-agnostic?
Oh no. Lennart has freedom of opinion. I'm just saying that if he intends to
make gstreamer/PulseAudio the only 'one' multimedia back-end for Linux/OSS,
then the VideoLAN project should exert its freedom to avoid PulseAudio.
I guess you could look at it that way, but I would have thought it made
sense for a developer to pick one stack and stick with it and try to
make it the best possible stack. That doesn't preclude anyone with a
competing solution trying to better that stack or a part of that stack.
Post by Rémi Denis-Courmont
To put it another way, I am saying that people who pretend to provide system
features should externally be more agnostic. I doubt D-Bus or upstart would
have enjoyed the support they now have if they had been, say GNOME/GTK/glib-
specific.
Perhaps, but this whole argument that PA is in any way "gnome specific"
is just bullshit (not saying that's what you said, it's just a general
statement). It specifically doesn't use glib in it's core, although does
integrate nicely with glib loop based apps and has a convenience gconf
module (although that is just a glorified module loader/config system,
so hardly of any importance in the overall scheme of things and
something I do intend to factor out at any rate).

I've developed for KDE for a while (not massively, just poking in here
and there as time permits) and the biggest thing that pisses me of
generally about KDE is the cry of "why were we not consulted on $X", and
"we were not involved in $Y". This is complete mince. If people want to
be involved in a project they have to *want* to be involved, they have
to see something and decide, "right, I'm going to research and get
involved in $X and then work out the best way to integrate that to KDE".
That's what I did with the PA support in KDE (a large part because I was
getting highly pissed off at people with that kind of attitude). The few
times Lennart has tried to post to KDE lists to make them aware of
something, it just gets thrown in his face - sure he likes to be
antagonistic at times, but that's just his personality - I don't agree
with all the things he says either, but I can separate these things
pragmatically (and take a light hearted view of it too).

And don't think for a second there is any particular anti-VLC slant here
that warrants some kind of retaliation by avoiding PA. He has this
opinion of just about everything that isn't his install on his systems.
If you use Gentoo you're smoking crack, if you don't use rpm you're
insane, if you try to do your own media decoding then you should be
wearing a jacket that buckles at the back etc. etc. (I've made them all
up, but I'm sure they could be attributed to him!). This is just his way
and how he focuses on the jobs important to him. It's not personal and
it shouldn't be taken that way. I certainly don't when he's critical of
things I've done or said.
Post by Rémi Denis-Courmont
I did consider (re)writing the PA output and adding the input. But I got so
annoyed with his attitude over time.
To avoid something because of personality issues is a real shame. In a
corporate environment people have to do work for people higher up the
chain of command that they can't stand. They do it ultimately because
they are paid and perhaps want to further their career, but ultimately
the overall strategy of doing a body of work is determined because it's
the best route forward, and pretty much factors out micro-management
personalities.

Is the entire open source community one big happy family? No. Are there
political arguments about trivial things all the time? Yes. Are
technical decisions based on personalities? Sadly, it seems so. I'd have
hoped people were more interested in the FOSS part rather than
individual personalities but I guess everyone has their own reasons for
contributing to the FOSS movement and not everyone is able to be quite
as pragmatic about these things.
Post by Rémi Denis-Courmont
Post by Colin Guthrie
Post by Rémi Denis-Courmont
* Much of what PulseAudio does, VLC and/or alsa-lib can do, notably
resampling, sample format conversion and software mixing. I am yet to
find any practical justification for PulseAudio.
This is a tiny part of what PA does. Support for network transparency
(e.g. thin clients or simply SSH'ing to another machine),
VLC couldn't care less. It cannot do network transparency due to video.
Oh, I thought VLC could play audio too. I've certainly run e.g. Amarok
or Rhythmbox etc. via X11 protocol on several occasions. I regularly run
VirtualBox on a bigger iron machine than I run for testing purposes.
Having sound is often essential in those circumstances.

And whether something is important to VLC or not is not the only thing
to consider. If the *system* that VLC runs on has a need for these
things, then VLC has to fit in with that and be respectful of the stack
rather than unilaterally imposing policy.
Post by Rémi Denis-Courmont
Post by Colin Guthrie
support for timer-based scheduling for use in low-power environments
(e.g. mobile phones, tablets etc. - why do you think Nokia and Intel are so
involved?), (proper) support for bluetooth devices,
support for network devices such as UPnP and Apple Airtunes
VLC has to support ROAP natively because PulseAudio is not running on most
systems that VLC runs on. But you probably know that since both PA and VLC
reverse-engineered and implemented it at the same time.
As a Linux user, I would be totally fine ditching the VLC implementation. But
guess what happens then?
Yeah I fully appreciate the need for this just now due to the way things
work. I'd far rather see Linux+PA+raop, OSX+airofoil/general RA stuff
and Windows+$RAOPSYSTEM work such that the stack itself supports these
things rather than having to reinvent the wheel in $APP. It makes much
more logical sense, but I appreciate why this isn't quite there yet on
all platforms.


The power point still stands too. If you want to use VLC on tablets and
and mobile environments for playing audio, then this is something to
really look into. You want to push 2s+ of audio decode into PA and then
just sleep for 2s if at all possible.
Post by Rémi Denis-Courmont
Post by Colin Guthrie
etc. etc. While some of these
can be done outwith PA, they are generally not properly integrated and
require manual configuration and don't deal properly with hotswapping etc.
With each application and framework doing their own thing, they each
individually have to provide audio configuration GUIs leading to poorly
integrated HCI rules and novice users really not having the first clue
what to do with their audio when using $APPLICATION. By providing a
central GUI in the desktop environment for controlling audio devices,
users can have a clearly defined method of making adjustments, which is
much better overall for Linux adoption by the non-l337.
And the end result is that VLC gets complaints about having its own things,
never mind that it has to. That's not really an improvement from my VLC
developer's perspective. Not to mention that many even Linux+PulseAudio users
would be quite pissed off if VLC stopped providing its own UI controls for
itself. I mean, I doubt users would be very happy if the VLC user interface
would reconfigure the whole system through PulseAudio, instead of just the VLC
instance media.
I'd say there would be less Linux+PA users that would be pissed off than
any other users would be if it were removed. But that's beside the point
really. I think the point still stands that if I pair my bluetooth
headphones with my computer, I want a quick and easy way to direct audio
to them regardless of individual application configuration. Having a
central place of config is still a very desirable goal.
Post by Rémi Denis-Courmont
In all due fairness, the fact that ALSA, Windows and MacOS are more limited is
not at all PulseAudio's fault, and most of PulseAudio's goals are technically
good. But unfortunately, this has brought more problems than solutions to us.
I can appreciate the frustration this causes. I'll try and do my best to
help alleviate these problems. Please feel free to ping me directly with
anything that I could help with as I don't keep up-to-date with these
lists all the time.
Post by Rémi Denis-Courmont
Post by Colin Guthrie
Really, the software mixing and resampling isn't the primary reason to
use PA and if you think that's all it is, I'm not surprised you doubt
it. But to make such bold statements while clearly lacking (or
withholding) knowledge on a given topic does not seem fair.
PS FWIW, I will submit a patch to disable, at runtime, the calls to the
xlib stuff in the VLC plugin in the next couple days.
I think this is already done in 1.2.0-git, but it is static. In other words,
VLC 1.2.0 requires libpulse 0.9.22 or later. I am not very keen on backporting
this as we will get a flood of "you suckers, VLC 1.1.6 bugfix releases
requires a new version of PulseAudio that my distro does not have" messages.
This is a run-time check. The plugin probe function is still called, and
expected to fail before it calls XOpenDisplay().
Ahh cool. I guess the problem remains that VLC could be compiled against
0.9,22 but still run against 0.9.21 which was my main concern with a
compile-time option (there is no libpulse lib-major difference as the
API is the same).

A runtime check should be fairly simple. Do you want me to take a look
still or do you think the current approach will catch enough of the
problem cases (most users should upgrade all their distro packages
together after all and if you self compile it should be caught too).



Take care

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/]
Rémi Denis-Courmont
2010-11-30 17:39:04 UTC
Permalink
Post by Colin Guthrie
Post by Rémi Denis-Courmont
Post by Colin Guthrie
Lennart has his own priorities here, but he fully accepts that gst is
not appropriate for several use cases (e.g. voip).
I am afraid you couldn't have put it worse. I consider VoIP features
(low- latency, symmetric RTP...) to be one of gstreamer largest if not
the largest purely technical advantages over LibVLC.
Perhaps. I'm going on comments from some time ago now. Perhaps things
have changed or perhaps I just misunderstood. Who knows.
I don't know what Lennart thinks. I just know that gstreamer can do VoIP (with
farsight, I guess) and VLC cannot. That being the biggest *technical*
advantage of gstreamer over libvlc.

(...)
Post by Colin Guthrie
Post by Rémi Denis-Courmont
This is a run-time check. The plugin probe function is still called, and
expected to fail before it calls XOpenDisplay().
Ahh cool. I guess the problem remains that VLC could be compiled against
0.9,22 but still run against 0.9.21 which was my main concern with a
compile-time option (there is no libpulse lib-major difference as the
API is the same).
That's would be a packaging bug. vlc-plugin-pulse should require a high enough
version of libpulse. As upstream, we can only try to warn packagers.
Post by Colin Guthrie
A runtime check should be fairly simple. Do you want me to take a look
still or do you think the current approach will catch enough of the
problem cases (most users should upgrade all their distro packages
together after all and if you self compile it should be caught too).
A run-time check will require the PA plugin be linked to libX11, unless you
want to play ugly dlsym() tricks. I would rather avoid that.
--
R?mi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
Colin Guthrie
2010-12-01 10:52:34 UTC
Permalink
'Twas brillig, and R?mi Denis-Courmont at 30/11/10 17:39 did gyre and
Post by Rémi Denis-Courmont
Post by Colin Guthrie
Ahh cool. I guess the problem remains that VLC could be compiled against
0.9,22 but still run against 0.9.21 which was my main concern with a
compile-time option (there is no libpulse lib-major difference as the
API is the same).
That's would be a packaging bug. vlc-plugin-pulse should require a high enough
version of libpulse. As upstream, we can only try to warn packagers.
Yeah, fair enough really. I'm certainly not going to be too worried
about the strange scenario I presented either. It's it a very, very edge
case in the overall scheme of things.
Post by Rémi Denis-Courmont
Post by Colin Guthrie
A runtime check should be fairly simple. Do you want me to take a look
still or do you think the current approach will catch enough of the
problem cases (most users should upgrade all their distro packages
together after all and if you self compile it should be caught too).
A run-time check will require the PA plugin be linked to libX11, unless you
want to play ugly dlsym() tricks. I would rather avoid that.
Hmm, right I see. I thought the problems would only present themselves
when xlib was actually used (which only happens when the PA connection
is established). I guess just pulling in the lib is enough to cause the
problems? If so then I fully agree that dlsym tricks would be not be
worth the effort here.

Cheers


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/]
Rémi Denis-Courmont
2010-12-02 17:48:23 UTC
Permalink
On Wed, 01 Dec 2010 10:52:34 +0000, Colin Guthrie <gmane at colin.guthr.ie>
Post by Colin Guthrie
Hmm, right I see. I thought the problems would only present themselves
when xlib was actually used (which only happens when the PA connection
is established). I guess just pulling in the lib is enough to cause the
problems? If so then I fully agree that dlsym tricks would be not be
worth the effort here.
No. The problem manifests if XInitThreads() is called for the first time
(in the process lifetime) while there is one (or more) active Display
pointers open. But I still would rather not link the VLC PA plugin to
libX11 anymore.

As far as Phonon VLC is concerned, the bug is still present since my fix
was reverted without explanations, and GLX exhibits the exact same problem
has libpulse had.
--
R?mi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis
Colin Guthrie
2010-12-04 17:50:35 UTC
Permalink
'Twas brillig, and R?mi Denis-Courmont at 02/12/10 17:48 did gyre and
Post by Rémi Denis-Courmont
On Wed, 01 Dec 2010 10:52:34 +0000, Colin Guthrie <gmane at colin.guthr.ie>
Post by Colin Guthrie
Hmm, right I see. I thought the problems would only present themselves
when xlib was actually used (which only happens when the PA connection
is established). I guess just pulling in the lib is enough to cause the
problems? If so then I fully agree that dlsym tricks would be not be
worth the effort here.
No. The problem manifests if XInitThreads() is called for the first time
(in the process lifetime) while there is one (or more) active Display
pointers open. But I still would rather not link the VLC PA plugin to
libX11 anymore.
As far as Phonon VLC is concerned, the bug is still present since my fix
was reverted without explanations, and GLX exhibits the exact same problem
has libpulse had.
To be fair there was an explanation in the commit log:

commit fa898f1beef7fae7c58fc1284c50a4cb886ad109
Author: Mark Kretschmann <kretschmann at kde.org>
Date: Fri Nov 12 07:03:46 2010 +0100

Revert "Disable usage of Xlib"

This reverts commit 3b1835d70aa38e4d86bcb9024c365e6b353766e4.

This revert was recommended by j-b, as the commit broke Phonon-VLC
in many cases.
(mine didn't work at all).


Although I will grant you that the explanation lacked a technical detail
that it probably deserved.


I'd be interested in seeing if it can be reinstated sensibly so will try
and take a look.

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/]
Jean-Baptiste Kempf
2010-12-04 18:11:05 UTC
Permalink
Post by Colin Guthrie
This revert was recommended by j-b, as the commit broke Phonon-VLC
in many cases.
Sorry to nitpick, but I didn't recommend the revert, I merely reported
the commit that might have broken it.
--
Jean-Baptiste Kempf
http://www.jbkempf.com/
+33 672 704 734
Colin Guthrie
2010-12-05 17:25:20 UTC
Permalink
'Twas brillig, and Jean-Baptiste Kempf at 04/12/10 18:11 did gyre and
Post by Jean-Baptiste Kempf
Post by Colin Guthrie
This revert was recommended by j-b, as the commit broke Phonon-VLC
in many cases.
Sorry to nitpick, but I didn't recommend the revert, I merely reported
the commit that might have broken it.
Nitpicking is allowed, but I don't really think this is a nitpicking
comment :D

I tried adding it back in and it did pretty much break video for me, but
on the plus side audio worked fine :D

Perhaps I've just not got the right subpackages of libvlc installed for
video output sans xlib, but certainly it's not a simple matter of just
using the --disable-xlib argument.

What video output modules should be used when xlib is disabled?

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/]
Jean-Baptiste Kempf
2010-12-05 18:45:03 UTC
Permalink
Post by Colin Guthrie
What video output modules should be used when xlib is disabled?
xcb ones, of course.

Best Regards,
--
Jean-Baptiste Kempf
http://www.jbkempf.com/
+33 672 704 734
Rémi Denis-Courmont
2010-12-05 23:19:35 UTC
Permalink
Hello,
Post by Colin Guthrie
Perhaps I've just not got the right subpackages of libvlc installed for
video output sans xlib, but certainly it's not a simple matter of just
using the --disable-xlib argument.
Anything except GLX, EGL and SDL.

GLX is fundamentally broken; it was _specified_ to use Xlib.
EGL, as provided by the Mesa project, builds on top of GLX.
SDL uses Xlib instead of XCB.
--
R?mi Denis-Courmont
http://www.remlab.net/
Rémi Denis-Courmont
2010-12-04 18:26:02 UTC
Permalink
Hello,
No, there was not.
Post by Colin Guthrie
commit fa898f1beef7fae7c58fc1284c50a4cb886ad109
Author: Mark Kretschmann <kretschmann at kde.org>
Date: Fri Nov 12 07:03:46 2010 +0100
Revert "Disable usage of Xlib"
This reverts commit 3b1835d70aa38e4d86bcb9024c365e6b353766e4.
This revert was recommended by j-b, as the commit broke Phonon-VLC
in many cases.
(mine didn't work at all).
This does not explain why it would have allegedly "broken" Phonon-VLC. And it
does not explain how it will not reintroduce the problem that the commit did
fix.

Besides, anything that this commit might have "broken" was surely already
broken to begin with.
Post by Colin Guthrie
Although I will grant you that the explanation lacked a technical detail
that it probably deserved.
I'd be interested in seeing if it can be reinstated sensibly so will try
and take a look.
If that is the quality standard of Phonon development operational mode, I
think I'd rather not care about Phonon at all and pretend it does not exist.
--
R?mi Denis-Courmont
http://www.remlab.net/
salsaman
2010-12-05 00:35:48 UTC
Permalink
I have implemented PA in LiVES for both playback and recording. I can
add the follwoing points:
1) once I had the client coded correctly, I have not observed any
memory leaks due to pulse.

2) pulse implementation is way easier than jack, because jack
callbacks forbid any kind of file IO which requires use of ring
buffers and extra threading. Pulse actually works better if you do
file IO in the callback because it uses variable sized buckets. If
your callback takes too long in jack, your client can be kicked from
the jack server. Pulse is a lot more forgiving.

3) A lot of the earlier problems with pulse and ALSA/OSS turn out to
be distro problems. More recent versions of ubuntu for example seem to
have pretty much fixed this.

4) I'm not using gstreamer so anything to do with pulse/gst does not
really affect me. If I was running a more pro-audio setup I would be
using jack with real time threading enabled, but pulse is fine for the
average desktop user.

Conclusion - if you can fix pulse support rather than remove it, a lot
more people will be happy.

Salsaman.



http://lives.sourceforge.net
https://www.ohloh.net/accounts/salsaman
? Hello,
No, there was not.
Post by Colin Guthrie
commit fa898f1beef7fae7c58fc1284c50a4cb886ad109
Author: Mark Kretschmann <kretschmann at kde.org>
Date: ? Fri Nov 12 07:03:46 2010 +0100
? ? Revert "Disable usage of Xlib"
? ? This reverts commit 3b1835d70aa38e4d86bcb9024c365e6b353766e4.
? ? This revert was recommended by j-b, as the commit broke Phonon-VLC
in many cases.
? ? (mine didn't work at all).
This does not explain why it would have allegedly "broken" Phonon-VLC. And it
does not explain how it will not reintroduce the problem that the commit did
fix.
Besides, anything that this commit might have "broken" was surely already
broken to begin with.
Post by Colin Guthrie
Although I will grant you that the explanation lacked a technical detail
that it probably deserved.
I'd be interested in seeing if it can be reinstated sensibly so will try
and take a look.
If that is the quality standard of Phonon development operational mode, I
think I'd rather not care about Phonon at all and pretend it does not exist.
--
R?mi Denis-Courmont
http://www.remlab.net/
_______________________________________________
vlc-devel mailing list
http://mailman.videolan.org/listinfo/vlc-devel
salsaman
2010-12-05 00:37:21 UTC
Permalink
Don't bother with phonon - I think only xine and amarok use it.

Salsaman.

http://lives.sourceforge.net
https://www.ohloh.net/accounts/salsaman
? Hello,
No, there was not.
Post by Colin Guthrie
commit fa898f1beef7fae7c58fc1284c50a4cb886ad109
Author: Mark Kretschmann <kretschmann at kde.org>
Date: ? Fri Nov 12 07:03:46 2010 +0100
? ? Revert "Disable usage of Xlib"
? ? This reverts commit 3b1835d70aa38e4d86bcb9024c365e6b353766e4.
? ? This revert was recommended by j-b, as the commit broke Phonon-VLC
in many cases.
? ? (mine didn't work at all).
This does not explain why it would have allegedly "broken" Phonon-VLC. And it
does not explain how it will not reintroduce the problem that the commit did
fix.
Besides, anything that this commit might have "broken" was surely already
broken to begin with.
Post by Colin Guthrie
Although I will grant you that the explanation lacked a technical detail
that it probably deserved.
I'd be interested in seeing if it can be reinstated sensibly so will try
and take a look.
If that is the quality standard of Phonon development operational mode, I
think I'd rather not care about Phonon at all and pretend it does not exist.
--
R?mi Denis-Courmont
http://www.remlab.net/
_______________________________________________
vlc-devel mailing list
http://mailman.videolan.org/listinfo/vlc-devel
Rémi Duraffort
2010-12-06 17:42:06 UTC
Permalink
Post by salsaman
Don't bother with phonon - I think only xine and amarok use it.
Yes but amarok for windows (not finished AFAIK) is based on
phonon-vlc and I think that's a reason to care about phonon-vlc.


Best regards
--
R?mi Duraffort | ivoire
http://ivoire.dinauz.org/blog/
Rémi Denis-Courmont
2010-12-06 18:08:39 UTC
Permalink
On Mon, 6 Dec 2010 18:42:06 +0100, R?mi Duraffort <ivoire at videolan.org>
Post by Rémi Duraffort
Post by salsaman
Don't bother with phonon - I think only xine and amarok use it.
Yes but amarok for windows (not finished AFAIK) is based on
phonon-vlc and I think that's a reason to care about phonon-vlc.
No. If that's how Phonon dudes do not communicate and do not manage quality
issues, then we should ignore them.
--
R?mi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis
Jean-Baptiste Kempf
2010-12-06 22:47:45 UTC
Permalink
Post by Rémi Denis-Courmont
No. If that's how Phonon dudes do not communicate and do not manage quality
issues, then we should ignore them.
Markey tried his best to test the issue.
He probably was wrong, but we are working on a solution, especially on
the libpulse integration side.

Phonon-VLC still has issues, but it has improved tremendously in the
past 6 months, thanks to apachelogger, coling and markey. And we try to
make it better. Sure it won't be the silver bullet, but it work decently
now (except the infamous pulse issue).

Best Regards,
--
Jean-Baptiste Kempf
http://www.jbkempf.com/
+33 672 704 734
Jean-Baptiste Kempf
2010-12-06 22:44:54 UTC
Permalink
Post by salsaman
Don't bother with phonon - I think only xine and amarok use it.
How about:
- you stop trolling this mailing-list?
- you about you start learning a minimum about what you are trolling about?
- you learn the minimum of politeness on mailing lists?
- you learn how to stop top-posting?
- you start signing with your real name?
- you start to actually discuss with arguments and not about your opinion?

Because, this is tiring...
--
Jean-Baptiste Kempf
http://www.jbkempf.com/
+33 672 704 734
salsaman
2010-12-05 00:44:17 UTC
Permalink
A runtime check can be done by forking and calling pa_context_get_server_info().

Salsaman.

http://lives.sourceforge.net
https://www.ohloh.net/accounts/salsaman
Post by Colin Guthrie
Hi,
'Twas brillig, and R?mi Denis-Courmont at 29/11/10 16:25 did gyre and
Post by Rémi Denis-Courmont
Post by Colin Guthrie
Post by Rémi Denis-Courmont
* Lennart pretends that the future of audio on open-source is gstreamer
in front of PulseAudio. By enabling PulseAudio, we give him more credits
than he deserves.
Lennart has his own priorities here, but he fully accepts that gst is
not appropriate for several use cases (e.g. voip).
I am afraid you couldn't have put it worse. I consider VoIP features (low-
latency, symmetric RTP...) to be one of gstreamer largest if not the largest
purely technical advantages over LibVLC.
Perhaps. I'm going on comments from some time ago now. Perhaps things
have changed or perhaps I just misunderstood. Who knows.
Post by Rémi Denis-Courmont
Post by Colin Guthrie
But that said, are you saying that any software developer must be
all-other-project-agnostic?
Oh no. Lennart has freedom of opinion. I'm just saying that if he intends to
make gstreamer/PulseAudio the only 'one' multimedia back-end for Linux/OSS,
then the VideoLAN project should exert its freedom to avoid PulseAudio.
I guess you could look at it that way, but I would have thought it made
sense for a developer to pick one stack and stick with it and try to
make it the best possible stack. That doesn't preclude anyone with a
competing solution trying to better that stack or a part of that stack.
Post by Rémi Denis-Courmont
To put it another way, I am saying that people who pretend to provide system
features should externally be more agnostic. I doubt D-Bus or upstart would
have enjoyed the support they now have if they had been, say GNOME/GTK/glib-
specific.
Perhaps, but this whole argument that PA is in any way "gnome specific"
is just bullshit (not saying that's what you said, it's just a general
statement). It specifically doesn't use glib in it's core, although does
integrate nicely with glib loop based apps and has a convenience gconf
module (although that is just a glorified module loader/config system,
so hardly of any importance in the overall scheme of things and
something I do intend to factor out at any rate).
I've developed for KDE for a while (not massively, just poking in here
and there as time permits) and the biggest thing that pisses me of
generally about KDE is the cry of "why were we not consulted on $X", and
"we were not involved in $Y". This is complete mince. If people want to
be involved in a project they have to *want* to be involved, they have
to see something and decide, "right, I'm going to research and get
involved in $X and then work out the best way to integrate that to KDE".
That's what I did with the PA support in KDE (a large part because I was
getting highly pissed off at people with that kind of attitude). The few
times Lennart has tried to post to KDE lists to make them aware of
something, it just gets thrown in his face - sure he likes to be
antagonistic at times, but that's just his personality - I don't agree
with all the things he says either, but I can separate these things
pragmatically (and take a light hearted view of it too).
And don't think for a second there is any particular anti-VLC slant here
that warrants some kind of retaliation by avoiding PA. He has this
opinion of just about everything that isn't his install on his systems.
If you use Gentoo you're smoking crack, if you don't use rpm you're
insane, if you try to do your own media decoding then you should be
wearing a jacket that buckles at the back etc. etc. (I've made them all
up, but I'm sure they could be attributed to him!). This is just his way
and how he focuses on the jobs important to him. It's not personal and
it shouldn't be taken that way. I certainly don't when he's critical of
things I've done or said.
Post by Rémi Denis-Courmont
I did consider (re)writing the PA output and adding the input. But I got so
annoyed with his attitude over time.
To avoid something because of personality issues is a real shame. In a
corporate environment people have to do work for people higher up the
chain of command that they can't stand. They do it ultimately because
they are paid and perhaps want to further their career, but ultimately
the overall strategy of doing a body of work is determined because it's
the best route forward, and pretty much factors out micro-management
personalities.
Is the entire open source community one big happy family? No. Are there
political arguments about trivial things all the time? Yes. Are
technical decisions based on personalities? Sadly, it seems so. I'd have
hoped people were more interested in the FOSS part rather than
individual personalities but I guess everyone has their own reasons for
contributing to the FOSS movement and not everyone is able to be quite
as pragmatic about these things.
Post by Rémi Denis-Courmont
Post by Colin Guthrie
Post by Rémi Denis-Courmont
* Much of what PulseAudio does, VLC and/or alsa-lib can do, notably
resampling, sample format conversion and software mixing. I am yet to
find any practical justification for PulseAudio.
This is a tiny part of what PA does. Support for network transparency
(e.g. thin clients or simply SSH'ing to another machine),
VLC couldn't care less. It cannot do network transparency due to video.
Oh, I thought VLC could play audio too. I've certainly run e.g. Amarok
or Rhythmbox etc. via X11 protocol on several occasions. I regularly run
VirtualBox on a bigger iron machine than I run for testing purposes.
Having sound is often essential in those circumstances.
And whether something is important to VLC or not is not the only thing
to consider. If the *system* that VLC runs on has a need for these
things, then VLC has to fit in with that and be respectful of the stack
rather than unilaterally imposing policy.
Post by Rémi Denis-Courmont
Post by Colin Guthrie
support for timer-based scheduling for use in low-power environments
(e.g. mobile phones, tablets etc. - why do you think Nokia and Intel are so
involved?), (proper) support for bluetooth devices,
support for network devices such as UPnP and Apple Airtunes
VLC has to support ROAP natively because PulseAudio is not running on most
systems that VLC runs on. But you probably know that since both PA and VLC
reverse-engineered and implemented it at the same time.
As a Linux user, I would be totally fine ditching the VLC implementation. But
guess what happens then?
Yeah I fully appreciate the need for this just now due to the way things
work. I'd far rather see Linux+PA+raop, OSX+airofoil/general RA stuff
and Windows+$RAOPSYSTEM work such that the stack itself supports these
things rather than having to reinvent the wheel in $APP. It makes much
more logical sense, but I appreciate why this isn't quite there yet on
all platforms.
The power point still stands too. If you want to use VLC on tablets and
and mobile environments for playing audio, then this is something to
really look into. You want to push 2s+ of audio decode into PA and then
just sleep for 2s if at all possible.
Post by Rémi Denis-Courmont
Post by Colin Guthrie
etc. etc. While some of these
can be done outwith PA, they are generally not properly integrated and
require manual configuration and don't deal properly with hotswapping etc.
With each application and framework doing their own thing, they each
individually have to provide audio configuration GUIs leading to poorly
integrated HCI rules and novice users really not having the first clue
what to do with their audio when using $APPLICATION. By providing a
central GUI in the desktop environment for controlling audio devices,
users can have a clearly defined method of making adjustments, which is
much better overall for Linux adoption by the non-l337.
And the end result is that VLC gets complaints about having its own things,
never mind that it has to. That's not really an improvement from my VLC
developer's perspective. Not to mention that many even Linux+PulseAudio users
would be quite pissed off if VLC stopped providing its own UI controls for
itself. I mean, I doubt users would be very happy if the VLC user interface
would reconfigure the whole system through PulseAudio, instead of just the VLC
instance media.
I'd say there would be less Linux+PA users that would be pissed off than
any other users would be if it were removed. But that's beside the point
really. I think the point still stands that if I pair my bluetooth
headphones with my computer, I want a quick and easy way to direct audio
to them regardless of individual application configuration. Having a
central place of config is still a very desirable goal.
Post by Rémi Denis-Courmont
In all due fairness, the fact that ALSA, Windows and MacOS are more limited is
not at all PulseAudio's fault, and most of PulseAudio's goals are technically
good. But unfortunately, this has brought more problems than solutions to us.
I can appreciate the frustration this causes. I'll try and do my best to
help alleviate these problems. Please feel free to ping me directly with
anything that I could help with as I don't keep up-to-date with these
lists all the time.
Post by Rémi Denis-Courmont
Post by Colin Guthrie
Really, the software mixing and resampling isn't the primary reason to
use PA and if you think that's all it is, I'm not surprised you doubt
it. But to make such bold statements while clearly lacking (or
withholding) knowledge on a given topic does not seem fair.
PS FWIW, I will submit a patch to disable, at runtime, the calls to the
xlib stuff in the VLC plugin in the next couple days.
I think this is already done in 1.2.0-git, but it is static. In other words,
VLC 1.2.0 requires libpulse 0.9.22 or later. I am not very keen on backporting
this as we will get a flood of "you suckers, VLC 1.1.6 bugfix releases
requires a new version of PulseAudio that my distro does not have" messages.
This is a run-time check. The plugin probe function is still called, and
expected to fail before it calls XOpenDisplay().
Ahh cool. I guess the problem remains that VLC could be compiled against
0.9,22 but still run against 0.9.21 which was my main concern with a
compile-time option (there is no libpulse lib-major difference as the
API is the same).
A runtime check should be fairly simple. Do you want me to take a look
still or do you think the current approach will catch enough of the
problem cases (most users should upgrade all their distro packages
together after all and if you self compile it should be caught too).
Take care
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
?Tribalogic Limited [http://www.tribalogic.net/]
?Mageia Contributor [http://www.mageia.org/]
?PulseAudio Hacker [http://www.pulseaudio.org/]
?Trac Hacker [http://trac.edgewall.org/]
_______________________________________________
vlc-devel mailing list
http://mailman.videolan.org/listinfo/vlc-devel
salsaman
2010-12-05 00:51:07 UTC
Permalink
http://lives.sourceforge.net
https://www.ohloh.net/accounts/salsaman
Post by salsaman
A runtime check can be done by forking and calling pa_context_get_server_info().
Sorry, I meant pa_context_connect().

pa_threaded_mainloop *pa_mloop=pa_threaded_mainloop_new();

pa_context *pcon=pa_context_new(pa_threaded_mainloop_get_api(pa_mloop),"VLC");
pa_context_connect(pcon,NULL,0,NULL);
pa_threaded_mainloop_start(pa_mloop);

pa_context_state_t pa_state=pa_context_get_state(pcon);

Then keep checking pa_state until you get either PA_CONTEXT_READY or
you time out.


Salsaman.
Post by salsaman
Salsaman.
http://lives.sourceforge.net
https://www.ohloh.net/accounts/salsaman
Post by Colin Guthrie
Hi,
'Twas brillig, and R?mi Denis-Courmont at 29/11/10 16:25 did gyre and
Post by Rémi Denis-Courmont
Post by Colin Guthrie
Post by Rémi Denis-Courmont
* Lennart pretends that the future of audio on open-source is gstreamer
in front of PulseAudio. By enabling PulseAudio, we give him more credits
than he deserves.
Lennart has his own priorities here, but he fully accepts that gst is
not appropriate for several use cases (e.g. voip).
I am afraid you couldn't have put it worse. I consider VoIP features (low-
latency, symmetric RTP...) to be one of gstreamer largest if not the largest
purely technical advantages over LibVLC.
Perhaps. I'm going on comments from some time ago now. Perhaps things
have changed or perhaps I just misunderstood. Who knows.
Post by Rémi Denis-Courmont
Post by Colin Guthrie
But that said, are you saying that any software developer must be
all-other-project-agnostic?
Oh no. Lennart has freedom of opinion. I'm just saying that if he intends to
make gstreamer/PulseAudio the only 'one' multimedia back-end for Linux/OSS,
then the VideoLAN project should exert its freedom to avoid PulseAudio.
I guess you could look at it that way, but I would have thought it made
sense for a developer to pick one stack and stick with it and try to
make it the best possible stack. That doesn't preclude anyone with a
competing solution trying to better that stack or a part of that stack.
Post by Rémi Denis-Courmont
To put it another way, I am saying that people who pretend to provide system
features should externally be more agnostic. I doubt D-Bus or upstart would
have enjoyed the support they now have if they had been, say GNOME/GTK/glib-
specific.
Perhaps, but this whole argument that PA is in any way "gnome specific"
is just bullshit (not saying that's what you said, it's just a general
statement). It specifically doesn't use glib in it's core, although does
integrate nicely with glib loop based apps and has a convenience gconf
module (although that is just a glorified module loader/config system,
so hardly of any importance in the overall scheme of things and
something I do intend to factor out at any rate).
I've developed for KDE for a while (not massively, just poking in here
and there as time permits) and the biggest thing that pisses me of
generally about KDE is the cry of "why were we not consulted on $X", and
"we were not involved in $Y". This is complete mince. If people want to
be involved in a project they have to *want* to be involved, they have
to see something and decide, "right, I'm going to research and get
involved in $X and then work out the best way to integrate that to KDE".
That's what I did with the PA support in KDE (a large part because I was
getting highly pissed off at people with that kind of attitude). The few
times Lennart has tried to post to KDE lists to make them aware of
something, it just gets thrown in his face - sure he likes to be
antagonistic at times, but that's just his personality - I don't agree
with all the things he says either, but I can separate these things
pragmatically (and take a light hearted view of it too).
And don't think for a second there is any particular anti-VLC slant here
that warrants some kind of retaliation by avoiding PA. He has this
opinion of just about everything that isn't his install on his systems.
If you use Gentoo you're smoking crack, if you don't use rpm you're
insane, if you try to do your own media decoding then you should be
wearing a jacket that buckles at the back etc. etc. (I've made them all
up, but I'm sure they could be attributed to him!). This is just his way
and how he focuses on the jobs important to him. It's not personal and
it shouldn't be taken that way. I certainly don't when he's critical of
things I've done or said.
Post by Rémi Denis-Courmont
I did consider (re)writing the PA output and adding the input. But I got so
annoyed with his attitude over time.
To avoid something because of personality issues is a real shame. In a
corporate environment people have to do work for people higher up the
chain of command that they can't stand. They do it ultimately because
they are paid and perhaps want to further their career, but ultimately
the overall strategy of doing a body of work is determined because it's
the best route forward, and pretty much factors out micro-management
personalities.
Is the entire open source community one big happy family? No. Are there
political arguments about trivial things all the time? Yes. Are
technical decisions based on personalities? Sadly, it seems so. I'd have
hoped people were more interested in the FOSS part rather than
individual personalities but I guess everyone has their own reasons for
contributing to the FOSS movement and not everyone is able to be quite
as pragmatic about these things.
Post by Rémi Denis-Courmont
Post by Colin Guthrie
Post by Rémi Denis-Courmont
* Much of what PulseAudio does, VLC and/or alsa-lib can do, notably
resampling, sample format conversion and software mixing. I am yet to
find any practical justification for PulseAudio.
This is a tiny part of what PA does. Support for network transparency
(e.g. thin clients or simply SSH'ing to another machine),
VLC couldn't care less. It cannot do network transparency due to video.
Oh, I thought VLC could play audio too. I've certainly run e.g. Amarok
or Rhythmbox etc. via X11 protocol on several occasions. I regularly run
VirtualBox on a bigger iron machine than I run for testing purposes.
Having sound is often essential in those circumstances.
And whether something is important to VLC or not is not the only thing
to consider. If the *system* that VLC runs on has a need for these
things, then VLC has to fit in with that and be respectful of the stack
rather than unilaterally imposing policy.
Post by Rémi Denis-Courmont
Post by Colin Guthrie
support for timer-based scheduling for use in low-power environments
(e.g. mobile phones, tablets etc. - why do you think Nokia and Intel are so
involved?), (proper) support for bluetooth devices,
support for network devices such as UPnP and Apple Airtunes
VLC has to support ROAP natively because PulseAudio is not running on most
systems that VLC runs on. But you probably know that since both PA and VLC
reverse-engineered and implemented it at the same time.
As a Linux user, I would be totally fine ditching the VLC implementation. But
guess what happens then?
Yeah I fully appreciate the need for this just now due to the way things
work. I'd far rather see Linux+PA+raop, OSX+airofoil/general RA stuff
and Windows+$RAOPSYSTEM work such that the stack itself supports these
things rather than having to reinvent the wheel in $APP. It makes much
more logical sense, but I appreciate why this isn't quite there yet on
all platforms.
The power point still stands too. If you want to use VLC on tablets and
and mobile environments for playing audio, then this is something to
really look into. You want to push 2s+ of audio decode into PA and then
just sleep for 2s if at all possible.
Post by Rémi Denis-Courmont
Post by Colin Guthrie
etc. etc. While some of these
can be done outwith PA, they are generally not properly integrated and
require manual configuration and don't deal properly with hotswapping etc.
With each application and framework doing their own thing, they each
individually have to provide audio configuration GUIs leading to poorly
integrated HCI rules and novice users really not having the first clue
what to do with their audio when using $APPLICATION. By providing a
central GUI in the desktop environment for controlling audio devices,
users can have a clearly defined method of making adjustments, which is
much better overall for Linux adoption by the non-l337.
And the end result is that VLC gets complaints about having its own things,
never mind that it has to. That's not really an improvement from my VLC
developer's perspective. Not to mention that many even Linux+PulseAudio users
would be quite pissed off if VLC stopped providing its own UI controls for
itself. I mean, I doubt users would be very happy if the VLC user interface
would reconfigure the whole system through PulseAudio, instead of just the VLC
instance media.
I'd say there would be less Linux+PA users that would be pissed off than
any other users would be if it were removed. But that's beside the point
really. I think the point still stands that if I pair my bluetooth
headphones with my computer, I want a quick and easy way to direct audio
to them regardless of individual application configuration. Having a
central place of config is still a very desirable goal.
Post by Rémi Denis-Courmont
In all due fairness, the fact that ALSA, Windows and MacOS are more limited is
not at all PulseAudio's fault, and most of PulseAudio's goals are technically
good. But unfortunately, this has brought more problems than solutions to us.
I can appreciate the frustration this causes. I'll try and do my best to
help alleviate these problems. Please feel free to ping me directly with
anything that I could help with as I don't keep up-to-date with these
lists all the time.
Post by Rémi Denis-Courmont
Post by Colin Guthrie
Really, the software mixing and resampling isn't the primary reason to
use PA and if you think that's all it is, I'm not surprised you doubt
it. But to make such bold statements while clearly lacking (or
withholding) knowledge on a given topic does not seem fair.
PS FWIW, I will submit a patch to disable, at runtime, the calls to the
xlib stuff in the VLC plugin in the next couple days.
I think this is already done in 1.2.0-git, but it is static. In other words,
VLC 1.2.0 requires libpulse 0.9.22 or later. I am not very keen on backporting
this as we will get a flood of "you suckers, VLC 1.1.6 bugfix releases
requires a new version of PulseAudio that my distro does not have" messages.
This is a run-time check. The plugin probe function is still called, and
expected to fail before it calls XOpenDisplay().
Ahh cool. I guess the problem remains that VLC could be compiled against
0.9,22 but still run against 0.9.21 which was my main concern with a
compile-time option (there is no libpulse lib-major difference as the
API is the same).
A runtime check should be fairly simple. Do you want me to take a look
still or do you think the current approach will catch enough of the
problem cases (most users should upgrade all their distro packages
together after all and if you self compile it should be caught too).
Take care
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
?Tribalogic Limited [http://www.tribalogic.net/]
?Mageia Contributor [http://www.mageia.org/]
?PulseAudio Hacker [http://www.pulseaudio.org/]
?Trac Hacker [http://trac.edgewall.org/]
_______________________________________________
vlc-devel mailing list
http://mailman.videolan.org/listinfo/vlc-devel
Colin Guthrie
2010-12-05 17:21:28 UTC
Permalink
Post by salsaman
http://lives.sourceforge.net
https://www.ohloh.net/accounts/salsaman
Post by salsaman
A runtime check can be done by forking and calling pa_context_get_server_info().
Sorry, I meant pa_context_connect().
pa_threaded_mainloop *pa_mloop=pa_threaded_mainloop_new();
pa_context *pcon=pa_context_new(pa_threaded_mainloop_get_api(pa_mloop),"VLC");
pa_context_connect(pcon,NULL,0,NULL);
pa_threaded_mainloop_start(pa_mloop);
pa_context_state_t pa_state=pa_context_get_state(pcon);
Then keep checking pa_state until you get either PA_CONTEXT_READY or
you time out.
I just meant a runtime check for the version of the library (i.e.
pa_get_library_version()). It's not actually important what version the
server is, so no need to connect to the server first.

But as R?mi pointed out, there is likely not much need to go into this
kind of detailed check and a built time check is probably sufficient.

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