David,

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.

Thanks, Fengguang