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

[Niels Mayer]

Excited to see
http://googleblog.blogspot.com/2010/08/call-phones-from-gmail.html , I was
quickly disappointed to find the plugin only supported debian and was 32
bit. However, I persevered and got it running on Fedora 12 x86_64 anyways.

Solution:
http://www.google.com/support/forum/p/chat/thread?tid=10ffe01c3a4779f5&hl=en&fid=10ffe01c3a4779f500048eaedc559f0f

Google ought to hire someone that knows about App Development and Linux
Audio and Fedora packaging (me?) to make the audio/video experience nicer
for it's Linux users. In particular, not just blindly using ALSA devices for
input that cannot possibly support audio capture, although I guess I'm a
fringe-case since I don't use pulseaudio, since I've got KDE's phonon setup
to do the right thing w/r/t all my audio devices, including the ones talking
via Jackd. (
http://ccrma-mail.stanford.edu/pipermail/planetccrma/2010-May/016886.html ).
Also, not assuming every Linux user runs a debian/ubuntu distro would be
helpful as well :-)

---------- Forwarded message ----------
From: Google Help <***@google.com>
Date: Wed, Aug 25, 2010 at 5:13 PM
Subject: Re: [Google Chat Help] Linux version now available!
To: ***@gmail.com


NielsMayer has posted an answer to the question "Linux version now
available!":

FYI, adventures in Installing google talk on fedora 12 x86_64

Linux installation doesn't distinguish between Fedora/OpenSUSE and
Debian/Ubuntu linux systems, so you get a download for the wrong distro:
-rw-r--r-- 1 npm npm 6926676 2010-08-25 15:47
google-talkplugin_current_amd64.deb

Which can be unpacked via ark(1) or file-roller(1) and contains a file
data.tar.gz

I installed the plugin for chrome/mozilla 64 bit by doing
132 16:01 cd /
134 16:02 sudo tar xvzf ~/Download/data.tar.gz ./opt/google/talkplugin
151 16:11 cd /usr/lib64/mozilla/plugins
## (or /usr/lib ... for 32 bit)
152 16:11 sudo ln -s /opt/google/talkplugin/libnpgoogletalk64.so
/opt/google/talkplugin/libnpgtpo3dautoplugin.so .

now, about:/plugins shows the existence of the plugin:

Google Talk Plugin (2 files)
Version: 1.4.1.0
Name: Google Talk Plugin
Description: Version: 1.4.1.0
Version:
Priority: 1
Location: /opt/google/talkplugin/libnpgoogletalk64.so
Disable
MIME types:
MIME type Description File extensions
application/googletalk Google Talk Plugin
.googletalk
Name: Google Talk Plugin Video Accelerator
Description: Google Talk Plugin Video Accelerator version:0.1.43.3
Version:
Priority: 2
Location: /opt/google/talkplugin/libnpgtpo3dautoplugin.so
Disable
MIME types:
MIME type Description File extensions
application/vnd.gtpo3d.auto O3D MIME
.

However, back in gmail. clicking on the "call phone" doesn't work....

Issue:

gnulem-230-~/Download> /opt/google/talkplugin/GoogleTalkPlugin
/opt/google/talkplugin/GoogleTalkPlugin: error while loading shared
libraries: libssl.so.0.9.8: cannot open shared object file: No such file or
directory

Solving:

gnulem-236-/usr/lib> sudo ln -s libssl.so.1.0.0a libssl.so.0.9.8

## note the plugin seems to rely on 32 bit libraries being installed, which
fortunately,
## they are even though I have x86_64 system as i've needed to run other 32
bit binaries...

Issue:

gnulem-245-~> /opt/google/talkplugin/GoogleTalkPlugin
/opt/google/talkplugin/GoogleTalkPlugin: error while loading shared
libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file
or directory

Solving:

gnulem-247-~> sudo ln -s /usr/lib/libcrypto.so.1.0.0a
/usr/lib/libcrypto.so.0.9.8

gnulem-248-~> /opt/google/talkplugin/GoogleTalkPlugin
/opt/google/talkplugin/GoogleTalkPlugin: /usr/lib/libcrypto.so.0.9.8: no
version information available (required by
/opt/google/talkplugin/GoogleTalkPlugin)
/opt/google/talkplugin/GoogleTalkPlugin: /usr/lib/libssl.so.0.9.8: no
version information available (required by
/opt/google/talkplugin/GoogleTalkPlugin)
socket(): Address family not supported by protocol
socket(): Address family not supported by protocol

restarting chrome... and it ...
!!!!!!!!!!!!!!!!!!!!!!!! WORKS !!!!!!!!!!!!!!!!!!!!!!!!


testing in a call, I'm using an ALSA device that doesn't have input by
default

gnulem-253-~> /opt/google/talkplugin/GoogleTalkPlugin
/opt/google/talkplugin/GoogleTalkPlugin: /usr/lib/libcrypto.so.0.9.8: no
version information available (required by
/opt/google/talkplugin/GoogleTalkPlugin)
/opt/google/talkplugin/GoogleTalkPlugin: /usr/lib/libssl.so.0.9.8: no
version information available (required by
/opt/google/talkplugin/GoogleTalkPlugin)

socket(): Address family not supported by protocol
socket(): Address family not supported by protocol
socket(): Address family not supported by protocol
ALSA lib pcm_dmix.c:957:(snd_pcm_dmix_open) The dmix plugin supports only
playback stream

Issue:

Given my default ALSA device is a dmix device, I now need to totally rework
http://nielsmayer.com/npm/dot-asoundrc.txt to make this all useful....


-- Nielsl
http://nielsmayer.com

[A. C. Censi]

Excited to see http://googleblog.blogspot.com/2010/08/call-phones-from-gmail.html , I was quickly disappointed to find the plugin only supported debian and was 32 bit.

alien can convert packages between deb and rpm.
http://kitenet.net/~joey/code/alien/

--
A. C. Censi
accensi [em] gmail [ponto] com
accensi [em] montreal [ponto] com [ponto] br

[Patrick Shirkey]

Post by Niels Mayer
Excited to see
http://googleblog.blogspot.com/2010/08/call-phones-from-gmail.html , I was
quickly disappointed to find the plugin only supported debian and was 32
bit. However, I persevered and got it running on Fedora 12 x86_64 anyways.
http://www.google.com/support/forum/p/chat/thread?tid=10ffe01c3a4779f5&hl=en&fid=10ffe01c3a4779f500048eaedc559f0f
Google ought to hire someone that knows about App Development and Linux
Audio and Fedora packaging (me?) to make the audio/video experience nicer
for it's Linux users. In particular, not just blindly using ALSA devices for
input that cannot possibly support audio capture, although I guess I'm a
fringe-case since I don't use pulseaudio, since I've got KDE's phonon setup
to do the right thing w/r/t all my audio devices, including the ones talking
via Jackd. (
http://ccrma-mail.stanford.edu/pipermail/planetccrma/2010-May/016886.html ).
Also, not assuming every Linux user runs a debian/ubuntu distro would be
helpful as well :-)

IIUC it's internal policy to develop their linux apps on ubuntu. that's
why they always release packages for ubuntu first before the other
distros.

Post by Niels Mayer
---------- Forwarded message ----------
Date: Wed, Aug 25, 2010 at 5:13 PM
Subject: Re: [Google Chat Help] Linux version now available!
NielsMayer has posted an answer to the question "Linux version now
FYI, adventures in Installing google talk on fedora 12 x86_64
Linux installation doesn't distinguish between Fedora/OpenSUSE and
-rw-r--r-- 1 npm npm 6926676 2010-08-25 15:47
google-talkplugin_current_amd64.deb
Which can be unpacked via ark(1) or file-roller(1) and contains a file
data.tar.gz
I installed the plugin for chrome/mozilla 64 bit by doing
132 16:01 cd /
134 16:02 sudo tar xvzf ~/Download/data.tar.gz ./opt/google/talkplugin
151 16:11 cd /usr/lib64/mozilla/plugins
## (or /usr/lib ... for 32 bit)
152 16:11 sudo ln -s /opt/google/talkplugin/libnpgoogletalk64.so
/opt/google/talkplugin/libnpgtpo3dautoplugin.so .
Google Talk Plugin (2 files)
Version: 1.4.1.0
Name: Google Talk Plugin
Description: Version: 1.4.1.0
Priority: 1
Location: /opt/google/talkplugin/libnpgoogletalk64.so
Disable
MIME type Description File extensions
application/googletalk Google Talk Plugin
.googletalk
Name: Google Talk Plugin Video Accelerator
Description: Google Talk Plugin Video Accelerator version:0.1.43.3
Priority: 2
Location: /opt/google/talkplugin/libnpgtpo3dautoplugin.so
Disable
MIME type Description File extensions
application/vnd.gtpo3d.auto O3D MIME
.
However, back in gmail. clicking on the "call phone" doesn't work....
gnulem-230-~/Download> /opt/google/talkplugin/GoogleTalkPlugin
/opt/google/talkplugin/GoogleTalkPlugin: error while loading shared
libraries: libssl.so.0.9.8: cannot open shared object file: No such file or
directory
gnulem-236-/usr/lib> sudo ln -s libssl.so.1.0.0a libssl.so.0.9.8
## note the plugin seems to rely on 32 bit libraries being installed, which
fortunately,
## they are even though I have x86_64 system as i've needed to run other 32
bit binaries...
gnulem-245-~> /opt/google/talkplugin/GoogleTalkPlugin
/opt/google/talkplugin/GoogleTalkPlugin: error while loading shared
libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file
or directory
gnulem-247-~> sudo ln -s /usr/lib/libcrypto.so.1.0.0a
/usr/lib/libcrypto.so.0.9.8
gnulem-248-~> /opt/google/talkplugin/GoogleTalkPlugin
/opt/google/talkplugin/GoogleTalkPlugin: /usr/lib/libcrypto.so.0.9.8: no
version information available (required by
/opt/google/talkplugin/GoogleTalkPlugin)
/opt/google/talkplugin/GoogleTalkPlugin: /usr/lib/libssl.so.0.9.8: no
version information available (required by
/opt/google/talkplugin/GoogleTalkPlugin)
socket(): Address family not supported by protocol
socket(): Address family not supported by protocol
restarting chrome... and it ...
!!!!!!!!!!!!!!!!!!!!!!!! WORKS !!!!!!!!!!!!!!!!!!!!!!!!
testing in a call, I'm using an ALSA device that doesn't have input by
default
gnulem-253-~> /opt/google/talkplugin/GoogleTalkPlugin
/opt/google/talkplugin/GoogleTalkPlugin: /usr/lib/libcrypto.so.0.9.8: no
version information available (required by
/opt/google/talkplugin/GoogleTalkPlugin)
/opt/google/talkplugin/GoogleTalkPlugin: /usr/lib/libssl.so.0.9.8: no
version information available (required by
/opt/google/talkplugin/GoogleTalkPlugin)
socket(): Address family not supported by protocol
socket(): Address family not supported by protocol
socket(): Address family not supported by protocol
ALSA lib pcm_dmix.c:957:(snd_pcm_dmix_open) The dmix plugin supports only
playback stream
Given my default ALSA device is a dmix device, I now need to totally rework
http://nielsmayer.com/npm/dot-asoundrc.txt to make this all useful....
-- Nielsl
http://nielsmayer.com
_______________________________________________
Linux-audio-user mailing list
http://lists.linuxaudio.org/listinfo/linux-audio-user

[david]

Post by Niels Mayer
Excited to
see http://googleblog.blogspot.com/2010/08/call-phones-from-gmail.html ,
I was quickly disappointed to find the plugin only supported debian and
was 32 bit. However, I persevered and got it running on Fedora 12 x86_64
anyways.
http://www.google.com/support/forum/p/chat/thread?tid=10ffe01c3a4779f5&hl=en&fid=10ffe01c3a4779f500048eaedc559f0f
<http://www.google.com/support/forum/p/chat/thread?tid=10ffe01c3a4779f5&hl=en&fid=10ffe01c3a4779f500048eaedc559f0f>
Google ought to hire someone that knows about App Development and Linux
Audio and Fedora packaging (me?) to make the audio/video experience
nicer for it's Linux users. In particular, not just blindly using ALSA
devices for input that cannot possibly support audio capture,

Don't blame Google for that. On all five of the computers around here,
ALSA sets up the PC speaker as an input source!

Post by Niels Mayer
although I
guess I'm a fringe-case since I don't use pulseaudio, since I've got
KDE's phonon setup to do the right thing w/r/t all my audio devices,
including the ones talking via Jackd.
( http://ccrma-mail.stanford.edu/pipermail/planetccrma/2010-May/016886.html ).
Also, not assuming every Linux user runs a debian/ubuntu distro would be
helpful as well :-)

But all five of the computers here run Debian and have for many years.
Outside a few folk on LAU, I don't know anyone who runs Fedora. So,
clearly, you are a fringe-case. ;-)

[Niels Mayer]

Don't blame Google for that. On all five of the computers around here, ALSA sets up the PC speaker as an input source!

Skype beta for Linux (2.1.0.47), for example, uses, or works well
alongside the phonon framework. That way, when i setup
SystemSettings->ComputerAdministration->Multimedia->{AudioOutput,AudioCapture}->Communication->LogitechUSBHeadset
, skype ends up using the headset. And if some other app, like
google-chrome&voice are hogging the headset even when not actively
using them, skype will automatically go on and use the next configured
device. If that "device" happens to be Jackd, then phonon will do the
right thing and actually invoke jackd with all the right arguments. (I
was surprised by the level of "magical" Jack integration  in phonon).

No such luck with either google-chrome or this new google-voice thing.
I might end up giving konqueror a go since at least it will use phonon
to connect the browser to the audio devices.

But all five of the computers here run Debian and have for many years. Outside a few folk on LAU, I don't know anyone who runs Fedora. So, clearly, you are a fringe-case. ;-)

Seems like Fedora is preferred by those that are professional computer
scientists or engineers, whereas Ubuntu is targeted at consumers.
Likewise, since Fedora eventually becomes Red Hat Enterprise Linux,
there's a good chance your financial institutions, telecom companies,
online web services, etc are actually using product versions of
"Fedora 10" or "Fedora 11."  How exactly is that "fringe" ?

As to why there might be Fedora users on LAU, consider the existence
of a major repository of Pro Audio/Video software (and realtime
patches of current fedora kernels)
http://ccrma.stanford.edu/planetccrma/software/ as well as the fact
that ALSA creator http://en.wikipedia.org/wiki/Jaroslav_Kysela works
there as well as Pulseaudio creator
http://fedoraproject.org/wiki/Interviews/LennartPoettering .

Also, ignoring the entire RPM community doesn't just ignore Fedora, it
also ignores http://www.opensuse.org/ a major distro with backing from
Novell and AMD. (Which might be the real reason for making RPM second
fiddle at Google -- the fact that Suse Linux Enterprise and Desktop
provides competition to Google's main business: stealing all of
Microsoft's Office and .Net customers:
http://techrights.org/2009/03/24/sled-11-is-about-mono-tech/ ).

The most popular answer on google's help for google-voice:
http://www.google.com/support/forum/p/chat/thread?tid=10ffe01c3a4779f5
...........
8/19/10 Popular answer
Great! Any word on how soon we can expect an RPM package? :-)
..........
supporting linux means releasing a source not a .deb or .rpm package!
try to respect us, release a clean tar.gz file! we can build our own
package! you may have to know that linux distros are not only debian
and redhat.
..........
hunternet93 8/20/10
We need a source package, or at least a binary not locked to any
specific package manager. I'm on Sabayon, and I've been waiting to use
Google video chat for a long time.
..........
jspaleta 8/20/10
Please provide a tar.gz for widest available usage for those of use
not using debian based systems. Ironic..considering that Google is
using portage internally for ChromeOS development. You would think
that a Gentoo friendly tarball would be a priority.
If you decide to make an rpm version as well as providing a tarball...
I'm willing to help even under NDA terms if that is required.  But
having a tar.gz of the binary is more important.
..........
ulif Level 1 8/26/10
Skype provide a RPM package which works without problems on opensuse -
why should I jump through hoops to install Gmail phone/video? Plenty
of other things to do. When Google bring out the RPM (preferably one
for x86_64 CPU) then I am interested.
............

As usual bad ALSA integration and bad mixer interfaces are a problem
with google's
implementation, but not with skype:

............
I had to go into alsamixer and hit F4 to change to the capture
devices. Then I had to turn up the Digital microphone device because
it was turned all the way down. Kind of weird as I never had to crank
that up on Skype or Gizmo or any other VoIP program, but at least it
works and now I'm happy! :D
...........

-- Niels
http://nielsmayer.com

[Niels Mayer]

Google help has another thread with advice that was developed in
parallel with my hack:
http://www.google.com/support/forum/p/chat/thread?tid=273c9ff21a1bbf53
"Installing and Running Google Talk on an RPM-based system"

My current response/status/questions:
http://www.google.com/support/forum/p/chat/thread?tid=273c9ff21a1bbf53&hl=en&fid=273c9ff21a1bbf5300048ed6476fb1fc
..........................
The main issues I'm now having

(1)> socket(): Address family not supported by protocol

The first socket() call emanates from the google-chat daemon/plugin
attempting to contact pulseaudio and failing, since I've disabled it
on my system. It's no biggie -- it just causes the same annoying delay
as all other gnome applications on fedora after you remove pulseaudio.
It's one of the reasons why I switched to the KDE desktop and phonon
as its handling for media is far better than Gnome -- it plays well
alongside jackd sound server used for pro audio/media work, and works
alonside pulseaudio as well. Skype also handles this much better,
resulting in no annoying pause on each audio connection.

(2)> ALSA lib pcm_dmix.c:957:(snd_pcm_dmix_open) The dmix plugin
supports only playback stream

The second line of output is a showstopper for now. The issue is that
I've got a rather interesting ALSA setup (
http://nielsmayer.com/npm/dot-asoundrc.txt ) which has my 'default'
device working as an ALSA dmix device. That and its alias plughw allow
flash and java audio applications to work nicely out of my web
browser, sending audio to a specific soundcard allocated for that
purpose.

Google-chat messes all that up. Unlike skype, which, in the absence of
pulseaudio, allows you to choose a specific card for microphone, a
separate card for speakers/playback, and optionally, a different card
or device for ringing. Which is why I'm still using skype and will
wait until I either figure out a way to hijack the google-chat
daemon's use of ALSA default device for input, or for google to put
out a proper RPM version that works as flexibly as skype "beta" for
linux version 2.1.0.47.

Of course, perhaps there's a command line option or environment
variable in the google voice daemon, or perhaps I need to investigate
what happens when I run it with some ALSA environment variables set (
http://www.alsa-project.org/main/index.php/LibEnvVars ) . I dread to
see what sort of heinosities I'lll see running with "env
LIBASOUND_DEBUG=1 google-chrome" although I guess I could just wrapper
the plugin.

LIBASOUND_DEBUG
=1 print errors to stderr, dump hw_params
=2 also assert(0)
........................

Niels
http://nielsmayer.com

[david]

Post by Niels Mayer

Don't blame Google for that. On all five of the computers around here, ALSA sets up the PC speaker as an input source!

Skype beta for Linux (2.1.0.47), for example, uses, or works well
alongside the phonon framework. That way, when i setup
SystemSettings->ComputerAdministration->Multimedia->{AudioOutput,AudioCapture}->Communication->LogitechUSBHeadset
, skype ends up using the headset. And if some other app, like
google-chrome&voice are hogging the headset even when not actively
using them, skype will automatically go on and use the next configured
device. If that "device" happens to be Jackd, then phonon will do the
right thing and actually invoke jackd with all the right arguments. (I
was surprised by the level of "magical" Jack integration in phonon).
No such luck with either google-chrome or this new google-voice thing.
I might end up giving konqueror a go since at least it will use phonon
to connect the browser to the audio devices.

But all five of the computers here run Debian and have for many years. Outside a few folk on LAU, I don't know anyone who runs Fedora. So, clearly, you are a fringe-case. ;-)

Seems like Fedora is preferred by those that are professional computer
scientists or engineers, whereas Ubuntu is targeted at consumers.
Likewise, since Fedora eventually becomes Red Hat Enterprise Linux,
there's a good chance your financial institutions, telecom companies,
online web services, etc are actually using product versions of
"Fedora 10" or "Fedora 11." How exactly is that "fringe" ?

For Skype/GoogleVoice consumers, they're more likely to be running
Ubuntu than Fedora or RHEL. So, yes, I think Fedora/RHEL is "fringe" for
this particular market.

Post by Niels Mayer
As to why there might be Fedora users on LAU, consider the existence
of a major repository of Pro Audio/Video software (and realtime
patches of current fedora kernels)
http://ccrma.stanford.edu/planetccrma/software/ as well as the fact
that ALSA creator http://en.wikipedia.org/wiki/Jaroslav_Kysela works
there as well as Pulseaudio creator
http://fedoraproject.org/wiki/Interviews/LennartPoettering .

I know. CCRMA software is the only reason I considered Fedora for my
little effectbox.

Maybe the ALSA creator can explain why it always considers a PC speaker
to be INPUT?

I intensely dislike Pulseaudio, so I don't consider its creator a point
in any distro's favor. ;-)

Post by Niels Mayer
Also, ignoring the entire RPM community doesn't just ignore Fedora, it
also ignores http://www.opensuse.org/ a major distro with backing from
Novell and AMD. (Which might be the real reason for making RPM second
fiddle at Google -- the fact that Suse Linux Enterprise and Desktop
provides competition to Google's main business: stealing all of
http://techrights.org/2009/03/24/sled-11-is-about-mono-tech/ ).

Could be true. Don't know much about OpenSUSE, but if it's money is
coming from server rooms, it's not likely to be used by consumers of
Skype/GoogleVoice.

[Niels Mayer]

I finally got tired of google talk for Linux not working due to
ALSA/audio issues (after I'd gotten "this" close hacking the .deb
distribution to work on fedora with chrome, w/o even running googles
init scripts and crontab :-) ) ... so I decided to fix it. The issue
was that the browser was happily working with an ALSA default device
that was set up as a dmix device. It gladly handled whatever bitrates
and depths the web, java, and flash could throw at it.

But google voice comes along, and all it can say is (duh!):
ALSA lib pcm_dmix.c:957:(snd_pcm_dmix_open) The dmix plugin supports
only playback stream
every time I initiate a call. Calls placed result in the landline user
being heard, but the landline user cannot hear the google-voice
caller: no microphone is connected. It's even worse of a fail because
all this output is on the browser's stdout/stderr and usually hidden
from most users in ~/.xsession-errors .

Solving this, and also wanting all my google-talk going to my USB
headset specifically purchased for doing skype and other VoIP
calling.... I did the following:

(0) "cd /opt/google/talkplugin"
(1) "mv GoogleTalkPlugin GoogleTalkPlugin-bin"
(2) Write a wrapper /opt/google/talkplugin/GoogleTalkPlugin :
///// ///// ///// ///// ///// ///// ///// /////
#!/bin/sh
## Tell it to use specicic configuration setting up Headset as
"default"
export ALSA_CONFIG_PATH="/opt/google/talkplugin/GoogleTalkPlugin.conf"
echo STARTING GoogleTalkPlugin-bin with
ALSA_CONFIG_PATH=$ALSA_CONFIG_PATH
exec /opt/google/talkplugin/GoogleTalkPlugin-bin
///// ///// ///// ///// ///// ///// ///// /////
(3) write /opt/google/talkplugin/GoogleTalkPlugin.conf :
///// ///// ///// ///// ///// ///// ///// /////
pcm.!default {
type hw
card Headset
}

ctl.!default {
type hw
card Headset
}
///// ///// ///// ///// ///// ///// ///// /////

Now, it only outputs a message "ALSA lib
control.c:902:(snd_ctl_open_noupdate) Invalid CTL hw:0" but seems to
work fine -- sounds great, on both ends of the call apparently.
Although it should be able to talk to CTL a USB headset, it seems to
be failing. Volumes seem ok anyway and I can control them easily via
kmix.

Here's current output in the course of starting gmail/gvoice and
making a few calls:
///// ///// ///// ///// ///// ///// ///// /////
[000:021] Started GoogleTalkPlugin, path=/opt/google/talkplugin/GoogleTalkPlugin
[000:021] Waiting for GoogleTalkPlugin to start...
STARTING GoogleTalkPlugin-bin with
ALSA_CONFIG_PATH=/opt/google/talkplugin/GoogleTalkPlugin.conf
/opt/google/talkplugin/GoogleTalkPlugin-bin:
/usr/lib/libcrypto.so.0.9.8: no version information available
(required by /opt/google/talkplugin/GoogleTalkPlugin-bin)
/opt/google/talkplugin/GoogleTalkPlugin-bin: /usr/lib/libssl.so.0.9.8:
no version information available (required by
/opt/google/talkplugin/GoogleTalkPlugin-bin)
[001:097] Read port file, port=35756
[001:099] Initiated connection to GoogleTalkPlugin
[001:197] Socket connection established
[001:197] ScheduleOnlineCheck: Online check in 5000ms
[001:296] Got cookie response, socket is authorized
[001:296] AUTHORIZED; socket handshake complete
socket(): Address family not supported by protocol
[006:261] HandleOnlineCheck: Starting check
[006:262] HandleOnlineCheck: OK; current state: 2
ALSA lib control.c:902:(snd_ctl_open_noupdate) Invalid CTL hw:0
socket(): Address family not supported by protocol
ALSA lib control.c:902:(snd_ctl_open_noupdate) Invalid CTL hw:0
socket(): Address family not supported by protocol
socket(): Address family not supported by protocol
[1296:213] Read port file, port=35756
[1296:218] Initiated connection to GoogleTalkPlugin
[1296:301] Socket connection established
[1296:301] ScheduleOnlineCheck: Online check in 5000ms
[1296:305] Got cookie response, socket is authorized
[1296:305] AUTHORIZED; socket handshake complete
socket(): Address family not supported by protocol
ALSA lib control.c:902:(snd_ctl_open_noupdate) Invalid CTL hw:0
[1301:373] HandleOnlineCheck: Starting check
[1301:373] HandleOnlineCheck: OK; current state: 2
socket(): Address family not supported by protocol
ALSA lib control.c:902:(snd_ctl_open_noupdate) Invalid CTL hw:0
///// ///// ///// ///// ///// ///// ///// /////

-- Niels
http://nielsmayer.com

[Niels Mayer]

Now that I've discovered the way of setting hardware devices in
http://mail.google.com/mail/#settings/chat , there's issues that limit
my using GoogleTalkPlugin to "[Logitech USB Headset]" -- a USB headset
that works well.

However,

(1) I have an old Hauppauge PVR-500 dual analog TV card and
/opt/google/talkplugin/GoogleTalkPlugin thinks it's a video camera for
chatting. However, the PVR-500 doesn't work w/ Google Talk, causing
people to attempt to contact by video, but then failing due to this
video device. (However, I could hook up an external old camcorder that
outputs composite or svideo to the PVR500 and it would nicely hardware
mpeg-encode the signal for me, however GoogleTalkPlugin doesn't seem
to recognize any of the output formats.)

There doesn't seem to be a way of telling it not to use a video camera
because i don't have one on this computer.

(2) Attempting to connect a variety of soundcards for input and
output, I found that many, including motherboard soundcards and
built-in snd-hda-intel hardware cannot talk to the GoogleTalkPlugin.
The following errors are issued for output:

(a) sample format mismatch (seen on Terratec DMX6Fire and M-Audio Delta 66).

ALSA lib pcm.c:7320:(snd_pcm_set_params) Sample format not available
for PLAYBACK: Invalid argument
ALSA lib pcm.c:7320:(snd_pcm_set_params) Sample format not available
for CAPTURE: Invalid argument

(above occurs talking to an envy24/ice1712's analog capture or pcm
outs. ... this error doesn't occur talking to the cards's 2-channels
of spdif output, or capturing from the spdif input. For the output
case, the spdif output can be sent to the card's built-in digital
mixer, which can then be routed (via http://mudita24.googlecode.com or
envy24control(1)) to the appropriate analog output for listening on
headphones and works correctly with GoogleVoicePlugin...
unfortunately, w/o a hardware spdif loopback this hack doesn't work
for using the card's microphone input).

(b) Channel count mismatch on Playback with totally standard output
devices, both motherboard and USB:

ALSA lib pcm.c:7326:(snd_pcm_set_params) Channels count (1) not
available for PLAYBACK: Invalid argument

(this seems to happen with some USB stereo soundcards and the
motherboard via snd-hda-intel audio hardware, when connecting to
"front" device.)

Note that these audio issues would probably not occur if I was running
pulseaudio, however, it is a mistake for Google to assume that
everybody in Linuxland uses pulseaudio. (And even if pulseaudio were
running, there'd be similar problems talking to multichannel
soundcards such as the M-audio delta series).

It sure would be nice to use the Terratec Dmx6Fire's handy microphone
input with a sensitivity knob, overload-LED, etc, and built-in digital
mixer, hardware-metering, and full control via
http://mudita24.googlecode.com
working properly, as it's nice being able to have proper microphone
metering, and full mixer control for audio input/output... However,
the current limitations seem to make that difficult.

Perhaps my earlier "wrappering" approach and setting up a separate
ALSA environment for google talk was the right way after all, at least
for such "prosumer" soundcards. That way I could use plughw to match
bit depths on PCM output; I'd have to figure out how to do that on
input.

How exactly could one work around
"ALSA lib pcm.c:7320:(snd_pcm_set_params) Sample format not available
for CAPTURE: Invalid argument"
for capture inputs? Is there anything like plughw that works for capture too?

-- Niels.
http://nielsmayer.com

[Niels Mayer]

Google Voice Chat is now available as RPMs for Fedora >=12 and
OpenSuse (which will still need same lib symlinking as described in my
earlier note)
http://www.google.com/chat/video
............................

http://www.google.com/support/forum/p/chat/thread?fid=10ffe01c3a4779f500048f370d827d69
..................
Video Chat Eng. Blue has posted an answer to the question "Linux
version now available!":

@DaeWon @Mike Cloaked @mattydaw @hipsauerkraut @NielsMayer @ulif
@gbvoris @wsanders @mannmaniyar @coyoteuser @huangjs @fchandur We have
now released official RPM packages of Google voice and video chat. You
can download and install them by visiting
http://www.google.com/chat/video. If you previously installed the DEB
package manually, please be sure to fully remove it before installing
the official RPMs.

We strongly recommend using the official RPMs rather than installing
the DEBs by hand. Using the official RPMs will allow your computer to
automatically resolve dependencies and receive software updates.

These RPMs have been built for Fedora 12 or later, but should work on
any RPM-based distro provided that all dependencies are satisfied.
Unfortunately on OpenSUSE the libssl.so.10 and libcrypto.so.10
symlinks are missing--you may need to create them manually. We are
investigating alternative solutions for a future update.
.............

-- Niels
http://nielsmayer.com

[Niels Mayer]

( http://www.google.com/support/forum/p/chat/thread?tid=10ffe01c3a4779f5&fid=10ffe01c3a4779f500048f64576456f8
)

I finally figured out what is going on with some of the ALSA errors
I've been seeing on an ice1712 soundcard.

http://lists.linuxaudio.org/pipermail/linux-audio-user/2010-September/072341.html
(forwarded below).

Now that I understand how the GoogleTalkPlugin is interacting with
ALSA default devices, I'm beginning to understand some of the issues
people might be having with "caller echo" on multichannel soundcards.

If there's more than a single capture device, it's possible one's
soundcard also has some kind of playback capture which could get mixed
into a separate digital mixer capture stream. The issue is that the
GootleTalkPlugin , when it gets an ALSA playback/capture device that's
not monophonic and there's a channel-count mixmatch, ALSA replicates
the output across all channels of the card, including SPDIF outputs
(channels 9+10). For capture, it does the same thing but captures from
ALL the capture channels simultaneously. On an ice1712, that's 12
channels, including 8 analog ins, 2 for spdif, and 2 for the digital
mixer. Capturing the digital mixer output is annoying (can be worked
around though) in case you want to use the soundcard's digital mixer
to record a conversation -- it'll get captured and sent back to the
caller causing the annoying echo of the callers own voice. Likewise,
if you want to use the digital mixer to listen to some music while
mixing in the phone line while on hold, the caller will end up hearing
what you're listening to on the digital mixer, which is also available
as capure11 and capture12.

Anyways, I've resolved my own issues w/ using a Terratec DMX6Fire as
an audio card for GoogleTalkPlugin. Eventually, I'll have to create a
"shadow definition" of ALSA's defaults for the ice1712 card such that
capture doesn't include the SPDIF input (capture9,10) nor digital
mixer (capture11,12) on the soundcard, so that GoogleTalkPlugin won't
capture their input. Likewise for output, I'll tell it to only send
the audio to the first two channels, so that i can use the other 6
channels of the card for other purposes.

------------
http://lists.linuxaudio.org/pipermail/linux-audio-user/2010-September/072341.html
///////// //////////// /////////////// //////////// //////////

Surely there must be a way to fix the problem with getting pulseaudio to
detect all channels of envy 17xx chipset based audio cards.

For some reason ( http://mudita24.googlecode.com ) I've spent an
inordinate amount of time understanding these sound cards, whose only
downfall is supporting 10 channels of audio output and input as a
single device rather than the screwy "standard" way that exposes two
separate devices, an eight channel analog device, and a separate SPDIF
(and possibly, separate HDMI) that need to be joined into a "multi" if
you want to send analog to the headphones and digital to the
HDMI/SPDIF at the same time...

Pulseaudio's success is ultimately predicated on ALSA's providing
correct interfaces for the following "standard names" or aliases from
/usr/share/alsa/pcm:

default: Default device
front: Front speakers
surround40: 4.0 Surround output to Front and Rear speakers
surround41: 4.1 Surround output to Front, Rear and Subwoofer speakers
surround50: 5.0 Surround output to Front, Center and Rear speakers
surround51: 5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71: 7.1 Surround output to Front, Center, Side, Rear and
Woofer speakers
iec958: IEC958 (S/PDIF) Digital Audio Output

I had a similar problem getting an ice1712 (terratec dmx6fire) working
with google-voice chat. It turned out that my ~/.asoundrc setting for
a default device was overriding the "default" device for all
soundcards, including the very important, special one for envy24's
10-channel-combo-of-analog-and-digital in
/usr/share/alsa/cards/ICE1712.conf . This was causing silly errors
like:

|| ALSA lib pcm_dmix.c:957:(snd_pcm_dmix_open) The dmix plugin
supports only playback stream

because the capture portion of the "default" device hadn't been taken
care of in my long-cobbled-on ~/.asoundrc. Whereas had I used ALSA's
standard "default" device, e.g."TerraTec DMX6Fire, ICE1712 multi -
Default Audio Device" then ALSA would have handled it for me
automatically, e.g. using a "dmix" device for PLAYBACK to allow
nonexclusive access of multiple apps to the same device. Likewise the
"default" CAPTURE uses a "dsnoop" to do similar things for application
audio input.

In summary, the problems with that particular app disappeared when I
got rid of my ~/.asoundrc and used the stock ALSA
(alsa-lib-1.0.23-1.fc12.x86_64) configuration for the "default"
device, both for capture and playback. For example,with the default
device in use, ALSA would automagically replicate the the mono
playback channel across all 10 output channels, instead of giving me
silence and an error message:

|| ALSA lib pcm.c:7326:(snd_pcm_set_params) Channels count (1) not
available for PLAYBACK: Invalid argument

And even if you solve the above, you'll then get a mismatch between
the S16_LE format used by the "generic" app, and the soundcard's
S32_LE, causing the following:

|| ALSA lib pcm.c:7320:(snd_pcm_set_params) Sample format not
available for PLAYBACK: Invalid argument
|| ALSA lib pcm.c:7320:(snd_pcm_set_params) Sample format not
available for CAPTURE: Invalid argument

So make sure that your ALSA is coming up by default, with everything
defined as it should so that
pulseaudio/GoogleTalkPlugin/<consumer-app> can actually talk to it
successfully. That is, /usr/share/alsa/alsa.conf has to load, as does
/usr/share/alsa/cards/ICE1712.conf .

With that all loaded up, as you notice, the "iec958" device of an
ice1712 ends up working with pulseaudio (or any other thing that
expects to talk to this sort of "normalized" ALSA port, abstracted
from your particular soundcard's specifics, such as the use of S32_LE
format). If you use "default" instead for the ice1712, the same magic
will be available for the analog portion.

Here's the default && iec958 definitions of interest from that file
that does all the magic, which is basically an odd place for ALSA to
be putting card-specific configuration information that isn't present
in ALSA, but probably should be, e.g. the channel count, or the card's
specific digital audio format.

First, the "iec958" device that unexpectedly works with pulseaudio or
GoogleTalkPlugin, because it does all the adaptations between software
and hardware "behind the scenes":

<confdir:pcm/iec958.conf>

ICE1712.pcm.iec958.0 {
@args [ CARD AES0 AES1 AES2 AES3 ]
@args.CARD {
type string
}
@args.AES0 {
type integer
}
@args.AES1 {
type integer
}
@args.AES2 {
type integer
}
@args.AES3 {
type integer
}
type asym
playback.pcm {
type hooks
slave.pcm {
type route
ttable.0.8 1
ttable.1.9 1
slave.pcm {
type hw
card $CARD
}
slave.format S32_LE
slave.channels 10
}
hooks.0 {
type ctl_elems
hook_args [
{
interface PCM
name "IEC958 Playback PCM Stream"
lock true
preserve true
value [ $AES0 $AES1 $AES2 $AES3 ]
}
]
}
}
capture.pcm {
type route
ttable.0.8 1
ttable.1.9 1
slave.pcm {
type hw
card $CARD
}
slave.format S32_LE
slave.channels 12
}
}

The same "magic" also gets enabled for "default" on this card if you
don't accidentally override it as I had:

ICE1712.pcm.default {
@args [ CARD ]
@args.CARD {
type string
}
type asym
playback.pcm {
type plug
slave.pcm {
@func concat
strings [ "dmix:" $CARD ",FORMAT=S32_LE" ]
}
}
capture.pcm {
type plug
slave.pcm {
@func concat
strings [ "dsnoop:" $CARD ",FORMAT=S32_LE" ]
}
}
}

Niels
http://nielsmayer.com
///////////////////////////////////////////////////////////////////////
PS: instead of moving the ~/.asoundrc out of the way, one could also startup the
application "my_app" like this:

env ALSA_CONFIG_PATH="/usr/share/alsa/my_alsa.conf" my_app

Where my_alsa.conf is a modification of alsa.conf specific to your
applications's needs, including not loading ~/.asoundrc and using it's
own or a different one.

Of course most needed alsa customizations can be achieved by a simple
~/.asoundrc based on overriding specific defaults setup in
/usr/share/alsa/alsa.conf or /usr/share/alsa/cards/ICE1712.conf ...
e.g. To make my DMX6Fire the "default" ALSA device, e.g. for
google-talk or flash/applet/web-audio, I can just do:

$ cat .asoundrc
defaults.ctl.card 6
defaults.pcm.card 6

This will give you a default device that runs "dmix" on outputs and
"dsnoop" on inputs, allowing nonexlcusive access to audio devices
across multiple apps. E.g. I can listen to web-radio with "mplayer
-quiet http://media.kcrw.com/live/kcrwlive.pls -ao alsa" while
watching a youtube video in the web-browser, all while on-hold using
google-talk as a landline phone.

At which point, other than remote-desktop audio, one might ask, why
bother with pulseaudio in the first place. (I don't).

[Niels Mayer]

FYI if you're running without pulseaudio (so as to avoid the problems
it introduces -- see two messages below as examples), the
GoogleTalkPlugin has an annoying delay every time it tries to access
an audio device, as it's querying for pulseaudio and not finding it
present and timing out. Each time this happens, you'll see a message
"socket(): Address family not supported by protocol"
On the browser's standard output. Worse than the message, when making
an outgoing call, this adds a few seconds of waiting before the call
actually dials and connects.

To solve this problem, start up chrome like this: "google-chrome
--disable-sound"

This doesn't actually disable web audio, or sound from the browser --
it just prevents attempting to use pulseaudio, and not giving timeouts
and errors when it can't be found.

IMHO, a better implementation of GoogleTalkPlugin would use KDE's
Phonon ( http://userbase.kde.org/Phonon ), at least for those using
KDE. Google should offer a KDE version of GoogleTalkPlugin to avoid
the myriad problems we're seeing with the current
gnome/pulseaudio-based implementation. Note that Skype uses Qt and
Phonon, and benefits in reliability and usability due to this choice.
One of the big advantages of Phonon is that it works well independent
of whether pulseaudio is present. It also allows clean integration of
http://jackaudio.org/ and it allows you to dedicate certain kinds of
Audio (e.g. VoIP) to work on a specific card -- such as a USB headset
-- while allowing regular system sounds, music to use other
soundcards.

-- Niels
http://nielsmayer.com

PS: A few pulseaudio related fixes/hacks needed for GoogleTalkPlugin:

http://www.google.com/support/forum/p/chat/thread?tid=10ffe01c3a4779f5&hl=en&fid=10ffe01c3a4779f500048faf0a748e82

//////// //////////// //////////// //////////// ////////////
/////////// //////////
Hi,

A few posts have been about microphones. In particular the auto level
adjust feature that google chat uses. Others, who have had issues with
the internal mic on their laptops/notebooks read on too....

This auto adjust CAN be tuned off.

My symptoms are the same as lintex i.e. for the internal mic to work
the left mic channel must be turned down to zero and the right channel
set to the desired level. Google talk however automatically adjusts
both channels to what it thinks is optimum and thus screws this up.

To see the mix channel settings use PulseAudio Volume control and go
to the input devices tab. PulseAudio Volume control is in the Linux
menus under the sound and video submenu (on Ubuntu anyway). You may
need to install the package pavucontrol to get this gui.

To turn off the auto adjust:

cd ~/.config/google-googletalkplugin # get to google chat's directory
cp -p options options.bak # make a backup before changing stuff !
gedit options # edit the config file

now change one of the lines so that it reads as follows:

audio-flags=1

Now restart you machine and google chat will now longer auto-adjust!!!

Remember to go to PulseAudio volume control just to make sure the left
channel stays at 0

//////// //////////// //////////// //////////// ////////////
/////////// //////////

wd5gnr
9/6/10

I had crackly audio issues -- not bad but annoying. I realized I'd
made some changes to my pulseaudio configuration a long time ago.

If you are comfortable with sudo and a text editor you might try experimenting:

Open /etc/pulse/daemon.conf.. Not sure which of these made the
difference. I was suing src-sinc-best-quality but I think even on my
quad core 3.8Ghz machine it was not doing me any favors. I also
adjusted the number of fragments and the fragment size. You won't find
the comments (lines with ;) in your file because I added them. But you
should find resample-method, default-fragments, and
default-fragment-ize-msec.

Here's the excerpt.

; choices in order from best to worst:
; src-sinc-best-quality, src-sinc-medium-quality, src-sinc-fastest,
speex-float-{10-0}, speex-fixed-{10-0}, ffmpeg, src-zero-order-hold,
src-linear, trivial
; default is speex-float-1
resample-method = src-sinc-fastest

And further down:
; default is 4 and 25
; was suggested to do 8 and 10
default-fragments = 32
default-fragment-size-msec = 25

Now my calls are GREAT quality!!!
--------------------------

//////// //////////// //////////// //////////// ////////////
/////////// //////////

[Niels Mayer]

Post by Niels Mayer
FYI if you're running without pulseaudio (so as to avoid the problems
it introduces -- see two messages below as examples), the
GoogleTalkPlugin has an annoying delay every time it tries to access
an audio device, as it's querying for pulseaudio and not finding it
present and timing out. Each time this happens, you'll see a message
"socket(): Address family not supported by protocol"

Ugh... I thought I had solved this, as I wasn't seeing the messages
when testing my change. But I just had a phone call and saw the
pulseaudio message again, even with my --disable-sound hack. I also
tried giving the command-line arg directly to the google plugin and
it won't accept this gnome argument (even though the browser does). SO
I'm not sure what I was seeing the first time, and sorry for reporting
on false success.

Is there an environment variable that does the same thing as
--disable-sound so that pulseaudio never gets called within a Gnome
app? Some KDE apps like 'kmix' have a special envvar for this:
KMIX_PULSEAUDIO_DISABLE=1

Any equivalent envvar in the underlying gnome libraries to disable
pulse and go straight to ALSA?

Niels
http://nielsmayer.com

[Paul Davis]

Post by Niels Mayer
Any equivalent envvar in the underlying gnome libraries to disable
pulse and go straight to ALSA?

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.

[Niels Mayer]

Post by Paul Davis
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

[Paul Davis]

Post by Niels Mayer
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.

gnome (not gtk) apps use the following gconf settings for sound output

system/gstreamer/0.10/audio/default/audiosink
system/gstreamer/0.10/audio/default/chataudiosink
system/gstreamer/0.10/audio/default/musicaudiosink

my machines have the first and last of these set to: jackaudiosink
buffer-time=2000000

and as a result all my gnome apps (and firefox too) route audio via
jack. there are other options too.

[Niels Mayer]

Post by Paul Davis
gnome (not gtk) apps use the following gconf settings for sound output
system/gstreamer/0.10/audio/default/audiosink
system/gstreamer/0.10/audio/default/chataudiosink
system/gstreamer/0.10/audio/default/musicaudiosink

I've long had these setup to skip pulseaudio, using alsasink with a
specific device (see
http://ccrma-mail.stanford.edu/pipermail/planetccrma/2010-March/016510.html
) :

<entry name="chataudiosink" mtime="1265693808" type="string">
<stringvalue>alsasink
device=&quot;hw:Headset,0&quot;</stringvalue>
</entry>
<entry name="musicaudiosink" mtime="1265693856" type="string">
<stringvalue>alsasink device=&quot;hw:SB,1&quot;</stringvalue>
</entry>
<entry name="audiosrc" mtime="1282881667" type="string">
<stringvalue>alsasrc
device=&quot;hw:BCD3000,0&quot;</stringvalue>
</entry>
<entry name="audiosink" mtime="1282881208" type="string">
<stringvalue>alsasink device=&quot;default&quot;</stringvalue>
</entry>

Unfortunately, despite these and other measures in place, I still
continue seeing signs of attempting to contact pulseaudio first in
gnome/gstreamer apps: "socket(): Address family not supported by
protocol" ( e.g.
http://www.spinics.net/lists/fedora-music/msg00607.html )

The only way I've disabled this consistently is with apps that accept the gnome
"--disable-sound" flag. Unfortunately, some apps, libs, plugins, etc.
don't use standard gnome command line processing and do not set this
capability. Which is why I wonder if there's yet another way, such as
environment variable, or some special extra magic setting I can add to
/home/npm/.gconf/system/gstreamer/0.10/default/%gconf.xml ?

Niels
http://nielsmayer.com

[Paul Davis]

Post by Niels Mayer

Post by Paul Davis
gnome (not gtk) apps use the following gconf settings for sound output
system/gstreamer/0.10/audio/default/audiosink
system/gstreamer/0.10/audio/default/chataudiosink
system/gstreamer/0.10/audio/default/musicaudiosink

I've long had these setup to skip pulseaudio, using alsasink with a
specific device (see
http://ccrma-mail.stanford.edu/pipermail/planetccrma/2010-March/016510.html
         <entry name="chataudiosink" mtime="1265693808" type="string">
               <stringvalue>alsasink
device=&quot;hw:Headset,0&quot;</stringvalue>
       </entry>
       <entry name="musicaudiosink" mtime="1265693856" type="string">
               <stringvalue>alsasink device=&quot;hw:SB,1&quot;</stringvalue>
       </entry>
       <entry name="audiosrc" mtime="1282881667" type="string">
               <stringvalue>alsasrc
device=&quot;hw:BCD3000,0&quot;</stringvalue>
       </entry>
       <entry name="audiosink" mtime="1282881208" type="string">
               <stringvalue>alsasink device=&quot;default&quot;</stringvalue>
       </entry>
Unfortunately, despite these and other measures in place, I still
continue seeing signs of attempting to contact pulseaudio first in
gnome/gstreamer apps: "socket(): Address family not supported by
protocol" ( e.g.
http://www.spinics.net/lists/fedora-music/msg00607.html )

sure, and its reasonably easy to at least guess why: what is the
"default" ALSA device on the affected system? what does aplay -D
default do?

i should stress that i *have* pulseaudio installed, and the few gnome
apps that i have on my system (fedora) do not attempt to use it.

[Philipp Überbacher]

Post by Paul Davis

Post by Niels Mayer
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.

gnome (not gtk) apps use the following gconf settings for sound output
system/gstreamer/0.10/audio/default/audiosink
system/gstreamer/0.10/audio/default/chataudiosink
system/gstreamer/0.10/audio/default/musicaudiosink
my machines have the first and last of these set to: jackaudiosink
buffer-time=2000000
and as a result all my gnome apps (and firefox too) route audio via
jack. there are other options too.

What I wonder about since a long time is how to set this kind of stuff
without gnome/gconf.

[Niels Mayer]

Post by Paul Davis
sure, and its reasonably easy to at least guess why: what is the
"default" ALSA device on the affected system? what does aplay -D
default do?
i should stress that i *have* pulseaudio installed, and the few gnome
apps that i have on my system (fedora) do not attempt to use it.

Then how about if you try killing your pulseaudio (that your devices
are not attempting to use so it shouldn't matter, right?) and see
whether the same thing happens. Unless I've woefully misconfigured my
system (some would say my uninstalling pulseaudio is a
misconfiguration), I imagine you might be able to get the same
"socket(): Address family not supported by protocol" error that got me
to switch to KDE....

For example, here's a standard gnome program (that I use regularly,
since ksnapshot generates garbage) that really shouldn't be
contacting pulseaudio, but it does, every single time it writes out a

Post by Paul Davis
gnulem-242-~> gnome-screenshot -i
socket(): Address family not supported by protocol

(One might think it was an audio prompt to select a window, but the
message is emitted after the snapshot is taken, and seems to cause a
short timeout delay in the program before the captured screenshot is
rendered. Note that my gnome preferences are set to "no desktop
sounds" and yet this unnecessary check to see if pulseaudio is running
is done anyways.).

W/r/t the query, what does "aplay -Ddefault" do:

gnulem-243-~> aplay -Ddefault 14854__reinsamba__Nightingale_song.wav
Playing WAVE '14854__reinsamba__Nightingale_song.wav' : Signed 16 bit
Little Endian, Rate 48000 Hz, Stereo
[ ... sound of bird chirping played ...]
^CAborted by signal Interrupt...

To emulate the environment where I'm seeing the problem, we need to
use a different configuration entirely (long story).. however that
does the exact same thing, play back a sound, immediately and without
any pulseaudio messages (which is not what I see out of most programs
that have this behavior).

gnulem-244-~> env ALSA_CONFIG_PATH=/usr/share/alsa/alsa-bsoundrc.conf
aplay -Ddefault 14854__reinsamba__Nightingale_song.wav
Playing WAVE '14854__reinsamba__Nightingale_song.wav' : Signed 16 bit
Little Endian, Rate 48000 Hz, Stereo
[ ... sound of bird chirping played ...]
^CAborted by signal Interrupt...

/////////////////////////////

On Wed, Sep 8, 2010 at 11:46 AM, Philipp Überbacher

Post by Paul Davis
What I wonder about since a long time is how to set this kind of stuff
without gnome/gconf.

Use a text editor on ~/.gconf/system/gstreamer/0.10/default/%gconf.xml
and be sure to use &-escapes, e.g. "alsasink
device=&quot;hw:Headset,0&quot;"

Or do
gconftool-2 --type string --set
/system/gstreamer/0.10/default/audiosink "alsasink"
gconftool-2 --type string --set
/system/gstreamer/0.10/default/musicaudiosink "alsasink"
gconftool-2 --type string --set
/system/gstreamer/0.10/default/chataudiosink "alsasink"

-- Niels
http://nielsmayer.com

[Ng Oon-Ee]

Post by Niels Mayer
(One might think it was an audio prompt to select a window, but the
message is emitted after the snapshot is taken, and seems to cause a
short timeout delay in the program before the captured screenshot is
rendered. Note that my gnome preferences are set to "no desktop
sounds" and yet this unnecessary check to see if pulseaudio is running
is done anyways.).

You mean when the 'camera-click' sound is supposed to play =)

[Philipp Überbacher]

Post by Niels Mayer
On Wed, Sep 8, 2010 at 11:46 AM, Philipp Überbacher

Post by Philipp Überbacher
What I wonder about since a long time is how to set this kind of stuff
without gnome/gconf.

Use a text editor on ~/.gconf/system/gstreamer/0.10/default/%gconf.xml
and be sure to use &-escapes, e.g. "alsasink
device=&quot;hw:Headset,0&quot;"
Or do
gconftool-2 --type string --set
/system/gstreamer/0.10/default/audiosink "alsasink"
gconftool-2 --type string --set
/system/gstreamer/0.10/default/musicaudiosink "alsasink"
gconftool-2 --type string --set
/system/gstreamer/0.10/default/chataudiosink "alsasink"

The question was how to configure gstreamer without gconf. Without gconf
installed there's no ~/.gconf and no gconftool. I'm under the impression
that gstreamer is impossible to configure without gconf. gstreamer is
afaik supposed to support jack as audio output, but no gstreamer
depending application I ever encountered provided a way to set its audio
output to jack, or change any other audio option for that matter.

[Niels Mayer]

On Thu, Sep 9, 2010 at 2:23 AM, Philipp Überbacher

Post by Philipp Überbacher
The question was how to configure gstreamer without gconf. Without gconf
installed there's no ~/.gconf and no gconftool. I'm under the impression
that gstreamer is impossible to configure without gconf. gstreamer is
afaik supposed to support jack as audio output, but no gstreamer
depending application I ever encountered provided a way to set its audio
output to jack, or change any other audio option for that matter.

Sorry for misunderstanding what you were looking for. I answered the
easy part of the question :-) . I'm not sure how it would be done w/o
gconf because you'd need a mechanism to specify which alsa source or
sink you'll be using.

To get this capability, you need to install the appropriate alsa
plugin for jack: alsa-plugins-jack; then use jackaudiosink instead of
alsasink, pulsesink, etc in your gstreamer config. See
http://ubuntuforums.org/showthread.php?t=554457
for details ("How to: Use Jack for GStreamer output (so you can EQ
banshee/rhythmbox w/Jack-Rack!)")

ANd here's the plugin you need to make it all work:

Name : alsa-plugins-jack
Summary : Jack PCM output plugin for ALSA
URL : http://www.alsa-project.org/
License : LGPLv2+
Description : This plugin converts the ALSA API over JACK (Jack Audio Connection
: Kit, http://jackit.sf.net) API. ALSA native applications can work
: transparently together with jackd for both playback and capture.
: This plugin provides the PCM type "jack"

-- Niels.
http://nielsmayer.com

[Paul Davis]

Post by Niels Mayer
Sorry for misunderstanding what you were looking for. I answered the
easy part of the question :-) . I'm not sure how it would be done w/o
gconf because you'd need a mechanism to specify which alsa source or
sink you'll be using.

its called gstreamer-properties(1)

Post by Niels Mayer
To get this capability, you need to install the appropriate alsa
plugin for jack: alsa-plugins-jack; then use jackaudiosink instead of
alsasink, pulsesink, etc in your gstreamer config.

the ALSA plugin for JACK has nothing to do with this. the
jackaudiosink plugin for gstreamer talks directly to JACK.

[Niels Mayer]

Post by Paul Davis
its called gstreamer-properties(1)

Yes, you can use gstreamer-properties (which incidentally has no
section 1 man-page :-) ) for some but not all of the needed
configurations, such as chataudiosink which is why i suggested the
command-line form earlier:

gconftool-2 --type string --set
/system/gstreamer/0.10/default/audiosink "alsasink"

Post by Paul Davis

Post by Niels Mayer
To get this capability, you need to install the appropriate alsa
plugin for jack: alsa-plugins-jack; then use jackaudiosink instead of
alsasink, pulsesink, etc in your gstreamer config.

the ALSA plugin for JACK has nothing to do with this. the
jackaudiosink plugin for gstreamer talks directly to JACK.

Um... in my defense, they totally screwed up my son's schedule at
school, so i woke up at 5:30AM so he could be at his "period 0"
class.... I obviously shouldn't be posting before 8AM, or at least
have a few more cups of coffee prior.

So I posted about http://ubuntuforums.org/showthread.php?t=554457
which suggests installing gstreamer0.10-plugins-bad and then I somehow
skipped to using jack through ALSA. (???).

Perhaps behind the brainfart is this confusion/mess: Why are there so
many different mechanisms for talking to jack/pulseaudio, and so much
duplication. There's
(1) a separate way of talking to jack/pulseaudio as a PCM device
from ALSA. Why would you want to do it a different way, or at a
different level than a "virtual alsa device", which you could then
specify as an alsaaudiosource/sink in gstreamer??

(2) There's the
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad-plugins/html/gst-plugins-bad-plugins-jackaudiosink.html
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad-plugins/html/gst-plugins-bad-plugins-jackaudiosrc.html
-- why are these "bad plugins?" and if they are, why would I want to
use them? What's the advantage of talking to jackd this way, versus #1
above.

(3) Just to make things more confusing, there's also Pulseaudio jack
plugin: http://tuxaudio.blogspot.com/2010/04/mint8-pulseaudio-and-jack.html
????

(4) My preferred method: phonon's priority list of devices and it's
non-lockup-if-device-busy behavior, and the ability to make jack, or
pulseaudio be one of those "devices" in the list, on a per activity.

Too bad's google's implementation is closed so we can't see what exact
code they're using, but from what i'm seeing, they've somehow managed
to get the worst-of-all-worlds behavior, by making a gnome app that
doesn't know about gstreamer and talks to ALSA and pulseaudio
directly. It doesn't pay attenption to settings like "chataudiosink",
unlike ekiga. (Incidentally, ekiga, doesn't get the "socket(): Address
family not supported by protocol" error on each connection. ") That's
why I infer that googletalkplugin doesn't use gstreamer, though it
should.

So if you wanted to use googletalkplugin with jack, you'd have to use
ALSA or pulseaudio with the pulseaudio jack plugin. Which might be why
I confabulated alsa-plugins-jack into my answer...

-- Niels
http://nielsmayer.com

[Niels Mayer]

Duh.... even better than wrappering the GoogleTalkPlugin for using a
different device, you can just go to
http://mail.google.com/mail/#settings/chat
and look for "Voice and video chat:" settings.

It'll say "Detecting devices..." for a while, especially if you're not
using pulseaudio, in which case it will time out
multiple times outputting 9 lines of
socket(): Address family not supported by protocol
socket(): Address family not supported by protocol
....

But if you wait long enough, eventually you're given the same listing
as "aplay -L" so you can choose the equivalent of
"front:CARD=Headset,DEV=0" for both microphone and speakers (or even a
different device for microphone if you've got a webcam with a built in
usb mic). It's silly to use the "aplay -L" listing as you're given
additional choices that make no sense for voice chatting:
surround40:CARD=Headset,DEV=0 ; surround41:CARD=Headset,DEV=0 ;
surround50:CARD=Headset,DEV=0 ; surround51:CARD=Headset,DEV=0 ;
surround71:CARD=Headset,DEV=0 ; iec958:CARD=Headset,DEV=0 ...

As final confusion, http://mail.google.com/mail/#settings/chat also
lists "aplay -L" outputs for the microphone, so you end up seeing
nonsense like "7.1 Surround output to Front, Center, Side, Rear and
Woofer speakers" as a potential choice of microphone source.

Fortunately it works with both "speaker" and microphone" set to the
"front" source of the desired card.

I never realized the gmail Settings->Chat options would do anything
useful beyond saying ""Detecting devices..." forever, as I never
thought of waiting till pulseaudio timed out 9 times before checking
the web page... Thus the previous attempt at wrappering
GoogleTalkPlugin ... at least it taught me their plugin is setting
some interesting environment variables:
LD_LIBRARY_PATH=/opt/google/chrome:/opt/google/chrome/lib:
GNOME_DISABLE_CRASH_DIALOG=SET_BY_GOOGLE_CHROME
SANDBOX_LD_LIBRARY_PATH=/opt/google/chrome:/opt/google/chrome/lib:
CHROME_WRAPPER=/opt/google/chrome/google-chrome
CHROME_VERSION_EXTRA=beta

Niels
http://nielsmayer.com

PS: For those getting reports of echo on the caller end, there is a
Settings->Chat option for echo-cancellation that appeared to be set by
default. There's also a "send call quality info back to google" button
that is also selected by default -- those worried about these kinds of
things may want to change this option.