mirror of https://github.com/mpv-player/mpv
3 mails describing hwac3 tech details
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@4779 b3059339-0415-0410-9bf9-f77b7e298cf2
This commit is contained in:
arpi
parent
8a3effafda
commit
44e1c06eb7
|
|
@ -0,0 +1,145 @@
|
|||
mails by A'rpi and Marcus Blomenkamp <Marcus.Blomenkamp@epost.de>
|
||||
describing how this ac3-passtrough hack work under linux and mplayer...
|
||||
-----------------------------------------------------------------------
|
||||
Hi,
|
||||
|
||||
> I received the following patch from Steven Brookes <stevenjb@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
|
||||
Loading…
Reference in New Issue