[alsa-devel] [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard

Wu Fengguang fengguang.wu at intel.com
Tue Oct 20 03:26:00 CEST 2009


Sorry for the long delay!

On Thu, Oct 15, 2009 at 01:40:53AM +0800, David Härdeman wrote:
> On Wed, Oct 14, 2009 at 10:00:44AM +0800, Wu Fengguang wrote:
> >On Wed, Oct 14, 2009 at 09:54:55AM +0800, Zhenyu Wang wrote:
> >> On 2009.10.11 23:45:13 +0200, David Härdeman wrote:
> >>> 
> >>> a)
> >>> 
> >>> Channel mapping seems funky. I have a 5.1 speaker setup (though the 
> >>> receiver supports 7.1) and using "speaker-test -c 6" or "speaker-test 
> >>> -c8" with the hdmi output will generate output to the different speakers 
> >>> but not the intended ones. Speakers are connected correctly though 
> >>> (since the channels are correct if I use passthrough to send a raw AC3 
> >>> stream through either the S/PDIF or HDMI connector). This only occurs 
> >>> when using HDMI.
> >
> >This is known problem. The G45 HDMI codec does not support channel
> >mapping, so the mapping must be handled in user space. Future Intel
> >HDMI codecs may add support for this feature.
> Two questions (and sorry if the questions show my lack of understanding 
> of how this is supposed to work):
> i) Can't the driver at least provide reasonable defaults? If playing a 
> six channel audio, it seems reasonable that the user would like the 
> tracks to play to the speakers conforming to a 5.1 setup?

The problem is, ALSA and HDMI each has their default channel mapping,
which unfortunately disagree. All the driver could do is to tell
hardware about the required remapping info. And G45 seem to just
ignore this info. 

> ii) Is there any documentation somewhere on how this mapping is supposed 
> to be performed in user space?

I think Shane has provided a good example for you in another email :)
Here are more descriptions for the route plugin:

        Plugin: Route & Volume
        This plugin converts channels and applies volume during the conversion. The format and rate must match for both of them.

        pcm.name {
                type route              # Route & Volume conversion PCM
                slave STR               # Slave name
                # or
                slave {                 # Slave definition
                        pcm STR         # Slave PCM name
                        # or
                        pcm { }         # Slave PCM definition
                        [format STR]    # Slave format
                        [channels INT]  # Slave channels
                ttable {                # Transfer table (bi-dimensional compound of cchannels * schannels numbers)
                        CCHANNEL {
                                SCHANNEL REAL   # route value (0.0 - 1.0)

> >>> b)
> >>> 
> >>> Each time a new audio starts playing, there seems to be a 50/50 chance 
> >>> of complete silence, meaning that for each track change while listening 
> >>> to music (for example), the entire track will either play or stay 
> >>> silent.
> >>> 
> >>> This only happens when using HDMI, not S/PDIF. The problem occurs with 
> >>> both MythTV's music player and when watching a movie with Xine.
> >
> >Complete silence for how much time?
> For the entire duration of the particular movie/audio track/video 
> clip/whatever.
> So for instance, if I'm playing a list of tracks using MythTV, each 
> particular track will either play completely *or* there will be complete 
> silence for the duration of the track.
> Same goes for showing a movie or a video clip with mplayer or 
> xine...either the audio will work for the entire duration of the 
> movie/clip or there will be complete silence for the duration of the 
> clip.
> This can be "fixed" by just stopping mplayer/xine/whatever and starting 
> the program again with the same media until it works, but it's pretty 
> annoying.
> My uneducated guess is that there's some kind of content negotiation 
> going on at the beginning of each new media playback. On the front of 
> the receiver there is a LCD display which shows info on the current 
> audio setup (number of speakers, type of audio, etc), and it flickers 
> briefly at the start of each new track/video/etc before it shows the 
> correct situation for the current media...perhaps there is some problem 
> with this negotiation.

I actually have a DG45FC box and have not run into this problem for
all the HDMI monitors I have. What's your monitor model?

Did the kernel emit some error messages? What if you change display
modes with xrandr?

> I got some feedback from another user on alsa-user (CC:ed):
> http://article.gmane.org/gmane.linux.alsa.user/33393
> And he had similar but not identical problems (2 second silence at the 
> beginning of tracks, but not silence for the entire duration of a 

It's <= 0.5 second silence from my experience.

Shane wrote:
: This is odd I've never had this happen. I do get a half
: second of track skip between tracks so track transitions
: sound pretty terrible but complete silence, perhaps a
: developer will know what this is about. I wonder if the
: skip between tracks and the silence problems are related.
: IE, is the hardware reset on device open doing more harm
: than good?

HDMI codec/sink seem to take some time to response to the output
enable and new infoframe, so there are some delay. I've moved the HDMI
output enable command to module load time, this helps. The infoframe
is in theory created in run time based on the format of _each_ new
audio stream, so infoframe transmission has to be started/stopped
for each track..

> track), so perhaps different receivers react in different ways to 
> something unexpected in the HDMI stream?

Definitely. HDMI monitors are smart devices and can behave slightly
different. I've also experienced some weird HDMI monitor behaviors.


More information about the Alsa-devel mailing list