[alsa-devel] [REGRESSION] Sound goes too fast due to 798cb7e897210
tiwai at suse.de
Tue Oct 18 16:51:57 CEST 2011
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
After all, there are not so many controller chips. If the quirk were
mandatory, the list would have been much longer :)
More information about the Alsa-devel