[Mplayer-cvslog] CVS: main/DOCS/tech hwac3.txt,NONE,1.1

[David Holm]

Steven Brookes told me he is working on DTS support for mplayer as well 
(by using -ac hwdts). He's been really helpful in fixing all digital 
audio stuff in the dxr3 driver, I'm glad he's set his mind to fix things 
in the mplayer world as well.

//David

Arpi of Ize wrote:

>Update of /cvsroot/mplayer/main/DOCS/tech
>In directory mplayer:/var/tmp.root/cvs-serv5946
>
>Added Files:
>	hwac3.txt 
>Log Message:
>3 mails describing hwac3 tech details
>
>--- NEW FILE ---
>mails by A'rpi and Marcus Blomenkamp <Marcus.Blomenkamp at epost.de>
>describing how this ac3-passtrough hack work under linux and mplayer...
>-----------------------------------------------------------------------
>Hi,
>
>>I received the following patch from Steven Brookes <stevenjb at mda.co.uk>.
>>He is working on fixing the digital audio output of the dxr3 driver and
>>told me he fixed some bugs in mplayer along the way. I don't know shit
>>about hwac3 output so all I did was to make sure the patch applied
>>against latest cvs.
>>This is from his e-mail to me:
>>
>>"Secondly there is a patch to dec_audio.c and
>>ac3-iec958 to fix the -ac hwac3 codec stuff and to use liba52 to sync it.
>>
>
>>Seems to work for everything I've thrown at and maintains sync for all audio
>>types through the DXR3."
>>
>
>patch applied (with some comments added and an unwanted change (in software
>a52 decoder) removed)
>
>now i understand how this whole hwac3 mess work.
>it's very very tricky. it virtually decodes ac3 to LPCM packets, but really
>it keeps the original compressed data padded by zeros. this way it's
>constant bitrate, and sync is calculated just like for stereo PCM.
>(so it bypass LPCM-capable media converters...)
>
>so, every ac3 frame is translated to 6144 byte long tricky LPCM packet.
>6144 = 4*(6*256) = 4 * samples_per_ac3_frame = LPCM size of uncompressed ac3
>frame.
>
>i wanna know if it works for sblive and other ac3-capable cards too?
>(i can't test it, lack of ac3 decoder)
>
>A'rpi / Astral & ESP-team
>
>-----------------------------------------------------------------------
>Hi folks.
>I spend some time fiddling with ac3 passthrough in mplayer. The
>traditional way of setting the output format to AFMT_AC3 was no ideal
>solution since not all digital io cards/drivers supported this format or
>honoured it to set the spdif non-audio bit. To make it short, it only
>worked with oss sblive driver IIRC.
>
>Inspired by alsa's ac3dec program I found an alternative way by
>inspecting to which format the alsa device had been set. Suprise: it was
>simple 16bit_le 2_channel pcm. So setting the non-audio bit doesn't
>necessarily mean the point. The only important thing seems to be
>bit-identical output at the correct samplerate. Modern AV-Receivers seem
>to be quite tolerant/compatible.
>
>So I changed the output format of hwac3 from
>
>AFMT_AC3 channels=1
>   to
>AFMT_S16_LE channels=2
>
>and corrected the absolute time calculation. That was all to get it
>running for me.
>
>-----------------------------------------------------------------------
>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
>
>_______________________________________________
>Mplayer-cvslog mailing list
>Mplayer-cvslog at mplayerhq.hu
>http://mplayerhq.hu/mailman/listinfo/mplayer-cvslog
>