Re: [alsa-devel] model needed for Clevo P150HM (Realtek ALC892)
At Thu, 30 Jun 2011 08:30:10 +0200, Julian Sikorski wrote:
W dniu 30.06.2011 07:26, Takashi Iwai pisze:
At Wed, 29 Jun 2011 21:29:38 +0200, Julian Sikorski wrote:
I also tried merging sound-2.6/master with Linus's tree, but this also did not help.
It's really strange. Are you sure that this is the kernel you modified properly? Before further debugging, check two things:
Run "git log sound/pci/hda/patch_realtek.c" and the first few entries, whether they come from sound git tree. For example, check the commit below is contained:
commit 7ec9c6ccc6007b14a916021d4ba7ffbcc7822ae3 Author: Takashi Iwai tiwai@suse.de Date: Mon Jun 27 15:53:38 2011 +0200
ALSA: hda - Fix volume-init for ALC259 with invalid widget caps
commit 0b0c8490670a77b937f502491ae9d5236aa4054a Author: Takashi Iwai tiwai@suse.de Date: Tue Jun 28 12:45:47 2011 +0200
ALSA: hda - Create snd_hda_get_conn_index() helper function Create snd_hda_get_conn_index() helper function for obtaining the connection index of the widget. Replaced the similar codes used in several codec-drivers with this common helper. Signed-off-by: Takashi Iwai <tiwai@suse.de>
commit 4f574b7b1a1cc8aac617e938459e8f03a641e678 Author: Takashi Iwai tiwai@suse.de Date: Mon Jun 27 16:17:07 2011 +0200
ALSA: hda - More volume-init fixes for ALC267 codec More similar fixes like previous commits: handle the exceptional case like ALC267 where no volume amp is found in ADC widget but in the capsrc widget instead. Also minor checks for avoiding possible erros: no connection-select when the pin has a single selection, and add beep verbs only when the 0x1d is used for beep. Signed-off-by: Takashi Iwai <tiwai@suse.de>
To be even more sure, I re-synced your branch again and built a new kernel. I am attaching patch_realtek.c file being built. Fresh alsa-info.sh is here: http://www.alsa-project.org/db/?f=5051b2cb788b1db4273e06e98a78783dd0ec679f
OK, then it's correct.
- Confirm the running kernel is what you really built and installed. You can modify the suffix via $CONFIG_LOCALVERSION in .config file. Name it uniquely, rebuild, re-install and reboot. The new suffix should appear in the output of "uname -r".
belegdol4 is the suffix I added: $ uname -r 3.0-0.rc5.git0.1.belegdol4.fc15.x86_64
- Once when these are correct, check /proc/asound/card0/codec#0: the widget NID 0x02 should contain "Speaker Playback Volume" instead of "Headphone Playback Volume" with the latest driver.
Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Headphone Playback Volume", index=0, device=0
Perhaps I need to specify a correct model to enable this code?
No, you shouldn't pass any model option.
Could you apply the patch below to add some debug prints, and give the relevant kernel messages you get? Just grep lines with 'XXX'.
Takashi
--- diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 7b96dce..3134555 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -18770,8 +18770,10 @@ static hda_nid_t alc_auto_look_for_dac(struct hda_codec *codec, hda_nid_t pin) static hda_nid_t get_dac_if_single(struct hda_codec *codec, hda_nid_t pin) { hda_nid_t sel = alc_go_down_to_selector(codec, pin); - if (snd_hda_get_conn_list(codec, sel, NULL) == 1) + if (snd_hda_get_conn_list(codec, sel, NULL) == 1) { + printk(KERN_DEBUG "XXX pin %x coupled with a single DAC\n", pin); return alc_auto_look_for_dac(codec, pin); + } return 0; }
@@ -18783,6 +18785,7 @@ static int alc662_auto_fill_dac_nids(struct hda_codec *codec) bool redone; int i;
+ printk(KERN_DEBUG "XXX alc662_auto_fill_dac_nids called\n"); again: spec->multiout.num_dacs = 0; spec->multiout.hp_nid = 0; @@ -18813,6 +18816,7 @@ static int alc662_auto_fill_dac_nids(struct hda_codec *codec) * checking the hard-wired DACs */ redone = true; + printk(KERN_DEBUG "XXX redoing...\n"); goto again; } } @@ -18826,6 +18830,17 @@ static int alc662_auto_fill_dac_nids(struct hda_codec *codec) sizeof(hda_nid_t) * (cfg->line_outs - i - 1)); }
+ printk(KERN_DEBUG "XXX filled dacs: %x/%x/%x/%x/%x, hp %x, ext %x/%x/%x\n", + spec->private_dac_nids[0], + spec->private_dac_nids[1], + spec->private_dac_nids[2], + spec->private_dac_nids[3], + spec->private_dac_nids[4], + spec->multiout.hp_nid, + spec->multiout.extra_out_nid[0], + spec->multiout.extra_out_nid[1], + spec->multiout.extra_out_nid[2]); + return 0; }
@@ -18877,6 +18892,7 @@ static int alc662_auto_create_multi_out_ctls(struct hda_codec *codec, mix = alc_auto_dac_to_mix(codec, pin, nid); if (!mix) continue; + printk(KERN_DEBUG "XXX create mixer ch %d pin %x dac %x mix %x\n", i, pin, nid, mix); name = alc_get_line_out_pfx(spec, i, true, &index); if (!name) { /* Center/LFE */ @@ -19026,6 +19042,7 @@ static int alc_auto_fill_multi_ios(struct hda_codec *codec, dac = alc_auto_look_for_dac(codec, nid); if (!dac) continue; + printk(KERN_DEBUG "XXX added multi-io pin %x, dac %x\n", nid, dac); spec->multi_io[num_pins].pin = nid; spec->multi_io[num_pins].dac = dac; num_pins++; @@ -19128,6 +19145,7 @@ static int alc_auto_add_multi_channel_mode(struct hda_codec *codec,
if (cfg->line_out_type == AUTO_PIN_SPEAKER_OUT && cfg->hp_outs == 1) { /* use HP as primary out */ + printk(KERN_DEBUG "XXX swap primary out to HP\n"); cfg->speaker_outs = cfg->line_outs; memcpy(cfg->speaker_pins, cfg->line_out_pins, sizeof(cfg->speaker_pins));
W dniu 30.06.2011 08:54, Takashi Iwai pisze:
At Thu, 30 Jun 2011 08:30:10 +0200, Julian Sikorski wrote:
W dniu 30.06.2011 07:26, Takashi Iwai pisze:
At Wed, 29 Jun 2011 21:29:38 +0200, Julian Sikorski wrote:
I also tried merging sound-2.6/master with Linus's tree, but this also did not help.
It's really strange. Are you sure that this is the kernel you modified properly? Before further debugging, check two things:
Run "git log sound/pci/hda/patch_realtek.c" and the first few entries, whether they come from sound git tree. For example, check the commit below is contained:
commit 7ec9c6ccc6007b14a916021d4ba7ffbcc7822ae3 Author: Takashi Iwai tiwai@suse.de Date: Mon Jun 27 15:53:38 2011 +0200
ALSA: hda - Fix volume-init for ALC259 with invalid widget caps
commit 0b0c8490670a77b937f502491ae9d5236aa4054a Author: Takashi Iwai tiwai@suse.de Date: Tue Jun 28 12:45:47 2011 +0200
ALSA: hda - Create snd_hda_get_conn_index() helper function Create snd_hda_get_conn_index() helper function for obtaining the connection index of the widget. Replaced the similar codes used in several codec-drivers with this common helper. Signed-off-by: Takashi Iwai <tiwai@suse.de>
commit 4f574b7b1a1cc8aac617e938459e8f03a641e678 Author: Takashi Iwai tiwai@suse.de Date: Mon Jun 27 16:17:07 2011 +0200
ALSA: hda - More volume-init fixes for ALC267 codec More similar fixes like previous commits: handle the exceptional case like ALC267 where no volume amp is found in ADC widget but in the capsrc widget instead. Also minor checks for avoiding possible erros: no connection-select when the pin has a single selection, and add beep verbs only when the 0x1d is used for beep. Signed-off-by: Takashi Iwai <tiwai@suse.de>
To be even more sure, I re-synced your branch again and built a new kernel. I am attaching patch_realtek.c file being built. Fresh alsa-info.sh is here: http://www.alsa-project.org/db/?f=5051b2cb788b1db4273e06e98a78783dd0ec679f
OK, then it's correct.
- Confirm the running kernel is what you really built and installed. You can modify the suffix via $CONFIG_LOCALVERSION in .config file. Name it uniquely, rebuild, re-install and reboot. The new suffix should appear in the output of "uname -r".
belegdol4 is the suffix I added: $ uname -r 3.0-0.rc5.git0.1.belegdol4.fc15.x86_64
- Once when these are correct, check /proc/asound/card0/codec#0: the widget NID 0x02 should contain "Speaker Playback Volume" instead of "Headphone Playback Volume" with the latest driver.
Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Headphone Playback Volume", index=0, device=0
Perhaps I need to specify a correct model to enable this code?
No, you shouldn't pass any model option.
Could you apply the patch below to add some debug prints, and give the relevant kernel messages you get? Just grep lines with 'XXX'.
Takashi
Here you go:
$ dmesg | grep XXX [ 12.789557] XXX alc662_auto_fill_dac_nids called [ 12.789716] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 12.789718] XXX swap primary out to HP [ 12.789719] XXX alc662_auto_fill_dac_nids called [ 12.789845] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 12.790094] XXX added multi-io pin 1a, dac 3 [ 12.790343] XXX added multi-io pin 18, dac 4 [ 12.790347] XXX create mixer ch 0 pin 1b dac 2 mix c [ 12.790351] XXX create mixer ch 1 pin 1a dac 3 mix d [ 12.790354] XXX create mixer ch 2 pin 18 dac 4 mix e
Julian
At Thu, 30 Jun 2011 19:00:44 +0200, Julian Sikorski wrote:
W dniu 30.06.2011 08:54, Takashi Iwai pisze:
At Thu, 30 Jun 2011 08:30:10 +0200, Julian Sikorski wrote:
W dniu 30.06.2011 07:26, Takashi Iwai pisze:
At Wed, 29 Jun 2011 21:29:38 +0200, Julian Sikorski wrote:
I also tried merging sound-2.6/master with Linus's tree, but this also did not help.
It's really strange. Are you sure that this is the kernel you modified properly? Before further debugging, check two things:
Run "git log sound/pci/hda/patch_realtek.c" and the first few entries, whether they come from sound git tree. For example, check the commit below is contained:
commit 7ec9c6ccc6007b14a916021d4ba7ffbcc7822ae3 Author: Takashi Iwai tiwai@suse.de Date: Mon Jun 27 15:53:38 2011 +0200
ALSA: hda - Fix volume-init for ALC259 with invalid widget caps
commit 0b0c8490670a77b937f502491ae9d5236aa4054a Author: Takashi Iwai tiwai@suse.de Date: Tue Jun 28 12:45:47 2011 +0200
ALSA: hda - Create snd_hda_get_conn_index() helper function Create snd_hda_get_conn_index() helper function for obtaining the connection index of the widget. Replaced the similar codes used in several codec-drivers with this common helper. Signed-off-by: Takashi Iwai <tiwai@suse.de>
commit 4f574b7b1a1cc8aac617e938459e8f03a641e678 Author: Takashi Iwai tiwai@suse.de Date: Mon Jun 27 16:17:07 2011 +0200
ALSA: hda - More volume-init fixes for ALC267 codec More similar fixes like previous commits: handle the exceptional case like ALC267 where no volume amp is found in ADC widget but in the capsrc widget instead. Also minor checks for avoiding possible erros: no connection-select when the pin has a single selection, and add beep verbs only when the 0x1d is used for beep. Signed-off-by: Takashi Iwai <tiwai@suse.de>
To be even more sure, I re-synced your branch again and built a new kernel. I am attaching patch_realtek.c file being built. Fresh alsa-info.sh is here: http://www.alsa-project.org/db/?f=5051b2cb788b1db4273e06e98a78783dd0ec679f
OK, then it's correct.
- Confirm the running kernel is what you really built and installed. You can modify the suffix via $CONFIG_LOCALVERSION in .config file. Name it uniquely, rebuild, re-install and reboot. The new suffix should appear in the output of "uname -r".
belegdol4 is the suffix I added: $ uname -r 3.0-0.rc5.git0.1.belegdol4.fc15.x86_64
- Once when these are correct, check /proc/asound/card0/codec#0: the widget NID 0x02 should contain "Speaker Playback Volume" instead of "Headphone Playback Volume" with the latest driver.
Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Headphone Playback Volume", index=0, device=0
Perhaps I need to specify a correct model to enable this code?
No, you shouldn't pass any model option.
Could you apply the patch below to add some debug prints, and give the relevant kernel messages you get? Just grep lines with 'XXX'.
Takashi
Here you go:
$ dmesg | grep XXX [ 12.789557] XXX alc662_auto_fill_dac_nids called [ 12.789716] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 12.789718] XXX swap primary out to HP [ 12.789719] XXX alc662_auto_fill_dac_nids called [ 12.789845] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0
OK, at this point, something is wrong.
Could you try the patch again (after reverting the previous debug patch)? This will give a bit more outputs.
I have a vague idea what could be wrong now. Maybe the connection list is differently returned from the real hardware unlike the emulator. But I need to see it in more details.
thanks,
Takashi
--- diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 7b96dce..0a28371 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -18770,8 +18770,11 @@ static hda_nid_t alc_auto_look_for_dac(struct hda_codec *codec, hda_nid_t pin) static hda_nid_t get_dac_if_single(struct hda_codec *codec, hda_nid_t pin) { hda_nid_t sel = alc_go_down_to_selector(codec, pin); - if (snd_hda_get_conn_list(codec, sel, NULL) == 1) + printk(KERN_DEBUG "XXX check single for pin %x, sel %x\n", pin, sel); + if (snd_hda_get_conn_list(codec, sel, NULL) == 1) { + printk(KERN_DEBUG "XXX pin %x coupled with a single DAC\n", pin); return alc_auto_look_for_dac(codec, pin); + } return 0; }
@@ -18783,6 +18786,13 @@ static int alc662_auto_fill_dac_nids(struct hda_codec *codec) bool redone; int i;
+ printk(KERN_DEBUG "XXX alc662_auto_fill_dac_nids called\n"); + printk(KERN_DEBUG "XXX line_outs=%d, %x/%x/%x\n", + cfg->line_outs, cfg->line_out_pins[0], cfg->line_out_pins[1], cfg->line_out_pins[2]); + printk(KERN_DEBUG "XXX hp_outs=%d, %x/%x/%x\n", + cfg->hp_outs, cfg->hp_pins[0], cfg->hp_pins[1], cfg->hp_pins[2]); + printk(KERN_DEBUG "XXX spk_outs=%d, %x/%x/%x\n", + cfg->speaker_outs, cfg->speaker_pins[0], cfg->speaker_pins[1], cfg->speaker_pins[2]); again: spec->multiout.num_dacs = 0; spec->multiout.hp_nid = 0; @@ -18813,6 +18823,7 @@ static int alc662_auto_fill_dac_nids(struct hda_codec *codec) * checking the hard-wired DACs */ redone = true; + printk(KERN_DEBUG "XXX redoing...\n"); goto again; } } @@ -18826,6 +18837,17 @@ static int alc662_auto_fill_dac_nids(struct hda_codec *codec) sizeof(hda_nid_t) * (cfg->line_outs - i - 1)); }
+ printk(KERN_DEBUG "XXX filled dacs: %x/%x/%x/%x/%x, hp %x, ext %x/%x/%x\n", + spec->private_dac_nids[0], + spec->private_dac_nids[1], + spec->private_dac_nids[2], + spec->private_dac_nids[3], + spec->private_dac_nids[4], + spec->multiout.hp_nid, + spec->multiout.extra_out_nid[0], + spec->multiout.extra_out_nid[1], + spec->multiout.extra_out_nid[2]); + return 0; }
@@ -18877,6 +18899,7 @@ static int alc662_auto_create_multi_out_ctls(struct hda_codec *codec, mix = alc_auto_dac_to_mix(codec, pin, nid); if (!mix) continue; + printk(KERN_DEBUG "XXX create mixer ch %d pin %x dac %x mix %x\n", i, pin, nid, mix); name = alc_get_line_out_pfx(spec, i, true, &index); if (!name) { /* Center/LFE */ @@ -19026,6 +19049,7 @@ static int alc_auto_fill_multi_ios(struct hda_codec *codec, dac = alc_auto_look_for_dac(codec, nid); if (!dac) continue; + printk(KERN_DEBUG "XXX added multi-io pin %x, dac %x\n", nid, dac); spec->multi_io[num_pins].pin = nid; spec->multi_io[num_pins].dac = dac; num_pins++; @@ -19128,13 +19152,16 @@ static int alc_auto_add_multi_channel_mode(struct hda_codec *codec,
if (cfg->line_out_type == AUTO_PIN_SPEAKER_OUT && cfg->hp_outs == 1) { /* use HP as primary out */ + printk(KERN_DEBUG "XXX swap primary out to HP\n"); cfg->speaker_outs = cfg->line_outs; memcpy(cfg->speaker_pins, cfg->line_out_pins, sizeof(cfg->speaker_pins)); + printk(KERN_DEBUG "XXX spk=%x\n", cfg->speaker_pins[0]); cfg->line_outs = cfg->hp_outs; memcpy(cfg->line_out_pins, cfg->hp_pins, sizeof(cfg->hp_pins)); cfg->hp_outs = 0; memset(cfg->hp_pins, 0, sizeof(cfg->hp_pins)); + printk(KERN_DEBUG "XXX line=%x\n", cfg->line_out_pins[0]); cfg->line_out_type = AUTO_PIN_HP_OUT; if (fill_dac) fill_dac(codec);
W dniu 30.06.2011 19:41, Takashi Iwai pisze:
At Thu, 30 Jun 2011 19:00:44 +0200, Julian Sikorski wrote:
W dniu 30.06.2011 08:54, Takashi Iwai pisze:
At Thu, 30 Jun 2011 08:30:10 +0200, Julian Sikorski wrote:
W dniu 30.06.2011 07:26, Takashi Iwai pisze:
At Wed, 29 Jun 2011 21:29:38 +0200, Julian Sikorski wrote:
I also tried merging sound-2.6/master with Linus's tree, but this also did not help.
It's really strange. Are you sure that this is the kernel you modified properly? Before further debugging, check two things:
Run "git log sound/pci/hda/patch_realtek.c" and the first few entries, whether they come from sound git tree. For example, check the commit below is contained:
commit 7ec9c6ccc6007b14a916021d4ba7ffbcc7822ae3 Author: Takashi Iwai tiwai@suse.de Date: Mon Jun 27 15:53:38 2011 +0200
ALSA: hda - Fix volume-init for ALC259 with invalid widget caps
commit 0b0c8490670a77b937f502491ae9d5236aa4054a Author: Takashi Iwai tiwai@suse.de Date: Tue Jun 28 12:45:47 2011 +0200
ALSA: hda - Create snd_hda_get_conn_index() helper function Create snd_hda_get_conn_index() helper function for obtaining the connection index of the widget. Replaced the similar codes used in several codec-drivers with this common helper. Signed-off-by: Takashi Iwai <tiwai@suse.de>
commit 4f574b7b1a1cc8aac617e938459e8f03a641e678 Author: Takashi Iwai tiwai@suse.de Date: Mon Jun 27 16:17:07 2011 +0200
ALSA: hda - More volume-init fixes for ALC267 codec More similar fixes like previous commits: handle the exceptional case like ALC267 where no volume amp is found in ADC widget but in the capsrc widget instead. Also minor checks for avoiding possible erros: no connection-select when the pin has a single selection, and add beep verbs only when the 0x1d is used for beep. Signed-off-by: Takashi Iwai <tiwai@suse.de>
To be even more sure, I re-synced your branch again and built a new kernel. I am attaching patch_realtek.c file being built. Fresh alsa-info.sh is here: http://www.alsa-project.org/db/?f=5051b2cb788b1db4273e06e98a78783dd0ec679f
OK, then it's correct.
- Confirm the running kernel is what you really built and installed. You can modify the suffix via $CONFIG_LOCALVERSION in .config file. Name it uniquely, rebuild, re-install and reboot. The new suffix should appear in the output of "uname -r".
belegdol4 is the suffix I added: $ uname -r 3.0-0.rc5.git0.1.belegdol4.fc15.x86_64
- Once when these are correct, check /proc/asound/card0/codec#0: the widget NID 0x02 should contain "Speaker Playback Volume" instead of "Headphone Playback Volume" with the latest driver.
Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Headphone Playback Volume", index=0, device=0
Perhaps I need to specify a correct model to enable this code?
No, you shouldn't pass any model option.
Could you apply the patch below to add some debug prints, and give the relevant kernel messages you get? Just grep lines with 'XXX'.
Takashi
Here you go:
$ dmesg | grep XXX [ 12.789557] XXX alc662_auto_fill_dac_nids called [ 12.789716] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 12.789718] XXX swap primary out to HP [ 12.789719] XXX alc662_auto_fill_dac_nids called [ 12.789845] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0
OK, at this point, something is wrong.
Could you try the patch again (after reverting the previous debug patch)? This will give a bit more outputs.
I have a vague idea what could be wrong now. Maybe the connection list is differently returned from the real hardware unlike the emulator. But I need to see it in more details.
thanks,
Takashi
No problem:
$ dmesg | grep XXX [ 14.813013] XXX alc662_auto_fill_dac_nids called [ 14.813015] XXX line_outs=1, 14/0/0 [ 14.813016] XXX hp_outs=1, 1b/0/0 [ 14.813018] XXX spk_outs=0, 0/0/0 [ 14.813186] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 14.813187] XXX swap primary out to HP [ 14.813188] XXX spk=14 [ 14.813190] XXX line=1b [ 14.813191] XXX alc662_auto_fill_dac_nids called [ 14.813192] XXX line_outs=1, 1b/0/0 [ 14.813194] XXX hp_outs=0, 0/0/0 [ 14.813195] XXX spk_outs=1, 14/0/0 [ 14.813311] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 14.813560] XXX added multi-io pin 1a, dac 3 [ 14.813814] XXX added multi-io pin 18, dac 4 [ 14.813818] XXX create mixer ch 0 pin 1b dac 2 mix c [ 14.813821] XXX create mixer ch 1 pin 1a dac 3 mix d [ 14.813825] XXX create mixer ch 2 pin 18 dac 4 mix e
Julian
At Thu, 30 Jun 2011 20:09:49 +0200, Julian Sikorski wrote:
$ dmesg | grep XXX [ 14.813013] XXX alc662_auto_fill_dac_nids called [ 14.813015] XXX line_outs=1, 14/0/0 [ 14.813016] XXX hp_outs=1, 1b/0/0 [ 14.813018] XXX spk_outs=0, 0/0/0 [ 14.813186] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 14.813187] XXX swap primary out to HP [ 14.813188] XXX spk=14 [ 14.813190] XXX line=1b [ 14.813191] XXX alc662_auto_fill_dac_nids called [ 14.813192] XXX line_outs=1, 1b/0/0 [ 14.813194] XXX hp_outs=0, 0/0/0 [ 14.813195] XXX spk_outs=1, 14/0/0 [ 14.813311] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 14.813560] XXX added multi-io pin 1a, dac 3 [ 14.813814] XXX added multi-io pin 18, dac 4 [ 14.813818] XXX create mixer ch 0 pin 1b dac 2 mix c [ 14.813821] XXX create mixer ch 1 pin 1a dac 3 mix d [ 14.813825] XXX create mixer ch 2 pin 18 dac 4 mix e
How about the fix below?
Takashi
--- diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 7b96dce..757a8a3 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -18780,7 +18780,7 @@ static int alc662_auto_fill_dac_nids(struct hda_codec *codec) { struct alc_spec *spec = codec->spec; const struct auto_pin_cfg *cfg = &spec->autocfg; - bool redone; + bool redone = false; int i;
again:
W dniu 30.06.2011 21:28, Takashi Iwai pisze:
At Thu, 30 Jun 2011 20:09:49 +0200, Julian Sikorski wrote:
$ dmesg | grep XXX [ 14.813013] XXX alc662_auto_fill_dac_nids called [ 14.813015] XXX line_outs=1, 14/0/0 [ 14.813016] XXX hp_outs=1, 1b/0/0 [ 14.813018] XXX spk_outs=0, 0/0/0 [ 14.813186] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 14.813187] XXX swap primary out to HP [ 14.813188] XXX spk=14 [ 14.813190] XXX line=1b [ 14.813191] XXX alc662_auto_fill_dac_nids called [ 14.813192] XXX line_outs=1, 1b/0/0 [ 14.813194] XXX hp_outs=0, 0/0/0 [ 14.813195] XXX spk_outs=1, 14/0/0 [ 14.813311] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 14.813560] XXX added multi-io pin 1a, dac 3 [ 14.813814] XXX added multi-io pin 18, dac 4 [ 14.813818] XXX create mixer ch 0 pin 1b dac 2 mix c [ 14.813821] XXX create mixer ch 1 pin 1a dac 3 mix d [ 14.813825] XXX create mixer ch 2 pin 18 dac 4 mix e
How about the fix below?
Takashi
It works, thanks! In more detail, the Speaker/Headphone situation is back to 2.6.38 state - you can regulate them independently, but muting one mutes the other. LFE/Center and Surround keep working correctly too. The new output of alsa-info.sh: http://www.alsa-project.org/db/?f=45bc0df9747371b348bde6c4aa508b2ba44aff47
$ dmesg | grep XXX [ 13.944531] XXX alc662_auto_fill_dac_nids called [ 13.944533] XXX line_outs=1, 14/0/0 [ 13.944534] XXX hp_outs=1, 1b/0/0 [ 13.944536] XXX spk_outs=0, 0/0/0 [ 13.944631] XXX check single for pin 14, sel 14 [ 13.944632] XXX pin 14 coupled with a single DAC [ 13.944843] XXX check single for pin 1b, sel 1b [ 13.944845] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 13.944847] XXX swap primary out to HP [ 13.944848] XXX spk=14 [ 13.944849] XXX line=1b [ 13.944850] XXX alc662_auto_fill_dac_nids called [ 13.944852] XXX line_outs=1, 1b/0/0 [ 13.944853] XXX hp_outs=0, 0/0/0 [ 13.944855] XXX spk_outs=1, 14/0/0 [ 13.944856] XXX check single for pin 1b, sel 1b [ 13.944858] XXX check single for pin 14, sel 14 [ 13.944859] XXX pin 14 coupled with a single DAC [ 13.944945] XXX filled dacs: 3/0/0/0/0, hp 0, ext 2/0/0 [ 13.945189] XXX added multi-io pin 1a, dac 4 [ 13.945440] XXX added multi-io pin 18, dac 5 [ 13.945446] XXX create mixer ch 0 pin 1b dac 3 mix d [ 13.945452] XXX create mixer ch 1 pin 1a dac 4 mix e [ 13.945457] XXX create mixer ch 2 pin 18 dac 5 mix f
So it seems that the only things remaining are the SPDIF/rear channel jack and the coupled muting issue. Thanks for all the help so far,
Julian
At Thu, 30 Jun 2011 22:16:04 +0200, Julian Sikorski wrote:
W dniu 30.06.2011 21:28, Takashi Iwai pisze:
At Thu, 30 Jun 2011 20:09:49 +0200, Julian Sikorski wrote:
$ dmesg | grep XXX [ 14.813013] XXX alc662_auto_fill_dac_nids called [ 14.813015] XXX line_outs=1, 14/0/0 [ 14.813016] XXX hp_outs=1, 1b/0/0 [ 14.813018] XXX spk_outs=0, 0/0/0 [ 14.813186] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 14.813187] XXX swap primary out to HP [ 14.813188] XXX spk=14 [ 14.813190] XXX line=1b [ 14.813191] XXX alc662_auto_fill_dac_nids called [ 14.813192] XXX line_outs=1, 1b/0/0 [ 14.813194] XXX hp_outs=0, 0/0/0 [ 14.813195] XXX spk_outs=1, 14/0/0 [ 14.813311] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 14.813560] XXX added multi-io pin 1a, dac 3 [ 14.813814] XXX added multi-io pin 18, dac 4 [ 14.813818] XXX create mixer ch 0 pin 1b dac 2 mix c [ 14.813821] XXX create mixer ch 1 pin 1a dac 3 mix d [ 14.813825] XXX create mixer ch 2 pin 18 dac 4 mix e
How about the fix below?
Takashi
It works, thanks! In more detail, the Speaker/Headphone situation is back to 2.6.38 state - you can regulate them independently, but muting one mutes the other. LFE/Center and Surround keep working correctly too. The new output of alsa-info.sh: http://www.alsa-project.org/db/?f=45bc0df9747371b348bde6c4aa508b2ba44aff47
Right, it's because ALC892 has no mute-control in pin widgets but only in the mixer widget. And HP and speaker paths share the same mixer, thus it's impossible to mute independently.
So it seems that the only things remaining are the SPDIF/rear channel jack and the coupled muting issue.
It's a BIOS bug. It doesn't tell SPDIF is available. Ditto for the 4th stereo out. No pin is exposed by BIOS.
thanks,
Takashi
W dniu 01.07.2011 07:21, Takashi Iwai pisze:
At Thu, 30 Jun 2011 22:16:04 +0200, Julian Sikorski wrote:
W dniu 30.06.2011 21:28, Takashi Iwai pisze:
At Thu, 30 Jun 2011 20:09:49 +0200, Julian Sikorski wrote:
$ dmesg | grep XXX [ 14.813013] XXX alc662_auto_fill_dac_nids called [ 14.813015] XXX line_outs=1, 14/0/0 [ 14.813016] XXX hp_outs=1, 1b/0/0 [ 14.813018] XXX spk_outs=0, 0/0/0 [ 14.813186] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 14.813187] XXX swap primary out to HP [ 14.813188] XXX spk=14 [ 14.813190] XXX line=1b [ 14.813191] XXX alc662_auto_fill_dac_nids called [ 14.813192] XXX line_outs=1, 1b/0/0 [ 14.813194] XXX hp_outs=0, 0/0/0 [ 14.813195] XXX spk_outs=1, 14/0/0 [ 14.813311] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 14.813560] XXX added multi-io pin 1a, dac 3 [ 14.813814] XXX added multi-io pin 18, dac 4 [ 14.813818] XXX create mixer ch 0 pin 1b dac 2 mix c [ 14.813821] XXX create mixer ch 1 pin 1a dac 3 mix d [ 14.813825] XXX create mixer ch 2 pin 18 dac 4 mix e
How about the fix below?
Takashi
It works, thanks! In more detail, the Speaker/Headphone situation is back to 2.6.38 state - you can regulate them independently, but muting one mutes the other. LFE/Center and Surround keep working correctly too. The new output of alsa-info.sh: http://www.alsa-project.org/db/?f=45bc0df9747371b348bde6c4aa508b2ba44aff47
Right, it's because ALC892 has no mute-control in pin widgets but only in the mixer widget. And HP and speaker paths share the same mixer, thus it's impossible to mute independently.
I assume that the auto-mute function uses a different approach then - it disables the speakers sound when headphone jack is plugged in.
So it seems that the only things remaining are the SPDIF/rear channel jack and the coupled muting issue.
It's a BIOS bug. It doesn't tell SPDIF is available. Ditto for the 4th stereo out. No pin is exposed by BIOS.
I see. I can try updating the BIOS and see if it changes anything. If it doesn't, is there a way to work the problem around in the driver?
thanks,
Takashi
Cheers, Julian
At Fri, 01 Jul 2011 08:14:26 +0200, Julian Sikorski wrote:
W dniu 01.07.2011 07:21, Takashi Iwai pisze:
At Thu, 30 Jun 2011 22:16:04 +0200, Julian Sikorski wrote:
W dniu 30.06.2011 21:28, Takashi Iwai pisze:
At Thu, 30 Jun 2011 20:09:49 +0200, Julian Sikorski wrote:
$ dmesg | grep XXX [ 14.813013] XXX alc662_auto_fill_dac_nids called [ 14.813015] XXX line_outs=1, 14/0/0 [ 14.813016] XXX hp_outs=1, 1b/0/0 [ 14.813018] XXX spk_outs=0, 0/0/0 [ 14.813186] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 14.813187] XXX swap primary out to HP [ 14.813188] XXX spk=14 [ 14.813190] XXX line=1b [ 14.813191] XXX alc662_auto_fill_dac_nids called [ 14.813192] XXX line_outs=1, 1b/0/0 [ 14.813194] XXX hp_outs=0, 0/0/0 [ 14.813195] XXX spk_outs=1, 14/0/0 [ 14.813311] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 14.813560] XXX added multi-io pin 1a, dac 3 [ 14.813814] XXX added multi-io pin 18, dac 4 [ 14.813818] XXX create mixer ch 0 pin 1b dac 2 mix c [ 14.813821] XXX create mixer ch 1 pin 1a dac 3 mix d [ 14.813825] XXX create mixer ch 2 pin 18 dac 4 mix e
How about the fix below?
Takashi
It works, thanks! In more detail, the Speaker/Headphone situation is back to 2.6.38 state - you can regulate them independently, but muting one mutes the other. LFE/Center and Surround keep working correctly too. The new output of alsa-info.sh: http://www.alsa-project.org/db/?f=45bc0df9747371b348bde6c4aa508b2ba44aff47
Right, it's because ALC892 has no mute-control in pin widgets but only in the mixer widget. And HP and speaker paths share the same mixer, thus it's impossible to mute independently.
I assume that the auto-mute function uses a different approach then - it disables the speakers sound when headphone jack is plugged in.
Yes, it changes the pin-control value.
So it seems that the only things remaining are the SPDIF/rear channel jack and the coupled muting issue.
It's a BIOS bug. It doesn't tell SPDIF is available. Ditto for the 4th stereo out. No pin is exposed by BIOS.
I see. I can try updating the BIOS and see if it changes anything. If it doesn't, is there a way to work the problem around in the driver?
You need to figure out pins manually by yourself, then change the driver code. I leave it as a homework :)
thanks,
Takashi
W dniu 01.07.2011 08:24, Takashi Iwai pisze:
At Fri, 01 Jul 2011 08:14:26 +0200, Julian Sikorski wrote:
W dniu 01.07.2011 07:21, Takashi Iwai pisze:
At Thu, 30 Jun 2011 22:16:04 +0200, Julian Sikorski wrote:
W dniu 30.06.2011 21:28, Takashi Iwai pisze:
At Thu, 30 Jun 2011 20:09:49 +0200, Julian Sikorski wrote:
$ dmesg | grep XXX [ 14.813013] XXX alc662_auto_fill_dac_nids called [ 14.813015] XXX line_outs=1, 14/0/0 [ 14.813016] XXX hp_outs=1, 1b/0/0 [ 14.813018] XXX spk_outs=0, 0/0/0 [ 14.813186] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 14.813187] XXX swap primary out to HP [ 14.813188] XXX spk=14 [ 14.813190] XXX line=1b [ 14.813191] XXX alc662_auto_fill_dac_nids called [ 14.813192] XXX line_outs=1, 1b/0/0 [ 14.813194] XXX hp_outs=0, 0/0/0 [ 14.813195] XXX spk_outs=1, 14/0/0 [ 14.813311] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 14.813560] XXX added multi-io pin 1a, dac 3 [ 14.813814] XXX added multi-io pin 18, dac 4 [ 14.813818] XXX create mixer ch 0 pin 1b dac 2 mix c [ 14.813821] XXX create mixer ch 1 pin 1a dac 3 mix d [ 14.813825] XXX create mixer ch 2 pin 18 dac 4 mix e
How about the fix below?
Takashi
It works, thanks! In more detail, the Speaker/Headphone situation is back to 2.6.38 state - you can regulate them independently, but muting one mutes the other. LFE/Center and Surround keep working correctly too. The new output of alsa-info.sh: http://www.alsa-project.org/db/?f=45bc0df9747371b348bde6c4aa508b2ba44aff47
Right, it's because ALC892 has no mute-control in pin widgets but only in the mixer widget. And HP and speaker paths share the same mixer, thus it's impossible to mute independently.
I assume that the auto-mute function uses a different approach then - it disables the speakers sound when headphone jack is plugged in.
Yes, it changes the pin-control value.
Thanks for clarification.
So it seems that the only things remaining are the SPDIF/rear channel jack and the coupled muting issue.
It's a BIOS bug. It doesn't tell SPDIF is available. Ditto for the 4th stereo out. No pin is exposed by BIOS.
I see. I can try updating the BIOS and see if it changes anything. If it doesn't, is there a way to work the problem around in the driver?
You need to figure out pins manually by yourself, then change the driver code. I leave it as a homework :)
:) I cannot write code, so I would not count on myself doing that. I will have a look into updating the BIOS though.
thanks,
Takashi
Once again thanks for all the work you have done,
Julian
W dniu 01.07.2011 08:27, Julian Sikorski pisze:
W dniu 01.07.2011 08:24, Takashi Iwai pisze:
At Fri, 01 Jul 2011 08:14:26 +0200, Julian Sikorski wrote:
W dniu 01.07.2011 07:21, Takashi Iwai pisze:
At Thu, 30 Jun 2011 22:16:04 +0200, Julian Sikorski wrote:
W dniu 30.06.2011 21:28, Takashi Iwai pisze:
At Thu, 30 Jun 2011 20:09:49 +0200, Julian Sikorski wrote: > > $ dmesg | grep XXX > [ 14.813013] XXX alc662_auto_fill_dac_nids called > [ 14.813015] XXX line_outs=1, 14/0/0 > [ 14.813016] XXX hp_outs=1, 1b/0/0 > [ 14.813018] XXX spk_outs=0, 0/0/0 > [ 14.813186] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 > [ 14.813187] XXX swap primary out to HP > [ 14.813188] XXX spk=14 > [ 14.813190] XXX line=1b > [ 14.813191] XXX alc662_auto_fill_dac_nids called > [ 14.813192] XXX line_outs=1, 1b/0/0 > [ 14.813194] XXX hp_outs=0, 0/0/0 > [ 14.813195] XXX spk_outs=1, 14/0/0 > [ 14.813311] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 > [ 14.813560] XXX added multi-io pin 1a, dac 3 > [ 14.813814] XXX added multi-io pin 18, dac 4 > [ 14.813818] XXX create mixer ch 0 pin 1b dac 2 mix c > [ 14.813821] XXX create mixer ch 1 pin 1a dac 3 mix d > [ 14.813825] XXX create mixer ch 2 pin 18 dac 4 mix e
How about the fix below?
Takashi
It works, thanks! In more detail, the Speaker/Headphone situation is back to 2.6.38 state - you can regulate them independently, but muting one mutes the other. LFE/Center and Surround keep working correctly too. The new output of alsa-info.sh: http://www.alsa-project.org/db/?f=45bc0df9747371b348bde6c4aa508b2ba44aff47
Right, it's because ALC892 has no mute-control in pin widgets but only in the mixer widget. And HP and speaker paths share the same mixer, thus it's impossible to mute independently.
I assume that the auto-mute function uses a different approach then - it disables the speakers sound when headphone jack is plugged in.
Yes, it changes the pin-control value.
Thanks for clarification.
So it seems that the only things remaining are the SPDIF/rear channel jack and the coupled muting issue.
It's a BIOS bug. It doesn't tell SPDIF is available. Ditto for the 4th stereo out. No pin is exposed by BIOS.
I see. I can try updating the BIOS and see if it changes anything. If it doesn't, is there a way to work the problem around in the driver?
You need to figure out pins manually by yourself, then change the driver code. I leave it as a homework :)
:) I cannot write code, so I would not count on myself doing that. I will have a look into updating the BIOS though.
thanks,
Takashi
Once again thanks for all the work you have done,
Julian
Hmm, I googled a bit and it seems the way to find the pins is to write values to user_pin_configs. So no coding knowledge seems needed, could you give me some pointers on where to start?
Thanks, Julian
At Fri, 01 Jul 2011 09:07:47 +0200, Julian Sikorski wrote:
So it seems that the only things remaining are the SPDIF/rear channel jack and the coupled muting issue.
It's a BIOS bug. It doesn't tell SPDIF is available. Ditto for the 4th stereo out. No pin is exposed by BIOS.
I see. I can try updating the BIOS and see if it changes anything. If it doesn't, is there a way to work the problem around in the driver?
You need to figure out pins manually by yourself, then change the driver code. I leave it as a homework :)
:) I cannot write code, so I would not count on myself doing that. I will have a look into updating the BIOS though.
thanks,
Takashi
Once again thanks for all the work you have done,
Julian
Hmm, I googled a bit and it seems the way to find the pins is to write values to user_pin_configs. So no coding knowledge seems needed, could you give me some pointers on where to start?
First off, read the HD-audio specification to understand what the values represent. Then, use hda-analyzer or manually via hda-verb, figure out which widget corresponds to which I/O jack. Compose the corresponding pin-config value, and put it to the sysfs file. A brief description is found in Documentation/sound/alsa/HD-Audio.txt.
Takashi
On 01/07/2011 09:14, Takashi Iwai wrote:
At Fri, 01 Jul 2011 09:07:47 +0200, Julian Sikorski wrote:
> So it seems that the only things remaining are the SPDIF/rear channel > jack and the coupled muting issue.
It's a BIOS bug. It doesn't tell SPDIF is available. Ditto for the 4th stereo out. No pin is exposed by BIOS.
I see. I can try updating the BIOS and see if it changes anything. If it doesn't, is there a way to work the problem around in the driver?
You need to figure out pins manually by yourself, then change the driver code. I leave it as a homework :)
:) I cannot write code, so I would not count on myself doing that. I will have a look into updating the BIOS though.
thanks,
Takashi
Once again thanks for all the work you have done,
Julian
Hmm, I googled a bit and it seems the way to find the pins is to write values to user_pin_configs. So no coding knowledge seems needed, could you give me some pointers on where to start?
First off, read the HD-audio specification to understand what the values represent. Then, use hda-analyzer or manually via hda-verb, figure out which widget corresponds to which I/O jack. Compose the corresponding pin-config value, and put it to the sysfs file. A brief description is found in Documentation/sound/alsa/HD-Audio.txt.
Takashi
I was reading a bit more and it is all very confusing, but luckily I have holidays coming to try and figure it out. In the meantime, should I also try to find the pin for the internal subwoofer? WRT the alsa-info.sh output I'll send it once I get home later today.
Julian
W dniu 01.07.2011 09:14, Takashi Iwai pisze:
At Fri, 01 Jul 2011 09:07:47 +0200, Julian Sikorski wrote:
> So it seems that the only things remaining are the SPDIF/rear channel > jack and the coupled muting issue.
It's a BIOS bug. It doesn't tell SPDIF is available. Ditto for the 4th stereo out. No pin is exposed by BIOS.
I see. I can try updating the BIOS and see if it changes anything. If it doesn't, is there a way to work the problem around in the driver?
You need to figure out pins manually by yourself, then change the driver code. I leave it as a homework :)
:) I cannot write code, so I would not count on myself doing that. I will have a look into updating the BIOS though.
thanks,
Takashi
Once again thanks for all the work you have done,
Julian
Hmm, I googled a bit and it seems the way to find the pins is to write values to user_pin_configs. So no coding knowledge seems needed, could you give me some pointers on where to start?
First off, read the HD-audio specification to understand what the values represent. Then, use hda-analyzer or manually via hda-verb, figure out which widget corresponds to which I/O jack. Compose the corresponding pin-config value, and put it to the sysfs file. A brief description is found in Documentation/sound/alsa/HD-Audio.txt.
Takashi
I have been scratching my head for almost 2 h now without much progress. Can I steal this values from Windows driver somehow? It seems to be possible:
http://www.insanelymac.com/forum/index.php?s=3298551705d0d48ba8faa28b9a7d328...
Julian
W dniu 2011-07-02 00:09, Julian Sikorski pisze:
W dniu 01.07.2011 09:14, Takashi Iwai pisze:
At Fri, 01 Jul 2011 09:07:47 +0200, Julian Sikorski wrote:
>> So it seems that the only things remaining are the SPDIF/rear channel >> jack and the coupled muting issue. > > It's a BIOS bug. It doesn't tell SPDIF is available. > Ditto for the 4th stereo out. No pin is exposed by BIOS.
I see. I can try updating the BIOS and see if it changes anything. If it doesn't, is there a way to work the problem around in the driver?
You need to figure out pins manually by yourself, then change the driver code. I leave it as a homework :)
:) I cannot write code, so I would not count on myself doing that. I will have a look into updating the BIOS though.
thanks,
Takashi
Once again thanks for all the work you have done,
Julian
Hmm, I googled a bit and it seems the way to find the pins is to write values to user_pin_configs. So no coding knowledge seems needed, could you give me some pointers on where to start?
First off, read the HD-audio specification to understand what the values represent. Then, use hda-analyzer or manually via hda-verb, figure out which widget corresponds to which I/O jack. Compose the corresponding pin-config value, and put it to the sysfs file. A brief description is found in Documentation/sound/alsa/HD-Audio.txt.
Takashi
I have been scratching my head for almost 2 h now without much progress. Can I steal this values from Windows driver somehow? It seems to be possible:
http://www.insanelymac.com/forum/index.php?s=3298551705d0d48ba8faa28b9a7d328...
Julian
I managed to get the data out of Windows install, does it look useful?
Julian
W dniu 02.07.2011 00:37, Julian Sikorski pisze:
W dniu 2011-07-02 00:09, Julian Sikorski pisze:
W dniu 01.07.2011 09:14, Takashi Iwai pisze:
At Fri, 01 Jul 2011 09:07:47 +0200, Julian Sikorski wrote:
>>> So it seems that the only things remaining are the SPDIF/rear >>> channel >>> jack and the coupled muting issue. >> >> It's a BIOS bug. It doesn't tell SPDIF is available. >> Ditto for the 4th stereo out. No pin is exposed by BIOS. > > I see. I can try updating the BIOS and see if it changes > anything. If it > doesn't, is there a way to work the problem around in the driver?
You need to figure out pins manually by yourself, then change the driver code. I leave it as a homework :)
:) I cannot write code, so I would not count on myself doing that. I will have a look into updating the BIOS though.
thanks,
Takashi
Once again thanks for all the work you have done,
Julian
Hmm, I googled a bit and it seems the way to find the pins is to write values to user_pin_configs. So no coding knowledge seems needed, could you give me some pointers on where to start?
First off, read the HD-audio specification to understand what the values represent. Then, use hda-analyzer or manually via hda-verb, figure out which widget corresponds to which I/O jack. Compose the corresponding pin-config value, and put it to the sysfs file. A brief description is found in Documentation/sound/alsa/HD-Audio.txt.
Takashi
I have been scratching my head for almost 2 h now without much progress. Can I steal this values from Windows driver somehow? It seems to be possible:
http://www.insanelymac.com/forum/index.php?s=3298551705d0d48ba8faa28b9a7d328...
Julian
I managed to get the data out of Windows install, does it look useful?
Julian
I managed to figure out which ini file is used for my device, I am attaching both the 32- and 64-bit versions. Hopefully there is some useful info inside.
Julian
W dniu 01.07.2011 08:24, Takashi Iwai pisze:
At Fri, 01 Jul 2011 08:14:26 +0200, Julian Sikorski wrote:
W dniu 01.07.2011 07:21, Takashi Iwai pisze:
At Thu, 30 Jun 2011 22:16:04 +0200, Julian Sikorski wrote:
W dniu 30.06.2011 21:28, Takashi Iwai pisze:
At Thu, 30 Jun 2011 20:09:49 +0200, Julian Sikorski wrote:
$ dmesg | grep XXX [ 14.813013] XXX alc662_auto_fill_dac_nids called [ 14.813015] XXX line_outs=1, 14/0/0 [ 14.813016] XXX hp_outs=1, 1b/0/0 [ 14.813018] XXX spk_outs=0, 0/0/0 [ 14.813186] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 14.813187] XXX swap primary out to HP [ 14.813188] XXX spk=14 [ 14.813190] XXX line=1b [ 14.813191] XXX alc662_auto_fill_dac_nids called [ 14.813192] XXX line_outs=1, 1b/0/0 [ 14.813194] XXX hp_outs=0, 0/0/0 [ 14.813195] XXX spk_outs=1, 14/0/0 [ 14.813311] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 14.813560] XXX added multi-io pin 1a, dac 3 [ 14.813814] XXX added multi-io pin 18, dac 4 [ 14.813818] XXX create mixer ch 0 pin 1b dac 2 mix c [ 14.813821] XXX create mixer ch 1 pin 1a dac 3 mix d [ 14.813825] XXX create mixer ch 2 pin 18 dac 4 mix e
How about the fix below?
Takashi
It works, thanks! In more detail, the Speaker/Headphone situation is back to 2.6.38 state - you can regulate them independently, but muting one mutes the other. LFE/Center and Surround keep working correctly too. The new output of alsa-info.sh: http://www.alsa-project.org/db/?f=45bc0df9747371b348bde6c4aa508b2ba44aff47
Right, it's because ALC892 has no mute-control in pin widgets but only in the mixer widget. And HP and speaker paths share the same mixer, thus it's impossible to mute independently.
I assume that the auto-mute function uses a different approach then - it disables the speakers sound when headphone jack is plugged in.
Yes, it changes the pin-control value.
So it seems that the only things remaining are the SPDIF/rear channel jack and the coupled muting issue.
It's a BIOS bug. It doesn't tell SPDIF is available. Ditto for the 4th stereo out. No pin is exposed by BIOS.
I see. I can try updating the BIOS and see if it changes anything. If it doesn't, is there a way to work the problem around in the driver?
You need to figure out pins manually by yourself, then change the driver code. I leave it as a homework :)
thanks,
Takashi
I have figured out part of the value I need to assign: a black 1/8'' jack for speakers, rear external, will be 0x01111xxx. I am having hard time figuring out the last 3 numbers: - only the last one of misc bits is defined in the spec (jack sensing override), yet the bios test it to values > 0001 for some of my jacks - the default association and sequence seem to have more choices, should I steal these from other pin configs to make it work with 8-channel sound?
Julian
At Fri, 01 Jul 2011 07:21:34 +0200, Takashi Iwai wrote:
At Thu, 30 Jun 2011 22:16:04 +0200, Julian Sikorski wrote:
It works, thanks! In more detail, the Speaker/Headphone situation is back to 2.6.38 state - you can regulate them independently, but muting one mutes the other. LFE/Center and Surround keep working correctly too. The new output of alsa-info.sh: http://www.alsa-project.org/db/?f=45bc0df9747371b348bde6c4aa508b2ba44aff47
Right, it's because ALC892 has no mute-control in pin widgets but only in the mixer widget. And HP and speaker paths share the same mixer, thus it's impossible to mute independently.
I seem to have lied. It should be possible, and the emulator shows it must be working well.
Do I understand correctly that the problem is that both HP and speaker outputs are muted simultaneously when you either of "Headphone" or "Speaker" mixer switch is muted?
If so, please give alsa-info.sh outputs at the problematic state, i.e. the speaker gets muted by the headphone mixer switch or vice versa, just to confirm.
thanks,
Takashi
W dniu 01.07.2011 09:32, Takashi Iwai pisze:
At Fri, 01 Jul 2011 07:21:34 +0200, Takashi Iwai wrote:
At Thu, 30 Jun 2011 22:16:04 +0200, Julian Sikorski wrote:
It works, thanks! In more detail, the Speaker/Headphone situation is back to 2.6.38 state - you can regulate them independently, but muting one mutes the other. LFE/Center and Surround keep working correctly too. The new output of alsa-info.sh: http://www.alsa-project.org/db/?f=45bc0df9747371b348bde6c4aa508b2ba44aff47
Right, it's because ALC892 has no mute-control in pin widgets but only in the mixer widget. And HP and speaker paths share the same mixer, thus it's impossible to mute independently.
I seem to have lied. It should be possible, and the emulator shows it must be working well.
Do I understand correctly that the problem is that both HP and speaker outputs are muted simultaneously when you either of "Headphone" or "Speaker" mixer switch is muted?
If so, please give alsa-info.sh outputs at the problematic state, i.e. the speaker gets muted by the headphone mixer switch or vice versa, just to confirm.
thanks,
Takashi
Here you go: http://www.alsa-project.org/db/?f=c8f1e149c155ed950aea1a7327a5800fc2b61da2 I muted the speakers and the headphones went silent.
Julian
At Fri, 01 Jul 2011 20:57:23 +0200, Julian Sikorski wrote:
W dniu 01.07.2011 09:32, Takashi Iwai pisze:
At Fri, 01 Jul 2011 07:21:34 +0200, Takashi Iwai wrote:
At Thu, 30 Jun 2011 22:16:04 +0200, Julian Sikorski wrote:
It works, thanks! In more detail, the Speaker/Headphone situation is back to 2.6.38 state - you can regulate them independently, but muting one mutes the other. LFE/Center and Surround keep working correctly too. The new output of alsa-info.sh: http://www.alsa-project.org/db/?f=45bc0df9747371b348bde6c4aa508b2ba44aff47
Right, it's because ALC892 has no mute-control in pin widgets but only in the mixer widget. And HP and speaker paths share the same mixer, thus it's impossible to mute independently.
I seem to have lied. It should be possible, and the emulator shows it must be working well.
Do I understand correctly that the problem is that both HP and speaker outputs are muted simultaneously when you either of "Headphone" or "Speaker" mixer switch is muted?
If so, please give alsa-info.sh outputs at the problematic state, i.e. the speaker gets muted by the headphone mixer switch or vice versa, just to confirm.
thanks,
Takashi
Here you go: http://www.alsa-project.org/db/?f=c8f1e149c155ed950aea1a7327a5800fc2b61da2 I muted the speakers and the headphones went silent.
Hm, I see no obvious problem in the codec tree and alsa mixers. Could you check whether the playback without PulseAudio has the same issue? Try pasuspender, e.g.
% pasuspender aplay -Dplughw foo.wav
(Depending on the version of PA, you might need to put '--' between pasuspender and aplay.)
Takashi
W dniu 01.07.2011 21:25, Takashi Iwai pisze:
At Fri, 01 Jul 2011 20:57:23 +0200, Julian Sikorski wrote:
W dniu 01.07.2011 09:32, Takashi Iwai pisze:
At Fri, 01 Jul 2011 07:21:34 +0200, Takashi Iwai wrote:
At Thu, 30 Jun 2011 22:16:04 +0200, Julian Sikorski wrote:
It works, thanks! In more detail, the Speaker/Headphone situation is back to 2.6.38 state - you can regulate them independently, but muting one mutes the other. LFE/Center and Surround keep working correctly too. The new output of alsa-info.sh: http://www.alsa-project.org/db/?f=45bc0df9747371b348bde6c4aa508b2ba44aff47
Right, it's because ALC892 has no mute-control in pin widgets but only in the mixer widget. And HP and speaker paths share the same mixer, thus it's impossible to mute independently.
I seem to have lied. It should be possible, and the emulator shows it must be working well.
Do I understand correctly that the problem is that both HP and speaker outputs are muted simultaneously when you either of "Headphone" or "Speaker" mixer switch is muted?
If so, please give alsa-info.sh outputs at the problematic state, i.e. the speaker gets muted by the headphone mixer switch or vice versa, just to confirm.
thanks,
Takashi
Here you go: http://www.alsa-project.org/db/?f=c8f1e149c155ed950aea1a7327a5800fc2b61da2 I muted the speakers and the headphones went silent.
Hm, I see no obvious problem in the codec tree and alsa mixers. Could you check whether the playback without PulseAudio has the same issue? Try pasuspender, e.g.
% pasuspender aplay -Dplughw foo.wav
(Depending on the version of PA, you might need to put '--' between pasuspender and aplay.)
Takashi
You are right, with pulseaudio out of the way everything works fine. Anything particular I should tell them?
Julian
W dniu 01.07.2011 07:21, Takashi Iwai pisze:
At Thu, 30 Jun 2011 22:16:04 +0200, Julian Sikorski wrote:
W dniu 30.06.2011 21:28, Takashi Iwai pisze:
At Thu, 30 Jun 2011 20:09:49 +0200, Julian Sikorski wrote:
$ dmesg | grep XXX [ 14.813013] XXX alc662_auto_fill_dac_nids called [ 14.813015] XXX line_outs=1, 14/0/0 [ 14.813016] XXX hp_outs=1, 1b/0/0 [ 14.813018] XXX spk_outs=0, 0/0/0 [ 14.813186] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 14.813187] XXX swap primary out to HP [ 14.813188] XXX spk=14 [ 14.813190] XXX line=1b [ 14.813191] XXX alc662_auto_fill_dac_nids called [ 14.813192] XXX line_outs=1, 1b/0/0 [ 14.813194] XXX hp_outs=0, 0/0/0 [ 14.813195] XXX spk_outs=1, 14/0/0 [ 14.813311] XXX filled dacs: 2/0/0/0/0, hp 0, ext 0/0/0 [ 14.813560] XXX added multi-io pin 1a, dac 3 [ 14.813814] XXX added multi-io pin 18, dac 4 [ 14.813818] XXX create mixer ch 0 pin 1b dac 2 mix c [ 14.813821] XXX create mixer ch 1 pin 1a dac 3 mix d [ 14.813825] XXX create mixer ch 2 pin 18 dac 4 mix e
How about the fix below?
Takashi
It works, thanks! In more detail, the Speaker/Headphone situation is back to 2.6.38 state - you can regulate them independently, but muting one mutes the other. LFE/Center and Surround keep working correctly too. The new output of alsa-info.sh: http://www.alsa-project.org/db/?f=45bc0df9747371b348bde6c4aa508b2ba44aff47
Right, it's because ALC892 has no mute-control in pin widgets but only in the mixer widget. And HP and speaker paths share the same mixer, thus it's impossible to mute independently.
So it seems that the only things remaining are the SPDIF/rear channel jack and the coupled muting issue.
It's a BIOS bug. It doesn't tell SPDIF is available. Ditto for the 4th stereo out. No pin is exposed by BIOS.
thanks,
Takashi
FYI I updated the BIOS to the latest available version, but it does not seem to have changed anything. New alsa-info.sh output: http://www.alsa-project.org/db/?f=89e03c194e599829e132517342cce70133f3fc7a
Julian
W dniu 01.07.2011 07:21, Takashi Iwai pisze:
It's a BIOS bug. It doesn't tell SPDIF is available. Ditto for the 4th stereo out. No pin is exposed by BIOS.
thanks,
Takashi
I finally managed to figure out what these numbers mean. But then I got confused by your statement:
$ cat /sys/class/sound/card0/hwC0D0/init_pin_configs 0x11 0x411111f0 0x12 0x411111f0 0x14 0x99130110 0x15 0x411111f0 0x16 0x411111f0 0x17 0x411111f0 0x18 0x01a11c30 0x19 0x99a30931 0x1a 0x0181143f 0x1b 0x0121101f 0x1c 0x411111f0 0x1d 0x598301f0 0x1e 0x01451120 0x1f 0x411111f0
_From what I was able to decipher, 0x1e is a jack, external rear, with spdif out default output and optical connection. It is black. The same physical socket is used for the last 2 surround channels. Could you please clarify? Thanks in advance.
Julian
2011/7/5 Julian Sikorski belegdol@gmail.com:
From what I was able to decipher, 0x1e is a jack, external rear, with spdif out default output and optical connection. It is black. The same physical socket is used for the last 2 surround channels. Could you please clarify? Thanks in advance.
Take a look at Block Diagram of alc892 datasheet
http://www.realtek.com/products/productsView.aspx?Langid=1&PNid=24&P...
if you can confirmed the internal mic, mic jack ,line in , line out and internal speaker work as expected
the only pin complex which can be connected to rear [Audio Output] 0x0d is 0x15
seem that the pin complex for 4 jack 8-ch notebook are different from desktop with 6 jacks at rear panel
a 10 channel codec is able to provide volume control for internal speaker and 4 jacks
W dniu 05.07.2011 03:31, Raymond Yau pisze:
2011/7/5 Julian Sikorski belegdol@gmail.com:
From what I was able to decipher, 0x1e is a jack, external rear, with spdif out default output and optical connection. It is black. The same physical socket is used for the last 2 surround channels. Could you please clarify? Thanks in advance.
Take a look at Block Diagram of alc892 datasheet
http://www.realtek.com/products/productsView.aspx?Langid=1&PNid=24&P...
if you can confirmed the internal mic, mic jack ,line in , line out and internal speaker work as expected
the only pin complex which can be connected to rear [Audio Output] 0x0d is 0x15
seem that the pin complex for 4 jack 8-ch notebook are different from desktop with 6 jacks at rear panel
a 10 channel codec is able to provide volume control for internal speaker and 4 jacks
I have tested int speakers, int mic, ext mic, line in, hp jack, lfe/center and rear surround. All seem to work. The only thing untested is the optical out.
Julian
W dniu 05.07.2011 03:31, Raymond Yau pisze:
2011/7/5 Julian Sikorskibelegdol@gmail.com:
From what I was able to decipher, 0x1e is a jack, external rear, with spdif out default output and optical connection. It is black. The same physical socket is used for the last 2 surround channels. Could you please clarify? Thanks in advance.
Take a look at Block Diagram of alc892 datasheet
http://www.realtek.com/products/productsView.aspx?Langid=1&PNid=24&P...
if you can confirmed the internal mic, mic jack ,line in , line out and internal speaker work as expected
the only pin complex which can be connected to rear [Audio Output] 0x0d is 0x15
seem that the pin complex for 4 jack 8-ch notebook are different from desktop with 6 jacks at rear panel
a 10 channel codec is able to provide volume control for internal speaker and 4 jacks
Thanks to Raymond's advice I was finally able to make the sound come out of the copper part of the spdif/side surround jack. I am pasting the diff created with hda-analyzer, please let me know if this gives you enough information to add proper 7.1 sound support for this laptop. Here is the alsa-info.sh with all jacks playing sound: http://www.alsa-project.org/db/?f=8f23e499727ec612ed925b81d3f38928e8f6aebb Of course, there is still no specific volume control for the side channel.
Julian
Diff for codec 0/0 (0x10ec0892): --- +++ @@ -223,23 +223,23 @@ Misc = NO_PRESENCE Pin-ctls: 0x20: IN Unsolicited: tag=0x00, enabled=0 Power: setting=D0, actual=D0 Connection: 1 0x0e Node 0x17 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 - Amp-Out vals: [0x80 0x80] + Amp-Out vals: [0x00 0x00] Pincap 0x00000036: IN OUT Detect Trigger Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE - Pin-ctls: 0x20: IN + Pin-ctls: 0x40: OUT Unsolicited: tag=0x00, enabled=0 Power: setting=D0, actual=D0 Connection: 1 0x0f Node 0x18 [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out Control: name="Center Playback Switch", index=0, device=0 ControlAmp: chs=1, dir=1, idx=0, ofs=0 Control: name="LFE Playback Switch", index=0, device=
W dniu 17.07.2011 13:55, Julian Sikorski pisze:
W dniu 05.07.2011 03:31, Raymond Yau pisze:
2011/7/5 Julian Sikorskibelegdol@gmail.com:
From what I was able to decipher, 0x1e is a jack, external rear, with spdif out default output and optical connection. It is black. The same physical socket is used for the last 2 surround channels. Could you please clarify? Thanks in advance.
Take a look at Block Diagram of alc892 datasheet
http://www.realtek.com/products/productsView.aspx?Langid=1&PNid=24&P...
if you can confirmed the internal mic, mic jack ,line in , line out and internal speaker work as expected
the only pin complex which can be connected to rear [Audio Output] 0x0d is 0x15
seem that the pin complex for 4 jack 8-ch notebook are different from desktop with 6 jacks at rear panel
a 10 channel codec is able to provide volume control for internal speaker and 4 jacks
Thanks to Raymond's advice I was finally able to make the sound come out of the copper part of the spdif/side surround jack. I am pasting the diff created with hda-analyzer, please let me know if this gives you enough information to add proper 7.1 sound support for this laptop. Here is the alsa-info.sh with all jacks playing sound: http://www.alsa-project.org/db/?f=8f23e499727ec612ed925b81d3f38928e8f6aebb Of course, there is still no specific volume control for the side channel.
Julian
Upon further investigation I discovered that with the volume on the 0x17 can be controlled with center/lfe in alsamixer. I don't think it is the intended behaviour.
Julian
Julian
At Sun, 17 Jul 2011 14:17:22 +0200, Julian Sikorski wrote:
W dniu 17.07.2011 13:55, Julian Sikorski pisze:
W dniu 05.07.2011 03:31, Raymond Yau pisze:
2011/7/5 Julian Sikorskibelegdol@gmail.com:
From what I was able to decipher, 0x1e is a jack, external rear, with spdif out default output and optical connection. It is black. The same physical socket is used for the last 2 surround channels. Could you please clarify? Thanks in advance.
Take a look at Block Diagram of alc892 datasheet
http://www.realtek.com/products/productsView.aspx?Langid=1&PNid=24&P...
if you can confirmed the internal mic, mic jack ,line in , line out and internal speaker work as expected
the only pin complex which can be connected to rear [Audio Output] 0x0d is 0x15
seem that the pin complex for 4 jack 8-ch notebook are different from desktop with 6 jacks at rear panel
a 10 channel codec is able to provide volume control for internal speaker and 4 jacks
Thanks to Raymond's advice I was finally able to make the sound come out of the copper part of the spdif/side surround jack. I am pasting the diff created with hda-analyzer, please let me know if this gives you enough information to add proper 7.1 sound support for this laptop. Here is the alsa-info.sh with all jacks playing sound: http://www.alsa-project.org/db/?f=8f23e499727ec612ed925b81d3f38928e8f6aebb Of course, there is still no specific volume control for the side channel.
Julian
Upon further investigation I discovered that with the volume on the 0x17 can be controlled with center/lfe in alsamixer. I don't think it is the intended behaviour.
Is it with the very latest alsa-driver snapshot?
Takashi
At Mon, 18 Jul 2011 09:35:33 +0200, Takashi Iwai wrote:
At Sun, 17 Jul 2011 14:17:22 +0200, Julian Sikorski wrote:
W dniu 17.07.2011 13:55, Julian Sikorski pisze:
W dniu 05.07.2011 03:31, Raymond Yau pisze:
2011/7/5 Julian Sikorskibelegdol@gmail.com:
From what I was able to decipher, 0x1e is a jack, external rear, with spdif out default output and optical connection. It is black. The same physical socket is used for the last 2 surround channels. Could you please clarify? Thanks in advance.
Take a look at Block Diagram of alc892 datasheet
http://www.realtek.com/products/productsView.aspx?Langid=1&PNid=24&P...
if you can confirmed the internal mic, mic jack ,line in , line out and internal speaker work as expected
the only pin complex which can be connected to rear [Audio Output] 0x0d is 0x15
seem that the pin complex for 4 jack 8-ch notebook are different from desktop with 6 jacks at rear panel
a 10 channel codec is able to provide volume control for internal speaker and 4 jacks
Thanks to Raymond's advice I was finally able to make the sound come out of the copper part of the spdif/side surround jack. I am pasting the diff created with hda-analyzer, please let me know if this gives you enough information to add proper 7.1 sound support for this laptop. Here is the alsa-info.sh with all jacks playing sound: http://www.alsa-project.org/db/?f=8f23e499727ec612ed925b81d3f38928e8f6aebb Of course, there is still no specific volume control for the side channel.
Julian
Upon further investigation I discovered that with the volume on the 0x17 can be controlled with center/lfe in alsamixer. I don't think it is the intended behaviour.
Is it with the very latest alsa-driver snapshot?
And I can't reproduce your problem with the alsa-info.sh output above. Give more exact information what you did and what is the problem.
thanks,
Takashi
W dniu 18.07.2011 10:52, Takashi Iwai pisze:
And I can't reproduce your problem with the alsa-info.sh output above. Give more exact information what you did and what is the problem.
thanks,
Takashi
I'm sorry for the confusion - let me sum up the current situation. With the fixes you pushed to sound-2.6/master I was able to get 5.1 sound out of my laptop. The only missing bit was the 7.1 sound. And the last channel goes via a jack/optical spdif hybrid. The problem is that the BIOS does not announce that and as such alsa is unaware of the side surround channel. Using Raymond's advice, I was able to make the sound come out of the last jack, by changing some values for pin 0x17 (described as sidesurr in the datasheet), diff is attached. I basically checked what was the difference in alsa-info.sh output when I was changing number of channels with alsamixer, and then did the same for pin 0x17. Since, from what I understood, you wanted me to figure out which pin is connected to the last jack [1], I thought this information would be useful to fix BIOS shortcomings. Other problem is that the volume on that jack is controlled by center and lfe sliders (in alsamixer), which is probably caused by the fact that alsa is unaware of the 7.1 sound. If more information is needed, please let me know what do you need in addition to alsa-info.sh output.
Regards, Julian
W dniu 18.07.2011 13:15, Julian Sikorski pisze:
W dniu 18.07.2011 10:52, Takashi Iwai pisze:
And I can't reproduce your problem with the alsa-info.sh output above. Give more exact information what you did and what is the problem.
thanks,
Takashi
I'm sorry for the confusion - let me sum up the current situation. With the fixes you pushed to sound-2.6/master I was able to get 5.1 sound out of my laptop. The only missing bit was the 7.1 sound. And the last channel goes via a jack/optical spdif hybrid. The problem is that the BIOS does not announce that and as such alsa is unaware of the side surround channel. Using Raymond's advice, I was able to make the sound come out of the last jack, by changing some values for pin 0x17 (described as sidesurr in the datasheet), diff is attached. I basically checked what was the difference in alsa-info.sh output when I was changing number of channels with alsamixer, and then did the same for pin 0x17. Since, from what I understood, you wanted me to figure out which pin is connected to the last jack [1], I thought this information would be useful to fix BIOS shortcomings. Other problem is that the volume on that jack is controlled by center and lfe sliders (in alsamixer), which is probably caused by the fact that alsa is unaware of the 7.1 sound. If more information is needed, please let me know what do you need in addition to alsa-info.sh output.
Regards, Julian
The diff is reverted for some reason - setting pin-ctls to 0x40: OUT and Amp-Out vals to [0x00 0x00] is what makes the sound appear. Sorry for the confusion.
Julian
At Mon, 18 Jul 2011 13:15:14 +0200, Julian Sikorski wrote:
W dniu 18.07.2011 10:52, Takashi Iwai pisze:
And I can't reproduce your problem with the alsa-info.sh output above. Give more exact information what you did and what is the problem.
thanks,
Takashi
I'm sorry for the confusion - let me sum up the current situation. With the fixes you pushed to sound-2.6/master I was able to get 5.1 sound out of my laptop. The only missing bit was the 7.1 sound. And the last channel goes via a jack/optical spdif hybrid. The problem is that the BIOS does not announce that and as such alsa is unaware of the side surround channel. Using Raymond's advice, I was able to make the sound come out of the last jack, by changing some values for pin 0x17 (described as sidesurr in the datasheet), diff is attached. I basically checked what was the difference in alsa-info.sh output when I was changing number of channels with alsamixer, and then did the same for pin 0x17. Since, from what I understood, you wanted me to figure out which pin is connected to the last jack [1], I thought this information would be useful to fix BIOS shortcomings.
Yes, and note that you can set up the initial pin configurations dynamically via sysfs, too.
Other problem is that the volume on that jack is controlled by center and lfe sliders (in alsamixer), which is probably caused by the fact that alsa is unaware of the 7.1 sound.
And this is not what I can't reproduce.
If more information is needed, please let me know what do you need in addition to alsa-info.sh output.
First off, double-check whether the CLFE mixer really changes the pin amp. At best, take alsa-info.sh output snapshot before and after changing the mixer state, and compare the files (better give both files in the mail).
Takashi
W dniu 18.07.2011 13:19, Takashi Iwai pisze:
At Mon, 18 Jul 2011 13:15:14 +0200, Julian Sikorski wrote:
W dniu 18.07.2011 10:52, Takashi Iwai pisze:
And I can't reproduce your problem with the alsa-info.sh output above. Give more exact information what you did and what is the problem.
thanks,
Takashi
I'm sorry for the confusion - let me sum up the current situation. With the fixes you pushed to sound-2.6/master I was able to get 5.1 sound out of my laptop. The only missing bit was the 7.1 sound. And the last channel goes via a jack/optical spdif hybrid. The problem is that the BIOS does not announce that and as such alsa is unaware of the side surround channel. Using Raymond's advice, I was able to make the sound come out of the last jack, by changing some values for pin 0x17 (described as sidesurr in the datasheet), diff is attached. I basically checked what was the difference in alsa-info.sh output when I was changing number of channels with alsamixer, and then did the same for pin 0x17. Since, from what I understood, you wanted me to figure out which pin is connected to the last jack [1], I thought this information would be useful to fix BIOS shortcomings.
Yes, and note that you can set up the initial pin configurations dynamically via sysfs, too.
I tried, but without much success [2] - I came up with 0x01111xxx, but I do not have enough understanding on what to put as the last 3 numbers. Moreover, I keep getting this upon trying to apply the new pin configuration: # echo 0x17 0x011111f0 > user_pin_configs # LANG=C pasuspender echo 1 > reconfig echo: write error: Device or resource busy
Other problem is that the volume on that jack is controlled by center and lfe sliders (in alsamixer), which is probably caused by the fact that alsa is unaware of the 7.1 sound.
And this is not what I can't reproduce.
If more information is needed, please let me know what do you need in addition to alsa-info.sh output.
First off, double-check whether the CLFE mixer really changes the pin amp. At best, take alsa-info.sh output snapshot before and after changing the mixer state, and compare the files (better give both files in the mail).
Here you go. playing.txt is the state when sound comes out of the spdif/side pin, and the center-lfe-half-volume.txt is when the volume is reduced to 50 % afterwards. Please keep in mind that if you enable 6-channel sound with alsamixer, the volume on center/lfe-mic jack will be reduced too (8-channel-half-volume.txt)
Takashi
Julian
At Mon, 18 Jul 2011 13:42:50 +0200, Julian Sikorski wrote:
W dniu 18.07.2011 13:19, Takashi Iwai pisze:
At Mon, 18 Jul 2011 13:15:14 +0200, Julian Sikorski wrote:
W dniu 18.07.2011 10:52, Takashi Iwai pisze:
And I can't reproduce your problem with the alsa-info.sh output above. Give more exact information what you did and what is the problem.
thanks,
Takashi
I'm sorry for the confusion - let me sum up the current situation. With the fixes you pushed to sound-2.6/master I was able to get 5.1 sound out of my laptop. The only missing bit was the 7.1 sound. And the last channel goes via a jack/optical spdif hybrid. The problem is that the BIOS does not announce that and as such alsa is unaware of the side surround channel. Using Raymond's advice, I was able to make the sound come out of the last jack, by changing some values for pin 0x17 (described as sidesurr in the datasheet), diff is attached. I basically checked what was the difference in alsa-info.sh output when I was changing number of channels with alsamixer, and then did the same for pin 0x17. Since, from what I understood, you wanted me to figure out which pin is connected to the last jack [1], I thought this information would be useful to fix BIOS shortcomings.
Yes, and note that you can set up the initial pin configurations dynamically via sysfs, too.
I tried, but without much success [2] - I came up with 0x01111xxx, but I do not have enough understanding on what to put as the last 3 numbers.
The last three numbers are pretty important, so check the HD-audio specification.
Moreover, I keep getting this upon trying to apply the new pin configuration: # echo 0x17 0x011111f0 > user_pin_configs # LANG=C pasuspender echo 1 > reconfig echo: write error: Device or resource busy
You should log out, go to linux console, and kill all processes accessing the sound devices, then do reconfig.
Other problem is that the volume on that jack is controlled by center and lfe sliders (in alsamixer), which is probably caused by the fact that alsa is unaware of the 7.1 sound.
And this is not what I can't reproduce.
If more information is needed, please let me know what do you need in addition to alsa-info.sh output.
First off, double-check whether the CLFE mixer really changes the pin amp. At best, take alsa-info.sh output snapshot before and after changing the mixer state, and compare the files (better give both files in the mail).
Here you go. playing.txt is the state when sound comes out of the spdif/side pin, and the center-lfe-half-volume.txt is when the volume is reduced to 50 % afterwards.
Between playing.txt and cneter-lfe-half-volume.txt, I see no change regarding the pin 0x17. The only difference is the DAC volume of NID 0x05. What am I missing?
Takashi
W dniu 18.07.2011 14:16, Takashi Iwai pisze:
At Mon, 18 Jul 2011 13:42:50 +0200, Julian Sikorski wrote:
W dniu 18.07.2011 13:19, Takashi Iwai pisze:
At Mon, 18 Jul 2011 13:15:14 +0200, Julian Sikorski wrote:
W dniu 18.07.2011 10:52, Takashi Iwai pisze:
And I can't reproduce your problem with the alsa-info.sh output above. Give more exact information what you did and what is the problem.
thanks,
Takashi
I'm sorry for the confusion - let me sum up the current situation. With the fixes you pushed to sound-2.6/master I was able to get 5.1 sound out of my laptop. The only missing bit was the 7.1 sound. And the last channel goes via a jack/optical spdif hybrid. The problem is that the BIOS does not announce that and as such alsa is unaware of the side surround channel. Using Raymond's advice, I was able to make the sound come out of the last jack, by changing some values for pin 0x17 (described as sidesurr in the datasheet), diff is attached. I basically checked what was the difference in alsa-info.sh output when I was changing number of channels with alsamixer, and then did the same for pin 0x17. Since, from what I understood, you wanted me to figure out which pin is connected to the last jack [1], I thought this information would be useful to fix BIOS shortcomings.
Yes, and note that you can set up the initial pin configurations dynamically via sysfs, too.
I tried, but without much success [2] - I came up with 0x01111xxx, but I do not have enough understanding on what to put as the last 3 numbers.
The last three numbers are pretty important, so check the HD-audio specification.
The specification [3] says the last 3 are misc, default association and sequence. So what I have now: - misc: not sure here, since 3 out of 4 bits are reserved. 4th one should be 0 though, since the port has jack sensing functionality. - default association: 3, as the working jacks have that set to 3 - sequence: since the working lfe has it set to 0 (center/lfe) and f (surround), I guess any value in between should work. I am not sure if my reasoning is right though.
Moreover, I keep getting this upon trying to apply the new pin configuration: # echo 0x17 0x011111f0> user_pin_configs # LANG=C pasuspender echo 1> reconfig echo: write error: Device or resource busy
You should log out, go to linux console, and kill all processes accessing the sound devices, then do reconfig.
OK, I will try with 0x17 0x111103b or something like that.
Other problem is that the volume on that jack is controlled by center and lfe sliders (in alsamixer), which is probably caused by the fact that alsa is unaware of the 7.1 sound.
And this is not what I can't reproduce.
If more information is needed, please let me know what do you need in addition to alsa-info.sh output.
First off, double-check whether the CLFE mixer really changes the pin amp. At best, take alsa-info.sh output snapshot before and after changing the mixer state, and compare the files (better give both files in the mail).
Here you go. playing.txt is the state when sound comes out of the spdif/side pin, and the center-lfe-half-volume.txt is when the volume is reduced to 50 % afterwards.
Between playing.txt and cneter-lfe-half-volume.txt, I see no change regarding the pin 0x17. The only difference is the DAC volume of NID 0x05. What am I missing?
Nothing probably. I can only confirm that the volume on the spdif/side jack goes down if you move the slider. I will check what does windows do.
Takashi
Julian
[3] http://www.intel.com/standards/hdaudio/pdf/High_Definition_Audio_1_0a.pdf
At Mon, 18 Jul 2011 14:42:55 +0200, Julian Sikorski wrote:
I tried, but without much success [2] - I came up with 0x01111xxx, but I do not have enough understanding on what to put as the last 3 numbers.
The last three numbers are pretty important, so check the HD-audio specification.
The specification [3] says the last 3 are misc, default association and sequence. So what I have now:
- misc: not sure here, since 3 out of 4 bits are reserved. 4th one
should be 0 though, since the port has jack sensing functionality.
- default association: 3, as the working jacks have that set to 3
- sequence: since the working lfe has it set to 0 (center/lfe) and f
(surround), I guess any value in between should work. I am not sure if my reasoning is right though.
The sequence number is the point. The driver assumes that the pins are ordered as front/CLFE/rear/side.
But, currently the multi-io assignment doesn't check the sequence number (because that number refers to the sequence of input pins). The extra channels are assigned in the order of widget NIDs (first from line-in pins, then mic-in pins). Its logic assumes that there are at most two valid input-pins.
That being said, you'd need to modify the driver anyway to make it working properly as I mentioned early in this thread, if a certain channel-map is required.
Takashi
W dniu 2011-07-18 15:23, Takashi Iwai pisze:
At Mon, 18 Jul 2011 14:42:55 +0200, Julian Sikorski wrote:
I tried, but without much success [2] - I came up with 0x01111xxx, but I do not have enough understanding on what to put as the last 3 numbers.
The last three numbers are pretty important, so check the HD-audio specification.
The specification [3] says the last 3 are misc, default association and sequence. So what I have now:
- misc: not sure here, since 3 out of 4 bits are reserved. 4th one
should be 0 though, since the port has jack sensing functionality.
- default association: 3, as the working jacks have that set to 3
- sequence: since the working lfe has it set to 0 (center/lfe) and f
(surround), I guess any value in between should work. I am not sure if my reasoning is right though.
The sequence number is the point. The driver assumes that the pins are ordered as front/CLFE/rear/side.
But, currently the multi-io assignment doesn't check the sequence number (because that number refers to the sequence of input pins). The extra channels are assigned in the order of widget NIDs (first from line-in pins, then mic-in pins). Its logic assumes that there are at most two valid input-pins.
That being said, you'd need to modify the driver anyway to make it working properly as I mentioned early in this thread, if a certain channel-map is required.
Takashi
I see. I am afraid there is not much more I can do then - I am a biologist and writing driver code is far beyond my IT skills. In the meantime, I was able to run reconfig in runlevel 3, but assigning neither 0x0111103e nor 0x011111f0 to 0x17 produced any changes in alsamixer output (which is expected in the light of what you wrote about modifying the driver). When it comes to volume control issue, under windows it is possible to control center, lfe and side channels separately.
Julian
At Tue, 05 Jul 2011 00:50:43 +0200, Julian Sikorski wrote:
W dniu 01.07.2011 07:21, Takashi Iwai pisze:
It's a BIOS bug. It doesn't tell SPDIF is available. Ditto for the 4th stereo out. No pin is exposed by BIOS.
thanks,
Takashi
I finally managed to figure out what these numbers mean. But then I got confused by your statement:
$ cat /sys/class/sound/card0/hwC0D0/init_pin_configs 0x11 0x411111f0 0x12 0x411111f0 0x14 0x99130110 0x15 0x411111f0 0x16 0x411111f0 0x17 0x411111f0 0x18 0x01a11c30 0x19 0x99a30931 0x1a 0x0181143f 0x1b 0x0121101f 0x1c 0x411111f0 0x1d 0x598301f0 0x1e 0x01451120 0x1f 0x411111f0
From what I was able to decipher, 0x1e is a jack, external rear, with
spdif out default output and optical connection. It is black. The same physical socket is used for the last 2 surround channels. Could you please clarify? Thanks in advance.
Two jacks shares the same place, but it doesn't mean that they share the physical connection. SPDIF is optical and the surround is mini-jack. Usually they are implemented in different pins, but placed to a single position.
Takashi
participants (3)
-
Julian Sikorski
-
Raymond Yau
-
Takashi Iwai