I have Perian 1.2.3 installed on an intel mac.
I have my digital out hooked up to an AC-3 capable receiver.
When I select that output in DVD Player and play a DVD, I see in Audio
MIDI Setup that the output is changed to 48000 Hz, Encoded Digital
Audio and I get nice surround effects from the receiver.
From this website:
http://sverigesradio.se/sida/default.aspx?programID=2445
near the bottom in the "Surroundtest" section, I have downloaded the
"DD (8 Mb)" file from this url:
http://sverigesradio.se/laddahem/multikanal/dd/
surroundtest_dd_640.zip
After unzipping you get a "SURROUNDTEST_DD_640.wav" file which is
44100 Hz stereo 16-bit little endian encoded 'cac3' format data.
Using "Audio MIDI Setup" to configure my digital output to 44100 Hz,
16-bit 2ch and then playing this file in QuickTime Player at full
volume, I hear a german voice that tests each of the different
speakers including the surround ones (any other settings produce
static). So I know that pass through works, but Perian/a52codec is
not involved in any way in the playback of this file.
From this website:
http://www.lynnemusic.com/surround.html
near the top in the "5.1 Surround Test File" section, I have
downloaded the "AC3 (Dolby Digital), click here" file from this url:
http://www.lynnepublishing.com/surround/www_lynnemusic_com_surround_test.ac3
With the default setting of attemptPassthrough disabled and Perian
Audio Output set to "Dolby Pro Logic II", the file opens in QuickTime
Player and plays and the locations the english voice describes matches
the speaker location.
This is a 48000 Hz file. When I enable attemptPassthrough and use
"Audio MIDI Setup" to configure my digital output to 48000 Hz, 16-bit
2ch and then play this file at 100% volume in QuickTime Player I get
silence. If I change any of the settings (24-bit or 44100 Hz for
example) I get static instead. It looks like the receiver locks on to
the 'cac3' data but doesn't like it.
In fact, I have a custom audio driver that lets me capture the data
sent out the digital port and I see 0x1800 byte packets that start
with the bytes "72 f8 1f 4e 01 00 00 70 77 0b" and are followed by a
section of mostly non-zero bytes, then a bunch of zero bytes padding
up to the next 0x1800 byte boundary where this repeats all over
again. I am able to capture 43 packets in the buffer and they all
start with those 10 bytes. The next two bytes vary and then the next
five bytes always seem to be "40 1e df e1 c0". All 43 packets seem to
have 0x708 bytes of data followed by 0x10f8 bytes of zeros.
So it sure looks to me like the pass through is not corrupting the
data (especially since the "SURROUNDTEST_DD_640.wav" file works).
Instead it appears that a52codec is generating 'cac3' packets that the
receiver does not like.
I have grabbed a copy of the source, and presume the relevant file is
a52codec/A52/ACShepA52Decoder.cpp as I can see where it tests the
passthrough flag and generates the sync bytes and so forth around line
919.
Any hints on what to look at/change in ACShepA52Decoder.cpp to try and
fix this so the receiver understands the generated 'cac3' packets?
Never mind. After looking at packet dumps of the successful
"SURROUNDTEST_DD_640.wav" file and DVD Player's output, it became
obvious that the 7th and 8th bytes of the 'cac3' packet header are the
16-bit little endian length in bits of the data to follow and
ACShepA52Decoder.cpp is setting that to a value that's twice what it
should be. After making that simple change, AC-3 pass through works
successfully on the "www_lynnemusic_com_surround_test.ac3" file now.
For anyone who wants the fix, I've posted it here:
https://github.com/mackyle/a52codec/commit/7a09e9caf686c68a0ebbaf0471e9a7151e6127ab
And a pre-built A52Codec.component (for 10.4+) that includes the fix
can be downloaded from:
https://github.com/mackyle/a52codec/downloads
Regards,
Kyle