Re: [LAU] envy 1712 - infamous but obscure

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