Bug 785417
| Summary: | alsa: snd_hda_intel - no sound | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jan ONDREJ <ondrejj> | ||||||||
| Component: | kernel | Assignee: | Jaroslav Kysela <jkysela> | ||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 16 | CC: | fedorabugmail, gansalmon, itamar, jkysela, jonathan, kernel-maint, madhu.chinakonda | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | i386 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2012-03-22 07:08:35 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Jan ONDREJ
2012-01-28 20:13:58 UTC
Please, attach output from 'alsa-info.sh --no-upload' to this bug. Created attachment 559582 [details]
alsa-info
Same problem with 3.2.3 kernel.
I have the same sound hardware and I also see the same issue. The BIOS didn't set the pincfg to some useable value. Blame the vendor. Use hda-analyzer - http://www.alsa-project.org/main/index.php/HDA_Analyzer - to analyze the hardware connections and codec behaviour. For ALC861 codec, we have some pinfixups for the node 0x0f - play with IN_EN and VREF_50. It controls the analog amplifier on some laptops. (In reply to comment #4) > The BIOS didn't set the pincfg to some useable value. Blame the vendor. > > Use hda-analyzer - http://www.alsa-project.org/main/index.php/HDA_Analyzer - to > analyze the hardware connections and codec behaviour. > > For ALC861 codec, we have some pinfixups for the node 0x0f - play with IN_EN > and VREF_50. It controls the analog amplifier on some laptops. Thanks. Here are results: IN_EN - no change, nothing happen VREF - all values works well, except default HIZ, so VREF_50 plays sound nicely. Can you fix this in later kernels? Is there a workaround to set these parameter at boot until it will be fixed? Use 'Exp' (export) button to generate a python script with the changes.
The kernel patch will look like this:
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5610,6 +5610,7 @@ static const struct alc_fixup alc861_fixups[] = {
static const struct snd_pci_quirk alc861_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x1393, "ASUS A6Rp", PINFIX_ASUS_A6RP),
+ SND_PCI_QUIRK(0x1584, 0x0000, "Uniwill ECS M31EI", PINFIX_ASUS_A6RP),
SND_PCI_QUIRK(0x1584, 0x2b01, "Haier W18", PINFIX_ASUS_A6RP),
SND_PCI_QUIRK(0x1734, 0x10c7, "FSC Amilo Pi1505", PINFIX_FSC_AMILO_PI1505),
{}
or:
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5603,6 +5603,7 @@ static const struct alc_fixup alc861_fixups[] = {
static const struct snd_pci_quirk alc861_fixup_tbl[] = {
SND_PCI_QUIRK_VENDOR(0x1043, "ASUS laptop", PINFIX_ASUS_A6RP),
+ SND_PCI_QUIRK(0x1584, 0x0000, "Uniwill ECS M31EI", PINFIX_ASUS_A6RP),
SND_PCI_QUIRK(0x1584, 0x2b01, "Haier W18", PINFIX_ASUS_A6RP),
SND_PCI_QUIRK(0x1734, 0x10c7, "FSC Amilo Pi1505", PINFIX_FSC_AMILO_PI1505),
{}
Created attachment 560369 [details]
Python script from hda-analyzer
This script fixes the problem on my machine
Jan, did you run the script and use the Exp button as Jaroslav suggested? Created attachment 570692 [details]
My hdafix script.
Yes, sure. Here is my script. Still not fixed in 3.2.9-2.fc16.i686.PAE.
What else I can do to fix this upstream?
It is fixed in upstream, but the patch is not in the Fedora kernel: http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commitdiff;h=416846d2b31fc740ed9d5a5ec116964fb43c4358 Looks like this is already fixed in 3.3.0-4.fc16.i686.PAE, which is now in Fedora stable updates. Closing this bug. Thanks to all for help. |