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

David Henningsson david.henningsson at canonical.com
Tue Oct 18 16:48:00 CEST 2011


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?


-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic


More information about the Alsa-devel mailing list