[mythtv-users] ac3 passthrough problems

Scott list-mythtv at bluecamel.eml.cc
Fri Sep 22 05:53:44 UTC 2006


On Sep 22, 2006, at 12:42 AM, Michael T. Dean wrote:
> On 09/21/06 22:28, Scott wrote:
>> Mike, are you implying, or saying, that when I use mplayer -vfm hwac3
>> to pass data to my spdif, that mplayer is putting some sort of header
>> on the stream to inform my A/V receiver to switch to the proper mode?
>
> I don't know the specifics of MPlayer's "-vfm hwac3", but  
> basically, yes
> it should do exactly that.
>
>> I really don't think you're saying this but I want to confirm.
>>
>> Going back to the AC3 sound saga at hand, I plan to update to alsa
>> 1.0.13-rcX and see if it makes a difference.  I suspect it will not
>> since it appears only MythTV is having an issue.
> Because informing the receiver of the type of sound data is the
> responsibility of the application not of the driver...

I think this was the final clue I needed to crack the nut. I had  
noticed with mplayer -v -vfm hwac3 that the following was logged:

alsa-init: requested format: 48000 Hz, 2 channels, 100
alsa-spdif-init: playing AC3, 2 channels
alsa-init: using device iec958:{CARD 0 AES0 0x02 AES1 0x82 AES2 0x00  
AES3 0x02}

The iec958 device from a default xine config looks like  
iec958:AES0=0x6,AES1=0x82,AES2=0x0,AES3=0x2.

As it turns out, all those hex numbers do something! I'm still  
digesting it but see this post for what looks like a reasonable  
explanation: http://sourceforge.net/mailarchive/message.php? 
msg_id=8560868. Note that mplayer sets AES0=0x02 instead of AES0-0x6  
like xine does. I don't know what the difference is yet or if it  
really matters. I stumbled onto this solution when I decided to test  
mplayer as "-vo digital-hw -vfm hwac3" which basically mimic the  
MythTV recommended settings from the HOWTO for passing AC3 sound.  
That test produced the _same_ stuttering sound that I was hearing  
from MythTV. Clearly mplayer and xine were doing something special  
with the spdif device and the "magic" seems to be in the hex codes.

So my final MythTV settings that enabled my A/V receiver to see and  
decode DD/DTS from the SPDIF

Audio output device:  
ALSA:iec958:CARD=0,AES0=0x6,AES1=0x82,AES2=0x0,AES3=0x2
Passthrough output device: Default
Enable AC3 to SPDIF passthrough: [checked]
Enable DTS to SPDIF passthrough: [checked]
Aggressive Sound card Buffering: [not checked]
Use internal volume controls: [not checked]

Because the Internal Volume controls are not enable, no mixer device  
is setup. A few caveats about this config. it seems most people get  
by just fine following the howto in the wiki. For Intel HDA Audio  
onboard the Asus P5B using the RCA-SPDIF connection to my A/V  
receiver I needed the above iec958 definition. If I didn't use it  
then sound would either be garbled (stuttering or helicopter blade  
like sound) or I would get analog 2 channel PCM at my A/V receiver.  
This config was tested under ALSA 1.0.13rc2 but it should also work  
on 1.0.11 and later.

All my TV sources are OTA ATSC signals. Even with two channel sound,  
I expect that AC3 format will always be present. I haven't tested,  
and would not expect, the above config to work for anything but 48kHz  
AC3 sound. I don't use MythMusic so I don't expect this to be a  
problem for me.

Also, not tested, but the above settings could most likely work  
better by swapping the values for Audio output device and Passthrough  
output device. I would expect that one day MythTV would be smart  
enough to detect AC3/DTS formats and route them through the  
Passthrough device only as needed. I could be wrong but I thought I  
read that currently MythTV 0.20 doesn't do things this way. Maybe one  
day soon? :)

Thanks to everyone for the help on this!

--
Scott



More information about the mythtv-users mailing list