ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio

PATCH In review [email protected] 5 participants 22 messages May 8, 2014 – May 13, 2014 Sound

lore

Share & tools

lore

[email protected]

author

2014-05-08 01:54 UTC #0 lore raw

PATCH 1/1 ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio

From: Libin Yang <[email protected]>

Audio stream is not continuous if using position buffer on Broadwell HDMI audio. Sound is clipped.
Fix this issue by using POS_FIX_LPIB.

Signed-off-by Libin Yang <[email protected]>

---
 sound/pci/hda/hda_intel.c | 1 +
 1 file changed, 1 insertion(+)

sound/pci/hda/hda_intel.c +1 -0

index b540ad7..9cd40c6 100644
@@ -993,6 +993,7 @@ static struct snd_pci_quirk position_fix_list[] = {
 	SND_PCI_QUIRK(0x1565, 0x8218, "Biostar Microtech", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x1849, 0x0888, "775Dual-VSTA", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x8086, 0x2503, "DG965OT AAD63733-203", POS_FIX_LPIB),
+	SND_PCI_QUIRK(0x8086, 0x2010, "Broadwell HDMI audio", POS_FIX_LPIB),
 	{}
 };

Signature · 1 line

1.8.3.2

Takashi Iwai

2014-05-08 05:09 UTC #1 lore raw

At Thu, 8 May 2014 02:03:24 +0800,

Quoted 6 lines · [email protected] wrote:

From: Libin Yang <[email protected]>
Audio stream is not continuous if using position buffer on Broadwell HDMI audio. Sound is clipped.
Fix this issue by using POS_FIX_LPIB.

That's odd. The recent Intel hardware has a wallclock support, so the position should be corrected by that.

In which situation did the problem happen? Did it happen with every application and any period/buffer setup?

Takashi

Quoted 21 lines

Signed-off-by Libin Yang <[email protected]>

---
 sound/pci/hda/hda_intel.c | 1 +
 1 file changed, 1 insertion(+)

sound/pci/hda/hda_intel.c +1 -0

index b540ad7..9cd40c6 100644
@@ -993,6 +993,7 @@ static struct snd_pci_quirk position_fix_list[] = {
 	SND_PCI_QUIRK(0x1565, 0x8218, "Biostar Microtech", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x1849, 0x0888, "775Dual-VSTA", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x8086, 0x2503, "DG965OT AAD63733-203", POS_FIX_LPIB),
+	SND_PCI_QUIRK(0x8086, 0x2010, "Broadwell HDMI audio", POS_FIX_LPIB),
 	{}
 };

Signature · 1 line

1.8.3.2

Yang, Libin

author

2014-05-08 05:48 UTC #2 lore raw

Hi Takashi,

I checked the wallclock counter. The counter is OK. But it failed to correct the position.

This issue happens when we play sound on HDMI audio. We have tried with aplay and paplay.

I have tried the buffer size of 16384, 8192 and 4096 and with the sample rate of 48KHz and 44.1KHz.

Regards,
Libin

Quoted 49 lines

-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Thursday, May 8, 2014 1:09 PM
To: Yang, Libin
Cc: [email protected]; Lin, Mengdong; Pierre-Louis Bossart
Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Thu, 8 May 2014 02:03:24 +0800,
Quoted 6 lines · [email protected] wrote:
From: Libin Yang <[email protected]>
Audio stream is not continuous if using position buffer on Broadwell HDMI audio. Sound is clipped.
Fix this issue by using POS_FIX_LPIB.
That's odd. The recent Intel hardware has a wallclock support, so the position should be corrected by that.
In which situation did the problem happen? Did it happen with every application and any period/buffer setup?
Takashi
Quoted 11 lines
Signed-off-by Libin Yang <[email protected]>
---
 sound/pci/hda/hda_intel.c | 1 +
 1 file changed, 1 insertion(+)
sound/pci/hda/hda_intel.c +0 -0
index b540ad7..9cd40c6 100644
sound/pci/hda/hda_intel.c static struct snd_pci_quirk position_fix_list[] = { · line 995
Quoted 3 lines
sound/pci/hda/hda_intel.c +0 -0
@@ -993,6 +993,7 @@ static struct snd_pci_quirk position_fix_list[] = {
 	SND_PCI_QUIRK(0x1565, 0x8218, "Biostar Microtech", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x1849, 0x0888, "775Dual-VSTA", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x8086, 0x2503, "DG965OT AAD63733-203",
POS_FIX_LPIB),
sound/pci/hda/hda_intel.c static struct snd_pci_quirk position_fix_list[] = { · line 996
Quoted 1 line
sound/pci/hda/hda_intel.c +1 -0
+	SND_PCI_QUIRK(0x8086, 0x2010, "Broadwell HDMI audio",
POS_FIX_LPIB),
Quoted 6 lines
sound/pci/hda/hda_intel.c +0 -1
 	{}
 };
 
--
1.8.3.2

Takashi Iwai

2014-05-08 05:51 UTC #3 lore raw

At Thu, 8 May 2014 05:48:04 +0000,

Quoted 4 lines · Libin

Hi Takashi,
I checked the wallclock counter. The counter is OK. But it failed to correct the position.

So, how wrong the position buffer is? Is the problem intermittent? Please elaborate more.

Takashi

Quoted 57 lines

This issue happens when we play sound on HDMI audio. We have tried with aplay and paplay.
I have tried the buffer size of 16384, 8192 and 4096 and with the sample rate of 48KHz and 44.1KHz.
Regards,
Libin
Quoted 49 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Thursday, May 8, 2014 1:09 PM
To: Yang, Libin
Cc: [email protected]; Lin, Mengdong; Pierre-Louis Bossart
Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Thu, 8 May 2014 02:03:24 +0800,
Quoted 6 lines · [email protected] wrote:
From: Libin Yang <[email protected]>
Audio stream is not continuous if using position buffer on Broadwell HDMI audio. Sound is clipped.
Fix this issue by using POS_FIX_LPIB.
That's odd. The recent Intel hardware has a wallclock support, so the position should be corrected by that.
In which situation did the problem happen? Did it happen with every application and any period/buffer setup?
Takashi
Quoted 11 lines
Signed-off-by Libin Yang <[email protected]>
---
 sound/pci/hda/hda_intel.c | 1 +
 1 file changed, 1 insertion(+)
sound/pci/hda/hda_intel.c +0 -0
index b540ad7..9cd40c6 100644
sound/pci/hda/hda_intel.c static struct snd_pci_quirk position_fix_list[] = { · line 995
Quoted 3 lines
sound/pci/hda/hda_intel.c +0 -0
@@ -993,6 +993,7 @@ static struct snd_pci_quirk position_fix_list[] = {
 	SND_PCI_QUIRK(0x1565, 0x8218, "Biostar Microtech", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x1849, 0x0888, "775Dual-VSTA", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x8086, 0x2503, "DG965OT AAD63733-203",
POS_FIX_LPIB),
sound/pci/hda/hda_intel.c static struct snd_pci_quirk position_fix_list[] = { · line 996
Quoted 1 line
sound/pci/hda/hda_intel.c +1 -0
+	SND_PCI_QUIRK(0x8086, 0x2010, "Broadwell HDMI audio",
POS_FIX_LPIB),
Quoted 6 lines
sound/pci/hda/hda_intel.c +0 -1
 	{}
 };
 
--
1.8.3.2

Yang, Libin

author

2014-05-08 06:14 UTC #4 lore raw

Hi Takashi,

Quoted 11 lines

-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Thursday, May 8, 2014 1:51 PM
To: Yang, Libin
Cc: [email protected]; Lin, Mengdong; Pierre-Louis Bossart
Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Thu, 8 May 2014 05:48:04 +0000,
Quoted 1 line · Libin

Quoted 7 lines

Quoted 3 lines
Hi Takashi,
I checked the wallclock counter. The counter is OK. But it failed to correct
the position.
So, how wrong the position buffer is? Is the problem intermittent? Please elaborate more.

The issue is the position is almost always inaccurate. You will hear there is intermittent noise in the sound. And the sound is played faster than it should be.

The following message is what I got from dmesg:

[ 73.278117] snd_hda_intel 0000:00:03.0: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
[ 73.528575] snd_hda_intel 0000:00:03.0: Unstable LPIB (26240 >= 24064); disabling LPIB delay counting

Do you think the print of wallclk and position information in the function azx_position_ok() is useful to you? If yes, I will add debug code to print the info.

Quoted 63 lines

Takashi
Quoted 1 line
This issue happens when we play sound on HDMI audio. We have tried
with aplay and paplay.
Quoted 2 lines
I have tried the buffer size of 16384, 8192 and 4096 and with the sample
rate of 48KHz and 44.1KHz.
Quoted 54 lines
Regards,
Libin
Quoted 49 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Thursday, May 8, 2014 1:09 PM
To: Yang, Libin
Cc: [email protected]; Lin, Mengdong; Pierre-Louis Bossart
Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Thu, 8 May 2014 02:03:24 +0800,
Quoted 6 lines · [email protected] wrote:
From: Libin Yang <[email protected]>
Audio stream is not continuous if using position buffer on Broadwell HDMI audio. Sound is clipped.
Fix this issue by using POS_FIX_LPIB.
That's odd. The recent Intel hardware has a wallclock support, so the position should be corrected by that.
In which situation did the problem happen? Did it happen with every application and any period/buffer setup?
Takashi
Quoted 11 lines
Signed-off-by Libin Yang <[email protected]>
---
 sound/pci/hda/hda_intel.c | 1 +
 1 file changed, 1 insertion(+)
sound/pci/hda/hda_intel.c +0 -0
index b540ad7..9cd40c6 100644
sound/pci/hda/hda_intel.c static struct snd_pci_quirk position_fix_list[] = { · line 995
Quoted 3 lines
sound/pci/hda/hda_intel.c +0 -0
@@ -993,6 +993,7 @@ static struct snd_pci_quirk position_fix_list[] = {
 	SND_PCI_QUIRK(0x1565, 0x8218, "Biostar Microtech", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x1849, 0x0888, "775Dual-VSTA", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x8086, 0x2503, "DG965OT AAD63733-203",
POS_FIX_LPIB),
sound/pci/hda/hda_intel.c static struct snd_pci_quirk position_fix_list[] = { · line 996
Quoted 1 line
sound/pci/hda/hda_intel.c +1 -0
+	SND_PCI_QUIRK(0x8086, 0x2010, "Broadwell HDMI audio",
POS_FIX_LPIB),
Quoted 6 lines
sound/pci/hda/hda_intel.c +0 -1
 	{}
 };
 
--
1.8.3.2

Regards,
Libin

Takashi Iwai

2014-05-08 06:19 UTC #5 lore raw

At Thu, 8 May 2014 06:13:31 +0000,

Quoted 22 lines · Libin

Hi Takashi,
Quoted 11 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Thursday, May 8, 2014 1:51 PM
To: Yang, Libin
Cc: [email protected]; Lin, Mengdong; Pierre-Louis Bossart
Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Thu, 8 May 2014 05:48:04 +0000,
Quoted 1 line · Libin
Quoted 7 lines
Quoted 3 lines
Hi Takashi,
I checked the wallclock counter. The counter is OK. But it failed to correct
the position.
So, how wrong the position buffer is? Is the problem intermittent? Please elaborate more.

Quoted 8 lines

The issue is the position is almost always inaccurate. You will hear there is intermittent noise in the sound. And the sound is played faster than it should be.
The following message is what I got from dmesg:
[ 73.278117] snd_hda_intel 0000:00:03.0: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
[ 73.528575] snd_hda_intel 0000:00:03.0: Unstable LPIB (26240 >= 24064); disabling LPIB delay counting
Do you think the print of wallclk and position information in the function azx_position_ok() is useful to you? If yes, I will add debug code to print the info.

It'd better to have the raw values of posbuf, lpib and wallclock for further analysis, yes.

BTW, did you try non-snoop mode via snoop=0 option?

Takashi

Quoted 69 lines

Quoted 64 lines
Takashi
Quoted 1 line
This issue happens when we play sound on HDMI audio. We have tried
with aplay and paplay.
Quoted 2 lines
I have tried the buffer size of 16384, 8192 and 4096 and with the sample
rate of 48KHz and 44.1KHz.
Quoted 54 lines
Regards,
Libin
Quoted 49 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Thursday, May 8, 2014 1:09 PM
To: Yang, Libin
Cc: [email protected]; Lin, Mengdong; Pierre-Louis Bossart
Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Thu, 8 May 2014 02:03:24 +0800,
Quoted 6 lines · [email protected] wrote:
From: Libin Yang <[email protected]>
Audio stream is not continuous if using position buffer on Broadwell HDMI audio. Sound is clipped.
Fix this issue by using POS_FIX_LPIB.
That's odd. The recent Intel hardware has a wallclock support, so the position should be corrected by that.
In which situation did the problem happen? Did it happen with every application and any period/buffer setup?
Takashi
Quoted 11 lines
Signed-off-by Libin Yang <[email protected]>
---
 sound/pci/hda/hda_intel.c | 1 +
 1 file changed, 1 insertion(+)
sound/pci/hda/hda_intel.c +0 -0
index b540ad7..9cd40c6 100644
sound/pci/hda/hda_intel.c static struct snd_pci_quirk position_fix_list[] = { · line 995
Quoted 3 lines
sound/pci/hda/hda_intel.c +0 -0
@@ -993,6 +993,7 @@ static struct snd_pci_quirk position_fix_list[] = {
 	SND_PCI_QUIRK(0x1565, 0x8218, "Biostar Microtech", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x1849, 0x0888, "775Dual-VSTA", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x8086, 0x2503, "DG965OT AAD63733-203",
POS_FIX_LPIB),
sound/pci/hda/hda_intel.c static struct snd_pci_quirk position_fix_list[] = { · line 996
Quoted 1 line
sound/pci/hda/hda_intel.c +1 -0
+	SND_PCI_QUIRK(0x8086, 0x2010, "Broadwell HDMI audio",
POS_FIX_LPIB),
Quoted 6 lines
sound/pci/hda/hda_intel.c +0 -1
 	{}
 };
 
--
1.8.3.2
Regards,
Libin

Yang, Libin

author

2014-05-08 06:28 UTC #6 lore raw

Hi Takashi,

Quoted 44 lines

-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Thursday, May 8, 2014 2:20 PM
To: Yang, Libin
Cc: [email protected]; Lin, Mengdong; Pierre-Louis Bossart
Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Thu, 8 May 2014 06:13:31 +0000,
Quoted 16 lines · Libin
Hi Takashi,
Quoted 13 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Thursday, May 8, 2014 1:51 PM
To: Yang, Libin
Cc: [email protected]; Lin, Mengdong; Pierre-Louis Bossart
Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Thu, 8 May 2014 05:48:04 +0000,
Quoted 3 lines · Libin
Hi Takashi,
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
I checked the wallclock counter. The counter is OK. But it failed to correct
the position.
So, how wrong the position buffer is? Is the problem intermittent? Please elaborate more.
The issue is the position is almost always inaccurate. You will hear there is
intermittent noise in the sound. And the sound is played faster than it should be.
Quoted 4 lines
The following message is what I got from dmesg:
[ 73.278117] snd_hda_intel 0000:00:03.0: IRQ timing workaround is
activated for card #0. Suggest a bigger bdl_pos_adj.
Quoted 3 lines
[ 73.528575] snd_hda_intel 0000:00:03.0: Unstable LPIB (26240 >=
24064); disabling LPIB delay counting

Quoted 8 lines

Quoted 1 line
Do you think the print of wallclk and position information in the function
azx_position_ok() is useful to you? If yes, I will add debug code to print the info.
It'd better to have the raw values of posbuf, lpib and wallclock for further analysis, yes.
BTW, did you try non-snoop mode via snoop=0 option?

I haven't tried non-snoop. Do I use modprobe snd-hda-intel snoop=0 to use non-snoop mode?

Quoted 78 lines

Takashi
Quoted 47 lines
Quoted 47 lines
Takashi
Quoted 1 line
This issue happens when we play sound on HDMI audio. We have tried
with aplay and paplay.
Quoted 3 lines
I have tried the buffer size of 16384, 8192 and 4096 and with the sample
rate of 48KHz and 44.1KHz.
Quoted 36 lines
Regards,
Libin
Quoted 32 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Thursday, May 8, 2014 1:09 PM
To: Yang, Libin
Cc: [email protected]; Lin, Mengdong; Pierre-Louis Bossart
Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
Quoted 6 lines · At Thu, 8 May 2014 02:03:24 +0800, [email protected] wrote:
From: Libin Yang <[email protected]>
Audio stream is not continuous if using position buffer on Broadwell HDMI audio. Sound is clipped.
Fix this issue by using POS_FIX_LPIB.
That's odd. The recent Intel hardware has a wallclock support, so the position should be corrected by that.
In which situation did the problem happen? Did it happen with every application and any period/buffer setup?
Takashi
Quoted 6 lines
Signed-off-by Libin Yang <[email protected]>
---
 sound/pci/hda/hda_intel.c | 1 +
 1 file changed, 1 insertion(+)
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
sound/pci/hda/hda_intel.c static struct snd_pci_quirk position_fix_list[]
Quoted 5 lines
(quoted diff) +0 -0
b/sound/pci/hda/hda_intel.c index b540ad7..9cd40c6 100644
sound/pci/hda/hda_intel.c +0 -0
@@ -993,6 +993,7 @@ static struct snd_pci_quirk position_fix_list[]
= {
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
sound/pci/hda/hda_intel.c static struct snd_pci_quirk position_fix_list[] · line 993
Quoted 1 line
sound/pci/hda/hda_intel.c +0 -0
 	SND_PCI_QUIRK(0x1565, 0x8218, "Biostar Microtech",
POS_FIX_LPIB),
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
sound/pci/hda/hda_intel.c static struct snd_pci_quirk position_fix_list[] · line 994
Quoted 1 line
sound/pci/hda/hda_intel.c +0 -0
 	SND_PCI_QUIRK(0x1849, 0x0888, "775Dual-VSTA",
POS_FIX_LPIB),
Quoted 16 lines
Quoted 11 lines
Quoted 11 lines
Quoted 10 lines
sound/pci/hda/hda_intel.c static struct snd_pci_quirk position_fix_list[] · line 995
Quoted 1 line
sound/pci/hda/hda_intel.c +0 -0
 	SND_PCI_QUIRK(0x8086, 0x2503, "DG965OT AAD63733-203",
POS_FIX_LPIB),
sound/pci/hda/hda_intel.c static struct snd_pci_quirk position_fix_list[] · line 996
Quoted 1 line
sound/pci/hda/hda_intel.c +1 -0
+	SND_PCI_QUIRK(0x8086, 0x2010, "Broadwell HDMI audio",
POS_FIX_LPIB),
Quoted 6 lines
sound/pci/hda/hda_intel.c +0 -1
 	{}
 };
 
--
1.8.3.2
Regards,
Libin

Takashi Iwai

2014-05-08 06:39 UTC #7 lore raw

At Thu, 8 May 2014 06:28:17 +0000,

Quoted 51 lines · Libin

Hi Takashi,
Quoted 48 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Thursday, May 8, 2014 2:20 PM
To: Yang, Libin
Cc: [email protected]; Lin, Mengdong; Pierre-Louis Bossart
Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Thu, 8 May 2014 06:13:31 +0000,
Quoted 16 lines · Libin
Hi Takashi,
Quoted 13 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Thursday, May 8, 2014 1:51 PM
To: Yang, Libin
Cc: [email protected]; Lin, Mengdong; Pierre-Louis Bossart
Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Thu, 8 May 2014 05:48:04 +0000,
Quoted 3 lines · Libin
Hi Takashi,
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
I checked the wallclock counter. The counter is OK. But it failed to correct
the position.
So, how wrong the position buffer is? Is the problem intermittent? Please elaborate more.
The issue is the position is almost always inaccurate. You will hear there is
intermittent noise in the sound. And the sound is played faster than it should be.
Quoted 4 lines
The following message is what I got from dmesg:
[ 73.278117] snd_hda_intel 0000:00:03.0: IRQ timing workaround is
activated for card #0. Suggest a bigger bdl_pos_adj.
Quoted 4 lines
[ 73.528575] snd_hda_intel 0000:00:03.0: Unstable LPIB (26240 >=
24064); disabling LPIB delay counting
Do you think the print of wallclk and position information in the function
azx_position_ok() is useful to you? If yes, I will add debug code to print the info.

Quoted 6 lines

Quoted 4 lines
It'd better to have the raw values of posbuf, lpib and wallclock for further analysis, yes.
BTW, did you try non-snoop mode via snoop=0 option?
I haven't tried non-snoop. Do I use modprobe snd-hda-intel snoop=0 to use non-snoop mode?

Yes.

Takashi

Yang, Libin

author

2014-05-08 07:58 UTC #8 lore raw

Hi Takashi,

I tested the non-snoop mode. It's worse than snoop mode. Only noise can be heard if using non-snoop mode.

I add the print in the function azx_position_ok(). The below is the dmesg:

[  119.509631] <0>posbuf: 26368, lpib: 16320, wallclk: 2330325
[  119.509674] snd_hda_intel 0000:00:03.0: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
[  119.509683] <0>posbuf: 26368, lpib: 16332, wallclk: 2331659
[  119.515467] <0>posbuf: 28224, lpib: 17444, wallclk: 2470504
[  119.523460] <0>posbuf: 30592, lpib: 18976, wallclk: 2662403
[  119.531431] <0>posbuf: 32128, lpib: 20508, wallclk: 2853751
[  119.594932] snd_hda_intel 0000:00:03.0: Unstable LPIB (20416 >= 16384); disabling LPIB delay counting
[  119.594940] <0>posbuf: 53120, lpib: 32708, wallclk: 4378574
[  119.680236] <0>posbuf: 14144, lpib: 49088, wallclk: 6426353
[  119.680268] <0>posbuf: 14208, lpib: 49096, wallclk: 6427176
[  119.687378] <0>posbuf: 15552, lpib: 50460, wallclk: 6597848
[  119.695391] <0>posbuf: 19776, lpib: 52000, wallclk: 6790194
[  119.765532] <0>posbuf: 42816, lpib: 65472, wallclk: 8474222
[  119.765558] <0>posbuf: 42880, lpib: 65476, wallclk: 8474886
[  119.771373] <0>posbuf: 43968, lpib: 1056, wallclk: 8614451
[  119.779343] <0>posbuf: 45824, lpib: 2588, wallclk: 8805772
[  119.787383] <0>posbuf: 63168, lpib: 4132, wallclk: 8998804
[  119.795365] <0>posbuf: 65472, lpib: 5664, wallclk: 9190453
[  119.803355] <0>posbuf: 1472, lpib: 7200, wallclk: 9382317
[  119.936141] <0>posbuf: 41272, lpib: 32704, wallclk: 12570283
[  120.021440] <0>posbuf: 1600, lpib: 49088, wallclk: 14618206
[  120.106744] <0>posbuf: 35584, lpib: 65472, wallclk: 16666259
[  120.192049] <0>posbuf: 59520, lpib: 16320, wallclk: 18714292
[  120.192083] <0>posbuf: 59584, lpib: 16328, wallclk: 18715146
[  120.199208] <0>posbuf: 60928, lpib: 17696, wallclk: 18886244
[  120.207186] <0>posbuf: 63360, lpib: 19228, wallclk: 19077747
[  120.215205] <0>posbuf: 64896, lpib: 20768, wallclk: 19270235
[  120.277352] <0>posbuf: 17472, lpib: 32704, wallclk: 20762304
[  120.362649] <0>posbuf: 51200, lpib: 49088, wallclk: 22810207
[  120.447951] <0>posbuf: 24128, lpib: 65472, wallclk: 24858211
[  120.533254] <0>posbuf: 50240, lpib: 16320, wallclk: 26906204
[  120.618557] <0>posbuf: 7872, lpib: 32704, wallclk: 28954206
[  120.703866] <0>posbuf: 34304, lpib: 49088, wallclk: 31002327
[  120.789162] <0>posbuf: 57216, lpib: 65472, wallclk: 33050211
[  120.874466] <0>posbuf: 21696, lpib: 16320, wallclk: 35098213
[  120.959775] <0>posbuf: 40896, lpib: 32704, wallclk: 37146356
[  121.045071] <0>posbuf: 65512, lpib: 49088, wallclk: 39194209
[  121.045105] <0>posbuf: 65512, lpib: 49096, wallclk: 39195098
[  121.050904] <0>posbuf: 1088, lpib: 50208, wallclk: 39334239
[  121.130373] <0>posbuf: 25672, lpib: 65472, wallclk: 41242241
[  121.130393] <0>posbuf: 25736, lpib: 65476, wallclk: 41242756
[  121.134894] <0>posbuf: 26568, lpib: 804, wallclk: 41350761
[  121.142891] <0>posbuf: 28104, lpib: 2340, wallclk: 41542772
[  121.150843] <0>posbuf: 29640, lpib: 3868, wallclk: 41733690
[  121.158872] <0>posbuf: 31816, lpib: 5408, wallclk: 41926445
[  121.300979] <0>posbuf: 5184, lpib: 32704, wallclk: 45338238
[  121.386301] <0>posbuf: 39616, lpib: 49092, wallclk: 47386704
[  121.471582] <0>posbuf: 63168, lpib: 65472, wallclk: 49434209
[  121.471617] <0>posbuf: 63232, lpib: 65480, wallclk: 49435075
[  121.478756] <0>posbuf: 1152, lpib: 1312, wallclk: 49606462
[  121.556891] <0>posbuf: 25408, lpib: 16320, wallclk: 51482305
[  121.556926] <0>posbuf: 25472, lpib: 16328, wallclk: 51483213
[  121.562750] <0>posbuf: 26560, lpib: 17448, wallclk: 51623001
[  121.570720] <0>posbuf: 28096, lpib: 18976, wallclk: 51814375
[  121.578734] <0>posbuf: 32128, lpib: 20516, wallclk: 52006750
[  121.586740] <0>posbuf: 33664, lpib: 22052, wallclk: 52198989
[  121.727492] <0>posbuf: 4032, lpib: 49088, wallclk: 55578261
[  121.812793] <0>posbuf: 33600, lpib: 65472, wallclk: 57626206
[  121.898104] <0>posbuf: 61632, lpib: 16320, wallclk: 59674370
[  121.898141] <0>posbuf: 61632, lpib: 16328, wallclk: 59675331
[  121.902593] <0>posbuf: 62464, lpib: 17184, wallclk: 59782193
[  121.910606] <0>posbuf: 2816, lpib: 18724, wallclk: 59974590
[  121.983404] <0>posbuf: 28096, lpib: 32704, wallclk: 61722303
[  121.983445] <0>posbuf: 28096, lpib: 32712, wallclk: 61723274
[  121.990560] <0>posbuf: 29504, lpib: 34080, wallclk: 61894156
[  121.998546] <0>posbuf: 34624, lpib: 35612, wallclk: 62085935
[  122.068702] <0>posbuf: 49600, lpib: 49088, wallclk: 63770204
[  122.154009] <0>posbuf: 15488, lpib: 65472, wallclk: 65818332
[  122.154046] <0>posbuf: 15552, lpib: 65480, wallclk: 65819256
[  122.158520] <0>posbuf: 16384, lpib: 804, wallclk: 65926628
[  122.239309] <0>posbuf: 45760, lpib: 16320, wallclk: 67866282
[  122.239331] <0>posbuf: 45760, lpib: 16324, wallclk: 67866855
[  122.246459] <0>posbuf: 47168, lpib: 17692, wallclk: 68037996
[  122.254452] <0>posbuf: 52480, lpib: 19228, wallclk: 68229867
[  122.324608] <0>posbuf: 16192, lpib: 32704, wallclk: 69914215
[  122.324644] <0>posbuf: 16256, lpib: 32712, wallclk: 69915098
[  122.330453] <0>posbuf: 19264, lpib: 33828, wallclk: 70054572
[  122.409916] <0>posbuf: 47744, lpib: 49088, wallclk: 71962318
[  122.409950] <0>posbuf: 47808, lpib: 49096, wallclk: 71963172
[  122.414421] <0>posbuf: 48640, lpib: 49952, wallclk: 72070480
[  122.422413] <0>posbuf: 50496, lpib: 51488, wallclk: 72262373
[  122.495215] <0>posbuf: 4544, lpib: 65472, wallclk: 74010232
[  122.580516] <0>posbuf: 30144, lpib: 16320, wallclk: 76058218
[  122.580549] <0>posbuf: 30144, lpib: 16328, wallclk: 76059056
[  122.586330] <0>posbuf: 31296, lpib: 17436, wallclk: 76197834
[  122.594354] <0>posbuf: 34304, lpib: 18976, wallclk: 76390435
[  122.665824] <0>posbuf: 48000, lpib: 32704, wallclk: 78106302
[  122.665859] <0>posbuf: 48064, lpib: 32712, wallclk: 78107204
[  122.670317] <0>posbuf: 49152, lpib: 33568, wallclk: 78214218
[  122.751125] <0>posbuf: 10368, lpib: 49088, wallclk: 80154285
[  122.751157] <0>posbuf: 10432, lpib: 49096, wallclk: 80155098
[  122.758292] <0>posbuf: 11776, lpib: 50464, wallclk: 80326335
[  122.766288] <0>posbuf: 13312, lpib: 52000, wallclk: 80518371
[  122.774277] <0>posbuf: 15616, lpib: 53536, wallclk: 80710186
[  122.782262] <0>posbuf: 17152, lpib: 55068, wallclk: 80901852
[  122.921726] <0>posbuf: 55680, lpib: 16320, wallclk: 84250213
[  123.007035] <0>posbuf: 20928, lpib: 32704, wallclk: 86298342
[  123.092332] <0>posbuf: 45824, lpib: 49088, wallclk: 88346236
[  123.092347] <0>posbuf: 45824, lpib: 49092, wallclk: 88346635
[  123.098155] <0>posbuf: 48512, lpib: 50208, wallclk: 88486077
[  123.106141] <0>posbuf: 50048, lpib: 51740, wallclk: 88677794
[  123.177633] <0>posbuf: 12928, lpib: 65472, wallclk: 90394202
[  123.177664] <0>posbuf: 12928, lpib: 65476, wallclk: 90394982
[  123.182132] <0>posbuf: 13824, lpib: 800, wallclk: 90502214
[  123.190135] <0>posbuf: 15360, lpib: 2336, wallclk: 90694383
[  123.198168] <0>posbuf: 22400, lpib: 3880, wallclk: 90887194
[  123.262941] <0>posbuf: 41152, lpib: 16320, wallclk: 92442299
[  123.262975] <0>posbuf: 41152, lpib: 16328, wallclk: 92443159
[  123.270098] <0>posbuf: 46080, lpib: 17696, wallclk: 92614190
[  123.278088] <0>posbuf: 53120, lpib: 19232, wallclk: 92806002
[  123.348238] <0>posbuf: 7808, lpib: 32704, wallclk: 94490195
[  123.433540] <0>posbuf: 41664, lpib: 49088, wallclk: 96538196
[  123.433574] <0>posbuf: 41728, lpib: 49096, wallclk: 96539044
[  123.438020] <0>posbuf: 42560, lpib: 49948, wallclk: 96645775
[  123.446056] <0>posbuf: 44096, lpib: 51492, wallclk: 96838682
[  123.454017] <0>posbuf: 45632, lpib: 53020, wallclk: 97029796
[  123.462035] <0>posbuf: 49536, lpib: 54560, wallclk: 97222323
[  123.604151] <0>posbuf: 26624, lpib: 16320, wallclk: 100634303

The aplay output is:
Playing WAVE '/home/younglee/wavs/48KHz.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo Plug PCM: Hardware PCM card 0 'HDA Intel HDMI' device 7 subdevice 0
Its setup is:

  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 16384
  period_size  : 4096
  period_time  : 85333
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 4096
  period_event : 0
  start_threshold  : 16384
  stop_threshold   : 16384
  silence_threshold: 0
  silence_size : 0
  boundary     : 4611686018427387904
  appl_ptr     : 0
  hw_ptr       : 0

Aborted by signal Interrupt...

Regards,
Libin

Quoted 74 lines

-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Thursday, May 8, 2014 2:40 PM
To: Yang, Libin
Cc: [email protected]; Lin, Mengdong; Pierre-Louis Bossart
Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Thu, 8 May 2014 06:28:17 +0000,
Quoted 53 lines · Libin
Hi Takashi,
Quoted 50 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Thursday, May 8, 2014 2:20 PM
To: Yang, Libin
Cc: [email protected]; Lin, Mengdong; Pierre-Louis Bossart
Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Thu, 8 May 2014 06:13:31 +0000,
Quoted 18 lines · Libin
Hi Takashi,
Quoted 15 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Thursday, May 8, 2014 1:51 PM
To: Yang, Libin
Cc: [email protected]; Lin, Mengdong; Pierre-Louis Bossart
Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
Quoted 5 lines · Libin
Hi Takashi,
I checked the wallclock counter. The counter is OK. But it failed to correct
Quoted 7 lines
Quoted 4 lines
the position.
So, how wrong the position buffer is? Is the problem intermittent? Please elaborate more.
The issue is the position is almost always inaccurate. You will hear there is
intermittent noise in the sound. And the sound is played faster than it should be.
Quoted 4 lines
The following message is what I got from dmesg:
[ 73.278117] snd_hda_intel 0000:00:03.0: IRQ timing workaround is
activated for card #0. Suggest a bigger bdl_pos_adj.
Quoted 5 lines
[ 73.528575] snd_hda_intel 0000:00:03.0: Unstable LPIB (26240 >=
24064); disabling LPIB delay counting
Do you think the print of wallclk and position information in the function
azx_position_ok() is useful to you? If yes, I will add debug code to print the info.
Quoted 6 lines
Quoted 4 lines
It'd better to have the raw values of posbuf, lpib and wallclock for further analysis, yes.
BTW, did you try non-snoop mode via snoop=0 option?
I haven't tried non-snoop. Do I use modprobe snd-hda-intel snoop=0 to
use non-snoop mode?
Yes.
Takashi

David Henningsson

2014-05-08 16:06 UTC #9 lore raw

Quoted 4 lines · Libin

Hi Takashi,
I tested the non-snoop mode. It's worse than snoop mode. Only noise can be heard if using non-snoop mode.

Quoted 8 lines

I add the print in the function azx_position_ok(). The below is the dmesg:

[  119.509631] <0>posbuf: 26368, lpib: 16320, wallclk: 2330325
[  119.509674] snd_hda_intel 0000:00:03.0: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
[  119.509683] <0>posbuf: 26368, lpib: 16332, wallclk: 2331659
[  119.515467] <0>posbuf: 28224, lpib: 17444, wallclk: 2470504
[  119.523460] <0>posbuf: 30592, lpib: 18976, wallclk: 2662403
[  119.531431] <0>posbuf: 32128, lpib: 20508, wallclk: 2853751
[  119.594932] snd_hda_intel 0000:00:03.0: Unstable LPIB (20416 >= 16384); disabling LPIB delay counting

This looks quite bad - is it not a hardware bug if LPIB > CBL (CBL should be 16384 in this case)?

Signature · 2 lines

David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Lin, Mengdong

2014-05-09 10:09 UTC #10 lore raw

Hi,

We found the Broadwell HDMI audio regression is introduced by this patch:

commit dcb32ecd9a533f47ab652c5c5680bc50a7a822cd
Author: Anssi Hannula <[email protected]>
Date: Tue Apr 8 12:36:42 2014 +0300
ALSA: hda - Do not assign streams in reverse order

We'll further check the root cause.
Since this patch seems only affect the stream ID. Actually Intel GPU tool only find the stream ID is changed by this patch.

In addition, Haswell HDMI audio is not affected and works well. It seems there is HW behavior difference between HSW and BDW.

Thanks
Mengdong

Quoted 34 lines

-----Original Message-----
From: David Henningsson [mailto:[email protected]]
Sent: Friday, May 09, 2014 12:06 AM
To: Yang, Libin; Takashi Iwai
Cc: Lin, Mengdong; [email protected]; Pierre-Louis Bossart
Subject: Re: [alsa-devel] [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
Quoted 3 lines · Libin
Hi Takashi,
I tested the non-snoop mode. It's worse than snoop mode. Only noise can be
heard if using non-snoop mode.
Quoted 4 lines
I add the print in the function azx_position_ok(). The below is the dmesg:
[  119.509631] <0>posbuf: 26368, lpib: 16320, wallclk: 2330325 [
119.509674] snd_hda_intel 0000:00:03.0: IRQ timing workaround is
activated for card #0. Suggest a bigger bdl_pos_adj.
Quoted 6 lines
[  119.509683] <0>posbuf: 26368, lpib: 16332, wallclk: 2331659 [
119.515467] <0>posbuf: 28224, lpib: 17444, wallclk: 2470504 [ 119.523460] <0>posbuf: 30592, lpib: 18976, wallclk: 2662403 [ 119.531431] <0>posbuf: 32128, lpib: 20508, wallclk: 2853751 [ 119.594932] snd_hda_intel 0000:00:03.0: Unstable LPIB (20416 >= 16384); disabling LPIB delay counting
This looks quite bad - is it not a hardware bug if LPIB > CBL (CBL should be 16384 in this case)?
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Takashi Iwai

2014-05-09 10:20 UTC #11 lore raw

At Fri, 9 May 2014 10:08:19 +0000,

Quoted 10 lines · Mengdong

Hi,
We found the Broadwell HDMI audio regression is introduced by this patch:
commit dcb32ecd9a533f47ab652c5c5680bc50a7a822cd
Author: Anssi Hannula <[email protected]>
Date: Tue Apr 8 12:36:42 2014 +0300
ALSA: hda - Do not assign streams in reverse order

Quoted 4 lines

We'll further check the root cause.
Since this patch seems only affect the stream ID. Actually Intel GPU tool only find the stream ID is changed by this patch.
In addition, Haswell HDMI audio is not affected and works well. It seems there is HW behavior difference between HSW and BDW.

Thanks for spotting out!

This sounds like a weird hardware bug of BDW. If any, we'd need to introduce a flag indicating flipping this lookup behavior depending on the chip.

Takashi

Quoted 39 lines

Thanks
Mengdong
Quoted 34 lines
-----Original Message-----
From: David Henningsson [mailto:[email protected]]
Sent: Friday, May 09, 2014 12:06 AM
To: Yang, Libin; Takashi Iwai
Cc: Lin, Mengdong; [email protected]; Pierre-Louis Bossart
Subject: Re: [alsa-devel] [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
Quoted 3 lines · Libin
Hi Takashi,
I tested the non-snoop mode. It's worse than snoop mode. Only noise can be
heard if using non-snoop mode.
Quoted 4 lines
I add the print in the function azx_position_ok(). The below is the dmesg:
[  119.509631] <0>posbuf: 26368, lpib: 16320, wallclk: 2330325 [
119.509674] snd_hda_intel 0000:00:03.0: IRQ timing workaround is
activated for card #0. Suggest a bigger bdl_pos_adj.
Quoted 6 lines
[  119.509683] <0>posbuf: 26368, lpib: 16332, wallclk: 2331659 [
119.515467] <0>posbuf: 28224, lpib: 17444, wallclk: 2470504 [ 119.523460] <0>posbuf: 30592, lpib: 18976, wallclk: 2662403 [ 119.531431] <0>posbuf: 32128, lpib: 20508, wallclk: 2853751 [ 119.594932] snd_hda_intel 0000:00:03.0: Unstable LPIB (20416 >= 16384); disabling LPIB delay counting
This looks quite bad - is it not a hardware bug if LPIB > CBL (CBL should be 16384 in this case)?
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Lin, Mengdong

2014-05-12 08:28 UTC #12 lore raw

Quoted 25 lines

-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Friday, May 09, 2014 6:20 PM
To: Lin, Mengdong
Cc: David Henningsson; Yang, Libin; [email protected]; [email protected]; Pierre-Louis Bossart
Subject: Re: [alsa-devel] [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Fri, 9 May 2014 10:08:19 +0000,
Quoted 5 lines · Mengdong
Hi,
We found the Broadwell HDMI audio regression is introduced by this patch:
Quoted 7 lines
commit dcb32ecd9a533f47ab652c5c5680bc50a7a822cd
Author: Anssi Hannula <[email protected]>
Date: Tue Apr 8 12:36:42 2014 +0300
ALSA: hda - Do not assign streams in reverse order
We'll further check the root cause.
Since this patch seems only affect the stream ID. Actually Intel GPU tool only
find the stream ID is changed by this patch.
Quoted 1 line

Quoted 7 lines

Quoted 1 line
In addition, Haswell HDMI audio is not affected and works well. It seems
there is HW behavior difference between HSW and BDW.
Thanks for spotting out!
This sounds like a weird hardware bug of BDW. If any, we'd need to introduce a flag indicating flipping this lookup behavior depending on the chip.

In the display HD-A controller of HSW/BDW, there are 3 sets of stream descriptors registers which controls the DMA engines to transfer audio data over HD-A link:
set #0: 0x80 ~ 0x9c SD0CTL ~ SD0BDPU
set #1: 0xa0 ~ 0xbc SD1CTL ~ SD1BDPU
set #2: 0xc0 ~ 0xdc SD2CTL ~ SD2BDPU

Test shows that
On HSW, DMA update on all 3 sets of registers are okay.
On BDW, DMA update on set #1 and #2 are okay, but is buggy on set #0. Since the three sets of registers have the same definition according to spec and driver behavior is also same, it seems to be a HW issue.

Maybe we'll have to use the original reverse lookup order for BDW HDMI/DP audio.

Thanks
Mengdong

Takashi Iwai

2014-05-12 08:31 UTC #13 lore raw

At Mon, 12 May 2014 08:22:13 +0000,

Quoted 39 lines · Mengdong

Quoted 26 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Friday, May 09, 2014 6:20 PM
To: Lin, Mengdong
Cc: David Henningsson; Yang, Libin; [email protected]; [email protected]; Pierre-Louis Bossart
Subject: Re: [alsa-devel] [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Fri, 9 May 2014 10:08:19 +0000,
Quoted 5 lines · Mengdong
Hi,
We found the Broadwell HDMI audio regression is introduced by this patch:
Quoted 7 lines
commit dcb32ecd9a533f47ab652c5c5680bc50a7a822cd
Author: Anssi Hannula <[email protected]>
Date: Tue Apr 8 12:36:42 2014 +0300
ALSA: hda - Do not assign streams in reverse order
We'll further check the root cause.
Since this patch seems only affect the stream ID. Actually Intel GPU tool only
find the stream ID is changed by this patch.
Quoted 1 line
Quoted 7 lines
Quoted 1 line
In addition, Haswell HDMI audio is not affected and works well. It seems
there is HW behavior difference between HSW and BDW.
Thanks for spotting out!
This sounds like a weird hardware bug of BDW. If any, we'd need to introduce a flag indicating flipping this lookup behavior depending on the chip.
In the display HD-A controller of HSW/BDW, there are 3 sets of stream descriptors registers which controls the DMA engines to transfer audio data over HD-A link:
set #0: 0x80 ~ 0x9c SD0CTL ~ SD0BDPU
set #1: 0xa0 ~ 0xbc SD1CTL ~ SD1BDPU
set #2: 0xc0 ~ 0xdc SD2CTL ~ SD2BDPU

Quoted 5 lines

Test shows that
On HSW, DMA update on all 3 sets of registers are okay.
On BDW, DMA update on set #1 and #2 are okay, but is buggy on set #0. Since the three sets of registers have the same definition according to spec and driver behavior is also same, it seems to be a HW issue.
Maybe we'll have to use the original reverse lookup order for BDW HDMI/DP audio.

I wonder what if you run three streams. Is the set#0 always broken, or broken only when used alone? In the former case, the fix would to mask the first slot. In the latter case, back to reverse assignment would work around it.

Takashi

Lin, Mengdong

2014-05-12 09:46 UTC #14 lore raw

Quoted 62 lines

-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Monday, May 12, 2014 4:31 PM
To: Lin, Mengdong
Cc: David Henningsson; Yang, Libin; [email protected]; [email protected]; Pierre-Louis Bossart
Subject: Re: [alsa-devel] [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Mon, 12 May 2014 08:22:13 +0000,
Quoted 10 lines · Mengdong
Quoted 10 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Friday, May 09, 2014 6:20 PM
To: Lin, Mengdong
Cc: David Henningsson; Yang, Libin; [email protected]; [email protected]; Pierre-Louis Bossart
Subject: Re: [alsa-devel] [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
Quoted 6 lines
Quoted 6 lines
At Fri, 9 May 2014 10:08:19 +0000,
Quoted 4 lines · Mengdong
Hi,
We found the Broadwell HDMI audio regression is introduced by this
patch:
Quoted 11 lines
Quoted 11 lines
Quoted 9 lines
commit dcb32ecd9a533f47ab652c5c5680bc50a7a822cd
Author: Anssi Hannula <[email protected]>
Date: Tue Apr 8 12:36:42 2014 +0300
ALSA: hda - Do not assign streams in reverse order
We'll further check the root cause.
Since this patch seems only affect the stream ID. Actually Intel GPU tool only
find the stream ID is changed by this patch.
Quoted 1 line
Quoted 8 lines
Quoted 8 lines
Quoted 2 lines
In addition, Haswell HDMI audio is not affected and works well. It seems
there is HW behavior difference between HSW and BDW.
Thanks for spotting out!
This sounds like a weird hardware bug of BDW. If any, we'd need to introduce a flag indicating flipping this lookup behavior depending on the
chip.
Quoted 2 lines
In the display HD-A controller of HSW/BDW, there are 3 sets of stream
descriptors registers which controls the DMA engines to transfer audio data over HD-A link:
Quoted 7 lines
set #0: 0x80 ~ 0x9c SD0CTL ~ SD0BDPU
set #1: 0xa0 ~ 0xbc SD1CTL ~ SD1BDPU
set #2: 0xc0 ~ 0xdc SD2CTL ~ SD2BDPU
Test shows that
On HSW, DMA update on all 3 sets of registers are okay.
On BDW, DMA update on set #1 and #2 are okay, but is buggy on set #0.
Since the three sets of registers have the same definition according to spec and driver behavior is also same, it seems to be a HW issue.
Quoted 1 line

Quoted 6 lines

Quoted 1 line
Maybe we'll have to use the original reverse lookup order for BDW HDMI/DP
audio.
I wonder what if you run three streams. Is the set#0 always broken, or broken only when used alone? In the former case, the fix would to mask the first slot. In the latter case, back to reverse assignment would work around it.

The set#0 is always broken, when I run single or two streams at the same time.
And when running two streams, there is no difference if the audio driver choose set#0 or #1 at first.

Is it okay to introduce a flag "disabled" to struct azx_dev? If this flag is set, the azx_dev slot is masked.

Thanks
Mengdong

Takashi Iwai

2014-05-12 09:51 UTC #15 lore raw

At Mon, 12 May 2014 09:46:07 +0000,

Quoted 70 lines · Mengdong

Quoted 63 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Monday, May 12, 2014 4:31 PM
To: Lin, Mengdong
Cc: David Henningsson; Yang, Libin; [email protected]; [email protected]; Pierre-Louis Bossart
Subject: Re: [alsa-devel] [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Mon, 12 May 2014 08:22:13 +0000,
Quoted 10 lines · Mengdong
Quoted 10 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Friday, May 09, 2014 6:20 PM
To: Lin, Mengdong
Cc: David Henningsson; Yang, Libin; [email protected]; [email protected]; Pierre-Louis Bossart
Subject: Re: [alsa-devel] [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
Quoted 6 lines
Quoted 6 lines
At Fri, 9 May 2014 10:08:19 +0000,
Quoted 4 lines · Mengdong
Hi,
We found the Broadwell HDMI audio regression is introduced by this
patch:
Quoted 11 lines
Quoted 11 lines
Quoted 9 lines
commit dcb32ecd9a533f47ab652c5c5680bc50a7a822cd
Author: Anssi Hannula <[email protected]>
Date: Tue Apr 8 12:36:42 2014 +0300
ALSA: hda - Do not assign streams in reverse order
We'll further check the root cause.
Since this patch seems only affect the stream ID. Actually Intel GPU tool only
find the stream ID is changed by this patch.
Quoted 1 line
Quoted 8 lines
Quoted 8 lines
Quoted 2 lines
In addition, Haswell HDMI audio is not affected and works well. It seems
there is HW behavior difference between HSW and BDW.
Thanks for spotting out!
This sounds like a weird hardware bug of BDW. If any, we'd need to introduce a flag indicating flipping this lookup behavior depending on the
chip.
Quoted 2 lines
In the display HD-A controller of HSW/BDW, there are 3 sets of stream
descriptors registers which controls the DMA engines to transfer audio data over HD-A link:
Quoted 7 lines
set #0: 0x80 ~ 0x9c SD0CTL ~ SD0BDPU
set #1: 0xa0 ~ 0xbc SD1CTL ~ SD1BDPU
set #2: 0xc0 ~ 0xdc SD2CTL ~ SD2BDPU
Test shows that
On HSW, DMA update on all 3 sets of registers are okay.
On BDW, DMA update on set #1 and #2 are okay, but is buggy on set #0.
Since the three sets of registers have the same definition according to spec and driver behavior is also same, it seems to be a HW issue.
Quoted 1 line
Quoted 6 lines
Quoted 1 line
Maybe we'll have to use the original reverse lookup order for BDW HDMI/DP
audio.
I wonder what if you run three streams. Is the set#0 always broken, or broken only when used alone? In the former case, the fix would to mask the first slot. In the latter case, back to reverse assignment would work around it.

Quoted 5 lines

The set#0 is always broken, when I run single or two streams at the same time.
And when running two streams, there is no difference if the audio driver choose set#0 or #1 at first.
Is it okay to introduce a flag "disabled" to struct azx_dev? If this flag is set, the azx_dev slot is masked.

You can just keep azx_dev->opened flag set at initialization time.

Takashi

Lin, Mengdong

2014-05-13 04:37 UTC #16 lore raw

Hi Takashi,

I submitted two patches to mask the buggy DMA0 of Broadwell display controller. Please review.

[PATCH 1/2] ALSA: hda - allow to mask a buggy stream DMA by setting it as opened [PATCH 2/2] ALSA: hda - mask buggy stream DMA0 for Broadwell display controller

Thanks again
Mengdong

Quoted 96 lines

-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Monday, May 12, 2014 5:52 PM
To: Lin, Mengdong
Cc: David Henningsson; Yang, Libin; [email protected]; [email protected]; Pierre-Louis Bossart
Subject: Re: [alsa-devel] [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Mon, 12 May 2014 09:46:07 +0000,
Quoted 64 lines · Mengdong
Quoted 64 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Monday, May 12, 2014 4:31 PM
To: Lin, Mengdong
Cc: David Henningsson; Yang, Libin; [email protected]; [email protected]; Pierre-Louis Bossart
Subject: Re: [alsa-devel] [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Mon, 12 May 2014 08:22:13 +0000,
Quoted 10 lines · Mengdong
Quoted 10 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Friday, May 09, 2014 6:20 PM
To: Lin, Mengdong
Cc: David Henningsson; Yang, Libin; [email protected]; [email protected]; Pierre-Louis Bossart
Subject: Re: [alsa-devel] [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines · Mengdong
Hi,
We found the Broadwell HDMI audio regression is introduced by this
patch:
Quoted 13 lines
Quoted 13 lines
Quoted 9 lines
commit dcb32ecd9a533f47ab652c5c5680bc50a7a822cd
Author: Anssi Hannula <[email protected]>
Date: Tue Apr 8 12:36:42 2014 +0300
ALSA: hda - Do not assign streams in reverse order
We'll further check the root cause.
Since this patch seems only affect the stream ID. Actually Intel GPU tool only
find the stream ID is changed by this patch.
Quoted 3 lines
In addition, Haswell HDMI audio is not affected and works well. It seems
Quoted 7 lines
Quoted 7 lines
there is HW behavior difference between HSW and BDW.
Thanks for spotting out!
This sounds like a weird hardware bug of BDW. If any, we'd need to introduce a flag indicating flipping this lookup behavior depending on the
chip.
Quoted 3 lines
In the display HD-A controller of HSW/BDW, there are 3 sets of stream
descriptors registers which controls the DMA engines to transfer audio data over HD-A link:
Quoted 6 lines
set #0: 0x80 ~ 0x9c SD0CTL ~ SD0BDPU set #1: 0xa0 ~ 0xbc SD1CTL ~ SD1BDPU set #2: 0xc0 ~ 0xdc SD2CTL ~ SD2BDPU
Test shows that
On HSW, DMA update on all 3 sets of registers are okay.
On BDW, DMA update on set #1 and #2 are okay, but is buggy on set #0.
Since the three sets of registers have the same definition according to spec and driver behavior is also same, it seems to be a HW issue.
Quoted 1 line
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
Maybe we'll have to use the original reverse lookup order for BDW HDMI/DP
audio.
I wonder what if you run three streams. Is the set#0 always broken, or broken only when used alone? In the former case, the fix would to
mask the first slot.
Quoted 3 lines
Quoted 1 line
In the latter case, back to reverse assignment would work around it.
The set#0 is always broken, when I run single or two streams at the same
time.
Quoted 1 line
And when running two streams, there is no difference if the audio driver
choose set#0 or #1 at first.
Quoted 3 lines
Is it okay to introduce a flag "disabled" to struct azx_dev? If this flag is set, the azx_dev slot is masked.
You can just keep azx_dev->opened flag set at initialization time.
Takashi

Takashi Iwai

2014-05-13 07:19 UTC #17 lore raw

At Tue, 13 May 2014 04:37:18 +0000,

Quoted 7 lines · Mengdong

Hi Takashi,
I submitted two patches to mask the buggy DMA0 of Broadwell display controller. Please review.
[PATCH 1/2] ALSA: hda - allow to mask a buggy stream DMA by setting it as opened [PATCH 2/2] ALSA: hda - mask buggy stream DMA0 for Broadwell display controller

It can be just simple like the patch below. This is rather a tentative workaround. If the hardware (or the corresponding part in the graphics driver) is fixed, we can get rid of it easily. So, just keep the change as small and simple as possible.

Takashi

---

sound/pci/hda/hda_intel.c +6 -0

index b540ad71eb0d..2c54629d62d1 100644
@@ -1367,6 +1367,12 @@ static int azx_first_init(struct azx *chip)
 	/* initialize streams */
 	azx_init_stream(chip);
 
+	/* workaround for Broadwell HDMI: the first stream is broken,
+	 * so mask it by keeping it as if opened
+	 */
+	if (pci->vendor == 0x8086 && pci->device == 0x160c)
+		chip->azx_dev[0].opened = 1;
+
 	/* initialize chip */
 	azx_init_pci(chip);
 	azx_init_chip(chip, (probe_only[dev] & 2) == 0);

Lin, Mengdong

2014-05-13 09:01 UTC #18 lore raw

Quoted 20 lines

-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Tuesday, May 13, 2014 3:20 PM
It can be just simple like the patch below. This is rather a tentative workaround. If the hardware (or the corresponding part in the graphics driver) is fixed, we can get rid of it easily. So, just keep the change as small and simple as possible.
Takashi
---
sound/pci/hda/hda_intel.c index renamed from sound/pci/hda/hda_intel.c +0 -0
b540ad71eb0d..2c54629d62d1 100644
sound/pci/hda/hda_intel.c +0 -0
@@ -1367,6 +1367,12 @@ static int azx_first_init(struct azx *chip)
 	/* initialize streams */
 	azx_init_stream(chip);

sound/pci/hda/hda_intel.c static int azx_first_init(struct azx *chip) · line 1378

Quoted 10 lines

sound/pci/hda/hda_intel.c +6 -0

 
+	/* workaround for Broadwell HDMI: the first stream is broken,
+	 * so mask it by keeping it as if opened
+	 */
+	if (pci->vendor == 0x8086 && pci->device == 0x160c)
+		chip->azx_dev[0].opened = 1;
+
 	/* initialize chip */
 	azx_init_pci(chip);
 	azx_init_chip(chip, (probe_only[dev] & 2) == 0);

Hi Takashi,

I revised the patch as you suggested. Hope we'll have a better solution for Broadwell soon.

Thanks
Mengdong

Pierre-Louis Bossart

2014-05-09 14:58 UTC #19 lore raw

In reply to Lin, Mengdong

Quoted 9 lines · Mengdong

Hi,
We found the Broadwell HDMI audio regression is introduced by this patch:
commit dcb32ecd9a533f47ab652c5c5680bc50a7a822cd
Author: Anssi Hannula <[email protected]>
Date: Tue Apr 8 12:36:42 2014 +0300
ALSA: hda - Do not assign streams in reverse order

Quoted 4 lines

We'll further check the root cause.
Since this patch seems only affect the stream ID. Actually Intel GPU tool only find the stream ID is changed by this patch.
In addition, Haswell HDMI audio is not affected and works well. It seems there is HW behavior difference between HSW and BDW.

It's unlikely that the wallclock is the issue here. LPIB and wallclock only make sense for the short link to the GPU, where the data is reshuffled. It'd look into how the audio data is inserted in the HDMI frame, the fact that the behavior is linked to a channel order or stream ID points to GPU-level configuration, not a counter issue at the HDAudio controller level. -Pierre

Lin, Mengdong

2014-05-08 09:37 UTC #20 lore raw

In reply to Takashi Iwai

Hi Takashi,

Is it possible to accept this patch as a quick fix?

It seems that a driver regression triggers this issue, since we don't have this problem two weeks ago. We're still trying to locate the regression and checking the root cause.

This patch could avoid audio degradation atm before we have a better solution.

Thanks
Mengdong

Quoted 73 lines

-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Thursday, May 08, 2014 2:40 PM
To: Yang, Libin
Cc: [email protected]; Lin, Mengdong; Pierre-Louis Bossart
Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Thu, 8 May 2014 06:28:17 +0000,
Quoted 53 lines · Libin
Hi Takashi,
Quoted 50 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Thursday, May 8, 2014 2:20 PM
To: Yang, Libin
Cc: [email protected]; Lin, Mengdong; Pierre-Louis Bossart
Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Thu, 8 May 2014 06:13:31 +0000,
Quoted 18 lines · Libin
Hi Takashi,
Quoted 15 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Thursday, May 8, 2014 1:51 PM
To: Yang, Libin
Cc: [email protected]; Lin, Mengdong; Pierre-Louis Bossart
Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
Quoted 5 lines · Libin
Hi Takashi,
I checked the wallclock counter. The counter is OK. But it failed to correct
Quoted 7 lines
Quoted 4 lines
the position.
So, how wrong the position buffer is? Is the problem intermittent? Please elaborate more.
The issue is the position is almost always inaccurate. You will hear there is
intermittent noise in the sound. And the sound is played faster than it should be.
Quoted 4 lines
The following message is what I got from dmesg:
[ 73.278117] snd_hda_intel 0000:00:03.0: IRQ timing workaround is
activated for card #0. Suggest a bigger bdl_pos_adj.
Quoted 5 lines
[ 73.528575] snd_hda_intel 0000:00:03.0: Unstable LPIB (26240 >=
24064); disabling LPIB delay counting
Do you think the print of wallclk and position information in the function
azx_position_ok() is useful to you? If yes, I will add debug code to print the info.
Quoted 6 lines
Quoted 4 lines
It'd better to have the raw values of posbuf, lpib and wallclock for further analysis, yes.
BTW, did you try non-snoop mode via snoop=0 option?
I haven't tried non-snoop. Do I use modprobe snd-hda-intel snoop=0 to use
non-snoop mode?
Yes.
Takashi

Takashi Iwai

2014-05-08 09:42 UTC #21 lore raw

At Thu, 8 May 2014 09:37:13 +0000,

Quoted 4 lines · Mengdong

Hi Takashi,
Is it possible to accept this patch as a quick fix?

Well, the question is whether this is specific to this board, or it's a generic issue of BDW HDMI controller. In the latter case, the fix is done in a wrong place.

Quoted 2 lines

It seems that a driver regression triggers this issue, since we don't have this problem two weeks ago. We're still trying to locate the regression and checking the root cause.

If it's a recent regression, I don't think it's good to apply a bandaid. There must be a cause (e.g. something changed in the graphics side) to fix properly.

Quoted 1 line

This patch could avoid audio degradation atm before we have a better solution.

The workaround can be applied easily via module option, and the machine isn't in the market yet. So I see no point to hurry too much for now...

thanks,

Takashi

Quoted 77 lines

Thanks
Mengdong
Quoted 73 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Thursday, May 08, 2014 2:40 PM
To: Yang, Libin
Cc: [email protected]; Lin, Mengdong; Pierre-Louis Bossart
Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Thu, 8 May 2014 06:28:17 +0000,
Quoted 53 lines · Libin
Hi Takashi,
Quoted 50 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Thursday, May 8, 2014 2:20 PM
To: Yang, Libin
Cc: [email protected]; Lin, Mengdong; Pierre-Louis Bossart
Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
At Thu, 8 May 2014 06:13:31 +0000,
Quoted 18 lines · Libin
Hi Takashi,
Quoted 15 lines
-----Original Message-----
From: Takashi Iwai [mailto:[email protected]]
Sent: Thursday, May 8, 2014 1:51 PM
To: Yang, Libin
Cc: [email protected]; Lin, Mengdong; Pierre-Louis Bossart
Subject: Re: [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
Quoted 5 lines · Libin
Hi Takashi,
I checked the wallclock counter. The counter is OK. But it failed to correct
Quoted 7 lines
Quoted 4 lines
the position.
So, how wrong the position buffer is? Is the problem intermittent? Please elaborate more.
The issue is the position is almost always inaccurate. You will hear there is
intermittent noise in the sound. And the sound is played faster than it should be.
Quoted 4 lines
The following message is what I got from dmesg:
[ 73.278117] snd_hda_intel 0000:00:03.0: IRQ timing workaround is
activated for card #0. Suggest a bigger bdl_pos_adj.
Quoted 5 lines
[ 73.528575] snd_hda_intel 0000:00:03.0: Unstable LPIB (26240 >=
24064); disabling LPIB delay counting
Do you think the print of wallclk and position information in the function
azx_position_ok() is useful to you? If yes, I will add debug code to print the info.
Quoted 6 lines
Quoted 4 lines
It'd better to have the raw values of posbuf, lpib and wallclock for further analysis, yes.
BTW, did you try non-snoop mode via snoop=0 option?
I haven't tried non-snoop. Do I use modprobe snd-hda-intel snoop=0 to use
non-snoop mode?
Yes.
Takashi