[alsa-devel] [REGRESSION] Sound goes too fast due to 798cb7e897210

[Takashi Iwai]

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 Iwai<tiwai at 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 at tremplin-utc.net>
> > Cc:<stable at kernel.org>
> > Signed-off-by: Takashi Iwai<tiwai at 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