[alsa-devel] [PATCH] ALSA: HDA: Use LPIB position fix for Macbook Pro 7, 1
Several users have reported "choppy" audio under the 3.2 kernel, and that changing position_fix to 1 has resolved their problem. The chip is an nVidia Corporation MCP89 High Definition Audio, [10de:0d94] (rev a2).
Cc: stable@kernel.org (v3.2+) BugLink: https://bugs.launchpad.net/bugs/909419 Signed-off-by: David Henningsson david.henningsson@canonical.com --- sound/pci/hda/hda_intel.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index bd447b6..2e1c063 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2500,6 +2500,7 @@ static struct snd_pci_quirk position_fix_list[] __devinitdata = { SND_PCI_QUIRK(0x1043, 0x81e7, "ASUS M2V", POS_FIX_LPIB), SND_PCI_QUIRK(0x1043, 0x83ce, "ASUS 1101HA", POS_FIX_LPIB), SND_PCI_QUIRK(0x104d, 0x9069, "Sony VPCS11V9E", POS_FIX_LPIB), + SND_PCI_QUIRK(0x10de, 0xcb89, "Macbook Pro 7,1", POS_FIX_LPIB), SND_PCI_QUIRK(0x1297, 0x3166, "Shuttle", POS_FIX_LPIB), SND_PCI_QUIRK(0x1458, 0xa022, "ga-ma770-ud3", POS_FIX_LPIB), SND_PCI_QUIRK(0x1462, 0x1002, "MSI Wind U115", POS_FIX_LPIB),
At Thu, 12 Jan 2012 16:31:14 +0100, David Henningsson wrote:
Several users have reported "choppy" audio under the 3.2 kernel, and that changing position_fix to 1 has resolved their problem. The chip is an nVidia Corporation MCP89 High Definition Audio, [10de:0d94] (rev a2).
Cc: stable@kernel.org (v3.2+) BugLink: https://bugs.launchpad.net/bugs/909419 Signed-off-by: David Henningsson david.henningsson@canonical.com
Applied now. Thanks.
Takashi
sound/pci/hda/hda_intel.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index bd447b6..2e1c063 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2500,6 +2500,7 @@ static struct snd_pci_quirk position_fix_list[] __devinitdata = { SND_PCI_QUIRK(0x1043, 0x81e7, "ASUS M2V", POS_FIX_LPIB), SND_PCI_QUIRK(0x1043, 0x83ce, "ASUS 1101HA", POS_FIX_LPIB), SND_PCI_QUIRK(0x104d, 0x9069, "Sony VPCS11V9E", POS_FIX_LPIB),
- SND_PCI_QUIRK(0x10de, 0xcb89, "Macbook Pro 7,1", POS_FIX_LPIB), SND_PCI_QUIRK(0x1297, 0x3166, "Shuttle", POS_FIX_LPIB), SND_PCI_QUIRK(0x1458, 0xa022, "ga-ma770-ud3", POS_FIX_LPIB), SND_PCI_QUIRK(0x1462, 0x1002, "MSI Wind U115", POS_FIX_LPIB),
-- 1.7.5.4
On 2012-01-13 09:50, Takashi Iwai wrote:
At Thu, 12 Jan 2012 16:31:14 +0100, David Henningsson wrote:
Several users have reported "choppy" audio under the 3.2 kernel, and that changing position_fix to 1 has resolved their problem. The chip is an nVidia Corporation MCP89 High Definition Audio, [10de:0d94] (rev a2).
Cc: stable@kernel.org (v3.2+) BugLink: https://bugs.launchpad.net/bugs/909419 Signed-off-by: David Henningssondavid.henningsson@canonical.com
Applied now. Thanks.
Thanks.
Just a thought...this was reported as working better under the previous Ubuntu release, which run kernel 3.0 (and not too many changes in PulseAudio), i e, a regression. While I haven't done any serious kernel bisection of this, I know you've being doing some work with the snoop/non-snoop stuff lately, which I haven't followed closely. Do you think this can be related to why we're seeing broken position values when we're using the DMA position buffer map on some machines?
At Fri, 13 Jan 2012 09:55:56 +0100, David Henningsson wrote:
On 2012-01-13 09:50, Takashi Iwai wrote:
At Thu, 12 Jan 2012 16:31:14 +0100, David Henningsson wrote:
Several users have reported "choppy" audio under the 3.2 kernel, and that changing position_fix to 1 has resolved their problem. The chip is an nVidia Corporation MCP89 High Definition Audio, [10de:0d94] (rev a2).
Cc: stable@kernel.org (v3.2+) BugLink: https://bugs.launchpad.net/bugs/909419 Signed-off-by: David Henningssondavid.henningsson@canonical.com
Applied now. Thanks.
Thanks.
Just a thought...this was reported as working better under the previous Ubuntu release, which run kernel 3.0 (and not too many changes in PulseAudio), i e, a regression. While I haven't done any serious kernel bisection of this, I know you've being doing some work with the snoop/non-snoop stuff lately, which I haven't followed closely. Do you think this can be related to why we're seeing broken position values when we're using the DMA position buffer map on some machines?
Honestly I have no idea. The possibility can't be excluded, though, since Windows seems using the non-cached pages as default.
The position-buffer is used primarily just because this was more robust on old hardware. OTOH, LPIB seems more robust on modern chips, so we may think of switching to LPIB, too.
Takashi
participants (2)
-
David Henningsson -
Takashi Iwai