[alsa-devel] Problem with VIA VT1708S and git versions of alsa-driver.
Hello,
Recently I'm having some strange issues with my VIA VT1708S on-board sound card. The description might be a bit long, so I'll give a brief summary first.
I have ASUS P5QL/EPU motherboard with VT1708S 8-channel HDA Codec. There are 3 OSs installed on this machine: openSUSE 11.1 (my main system), openSUSE 11.3, Kubuntu 10.04. Audio worked fine until some updates at the beginning of September. Since then I have 2 different issues.
1).On 11.1 - Line In control seems inactive, instead Front Mic control controls the level from Line In jack. Front Mic is constanly disabled. alsaconf does not show hda-intel in the list of detected cards. Latest version it happened with is git20100925. When I compiled stable 1.0.23 sources, everything started working as expected again. I reported this issue on bugtrack: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5133
2) On oS 11.3 I start experiencing problems recording audio either from Mic or from Line. After some experiments I found out that the Capture1 control is somehow broken. Mute switch is reversed. When it is unmuted, there is no audio recorded. When it is muted, recording works. The same happened to at least one more user of openSUSE, see the thread "How to investigate the problem with MIC" on alsa-user mailing list. I've also added my comments to issue https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5130 but now I think it is different issue. Even when I have audio recorded normally when Capture1 is muted, I still have very distorted voice from Mic in Skype. It worked fine before the problem started.
More details: On oS 11.1 I had my audio working fine after updating to 1.0.23 versions of alsa driver. I'm using opensuse/multimedia: repository that provides binary rpm of alsa-driver git snapshots. I have only one current kernel 2.6.27.48 on 11.1. On oS 11.3 audio worked right out of the box, since it uses kernels with alsa-driver 1.0.23. I have 2-3 kernels installed at the same time - normal 2.6.34 from official repository and 2.6.35 from kernel build service.
I'm not sure when exactly the problems started, but definitely at the beginning of September.
I've initially saw that on oS 11.1 I can't hear the audio from my TV card connected to Line In. Then I noticed that Mic does not work in Skype on both 11.1 and 11.3, while it still works on Kubuntu. When I unmuted Front Mic on 11.1 I've suddenly found that it actually enabled Line In. I think now that something went bad with card detecting. Probably on 11.1 with latest git versions my card is not properly detected and some "defaults" are used.
I'm attaching here 2 outputs of alsa-info.sh - 11.1_stable captured with alsa-driver compiled from stable 1.0.23 sources. 11.1_git25 captured with driver compiled with git20100925 version from opensuse/multimedia: repository.
For me the problem with 11.1 is resolved, but probably it's worth checking why latest version from git behave this way.
I'll continue with 11.3 investigation later on.
Regards,
2010/9/25 Mark Goldstein goldstein.mark@gmail.com
Hello,
Recently I'm having some strange issues with my VIA VT1708S on-board sound card. The description might be a bit long, so I'll give a brief summary first.
I have ASUS P5QL/EPU motherboard with VT1708S 8-channel HDA Codec. There are 3 OSs installed on this machine: openSUSE 11.1 (my main system), openSUSE 11.3, Kubuntu 10.04. Audio worked fine until some updates at the beginning of September. Since then I have 2 different issues.
1).On 11.1 - Line In control seems inactive, instead Front Mic control controls the level from Line In jack. Front Mic is constanly disabled. alsaconf does not show hda-intel in the list of detected cards. Latest version it happened with is git20100925. When I compiled stable 1.0.23 sources, everything started working as expected again. I reported this issue on bugtrack: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5133
- On oS 11.3 I start experiencing problems recording audio either
from Mic or from Line. After some experiments I found out that the Capture1 control is somehow broken. Mute switch is reversed. When it is unmuted, there is no audio recorded. When it is muted, recording works. The same happened to at least one more user of openSUSE, see the thread "How to investigate the problem with MIC" on alsa-user mailing list. I've also added my comments to issue https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5130 but now I think it is different issue. Even when I have audio recorded normally when Capture1 is muted, I still have very distorted voice from Mic in Skype. It worked fine before the problem started.
More details: On oS 11.1 I had my audio working fine after updating to 1.0.23 versions of alsa driver. I'm using opensuse/multimedia: repository that provides binary rpm of alsa-driver git snapshots. I have only one current kernel 2.6.27.48 on 11.1. On oS 11.3 audio worked right out of the box, since it uses kernels with alsa-driver 1.0.23. I have 2-3 kernels installed at the same time
- normal 2.6.34 from official repository and 2.6.35 from kernel build
service.
I'm not sure when exactly the problems started, but definitely at the beginning of September.
I've initially saw that on oS 11.1 I can't hear the audio from my TV card connected to Line In. Then I noticed that Mic does not work in Skype on both 11.1 and 11.3, while it still works on Kubuntu. When I unmuted Front Mic on 11.1 I've suddenly found that it actually enabled Line In. I think now that something went bad with card detecting. Probably on 11.1 with latest git versions my card is not properly detected and some "defaults" are used.
I'm attaching here 2 outputs of alsa-info.sh - 11.1_stable captured with alsa-driver compiled from stable 1.0.23 sources. 11.1_git25 captured with driver compiled with git20100925 version from opensuse/multimedia: repository.
For me the problem with 11.1 is resolved, but probably it's worth checking why latest version from git behave this way.
I'll continue with 11.3 investigation later on.
Regards,
Mark Goldstein
In theory, a motherboard with 6 audio jacks at back panel does not need retasking pink and blue jacks as output pins , it seem to me that the "smart5.1" switch is redundant for your motherboard.
it seem this patch may has side effect on those via codec since they need to differentate the front mic and mic at rear panel for retasking
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=bbe959733a719e...
Hi,
On Tue, Sep 28, 2010 at 2:00 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2010/9/25 Mark Goldstein goldstein.mark@gmail.com
Hello,
Recently I'm having some strange issues with my VIA VT1708S on-board sound card. The description might be a bit long, so I'll give a brief summary first.
I have ASUS P5QL/EPU motherboard with VT1708S 8-channel HDA Codec. There are 3 OSs installed on this machine: openSUSE 11.1 (my main system), openSUSE 11.3, Kubuntu 10.04. Audio worked fine until some updates at the beginning of September. Since then I have 2 different issues.
1).On 11.1 - Line In control seems inactive, instead Front Mic control controls the level from Line In jack. Front Mic is constanly disabled. alsaconf does not show hda-intel in the list of detected cards. Latest version it happened with is git20100925. When I compiled stable 1.0.23 sources, everything started working as expected again. I reported this issue on bugtrack: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3D5133
- On oS 11.3 I start experiencing problems recording audio either
from Mic or from Line. After some experiments I found out that the Capture1 control is somehow broken. Mute switch is reversed. When it is unmuted, there is no audio recorded. When it is muted, recording works. The same happened to at least one more user of openSUSE, see the thread "How to investigate the problem with MIC" on alsa-user mailing list. I've also added my comments to issue https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3D5130 but now I think it is different issue. Even when I have audio recorded normally when Capture1 is muted, I still have very distorted voice from Mic in Skype. It worked fine before the problem started.
More details: On oS 11.1 I had my audio working fine after updating to 1.0.23 versions of alsa driver. I'm using opensuse/multimedia: repository that provides binary rpm of alsa-driver git snapshots. I have only one current kernel 2.6.27.48 on 11.1. On oS 11.3 audio worked right out of the box, since it uses kernels with alsa-driver 1.0.23. I have 2-3 kernels installed at the same time
- normal 2.6.34 from official repository and 2.6.35 from kernel build
service.
I'm not sure when exactly the problems started, but definitely at the beginning of September.
I've initially saw that on oS 11.1 I can't hear the audio from my TV card connected to Line In. Then I noticed that Mic does not work in Skype on both 11.1 and 11.3, while it still works on Kubuntu. When I unmuted Front Mic on 11.1 I've suddenly found that it actually enabled Line In. I think now that something went bad with card detecting. Probably on 11.1 with latest git versions my card is not properly detected and some "defaults" are used.
I'm attaching here 2 outputs of alsa-info.sh - =A011.1_stable captured with alsa-driver compiled from stable 1.0.23 sou=
rces.
=A011.1_git25 captured with driver compiled with git20100925 version from opensuse/multimedia: repository.
For me the problem with 11.1 is resolved, but probably it's worth checking why latest version from git behave this way.
I'll continue with 11.3 investigation later on.
Regards,
Mark Goldstein
In theory, a motherboard with 6 audio jacks at back panel does not need retasking pink and blue jacks as output pins , it seem to me that the "smart5.1" switch is redundant for your motherboard.
it seem this patch may has side effect on those via codec since they need=
to
differentate the front mic and mic at rear panel for retasking
http://git.alsa-project.org/?p=3Dalsa-kernel.git;a=3Dcommitdiff;h=3Dbbe95=
9733a719ecffda8ecd7d4b9631a2745e8b4;hp=3D6650d30dfe1cf9ef6e639bd898d3b2f637= f4bf3b
Looks like a possibility.
What bothers me is the fact that with git version the card is not detected properly (on oS 11.1). I missed this detail in my report just because I did not try alsaconf after the problem first occurred. That is, alsaconf does not show it in the list of cards. So I guess that the sound driver uses some defaults (it does indicate the this is hda-intel) that just does not match the actual codec. While when I use stable 1.0.23 version card is detected by alsaconf and works correctly.
_From the other side, the problem on oS 11.3 looks very different. I did not update driver there, just installed additional kernel that also has alsa 1.0.23.
How it could lead to "Capture1" switch "reversing"? And now when I found it out and set it to "mute", Mic works correctly with recording SW and produces distorted audio in Skype in exactly the same configuration where it worked perfectly a couple of weeks ago.
Regards, --=20 Mark Goldstein
2010/9/28 Mark Goldstein goldstein.mark@gmail.com
Hi,
In theory, a motherboard with 6 audio jacks at back panel does not need retasking pink and blue jacks as output pins , it seem to me that the "smart5.1" switch is redundant for your motherboard.
it seem this patch may has side effect on those via codec since they need
to
differentate the front mic and mic at rear panel for retasking
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=bbe959733a719e...
Looks like a possibility.
What bothers me is the fact that with git version the card is not detected properly (on oS 11.1). I missed this detail in my report just because I did not try alsaconf after the problem first occurred. That is, alsaconf does not show it in the list of cards. So I guess that the sound driver uses some defaults (it does indicate the this is hda-intel) that just does not match the actual codec. While when I use stable 1.0.23 version card is detected by alsaconf and works correctly.
From the other side, the problem on oS 11.3 looks very different. I did not update driver there, just installed additional kernel that also has alsa 1.0.23.
How it could lead to "Capture1" switch "reversing"? And now when I found it out and set it to "mute", Mic works correctly with recording SW and produces distorted audio in Skype in exactly the same configuration where it worked perfectly a couple of weeks ago.
Regards,
Mark Goldstein
How did you perform the recording since there are two capturing subdevices ?
Are you sure that Skype/pulseaudo open the same subdevice ?
"Capture1" switch is associated with Node 0x14 [Audio Input]
Refer to the graph in hda_analyzer , when you place the mouse cursor inside the "out" box of the Node 0x1e (Front Mic Pin) , there are three red lines indicate the possible connections to 0x14, 0x16 and 0x17
Unlike the other HDA codec , your vt1708s has only one "Input Souce" control and two ADC
For the other HDA codec, the number of "Input Source" controls is usually equal to the number of ADC, this mean that some input sources (e.g. mic ) can only be connected to one ADC .
As you can see in the graph, node 0x14 can be connected to 0x1e only
All the connected audio path are displayed as blue line and it is strange there are no blue line connected to both the node 0x13 and 0x14 [Audio Input]
Hi,
On Wed, Sep 29, 2010 at 5:06 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2010/9/28 Mark Goldstein goldstein.mark@gmail.com
Hi,
In theory, a motherboard with 6 audio jacks at back panel does not need retasking pink and blue jacks as output pins , it seem to me that the "smart5.1" switch is redundant for your motherboard.
it seem this patch may has side effect on those via codec since they need
to
differentate the front mic and mic at rear panel for retasking
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=bbe959733a719e...
Looks like a possibility.
What bothers me is the fact that with git version the card is not detected properly (on oS 11.1). I missed this detail in my report just because I did not try alsaconf after the problem first occurred. That is, alsaconf does not show it in the list of cards. So I guess that the sound driver uses some defaults (it does indicate the this is hda-intel) that just does not match the actual codec. While when I use stable 1.0.23 version card is detected by alsaconf and works correctly.
From the other side, the problem on oS 11.3 looks very different. I did not update driver there, just installed additional kernel that also has alsa 1.0.23.
How it could lead to "Capture1" switch "reversing"? And now when I found it out and set it to "mute", Mic works correctly with recording SW and produces distorted audio in Skype in exactly the same configuration where it worked perfectly a couple of weeks ago.
Regards,
Mark Goldstein
How did you perform the recording since there are two capturing subdevices ?
When I played with alsamixer before, I saw that only Capture1 works for me. This time I set both Capture1 and Capture2 levels to some high value and saw that Capture2 does not change anything.
2010/9/29 Mark Goldstein goldstein.mark@gmail.com
Hi,
On Wed, Sep 29, 2010 at 5:06 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2010/9/28 Mark Goldstein goldstein.mark@gmail.com
Hi,
In theory, a motherboard with 6 audio jacks at back panel does not
need
retasking pink and blue jacks as output pins , it seem to me that the "smart5.1" switch is redundant for your motherboard.
it seem this patch may has side effect on those via codec since they
need
to
differentate the front mic and mic at rear panel for retasking
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=bbe959733a719e...
Looks like a possibility.
What bothers me is the fact that with git version the card is not detected properly (on oS 11.1). I missed this detail in my report just because I did not try alsaconf after the problem first occurred. That is, alsaconf does not show it in the list of cards. So I guess that the sound driver uses some defaults (it does indicate the this is hda-intel) that just does not match the actual codec. While when I use stable 1.0.23 version card is detected by alsaconf and works correctly.
From the other side, the problem on oS 11.3 looks very different. I did not update driver there, just installed additional kernel that also has alsa 1.0.23.
How it could lead to "Capture1" switch "reversing"? And now when I found it out and set it to "mute", Mic works correctly with recording SW and produces distorted audio in Skype in exactly the same configuration where it worked perfectly a couple of weeks ago.
Regards,
Mark Goldstein
How did you perform the recording since there are two capturing
subdevices ?
When I played with alsamixer before, I saw that only Capture1 works for me. This time I set both Capture1 and Capture2 levels to some high value and saw that Capture2 does not change anything. From the other side, using hda_analyzer I noticed that that MSB of the volume actually means "mute", that is when I see something like 9f there is no sound recored, while 1f produces sound. And then I saw that this bit reflects the "Mute" checkbox state.
Are you sure that Skype/pulseaudo open the same subdevice ?
I think so. First, It worked before. I have no pulseaudio. Skype just uses hw:0 device. It does some recording, but the audio is very distorted (low volume, no high frequencies, kind of clipped). I disabled the Skype option to adjust mixer volumes and play with it myself.
"Capture1" switch is associated with Node 0x14 [Audio Input]
Refer to the graph in hda_analyzer , when you place the mouse cursor
inside
the "out" box of the Node 0x1e (Front Mic Pin) , there are three red
lines
indicate the possible connections to 0x14, 0x16 and 0x17
Unlike the other HDA codec , your vt1708s has only one "Input Souce"
control
and two ADC
For the other HDA codec, the number of "Input Source" controls is
usually
equal to the number of ADC, this mean that some input sources (e.g. mic
)
can only be connected to one ADC .
As you can see in the graph, node 0x14 can be connected to 0x1e only
All the connected audio path are displayed as blue line and it is strange there are no blue line connected to both the node 0x13 and 0x14 [Audio Input]
I will not be able to check it for about a week. When I'll have access to my PC again, I'll re-check and let you know what I see. Thanks a lot. -- Mark Goldstein
if you can run hda-emu on another PC , you can compare the read/write of HDA codec during driver initialization , capturing , set the contents of the given control element in working and non-working version of alsa-driver
To emulate the capturing using subdevice 1 in hda-emu , you need to use the undocumented parameter "c:1" instead of c
as you can see the output of hda-emu , recording through hw:0,0,0 use Node 0x13 and hw:0,0,1 use Node 0x14
Attach PCM dev 0, name VT1708S Analog, type audio, play #2, capture #2 send: NID=0x12, VERB=0xf00(get_parameters), PARM=0xa(PCM) receive: 0xe05e0 send: NID=0x12, VERB=0xf00(get_parameters), PARM=0xb(stream) receive: 0x1 Attach PCM dev 1, name VT1708S Digital, type SPDIF, play #1, capture #0
PCM 0 c 44100 2 16
Open PCM VT1708S Analog for capt send: NID=0x16, VERB=0xf02(get_connect_list), PARM=0x0 receive: 0x1b1a1f10 send: NID=0x1, VERB=0xf73(unknown), PARM=0xe1 invalid command: NID=0x1, verb=0xf73, parm=0xe1 Available PCM parameters: channels: 2/2 formats: S16_LE S32_LE rates: 44100 48000 96000 192000 Prepare PCM, rate=44100, channels=2, format=16 bits PCM format_val = 0x4011 hda_codec_setup_stream: NID=0x13, stream=0x1, channel=0, format=0x4011 send: NID=0x13, VERB=0xf06(get_channel_streamid), PARM=0x0 receive: 0x0 send: NID=0x13, VERB=0x706(set_channel_streamid), PARM=0x10 send: NID=0x13, VERB=0xa00(get_stream_format), PARM=0x0 receive: 0x0 send: NID=0x13, VERB=0x240(set_stream_format), PARM=0x11 PCM Clean up hda_codec_cleanup_stream: NID=0x13 Close PCM send: NID=0x16, VERB=0xf02(get_connect_list), PARM=0x0 receive: 0x1b1a1f10 send: NID=0x1, VERB=0xf73(unknown), PARM=0xe1 invalid command: NID=0x1, verb=0xf73, parm=0xe1
PCM 0 c:1 44100 2 16
Open PCM VT1708S Analog for capt send: NID=0x16, VERB=0xf02(get_connect_list), PARM=0x0 receive: 0x1b1a1f10 send: NID=0x1, VERB=0xf73(unknown), PARM=0xe1 invalid command: NID=0x1, verb=0xf73, parm=0xe1 Available PCM parameters: channels: 2/2 formats: S16_LE S32_LE rates: 44100 48000 96000 192000 Prepare PCM, rate=44100, channels=2, format=16 bits PCM format_val = 0x4011 hda_codec_setup_stream: NID=0x14, stream=0x1, channel=0, format=0x4011 send: NID=0x14, VERB=0xf06(get_channel_streamid), PARM=0x0 receive: 0x0 send: NID=0x14, VERB=0x706(set_channel_streamid), PARM=0x10 send: NID=0x14, VERB=0xa00(get_stream_format), PARM=0x0 receive: 0x0 send: NID=0x14, VERB=0x240(set_stream_format), PARM=0x11 PCM Clean up hda_codec_cleanup_stream: NID=0x14 Close PCM send: NID=0x16, VERB=0xf02(get_connect_list), PARM=0x0 receive: 0x1b1a1f10 send: NID=0x1, VERB=0xf73(unknown), PARM=0xe1 invalid command: NID=0x1, verb=0xf73, parm=0xe1
Hi,
On Wed, Sep 29, 2010 at 4:33 PM, Raymond Yau superquad.vortex2@gmail.com wrote:
2010/9/29 Mark Goldstein goldstein.mark@gmail.com
Hi,
On Wed, Sep 29, 2010 at 5:06 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2010/9/28 Mark Goldstein goldstein.mark@gmail.com
Hi,
In theory, a motherboard with 6 audio jacks at back panel does not
need
retasking pink and blue jacks as output pins , it seem to me that the "smart5.1" switch is redundant for your motherboard.
it seem this patch may has side effect on those via codec since they
need
to
differentate the front mic and mic at rear panel for retasking
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=bbe959733a719e...
Looks like a possibility.
What bothers me is the fact that with git version the card is not detected properly (on oS 11.1). I missed this detail in my report just because I did not try alsaconf after the problem first occurred. That is, alsaconf does not show it in the list of cards. So I guess that the sound driver uses some defaults (it does indicate the this is hda-intel) that just does not match the actual codec. While when I use stable 1.0.23 version card is detected by alsaconf and works correctly.
From the other side, the problem on oS 11.3 looks very different. I did not update driver there, just installed additional kernel that also has alsa 1.0.23.
How it could lead to "Capture1" switch "reversing"? And now when I found it out and set it to "mute", Mic works correctly with recording SW and produces distorted audio in Skype in exactly the same configuration where it worked perfectly a couple of weeks ago.
Regards,
Mark Goldstein
How did you perform the recording since there are two capturing
subdevices ?
When I played with alsamixer before, I saw that only Capture1 works for me. This time I set both Capture1 and Capture2 levels to some high value and saw that Capture2 does not change anything. From the other side, using hda_analyzer I noticed that that MSB of the volume actually means "mute", that is when I see something like 9f there is no sound recored, while 1f produces sound. And then I saw that this bit reflects the "Mute" checkbox state.
Are you sure that Skype/pulseaudo open the same subdevice ?
I think so. First, It worked before. I have no pulseaudio. Skype just uses hw:0 device. It does some recording, but the audio is very distorted (low volume, no high frequencies, kind of clipped). I disabled the Skype option to adjust mixer volumes and play with it myself.
"Capture1" switch is associated with Node 0x14 [Audio Input]
Refer to the graph in hda_analyzer , when you place the mouse cursor
inside
the "out" box of the Node 0x1e (Front Mic Pin) , there are three red
lines
indicate the possible connections to 0x14, 0x16 and 0x17
Unlike the other HDA codec , your vt1708s has only one "Input Souce"
control
and two ADC
For the other HDA codec, the number of "Input Source" controls is
usually
equal to the number of ADC, this mean that some input sources (e.g. mic
)
can only be connected to one ADC .
As you can see in the graph, node 0x14 can be connected to 0x1e only
All the connected audio path are displayed as blue line and it is strange there are no blue line connected to both the node 0x13 and 0x14 [Audio Input]
I will not be able to check it for about a week. When I'll have access to my PC again, I'll re-check and let you know what I see. Thanks a lot. -- Mark Goldstein
if you can run hda-emu on another PC , you can compare the read/write of HDA codec during driver initialization , capturing , set the contents of the given control element in working and non-working version of alsa-driver
To emulate the capturing using subdevice 1 in hda-emu , you need to use the undocumented parameter "c:1" instead of c
as you can see the output of hda-emu , recording through hw:0,0,0 use Node 0x13 and hw:0,0,1 use Node 0x14
Attach PCM dev 0, name VT1708S Analog, type audio, play #2, capture #2 send: NID=0x12, VERB=0xf00(get_parameters), PARM=0xa(PCM) receive: 0xe05e0 send: NID=0x12, VERB=0xf00(get_parameters), PARM=0xb(stream) receive: 0x1 Attach PCM dev 1, name VT1708S Digital, type SPDIF, play #1, capture #0
PCM 0 c 44100 2 16
Open PCM VT1708S Analog for capt send: NID=0x16, VERB=0xf02(get_connect_list), PARM=0x0 receive: 0x1b1a1f10 send: NID=0x1, VERB=0xf73(unknown), PARM=0xe1 invalid command: NID=0x1, verb=0xf73, parm=0xe1 Available PCM parameters: channels: 2/2 formats: S16_LE S32_LE rates: 44100 48000 96000 192000 Prepare PCM, rate=44100, channels=2, format=16 bits PCM format_val = 0x4011 hda_codec_setup_stream: NID=0x13, stream=0x1, channel=0, format=0x4011 send: NID=0x13, VERB=0xf06(get_channel_streamid), PARM=0x0 receive: 0x0 send: NID=0x13, VERB=0x706(set_channel_streamid), PARM=0x10 send: NID=0x13, VERB=0xa00(get_stream_format), PARM=0x0 receive: 0x0 send: NID=0x13, VERB=0x240(set_stream_format), PARM=0x11 PCM Clean up hda_codec_cleanup_stream: NID=0x13 Close PCM send: NID=0x16, VERB=0xf02(get_connect_list), PARM=0x0 receive: 0x1b1a1f10 send: NID=0x1, VERB=0xf73(unknown), PARM=0xe1 invalid command: NID=0x1, verb=0xf73, parm=0xe1
PCM 0 c:1 44100 2 16
Open PCM VT1708S Analog for capt send: NID=0x16, VERB=0xf02(get_connect_list), PARM=0x0 receive: 0x1b1a1f10 send: NID=0x1, VERB=0xf73(unknown), PARM=0xe1 invalid command: NID=0x1, verb=0xf73, parm=0xe1 Available PCM parameters: channels: 2/2 formats: S16_LE S32_LE rates: 44100 48000 96000 192000 Prepare PCM, rate=44100, channels=2, format=16 bits PCM format_val = 0x4011 hda_codec_setup_stream: NID=0x14, stream=0x1, channel=0, format=0x4011 send: NID=0x14, VERB=0xf06(get_channel_streamid), PARM=0x0 receive: 0x0 send: NID=0x14, VERB=0x706(set_channel_streamid), PARM=0x10 send: NID=0x14, VERB=0xa00(get_stream_format), PARM=0x0 receive: 0x0 send: NID=0x14, VERB=0x240(set_stream_format), PARM=0x11 PCM Clean up hda_codec_cleanup_stream: NID=0x14 Close PCM send: NID=0x16, VERB=0xf02(get_connect_list), PARM=0x0 receive: 0x1b1a1f10 send: NID=0x1, VERB=0xf73(unknown), PARM=0xe1 invalid command: NID=0x1, verb=0xf73, parm=0xe1
Raymond, I probably misled you by mentioning Capture1 control. I actually meant 1st Capture control, associated with node 0x13. It is called just "Capture" in mixer. Apologies for mistake. I could see that node 0x13 is connected to node 0x17 (AUD_SEL - Input source). And node 0x1e is one of the possible inputs to 0x17. Playing with Capture2 (Node 0x14) does not change a thing.
Now, I did another additional experiment. I installed latest git version of alsa driver from openSUSE 11.3 multimedia repository and got the same issue I had with 11.1 before: Line In control did not work while Front Mic control actually controls Line In. So at least this is consistent :-(
What is hda-emu you mentioned? I tried searching alsa site and got nothing.
Regards,
2010/10/10 Mark Goldstein goldstein.mark@gmail.com
Hi,
On Wed, Sep 29, 2010 at 4:33 PM, Raymond Yau superquad.vortex2@gmail.com wrote:
2010/9/29 Mark Goldstein goldstein.mark@gmail.com
Hi,
On Wed, Sep 29, 2010 at 5:06 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2010/9/28 Mark Goldstein goldstein.mark@gmail.com
Hi,
In theory, a motherboard with 6 audio jacks at back panel does not
need
retasking pink and blue jacks as output pins , it seem to me that
the
"smart5.1" switch is redundant for your motherboard.
it seem this patch may has side effect on those via codec since
they
need
to
differentate the front mic and mic at rear panel for retasking
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=bbe959733a719e...
Looks like a possibility.
What bothers me is the fact that with git version the card is not detected properly (on oS 11.1). I missed this detail in my report
just
because I did not try alsaconf after the problem first occurred. That is, alsaconf does not show it in the list of cards. So I guess that the sound driver uses some defaults (it does indicate the this is hda-intel) that just does not match the actual codec. While when I use stable 1.0.23 version card is detected by alsaconf and works correctly.
From the other side, the problem on oS 11.3 looks very different. I did not update driver there, just installed additional kernel that also has alsa 1.0.23.
How it could lead to "Capture1" switch "reversing"? And now when I found it out and set it to "mute", Mic works correctly with recording SW and produces distorted audio in Skype in exactly the same configuration where it worked perfectly a couple of weeks ago.
Regards,
Mark Goldstein
How did you perform the recording since there are two capturing
subdevices ?
When I played with alsamixer before, I saw that only Capture1 works for me. This time I set both Capture1 and Capture2 levels to some high value and saw that Capture2 does not change anything. From the other side, using hda_analyzer I noticed that that MSB of the volume actually means "mute", that is when I see something like 9f there is no sound recored, while 1f produces sound. And then I saw that this bit reflects the "Mute" checkbox state.
Are you sure that Skype/pulseaudo open the same subdevice ?
I think so. First, It worked before. I have no pulseaudio. Skype just uses hw:0 device. It does some recording, but the audio is very distorted (low volume, no high frequencies, kind of clipped). I disabled the Skype option to adjust mixer volumes and play with it myself.
"Capture1" switch is associated with Node 0x14 [Audio Input]
Refer to the graph in hda_analyzer , when you place the mouse cursor
inside
the "out" box of the Node 0x1e (Front Mic Pin) , there are three red
lines
indicate the possible connections to 0x14, 0x16 and 0x17
Unlike the other HDA codec , your vt1708s has only one "Input Souce"
control
and two ADC
For the other HDA codec, the number of "Input Source" controls is
usually
equal to the number of ADC, this mean that some input sources (e.g.
mic
)
can only be connected to one ADC .
As you can see in the graph, node 0x14 can be connected to 0x1e only
All the connected audio path are displayed as blue line and it is
strange
there are no blue line connected to both the node 0x13 and 0x14
[Audio
Input]
I will not be able to check it for about a week. When I'll have access to my PC again, I'll re-check and let you know what I see. Thanks a lot. -- Mark Goldstein
if you can run hda-emu on another PC , you can compare the read/write of
HDA
codec during driver initialization , capturing , set the contents of the given control element in working and non-working version of alsa-driver
To emulate the capturing using subdevice 1 in hda-emu , you need to use
the
undocumented parameter "c:1" instead of c
as you can see the output of hda-emu , recording through hw:0,0,0 use
Node
0x13 and hw:0,0,1 use Node 0x14
Attach PCM dev 0, name VT1708S Analog, type audio, play #2, capture #2 send: NID=0x12, VERB=0xf00(get_parameters), PARM=0xa(PCM) receive: 0xe05e0 send: NID=0x12, VERB=0xf00(get_parameters), PARM=0xb(stream) receive: 0x1 Attach PCM dev 1, name VT1708S Digital, type SPDIF, play #1, capture #0
PCM 0 c 44100 2 16
Open PCM VT1708S Analog for capt send: NID=0x16, VERB=0xf02(get_connect_list), PARM=0x0 receive: 0x1b1a1f10 send: NID=0x1, VERB=0xf73(unknown), PARM=0xe1 invalid command: NID=0x1, verb=0xf73, parm=0xe1 Available PCM parameters: channels: 2/2 formats: S16_LE S32_LE rates: 44100 48000 96000 192000 Prepare PCM, rate=44100, channels=2, format=16 bits PCM format_val = 0x4011 hda_codec_setup_stream: NID=0x13, stream=0x1, channel=0, format=0x4011 send: NID=0x13, VERB=0xf06(get_channel_streamid), PARM=0x0 receive: 0x0 send: NID=0x13, VERB=0x706(set_channel_streamid), PARM=0x10 send: NID=0x13, VERB=0xa00(get_stream_format), PARM=0x0 receive: 0x0 send: NID=0x13, VERB=0x240(set_stream_format), PARM=0x11 PCM Clean up hda_codec_cleanup_stream: NID=0x13 Close PCM send: NID=0x16, VERB=0xf02(get_connect_list), PARM=0x0 receive: 0x1b1a1f10 send: NID=0x1, VERB=0xf73(unknown), PARM=0xe1 invalid command: NID=0x1, verb=0xf73, parm=0xe1
PCM 0 c:1 44100 2 16
Open PCM VT1708S Analog for capt send: NID=0x16, VERB=0xf02(get_connect_list), PARM=0x0 receive: 0x1b1a1f10 send: NID=0x1, VERB=0xf73(unknown), PARM=0xe1 invalid command: NID=0x1, verb=0xf73, parm=0xe1 Available PCM parameters: channels: 2/2 formats: S16_LE S32_LE rates: 44100 48000 96000 192000 Prepare PCM, rate=44100, channels=2, format=16 bits PCM format_val = 0x4011 hda_codec_setup_stream: NID=0x14, stream=0x1, channel=0, format=0x4011 send: NID=0x14, VERB=0xf06(get_channel_streamid), PARM=0x0 receive: 0x0 send: NID=0x14, VERB=0x706(set_channel_streamid), PARM=0x10 send: NID=0x14, VERB=0xa00(get_stream_format), PARM=0x0 receive: 0x0 send: NID=0x14, VERB=0x240(set_stream_format), PARM=0x11 PCM Clean up hda_codec_cleanup_stream: NID=0x14 Close PCM send: NID=0x16, VERB=0xf02(get_connect_list), PARM=0x0 receive: 0x1b1a1f10 send: NID=0x1, VERB=0xf73(unknown), PARM=0xe1 invalid command: NID=0x1, verb=0xf73, parm=0xe1
Raymond, I probably misled you by mentioning Capture1 control. I actually meant 1st Capture control, associated with node 0x13. It is called just "Capture" in mixer. Apologies for mistake. I could see that node 0x13 is connected to node 0x17 (AUD_SEL - Input source). And node 0x1e is one of the possible inputs to 0x17. Playing with Capture2 (Node 0x14) does not change a thing.
it is strange to find "Independent HP" on Line In at Ext Rear , seem something wrong in creating "Independent HP" control
Node 0x1b [Pin Complex] wcaps 0x400581: Stereo Control: name="Independent HP", index=0, device=0 Pincap 0x00002334: IN OUT Detect Vref caps: HIZ 50 100 Pin Default 0x0181303e: [Jack] Line In at Ext Rear Conn = 1/8, Color = Blue DefAssociation = 0x3, Sequence = 0xe Pin-ctls: 0x21: IN VREF_50 Unsolicited: tag=04, enabled=1 Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 1 0x18
Now, I did another additional experiment. I installed latest git version of alsa driver from openSUSE 11.3 multimedia repository and got the same issue I had with 11.1 before: Line In control did not work while Front Mic control actually controls Line In. So at least this is consistent :-(
Do you mean you have already tested this patch ?
http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=0c038a0767e71dcda4...
Node 0x16 [Audio Mixer] wcaps 0x20050b: Stereo Amp-In Control: name="Master Front Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Master Front Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Mic Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=1, ofs=0 Control: name="Mic Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=1, ofs=0 Control: name="Line Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=2, ofs=0 Control: name="Line Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=2, ofs=0 Control: name="Front Mic Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=3, ofs=0 Control: name="Front Mic Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=3, ofs=0 Control: name="CD Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="CD Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x16 0x16] [0x19 0x19] [0x10 0x10] [0x1c 0x1c] [0x00 0x00] [0x97 0x97] [0x97 0x97] Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 7 0x10 0x1f 0x1a 0x1b 0x1e 0x1d 0x25
Node 0x17 [Audio Selector] wcaps 0x300501: Stereo Control: name="Input Source", index=0, device=0 Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 6 0x1f 0x1a 0x1b 0x1e* 0x1d 0x16
Simple mixer control 'Input Source',0 Capabilities: cenum Items: 'Stereo Mixer' 'Mic' 'Line' 'Front Mic' 'CD' Item0: 'Front Mic'
What is hda-emu you mentioned? I tried searching alsa site and got nothing.
Regards,
Mark Goldstein
http://git.alsa-project.org/?p=alsa-kernel.git;a=blob;f=Documentation/sound/...
hda-emu is a tool which just dumps the codec register changes and the ALSA-driver internal changes at probing and operating the HD-audio driver
You can easily know any difference in codec register changes in the working version/non working version
e.g. the codec read/write when you change "input source" from mic to front mic or line in
The driver deactivate "Headphone Playback Volume" and "Headphone Playback Mute" control if "Independent HP" mode is OFF.
http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=0713efebfa1a1878fe...
control.13 { iface MIXER name 'Headphone Playback Volume' value.0 33 value.1 33 comment { access 'read write inactive' type INTEGER count 2 range '0 - 42' dbmin -6300 dbmax 0 dbvalue.0 -1350 dbvalue.1 -1350 } } control.14 { iface MIXER name 'Headphone Playback Switch' value.0 true value.1 true comment { access 'read write inactive' type BOOLEAN count 2 } }
Does alsamixer or amixer allow you to change the value of headphone volume/switch when they are inactive ?
why the driver does not deactivate "Side Playback Volume" when independent phone is ON since via_independent_put() increase/decrease spec->multiout.num_dacs ?
Node 0x1d [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Headphone Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Independent HP", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0000233c: IN OUT HP Detect Vref caps: HIZ 50 100 Pin Default 0x0221401f: [Jack] HP Out at Ext Front Conn = 1/8, Color = Green DefAssociation = 0x1, Sequence = 0xf Pin-ctls: 0xc0: OUT HP VREF_HIZ Unsolicited: tag=05, enabled=1 Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 2 0x16* 0x25
Node 0x25 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Side Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Headphone Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x2a, nsteps=0x2a, stepsize=0x05, mute=0 Amp-Out vals: [0x21 0x21] Converter: stream=0, channel=0 PCM: rates [0x5e0]: 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0
Node 0x27 [Audio Selector] wcaps 0x30050d: Stereo Amp-Out Control: name="Side Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 1 0x25
On Sun, Oct 10, 2010 at 3:19 PM, Raymond Yau superquad.vortex2@gmail.com wrote:
2010/10/10 Mark Goldstein goldstein.mark@gmail.com
...
Now, I did another additional experiment. I installed latest git version of alsa driver from openSUSE 11.3 multimedia repository and got the same issue I had with 11.1 before: Line In control did not work while Front Mic control actually controls Line In. So at least this is consistent :-(
Do you mean you have already tested this patch ?
http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=0c038a0767e71dcda4...
It is possible. The binary RPM from openSUSE multimedia repository is called git20101007, that is dated by Oct 7th and this patch was committed on Oct 6th.
I noticed one visible change: Input Source had "Rear Mic" instead of "Mic".
Node 0x16 [Audio Mixer] wcaps 0x20050b: Stereo Amp-In Control: name="Master Front Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Master Front Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Mic Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=1, ofs=0 Control: name="Mic Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=1, ofs=0 Control: name="Line Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=2, ofs=0 Control: name="Line Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=2, ofs=0 Control: name="Front Mic Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=3, ofs=0 Control: name="Front Mic Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=3, ofs=0 Control: name="CD Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="CD Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x16 0x16] [0x19 0x19] [0x10 0x10] [0x1c 0x1c] [0x00 0x00] [0x97 0x97] [0x97 0x97] Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 7 0x10 0x1f 0x1a 0x1b 0x1e 0x1d 0x25
Node 0x17 [Audio Selector] wcaps 0x300501: Stereo Control: name="Input Source", index=0, device=0 Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 6 0x1f 0x1a 0x1b 0x1e* 0x1d 0x16
Simple mixer control 'Input Source',0 Capabilities: cenum Items: 'Stereo Mixer' 'Mic' 'Line' 'Front Mic' 'CD' Item0: 'Front Mic'
What is hda-emu you mentioned? I tried searching alsa site and got nothing.
...
http://git.alsa-project.org/?p=alsa-kernel.git;a=blob;f=Documentation/sound/...
hda-emu is a tool which just dumps the codec register changes and the ALSA-driver internal changes at probing and operating the HD-audio driver
You can easily know any difference in codec register changes in the working version/non working version
e.g. the codec read/write when you change "input source" from mic to front mic or line in
Thanks, I downloaded it. Will read the document and try the hda-emu later.
The driver deactivate "Headphone Playback Volume" and "Headphone Playback Mute" control if "Independent HP" mode is OFF.
http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=0713efebfa1a1878fe...
control.13 { iface MIXER name 'Headphone Playback Volume' value.0 33 value.1 33 comment { access 'read write inactive' type INTEGER count 2 range '0 - 42' dbmin -6300 dbmax 0 dbvalue.0 -1350 dbvalue.1 -1350 } } control.14 { iface MIXER name 'Headphone Playback Switch' value.0 true value.1 true comment { access 'read write inactive' type BOOLEAN count 2 } }
Does alsamixer or amixer allow you to change the value of headphone volume/switch when they are inactive ?
No. The Headphone name is grayed and though it can be selected, the volume can't be changed.
Thanks & regards,
2010/10/11 Mark Goldstein goldstein.mark@gmail.com
I noticed one visible change: Input Source had "Rear Mic" instead of "Mic".
spec->private_imux[1] is un-initialised before calling create_hp_imux() however there is no node with connection list which can be used as input mix for "independent HP" control
How about "Mic Boost" ?
if "Mic" is changed to "Rear Mic" , "Mic Boost Capture Volume" should also be changed to "Rear Mic Boost Capture Volume "
static struct snd_kcontrol_new vt1708S_capture_mixer[] = {
HDA_CODEC_VOLUME("Capture Volume", 0x13, 0x0, HDA_INPUT), HDA_CODEC_MUTE("Capture Switch", 0x13, 0x0, HDA_INPUT), HDA_CODEC_VOLUME_IDX("Capture Volume", 1, 0x14, 0x0, HDA_INPUT), HDA_CODEC_MUTE_IDX("Capture Switch", 1, 0x14, 0x0, HDA_INPUT), HDA_CODEC_VOLUME("Mic Boost Capture Volume", 0x1A, 0x0, HDA_INPUT), HDA_CODEC_VOLUME("Front Mic Boost Capture Volume", 0x1E, 0x0, HDA_INPUT),
Hi,
On Mon, Oct 11, 2010 at 1:09 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2010/10/11 Mark Goldstein goldstein.mark@gmail.com
I noticed one visible change: Input Source had "Rear Mic" instead of "Mic".
spec->private_imux[1] is un-initialised before calling create_hp_imux() however there is no node with connection list which can be used as input mix for "independent HP" control
How about "Mic Boost" ?
if "Mic" is changed to "Rear Mic" , "Mic Boost Capture Volume" should also be changed to "Rear Mic Boost Capture Volume "
static struct snd_kcontrol_new vt1708S_capture_mixer[] = {
HDA_CODEC_VOLUME("Capture Volume", 0x13, 0x0, HDA_INPUT), HDA_CODEC_MUTE("Capture Switch", 0x13, 0x0, HDA_INPUT), HDA_CODEC_VOLUME_IDX("Capture Volume", 1, 0x14, 0x0, HDA_INPUT), HDA_CODEC_MUTE_IDX("Capture Switch", 1, 0x14, 0x0, HDA_INPUT), HDA_CODEC_VOLUME("Mic Boost Capture Volume", 0x1A, 0x0, HDA_INPUT), HDA_CODEC_VOLUME("Front Mic Boost Capture Volume", 0x1E, 0x0, HDA_INPUT),
I've renewed my experiments after long break (sorry, had to do other stuff and since released version 1.0.23 worked for me, I reverted to that version).
I still have not tried hda-emulator, but I made some progress.
1) I compiled the git version (snapshot from Jan 20) for OpenSUSE 11.1 with test kernel 2.6.32.28. I saw the same behavior as before: - Line control does nothing; - Front Mic control actually changes volume of Line In; - Neither Front nor Rear Mic work at all; (Answering to Raymond's question regarding Mic Boost - I have "Rear Mic" control, but Mic Boost).
2) I decided to compare patch.via.c from version 1.0.23 that works for me and git version. It appears to me that the clue could be found in the function vt1708S_auto_create_analog_input_ctls. The one in 1.0.23 uses explicit control indexes, while the function from git version calls vt_auto_create_analog_input_ctls, passing it the array of indexes: static hda_nid_t pin_idxs[] = { 0x1f, 0x1a, 0x1b, 0x1e, 0, 0xff };
Comparing the indexes used in vt1708S_auto_create_analog_input_ctls with those used for other codec and with version from 1.0.23, I started suspecting that the order of indexes is wrong. I changed the array like this: static hda_nid_t pin_idxs[] = { 0, 0x1f, 0x1a, 0x1b, 0x1e, 0xff }; After re-compiling the version I've got much better behavior: - Line control (index 1b) works correctly now; - Front Mic control (index 0x1e) actually controls Rear Mic and this Rear Mic works; - Front mic still does not work; - Rear Mic control (index 0x1a) seems not working and there is still Mic Boost, not Rear Mic Boost.
Maybe someone who knows the code could look at this function and suggest how to fix it?
Regards,
2011/1/27 Mark Goldstein goldstein.mark@gmail.com
Hi,
I've renewed my experiments after long break (sorry, had to do other stuff and since released version 1.0.23 worked for me, I reverted to that version).
I still have not tried hda-emulator, but I made some progress.
- I compiled the git version (snapshot from Jan 20) for OpenSUSE 11.1
with test kernel 2.6.32.28. I saw the same behavior as before:
- Line control does nothing;
- Front Mic control actually changes volume of Line In;
- Neither Front nor Rear Mic work at all; (Answering to Raymond's
question regarding Mic Boost - I have "Rear Mic" control, but Mic Boost).
- I decided to compare patch.via.c from version 1.0.23 that works for
me and git version. It appears to me that the clue could be found in the function vt1708S_auto_create_analog_input_ctls. The one in 1.0.23 uses explicit control indexes, while the function from git version calls vt_auto_create_analog_input_ctls, passing it the array of indexes: static hda_nid_t pin_idxs[] = { 0x1f, 0x1a, 0x1b, 0x1e, 0, 0xff };
Comparing the indexes used in vt1708S_auto_create_analog_input_ctls with those used for other codec and with version from 1.0.23, I started suspecting that the order of indexes is wrong. I changed the array like this: static hda_nid_t pin_idxs[] = { 0, 0x1f, 0x1a, 0x1b, 0x1e, 0xff }; After re-compiling the version I've got much better behavior:
- Line control (index 1b) works correctly now;
- Front Mic control (index 0x1e) actually controls Rear Mic and this
Rear Mic works;
- Front mic still does not work;
- Rear Mic control (index 0x1a) seems not working and there is still
Mic Boost, not Rear Mic Boost.
Do you mean that regiession is caused by this patch ?
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=f3268512c3a5de...
it seem vt_auto_create_analog_input_ctls() try to assign stereo mixer as the first item of the imux(s) node 0x17 and 0x1e
assign those playback volume of those input pins in to stereo mixer for node 0x16
but it should assign auto_pin_cfg_labels[] according to the imux node 0x17 and 0x1e
On Thu, Jan 27, 2011 at 11:09 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2011/1/27 Mark Goldstein goldstein.mark@gmail.com
Hi,
I've renewed my experiments after long break (sorry, had to do other stuff and since released version 1.0.23 worked for me, I reverted to that version).
I still have not tried hda-emulator, but I made some progress.
- I compiled the git version (snapshot from Jan 20) for OpenSUSE 11.1
with test kernel 2.6.32.28. I saw the same behavior as before:
- Line control does nothing;
- Front Mic control actually changes volume of Line In;
- Neither Front nor Rear Mic work at all; (Answering to Raymond's
question regarding Mic Boost - I have "Rear Mic" control, but Mic Boost).
- I decided to compare patch.via.c from version 1.0.23 that works for
me and git version. It appears to me that the clue could be found in the function vt1708S_auto_create_analog_input_ctls. The one in 1.0.23 uses explicit control indexes, while the function from git version calls vt_auto_create_analog_input_ctls, passing it the array of indexes: static hda_nid_t pin_idxs[] = { 0x1f, 0x1a, 0x1b, 0x1e, 0, 0xff };
Comparing the indexes used in vt1708S_auto_create_analog_input_ctls with those used for other codec and with version from 1.0.23, I started suspecting that the order of indexes is wrong. I changed the array like this: static hda_nid_t pin_idxs[] = { 0, 0x1f, 0x1a, 0x1b, 0x1e, 0xff }; After re-compiling the version I've got much better behavior:
- Line control (index 1b) works correctly now;
- Front Mic control (index 0x1e) actually controls Rear Mic and this
Rear Mic works;
- Front mic still does not work;
- Rear Mic control (index 0x1a) seems not working and there is still
Mic Boost, not Rear Mic Boost.
Do you mean that regiession is caused by this patch ?
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=f3268512c3a5de...
Yes, looks very probable. Additional confirmation to this is that I noticed the problem at the beginning of September after installing git version; this patch is dated by Aug 30th.
it seem vt_auto_create_analog_input_ctls() try to assign stereo mixer as the first item of the imux(s) node 0x17 and 0x1e
assign those playback volume of those input pins in to stereo mixer for node 0x16
but it should assign auto_pin_cfg_labels[] according to the imux node 0x17 and 0x1e
Is the order of controls in hda_nid_t_pin_idxs fixed, or depends on specific codec?
In any case, I will probably try to temporary replace the vt1708S_auto_create_analog_input_ctls by the one from 1.0.23 and see if this will fix the issue.
Thanks,
2011/1/27 Mark Goldstein goldstein.mark@gmail.com
On Thu, Jan 27, 2011 at 11:09 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2011/1/27 Mark Goldstein goldstein.mark@gmail.com
Hi,
I've renewed my experiments after long break (sorry, had to do other stuff and since released version 1.0.23 worked for me, I reverted to that version).
I still have not tried hda-emulator, but I made some progress.
- I compiled the git version (snapshot from Jan 20) for OpenSUSE 11.1
with test kernel 2.6.32.28. I saw the same behavior as before:
- Line control does nothing;
- Front Mic control actually changes volume of Line In;
- Neither Front nor Rear Mic work at all; (Answering to Raymond's
question regarding Mic Boost - I have "Rear Mic" control, but Mic Boost).
- I decided to compare patch.via.c from version 1.0.23 that works for
me and git version. It appears to me that the clue could be found in the function vt1708S_auto_create_analog_input_ctls. The one in 1.0.23 uses explicit control indexes, while the function from git version calls vt_auto_create_analog_input_ctls, passing it the array of indexes: static hda_nid_t pin_idxs[] = { 0x1f, 0x1a, 0x1b, 0x1e, 0, 0xff };
Comparing the indexes used in vt1708S_auto_create_analog_input_ctls with those used for other codec and with version from 1.0.23, I started suspecting that the order of indexes is wrong. I changed the array like this: static hda_nid_t pin_idxs[] = { 0, 0x1f, 0x1a, 0x1b, 0x1e, 0xff }; After re-compiling the version I've got much better behavior:
- Line control (index 1b) works correctly now;
- Front Mic control (index 0x1e) actually controls Rear Mic and this
Rear Mic works;
- Front mic still does not work;
- Rear Mic control (index 0x1a) seems not working and there is still
Mic Boost, not Rear Mic Boost.
Do you mean that regiession is caused by this patch ?
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=f3268512c3a5de...
Yes, looks very probable. Additional confirmation to this is that I noticed the problem at the beginning of September after installing git version; this patch is dated by Aug 30th.
it seem vt_auto_create_analog_input_ctls() try to assign stereo mixer as
the
first item of the imux(s) node 0x17 and 0x1e
assign those playback volume of those input pins in to stereo mixer for
node
0x16
but it should assign auto_pin_cfg_labels[] according to the imux node
0x17
and 0x1e
Is the order of controls in hda_nid_t_pin_idxs fixed, or depends on specific codec?
In any case, I will probably try to temporary replace the vt1708S_auto_create_analog_input_ctls by the one from 1.0.23 and see if this will fix the issue.
Either [Audio Input] nodes connect directly to input pin [Pin complex] or connected to [Audio Selector] which has a connection list
Node 0x13 [Audio Input] wcaps 0x10051b: Stereo Amp-In Control: name="Capture Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Capture Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Device: name="VT1708S Analog", type="Audio", device=0 Amp-In caps: ofs=0x0b, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x93 0x93] Converter: stream=1, channel=0 SDI-Select: 0 PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 1 0x17
ARECORD
**** List of CAPTURE Hardware Devices **** card 0: Intel [HDA Intel], device 0: VT1708S Analog [VT1708S Analog] Subdevices: 2/2 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1
dsnoop does work properlry when there is more than on subdevices since dmix/dsnoop must use subdevice 0
This mean that the subdevice 1 is only connected to mic at front panel
Node 0x14 [Audio Input] wcaps 0x10051b: Stereo Amp-In Control: name="Capture Volume", index=1, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Capture Switch", index=1, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Amp-In caps: ofs=0x0b, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x80 0x80] Converter: stream=0, channel=0 SDI-Select: 0 PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 1 0x1e
Node 0x1e [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Front Mic Boost Capture Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Smart 5.1", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0000233c: IN OUT HP Detect Vref caps: HIZ 50 100 Pin Default 0x02a19038: [Jack] Mic at Ext Front Conn = 1/8, Color = Pink DefAssociation = 0x3, Sequence = 0x8 Pin-ctls: 0x21: IN VREF_50 Unsolicited: tag=04, enabled=1 Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 2 0x16 0x25*
Auto parsing give you a list of input pins , mic, cd ,aux, ...
Just need the "stereo mixer" node 0x16 and the list of input pins to build the enum item list of Input Source with the position of those input pin in the connection list of [Audio selector] to change the amp in values
Node 0x17 [Audio Selector] wcaps 0x300501: Stereo Control: name="Input Source", index=0, device=0 Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 6 0x1f 0x1a* 0x1b 0x1e 0x1d 0x16
the list of input pins can also be used to create those "Playback Volume" controls and "mute" switches with the position of those input in in the connection list of the strereo mixer [Audio Mixer]
Node 0x16 [Audio Mixer] wcaps 0x20050b: Stereo Amp-In Control: name="Master Front Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Master Front Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Mic Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=2, ofs=0 Control: name="Mic Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=2, ofs=0 Control: name="Front Mic Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=4, ofs=0 Control: name="Front Mic Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=4, ofs=0 Control: name="Line Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=3, ofs=0 Control: name="Line Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=3, ofs=0 Control: name="CD Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=1, ofs=0 Control: name="CD Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=1, ofs=0 Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x0f 0x14] [0x17 0x17] [0x80 0x80] [0x1b 0x1b] [0x9b 0x9b] [0x97 0x97] [0x97 0x97] Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 7 0x10 0x1f 0x1a 0x1b 0x1e 0x1d 0x25
**** List of PLAYBACK Hardware Devices **** card 0: Intel [HDA Intel], device 0: VT1708S Analog [VT1708S Analog] Subdevices: 2/2 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1
The independent headpone seem share with "side' channel since vt1708s only has 8 channels
Node 0x25 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Side Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Headphone Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x2a, nsteps=0x2a, stepsize=0x05, mute=0 Amp-Out vals: [0x24 0x24] Converter: stream=0, channel=0 PCM: rates [0x5e0]: 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0
On Fri, Jan 28, 2011 at 2:47 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2011/1/27 Mark Goldstein goldstein.mark@gmail.com
On Thu, Jan 27, 2011 at 11:09 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2011/1/27 Mark Goldstein goldstein.mark@gmail.com
Hi,
I've renewed my experiments after long break (sorry, had to do other stuff and since released version 1.0.23 worked for me, I reverted to that version).
I still have not tried hda-emulator, but I made some progress.
- I compiled the git version (snapshot from Jan 20) for OpenSUSE 11.1
with test kernel 2.6.32.28. I saw the same behavior as before:
- Line control does nothing;
- Front Mic control actually changes volume of Line In;
- Neither Front nor Rear Mic work at all; (Answering to Raymond's
question regarding Mic Boost - I have "Rear Mic" control, but Mic Boost).
- I decided to compare patch.via.c from version 1.0.23 that works for
me and git version. It appears to me that the clue could be found in the function vt1708S_auto_create_analog_input_ctls. The one in 1.0.23 uses explicit control indexes, while the function from git version calls vt_auto_create_analog_input_ctls, passing it the array of indexes: static hda_nid_t pin_idxs[] = { 0x1f, 0x1a, 0x1b, 0x1e, 0, 0xff };
Comparing the indexes used in vt1708S_auto_create_analog_input_ctls with those used for other codec and with version from 1.0.23, I started suspecting that the order of indexes is wrong. I changed the array like this: static hda_nid_t pin_idxs[] = { 0, 0x1f, 0x1a, 0x1b, 0x1e, 0xff }; After re-compiling the version I've got much better behavior:
- Line control (index 1b) works correctly now;
- Front Mic control (index 0x1e) actually controls Rear Mic and this
Rear Mic works;
- Front mic still does not work;
- Rear Mic control (index 0x1a) seems not working and there is still
Mic Boost, not Rear Mic Boost.
Do you mean that regiession is caused by this patch ?
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=f3268512c3a5de...
Yes, looks very probable. Additional confirmation to this is that I noticed the problem at the beginning of September after installing git version; this patch is dated by Aug 30th.
it seem vt_auto_create_analog_input_ctls() try to assign stereo mixer as
the
first item of the imux(s) node 0x17 and 0x1e
assign those playback volume of those input pins in to stereo mixer for
node
0x16
but it should assign auto_pin_cfg_labels[] according to the imux node
0x17
and 0x1e
Is the order of controls in hda_nid_t_pin_idxs fixed, or depends on specific codec?
In any case, I will probably try to temporary replace the vt1708S_auto_create_analog_input_ctls by the one from 1.0.23 and see if this will fix the issue.
Either [Audio Input] nodes connect directly to input pin [Pin complex] or connected to [Audio Selector] which has a connection list
...
Node 0x17 [Audio Selector] wcaps 0x300501: Stereo Control: name="Input Source", index=0, device=0 Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 6 0x1f 0x1a* 0x1b 0x1e 0x1d 0x16
Hi,
I think I found one problem with Audio Selector. The problem with the above mentioned patch is that vt_auto_create_analog_input_ctls uses the same idx when creating new analog input and when adding item to imux:
err = via_new_analog_input(spec, label, type_idx, idx, cap_nid); ... snd_hda_add_imux_item(imux, label, idx, NULL);
In older version that worked for me (1.0.23) for some codecs (including my 1708S) when adding item to imux, (idx - 1) is used.
So when specific Input source is selected throught the mixer application, actually the next one is marked "active" in Node 0x17.
I copied the body of vt_auto_create_analog_input_ctls into vt1708S_auto_create_analog_input_ctls and changed the call to snd_hda_add_imux_item like that:
static int vt1708S_auto_create_analog_input_ctls(struct hda_codec *codec, const struct auto_pin_cfg *cfg) { static hda_nid_t pin_idxs[] = { 0, 0x1f, 0x1a, 0x1b, 0x1e, 0xff }; /*return vt_auto_create_analog_input_ctls(codec, cfg, 0x16, pin_idxs, ARRAY_SIZE(pin_idxs)); */
struct via_spec *spec = codec->spec; struct hda_input_mux *imux = &spec->private_imux[0]; int i, pin, err, idx, type, type_idx = 0; /* for internal loopback recording select */ snd_hda_add_imux_item(imux, "Stereo Mixer", 5, NULL);
for (i = 0; i < cfg->num_inputs; i++) { const char *label; type = cfg->inputs[i].type; pin = cfg->inputs[i].pin; for (idx = 0; idx < ARRAY_SIZE(pin_idxs); idx++) { if (pin_idxs[idx] == pin) break; } if (idx >= ARRAY_SIZE(pin_idxs)) continue; if (i > 0 && type == cfg->inputs[i - 1].type) type_idx++; else type_idx = 0; label = hda_get_autocfg_input_label(codec, cfg, i); err = via_new_analog_input(spec, label, type_idx, idx, 0x16); if (err < 0) return err; snd_hda_add_imux_item(imux, label, idx - 1, NULL); ^^^^^^^^^ } }
and now the 0x17 shows the correct active source.
BTW, the type_idx is passed to via_new_analog_input and then to __via_add_control, where it is not used at all.
Still trying to figure out why only Rear Mic works while Front Mic does not.
On Sat, Jan 29, 2011 at 11:37 AM, Mark Goldstein goldstein.mark@gmail.com wrote:
On Fri, Jan 28, 2011 at 2:47 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2011/1/27 Mark Goldstein goldstein.mark@gmail.com
On Thu, Jan 27, 2011 at 11:09 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2011/1/27 Mark Goldstein goldstein.mark@gmail.com
Still trying to figure out why only Rear Mic works while Front Mic does not.
Ok, for some reason Pin-ctls for Front Mic (0x1e) set to VREF Hi-Z. After I set it to VREF 50 using hda-analyser, Front Mic started working. Have to figure out why it is set to Hi-Z.
On Sat, Jan 29, 2011 at 12:42 PM, Mark Goldstein goldstein.mark@gmail.com wrote:
On Sat, Jan 29, 2011 at 11:37 AM, Mark Goldstein goldstein.mark@gmail.com wrote:
On Fri, Jan 28, 2011 at 2:47 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2011/1/27 Mark Goldstein goldstein.mark@gmail.com
On Thu, Jan 27, 2011 at 11:09 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2011/1/27 Mark Goldstein goldstein.mark@gmail.com
Still trying to figure out why only Rear Mic works while Front Mic does not.
Ok, for some reason Pin-ctls for Front Mic (0x1e) set to VREF Hi-Z. After I set it to VREF 50 using hda-analyser, Front Mic started working. Have to figure out why it is set to Hi-Z.
static void via_auto_init_analog_input(struct hda_codec *codec) { struct via_spec *spec = codec->spec; const struct auto_pin_cfg *cfg = &spec->autocfg; unsigned int ctl; int i;
for (i = 0; i < cfg->num_inputs; i++) { hda_nid_t nid = cfg->inputs[i].pin; if (spec->smart51_enabled && is_smart51_pins(spec, nid)) ctl = PIN_OUT; else if (i == AUTO_PIN_MIC) ^^^^^^^^^^^^^^^^^^^^^^^^^ ctl = PIN_VREF50; else ctl = PIN_IN; snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_PIN_WIDGET_CONTROL, ctl); } }
Should it probably be else if (cfg->input[i].type == AUTO_PIN_MIC) ?
On Sat, Jan 29, 2011 at 12:53 PM, Mark Goldstein goldstein.mark@gmail.com wrote:
On Sat, Jan 29, 2011 at 12:42 PM, Mark Goldstein goldstein.mark@gmail.com wrote:
On Sat, Jan 29, 2011 at 11:37 AM, Mark Goldstein goldstein.mark@gmail.com wrote:
On Fri, Jan 28, 2011 at 2:47 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2011/1/27 Mark Goldstein goldstein.mark@gmail.com
On Thu, Jan 27, 2011 at 11:09 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2011/1/27 Mark Goldstein goldstein.mark@gmail.com
Still trying to figure out why only Rear Mic works while Front Mic does not.
Ok, for some reason Pin-ctls for Front Mic (0x1e) set to VREF Hi-Z. After I set it to VREF 50 using hda-analyser, Front Mic started working. Have to figure out why it is set to Hi-Z.
static void via_auto_init_analog_input(struct hda_codec *codec) { struct via_spec *spec = codec->spec; const struct auto_pin_cfg *cfg = &spec->autocfg; unsigned int ctl; int i;
for (i = 0; i < cfg->num_inputs; i++) { hda_nid_t nid = cfg->inputs[i].pin; if (spec->smart51_enabled && is_smart51_pins(spec, nid)) ctl = PIN_OUT; else if (i == AUTO_PIN_MIC) ^^^^^^^^^^^^^^^^^^^^^^^^^ ctl = PIN_VREF50; else ctl = PIN_IN; snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_PIN_WIDGET_CONTROL, ctl); } }
Should it probably be else if (cfg->input[i].type == AUTO_PIN_MIC) ?
OK, now it works for me. So totally there were 3 changes: 1) setting of PIN control for Mics 2) shifting the ids in pin_idxs one position to the right 3) using specialized version of vt_auto_create_analog_input_ctls, that passes idx - 1 to snd_hda_add_imux_item.
Well, instead of last two changes it was probably possible to use only 3rd, but instead of passing idx - 1 to snd_hda_add_imux_item pass idx + 1 to via_new_analog_input.
Of course it should be done in more common way, since not only VT1708S used different indexes for via_new_analog_input and snd_hda_add_imux_item.
2011/1/29 Mark Goldstein goldstein.mark@gmail.com
On Sat, Jan 29, 2011 at 12:53 PM, Mark Goldstein goldstein.mark@gmail.com wrote:
On Sat, Jan 29, 2011 at 12:42 PM, Mark Goldstein goldstein.mark@gmail.com wrote:
On Sat, Jan 29, 2011 at 11:37 AM, Mark Goldstein goldstein.mark@gmail.com wrote:
On Fri, Jan 28, 2011 at 2:47 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2011/1/27 Mark Goldstein goldstein.mark@gmail.com
On Thu, Jan 27, 2011 at 11:09 AM, Raymond Yau superquad.vortex2@gmail.com wrote: > 2011/1/27 Mark Goldstein goldstein.mark@gmail.com >
Still trying to figure out why only Rear Mic works while Front Mic does
not.
Ok, for some reason Pin-ctls for Front Mic (0x1e) set to VREF Hi-Z. After I set it to VREF 50 using hda-analyser, Front Mic started working. Have to figure out why it is set to Hi-Z.
static void via_auto_init_analog_input(struct hda_codec *codec) { struct via_spec *spec = codec->spec; const struct auto_pin_cfg *cfg = &spec->autocfg; unsigned int ctl; int i;
for (i = 0; i < cfg->num_inputs; i++) { hda_nid_t nid = cfg->inputs[i].pin; if (spec->smart51_enabled && is_smart51_pins(spec, nid)) ctl = PIN_OUT; else if (i == AUTO_PIN_MIC) ^^^^^^^^^^^^^^^^^^^^^^^^^ ctl = PIN_VREF50; else ctl = PIN_IN; snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_PIN_WIDGET_CONTROL, ctl); }}
Should it probably be else if (cfg->input[i].type == AUTO_PIN_MIC) ?
OK, now it works for me. So totally there were 3 changes:
- setting of PIN control for Mics
- shifting the ids in pin_idxs one position to the right
- using specialized version of vt_auto_create_analog_input_ctls, that
passes idx - 1 to snd_hda_add_imux_item.
Well, instead of last two changes it was probably possible to use only 3rd, but instead of passing idx - 1 to snd_hda_add_imux_item pass idx
- 1 to via_new_analog_input.
Of course it should be done in more common way, since not only VT1708S used different indexes for via_new_analog_input and snd_hda_add_imux_item.
The reason is assign "Stereo Mix" as first element of input source ,
In snd_hda_input_mux_put() , imux->items[].index is the position of the pin in the connection list
snd_hda_codec_write_cache(codec, nid, 0, AC_VERB_SET_CONNECT_SEL, imux->items[idx].index);
if you look at print_codec_info() in hda_proc.c
you can get the connection list of imux using snd_hda_get_connections()
conn_len = snd_hda_get_connections(codec, nid, conn, HDA_MAX_CONNECTIONS);
Raymond,
On Mon, Jan 31, 2011 at 11:22 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2011/1/29 Mark Goldstein goldstein.mark@gmail.com
On Sat, Jan 29, 2011 at 12:53 PM, Mark Goldstein goldstein.mark@gmail.com wrote:
On Sat, Jan 29, 2011 at 12:42 PM, Mark Goldstein goldstein.mark@gmail.com wrote:
On Sat, Jan 29, 2011 at 11:37 AM, Mark Goldstein goldstein.mark@gmail.com wrote:
On Fri, Jan 28, 2011 at 2:47 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2011/1/27 Mark Goldstein goldstein.mark@gmail.com
> On Thu, Jan 27, 2011 at 11:09 AM, Raymond Yau > superquad.vortex2@gmail.com wrote: > > 2011/1/27 Mark Goldstein goldstein.mark@gmail.com > >
Still trying to figure out why only Rear Mic works while Front Mic does
not.
Ok, for some reason Pin-ctls for Front Mic (0x1e) set to VREF Hi-Z. After I set it to VREF 50 using hda-analyser, Front Mic started working. Have to figure out why it is set to Hi-Z.
static void via_auto_init_analog_input(struct hda_codec *codec) { struct via_spec *spec = codec->spec; const struct auto_pin_cfg *cfg = &spec->autocfg; unsigned int ctl; int i;
for (i = 0; i < cfg->num_inputs; i++) { hda_nid_t nid = cfg->inputs[i].pin; if (spec->smart51_enabled && is_smart51_pins(spec, nid)) ctl = PIN_OUT; else if (i == AUTO_PIN_MIC) ^^^^^^^^^^^^^^^^^^^^^^^^^ ctl = PIN_VREF50; else ctl = PIN_IN; snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_PIN_WIDGET_CONTROL, ctl); } }
Should it probably be else if (cfg->input[i].type == AUTO_PIN_MIC) ?
OK, now it works for me. So totally there were 3 changes:
- setting of PIN control for Mics
- shifting the ids in pin_idxs one position to the right
- using specialized version of vt_auto_create_analog_input_ctls, that
passes idx - 1 to snd_hda_add_imux_item.
Well, instead of last two changes it was probably possible to use only 3rd, but instead of passing idx - 1 to snd_hda_add_imux_item pass idx
- 1 to via_new_analog_input.
Of course it should be done in more common way, since not only VT1708S used different indexes for via_new_analog_input and snd_hda_add_imux_item.
The reason is assign "Stereo Mix" as first element of input source ,
In snd_hda_input_mux_put() , imux->items[].index is the position of the pin in the connection list
snd_hda_codec_write_cache(codec, nid, 0, AC_VERB_SET_CONNECT_SEL, imux->items[idx].index);
if you look at print_codec_info() in hda_proc.c
you can get the connection list of imux using snd_hda_get_connections()
conn_len = snd_hda_get_connections(codec, nid, conn, HDA_MAX_CONNECTIONS);
... Not sure what do you mean. In case of VT1708S Stereo Mixer is added with index 5 (and it was so in 1.0.23 also). I noticed that in part of the codecs Stereo Mixer is passed with index 0 and there the same idx is used for both snd_hda_add_imux_item and via_new_analog_input. But for VT1708S and some others Stereo Mixer is passed as the last element in the array.
In any case, using of idx and idx -1 definitely resolved the problem.
Also I think that the issue with Mic Pin configuration is generic for patch_via.c - if you have more than one Mic, the current git code will configure correctly only the first one (index 0). In 1.0.23 the code was checking whether index is < that that of the FrontMic. Probably it assumed that Front Mic is always the last one in the connection list. The new code only checks for index 0. Since there is now explicit field for input type, I think the change I did (cfg->input[i].type == AUTO_PIN_MIC) should be OK.
2011/1/31 Mark Goldstein goldstein.mark@gmail.com
Raymond,
On Mon, Jan 31, 2011 at 11:22 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2011/1/29 Mark Goldstein goldstein.mark@gmail.com
On Sat, Jan 29, 2011 at 12:53 PM, Mark Goldstein goldstein.mark@gmail.com wrote:
On Sat, Jan 29, 2011 at 12:42 PM, Mark Goldstein goldstein.mark@gmail.com wrote:
On Sat, Jan 29, 2011 at 11:37 AM, Mark Goldstein goldstein.mark@gmail.com wrote:
On Fri, Jan 28, 2011 at 2:47 AM, Raymond Yau superquad.vortex2@gmail.com wrote: > 2011/1/27 Mark Goldstein goldstein.mark@gmail.com > >> On Thu, Jan 27, 2011 at 11:09 AM, Raymond Yau >> superquad.vortex2@gmail.com wrote: >> > 2011/1/27 Mark Goldstein goldstein.mark@gmail.com >> >
Still trying to figure out why only Rear Mic works while Front Mic
does
not.
Ok, for some reason Pin-ctls for Front Mic (0x1e) set to VREF Hi-Z. After I set it to VREF 50 using hda-analyser, Front Mic started working. Have to figure out why it is set to Hi-Z.
static void via_auto_init_analog_input(struct hda_codec *codec) { struct via_spec *spec = codec->spec; const struct auto_pin_cfg *cfg = &spec->autocfg; unsigned int ctl; int i;
for (i = 0; i < cfg->num_inputs; i++) { hda_nid_t nid = cfg->inputs[i].pin; if (spec->smart51_enabled && is_smart51_pins(spec,nid))
ctl = PIN_OUT; else if (i == AUTO_PIN_MIC) ^^^^^^^^^^^^^^^^^^^^^^^^^ ctl = PIN_VREF50; else ctl = PIN_IN; snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_PIN_WIDGET_CONTROL,ctl);
}}
Should it probably be else if (cfg->input[i].type == AUTO_PIN_MIC) ?
OK, now it works for me. So totally there were 3 changes:
- setting of PIN control for Mics
- shifting the ids in pin_idxs one position to the right
- using specialized version of vt_auto_create_analog_input_ctls, that
passes idx - 1 to snd_hda_add_imux_item.
Well, instead of last two changes it was probably possible to use only 3rd, but instead of passing idx - 1 to snd_hda_add_imux_item pass idx
- 1 to via_new_analog_input.
Of course it should be done in more common way, since not only VT1708S used different indexes for via_new_analog_input and snd_hda_add_imux_item.
The reason is assign "Stereo Mix" as first element of input source ,
In snd_hda_input_mux_put() , imux->items[].index is the position of the
pin
in the connection list
snd_hda_codec_write_cache(codec, nid, 0, AC_VERB_SET_CONNECT_SEL, imux->items[idx].index);
if you look at print_codec_info() in hda_proc.c
you can get the connection list of imux using snd_hda_get_connections()
conn_len = snd_hda_get_connections(codec, nid, conn, HDA_MAX_CONNECTIONS);
... Not sure what do you mean. In case of VT1708S Stereo Mixer is added with index 5 (and it was so in 1.0.23 also). I noticed that in part of the codecs Stereo Mixer is passed with index 0 and there the same idx is used for both snd_hda_add_imux_item and via_new_analog_input. But for VT1708S and some others Stereo Mixer is passed as the last element in the array.
In any case, using of idx and idx -1 definitely resolved the problem.
Also I think that the issue with Mic Pin configuration is generic for patch_via.c - if you have more than one Mic, the current git code will configure correctly only the first one (index 0). In 1.0.23 the code was checking whether index is < that that of the FrontMic. Probably it assumed that Front Mic is always the last one in the connection list. The new code only checks for index 0. Since there is now explicit field for input type, I think the change I did (cfg->input[i].type == AUTO_PIN_MIC) should be OK.
Node 0x17 [Audio Selector] wcaps 0x300501: Stereo Control: name="Input Source", index=0, device=0 Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 6 0x1f 0x1a* 0x1b 0x1e 0x1d 0x16
static int vt1708S_auto_create_analog_input_ctls(struct hda_codec *codec, const struct auto_pin_cfg *cfg) { static hda_nid_t pin_idxs[] = { 0x1f, 0x1a, 0x1b, 0x1e, 0, 0xff }; return vt_auto_create_analog_input_ctls(codec, cfg, 0x16, pin_idxs, ARRAY_SIZE(pin_idxs)); }
you should notice that pin_idxs[] is just the connection list of imux node 0x17
the position of 0xff is the nid of the stereo mixer 0x16
0x1f [Fixed] CD is also input pins
you don't need to add 0x1d since 0x1d is not in cfg->inputs[i].pin
The routine just add stereo mixer first into the input source items
On Mon, Jan 31, 2011 at 4:26 PM, Raymond Yau superquad.vortex2@gmail.com wrote:
2011/1/31 Mark Goldstein goldstein.mark@gmail.com
Raymond,
On Mon, Jan 31, 2011 at 11:22 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2011/1/29 Mark Goldstein goldstein.mark@gmail.com
On Sat, Jan 29, 2011 at 12:53 PM, Mark Goldstein goldstein.mark@gmail.com wrote:
On Sat, Jan 29, 2011 at 12:42 PM, Mark Goldstein goldstein.mark@gmail.com wrote:
On Sat, Jan 29, 2011 at 11:37 AM, Mark Goldstein goldstein.mark@gmail.com wrote: > On Fri, Jan 28, 2011 at 2:47 AM, Raymond Yau > superquad.vortex2@gmail.com wrote: >> 2011/1/27 Mark Goldstein goldstein.mark@gmail.com >> >>> On Thu, Jan 27, 2011 at 11:09 AM, Raymond Yau >>> superquad.vortex2@gmail.com wrote: >>> > 2011/1/27 Mark Goldstein goldstein.mark@gmail.com >>> >
> Still trying to figure out why only Rear Mic works while Front Mic
does
not.
Ok, for some reason Pin-ctls for Front Mic (0x1e) set to VREF Hi-Z. After I set it to VREF 50 using hda-analyser, Front Mic started working. Have to figure out why it is set to Hi-Z.
static void via_auto_init_analog_input(struct hda_codec *codec) { struct via_spec *spec = codec->spec; const struct auto_pin_cfg *cfg = &spec->autocfg; unsigned int ctl; int i;
for (i = 0; i < cfg->num_inputs; i++) { hda_nid_t nid = cfg->inputs[i].pin; if (spec->smart51_enabled && is_smart51_pins(spec,
nid))
ctl = PIN_OUT; else if (i == AUTO_PIN_MIC) ^^^^^^^^^^^^^^^^^^^^^^^^^ ctl = PIN_VREF50; else ctl = PIN_IN; snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_PIN_WIDGET_CONTROL,
ctl);
} }
Should it probably be else if (cfg->input[i].type == AUTO_PIN_MIC) ?
OK, now it works for me. So totally there were 3 changes:
- setting of PIN control for Mics
- shifting the ids in pin_idxs one position to the right
- using specialized version of vt_auto_create_analog_input_ctls, that
passes idx - 1 to snd_hda_add_imux_item.
Well, instead of last two changes it was probably possible to use only 3rd, but instead of passing idx - 1 to snd_hda_add_imux_item pass idx
- 1 to via_new_analog_input.
Of course it should be done in more common way, since not only VT1708S used different indexes for via_new_analog_input and snd_hda_add_imux_item.
The reason is assign "Stereo Mix" as first element of input source ,
In snd_hda_input_mux_put() , imux->items[].index is the position of the
pin
in the connection list
snd_hda_codec_write_cache(codec, nid, 0, AC_VERB_SET_CONNECT_SEL, imux->items[idx].index);
if you look at print_codec_info() in hda_proc.c
you can get the connection list of imux using snd_hda_get_connections()
conn_len = snd_hda_get_connections(codec, nid, conn, HDA_MAX_CONNECTIONS);
... Not sure what do you mean. In case of VT1708S Stereo Mixer is added with index 5 (and it was so in 1.0.23 also). I noticed that in part of the codecs Stereo Mixer is passed with index 0 and there the same idx is used for both snd_hda_add_imux_item and via_new_analog_input. But for VT1708S and some others Stereo Mixer is passed as the last element in the array.
In any case, using of idx and idx -1 definitely resolved the problem.
Also I think that the issue with Mic Pin configuration is generic for patch_via.c - if you have more than one Mic, the current git code will configure correctly only the first one (index 0). In 1.0.23 the code was checking whether index is < that that of the FrontMic. Probably it assumed that Front Mic is always the last one in the connection list. The new code only checks for index 0. Since there is now explicit field for input type, I think the change I did (cfg->input[i].type == AUTO_PIN_MIC) should be OK.
Node 0x17 [Audio Selector] wcaps 0x300501: Stereo Control: name="Input Source", index=0, device=0 Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 6 0x1f 0x1a* 0x1b 0x1e 0x1d 0x16
static int vt1708S_auto_create_analog_input_ctls(struct hda_codec *codec, const struct auto_pin_cfg *cfg) { static hda_nid_t pin_idxs[] = { 0x1f, 0x1a, 0x1b, 0x1e, 0, 0xff }; return vt_auto_create_analog_input_ctls(codec, cfg, 0x16, pin_idxs, ARRAY_SIZE(pin_idxs)); }
you should notice that pin_idxs[] is just the connection list of imux node 0x17
the position of 0xff is the nid of the stereo mixer 0x16
0x1f [Fixed] CD is also input pins
you don't need to add 0x1d since 0x1d is not in cfg->inputs[i].pin
The routine just add stereo mixer first into the input source items
Yes, and that's exactly what did not work for me. Looking into vt_auto_create_analog_input_ctls, I saw that it passes indexes 0, 1, 2, 3 for CD, Rear Mic, Line and Front Mic to both snd_hda_add_imux_item and via_new_analog_input, while in the 1.0.23 for vt1708s vt1708S_auto_create_analog_input_ctls passed the same 0,1,2,3 to snd_hda_add_imux_item, but 1,2,3,4 to via_new_analog_input. When I did the same, everything started working.
So probably to do it in common way, I would suggest to add another parameter "idx_offset" to vt_auto_create_analog_input_ctls. Then for the codecs that require the same indexes for both functions, pass idx_offset 0 and for these like vt1708s, pass idx_offset 1. And then vt_auto_create_analog_input_ctls will pass idx+idx_offset to via_new_analog_input.
Regards,
participants (2)
-
Mark Goldstein -
Raymond Yau