diff options
Diffstat (limited to 'DOCS/tech/hwac3.txt')
| -rw-r--r-- | DOCS/tech/hwac3.txt | 98 |
1 files changed, 49 insertions, 49 deletions
diff --git a/DOCS/tech/hwac3.txt b/DOCS/tech/hwac3.txt index b3a7e9a757..9ae5a4f136 100644 --- a/DOCS/tech/hwac3.txt +++ b/DOCS/tech/hwac3.txt @@ -61,83 +61,83 @@ running for me. ----------------------------------------------------------------------- Hi there. -Perhaps I can clear up some mystification about AC3 passthrough in +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 +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 +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 +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 +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 +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 +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 +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 +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 +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 -dependent script (e.g. Mandrake-8.1 has an 'alsa' script which depends +This works flawlessly in combination with alsa's native +SysVrc-init-script 'alsasound'. Be sure to disable any distribution +dependent 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. |