Hi there. Perhaps I can clear up some mystification about AC3 passthrough in general and mplayer in special: To get the external decoder solution working, it must be fed with data which is bitidentical to the chunks in the source ac3 file (compressed data is very picky about bit errors). Additionally - or better to say 'historically' - the non-audio bit should be set in the spdif status fields to prevent old spdif hardware from reproducing ugly scratchy noise. Note: for current decoders (probably those with DTS capability) this safety bit isn't needed anymore. At least I can state that for my Sherwood RVD-6095RDS. I think it is due to DTS because DTS sound can reside on a ordinary AudioCD and an ordinary AudioCD-Player will always have it's audio-bit set. The sample format of the data must be 2channel 16bit (little endian IIRC). Samplerates are 48kHz - although my receiver also accepts 44100Hz. I do not know if this is due to an over-compatability of my receiver or if 44100 is also possible in the ac3 specs. For safety's sake lets keep this at 48000Hz. AC3 data chunks are inserted into the stream every 0x1600 bytes (don't bite me on that, look into 'ac3-iec958.c': 'ac3_iec958_build_burst'). To come back to the problem: data must be played bit-identically through the soundcard at the correct samplerate and should optionally have it's non-audio bit set. There are two ways to accomplish this: 1) Some OSS guy invented the format AFMT_AC3. Soundcard drivers implementing this format should therefore adjust it's mixers and switches to produce the desired output. Unfortunately some soundcard drivers do not support this format correctly and most do not even support it at all (including ALSA). 2) The alternative approach currently in mplayer CVS is to simply set the output format to 48kHz16bitLE and rely on the user to have the soundcard mixers adjusted properly. I do have two soundcards with digital IO facilities (CMI8738 and Trident4DWaveNX based) plus the mentioned decoder. I'm currently running Linux-2.4.17. Following configurations are happily running here: 1. Trident with ALSA drivers (OSS does not support Hoontech's dig. IO) 2. CMI with ALSA drivers 3. CMI with OSS drivers For Linux I'd suggest using ALSA because of it's cleaner architecture and more consitent user interface. Not to mention that it'll be the standard sound support in Linux soon. For those who want to stick to OSS drivers: The CMI8738 drivers works out-of-the-box, if the PCM/Wave mixer is set to 100%. For ALSA I'd suggest using its OSS emulation. More on that later. ALSA-0.9 invented the idea of cards, devices and dubdevices. You can reach the digital interface of all supported cards consitently by using the device 'hw:x,2' (x counting from 0 is the number of your soundcard). So most people would end up at 'hw:0,2'. This device can only be opened in sample formats and rates which are directly supported in hardware hence no samplerate conversion is done keeping the stream as-is. However most consumer soundcards do not support 44kHz so it would definitively be a bad idea to use this as your standard device if you wanted to listen to some mp3s (most of them are 44kHz due to CD source). Here the OSS comes to play again. You can configure which OSS device (/dev/dsp and /dev/adsp) uses which ALSA device. So I'd suggest pointing the standard '/dev/dsp' to standard 'hw:0,0' which suports mixing and samplerate conversion. No further reconfiguration would be needed for your sound apps. For movies I'd point '/dev/adsp' to 'hw:0,2' and configure mplayer to use adsp instead of dsp. The samplerate constrain is no big deal here since movies usually are in 48Khz anyway. The configuration in '/etc/modules.conf' is no big deal also: alias snd-card-0 snd-card-cmipci # insert your card here alias snd-card-1 snd-pcm-oss # load OSS emulation options snd-pcm-oss snd_dsp_map=0 snd_adsp_map=2 # do the mapping This works flawlessly in combination with alsa's native SysVrc-init-script 'alsasound'. Be sure to disable any distribution dependant script (e.g. Mandrake-8.1 has an 'alsa' script which depends on ALSA-0.5). Sorry for you *BSD'lers out there. I have no grasp on sound support there. HTH Marcus