[alsa-devel] Fixing ALC269 the right way?
Here's what I try to fix by playing around with it in hda-emu, it seems like more than one thing is broken here, but let's start with playback. This machine has one internal speaker and one line-out. Codec proc file is attached.
Here's my analysis so far:
1) If there's one internal speaker and one line-out (rather than headphone-out), should the internal speaker auto-mute? What's standard practice?
2) There are two DAC nids, 0x02 and 0x03, but only 0x02 is used (i e activated on playback). But line-out is connected (via nid 0x0d) to DAC 0x03, so there is no sound on line-out.
Should we try to activate DAC nid 0x03 or try to move line-out to DAC 0x02? And is either possible through just fiddling with pin_configs (which Takashi preferred), or should we add fixup verbs, or a completely new model? What would upstream prefer in this case?
3) Another strange thing is the controls, there is both Master Playback and Speaker Playback Volumes and Switches, but they both control Volume=0x02 and Switch=0x14, and setting one then getting the other returns the wrong result since they're not updating each other's cached values (I assume). So we should try to get rid of one of these, but how depends on the answer to question 1...
Thanks in advance for helping out!
At Fri, 30 Jul 2010 09:37:33 +0200, David Henningsson wrote:
Here's what I try to fix by playing around with it in hda-emu, it seems like more than one thing is broken here, but let's start with playback. This machine has one internal speaker and one line-out. Codec proc file is attached.
Please give alsa-info.sh output instead. It'll contain more comprehensive information to analyze.
Here's my analysis so far:
- If there's one internal speaker and one line-out (rather than
headphone-out), should the internal speaker auto-mute? What's standard practice?
It's just because the pin is a line-out, no headphone (in addition to the bug below). If the pin is declared as a headphone, the driver turns on the auto-mute function.
- There are two DAC nids, 0x02 and 0x03, but only 0x02 is used (i e
activated on playback). But line-out is connected (via nid 0x0d) to DAC 0x03, so there is no sound on line-out.
Right, it's a missing check of the pin. The pin 0x1b doesn't exist on ALC268, so the parser (shared by both ALC268/269) ignored it. The one-liner below fixes the problem.
Should we try to activate DAC nid 0x03 or try to move line-out to DAC 0x02? And is either possible through just fiddling with pin_configs (which Takashi preferred), or should we add fixup verbs, or a completely new model? What would upstream prefer in this case?
- Another strange thing is the controls, there is both Master Playback
and Speaker Playback Volumes and Switches, but they both control Volume=0x02 and Switch=0x14, and setting one then getting the other returns the wrong result since they're not updating each other's cached values (I assume). So we should try to get rid of one of these, but how depends on the answer to question 1...
Ditto.
thanks,
Takashi
--- diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 14ef383..60bb361 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -13124,6 +13124,7 @@ static int alc268_new_analog_output(struct alc_spec *spec, hda_nid_t nid, dac = 0x02; break; case 0x15: + case 0x1b: case 0x21: /* ALC269vb has this pin, too */ dac = 0x03; break;
2010-07-30 10:11, Takashi Iwai skrev:
At Fri, 30 Jul 2010 09:37:33 +0200, David Henningsson wrote:
Here's what I try to fix by playing around with it in hda-emu, it seems like more than one thing is broken here, but let's start with playback. This machine has one internal speaker and one line-out. Codec proc file is attached.
Please give alsa-info.sh output instead. It'll contain more comprehensive information to analyze.
Sorry. I have an alsa-info of a slightly differently machine here:
http://launchpadlibrarian.net/49532111/alsa-info-forrest
The difference is two outputs (one line, one headphone), and two inputs.
Here's my analysis so far:
- If there's one internal speaker and one line-out (rather than
headphone-out), should the internal speaker auto-mute? What's standard practice?
It's just because the pin is a line-out, no headphone (in addition to the bug below). If the pin is declared as a headphone, the driver turns on the auto-mute function.
- There are two DAC nids, 0x02 and 0x03, but only 0x02 is used (i e
activated on playback). But line-out is connected (via nid 0x0d) to DAC 0x03, so there is no sound on line-out.
Right, it's a missing check of the pin.
Should that have given a warning message, or is it a normal condition to ignore pins?
The pin 0x1b doesn't exist on ALC268, so the parser (shared by both ALC268/269) ignored it. The one-liner below fixes the problem.
Nice, thanks for spotting! I've attached a signed-off commit that un-ignores both 0x1b and 0x1a (the latter one used in the alsa-info link above). Please apply.
At Fri, 30 Jul 2010 13:42:32 +0200, David Henningsson wrote:
2010-07-30 10:11, Takashi Iwai skrev:
At Fri, 30 Jul 2010 09:37:33 +0200, David Henningsson wrote:
Here's what I try to fix by playing around with it in hda-emu, it seems like more than one thing is broken here, but let's start with playback. This machine has one internal speaker and one line-out. Codec proc file is attached.
Please give alsa-info.sh output instead. It'll contain more comprehensive information to analyze.
Sorry. I have an alsa-info of a slightly differently machine here:
http://launchpadlibrarian.net/49532111/alsa-info-forrest
The difference is two outputs (one line, one headphone), and two inputs.
Thanks.
Here's my analysis so far:
- If there's one internal speaker and one line-out (rather than
headphone-out), should the internal speaker auto-mute? What's standard practice?
It's just because the pin is a line-out, no headphone (in addition to the bug below). If the pin is declared as a headphone, the driver turns on the auto-mute function.
- There are two DAC nids, 0x02 and 0x03, but only 0x02 is used (i e
activated on playback). But line-out is connected (via nid 0x0d) to DAC 0x03, so there is no sound on line-out.
Right, it's a missing check of the pin.
Should that have given a warning message, or is it a normal condition to ignore pins?
It depends. I personally think it's good to give a warning, though.
The pin 0x1b doesn't exist on ALC268, so the parser (shared by both ALC268/269) ignored it. The one-liner below fixes the problem.
Nice, thanks for spotting! I've attached a signed-off commit that un-ignores both 0x1b and 0x1a (the latter one used in the alsa-info link above). Please apply.
OK, 0x1a is another thing. As I already applied the fix for 0x1b, I apply it in addition.
But, this isn't the "right" fix -- these pins are actually invalid on ALC268. The parse should be changed to check the pin capability, and assign dynamically.
thanks,
Takashi
participants (2)
-
David Henningsson
-
Takashi Iwai