Re: [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard

Re: [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard

[Wu Fengguang]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard

[David Härdeman]

On Tue, Oct 20, 2009 at 09:26:00AM +0800, Wu Fengguang wrote:

>Sorry for the long delay!

No problem.

>On Thu, Oct 15, 2009 at 01:40:53AM +0800, David Härdeman wrote:
>> 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:

So perhaps I should still file a bug with the ALSA bugtracker asking for 
the default ALSA userspace to include a channel mapping along Shane's 
recommendation?

>> >Complete silence for how much time?
>> 
>> For the entire duration of the particular movie/audio track/video 
>> clip/whatever.
>> 
>
>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?

A Samsung LE-55A956 LCD TV. But I think the problem is not with the 
monitor (TV) but rather with the receiver that is between the DG45FC and 
the TV. The receiver is a Marantz SR8002 with HDMI support.

>Did the kernel emit some error messages?

Nope

>What if you change display
>modes with xrandr?

Haven't tried that yet...currently running on 1920x1080@60 which should 
(I guess) be one of the most common modes with modern LCD TV's.

>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..

So my current theory is along the line of HDMI audio infoframe or video 
infoframe problems. Do you have any pointers where in the driver(s) 
the infoframes (both audio and video) are generated so that I can add 
some debugging statements to dump the frames and compare the working 
and non-working scenarios?

Regards,
David


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

Re: [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard

[Wu Fengguang]

On Wed, Oct 21, 2009 at 06:37:58AM +0800, David Härdeman wrote:
> On Tue, Oct 20, 2009 at 09:26:00AM +0800, Wu Fengguang wrote:
> >On Thu, Oct 15, 2009 at 01:40:53AM +0800, David Härdeman wrote:
> >> 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:
> 
> So perhaps I should still file a bug with the ALSA bugtracker asking for 
> the default ALSA userspace to include a channel mapping along Shane's 
> recommendation?

That would be good. I'm not sure if PulseAudio need a separate fix.
(Lennart CCed).

> >> >Complete silence for how much time?
> >> 
> >> For the entire duration of the particular movie/audio track/video 
> >> clip/whatever.
> >> 
> >
> >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?
> 
> A Samsung LE-55A956 LCD TV. But I think the problem is not with the 
> monitor (TV) but rather with the receiver that is between the DG45FC and 
> the TV. The receiver is a Marantz SR8002 with HDMI support.

Got it. If you have a HDMI capable TV or monitor, it would be possible to get
rid of the Marantz and check if the problem sticks :)

> >Did the kernel emit some error messages?
> 
> Nope

OK. You can get more debug info if turning on

CONFIG_SND_VERBOSE_PROCFS=y
CONFIG_SND_VERBOSE_PRINTK=y
CONFIG_SND_DEBUG=y
CONFIG_SND_DEBUG_VERBOSE=y
CONFIG_SND_PCM_XRUN_DEBUG=y

> >What if you change display
> >modes with xrandr?
> 
> Haven't tried that yet...currently running on 1920x1080@60 which should 
> (I guess) be one of the most common modes with modern LCD TV's.

The infoframe would be different for 2-channel pure music and 5.1 channel
movie. The video timing might also affect audio stream, because the HDMI
audio data is transfered in the gaps of video data.
 
> >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..
> 
> So my current theory is along the line of HDMI audio infoframe or video 
> infoframe problems. Do you have any pointers where in the driver(s) 
> the infoframes (both audio and video) are generated so that I can add 
> some debugging statements to dump the frames and compare the working 
> and non-working scenarios?

I guess the infoframe itself should be identical for the same clip.
Have you tried upgrading to a recent Xorg/intel gfx driver?

Anyway, the kernel driver code is linux/sound/pci/hda/patch_intelhdmi.c
The relevant function is hdmi_setup_audio_infoframe(). Inside which the
hdmi_setup_channel_mapping() is not functioning for G45,
hdmi_setup_channel_allocation() is no-op for 2-channel music.
hdmi_debug_dip_size() and hdmi_clear_dip_buffers() can also be commented out.
And feel free to ask more questions :)

Thanks,
Fengguang
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard

[David Härdeman]

On Wed, Oct 21, 2009 at 09:38:12AM +0800, Wu Fengguang wrote:
> On Wed, Oct 21, 2009 at 06:37:58AM +0800, David Härdeman wrote:
> > On Tue, Oct 20, 2009 at 09:26:00AM +0800, Wu Fengguang wrote:
> > >On Thu, Oct 15, 2009 at 01:40:53AM +0800, David Härdeman wrote:
> > >> >Complete silence for how much time?
> > >> 
> > >> For the entire duration of the particular movie/audio track/video 
> > >> clip/whatever.
> > >> 
> > >
> > >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?
> > 
> > A Samsung LE-55A956 LCD TV. But I think the problem is not with the 
> > monitor (TV) but rather with the receiver that is between the DG45FC and 
> > the TV. The receiver is a Marantz SR8002 with HDMI support.
> 
> Got it. If you have a HDMI capable TV or monitor, it would be possible to get
> rid of the Marantz and check if the problem sticks :)

Nope, DG45FC <-> TV works fine (although only with stereo of course), so 
the culprit is the Marantz which is either being picky or buggy. Judging 
from from quick Google searches, HDMI related problems with audio/video 
seems par for the course with lots of different manufacturers (oh joy).

> OK. You can get more debug info if turning on
> 
> CONFIG_SND_VERBOSE_PROCFS=y
> CONFIG_SND_VERBOSE_PRINTK=y
> CONFIG_SND_DEBUG=y
> CONFIG_SND_DEBUG_VERBOSE=y
> CONFIG_SND_PCM_XRUN_DEBUG=y

Enabled in my latest tests, dmesg included below...

> > >What if you change display
> > >modes with xrandr?
> > 
> > Haven't tried that yet...currently running on 1920x1080@60 which should 
> > (I guess) be one of the most common modes with modern LCD TV's.
> 
> The infoframe would be different for 2-channel pure music and 5.1 channel
> movie. The video timing might also affect audio stream, because the HDMI
> audio data is transfered in the gaps of video data.

I've tried a couple of different modes with xrandr, with both 2, 6 and 8 
channels of audio but it doesn't seem to change anything.
 
> > >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..
> > 
> > So my current theory is along the line of HDMI audio infoframe or video 
> > infoframe problems. Do you have any pointers where in the driver(s) 
> > the infoframes (both audio and video) are generated so that I can add 
> > some debugging statements to dump the frames and compare the working 
> > and non-working scenarios?
> 
> I guess the infoframe itself should be identical for the same clip.
> Have you tried upgrading to a recent Xorg/intel gfx driver?

Currently testing with kernel 2.6.32-rc5 (self-compiled) + intel-gfx 
2.9.0 and X11R7.4 (from Debian unstable).
 
> Anyway, the kernel driver code is linux/sound/pci/hda/patch_intelhdmi.c
> The relevant function is hdmi_setup_audio_infoframe(). Inside which the
> hdmi_setup_channel_mapping() is not functioning for G45,
> hdmi_setup_channel_allocation() is no-op for 2-channel music.
> hdmi_debug_dip_size() and hdmi_clear_dip_buffers() can also be commented out.
> And feel free to ask more questions :)

I think I found a bug in the infoframe generation, 
hdmi_fill_audio_infoframe from sound/pci/hda/patch_intelhdmi.c has two 
for loops which use sizeof(ai) but ai is a pointer to struct 
hdmi_audio_infoframe so the size of a pointer is used rather than the 
size of the struct meaning that the wrong number of bytes is written.

After fixing that, the dmesg output when playing "speaker-test -c8 -twav 
-D hdmi -l1" is:

[  866.169344] ALSA sound/pci/hda/hda_intel.c:1617: azx_pcm_prepare: 
bufsize=0x10000, format=0x17
[  866.169353] ALSA sound/pci/hda/hda_codec.c:1083: 
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x17
[  866.176112] ALSA sound/pci/hda/patch_intelhdmi.c:446: HDMI: select CA 
0x13 for 8-channel allocation:  FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC 
FLW/FRW FLH/FRH TC FCH
[  866.176321] HDMI: ASP channel 0 => slot 0
[  866.176354] HDMI: ASP channel 0 => slot 0
[  866.176406] HDMI: ASP channel 0 => slot 0
[  866.176438] HDMI: ASP channel 0 => slot 0
[  866.176490] HDMI: ASP channel 0 => slot 0
[  866.176533] HDMI: ASP channel 0 => slot 0
[  866.176565] HDMI: ASP channel 0 => slot 0
[  866.176617] HDMI: ASP channel 0 => slot 0
[  866.176649] HDMI: ELD buf size is 64
[  866.176691] HDMI: DIP GP[0] buf size is 13
[  866.176733] HDMI: DIP GP[1] buf size is 10
[  866.176775] HDMI: DIP GP[2] buf size is 30
[  866.176817] HDMI: DIP GP[3] buf size is 30
[  866.176859] HDMI: DIP GP[4] buf size is 0
[  866.176901] HDMI: DIP GP[5] buf size is 0
[  866.176943] HDMI: DIP GP[6] buf size is 0
[  866.176986] HDMI: DIP GP[7] buf size is 0
[  866.179041] ALSA sound/pci/hda/patch_intelhdmi.c:342: HDMI: DIP GP[0] 
buf reported size=13, written=32
[  866.181209] ALSA sound/pci/hda/patch_intelhdmi.c:342: HDMI: DIP GP[1] 
buf reported size=10, written=32
[  866.183271] ALSA sound/pci/hda/patch_intelhdmi.c:342: HDMI: DIP GP[2] 
buf reported size=30, written=32
[  866.185385] ALSA sound/pci/hda/patch_intelhdmi.c:342: HDMI: DIP GP[3] 
buf reported size=30, written=32
[  866.185574] XXX: Writing audio inf: 0x84 0x01 0x0A 0x57 0x07 0x00 
0x00 0x13 0x00 0x00 0x00 0x00 0x00 0x00
[  872.032225] ALSA sound/pci/hda/hda_codec.c:1096: 
hda_codec_cleanup_stream: NID=0x2

(The XXX line was added by me to print the audio infoframe)

I think (if I understood the code correctly), that "DIP GP[0]" holds the 
infoframe, but I don't understand why it would report a buf size of 
13...the audio infoframe is 14 bytes (3 header + 1 checksum + 10 body)?

Also, what does the GP[1..3] buffers hold?

Anyway, even with the above for loops fixed, I still have the same 
problems (not that weird perhaps since all the bytes that were being 
missed anyway defaulted to 0x00).

I've noticed that if a run this:

	while true; do
		speaker-test -t wav -c 8 -D hdmi -l 1
		speaker-test -t wav -c 2 -D hdmi -l 1
	done

it always works, but this:

	while true; do
		speaker-test -t wav -c 2 -D hdmi -l 1
	done

doesn't.

Not sure what to make of it, the intel hdmi driver doesn't seem to do 
anything special if the parameters (like channel count) change between 
clips.

-- 
David Härdeman

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

Re: [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard

[Wu Fengguang]

On Mon, Oct 26, 2009 at 06:31:45AM +0800, David Härdeman wrote:
> On Wed, Oct 21, 2009 at 09:38:12AM +0800, Wu Fengguang wrote:
> > On Wed, Oct 21, 2009 at 06:37:58AM +0800, David Härdeman wrote:
> > > On Tue, Oct 20, 2009 at 09:26:00AM +0800, Wu Fengguang wrote:
> > > >On Thu, Oct 15, 2009 at 01:40:53AM +0800, David Härdeman wrote:
> > > >> >Complete silence for how much time?
> > > >> 
> > > >> For the entire duration of the particular movie/audio track/video 
> > > >> clip/whatever.
> > > >> 
> > > >
> > > >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?
> > > 
> > > A Samsung LE-55A956 LCD TV. But I think the problem is not with the 
> > > monitor (TV) but rather with the receiver that is between the DG45FC and 
> > > the TV. The receiver is a Marantz SR8002 with HDMI support.
> > 
> > Got it. If you have a HDMI capable TV or monitor, it would be possible to get
> > rid of the Marantz and check if the problem sticks :)
> 
> Nope, DG45FC <-> TV works fine (although only with stereo of course), so 
> the culprit is the Marantz which is either being picky or buggy. Judging 
> from from quick Google searches, HDMI related problems with audio/video 
> seems par for the course with lots of different manufacturers (oh joy).

Hmm..

> > OK. You can get more debug info if turning on
> > 
> > CONFIG_SND_VERBOSE_PROCFS=y
> > CONFIG_SND_VERBOSE_PRINTK=y
> > CONFIG_SND_DEBUG=y
> > CONFIG_SND_DEBUG_VERBOSE=y
> > CONFIG_SND_PCM_XRUN_DEBUG=y
> 
> Enabled in my latest tests, dmesg included below...

Thanks.

> > > >What if you change display
> > > >modes with xrandr?
> > > 
> > > Haven't tried that yet...currently running on 1920x1080@60 which should 
> > > (I guess) be one of the most common modes with modern LCD TV's.
> > 
> > The infoframe would be different for 2-channel pure music and 5.1 channel
> > movie. The video timing might also affect audio stream, because the HDMI
> > audio data is transfered in the gaps of video data.
> 
> I've tried a couple of different modes with xrandr, with both 2, 6 and 8 
> channels of audio but it doesn't seem to change anything.

OK.

> > > >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..
> > > 
> > > So my current theory is along the line of HDMI audio infoframe or video 
> > > infoframe problems. Do you have any pointers where in the driver(s) 
> > > the infoframes (both audio and video) are generated so that I can add 
> > > some debugging statements to dump the frames and compare the working 
> > > and non-working scenarios?
> > 
> > I guess the infoframe itself should be identical for the same clip.
> > Have you tried upgrading to a recent Xorg/intel gfx driver?
> 
> Currently testing with kernel 2.6.32-rc5 (self-compiled) + intel-gfx 
> 2.9.0 and X11R7.4 (from Debian unstable).

That's fairly bleeding edge :)

> > Anyway, the kernel driver code is linux/sound/pci/hda/patch_intelhdmi.c
> > The relevant function is hdmi_setup_audio_infoframe(). Inside which the
> > hdmi_setup_channel_mapping() is not functioning for G45,
> > hdmi_setup_channel_allocation() is no-op for 2-channel music.
> > hdmi_debug_dip_size() and hdmi_clear_dip_buffers() can also be commented out.
> > And feel free to ask more questions :)
> 
> I think I found a bug in the infoframe generation, 
> hdmi_fill_audio_infoframe from sound/pci/hda/patch_intelhdmi.c has two 
> for loops which use sizeof(ai) but ai is a pointer to struct 
> hdmi_audio_infoframe so the size of a pointer is used rather than the 
> size of the struct meaning that the wrong number of bytes is written.

Good catch, thank you very much!

> After fixing that, the dmesg output when playing "speaker-test -c8 -twav 
> -D hdmi -l1" is:
> 
> [  866.169344] ALSA sound/pci/hda/hda_intel.c:1617: azx_pcm_prepare: 
> bufsize=0x10000, format=0x17
> [  866.169353] ALSA sound/pci/hda/hda_codec.c:1083: 
> hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x17
> [  866.176112] ALSA sound/pci/hda/patch_intelhdmi.c:446: HDMI: select CA 
> 0x13 for 8-channel allocation:  FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC 
> FLW/FRW FLH/FRH TC FCH
> [  866.176321] HDMI: ASP channel 0 => slot 0
> [  866.176354] HDMI: ASP channel 0 => slot 0
> [  866.176406] HDMI: ASP channel 0 => slot 0
> [  866.176438] HDMI: ASP channel 0 => slot 0
> [  866.176490] HDMI: ASP channel 0 => slot 0
> [  866.176533] HDMI: ASP channel 0 => slot 0
> [  866.176565] HDMI: ASP channel 0 => slot 0
> [  866.176617] HDMI: ASP channel 0 => slot 0
> [  866.176649] HDMI: ELD buf size is 64
> [  866.176691] HDMI: DIP GP[0] buf size is 13
> [  866.176733] HDMI: DIP GP[1] buf size is 10
> [  866.176775] HDMI: DIP GP[2] buf size is 30
> [  866.176817] HDMI: DIP GP[3] buf size is 30
> [  866.176859] HDMI: DIP GP[4] buf size is 0
> [  866.176901] HDMI: DIP GP[5] buf size is 0
> [  866.176943] HDMI: DIP GP[6] buf size is 0
> [  866.176986] HDMI: DIP GP[7] buf size is 0
> [  866.179041] ALSA sound/pci/hda/patch_intelhdmi.c:342: HDMI: DIP GP[0] 
> buf reported size=13, written=32
> [  866.181209] ALSA sound/pci/hda/patch_intelhdmi.c:342: HDMI: DIP GP[1] 
> buf reported size=10, written=32
> [  866.183271] ALSA sound/pci/hda/patch_intelhdmi.c:342: HDMI: DIP GP[2] 
> buf reported size=30, written=32
> [  866.185385] ALSA sound/pci/hda/patch_intelhdmi.c:342: HDMI: DIP GP[3] 
> buf reported size=30, written=32
> [  866.185574] XXX: Writing audio inf: 0x84 0x01 0x0A 0x57 0x07 0x00 
> 0x00 0x13 0x00 0x00 0x00 0x00 0x00 0x00
> [  872.032225] ALSA sound/pci/hda/hda_codec.c:1096: 
> hda_codec_cleanup_stream: NID=0x2
> 
> (The XXX line was added by me to print the audio infoframe)

FYI, I'll write another Intel GPU tool to dump the audio infoframe
(among others) directly from the GPU registers :)

> I think (if I understood the code correctly), that "DIP GP[0]" holds the 
> infoframe, but I don't understand why it would report a buf size of 
> 13...the audio infoframe is 14 bytes (3 header + 1 checksum + 10 body)?

Good question. I guess I made it wrong again. The checksum field may
be auto-generated by hardware:

        The HDMI specification defines a data island packet with a
        header of 4 bytes (3 bytes content + 1 byte ECC) and packet
        body of 32 bytes (28 bytes content and 4 bytes ECC). Note that
        the ECC bytes are not present in the DIP content populated by
        software and are hardware generated.
                                                      - from HDA-034-A2.pdf

> Also, what does the GP[1..3] buffers hold?

They are for ACP and ISRC1/2 (not utilized by driver for now):

        When audio data is transmitted over the HDMI link, associated
        control information is transmitted as "Data Island Packets"
        over the link. Some of the packet types applicable to audio
        are ACP packets (for content protection), ISRC1/2 (for content
        info), Audio infoframe etc. For a detailed list of control
        packets and respective formats, please refer to the HDMI
        specification. 

> Anyway, even with the above for loops fixed, I still have the same 
> problems (not that weird perhaps since all the bytes that were being 
> missed anyway defaulted to 0x00).

Yeah. I have always be wondering whether the checksum field is
necessary. Removing it seems to change nothing. Anyway the number 13
is a strong indication for removing it.

> I've noticed that if a run this:
> 
> 	while true; do
> 		speaker-test -t wav -c 8 -D hdmi -l 1
> 		speaker-test -t wav -c 2 -D hdmi -l 1
> 	done
> 
> it always works, but this:
> 
> 	while true; do
> 		speaker-test -t wav -c 2 -D hdmi -l 1
> 	done
> 
> doesn't.

This is weird for now. Thanks for the tip!

> Not sure what to make of it, the intel hdmi driver doesn't seem to do 
> anything special if the parameters (like channel count) change between 
> clips.

Thanks,
Fengguang
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard

[Takashi Iwai]

At Wed, 21 Oct 2009 09:38:12 +0800,
Wu Fengguang wrote:
> 
> On Wed, Oct 21, 2009 at 06:37:58AM +0800, David Härdeman wrote:
> > On Tue, Oct 20, 2009 at 09:26:00AM +0800, Wu Fengguang wrote:
> > >On Thu, Oct 15, 2009 at 01:40:53AM +0800, David Härdeman wrote:
> > >> 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:
> > 
> > So perhaps I should still file a bug with the ALSA bugtracker asking for 
> > the default ALSA userspace to include a channel mapping along Shane's 
> > recommendation?
> 
> That would be good. I'm not sure if PulseAudio need a separate fix.
> (Lennart CCed).

Some ideas in my mind (and experimental patches in my archive) for
exposing the channel mapping to user-space.  But I've had too little
time to work on it until now.  Will try to find some time again.

Also, for remapping the channels, we can write another plugin that
is more optimized than the route plugin.


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard

[Shane W]

Hey all,

On Tue, Oct 20, 2009 at 09:26:00AM +0800, Wu Fengguang wrote:
> It's <= 0.5 second silence from my experience.

Correct.

> 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..

I know this has come up before but can't we not start/stop
the infoframe if the sample format on the new track is the
same as the old. I mean playing an album, you're gonna get
44100, 2ch s16le 95% of the time so that would atleast
cause the problem to appear much less.

Shane

Re: [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard

[David Härdeman]

On Tue, Oct 20, 2009 at 03:43:53PM -0700, Shane W wrote:
> On Tue, Oct 20, 2009 at 09:26:00AM +0800, Wu Fengguang wrote:
> > 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..
> 
> I know this has come up before but can't we not start/stop
> the infoframe if the sample format on the new track is the
> same as the old. I mean playing an album, you're gonna get
> 44100, 2ch s16le 95% of the time so that would atleast
> cause the problem to appear much less.

Tried it, still had the second-track-produces-silence bug on my receiver 
so I couldn't test it properly.

I however did manage to create a different patch which fixed my receiver 
bug (yay!)...by sending "refer-to-stream-header" audio infoframes from 
pcm close to pcm open...something like this quick hack:


--- linux-2.6.32-rc5/sound/pci/hda/patch_intelhdmi.c	2009-10-16 02:41:50.000000000 +0200
+++ ../linux-2.6.32-rc5/sound/pci/hda/patch_intelhdmi.c	2009-10-26 23:39:54.000000000 +0100
@@ -552,8 +552,16 @@
 					 struct snd_pcm_substream *substream)
 {
 	struct intel_hdmi_spec *spec = codec->spec;
+	struct hdmi_audio_infoframe ai = {
+		.type		= 0x84,
+		.ver		= 0x01,
+		.len		= 0x0a,
+		.CC02_CT47	= 0x00,
+	};
 
 	hdmi_stop_infoframe_trans(codec);
+	hdmi_fill_audio_infoframe(codec, &ai);
+	hdmi_start_infoframe_trans(codec);
 
 	return snd_hda_multi_out_dig_close(codec, &spec->multiout);
 }
@@ -571,6 +579,7 @@
 
 	hdmi_set_channel_count(codec, substream->runtime->channels);
 
+	hdmi_stop_infoframe_trans(codec);
 	hdmi_setup_audio_infoframe(codec, substream);
 
 	return 0;


Not sure how/if something like that could be turned into an acceptable 
patch though...

-- 
David Härdeman

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

Re: [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard

[Wu Fengguang]

[-- Attachment #1: Type: text/plain, Size: 2521 bytes --]

On Tue, Oct 27, 2009 at 07:11:25AM +0800, David Härdeman wrote:
> On Tue, Oct 20, 2009 at 03:43:53PM -0700, Shane W wrote:
> > On Tue, Oct 20, 2009 at 09:26:00AM +0800, Wu Fengguang wrote:
> > > 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..
> > 
> > I know this has come up before but can't we not start/stop
> > the infoframe if the sample format on the new track is the
> > same as the old. I mean playing an album, you're gonna get
> > 44100, 2ch s16le 95% of the time so that would atleast
> > cause the problem to appear much less.
> 
> Tried it, still had the second-track-produces-silence bug on my receiver 
> so I couldn't test it properly.
> 
> I however did manage to create a different patch which fixed my receiver 
> bug (yay!)...by sending "refer-to-stream-header" audio infoframes from 
> pcm close to pcm open...something like this quick hack:

This is an important clue, thank you! :)

The patch is not quite logical. Hopefully the sticky infoframe patch
can help in the same way.

Attached is the broken up patches, hope that helps your debugging.
The last 4 patches in the series are inspired by your comments.

Thanks,
Fengguang

> 
> --- linux-2.6.32-rc5/sound/pci/hda/patch_intelhdmi.c	2009-10-16 02:41:50.000000000 +0200
> +++ ../linux-2.6.32-rc5/sound/pci/hda/patch_intelhdmi.c	2009-10-26 23:39:54.000000000 +0100
> @@ -552,8 +552,16 @@
>  					 struct snd_pcm_substream *substream)
>  {
>  	struct intel_hdmi_spec *spec = codec->spec;
> +	struct hdmi_audio_infoframe ai = {
> +		.type		= 0x84,
> +		.ver		= 0x01,
> +		.len		= 0x0a,
> +		.CC02_CT47	= 0x00,
> +	};
>  
>  	hdmi_stop_infoframe_trans(codec);
> +	hdmi_fill_audio_infoframe(codec, &ai);
> +	hdmi_start_infoframe_trans(codec);
>  
>  	return snd_hda_multi_out_dig_close(codec, &spec->multiout);
>  }
> @@ -571,6 +579,7 @@
>  
>  	hdmi_set_channel_count(codec, substream->runtime->channels);
>  
> +	hdmi_stop_infoframe_trans(codec);
>  	hdmi_setup_audio_infoframe(codec, substream);
>  
>  	return 0;
> 
> 
> Not sure how/if something like that could be turned into an acceptable 
> patch though...
> 
> -- 
> David Härdeman

[-- Attachment #2: intel-hdmi-2009-10-27.tgz --]
[-- Type: application/x-gtar, Size: 9364 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard

[Wu Fengguang]

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]

Hi Shane,

[sorry for late response - I was out traveling]

On Wed, Oct 21, 2009 at 06:43:53AM +0800, Shane W wrote:
> Hey all,
> 
> On Tue, Oct 20, 2009 at 09:26:00AM +0800, Wu Fengguang wrote:
> > It's <= 0.5 second silence from my experience.
> 
> Correct.
> 
> > 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..
> 
> I know this has come up before but can't we not start/stop
> the infoframe if the sample format on the new track is the
> same as the old. I mean playing an album, you're gonna get
> 44100, 2ch s16le 95% of the time so that would atleast
> cause the problem to appear much less.

Yeah, this is worth trying. The attached (combined) patch have bits to
do sticky infoframe. However my tests show that it didn't improve the
0.5s delay..

Thanks,
Fengguang


[-- Attachment #2: hdmi-intel.patch --]
[-- Type: text/x-diff, Size: 24420 bytes --]

--- sound-2.6.orig/sound/pci/hda/patch_intelhdmi.c	2009-10-15 11:16:05.000000000 +0800
+++ sound-2.6/sound/pci/hda/patch_intelhdmi.c	2009-10-27 11:23:12.000000000 +0800
@@ -33,15 +33,19 @@
 #include "hda_codec.h"
 #include "hda_local.h"
 
-static hda_nid_t cvt_nid;	/* audio converter */
-static hda_nid_t pin_nid;	/* HDMI output pin */
-
-#define INTEL_HDMI_EVENT_TAG		0x08
+/*
+ * The HDMI/DisplayPort configuration can be highly dynamic. A graphics device
+ * could support two independent pipes, each of them can be connected to one or
+ * more ports (DVI, HDMI or DisplayPort).
+ *
+ * The HDA correspondence of pipes/ports are converter/pin nodes.
+ */
+#define INTEL_HDMI_CVTS	2
+#define INTEL_HDMI_PINS	3
 
-struct intel_hdmi_spec {
-	struct hda_multi_out multiout;
-	struct hda_pcm pcm_rec;
-	struct hdmi_eld sink_eld;
+static char *intel_hdmi_pcm_names[INTEL_HDMI_CVTS] = {
+	"INTEL HDMI 0",
+	"INTEL HDMI 1",
 };
 
 struct hdmi_audio_infoframe {
@@ -49,7 +53,6 @@ struct hdmi_audio_infoframe {
 	u8 ver;  /* 0x01 */
 	u8 len;  /* 0x0a */
 
-	u8 checksum;	/* PB0 */
 	u8 CC02_CT47;	/* CC in bits 0:2, CT in 4:7 */
 	u8 SS01_SF24;
 	u8 CXT04;
@@ -58,6 +61,35 @@ struct hdmi_audio_infoframe {
 	u8 reserved[5];	/* PB6 - PB10 */
 };
 
+struct intel_hdmi_spec {
+	int num_cvts;
+	int num_pins;
+	hda_nid_t cvt[INTEL_HDMI_CVTS+1];  /* audio sources */
+	hda_nid_t pin[INTEL_HDMI_PINS+1];  /* audio sinks */
+
+	/*
+	 * source connection for each pin
+	 */
+	hda_nid_t pin_cvt[INTEL_HDMI_PINS+1];
+
+	/*
+	 * HDMI sink attached to each pin
+	 */
+	bool		sink_present[INTEL_HDMI_PINS];
+	bool		sink_eldv[INTEL_HDMI_PINS];
+	struct hdmi_eld sink_eld[INTEL_HDMI_PINS];
+
+	/*
+	 * export one pcm per pipe
+	 */
+	struct hda_pcm	pcm_rec[INTEL_HDMI_CVTS];
+
+	/*
+	 * cache the active infoframe
+	 */
+	struct hdmi_audio_infoframe ai[INTEL_HDMI_PINS];
+};
+
 /*
  * CEA speaker placement:
  *
@@ -184,40 +216,165 @@ static struct cea_channel_speaker_alloca
 { .ca_index = 0x31,  .speakers = { FRW,  FLW,  RR,  RL,  FC,  LFE,  FR,  FL } },
 };
 
+
+/*
+ * HDA/HDMI auto parsing
+ */
+
+static int hda_node_index(hda_nid_t *nids, hda_nid_t nid)
+{
+	int i;
+
+	for (i = 0; nids[i]; i++)
+		if (nids[i] == nid)
+			return i;
+
+	snd_printk(KERN_WARNING "HDMI: nid %d not registered\n", nid);
+	return -EINVAL;
+}
+
+static int intel_hdmi_read_pin_conn(struct hda_codec *codec, hda_nid_t pin_nid)
+{
+	struct intel_hdmi_spec *spec = codec->spec;
+	hda_nid_t conn_list[HDA_MAX_CONNECTIONS];
+	int conn_len, curr;
+	int index;
+
+	if (!(get_wcaps(codec, pin_nid) & AC_WCAP_CONN_LIST)) {
+		snd_printk(KERN_WARNING
+			   "HDMI: pin %d wcaps %#x "
+			   "does not support connection list\n",
+			   pin_nid, get_wcaps(codec, pin_nid));
+		return -EINVAL;
+	}
+
+	conn_len = snd_hda_get_connections(codec, pin_nid, conn_list,
+					   HDA_MAX_CONNECTIONS);
+	if (conn_len > 1)
+		curr = snd_hda_codec_read(codec, pin_nid, 0,
+					  AC_VERB_GET_CONNECT_SEL, 0);
+	else
+		curr = 0;
+
+	index = hda_node_index(spec->pin, pin_nid);
+	if (index < 0)
+		return -EINVAL;
+
+	spec->pin_cvt[index] = conn_list[curr];
+
+	return 0;
+}
+
+static int intel_hdmi_add_pin(struct hda_codec *codec, hda_nid_t pin_nid)
+{
+	struct intel_hdmi_spec *spec = codec->spec;
+
+	if (spec->num_pins >= INTEL_HDMI_PINS) {
+		snd_printk(KERN_WARNING
+			   "HDMI: no space for pin %d \n", pin_nid);
+		return -EINVAL;
+	}
+
+	spec->pin[spec->num_pins] = pin_nid;
+	spec->num_pins++;
+
+	/*
+	 * It is assumed that converter nodes come first in the node list and
+	 * hence have been registered and usable now.
+	 */
+	return intel_hdmi_read_pin_conn(codec, pin_nid);
+}
+
+static int intel_hdmi_add_cvt(struct hda_codec *codec, hda_nid_t nid)
+{
+	struct intel_hdmi_spec *spec = codec->spec;
+
+	if (spec->num_cvts >= INTEL_HDMI_CVTS) {
+		snd_printk(KERN_WARNING
+			   "HDMI: no space for converter %d \n", nid);
+		return -EINVAL;
+	}
+
+	spec->cvt[spec->num_cvts] = nid;
+	spec->num_cvts++;
+
+	return 0;
+}
+
+static int intel_hdmi_parse_codec(struct hda_codec *codec)
+{
+	hda_nid_t nid;
+	int i, nodes;
+
+	nodes = snd_hda_get_sub_nodes(codec, codec->afg, &nid);
+	if (!nid || nodes < 0) {
+		snd_printk(KERN_WARNING "HDMI: failed to get afg sub nodes\n");
+		return -EINVAL;
+	}
+
+	for (i = 0; i < nodes; i++, nid++) {
+		unsigned int caps;
+		unsigned int type;
+
+		caps = snd_hda_param_read(codec, nid, AC_PAR_AUDIO_WIDGET_CAP);
+		type = get_wcaps_type(caps);
+
+		if (!(caps & AC_WCAP_DIGITAL))
+			continue;
+
+		switch (type) {
+		case AC_WID_AUD_OUT:
+			if (intel_hdmi_add_cvt(codec, nid) < 0)
+				return -EINVAL;
+			break;
+		case AC_WID_PIN:
+			caps = snd_hda_param_read(codec, nid, AC_PAR_PIN_CAP);
+			if (!(caps & AC_PINCAP_HDMI))
+				continue;
+			if (intel_hdmi_add_pin(codec, nid) < 0)
+				return -EINVAL;
+			break;
+		}
+	}
+
+	return 0;
+}
+
 /*
  * HDMI routines
  */
 
 #ifdef BE_PARANOID
-static void hdmi_get_dip_index(struct hda_codec *codec, hda_nid_t nid,
+static void hdmi_get_dip_index(struct hda_codec *codec, hda_nid_t pin_nid,
 				int *packet_index, int *byte_index)
 {
 	int val;
 
-	val = snd_hda_codec_read(codec, nid, 0, AC_VERB_GET_HDMI_DIP_INDEX, 0);
+	val = snd_hda_codec_read(codec, pin_nid, 0,
+				 AC_VERB_GET_HDMI_DIP_INDEX, 0);
 
 	*packet_index = val >> 5;
 	*byte_index = val & 0x1f;
 }
 #endif
 
-static void hdmi_set_dip_index(struct hda_codec *codec, hda_nid_t nid,
+static void hdmi_set_dip_index(struct hda_codec *codec, hda_nid_t pin_nid,
 				int packet_index, int byte_index)
 {
 	int val;
 
 	val = (packet_index << 5) | (byte_index & 0x1f);
 
-	snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_HDMI_DIP_INDEX, val);
+	snd_hda_codec_write(codec, pin_nid, 0, AC_VERB_SET_HDMI_DIP_INDEX, val);
 }
 
-static void hdmi_write_dip_byte(struct hda_codec *codec, hda_nid_t nid,
+static void hdmi_write_dip_byte(struct hda_codec *codec, hda_nid_t pin_nid,
 				unsigned char val)
 {
-	snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_HDMI_DIP_DATA, val);
+	snd_hda_codec_write(codec, pin_nid, 0, AC_VERB_SET_HDMI_DIP_DATA, val);
 }
 
-static void hdmi_enable_output(struct hda_codec *codec)
+static void hdmi_enable_output(struct hda_codec *codec, hda_nid_t pin_nid)
 {
 	/* Unmute */
 	if (get_wcaps(codec, pin_nid) & AC_WCAP_OUT_AMP)
@@ -231,7 +388,8 @@ static void hdmi_enable_output(struct hd
 /*
  * Enable Audio InfoFrame Transmission
  */
-static void hdmi_start_infoframe_trans(struct hda_codec *codec)
+static void hdmi_start_infoframe_trans(struct hda_codec *codec,
+				       hda_nid_t pin_nid)
 {
 	hdmi_set_dip_index(codec, pin_nid, 0x0, 0x0);
 	snd_hda_codec_write(codec, pin_nid, 0, AC_VERB_SET_HDMI_DIP_XMIT,
@@ -241,50 +399,53 @@ static void hdmi_start_infoframe_trans(s
 /*
  * Disable Audio InfoFrame Transmission
  */
-static void hdmi_stop_infoframe_trans(struct hda_codec *codec)
+static void hdmi_stop_infoframe_trans(struct hda_codec *codec,
+				      hda_nid_t pin_nid)
 {
 	hdmi_set_dip_index(codec, pin_nid, 0x0, 0x0);
 	snd_hda_codec_write(codec, pin_nid, 0, AC_VERB_SET_HDMI_DIP_XMIT,
 						AC_DIPXMIT_DISABLE);
 }
 
-static int hdmi_get_channel_count(struct hda_codec *codec)
+static int hdmi_get_channel_count(struct hda_codec *codec, hda_nid_t nid)
 {
-	return 1 + snd_hda_codec_read(codec, cvt_nid, 0,
+	return 1 + snd_hda_codec_read(codec, nid, 0,
 					AC_VERB_GET_CVT_CHAN_COUNT, 0);
 }
 
-static void hdmi_set_channel_count(struct hda_codec *codec, int chs)
+static void hdmi_set_channel_count(struct hda_codec *codec,
+				   hda_nid_t nid, int chs)
 {
-	snd_hda_codec_write(codec, cvt_nid, 0,
-					AC_VERB_SET_CVT_CHAN_COUNT, chs - 1);
+	snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_CVT_CHAN_COUNT, chs - 1);
 
-	if (chs != hdmi_get_channel_count(codec))
+#ifdef CONFIG_SND_DEBUG_VERBOSE
+	if (chs != hdmi_get_channel_count(codec, nid))
 		snd_printd(KERN_INFO "HDMI channel count: expect %d, get %d\n",
-					chs, hdmi_get_channel_count(codec));
+			   chs, hdmi_get_channel_count(codec, nid));
+#endif
 }
 
-static void hdmi_debug_channel_mapping(struct hda_codec *codec)
+static void hdmi_debug_channel_mapping(struct hda_codec *codec, hda_nid_t nid)
 {
 #ifdef CONFIG_SND_DEBUG_VERBOSE
 	int i;
 	int slot;
 
 	for (i = 0; i < 8; i++) {
-		slot = snd_hda_codec_read(codec, cvt_nid, 0,
+		slot = snd_hda_codec_read(codec, nid, 0,
 						AC_VERB_GET_HDMI_CHAN_SLOT, i);
 		printk(KERN_DEBUG "HDMI: ASP channel %d => slot %d\n",
-						slot >> 4, slot & 0x7);
+						slot >> 4, slot & 0xf);
 	}
 #endif
 }
 
-static void hdmi_parse_eld(struct hda_codec *codec)
+static void hdmi_parse_eld(struct hda_codec *codec, int index)
 {
 	struct intel_hdmi_spec *spec = codec->spec;
-	struct hdmi_eld *eld = &spec->sink_eld;
+	struct hdmi_eld *eld = &spec->sink_eld[index];
 
-	if (!snd_hdmi_get_eld(eld, codec, pin_nid))
+	if (!snd_hdmi_get_eld(eld, codec, spec->pin[index]))
 		snd_hdmi_show_eld(eld);
 }
 
@@ -293,7 +454,7 @@ static void hdmi_parse_eld(struct hda_co
  * Audio InfoFrame routines
  */
 
-static void hdmi_debug_dip_size(struct hda_codec *codec)
+static void hdmi_debug_dip_size(struct hda_codec *codec, hda_nid_t pin_nid)
 {
 #ifdef CONFIG_SND_DEBUG_VERBOSE
 	int i;
@@ -310,7 +471,7 @@ static void hdmi_debug_dip_size(struct h
 #endif
 }
 
-static void hdmi_clear_dip_buffers(struct hda_codec *codec)
+static void hdmi_clear_dip_buffers(struct hda_codec *codec, hda_nid_t pin_nid)
 {
 #ifdef BE_PARANOID
 	int i, j;
@@ -340,21 +501,17 @@ static void hdmi_clear_dip_buffers(struc
 }
 
 static void hdmi_fill_audio_infoframe(struct hda_codec *codec,
-					struct hdmi_audio_infoframe *ai)
+				      hda_nid_t pin_nid,
+				      struct hdmi_audio_infoframe *ai)
 {
 	u8 *params = (u8 *)ai;
-	u8 sum = 0;
 	int i;
 
-	hdmi_debug_dip_size(codec);
-	hdmi_clear_dip_buffers(codec); /* be paranoid */
-
-	for (i = 0; i < sizeof(ai); i++)
-		sum += params[i];
-	ai->checksum = - sum;
+	hdmi_debug_dip_size(codec, pin_nid);
+	hdmi_clear_dip_buffers(codec, pin_nid); /* be paranoid */
 
 	hdmi_set_dip_index(codec, pin_nid, 0x0, 0x0);
-	for (i = 0; i < sizeof(ai); i++)
+	for (i = 0; i < sizeof(*ai); i++)
 		hdmi_write_dip_byte(codec, pin_nid, params[i]);
 }
 
@@ -386,11 +543,11 @@ static void init_channel_allocations(voi
  *
  * TODO: it could select the wrong CA from multiple candidates.
 */
-static int hdmi_setup_channel_allocation(struct hda_codec *codec,
+static int hdmi_setup_channel_allocation(struct hda_codec *codec, hda_nid_t nid,
 					 struct hdmi_audio_infoframe *ai)
 {
 	struct intel_hdmi_spec *spec = codec->spec;
-	struct hdmi_eld *eld = &spec->sink_eld;
+	struct hdmi_eld *eld;
 	int i;
 	int spk_mask = 0;
 	int channels = 1 + (ai->CC02_CT47 & 0x7);
@@ -402,6 +559,11 @@ static int hdmi_setup_channel_allocation
 	if (channels <= 2)
 		return 0;
 
+	i = hda_node_index(spec->pin_cvt, nid);
+	if (i < 0)
+		return 0;
+	eld = &spec->sink_eld[i];
+
 	/*
 	 * HDMI sink's ELD info cannot always be retrieved for now, e.g.
 	 * in console or for audio devices. Assume the highest speakers
@@ -439,8 +601,8 @@ static int hdmi_setup_channel_allocation
 	return ai->CA;
 }
 
-static void hdmi_setup_channel_mapping(struct hda_codec *codec,
-					struct hdmi_audio_infoframe *ai)
+static void hdmi_setup_channel_mapping(struct hda_codec *codec, hda_nid_t nid,
+				       struct hdmi_audio_infoframe *ai)
 {
 	int i;
 
@@ -453,17 +615,20 @@ static void hdmi_setup_channel_mapping(s
 	 */
 
 	for (i = 0; i < 8; i++)
-		snd_hda_codec_write(codec, cvt_nid, 0,
+		snd_hda_codec_write(codec, nid, 0,
 				    AC_VERB_SET_HDMI_CHAN_SLOT,
 				    (i << 4) | i);
 
-	hdmi_debug_channel_mapping(codec);
+	hdmi_debug_channel_mapping(codec, nid);
 }
 
 
-static void hdmi_setup_audio_infoframe(struct hda_codec *codec,
+static void hdmi_setup_audio_infoframe(struct hda_codec *codec, hda_nid_t nid,
 					struct snd_pcm_substream *substream)
 {
+	struct intel_hdmi_spec *spec = codec->spec;
+	hda_nid_t pin_nid;
+	int i;
 	struct hdmi_audio_infoframe ai = {
 		.type		= 0x84,
 		.ver		= 0x01,
@@ -471,11 +636,23 @@ static void hdmi_setup_audio_infoframe(s
 		.CC02_CT47	= substream->runtime->channels - 1,
 	};
 
-	hdmi_setup_channel_allocation(codec, &ai);
-	hdmi_setup_channel_mapping(codec, &ai);
+	hdmi_setup_channel_allocation(codec, nid, &ai);
+	hdmi_setup_channel_mapping(codec, nid, &ai);
 
-	hdmi_fill_audio_infoframe(codec, &ai);
-	hdmi_start_infoframe_trans(codec);
+	for (i = 0; i < spec->num_pins; i++) {
+		if (spec->pin_cvt[i] != nid)
+			continue;
+		if (spec->sink_present[i] != true)
+			continue;
+
+		pin_nid = spec->pin[i];
+		if (memcmp(&ai, &spec->ai[i], sizeof(ai))) {
+			hdmi_stop_infoframe_trans(codec, pin_nid);
+			hdmi_fill_audio_infoframe(codec, pin_nid, &ai);
+			hdmi_start_infoframe_trans(codec, pin_nid);
+			spec->ai[i] = ai;
+		}
+	}
 }
 
 
@@ -485,27 +662,39 @@ static void hdmi_setup_audio_infoframe(s
 
 static void hdmi_intrinsic_event(struct hda_codec *codec, unsigned int res)
 {
+	struct intel_hdmi_spec *spec = codec->spec;
+	int tag = res >> AC_UNSOL_RES_TAG_SHIFT;
 	int pind = !!(res & AC_UNSOL_RES_PD);
 	int eldv = !!(res & AC_UNSOL_RES_ELDV);
+	int index;
 
 	printk(KERN_INFO
-		"HDMI hot plug event: Presence_Detect=%d ELD_Valid=%d\n",
-		pind, eldv);
+		"HDMI hot plug event: Pin=%d Presence_Detect=%d ELD_Valid=%d\n",
+		tag, pind, eldv);
+
+	index = hda_node_index(spec->pin, tag);
+	if (index < 0)
+		return;
+
+	spec->sink_present[index] = pind;
+	spec->sink_eldv[index] = eldv;
 
 	if (pind && eldv) {
-		hdmi_parse_eld(codec);
+		hdmi_parse_eld(codec, index);
 		/* TODO: do real things about ELD */
 	}
 }
 
 static void hdmi_non_intrinsic_event(struct hda_codec *codec, unsigned int res)
 {
+	int tag = res >> AC_UNSOL_RES_TAG_SHIFT;
 	int subtag = (res & AC_UNSOL_RES_SUBTAG) >> AC_UNSOL_RES_SUBTAG_SHIFT;
 	int cp_state = !!(res & AC_UNSOL_RES_CP_STATE);
 	int cp_ready = !!(res & AC_UNSOL_RES_CP_READY);
 
 	printk(KERN_INFO
-		"HDMI content protection event: SUBTAG=0x%x CP_STATE=%d CP_READY=%d\n",
+		"HDMI CP event: PIN=%d SUBTAG=0x%x CP_STATE=%d CP_READY=%d\n",
+		tag,
 		subtag,
 		cp_state,
 		cp_ready);
@@ -520,10 +709,11 @@ static void hdmi_non_intrinsic_event(str
 
 static void intel_hdmi_unsol_event(struct hda_codec *codec, unsigned int res)
 {
+	struct intel_hdmi_spec *spec = codec->spec;
 	int tag = res >> AC_UNSOL_RES_TAG_SHIFT;
 	int subtag = (res & AC_UNSOL_RES_SUBTAG) >> AC_UNSOL_RES_SUBTAG_SHIFT;
 
-	if (tag != INTEL_HDMI_EVENT_TAG) {
+	if (hda_node_index(spec->pin, tag) < 0) {
 		snd_printd(KERN_INFO "Unexpected HDMI event tag 0x%x\n", tag);
 		return;
 	}
@@ -538,69 +728,60 @@ static void intel_hdmi_unsol_event(struc
  * Callbacks
  */
 
-static int intel_hdmi_playback_pcm_open(struct hda_pcm_stream *hinfo,
-					struct hda_codec *codec,
-					struct snd_pcm_substream *substream)
-{
-	struct intel_hdmi_spec *spec = codec->spec;
-
-	return snd_hda_multi_out_dig_open(codec, &spec->multiout);
-}
-
-static int intel_hdmi_playback_pcm_close(struct hda_pcm_stream *hinfo,
-					 struct hda_codec *codec,
-					 struct snd_pcm_substream *substream)
-{
-	struct intel_hdmi_spec *spec = codec->spec;
-
-	hdmi_stop_infoframe_trans(codec);
-
-	return snd_hda_multi_out_dig_close(codec, &spec->multiout);
-}
-
 static int intel_hdmi_playback_pcm_prepare(struct hda_pcm_stream *hinfo,
 					   struct hda_codec *codec,
 					   unsigned int stream_tag,
 					   unsigned int format,
 					   struct snd_pcm_substream *substream)
 {
-	struct intel_hdmi_spec *spec = codec->spec;
-
-	snd_hda_multi_out_dig_prepare(codec, &spec->multiout, stream_tag,
-					     format, substream);
+	hdmi_set_channel_count(codec, hinfo->nid,
+			       substream->runtime->channels);
 
-	hdmi_set_channel_count(codec, substream->runtime->channels);
+	hdmi_setup_audio_infoframe(codec, hinfo->nid, substream);
 
-	hdmi_setup_audio_infoframe(codec, substream);
+	snd_hda_codec_setup_stream(codec, hinfo->nid, stream_tag, 0, format);
+	return 0;
+}
 
+static int intel_hdmi_playback_pcm_cleanup(struct hda_pcm_stream *hinfo,
+					   struct hda_codec *codec,
+					   struct snd_pcm_substream *substream)
+{
+	snd_hda_codec_cleanup_stream(codec, hinfo->nid);
 	return 0;
 }
 
 static struct hda_pcm_stream intel_hdmi_pcm_playback = {
 	.substreams = 1,
 	.channels_min = 2,
-	.channels_max = 8,
 	.ops = {
-		.open    = intel_hdmi_playback_pcm_open,
-		.close   = intel_hdmi_playback_pcm_close,
-		.prepare = intel_hdmi_playback_pcm_prepare
+		.prepare = intel_hdmi_playback_pcm_prepare,
+		.cleanup = intel_hdmi_playback_pcm_cleanup,
 	},
 };
 
 static int intel_hdmi_build_pcms(struct hda_codec *codec)
 {
 	struct intel_hdmi_spec *spec = codec->spec;
-	struct hda_pcm *info = &spec->pcm_rec;
+	struct hda_pcm *info = spec->pcm_rec;
+	int i;
 
-	codec->num_pcms = 1;
+	codec->num_pcms = spec->num_cvts;
 	codec->pcm_info = info;
 
-	/* NID to query formats and rates and setup streams */
-	intel_hdmi_pcm_playback.nid = cvt_nid;
+	for (i = 0; i < codec->num_pcms; i++, info++) {
+		unsigned int chans;
 
-	info->name = "INTEL HDMI";
-	info->pcm_type = HDA_PCM_TYPE_HDMI;
-	info->stream[SNDRV_PCM_STREAM_PLAYBACK] = intel_hdmi_pcm_playback;
+		chans = get_wcaps(codec, spec->cvt[i]);
+		chans = get_wcaps_channels(chans);
+
+		info->name = intel_hdmi_pcm_names[i];
+		info->pcm_type = HDA_PCM_TYPE_HDMI;
+		info->stream[SNDRV_PCM_STREAM_PLAYBACK] =
+							intel_hdmi_pcm_playback;
+		info->stream[SNDRV_PCM_STREAM_PLAYBACK].nid = spec->cvt[i];
+		info->stream[SNDRV_PCM_STREAM_PLAYBACK].channels_max = chans;
+	}
 
 	return 0;
 }
@@ -609,29 +790,39 @@ static int intel_hdmi_build_controls(str
 {
 	struct intel_hdmi_spec *spec = codec->spec;
 	int err;
+	int i;
 
-	err = snd_hda_create_spdif_out_ctls(codec, spec->multiout.dig_out_nid);
-	if (err < 0)
-		return err;
+	for (i = 0; i < codec->num_pcms; i++) {
+		err = snd_hda_create_spdif_out_ctls(codec, spec->cvt[i]);
+		if (err < 0)
+			return err;
+	}
 
 	return 0;
 }
 
 static int intel_hdmi_init(struct hda_codec *codec)
 {
-	hdmi_enable_output(codec);
+	struct intel_hdmi_spec *spec = codec->spec;
+	int i;
 
-	snd_hda_codec_write(codec, pin_nid, 0,
-			    AC_VERB_SET_UNSOLICITED_ENABLE,
-			    AC_USRSP_EN | INTEL_HDMI_EVENT_TAG);
+	for (i = 0; spec->pin[i]; i++) {
+		hdmi_enable_output(codec, spec->pin[i]);
+		snd_hda_codec_write(codec, spec->pin[i], 0,
+				    AC_VERB_SET_UNSOLICITED_ENABLE,
+				    AC_USRSP_EN | spec->pin[i]);
+	}
 	return 0;
 }
 
 static void intel_hdmi_free(struct hda_codec *codec)
 {
 	struct intel_hdmi_spec *spec = codec->spec;
+	int i;
+
+	for (i = 0; i < spec->num_pins; i++)
+		snd_hda_eld_proc_free(codec, &spec->sink_eld[i]);
 
-	snd_hda_eld_proc_free(codec, &spec->sink_eld);
 	kfree(spec);
 }
 
@@ -643,22 +834,45 @@ static struct hda_codec_ops intel_hdmi_p
 	.unsol_event		= intel_hdmi_unsol_event,
 };
 
-static int do_patch_intel_hdmi(struct hda_codec *codec)
+static struct intel_hdmi_spec static_specs[] = {
+	{
+		.num_cvts = 1,
+		.num_pins = 1,
+		.cvt	  = { 0x2 },
+		.pin	  = { 0x3 },
+		.pin_cvt  = { 0x2 },
+	},
+	{
+		.num_cvts = 2,
+		.num_pins = 3,
+		.cvt	  = { 0x2, 0x3 },
+		.pin	  = { 0x4, 0x5, 0x6 },
+		.pin_cvt  = { 0x2, 0x2, 0x2 },
+	},
+};
+
+static int do_patch_intel_hdmi(struct hda_codec *codec, int spec_id)
 {
 	struct intel_hdmi_spec *spec;
+	int i;
 
 	spec = kzalloc(sizeof(*spec), GFP_KERNEL);
 	if (spec == NULL)
 		return -ENOMEM;
 
-	spec->multiout.num_dacs = 0;	  /* no analog */
-	spec->multiout.max_channels = 8;
-	spec->multiout.dig_out_nid = cvt_nid;
-
 	codec->spec = spec;
+	if (intel_hdmi_parse_codec(codec) < 0) {
+		codec->spec = NULL;
+		kfree(spec);
+		return -EINVAL;
+	}
+	if (memcmp(spec, static_specs + spec_id, sizeof(*spec)))
+		snd_printk(KERN_WARNING
+			   "HDMI: auto parse disagree with known config\n");
 	codec->patch_ops = intel_hdmi_patch_ops;
 
-	snd_hda_eld_proc_new(codec, &spec->sink_eld);
+	for (i = 0; i < spec->num_pins; i++)
+		snd_hda_eld_proc_new(codec, &spec->sink_eld[i], i);
 
 	init_channel_allocations();
 
@@ -667,16 +881,12 @@ static int do_patch_intel_hdmi(struct hd
 
 static int patch_intel_hdmi(struct hda_codec *codec)
 {
-	cvt_nid = 0x02;
-	pin_nid = 0x03;
-	return do_patch_intel_hdmi(codec);
+	return do_patch_intel_hdmi(codec, 0);
 }
 
 static int patch_intel_hdmi_ibexpeak(struct hda_codec *codec)
 {
-	cvt_nid = 0x02;
-	pin_nid = 0x04;
-	return do_patch_intel_hdmi(codec);
+	return do_patch_intel_hdmi(codec, 1);
 }
 
 static struct hda_codec_preset snd_hda_preset_intelhdmi[] = {
@@ -684,7 +894,7 @@ static struct hda_codec_preset snd_hda_p
 	{ .id = 0x80862801, .name = "G45 DEVBLC", .patch = patch_intel_hdmi },
 	{ .id = 0x80862802, .name = "G45 DEVCTG", .patch = patch_intel_hdmi },
 	{ .id = 0x80862803, .name = "G45 DEVELK", .patch = patch_intel_hdmi },
-	{ .id = 0x80862804, .name = "G45 DEVIBX", .patch = patch_intel_hdmi },
+	{ .id = 0x80862804, .name = "G45 DEVIBX", .patch = patch_intel_hdmi_ibexpeak },
 	{ .id = 0x80860054, .name = "Q57 DEVIBX", .patch = patch_intel_hdmi_ibexpeak },
 	{ .id = 0x10951392, .name = "SiI1392 HDMI",     .patch = patch_intel_hdmi },
 	{} /* terminator */
@@ -718,3 +928,4 @@ static void __exit patch_intelhdmi_exit(
 
 module_init(patch_intelhdmi_init)
 module_exit(patch_intelhdmi_exit)
+
--- sound-2.6.orig/sound/pci/hda/hda_codec.c	2009-10-15 11:16:05.000000000 +0800
+++ sound-2.6/sound/pci/hda/hda_codec.c	2009-10-15 11:16:12.000000000 +0800
@@ -2885,43 +2885,26 @@ static int get_empty_pcm_device(struct h
 	static const char *dev_name[HDA_PCM_NTYPES] = {
 		"Audio", "SPDIF", "HDMI", "Modem"
 	};
-	/* starting device index for each PCM type */
-	static int dev_idx[HDA_PCM_NTYPES] = {
-		[HDA_PCM_TYPE_AUDIO] = 0,
-		[HDA_PCM_TYPE_SPDIF] = 1,
-		[HDA_PCM_TYPE_HDMI] = 3,
-		[HDA_PCM_TYPE_MODEM] = 6
+	/* audio device indices; not linear to keep compatibility */
+	static int audio_idx[HDA_PCM_NTYPES][5] = {
+		[HDA_PCM_TYPE_AUDIO] = { 0, 2, 4, 5, -1 },
+		[HDA_PCM_TYPE_SPDIF] = { 1, -1 },
+		[HDA_PCM_TYPE_HDMI]  = { 3, 7, 8, 9, -1 },
+		[HDA_PCM_TYPE_MODEM] = { 6, -1 },
 	};
-	/* normal audio device indices; not linear to keep compatibility */
-	static int audio_idx[4] = { 0, 2, 4, 5 };
-	int i, dev;
-
-	switch (type) {
-	case HDA_PCM_TYPE_AUDIO:
-		for (i = 0; i < ARRAY_SIZE(audio_idx); i++) {
-			dev = audio_idx[i];
-			if (!test_bit(dev, bus->pcm_dev_bits))
-				goto ok;
-		}
-		snd_printk(KERN_WARNING "Too many audio devices\n");
-		return -EAGAIN;
-	case HDA_PCM_TYPE_SPDIF:
-	case HDA_PCM_TYPE_HDMI:
-	case HDA_PCM_TYPE_MODEM:
-		dev = dev_idx[type];
-		if (test_bit(dev, bus->pcm_dev_bits)) {
-			snd_printk(KERN_WARNING "%s already defined\n",
-				   dev_name[type]);
-			return -EAGAIN;
-		}
-		break;
-	default:
+	int i;
+
+	if (type >= HDA_PCM_NTYPES) {
 		snd_printk(KERN_WARNING "Invalid PCM type %d\n", type);
 		return -EINVAL;
 	}
- ok:
-	set_bit(dev, bus->pcm_dev_bits);
-	return dev;
+
+	for (i = 0; audio_idx[type][i] >= 0 ; i++)
+		if (!test_and_set_bit(audio_idx[type][i], bus->pcm_dev_bits))
+			return audio_idx[type][i];
+
+	snd_printk(KERN_WARNING "Too many %s devices\n", dev_name[type]);
+	return -EAGAIN;
 }
 
 /*
--- sound-2.6.orig/sound/pci/hda/hda_eld.c	2009-10-15 11:16:02.000000000 +0800
+++ sound-2.6/sound/pci/hda/hda_eld.c	2009-10-15 12:35:42.000000000 +0800
@@ -560,13 +560,14 @@ static void hdmi_write_eld_info(struct s
 }
 
 
-int snd_hda_eld_proc_new(struct hda_codec *codec, struct hdmi_eld *eld)
+int snd_hda_eld_proc_new(struct hda_codec *codec, struct hdmi_eld *eld,
+			 int index)
 {
 	char name[32];
 	struct snd_info_entry *entry;
 	int err;
 
-	snprintf(name, sizeof(name), "eld#%d", codec->addr);
+	snprintf(name, sizeof(name), "eld#%d.%d", codec->addr, index);
 	err = snd_card_proc_new(codec->bus->card, name, &entry);
 	if (err < 0)
 		return err;
--- sound-2.6.orig/sound/pci/hda/hda_local.h	2009-10-15 11:16:02.000000000 +0800
+++ sound-2.6/sound/pci/hda/hda_local.h	2009-10-15 12:35:42.000000000 +0800
@@ -541,11 +541,13 @@ int snd_hdmi_get_eld(struct hdmi_eld *, 
 void snd_hdmi_show_eld(struct hdmi_eld *eld);
 
 #ifdef CONFIG_PROC_FS
-int snd_hda_eld_proc_new(struct hda_codec *codec, struct hdmi_eld *eld);
+int snd_hda_eld_proc_new(struct hda_codec *codec, struct hdmi_eld *eld,
+			 int index);
 void snd_hda_eld_proc_free(struct hda_codec *codec, struct hdmi_eld *eld);
 #else
 static inline int snd_hda_eld_proc_new(struct hda_codec *codec,
-				       struct hdmi_eld *eld)
+				       struct hdmi_eld *eld,
+				       int index)
 {
 	return 0;
 }

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard

[Wu Fengguang]

On Fri, Oct 30, 2009 at 06:29:32AM +0800, David Härdeman wrote:
> On Thu, Oct 29, 2009 at 05:46:02PM +0800, Wu Fengguang wrote:
> > I'm not sure why your device can silence even nothing changed with the
> > infoframe. Would you retry the attached patch and post the dmesg? This
> > is just to make things more clear. I'm not against your patch in general.
> 
> dmesg attached...the first and third speaker-test invocation produced 
> audible sound while the second and fourth didn't (the changed infoframe 
> seems to cause the receiver to reset some internal state which kicks it 
> into working).

OK, your device seems to work if there is a switch of infoframe,
ie. coupled with the "HDMI: updating infoframe" message.

Note that the message only happens if the audio infoframe don't match
up with previous one, _or_ the previous one has been wiped out by some
reset operation:

        Data Island Packet Data
        -----------------------
        The contents of this buffer are cleared during function reset
        or HD audio link reset.

Could you try dumping the audio infoframe data at the beginning of
hdmi_switch_infoframe() or hdmi_stop_infoframe_trans(), to check if
the previous content have been reset to 0?

Thanks,
Fengguang
---

Content-Description: intel-hdmi-oct-29.log
> Script started on Thu 29 Oct 2009 11:18:26 PM CET
> scott:~/new8# dmesg -c > /dev/null
> scott:~/new8# speaker-test -c2 -D hdmi -twav -l1
> 
> speaker-test 1.0.20
> 
> Playback device is hdmi
> Stream parameters are 48000Hz, S16_LE, 2 channels
> WAV file(s)
> Rate set to 48000Hz (requested 48000Hz)
> Buffer size range from 64 to 16384
> Period size range from 32 to 8192
> Using max buffer size 16384
> Periods = 4
> was set period_size = 4096
> was set buffer_size = 16384
>  0 - Front Left
>  1 - Front Right
> Time per period = 2.730676
> scott:~/new8# dmesg -c
> [  470.461885] ALSA sound/pci/hda/hda_intel.c:1621: azx_pcm_prepare: bufsize=0x10000, format=0x11
> [  470.461959] HDMI: hdmi_setup_audio_infoframe
> [  470.461961] HDMI: trying to update infoframe
> [  470.462067] infoframe 132 =? 132
> [  470.462110] infoframe 1 =? 1
> [  470.462153] infoframe 10 =? 10
> [  470.462187] infoframe 87 =? 112
> [  470.462188] HDMI: updating infoframe
> [  470.462283] HDMI: ELD buf size is 64
> [  470.462336] HDMI: DIP GP[0] buf size is 13
> [  470.462379] HDMI: DIP GP[1] buf size is 10
> [  470.462422] HDMI: DIP GP[2] buf size is 30
> [  470.462464] HDMI: DIP GP[3] buf size is 30
> [  470.462498] HDMI: DIP GP[4] buf size is 0
> [  470.462551] HDMI: DIP GP[5] buf size is 0
> [  470.462584] HDMI: DIP GP[6] buf size is 0
> [  470.462627] HDMI: DIP GP[7] buf size is 0
> [  470.462644] ALSA sound/pci/hda/hda_codec.c:1083: hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
> [  473.199329] ALSA sound/pci/hda/hda_codec.c:1096: hda_codec_cleanup_stream: NID=0x2
> [  473.199389] ALSA sound/pci/hda/hda_codec.c:1096: hda_codec_cleanup_stream: NID=0x2
> scott:~/new8# speaker-test -c2 -D hdmi -twav -l1
> 
> speaker-test 1.0.20
> 
> Playback device is hdmi
> Stream parameters are 48000Hz, S16_LE, 2 channels
> WAV file(s)
> Rate set to 48000Hz (requested 48000Hz)
> Buffer size range from 64 to 16384
> Period size range from 32 to 8192
> Using max buffer size 16384
> Periods = 4
> was set period_size = 4096
> was set buffer_size = 16384
>  0 - Front Left
>  1 - Front Right
> Time per period = 2.730384
> scott:~/new8# dmesg -c
> [  489.945260] ALSA sound/pci/hda/hda_intel.c:1621: azx_pcm_prepare: bufsize=0x10000, format=0x11
> [  489.945341] HDMI: hdmi_setup_audio_infoframe
> [  489.945342] HDMI: trying to update infoframe
> [  489.945447] infoframe 132 =? 132
> [  489.945489] infoframe 1 =? 1
> [  489.945531] infoframe 10 =? 10
> [  489.945573] infoframe 112 =? 112
> [  489.945614] infoframe 1 =? 1
> [  489.945656] infoframe 0 =? 0
> [  489.945697] infoframe 0 =? 0
> [  489.945739] infoframe 0 =? 0
> [  489.945781] infoframe 0 =? 0
> [  489.945823] infoframe 0 =? 0
> [  489.945864] infoframe 0 =? 0
> [  489.945906] infoframe 0 =? 0
> [  489.945948] infoframe 0 =? 0
> [  489.945989] infoframe 0 =? 0
> [  489.945991] ALSA sound/pci/hda/hda_codec.c:1083: hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
> [  492.682520] ALSA sound/pci/hda/hda_codec.c:1096: hda_codec_cleanup_stream: NID=0x2
> [  492.682584] ALSA sound/pci/hda/hda_codec.c:1096: hda_codec_cleanup_stream: NID=0x2
> scott:~/new8# speaker-test -c8 -D hdmi -twav -l1
> 
> speaker-test 1.0.20
> 
> Playback device is hdmi
> Stream parameters are 48000Hz, S16_LE, 8 channels
> WAV file(s)
> Rate set to 48000Hz (requested 48000Hz)
> Buffer size range from 16 to 4096
> Period size range from 8 to 2048
> Using max buffer size 4096
> Periods = 4
> was set period_size = 1024
> was set buffer_size = 4096
>  0 - Front Left
>  4 - Center
>  1 - Front Right
>  7 - Side Right
>  3 - Rear Right
>  2 - Rear Left
>  6 - Side Left
>  5 - LFE
> Time per period = 11.307268
> scott:~/new8# dmesg -c
> [  540.685870] ALSA sound/pci/hda/hda_intel.c:1621: azx_pcm_prepare: bufsize=0x10000, format=0x17
> [  540.685954] HDMI: hdmi_setup_audio_infoframe
> [  540.685959] ALSA sound/pci/hda/patch_intelhdmi.c:605: HDMI: select CA 0x13 for 8-channel allocation:  FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC FLW/FRW FLH/FRH TC FCH
> [  540.686168] HDMI: ASP channel 0 => slot 0
> [  540.686201] HDMI: ASP channel 0 => slot 0
> [  540.686254] HDMI: ASP channel 0 => slot 0
> [  540.686306] HDMI: ASP channel 0 => slot 0
> [  540.686349] HDMI: ASP channel 0 => slot 0
> [  540.686393] HDMI: ASP channel 0 => slot 0
> [  540.686436] HDMI: ASP channel 0 => slot 0
> [  540.686470] HDMI: ASP channel 0 => slot 0
> [  540.686472] HDMI: trying to update infoframe
> [  540.686586] infoframe 132 =? 132
> [  540.686639] infoframe 1 =? 1
> [  540.686682] infoframe 10 =? 10
> [  540.686726] infoframe 112 =? 87
> [  540.686727] HDMI: updating infoframe
> [  540.686812] HDMI: ELD buf size is 64
> [  540.686844] HDMI: DIP GP[0] buf size is 13
> [  540.686897] HDMI: DIP GP[1] buf size is 10
> [  540.686930] HDMI: DIP GP[2] buf size is 30
> [  540.686973] HDMI: DIP GP[3] buf size is 30
> [  540.687016] HDMI: DIP GP[4] buf size is 0
> [  540.687059] HDMI: DIP GP[5] buf size is 0
> [  540.687093] HDMI: DIP GP[6] buf size is 0
> [  540.687146] HDMI: DIP GP[7] buf size is 0
> [  540.687160] ALSA sound/pci/hda/hda_codec.c:1083: hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x17
> [  551.999466] ALSA sound/pci/hda/hda_codec.c:1096: hda_codec_cleanup_stream: NID=0x2
> [  551.999526] ALSA sound/pci/hda/hda_codec.c:1096: hda_codec_cleanup_stream: NID=0x2
> scott:~/new8# speaker-test -c8 -D hdmi -twav -l1
> 
> speaker-test 1.0.20
> 
> Playback device is hdmi
> Stream parameters are 48000Hz, S16_LE, 8 channels
> WAV file(s)
> Rate set to 48000Hz (requested 48000Hz)
> Buffer size range from 16 to 4096
> Period size range from 8 to 2048
> Using max buffer size 4096
> Periods = 4
> was set period_size = 1024
> was set buffer_size = 4096
>  0 - Front Left
>  4 - Center
>  1 - Front Right
>  7 - Side Right
>  3 - Rear Right
>  2 - Rear Left
>  6 - Side Left
>  5 - LFE
> Time per period = 11.307234
> scott:~/new8# dmesg -c
> [  569.801850] ALSA sound/pci/hda/hda_intel.c:1621: azx_pcm_prepare: bufsize=0x10000, format=0x17
> [  569.801933] HDMI: hdmi_setup_audio_infoframe
> [  569.801939] ALSA sound/pci/hda/patch_intelhdmi.c:605: HDMI: select CA 0x13 for 8-channel allocation:  FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC FLW/FRW FLH/FRH TC FCH
> [  569.802149] HDMI: ASP channel 0 => slot 0
> [  569.802202] HDMI: ASP channel 0 => slot 0
> [  569.802235] HDMI: ASP channel 0 => slot 0
> [  569.802278] HDMI: ASP channel 0 => slot 0
> [  569.802321] HDMI: ASP channel 0 => slot 0
> [  569.802364] HDMI: ASP channel 0 => slot 0
> [  569.802398] HDMI: ASP channel 0 => slot 0
> [  569.802451] HDMI: ASP channel 0 => slot 0
> [  569.802453] HDMI: trying to update infoframe
> [  569.802567] infoframe 132 =? 132
> [  569.802620] infoframe 1 =? 1
> [  569.802673] infoframe 10 =? 10
> [  569.802715] infoframe 87 =? 87
> [  569.802758] infoframe 7 =? 7
> [  569.802801] infoframe 0 =? 0
> [  569.802834] infoframe 0 =? 0
> [  569.802887] infoframe 19 =? 19
> [  569.802920] infoframe 0 =? 0
> [  569.802972] infoframe 0 =? 0
> [  569.803025] infoframe 0 =? 0
> [  569.803068] infoframe 0 =? 0
> [  569.803111] infoframe 0 =? 0
> [  569.803154] infoframe 0 =? 0
> [  569.803156] ALSA sound/pci/hda/hda_codec.c:1083: hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x17
> [  581.115970] ALSA sound/pci/hda/hda_codec.c:1096: hda_codec_cleanup_stream: NID=0x2
> [  581.116033] ALSA sound/pci/hda/hda_codec.c:1096: hda_codec_cleanup_stream: NID=0x2
> scott:~/new8# exit
> exit
> 
> Script done on Thu 29 Oct 2009 11:21:01 PM CET

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard

[Wu Fengguang]

On Thu, Nov 05, 2009 at 05:06:22PM +0800, David Härdeman wrote:
> On Thu, November 5, 2009 08:47, Wu Fengguang wrote:
> > On Thu, Nov 05, 2009 at 08:46:55AM +0800, David wrote:
> >> Currently doing some testing with sticky stream id and format.
> >>
> >> Could you test the attached patch (applies to alsa git repo, without
> >> your patchset) and see if you get the initial 0.5s silence with your
> >> receiver?
> >
> > Yes it worked!
> 
> Worked as in you get no 0.5s of initial silence? Or worked as in you at
> least got some audio and the computer didn't crash? :)

no 0.5s :)

> > However something is broken when
> >
> > CONFIG_SND_HDA_POWER_SAVE=y
> > CONFIG_SND_HDA_POWER_SAVE_DEFAULT=1

In the above config, you need to restart playback within 1s to avoid
losing the first 0.5s samples. (Otherwise power save will kick in.)

> I was kind of expecting my patch to break both power save and
> suspend/resume given that it expects the stream format and id to survive
> from pcm_close to pcm_prepare (which they probably won't if power saving

Don't worry, I fixed that in my implementation :)

> and/or resume/suspend kicks in). Power save also seems to mess up some
> other parts of the driver even without my patch (haven't really looked
> into that yet...power save might be tricky with HDMI from what I've seen
> so far).

Yes, HDMI power save is inherently not possible given that the sink
devices have the more than 1s delays..

> The patch was just a test case to see if it was enough to fix the 0.5s
> silence on receivers which are less picky than mine (it still doesn't fix
> the 0.5s silence on my receiver but it fixes the
> silence-for-the-duration-of-a-track problem).
> 
> Next up, more testing with VCFG when I have more time. I have actually
> tried setting that bit but it didn't change anything. Comments in
> setup_dig_out_stream from hda_codec.c seems to suggest that it's a bit
> more complex than just setting the right bit.

No worry, I guess that's realtek specific problem (spdif_status_reset
is only set by it).

> > Attached is my updated patchset, which includes the sticky
> > stream/infoframe features.
> 
> Thanks, I'll take a look at it as soon as possible.

Thanks,
Fengguang
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard

[Wu Fengguang]

Hi David,

On Tue, Nov 10, 2009 at 06:35:05PM +0800, David Härdeman wrote:
> > On Thu, Nov 05, 2009 at 05:06:22PM +0800, David Härdeman wrote:
> >> On Thu, November 5, 2009 08:47, Wu Fengguang wrote:
> >>>
> >>> Attached is my updated patchset, which includes the sticky
> >>> stream/infoframe features.
> >>
> >> Thanks, I'll take a look at it as soon as possible.
> 
> I've read through the latest set of patches you sent me and also compiled
> a kernel using them. The patches look good and work great (save for the
> fact that I still have a 0.2s silence, but it's still a big improvement).
> I'd be happy to see them go upstream :)

Thank you :)

You mean 0.2s silence, not 0.2s lost of audio samples?
I'd say you have smart ears :) Did you compared the playback over HDMI
vs over legacy audio and feel the silence at start of HDMI stream?

> On a related note, I still think the only way to get a really flawless
> playback on my picky receiver is to implement some kind of "silentstream"
> as mentioned earlier (since then I've also tried messing with VCFG and V,
> but it seems to upset my receiver even more than complete silence since it
> will take even longer to provide sounds once audio starts flowing again).
> 
> Some other drivers seem to support it (though implemented via hardware
> specific means), one example:
> http://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/commit/?id=422ac06b69cfcbfbaa802fdc916d3b87f40eeb41
> 
> Do you think you could ask your colleagues at Intel to explain how they've
> implemented silentstream in the windows driver?

Hmm, I'm not sure if it would be possible. I'll check it.

Thanks,
Fengguang

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard

[Paul Fertser]

Hi,

To all the folks reading this on alsa list, sorry for the offtopic, i hope
pressing 'd' one extra time is "ok" for you.

On Wed, Nov 11, 2009 at 03:05:40PM +0800, Wu Fengguang wrote:
> > Do you think you could ask your colleagues at Intel to explain how they've
> > implemented silentstream in the windows driver?
> 
> Hmm, I'm not sure if it would be possible. I'll check it.

I'm sorry for a silly comment but that sounds so wrong in so many ways that
i just can't resist.

I'm sure you're not lying and that means that Intel internally works in a
really freaking ridiculously strange ineffective way that even bears some
signs of insanity, right?

How on Earth can it be not possible to obtain details about driver
implementation? It can't be unmaintained, therefore there're developers who
understand the codebase and for whom it shouldn't be hard to give a precise
answer. Moreover it's unlikely it's hard to determine the original author
of the feature (using git blame like facilities) and ask him about it. At
least that's how things like that generally work. I can't even imagine how
much a process must be screwed up to not allow that.

Another example about Intel is their WiMax drivers. They've written some (i
assume decent since they were accepted mainline) drivers for their
high-quality wimax chipsets. But to actually use them they require
user-space supplicant (a bit like wpa_supplicant but different enough). And
somehow it happened that the supplicant is binary x86-only (not even
amd64!). At the same time they're working on a binary supplicant for arm
(n810 wimax edition) and at the same time they're working on a "open
source" supplicant.

One less obvious manifistation of "suboptimal" code is the intel's X.org
drivers. For quite some time they relied on video bios in one way or
another instead of doing proper register-level modesetting, of course with
all ill effects attached.  And when i needed to use i915resolution to get
native mode for my laptop panel i felt like i got in some kind of absurdist
tale, and not in a nice way.

I'm sure there's some important reason behind all that but to an outsider
that looks just really frustratingly fucked up.

Wu, thank you personally for all your work and involvment and efforts! And
if you by any chance can forward my mail to some sane PR guys, please do,
it would be nice to understand that things like that are _bad_ PR.

Good luck and happy hacking, Wu :)
-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com