From: "Stéphane BERTHELOT" <sberthelot@emisfr.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: wni@nvidia.com, alsa-devel@alsa-project.org
Subject: Re: MCP7A HDMI passthrough audio Linux/ALSA
Date: Wed, 01 Jul 2009 11:18:15 +0200 [thread overview]
Message-ID: <4A4B29D7.5070805@emisfr.com> (raw)
In-Reply-To: <s5hr5x1apu9.wl%tiwai@suse.de>
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.
next prev parent reply other threads:[~2009-07-01 9:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4A4A01CF.9090203@emisfr.com>
[not found] ` <s5hocs598yz.wl%tiwai@suse.de>
[not found] ` <4A4A0D45.7030501@emisfr.com>
[not found] ` <s5hhbxx98d4.wl%tiwai@suse.de>
2009-06-30 20:51 ` MCP7A HDMI passthrough audio Linux/ALSA Stephane BERTHELOT
2009-07-01 6:18 ` Takashi Iwai
2009-07-01 9:18 ` Stéphane BERTHELOT [this message]
2009-07-01 10:01 ` Takashi Iwai
2009-07-03 18:07 ` Stéphane BERTHELOT
2009-07-03 19:27 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A4B29D7.5070805@emisfr.com \
--to=sberthelot@emisfr.com \
--cc=alsa-devel@alsa-project.org \
--cc=tiwai@suse.de \
--cc=wni@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.