Mercurial > mplayer.hg
annotate DOCS/tech/hwac3.txt @ 26883:a365271c97a5
Revert commit r26897.
XviD is the correct spelling of the codec.
You can see it written in the codec own
documentation and header files.
Prefered name capitalization confirmed
in conversation with XviD developer (prunedtree).
author | iive |
---|---|
date | Wed, 28 May 2008 23:04:41 +0000 |
parents | f3d7a1b58a82 |
children | 0f1b5b68af32 |
rev | line source |
---|---|
4778 | 1 mails by A'rpi and Marcus Blomenkamp <Marcus.Blomenkamp@epost.de> |
2 describing how this ac3-passtrough hack work under linux and mplayer... | |
3 ----------------------------------------------------------------------- | |
4 Hi, | |
5 | |
6 > I received the following patch from Steven Brookes <stevenjb@mda.co.uk>. | |
7 > He is working on fixing the digital audio output of the dxr3 driver and | |
8 > told me he fixed some bugs in mplayer along the way. I don't know shit | |
9 > about hwac3 output so all I did was to make sure the patch applied | |
10 > against latest cvs. | |
11 > This is from his e-mail to me: | |
12 > | |
13 > "Secondly there is a patch to dec_audio.c and | |
14 > ac3-iec958 to fix the -ac hwac3 codec stuff and to use liba52 to sync it. | |
15 | |
16 > Seems to work for everything I've thrown at and maintains sync for all audio | |
17 > types through the DXR3." | |
18 | |
19 patch applied (with some comments added and an unwanted change (in software | |
20 a52 decoder) removed) | |
21 | |
22 now i understand how this whole hwac3 mess work. | |
23 it's very very tricky. it virtually decodes ac3 to LPCM packets, but really | |
24 it keeps the original compressed data padded by zeros. this way it's | |
25 constant bitrate, and sync is calculated just like for stereo PCM. | |
26 (so it bypass LPCM-capable media converters...) | |
27 | |
28 so, every ac3 frame is translated to 6144 byte long tricky LPCM packet. | |
29 6144 = 4*(6*256) = 4 * samples_per_ac3_frame = LPCM size of uncompressed ac3 | |
30 frame. | |
31 | |
32 i wanna know if it works for sblive and other ac3-capable cards too? | |
33 (i can't test it, lack of ac3 decoder) | |
34 | |
35 A'rpi / Astral & ESP-team | |
36 | |
37 ----------------------------------------------------------------------- | |
38 Hi folks. | |
39 I spend some time fiddling with ac3 passthrough in mplayer. The | |
40 traditional way of setting the output format to AFMT_AC3 was no ideal | |
41 solution since not all digital io cards/drivers supported this format or | |
42 honoured it to set the spdif non-audio bit. To make it short, it only | |
43 worked with oss sblive driver IIRC. | |
44 | |
45 Inspired by alsa's ac3dec program I found an alternative way by | |
46 inspecting to which format the alsa device had been set. Suprise: it was | |
47 simple 16bit_le 2_channel pcm. So setting the non-audio bit doesn't | |
48 necessarily mean the point. The only important thing seems to be | |
49 bit-identical output at the correct samplerate. Modern AV-Receivers seem | |
50 to be quite tolerant/compatible. | |
51 | |
52 So I changed the output format of hwac3 from | |
53 | |
54 AFMT_AC3 channels=1 | |
55 to | |
56 AFMT_S16_LE channels=2 | |
57 | |
58 and corrected the absolute time calculation. That was all to get it | |
59 running for me. | |
60 | |
61 ----------------------------------------------------------------------- | |
62 Hi there. | |
63 | |
64 Perhaps I can clear up some mystification about AC3 passthrough in | |
65 general and mplayer in special: | |
66 | |
67 To get the external decoder solution working, it must be fed with data | |
68 which is bitidentical to the chunks in the source ac3 file (compressed | |
69 data is very picky about bit errors). Additionally - or better to say | |
70 'historically' - the non-audio bit should be set in the spdif status | |
71 fields to prevent old spdif hardware from reproducing ugly scratchy | |
72 noise. Note: for current decoders (probably those with DTS capability) | |
73 this safety bit isn't needed anymore. At least I can state that for my | |
74 Sherwood RVD-6095RDS. I think it is due to DTS because DTS sound can | |
75 reside on a ordinary AudioCD and an ordinary AudioCD-Player will always | |
76 have it's audio-bit set. | |
77 | |
78 The sample format of the data must be 2channel 16bit (little endian | |
79 IIRC). Samplerates are 48kHz - although my receiver also accepts | |
80 44100Hz. I do not know if this is due to an over-compatability of my | |
81 receiver or if 44100 is also possible in the ac3 specs. For safety's | |
82 sake lets keep this at 48000Hz. AC3 data chunks are inserted into the | |
83 stream every 0x1600 bytes (don't bite me on that, look into | |
84 'ac3-iec958.c': 'ac3_iec958_build_burst'). | |
85 | |
86 To come back to the problem: data must be played bit-identically through | |
87 the soundcard at the correct samplerate and should optionally have it's | |
88 non-audio bit set. There are two ways to accomplish this: | |
89 | |
90 1) Some OSS guy invented the format AFMT_AC3. Soundcard drivers | |
91 implementing this format should therefore adjust it's mixers and | |
92 switches to produce the desired output. Unfortunately some soundcard | |
93 drivers do not support this format correctly and most do not even | |
94 support it at all (including ALSA). | |
95 | |
96 2) The alternative approach currently in mplayer CVS is to simply set | |
97 the output format to 48kHz16bitLE and rely on the user to have the | |
98 soundcard mixers adjusted properly. | |
99 | |
100 I do have two soundcards with digital IO facilities (CMI8738 and | |
101 Trident4DWaveNX based) plus the mentioned decoder. I'm currently running | |
102 Linux-2.4.17. Following configurations are happily running here: | |
103 | |
104 1. Trident with ALSA drivers (OSS does not support Hoontech's dig. IO) | |
105 2. CMI with ALSA drivers | |
106 3. CMI with OSS drivers | |
107 | |
108 For Linux I'd suggest using ALSA because of it's cleaner architecture | |
109 and more consitent user interface. Not to mention that it'll be the | |
110 standard sound support in Linux soon. | |
111 | |
112 For those who want to stick to OSS drivers: The CMI8738 drivers works | |
113 out-of-the-box, if the PCM/Wave mixer is set to 100%. | |
114 | |
115 For ALSA I'd suggest using its OSS emulation. More on that later. | |
116 ALSA-0.9 invented the idea of cards, devices and dubdevices. You can | |
117 reach the digital interface of all supported cards consitently by using | |
118 the device 'hw:x,2' (x counting from 0 is the number of your soundcard). | |
119 So most people would end up at 'hw:0,2'. This device can only be opened | |
120 in sample formats and rates which are directly supported in hardware | |
121 hence no samplerate conversion is done keeping the stream as-is. However | |
122 most consumer soundcards do not support 44kHz so it would definitively | |
123 be a bad idea to use this as your standard device if you wanted to | |
124 listen to some mp3s (most of them are 44kHz due to CD source). Here the | |
125 OSS comes to play again. You can configure which OSS device (/dev/dsp | |
126 and /dev/adsp) uses which ALSA device. So I'd suggest pointing the | |
127 standard '/dev/dsp' to standard 'hw:0,0' which suports mixing and | |
128 samplerate conversion. No further reconfiguration would be needed for | |
129 your sound apps. For movies I'd point '/dev/adsp' to 'hw:0,2' and | |
130 configure mplayer to use adsp instead of dsp. The samplerate constrain | |
131 is no big deal here since movies usually are in 48Khz anyway. The | |
132 configuration in '/etc/modules.conf' is no big deal also: | |
133 | |
134 alias snd-card-0 snd-card-cmipci # insert your card here | |
135 alias snd-card-1 snd-pcm-oss # load OSS emulation | |
136 options snd-pcm-oss snd_dsp_map=0 snd_adsp_map=2 # do the mapping | |
137 | |
138 This works flawlessly in combination with alsa's native | |
139 SysVrc-init-script 'alsasound'. Be sure to disable any distribution | |
22316
f3d7a1b58a82
cosmetics: Fix some common typos, appropiate --> appropRiate,
diego
parents:
4778
diff
changeset
|
140 dependent script (e.g. Mandrake-8.1 has an 'alsa' script which depends |
4778 | 141 on ALSA-0.5). |
142 | |
143 Sorry for you *BSD'lers out there. I have no grasp on sound support there. | |
144 | |
145 HTH Marcus |