View Single Post
Old 12-03-10, 02:00 PM   #19
Anssi
Mageia packager
 
Join Date: Mar 2005
Location: Tampere, Finland
Posts: 45
Send a message via MSN to Anssi
Default Re: Call for testers: HDMI pass-through

Stephen, thanks a lot for your reply
Quote:
Originally Posted by Stephen Warren View Post
Some thoughts:

1) I believe these files are so-called "HBR" audio (High BitRate audio, name per HDMI spec)?
Yes.
Quote:
Originally Posted by Stephen Warren View Post
If so, looking at our Windows driver, only a limited subset of our GPUs support this feature, based on audio codec ID:

0x000B (perhaps, based on silicon rev)
0x0011
0x0012
0x0013
0x0014
0x0018
0x0019
0x001A
0x001B
0x001C
(some of those IDs don't actually exist in production)
Carl Eugen (non-working) and I (working) have both 0x000b codecs. Does "(perhaps, based on silicon rev)" mean that only a subset is supported? Both of the cards do have the HBR capability flag set, though.

Quote:
Originally Posted by Stephen Warren View Post
2) I don't recall what state the kernel driver is in for HBR support on NVIDIA codecs/controllers.
I added HBR mode support into ALSA several months ago, and the support is in 2.6.36. However, it is always possible I missed something (I just set the HBR flag in the pin (IIRC) and the non-pcm flag in the HDA stream format).
Quote:
Originally Posted by Stephen Warren View Post
3) There are some AES control bits that I think indicate the format of the audio being sent to the receiver; I can't remember if these are bits that asound.conf needs to set or the application needs to specify when opening the ALSA device, or if they're something that's simply encoded into the SPDIF stream. Perhaps some receivers are better than others at interpreting audio if those bits aren't set correctly?
ALSA configuration defines default AES bits, but they can be changed by using the device string or by manipulating mixer controls.
AFAICS the bits are set correctly, but I guess it wouldn't hurt to try some different values on affected systems. I believe most receivers ignore the AES bits, though.

I think the only relevant AES bit is the 0x02 (non-audio) bit. The AES bits are indeed encoded into the IEC958 stream, however that stream is produced in-hardware, while only the data payload (the IEC61937 stream) is sent to ALSA from userspace (+ the AES bits).

BTW, I got another success from a user with the following configuration:
  • NVidia GT240
  • 260.19.21
  • self-compiled alsa on 2.6.32-26-generic
  • Integra DTC-9.8
__________________
Anssi Hannula (anssi@mageia.org)
Mageia packager of NVIDIA drivers
XBMC developer
Anssi is offline   Reply With Quote