( 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). ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
