Re: [alsa-devel] [REGRESSION] Sound goes too fast due to 798cb7e897210
At Tue, 18 Oct 2011 10:38:06 +0200, Éric Piel wrote:
Op 18-10-11 10:23, Takashi Iwai schreef:
At Tue, 18 Oct 2011 10:10:14 +0200, Éric Piel wrote:
:
If that commit affects, the best fix would be to give a quirk specific to your device. Try to pass either position_fix=1 or position_fix=2. Only one of them should work (likely 2).
After checking it, you can add it to position_fix_list[] in sound/pci/hda/hda_intel.c together with PCI SSID.
Hello, Thanks for the quick response. Indeed forcing position_fix=1 does fix the bug. I'll not try to make a patch for my device.
Hm, interesting. So, in your case, the position-buffer exists and reports some valid values, but the values are sloppy actually. It's hard to detect in the driver, unfortunately. The relevant commit (and its original fix) were the attempts to detect better, but it seems that it fails...
FWIW, the patch below is what I'm committing to the tree.
thanks,
Takashi
--- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Add position_fix quirk for Dell Inspiron 1010
The previous fix for the position-buffer check gives yet another regression on a Dell laptop. The safest fix right now is to add a static quirk for this device (and better to apply it for stable kernels too).
Reported-by: Éric Piel Eric.Piel@tremplin-utc.net Cc: stable@kernel.org Signed-off-by: Takashi Iwai tiwai@suse.de --- 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 e9a2a87..191284a 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2370,6 +2370,7 @@ static int azx_dev_free(struct snd_device *device) static struct snd_pci_quirk position_fix_list[] __devinitdata = { SND_PCI_QUIRK(0x1028, 0x01cc, "Dell D820", POS_FIX_LPIB), SND_PCI_QUIRK(0x1028, 0x01de, "Dell Precision 390", POS_FIX_LPIB), + SND_PCI_QUIRK(0x1028, 0x02c6, "Dell Inspiron 1010", POS_FIX_LPIB), SND_PCI_QUIRK(0x103c, 0x306d, "HP dv3", POS_FIX_LPIB), SND_PCI_QUIRK(0x1043, 0x813d, "ASUS P5AD2", POS_FIX_LPIB), SND_PCI_QUIRK(0x1043, 0x81b3, "ASUS", POS_FIX_LPIB),
(Sorry for removing some CC people from this mail, seems to be a mail problem at this end)
2011-10-18 10:46, Takashi Iwai skrev:
At Tue, 18 Oct 2011 10:38:06 +0200, Éric Piel wrote:
Op 18-10-11 10:23, Takashi Iwai schreef:
At Tue, 18 Oct 2011 10:10:14 +0200, Éric Piel wrote:
:
If that commit affects, the best fix would be to give a quirk specific to your device. Try to pass either position_fix=1 or position_fix=2. Only one of them should work (likely 2).
After checking it, you can add it to position_fix_list[] in sound/pci/hda/hda_intel.c together with PCI SSID.
Hello, Thanks for the quick response. Indeed forcing position_fix=1 does fix the bug. I'll not try to make a patch for my device.
Hm, interesting. So, in your case, the position-buffer exists and reports some valid values, but the values are sloppy actually. It's hard to detect in the driver, unfortunately. The relevant commit (and its original fix) were the attempts to detect better, but it seems that it fails...
FWIW, the patch below is what I'm committing to the tree.
I'm wondering if quirking this based on PCI Vendor-ID would be better than PCI SSID. After all, a broken position buffer should be more of a controller chip problem than a controller/codec/config problem, right?
From: Takashi Iwaitiwai@suse.de Subject: [PATCH] ALSA: hda - Add position_fix quirk for Dell Inspiron 1010
The previous fix for the position-buffer check gives yet another regression on a Dell laptop. The safest fix right now is to add a static quirk for this device (and better to apply it for stable kernels too).
Reported-by: Éric PielEric.Piel@tremplin-utc.net Cc:stable@kernel.org Signed-off-by: Takashi Iwaitiwai@suse.de
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 e9a2a87..191284a 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2370,6 +2370,7 @@ static int azx_dev_free(struct snd_device *device) static struct snd_pci_quirk position_fix_list[] __devinitdata = { SND_PCI_QUIRK(0x1028, 0x01cc, "Dell D820", POS_FIX_LPIB), SND_PCI_QUIRK(0x1028, 0x01de, "Dell Precision 390", POS_FIX_LPIB),
- SND_PCI_QUIRK(0x1028, 0x02c6, "Dell Inspiron 1010", POS_FIX_LPIB),
As seen here there are several relatively similar IDs - even more reason to suspect they share the same controller chip perhaps?
// David
At Tue, 18 Oct 2011 15:11:23 +0200, David Henningsson wrote:
(Sorry for removing some CC people from this mail, seems to be a mail problem at this end)
2011-10-18 10:46, Takashi Iwai skrev:
At Tue, 18 Oct 2011 10:38:06 +0200, Éric Piel wrote:
Op 18-10-11 10:23, Takashi Iwai schreef:
At Tue, 18 Oct 2011 10:10:14 +0200, Éric Piel wrote:
:
If that commit affects, the best fix would be to give a quirk specific to your device. Try to pass either position_fix=1 or position_fix=2. Only one of them should work (likely 2).
After checking it, you can add it to position_fix_list[] in sound/pci/hda/hda_intel.c together with PCI SSID.
Hello, Thanks for the quick response. Indeed forcing position_fix=1 does fix the bug. I'll not try to make a patch for my device.
Hm, interesting. So, in your case, the position-buffer exists and reports some valid values, but the values are sloppy actually. It's hard to detect in the driver, unfortunately. The relevant commit (and its original fix) were the attempts to detect better, but it seems that it fails...
FWIW, the patch below is what I'm committing to the tree.
I'm wondering if quirking this based on PCI Vendor-ID would be better than PCI SSID. After all, a broken position buffer should be more of a controller chip problem than a controller/codec/config problem, right?
Unfortunately this isn't sure. At least, many Intel chips work fine, so the PCI vendor-id itself isn't correct to use. And PCI SSID vendor alone also is no good way to filter, because it may use different controller chips (like AMD).
The PCI SSID is used now with a hope of that such a breakage won't be too often. And if it's really generic to a PCI controller (vendor/device ID pair), we should put a workaround in driver_caps bits instead.
From: Takashi Iwaitiwai@suse.de Subject: [PATCH] ALSA: hda - Add position_fix quirk for Dell Inspiron 1010
The previous fix for the position-buffer check gives yet another regression on a Dell laptop. The safest fix right now is to add a static quirk for this device (and better to apply it for stable kernels too).
Reported-by: Éric PielEric.Piel@tremplin-utc.net Cc:stable@kernel.org Signed-off-by: Takashi Iwaitiwai@suse.de
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 e9a2a87..191284a 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2370,6 +2370,7 @@ static int azx_dev_free(struct snd_device *device) static struct snd_pci_quirk position_fix_list[] __devinitdata = { SND_PCI_QUIRK(0x1028, 0x01cc, "Dell D820", POS_FIX_LPIB), SND_PCI_QUIRK(0x1028, 0x01de, "Dell Precision 390", POS_FIX_LPIB),
- SND_PCI_QUIRK(0x1028, 0x02c6, "Dell Inspiron 1010", POS_FIX_LPIB),
As seen here there are several relatively similar IDs - even more reason to suspect they share the same controller chip perhaps?
In general, using LPIB is more reliable. But there are certainly some corner cases that LPIB isn't correct. That was the reason of the previous fix after all.
thanks,
Takashi
On 10/18/2011 03:22 PM, Takashi Iwai wrote:
At Tue, 18 Oct 2011 15:11:23 +0200, David Henningsson wrote:
(Sorry for removing some CC people from this mail, seems to be a mail problem at this end)
2011-10-18 10:46, Takashi Iwai skrev:
At Tue, 18 Oct 2011 10:38:06 +0200, Éric Piel wrote:
Op 18-10-11 10:23, Takashi Iwai schreef:
At Tue, 18 Oct 2011 10:10:14 +0200, Éric Piel wrote:
:
If that commit affects, the best fix would be to give a quirk specific to your device. Try to pass either position_fix=1 or position_fix=2. Only one of them should work (likely 2).
After checking it, you can add it to position_fix_list[] in sound/pci/hda/hda_intel.c together with PCI SSID.
Hello, Thanks for the quick response. Indeed forcing position_fix=1 does fix the bug. I'll not try to make a patch for my device.
Hm, interesting. So, in your case, the position-buffer exists and reports some valid values, but the values are sloppy actually. It's hard to detect in the driver, unfortunately. The relevant commit (and its original fix) were the attempts to detect better, but it seems that it fails...
FWIW, the patch below is what I'm committing to the tree.
I'm wondering if quirking this based on PCI Vendor-ID would be better than PCI SSID. After all, a broken position buffer should be more of a controller chip problem than a controller/codec/config problem, right?
Unfortunately this isn't sure. At least, many Intel chips work fine, so the PCI vendor-id itself isn't correct to use. And PCI SSID vendor alone also is no good way to filter, because it may use different controller chips (like AMD).
The PCI SSID is used now with a hope of that such a breakage won't be too often. And if it's really generic to a PCI controller (vendor/device ID pair), we should put a workaround in driver_caps bits instead.
Sorry, the PCI VendorID/deviceID was what I meant here. If you need a certain position fix type, isn't it more likely to affect an entire controller, rather than just the controller/codec/config combination that you're quirking?
At Tue, 18 Oct 2011 16:48:00 +0200, David Henningsson wrote:
On 10/18/2011 03:22 PM, Takashi Iwai wrote:
At Tue, 18 Oct 2011 15:11:23 +0200, David Henningsson wrote:
(Sorry for removing some CC people from this mail, seems to be a mail problem at this end)
2011-10-18 10:46, Takashi Iwai skrev:
At Tue, 18 Oct 2011 10:38:06 +0200, Éric Piel wrote:
Op 18-10-11 10:23, Takashi Iwai schreef:
At Tue, 18 Oct 2011 10:10:14 +0200, Éric Piel wrote:
:
If that commit affects, the best fix would be to give a quirk specific to your device. Try to pass either position_fix=1 or position_fix=2. Only one of them should work (likely 2).
After checking it, you can add it to position_fix_list[] in sound/pci/hda/hda_intel.c together with PCI SSID.
Hello, Thanks for the quick response. Indeed forcing position_fix=1 does fix the bug. I'll not try to make a patch for my device.
Hm, interesting. So, in your case, the position-buffer exists and reports some valid values, but the values are sloppy actually. It's hard to detect in the driver, unfortunately. The relevant commit (and its original fix) were the attempts to detect better, but it seems that it fails...
FWIW, the patch below is what I'm committing to the tree.
I'm wondering if quirking this based on PCI Vendor-ID would be better than PCI SSID. After all, a broken position buffer should be more of a controller chip problem than a controller/codec/config problem, right?
Unfortunately this isn't sure. At least, many Intel chips work fine, so the PCI vendor-id itself isn't correct to use. And PCI SSID vendor alone also is no good way to filter, because it may use different controller chips (like AMD).
The PCI SSID is used now with a hope of that such a breakage won't be too often. And if it's really generic to a PCI controller (vendor/device ID pair), we should put a workaround in driver_caps bits instead.
Sorry, the PCI VendorID/deviceID was what I meant here. If you need a certain position fix type, isn't it more likely to affect an entire controller, rather than just the controller/codec/config combination that you're quirking?
Again, it's not sure. At least most of the controllers work as is. I bet that the same controller on other machines would work without position_fix quirk.
After all, there are not so many controller chips. If the quirk were mandatory, the list would have been much longer :)
Takashi
participants (2)
-
David Henningsson -
Takashi Iwai