[alsa-devel] [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
From: Libin Yang libin.yang@intel.com
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 libin.yang@intel.com --- sound/pci/hda/hda_intel.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index b540ad7..9cd40c6 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -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), {} };
At Thu, 8 May 2014 02:03:24 +0800, libin.yang@intel.com wrote:
From: Libin Yang libin.yang@intel.com
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
Signed-off-by: Libin Yang libin.yang@intel.com
sound/pci/hda/hda_intel.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index b540ad7..9cd40c6 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -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), {}
};
-- 1.8.3.2
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
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, May 8, 2014 1:09 PM To: Yang, Libin Cc: alsa-devel@alsa-project.org; 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, libin.yang@intel.com wrote:
From: Libin Yang libin.yang@intel.com
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
Signed-off-by: Libin Yang libin.yang@intel.com
sound/pci/hda/hda_intel.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index b540ad7..9cd40c6 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -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),
{} };
-- 1.8.3.2
At Thu, 8 May 2014 05:48:04 +0000, Yang, Libin wrote:
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
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
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, May 8, 2014 1:09 PM To: Yang, Libin Cc: alsa-devel@alsa-project.org; 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, libin.yang@intel.com wrote:
From: Libin Yang libin.yang@intel.com
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
Signed-off-by: Libin Yang libin.yang@intel.com
sound/pci/hda/hda_intel.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index b540ad7..9cd40c6 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -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),
{} };
-- 1.8.3.2
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, May 8, 2014 1:51 PM To: Yang, Libin Cc: alsa-devel@alsa-project.org; 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, Yang, Libin wrote:
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.
Takashi
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
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, May 8, 2014 1:09 PM To: Yang, Libin Cc: alsa-devel@alsa-project.org; 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, libin.yang@intel.com wrote:
From: Libin Yang libin.yang@intel.com
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
Signed-off-by: Libin Yang libin.yang@intel.com
sound/pci/hda/hda_intel.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index b540ad7..9cd40c6 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -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),
{} };
-- 1.8.3.2
Regards, Libin
At Thu, 8 May 2014 06:13:31 +0000, Yang, Libin wrote:
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, May 8, 2014 1:51 PM To: Yang, Libin Cc: alsa-devel@alsa-project.org; 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, Yang, Libin wrote:
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.
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
Takashi
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
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, May 8, 2014 1:09 PM To: Yang, Libin Cc: alsa-devel@alsa-project.org; 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, libin.yang@intel.com wrote:
From: Libin Yang libin.yang@intel.com
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
Signed-off-by: Libin Yang libin.yang@intel.com
sound/pci/hda/hda_intel.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index b540ad7..9cd40c6 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -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),
{} };
-- 1.8.3.2
Regards, Libin
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, May 8, 2014 2:20 PM To: Yang, Libin Cc: alsa-devel@alsa-project.org; 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, Yang, Libin wrote:
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, May 8, 2014 1:51 PM To: Yang, Libin Cc: alsa-devel@alsa-project.org; 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, Yang, Libin wrote:
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.
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?
Takashi
Takashi
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
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, May 8, 2014 1:09 PM To: Yang, Libin Cc: alsa-devel@alsa-project.org; 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, libin.yang@intel.com wrote:
From: Libin Yang libin.yang@intel.com
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
Signed-off-by: Libin Yang libin.yang@intel.com
sound/pci/hda/hda_intel.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index b540ad7..9cd40c6 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -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),
{} };
-- 1.8.3.2
Regards, Libin
At Thu, 8 May 2014 06:28:17 +0000, Yang, Libin wrote:
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, May 8, 2014 2:20 PM To: Yang, Libin Cc: alsa-devel@alsa-project.org; 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, Yang, Libin wrote:
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, May 8, 2014 1:51 PM To: Yang, Libin Cc: alsa-devel@alsa-project.org; 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, Yang, Libin wrote:
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.
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
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
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, May 8, 2014 2:40 PM To: Yang, Libin Cc: alsa-devel@alsa-project.org; 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, Yang, Libin wrote:
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, May 8, 2014 2:20 PM To: Yang, Libin Cc: alsa-devel@alsa-project.org; 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, Yang, Libin wrote:
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, May 8, 2014 1:51 PM To: Yang, Libin Cc: alsa-devel@alsa-project.org; 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, Yang, Libin wrote:
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.
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
On 2014-05-08 09:58, Yang, Libin wrote:
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
This looks quite bad - is it not a hardware bug if LPIB > CBL (CBL should be 16384 in this case)?
Hi,
We found the Broadwell HDMI audio regression is introduced by this patch:
commit dcb32ecd9a533f47ab652c5c5680bc50a7a822cd Author: Anssi Hannula anssi.hannula@iki.fi 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
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Friday, May 09, 2014 12:06 AM To: Yang, Libin; Takashi Iwai Cc: Lin, Mengdong; alsa-devel@alsa-project.org; Pierre-Louis Bossart Subject: Re: [alsa-devel] [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
On 2014-05-08 09:58, Yang, Libin wrote:
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
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
At Fri, 9 May 2014 10:08:19 +0000, Lin, Mengdong wrote:
Hi,
We found the Broadwell HDMI audio regression is introduced by this patch:
commit dcb32ecd9a533f47ab652c5c5680bc50a7a822cd Author: Anssi Hannula anssi.hannula@iki.fi 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 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
Thanks Mengdong
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Friday, May 09, 2014 12:06 AM To: Yang, Libin; Takashi Iwai Cc: Lin, Mengdong; alsa-devel@alsa-project.org; Pierre-Louis Bossart Subject: Re: [alsa-devel] [PATCH] ALSA: hda - using POS_FIX_LPIB on Broadwell HDMI Audio
On 2014-05-08 09:58, Yang, Libin wrote:
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
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
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, May 09, 2014 6:20 PM To: Lin, Mengdong Cc: David Henningsson; Yang, Libin; anssi.hannula@iki.fi; alsa-devel@alsa-project.org; 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, Lin, Mengdong wrote:
Hi,
We found the Broadwell HDMI audio regression is introduced by this patch:
commit dcb32ecd9a533f47ab652c5c5680bc50a7a822cd Author: Anssi Hannula anssi.hannula@iki.fi 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 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
At Mon, 12 May 2014 08:22:13 +0000, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, May 09, 2014 6:20 PM To: Lin, Mengdong Cc: David Henningsson; Yang, Libin; anssi.hannula@iki.fi; alsa-devel@alsa-project.org; 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, Lin, Mengdong wrote:
Hi,
We found the Broadwell HDMI audio regression is introduced by this patch:
commit dcb32ecd9a533f47ab652c5c5680bc50a7a822cd Author: Anssi Hannula anssi.hannula@iki.fi 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 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.
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
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Monday, May 12, 2014 4:31 PM To: Lin, Mengdong Cc: David Henningsson; Yang, Libin; anssi.hannula@iki.fi; alsa-devel@alsa-project.org; 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, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, May 09, 2014 6:20 PM To: Lin, Mengdong Cc: David Henningsson; Yang, Libin; anssi.hannula@iki.fi; alsa-devel@alsa-project.org; 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, Lin, Mengdong wrote:
Hi,
We found the Broadwell HDMI audio regression is introduced by this
patch:
commit dcb32ecd9a533f47ab652c5c5680bc50a7a822cd Author: Anssi Hannula anssi.hannula@iki.fi 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 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.
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
At Mon, 12 May 2014 09:46:07 +0000, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Monday, May 12, 2014 4:31 PM To: Lin, Mengdong Cc: David Henningsson; Yang, Libin; anssi.hannula@iki.fi; alsa-devel@alsa-project.org; 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, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, May 09, 2014 6:20 PM To: Lin, Mengdong Cc: David Henningsson; Yang, Libin; anssi.hannula@iki.fi; alsa-devel@alsa-project.org; 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, Lin, Mengdong wrote:
Hi,
We found the Broadwell HDMI audio regression is introduced by this
patch:
commit dcb32ecd9a533f47ab652c5c5680bc50a7a822cd Author: Anssi Hannula anssi.hannula@iki.fi 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 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.
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.
You can just keep azx_dev->opened flag set at initialization time.
Takashi
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
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Monday, May 12, 2014 5:52 PM To: Lin, Mengdong Cc: David Henningsson; Yang, Libin; anssi.hannula@iki.fi; alsa-devel@alsa-project.org; 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, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Monday, May 12, 2014 4:31 PM To: Lin, Mengdong Cc: David Henningsson; Yang, Libin; anssi.hannula@iki.fi; alsa-devel@alsa-project.org; 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, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, May 09, 2014 6:20 PM To: Lin, Mengdong Cc: David Henningsson; Yang, Libin; anssi.hannula@iki.fi; alsa-devel@alsa-project.org; 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, Lin, Mengdong wrote:
Hi,
We found the Broadwell HDMI audio regression is introduced by this
patch:
commit dcb32ecd9a533f47ab652c5c5680bc50a7a822cd Author: Anssi Hannula anssi.hannula@iki.fi 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 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.
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.
You can just keep azx_dev->opened flag set at initialization time.
Takashi
At Tue, 13 May 2014 04:37:18 +0000, Lin, Mengdong wrote:
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
--- diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index b540ad71eb0d..2c54629d62d1 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -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);
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] 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
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index b540ad71eb0d..2c54629d62d1 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -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);
Hi Takashi,
I revised the patch as you suggested. Hope we'll have a better solution for Broadwell soon.
Thanks Mengdong
On 5/9/14, 5:08 AM, Lin, Mengdong wrote:
Hi,
We found the Broadwell HDMI audio regression is introduced by this patch:
commit dcb32ecd9a533f47ab652c5c5680bc50a7a822cd Author: Anssi Hannula anssi.hannula@iki.fi 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.
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
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
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, May 08, 2014 2:40 PM To: Yang, Libin Cc: alsa-devel@alsa-project.org; 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, Yang, Libin wrote:
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, May 8, 2014 2:20 PM To: Yang, Libin Cc: alsa-devel@alsa-project.org; 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, Yang, Libin wrote:
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, May 8, 2014 1:51 PM To: Yang, Libin Cc: alsa-devel@alsa-project.org; 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, Yang, Libin wrote:
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.
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
At Thu, 8 May 2014 09:37:13 +0000, Lin, Mengdong wrote:
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.
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.
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
Thanks Mengdong
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, May 08, 2014 2:40 PM To: Yang, Libin Cc: alsa-devel@alsa-project.org; 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, Yang, Libin wrote:
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, May 8, 2014 2:20 PM To: Yang, Libin Cc: alsa-devel@alsa-project.org; 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, Yang, Libin wrote:
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, May 8, 2014 1:51 PM To: Yang, Libin Cc: alsa-devel@alsa-project.org; 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, Yang, Libin wrote: > > 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.
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
participants (6)
-
David Henningsson -
libin.yang＠intel.com -
Lin, Mengdong -
Pierre-Louis Bossart -
Takashi Iwai -
Yang, Libin