[alsa-devel] Sound issues with ALC269VB-based hardware
Hi,
So I have this hardware that has a few issues (all tested with tiwai/sound for-next)
Audio out/speakers: - Audio does not work by default. It needs plugging a jack in either headphone or mic. - disabling "Enable Automute" does make it work. But then it doesn't mute when jack is plugged (obviously).
Mic: - needs model=laptop-dmic so that working "Internal Mic 1" appears - "Internal Mic" is useless. - no jack sense, need to select manually "Internal Mic 1" or "Mic" (external) as Input Source
Please find alsa-info.sh with and without model=laptop-dmic in attachement.
Regards,
Anisse
At Tue, 17 Jul 2012 15:11:09 +0200, Anisse Astier wrote:
Hi,
So I have this hardware that has a few issues (all tested with tiwai/sound for-next)
Audio out/speakers:
- Audio does not work by default. It needs plugging a jack in either headphone or mic.
- disabling "Enable Automute" does make it work. But then it doesn't mute when jack is plugged (obviously).
Mic:
- needs model=laptop-dmic so that working "Internal Mic 1" appears
- "Internal Mic" is useless.
- no jack sense, need to select manually "Internal Mic 1" or "Mic" (external) as Input Source
Please find alsa-info.sh with and without model=laptop-dmic in attachement.
All sounds like that your BIOS setup is broken.
You have two internal mics on 0x12 and 0x19. Judging from your comment, the pin 0x12 seems bogus.
The problem of the auto-mute is likely because either the jack detection on pin 0x21 doesn't work, or the pin 0x21 is bogus. You need to figure it out.
Usually the device has a jack detection mechanism, and you can check it via hda-verb or whatever. Plug your headphone to the headphone jack, and check any of the pin reacts to GET_PIN_SENSE verb (call it after setting SET_PIN_SENSE verb). For example,
% hda-verb /dev/snd/hwC0D0 0x21 SET_PIN_SENSE 1 % hda-verb /dev/snd/hwC0D0 0x21 GET_PIN_SENSE 0
Check the value returned from GET_PIN_SENSE. If bit 31 (0x80000000) is set, this is likely the pin of the interest.
Check this for all pins, i.e. between 0x12 and 0x21. Some nodes are no pins, but it doesn't matter much.
Ditto for other external jacks (if any). Figure out which pin corresponds to what I/O. Then you can write your own "patch" file and load it via option.
For details, read Documentation/sound/alsa/HD-Audio.txt.
Takashi
On 07/17/2012 05:05 PM, Takashi Iwai wrote:
Usually the device has a jack detection mechanism, and you can check it via hda-verb or whatever. Plug your headphone to the headphone jack, and check any of the pin reacts to GET_PIN_SENSE verb (call it after setting SET_PIN_SENSE verb). For example,
% hda-verb /dev/snd/hwC0D0 0x21 SET_PIN_SENSE 1
How many codecs really require SET_PIN_SENSE? I have never had a problem with omitting the SET_PIN_SENSE command.
% hda-verb /dev/snd/hwC0D0 0x21 GET_PIN_SENSE 0
Check the value returned from GET_PIN_SENSE. If bit 31 (0x80000000) is set, this is likely the pin of the interest.
Check this for all pins, i.e. between 0x12 and 0x21. Some nodes are no pins, but it doesn't matter much.
Btw, I made convenience script for doing this a year ago. Here it is again.
To install, you put it right next to the hda-analyzer py files, as it makes use of hda_codec.py from hda-analyzer, then run "sudo hda-jack-sense-test.py -a" (see -h for switches to set codec and card indices).
Let me know if you're interested in having this small script in ALSA upstream, and if so, what I should do to get it in there.
At Tue, 17 Jul 2012 17:20:27 +0200, David Henningsson wrote:
On 07/17/2012 05:05 PM, Takashi Iwai wrote:
Usually the device has a jack detection mechanism, and you can check it via hda-verb or whatever. Plug your headphone to the headphone jack, and check any of the pin reacts to GET_PIN_SENSE verb (call it after setting SET_PIN_SENSE verb). For example,
% hda-verb /dev/snd/hwC0D0 0x21 SET_PIN_SENSE 1
How many codecs really require SET_PIN_SENSE? I have never had a problem with omitting the SET_PIN_SENSE command.
Well, in theory, if the codec has the trigger bit set, you always need to give this trigger verb. IIRC, IDT codecs require the trigger explicitly.
% hda-verb /dev/snd/hwC0D0 0x21 GET_PIN_SENSE 0
Check the value returned from GET_PIN_SENSE. If bit 31 (0x80000000) is set, this is likely the pin of the interest.
Check this for all pins, i.e. between 0x12 and 0x21. Some nodes are no pins, but it doesn't matter much.
Btw, I made convenience script for doing this a year ago. Here it is again.
To install, you put it right next to the hda-analyzer py files, as it makes use of hda_codec.py from hda-analyzer, then run "sudo hda-jack-sense-test.py -a" (see -h for switches to set codec and card indices).
Let me know if you're interested in having this small script in ALSA upstream, and if so, what I should do to get it in there.
I guess it can be put to the same repo of hda_analyzer. I left the decision to Jaroslav...
thanks,
Takashi
-- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
[2 hda-jack-sense-test.py <text/x-python (7bit)>] #!/usr/bin/env python # # Written by David Henningsson, Copyright 2011 Canonical Ltd. # Licensed under GPLv2+
# the hda_codec.py file comes from Jaroslav Kysela's hda_analyzer program. from hda_codec import *
def parseoptions(): from optparse import OptionParser parser = OptionParser() parser.add_option("-c", "--card", dest="cardindex", default=0, metavar="CARD", help="card index (as can be seen in /proc/asound/cards)") parser.add_option("-d", "--codec", dest="codecindex", default=0, metavar="CODEC", help="codec device index (as can be seen in /proc/asound/cardX/codecY)") parser.add_option("-a", "--allpins", dest="tryallpins", default=False, action="store_true", help="also check pins which (probably) are not physical jacks") (options, args) = parser.parse_args() return int(options.cardindex), int(options.codecindex), options.tryallpins
def should_check_presence(node, tryallpins): if WIDGET_TYPE_IDS[node.wtype] != 'PIN': return False if tryallpins: return True conn_type = (node.defcfg_pincaps >> 30) & 0x03 if conn_type != 0: # Not a Jack return False if node.defcfg_pincaps & (1 << 8): # Jack has NO_PRESENCE set return False return True
def get_simplecaps(node): conn_type = (node.defcfg_pincaps >> 30) & 0x03 if conn_type == 1: # N/A return 'Not connected' if conn_type == 0: # Jack return "%s %s" % (node.jack_color_name, node.jack_type_name) return "Internal %s" % node.jack_type_name
cardindex, codecindex, tryallpins = parseoptions() codec = HDACodec(cardindex, codecindex) codec.analyze() for nid in codec.nodes: node = codec.get_node(nid) if not should_check_presence(node, tryallpins): continue present = codec.rw(nid, VERBS['GET_PIN_SENSE'], 0) & 0x80000000 print "Pin 0x%.2x (%s): present = %s" % (nid, get_simplecaps(node), "Yes" if present else "No")
At Tue, 17 Jul 2012 17:05:36 +0200, Takashi Iwai wrote:
At Tue, 17 Jul 2012 15:11:09 +0200, Anisse Astier wrote:
Hi,
So I have this hardware that has a few issues (all tested with tiwai/sound for-next)
Audio out/speakers:
- Audio does not work by default. It needs plugging a jack in either headphone or mic.
- disabling "Enable Automute" does make it work. But then it doesn't mute when jack is plugged (obviously).
Mic:
- needs model=laptop-dmic so that working "Internal Mic 1" appears
- "Internal Mic" is useless.
- no jack sense, need to select manually "Internal Mic 1" or "Mic" (external) as Input Source
Please find alsa-info.sh with and without model=laptop-dmic in attachement.
All sounds like that your BIOS setup is broken.
You have two internal mics on 0x12 and 0x19. Judging from your comment, the pin 0x12 seems bogus.
BTW, this revealed a bug in the latest code. Since phantom jack renaming, the account of ctl name index seems broken. With this setup, the driver ended up with the duplicated internal mic phantom jack controls.
So I applied the patch below now.
Takashi
--- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Fix index number conflicts of phantom jacks
Since some jack controls may be renamed as phantom jacks, the existing check for index conflicts doesn't work because it simply compares the name with the last used name, assuming that the controls with the same name continue. Thus, it would result in the duplicated controls when two or more phantom jacks with the very same type exist, and the driver gives up with an error.
This patch fixes the problem by checking the index number conflicts more intensively (but dumbly).
Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/pci/hda/hda_jack.c | 45 ++++++++++++++++++++++++++++++--------------- 1 file changed, 30 insertions(+), 15 deletions(-)
diff --git a/sound/pci/hda/hda_jack.c b/sound/pci/hda/hda_jack.c index 60c976f..aaccc02 100644 --- a/sound/pci/hda/hda_jack.c +++ b/sound/pci/hda/hda_jack.c @@ -314,9 +314,28 @@ int snd_hda_jack_add_kctl(struct hda_codec *codec, hda_nid_t nid, } EXPORT_SYMBOL_HDA(snd_hda_jack_add_kctl);
+/* get the unique index number for the given kctl name */ +static int get_unique_index(struct hda_codec *codec, const char *name, int idx) +{ + struct hda_jack_tbl *jack; + int i, len = strlen(name); + again: + jack = codec->jacktbl.list; + for (i = 0; i < codec->jacktbl.used; i++, jack++) { + /* jack->kctl.id contains "XXX Jack" name string with index */ + if (jack->kctl && + !strncmp(name, jack->kctl->id.name, len) && + !strcmp(" Jack", jack->kctl->id.name + len) && + jack->kctl->id.index == idx) { + idx++; + goto again; + } + } + return idx; +} + static int add_jack_kctl(struct hda_codec *codec, hda_nid_t nid, - const struct auto_pin_cfg *cfg, - char *lastname, int *lastidx) + const struct auto_pin_cfg *cfg) { unsigned int def_conf, conn; char name[44]; @@ -336,10 +355,7 @@ static int add_jack_kctl(struct hda_codec *codec, hda_nid_t nid, if (phantom_jack) /* Example final name: "Internal Mic Phantom Jack" */ strncat(name, " Phantom", sizeof(name) - strlen(name) - 1); - if (!strcmp(name, lastname) && idx == *lastidx) - idx++; - strncpy(lastname, name, sizeof(name)); - *lastidx = idx; + idx = get_unique_index(codec, name, idx); err = __snd_hda_jack_add_kctl(codec, nid, name, idx, phantom_jack); if (err < 0) return err; @@ -356,42 +372,41 @@ int snd_hda_jack_add_kctls(struct hda_codec *codec, const struct auto_pin_cfg *cfg) { const hda_nid_t *p; - int i, err, lastidx = 0; - char lastname[44] = ""; + int i, err;
for (i = 0, p = cfg->line_out_pins; i < cfg->line_outs; i++, p++) { - err = add_jack_kctl(codec, *p, cfg, lastname, &lastidx); + err = add_jack_kctl(codec, *p, cfg); if (err < 0) return err; } for (i = 0, p = cfg->hp_pins; i < cfg->hp_outs; i++, p++) { if (*p == *cfg->line_out_pins) /* might be duplicated */ break; - err = add_jack_kctl(codec, *p, cfg, lastname, &lastidx); + err = add_jack_kctl(codec, *p, cfg); if (err < 0) return err; } for (i = 0, p = cfg->speaker_pins; i < cfg->speaker_outs; i++, p++) { if (*p == *cfg->line_out_pins) /* might be duplicated */ break; - err = add_jack_kctl(codec, *p, cfg, lastname, &lastidx); + err = add_jack_kctl(codec, *p, cfg); if (err < 0) return err; } for (i = 0; i < cfg->num_inputs; i++) { - err = add_jack_kctl(codec, cfg->inputs[i].pin, cfg, lastname, &lastidx); + err = add_jack_kctl(codec, cfg->inputs[i].pin, cfg); if (err < 0) return err; } for (i = 0, p = cfg->dig_out_pins; i < cfg->dig_outs; i++, p++) { - err = add_jack_kctl(codec, *p, cfg, lastname, &lastidx); + err = add_jack_kctl(codec, *p, cfg); if (err < 0) return err; } - err = add_jack_kctl(codec, cfg->dig_in_pin, cfg, lastname, &lastidx); + err = add_jack_kctl(codec, cfg->dig_in_pin, cfg); if (err < 0) return err; - err = add_jack_kctl(codec, cfg->mono_out_pin, cfg, lastname, &lastidx); + err = add_jack_kctl(codec, cfg->mono_out_pin, cfg); if (err < 0) return err; return 0;
On 07/17/2012 05:25 PM, Takashi Iwai wrote:
At Tue, 17 Jul 2012 17:05:36 +0200, Takashi Iwai wrote:
At Tue, 17 Jul 2012 15:11:09 +0200, Anisse Astier wrote:
Hi,
So I have this hardware that has a few issues (all tested with tiwai/sound for-next)
Audio out/speakers:
- Audio does not work by default. It needs plugging a jack in either headphone or mic.
- disabling "Enable Automute" does make it work. But then it doesn't mute when jack is plugged (obviously).
Mic:
- needs model=laptop-dmic so that working "Internal Mic 1" appears
- "Internal Mic" is useless.
- no jack sense, need to select manually "Internal Mic 1" or "Mic" (external) as Input Source
Please find alsa-info.sh with and without model=laptop-dmic in attachement.
All sounds like that your BIOS setup is broken.
You have two internal mics on 0x12 and 0x19. Judging from your comment, the pin 0x12 seems bogus.
BTW, this revealed a bug in the latest code. Since phantom jack renaming, the account of ctl name index seems broken. With this setup, the driver ended up with the duplicated internal mic phantom jack controls.
So I applied the patch below now.
While the new checking is more robust, I fail to see how it happens, and what the phantom jacks have anything to do with it? Both inputs and outputs should be sent to add_jack_kctl in type order, phantom or not.
At Tue, 17 Jul 2012 17:40:14 +0200, David Henningsson wrote:
On 07/17/2012 05:25 PM, Takashi Iwai wrote:
At Tue, 17 Jul 2012 17:05:36 +0200, Takashi Iwai wrote:
At Tue, 17 Jul 2012 15:11:09 +0200, Anisse Astier wrote:
Hi,
So I have this hardware that has a few issues (all tested with tiwai/sound for-next)
Audio out/speakers:
- Audio does not work by default. It needs plugging a jack in either headphone or mic.
- disabling "Enable Automute" does make it work. But then it doesn't mute when jack is plugged (obviously).
Mic:
- needs model=laptop-dmic so that working "Internal Mic 1" appears
- "Internal Mic" is useless.
- no jack sense, need to select manually "Internal Mic 1" or "Mic" (external) as Input Source
Please find alsa-info.sh with and without model=laptop-dmic in attachement.
All sounds like that your BIOS setup is broken.
You have two internal mics on 0x12 and 0x19. Judging from your comment, the pin 0x12 seems bogus.
BTW, this revealed a bug in the latest code. Since phantom jack renaming, the account of ctl name index seems broken. With this setup, the driver ended up with the duplicated internal mic phantom jack controls.
So I applied the patch below now.
While the new checking is more robust, I fail to see how it happens, and what the phantom jacks have anything to do with it?
So far, the code assumed that the pins to be checked are already sorted with the same type, i.e. the lastname string is retained more or less. After the implementation of phantom jacks, the name string may be morphing to a different name in the middle, thus the check with lastname string failed.
Takashi
On Tue, 17 Jul 2012 17:25:48 +0200, Takashi Iwai tiwai@suse.de wrote :
At Tue, 17 Jul 2012 17:05:36 +0200, Takashi Iwai wrote:
All sounds like that your BIOS setup is broken.
You have two internal mics on 0x12 and 0x19. Judging from your comment, the pin 0x12 seems bogus.
Thanks, I will explore this and maybe come back to you.
BTW, this revealed a bug in the latest code. Since phantom jack renaming, the account of ctl name index seems broken. With this setup, the driver ended up with the duplicated internal mic phantom jack controls.
Glad I could help.
So I applied the patch below now.
I'm testing this right now to see if anything changes. (Although it shouldn't if I understand well)
Anisse
At Tue, 17 Jul 2012 17:50:40 +0200, Anisse Astier wrote:
On Tue, 17 Jul 2012 17:25:48 +0200, Takashi Iwai tiwai@suse.de wrote :
At Tue, 17 Jul 2012 17:05:36 +0200, Takashi Iwai wrote:
All sounds like that your BIOS setup is broken.
You have two internal mics on 0x12 and 0x19. Judging from your comment, the pin 0x12 seems bogus.
Thanks, I will explore this and maybe come back to you.
BTW, this revealed a bug in the latest code. Since phantom jack renaming, the account of ctl name index seems broken. With this setup, the driver ended up with the duplicated internal mic phantom jack controls.
Glad I could help.
So I applied the patch below now.
I'm testing this right now to see if anything changes. (Although it shouldn't if I understand well)
Note that this won't help much for the bogus jacks. It will help for avoiding the module loading error (if any).
Takashi
Hi again,
On Tue, 17 Jul 2012 17:50:40 +0200, Anisse Astier anisse@astier.eu wrote :
On Tue, 17 Jul 2012 17:25:48 +0200, Takashi Iwai tiwai@suse.de wrote :
At Tue, 17 Jul 2012 17:05:36 +0200, Takashi Iwai wrote:
All sounds like that your BIOS setup is broken.
You have two internal mics on 0x12 and 0x19. Judging from your comment, the pin 0x12 seems bogus.
Thanks, I will explore this and maybe come back to you.
I used David's tool and came up with this fixup:
[codec] 0x10ec0269 0x1b7da831 0
[pincfg] 0x18 0x411111f0 0x12 0x99a3092f
The problem is I can't seem to get a sense on the mic port (0x19).
I tried it on Windows, and the Realtek HD Audio tool can detect the jack on the headphone and mic port independently. I didn't use any vendor-provided (oem specific) driver on Windows.
Regards,
Anisse
This fixes the internal and external mic on Ordissimo EVE2, also known as Malata PC-B1303.
We still don't know how to detect mic jack like Realtek's windows driver.
Signed-off-by: Anisse Astier anisse@astier.eu --- Hi,
I'm on a dead end on this computer, I can't seem to find how the mic jack presence works. It's always on(presence detected whatever the status) on NID 0x18, the one used for the external mic. I have tried every NID, manually enabling pin_sense on each, but only the headphone jack detection works. The mic sense is nowhere to be seen.
This is on top sound/for-next.
Also, I'd love to have access to an ALC269VB datasheet, or at least know the differences with an ALC269. Do no hesitate to contact me in private.
Regards,
Anisse --- sound/pci/hda/patch_realtek.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 59d2e91..6b0d8fe 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -3225,6 +3225,7 @@ enum { ALC271_FIXUP_HP_GATE_MIC_JACK, ALC269_FIXUP_ACER_AC700, ALC269_FIXUP_LIMIT_INT_MIC_BOOST, + ALC269VB_FIXUP_ORDISSIMO_EVE2, };
static const struct hda_fixup alc269_fixups[] = { @@ -3467,6 +3468,15 @@ static const struct hda_fixup alc269_fixups[] = { .type = HDA_FIXUP_FUNC, .v.func = alc269_fixup_limit_int_mic_boost, }, + [ALC269VB_FIXUP_ORDISSIMO_EVE2] = { + .type = HDA_FIXUP_PINS, + .v.pins = (const struct hda_pintbl[]) { + { 0x12, 0x99a3092f }, /* int-mic */ + { 0x18, 0x03a11d20 }, /* mic */ + { 0x19, 0x411111f0 }, /* Unused bogus pin */ + { } + }, + }, };
static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -3533,6 +3543,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x17aa, 0x2203, "Thinkpad X230 Tablet", ALC269_FIXUP_LENOVO_DOCK), SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K), SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD), + SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ", ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */
#if 0 /* Below is a quirk table taken from the old code.
At Mon, 3 Jun 2013 11:53:10 +0200, Anisse Astier wrote:
This fixes the internal and external mic on Ordissimo EVE2, also known as Malata PC-B1303.
We still don't know how to detect mic jack like Realtek's windows driver.
Signed-off-by: Anisse Astier anisse@astier.eu
Thanks, applied.
Hi,
I'm on a dead end on this computer, I can't seem to find how the mic jack presence works. It's always on(presence detected whatever the status) on NID 0x18, the one used for the external mic. I have tried every NID, manually enabling pin_sense on each, but only the headphone jack detection works. The mic sense is nowhere to be seen.
I also don't know any other method for Realtek. For IDT codecs, there are some devices with GPIO unsol events, but Realtek codecs seem to use only the normal pin detection unsol events.
So, on your device, GET_PIN_SENSE doesn't return the detection bit set? You tried setting SET_PIN_SENSE before GET_PIN_SENSE, right?
Takashi
This is on top sound/for-next.
Also, I'd love to have access to an ALC269VB datasheet, or at least know the differences with an ALC269. Do no hesitate to contact me in private.
Regards,
Anisse
sound/pci/hda/patch_realtek.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 59d2e91..6b0d8fe 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -3225,6 +3225,7 @@ enum { ALC271_FIXUP_HP_GATE_MIC_JACK, ALC269_FIXUP_ACER_AC700, ALC269_FIXUP_LIMIT_INT_MIC_BOOST,
- ALC269VB_FIXUP_ORDISSIMO_EVE2,
};
static const struct hda_fixup alc269_fixups[] = { @@ -3467,6 +3468,15 @@ static const struct hda_fixup alc269_fixups[] = { .type = HDA_FIXUP_FUNC, .v.func = alc269_fixup_limit_int_mic_boost, },
- [ALC269VB_FIXUP_ORDISSIMO_EVE2] = {
.type = HDA_FIXUP_PINS,.v.pins = (const struct hda_pintbl[]) {{ 0x12, 0x99a3092f }, /* int-mic */{ 0x18, 0x03a11d20 }, /* mic */{ 0x19, 0x411111f0 }, /* Unused bogus pin */{ }},- },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -3533,6 +3543,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x17aa, 0x2203, "Thinkpad X230 Tablet", ALC269_FIXUP_LENOVO_DOCK), SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K), SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD),
- SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ", ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */
#if 0 /* Below is a quirk table taken from the old code. -- 1.8.1.4
Hi,
On Wed, 05 Jun 2013 12:26:59 +0200, Takashi Iwai tiwai@suse.de wrote :
At Mon, 3 Jun 2013 11:53:10 +0200, Anisse Astier wrote:
This fixes the internal and external mic on Ordissimo EVE2, also known as Malata PC-B1303.
We still don't know how to detect mic jack like Realtek's windows driver.
Signed-off-by: Anisse Astier anisse@astier.eu
Thanks, applied.
Hi,
I'm on a dead end on this computer, I can't seem to find how the mic jack presence works. It's always on(presence detected whatever the status) on NID 0x18, the one used for the external mic. I have tried every NID, manually enabling pin_sense on each, but only the headphone jack detection works. The mic sense is nowhere to be seen.
I also don't know any other method for Realtek. For IDT codecs, there are some devices with GPIO unsol events, but Realtek codecs seem to use only the normal pin detection unsol events.
So, on your device, GET_PIN_SENSE doesn't return the detection bit set? You tried setting SET_PIN_SENSE before GET_PIN_SENSE, right?
Yes, I tried it although the ALC269 datasheet states that it's a NO-OP.
Anisse
On Wed, 05 Jun 2013 12:26:59 +0200, Takashi Iwai tiwai@suse.de wrote :
I'm on a dead end on this computer, I can't seem to find how the mic jack presence works. It's always on(presence detected whatever the status) on NID 0x18, the one used for the external mic. I have tried every NID, manually enabling pin_sense on each, but only the headphone jack detection works. The mic sense is nowhere to be seen.
I also don't know any other method for Realtek. For IDT codecs, there are some devices with GPIO unsol events, but Realtek codecs seem to use only the normal pin detection unsol events.
So, on your device, GET_PIN_SENSE doesn't return the detection bit set? You tried setting SET_PIN_SENSE before GET_PIN_SENSE, right?
I did more tests, this time using hda-verb directly instead of hda-analyzer tools. And GET_PIN_SENSE does return the correct value… sometimes. (without the need for SET_PIN_SENSE) It seems the value is correct only if queried once every 10 to 15 seconds. Changing the jackpoll_ms argument does not seem to help, so I'll keep digging into it.
Anisse
At Wed, 5 Jun 2013 17:36:43 +0200, Anisse Astier wrote:
On Wed, 05 Jun 2013 12:26:59 +0200, Takashi Iwai tiwai@suse.de wrote :
I'm on a dead end on this computer, I can't seem to find how the mic jack presence works. It's always on(presence detected whatever the status) on NID 0x18, the one used for the external mic. I have tried every NID, manually enabling pin_sense on each, but only the headphone jack detection works. The mic sense is nowhere to be seen.
I also don't know any other method for Realtek. For IDT codecs, there are some devices with GPIO unsol events, but Realtek codecs seem to use only the normal pin detection unsol events.
So, on your device, GET_PIN_SENSE doesn't return the detection bit set? You tried setting SET_PIN_SENSE before GET_PIN_SENSE, right?
I did more tests, this time using hda-verb directly instead of hda-analyzer tools. And GET_PIN_SENSE does return the correct value… sometimes. (without the need for SET_PIN_SENSE) It seems the value is correct only if queried once every 10 to 15 seconds.
Does this mean that it gives a wrong result (i.e. no detect bit although plugged, or vice versa)? Also, is the unsol event issued per jack plug/unplug? If so, is the detection correct just after the unsol event?
Currently we don't need to issue the real GET_PIN_SENSE at every inquiry but only when demanded (e.g. after unsol event, init and resume). If the detection works reliably at these moments, it should be enough in theory.
Takashi
Changing the jackpoll_ms argument does not seem to help, so I'll keep digging into it.
Anisse
On Thu, 06 Jun 2013 11:49:00 +0200, Takashi Iwai tiwai@suse.de wrote :
At Wed, 5 Jun 2013 17:36:43 +0200, Anisse Astier wrote:
On Wed, 05 Jun 2013 12:26:59 +0200, Takashi Iwai tiwai@suse.de wrote :
I'm on a dead end on this computer, I can't seem to find how the mic jack presence works. It's always on(presence detected whatever the status) on NID 0x18, the one used for the external mic. I have tried every NID, manually enabling pin_sense on each, but only the headphone jack detection works. The mic sense is nowhere to be seen.
I also don't know any other method for Realtek. For IDT codecs, there are some devices with GPIO unsol events, but Realtek codecs seem to use only the normal pin detection unsol events.
So, on your device, GET_PIN_SENSE doesn't return the detection bit set? You tried setting SET_PIN_SENSE before GET_PIN_SENSE, right?
I did more tests, this time using hda-verb directly instead of hda-analyzer tools. And GET_PIN_SENSE does return the correct value… sometimes. (without the need for SET_PIN_SENSE) It seems the value is correct only if queried once every 10 to 15 seconds.
Does this mean that it gives a wrong result (i.e. no detect bit although plugged, or vice versa)? Also, is the unsol event issued per
It means it gives detect bit (most of the time) although unplugged.
jack plug/unplug? If so, is the detection correct just after the unsol event?
I don't know yet. From what I observed for now: - there are multiple events in a row. - the event is issued for unplugs, everytime. For plugs, it's only issued sometimes, if we wait long enough. - when unpluged, we get unsol events every 10 seconds or so, even when doing nothing.
To gather more information I added some printfs:
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 55108b5..f6b0592 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -271,6 +271,9 @@ unsigned int snd_hda_codec_read(struct hda_codec *codec, hda_nid_t nid, unsigned int res; if (codec_exec_verb(codec, cmd, &res)) return -1; + if (verb == AC_VERB_GET_PIN_SENSE) { + snd_printd("hda_codec: Getting PIN Sense on nid 0x%x: %08x\n", nid, res); + } return res; } EXPORT_SYMBOL_HDA(snd_hda_codec_read); @@ -292,6 +295,9 @@ int snd_hda_codec_write(struct hda_codec *codec, hda_nid_t nid, int direct, { unsigned int cmd = make_codec_cmd(codec, nid, direct, verb, parm); unsigned int res; + if (verb == AC_VERB_SET_UNSOLICITED_ENABLE) { + snd_printd("hda_codec: Enabling unsolicited on nid 0x%x: %08x\n", nid, parm); + } return codec_exec_verb(codec, cmd, codec->bus->sync_write ? &res : NULL); } @@ -723,7 +729,10 @@ static void process_unsol_events(struct work_struct *work) continue; codec = bus->caddr_tbl[caddr & 0x0f]; if (codec && codec->patch_ops.unsol_event) + { + snd_printd("hda_codec: Unsol event with res 0x%x", res); codec->patch_ops.unsol_event(codec, res); + } } }
Here's an annotated log I collected with this patch:
Mic is NID 0x18, and headphones 0x21. Headphones are unplugged the entire time.
Mic jack is plugged. I unplug it.
[ 444.059100] ALSA sound/pci/hda/hda_codec.c:733 hda_codec: Unsol event with res 0x8000000 [ 445.063294] ALSA sound/pci/hda/hda_intel.c:948 0000:00:1b.0: azx_get_response timeout, polling the codec once: last cmd=0x020c0000 [ 445.063656] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x21: 00000000 [ 445.063739] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 00000000 [ 445.064050] ALSA sound/pci/hda/hda_codec.c:299 hda_codec: Enabling unsolicited on nid 0x21: 00000081 [ 445.064072] ALSA sound/pci/hda/hda_codec.c:299 hda_codec: Enabling unsolicited on nid 0x18: 00000082 [ 445.065180] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 00000000 [ 445.083919] ALSA sound/pci/hda/hda_codec.c:733 hda_codec: Unsol event with res 0x8000010 [ 445.084043] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 80000000
10 seconds later, an unsol events while I did nothing [ 456.097023] ALSA sound/pci/hda/hda_intel.c:948 0000:00:1b.0: azx_get_response timeout, polling the codec once: last cmd=0x020c0000 [ 456.111282] ALSA sound/pci/hda/hda_codec.c:733 hda_codec: Unsol event with res 0x8000000 [ 456.112267] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x21: 00000000 [ 456.112367] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 00000000 [ 456.112677] ALSA sound/pci/hda/hda_codec.c:299 hda_codec: Enabling unsolicited on nid 0x21: 00000081 [ 456.112700] ALSA sound/pci/hda/hda_codec.c:299 hda_codec: Enabling unsolicited on nid 0x18: 00000082 [ 456.113792] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 00000000 [ 456.132647] ALSA sound/pci/hda/hda_codec.c:733 hda_codec: Unsol event with res 0x8000010 [ 456.132722] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 80000000
again [ 466.156558] ALSA sound/pci/hda/hda_codec.c:733 hda_codec: Unsol event with res 0x8000000 [ 466.157490] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x21: 00000000 [ 466.157584] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 00000000 [ 466.157873] ALSA sound/pci/hda/hda_codec.c:299 hda_codec: Enabling unsolicited on nid 0x21: 00000081 [ 466.157959] ALSA sound/pci/hda/hda_codec.c:299 hda_codec: Enabling unsolicited on nid 0x18: 00000082 [ 466.159033] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 00000000 [ 466.177922] ALSA sound/pci/hda/hda_codec.c:733 hda_codec: Unsol event with res 0x8000010 [ 466.178088] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 80000000
and again [ 476.212512] ALSA sound/pci/hda/hda_codec.c:733 hda_codec: Unsol event with res 0x8000000 [ 477.214751] ALSA sound/pci/hda/hda_intel.c:948 0000:00:1b.0: azx_get_response timeout, polling the codec once: last cmd=0x020c0000 [ 477.215049] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x21: 00000000 [ 477.215158] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 00000000 [ 477.215519] ALSA sound/pci/hda/hda_codec.c:299 hda_codec: Enabling unsolicited on nid 0x21: 00000081 [ 477.215553] ALSA sound/pci/hda/hda_codec.c:299 hda_codec: Enabling unsolicited on nid 0x18: 00000082 [ 477.216926] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 00000000 [ 477.237333] ALSA sound/pci/hda/hda_codec.c:733 hda_codec: Unsol event with res 0x8000010 [ 477.237404] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 80000000
here I plug the mic [ 480.215725] ALSA sound/pci/hda/hda_codec.c:733 hda_codec: Unsol event with res 0x8000000 [ 480.215824] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 00000000 [ 480.279747] ALSA sound/pci/hda/hda_codec.c:733 hda_codec: Unsol event with res 0x8000010 [ 480.279809] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 80000000
and unplug it [ 506.284318] ALSA sound/pci/hda/hda_codec.c:733 hda_codec: Unsol event with res 0x8000000 [ 506.285313] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x21: 00000000 [ 506.285413] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 00000000 [ 506.285853] ALSA sound/pci/hda/hda_codec.c:299 hda_codec: Enabling unsolicited on nid 0x21: 00000081 [ 506.285888] ALSA sound/pci/hda/hda_codec.c:299 hda_codec: Enabling unsolicited on nid 0x18: 00000082 [ 506.286878] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 00000000 [ 506.305697] ALSA sound/pci/hda/hda_codec.c:733 hda_codec: Unsol event with res 0x8000010 [ 506.305779] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 80000000
10 seconds later, an automatic unsolicited event [ 516.308248] ALSA sound/pci/hda/hda_codec.c:733 hda_codec: Unsol event with res 0x8000000 [ 516.309285] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x21: 00000000 [ 516.309384] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 00000000 [ 516.309779] ALSA sound/pci/hda/hda_codec.c:299 hda_codec: Enabling unsolicited on nid 0x21: 00000081 [ 516.309813] ALSA sound/pci/hda/hda_codec.c:299 hda_codec: Enabling unsolicited on nid 0x18: 00000082 [ 516.310837] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 00000000 [ 516.329607] ALSA sound/pci/hda/hda_codec.c:733 hda_codec: Unsol event with res 0x8000010 [ 516.329682] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 80000000
I plug it again [ 520.674375] ALSA sound/pci/hda/hda_codec.c:733 hda_codec: Unsol event with res 0x8000008 [ 520.674512] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 00000000 [ 520.674665] ALSA sound/pci/hda/hda_codec.c:733 hda_codec: Unsol event with res 0x4000008 [ 520.674741] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x21: 80000000 [ 520.695707] ALSA sound/pci/hda/hda_codec.c:733 hda_codec: Unsol event with res 0x8000010 [ 520.695791] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x18: 80000000 [ 520.695863] ALSA sound/pci/hda/hda_codec.c:733 hda_codec: Unsol event with res 0x4000010 [ 520.695923] ALSA sound/pci/hda/hda_codec.c:275 hda_codec: Getting PIN Sense on nid 0x21: 00000000
Currently we don't need to issue the real GET_PIN_SENSE at every inquiry but only when demanded (e.g. after unsol event, init and resume). If the detection works reliably at these moments, it should be enough in theory.
I'm not sure that would be enough according to what I'm observing.
Anisse
On Thu, 6 Jun 2013 18:14:58 +0200, Anisse Astier anisse@astier.eu wrote :
On Thu, 06 Jun 2013 11:49:00 +0200, Takashi Iwai tiwai@suse.de wrote :
At Wed, 5 Jun 2013 17:36:43 +0200, Anisse Astier wrote:
On Wed, 05 Jun 2013 12:26:59 +0200, Takashi Iwai tiwai@suse.de wrote :
I'm on a dead end on this computer, I can't seem to find how the mic jack presence works. It's always on(presence detected whatever the status) on NID 0x18, the one used for the external mic. I have tried every NID, manually enabling pin_sense on each, but only the headphone jack detection works. The mic sense is nowhere to be seen.
I also don't know any other method for Realtek. For IDT codecs, there are some devices with GPIO unsol events, but Realtek codecs seem to use only the normal pin detection unsol events.
So, on your device, GET_PIN_SENSE doesn't return the detection bit set? You tried setting SET_PIN_SENSE before GET_PIN_SENSE, right?
I did more tests, this time using hda-verb directly instead of hda-analyzer tools. And GET_PIN_SENSE does return the correct value… sometimes. (without the need for SET_PIN_SENSE) It seems the value is correct only if queried once every 10 to 15 seconds.
Does this mean that it gives a wrong result (i.e. no detect bit although plugged, or vice versa)? Also, is the unsol event issued per
It means it gives detect bit (most of the time) although unplugged.
jack plug/unplug? If so, is the detection correct just after the unsol event?
I don't know yet. From what I observed for now:
- there are multiple events in a row.
- the event is issued for unplugs, everytime. For plugs, it's only issued sometimes, if we wait long enough.
- when unpluged, we get unsol events every 10 seconds or so, even when doing nothing.
Also: the second GET_PIN_SENSE seems to be always correct according to the data collected. I don't know what to make of it.
At Thu, 6 Jun 2013 18:14:58 +0200, Anisse Astier wrote:
On Thu, 06 Jun 2013 11:49:00 +0200, Takashi Iwai tiwai@suse.de wrote :
At Wed, 5 Jun 2013 17:36:43 +0200, Anisse Astier wrote:
On Wed, 05 Jun 2013 12:26:59 +0200, Takashi Iwai tiwai@suse.de wrote :
I'm on a dead end on this computer, I can't seem to find how the mic jack presence works. It's always on(presence detected whatever the status) on NID 0x18, the one used for the external mic. I have tried every NID, manually enabling pin_sense on each, but only the headphone jack detection works. The mic sense is nowhere to be seen.
I also don't know any other method for Realtek. For IDT codecs, there are some devices with GPIO unsol events, but Realtek codecs seem to use only the normal pin detection unsol events.
So, on your device, GET_PIN_SENSE doesn't return the detection bit set? You tried setting SET_PIN_SENSE before GET_PIN_SENSE, right?
I did more tests, this time using hda-verb directly instead of hda-analyzer tools. And GET_PIN_SENSE does return the correct value… sometimes. (without the need for SET_PIN_SENSE) It seems the value is correct only if queried once every 10 to 15 seconds.
Does this mean that it gives a wrong result (i.e. no detect bit although plugged, or vice versa)? Also, is the unsol event issued per
It means it gives detect bit (most of the time) although unplugged.
jack plug/unplug? If so, is the detection correct just after the unsol event?
I don't know yet. From what I observed for now:
- there are multiple events in a row.
- the event is issued for unplugs, everytime. For plugs, it's only issued sometimes, if we wait long enough.
- when unpluged, we get unsol events every 10 seconds or so, even when doing nothing.
To gather more information I added some printfs:
FYI, you can track the tracepoints instead of printks. See HD-Audio.txt "Tracepoints" section.
Takashi
participants (3)
-
Anisse Astier -
David Henningsson -
Takashi Iwai