Re: [REGRESSION] Sound goes too fast due to 798cb7e897210

[Takashi Iwai <tiwai@suse.de>]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel