[alsa-devel] MCP7A HDMI passthrough audio Linux/ALSA

Stéphane BERTHELOT sberthelot at emisfr.com
Wed Jul 1 11:18:15 CEST 2009


Takashi Iwai a écrit :
> At Tue, 30 Jun 2009 22:51:03 +0200,
> Stephane BERTHELOT wrote:
>   
>
> Hm, so apparently your TV doesn't accept non-audio format?
> But TV accepted the ac3dec output with -R option, right?
> (Make sure this -- otherwise ac3dec might have decoded by itself.)
>
> Basically, -R means to send the encoded an AC3 stream (packed in the
> SPDIF format) without setting non-audio bit.  Whether non-audio bit is
> 1 or 0 is the only difference between -C and -R.  So, if -R really
> works but not -C, it means that the non-audio bit must be off no
> matter what you send.  Weird.
>
>   
I'm sure the TV only accepted -R and not -C (or -P) with the same ac3 file.
But I'm confused since I was quite sure -R would *decode* ac3 to PCM and 
then send it in LPCM format.
I used alsa-tools 1.0.20, should I try with a Git version ?
Sorry to ask this, but are you sure the data is sent as-is (in ac3 
format) with only audio bit changed ?
It sounds effectively completely weird to me, because moreover my Amp is 
showing LPCM format with -R (my TV would downsample the 5.1 AC3 signal 
to LPCM ??)
>> I may try again on XP/Vista tomorrow to be really sure it works on them.
>>
>> When changing play mode AES0 changes from 0x00 to 0x02 and AES1 to AES3 stay
>> the same (0x82,0x00,0x02 if I remember well)
>>     
>
> Note that the setup you made before ac3dec will be overridden anyway.
> And during ac3dec playback, the status bits are locked and can't be
> changed by others.
>
>   
Ok that's what I thought since ac3dec show AES bytes and they depend 
only on command line options and not iecset done before.
> Takashi
>
>
>   
Stephane.


More information about the Alsa-devel mailing list