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

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

( http://www.google.com/support/forum/p/chat/thread?tid=10ffe01c3a4779f5&… ) 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/07234… (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/07234… ///////// //////////// /////////////// //////////// ////////// 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).

On Tue, Sep 7, 2010 at 10:57 AM, Niels Mayer &lt;nielsmayer(a)gmail.com&gt; wrote: 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

On Wed, Sep 8, 2010 at 7:31 AM, Paul Davis &lt;paul(a)linuxaudiosystems.com&gt; wrote: 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

On Wed, Sep 8, 2010 at 9:57 AM, Paul Davis &lt;paul(a)linuxaudiosystems.com&gt; wrote: 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

Excerpts from Paul Davis's message of 2010-09-08 18:57:38 +0200: What I wonder about since a long time is how to set this kind of stuff without gnome/gconf. -- Philipp -- "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan

On Wed, 2010-09-08 at 17:00 -0700, Niels Mayer wrote: You mean when the 'camera-click' sound is supposed to play =)

On Thu, Sep 9, 2010 at 2:23 AM, Philipp Überbacher &lt;hollunder(a)lavabit.com&gt; wrote: 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

On Thu, Sep 9, 2010 at 12:46 PM, Paul Davis &lt;paul(a)linuxaudiosystems.com&gt; wrote: 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" 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-pl… http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad-pl… -- 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