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

Niels Mayer nielsmayer at gmail.com
Sat Sep 4 00:51:32 UTC 2010


( 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).


More information about the Linux-audio-user mailing list