[LAU] Installing Google Voice Chat for Linux on Fedora instead of Debian

[Niels Mayer]

On Wed, Sep 8, 2010 at 7:31 AM, Paul Davis <paul at linuxaudiosystems.com> wrote:
> most (or maybe just a lot of) code doesn't use PulseAudio directly at
> all. it opens an ALSA device that is implemented by the Pulse ALSA
> user-space plugin.
>
> last time i looked lennart was still encouraging people NOT to use the
> PulseAudio API for writing apps, but people are.

Thanks for the clarification.

The underlying issue is that in practice most gnome apps, attempt to
contact pulseaudio first, failing with "socket(): Address family not
supported by protocol" and causing a short delay before directly going
to the device.

Since pulse is completely uninstalled  on the systems where I see this
problem, there's no chance that the ALSA user-space plugin is being
invoked, since neither of these packages are installed
"alsa-plugins-pulseaudio.i686" or "alsa-plugins-pulseaudio.x86_64"

Unfortunately, I see this behavior across-the-board in all Gnome
applications, which is one of the reasons why I switched to KDE for
everything other than ardour, emacs, evolution, google-chrome, and
gnote. Of course, ardour behaves impeccably -- you've trained it well
:-) Most of the rest can be taught to behave by setting up gnome
configuration to not use any system sounds, and sometimes apps like
http://googsystray.sourceforge.net/ need to be explicitly told in
every possible setting not to use "system sounds" for notification
(despite global gnome settings to the contrary).

So the question remains, is there a single configuration setting or
environment variable that can prevent applications from even trying to
use pulseaudio API directly? Despite Lennart's warning, it seems like
most gnome applications have this problem, which lead me to believe
that underlying gnome libs are the ones using the pulseaudio API
directly.

Alternately, maybe we just need a "null socket hack" so that
pulseaudio finds the ""socket(): Address family not supported by
protocol"  and that socket immediately closes and causes pulseaudio to
get an error. At least  then you won't have the annoying few seconds
of waiting every time an audio connection is made.

(And of course, the "system" should recognize that if pulse is not
running, it shouldn't keep attempting to connect to its socket -- IMHO
that's an underlying gnome bug).

-- Niels
http://nielsmayer.com