Problem with VIA VT1708S and git versions of alsa-driver.

Problem with VIA VT1708S and git versions of alsa-driver.

[Mark Goldstein]

[-- Attachment #1: Type: text/plain, Size: 3034 bytes --]

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,
-- 
Mark Goldstein

[-- Attachment #2: alsa-info.zip --]
[-- Type: application/zip, Size: 10594 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Raymond Yau]

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
>
> 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,
> --
> 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=bbe959733a719ecffda8ecd7d4b9631a2745e8b4;hp=6650d30dfe1cf9ef6e639bd898d3b2f637f4bf3b

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Mark Goldstein]

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=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,
>> --
>> 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=bbe959733a719ecffda8ecd7d4b9631a2745e8b4;hp=6650d30dfe1cf9ef6e639bd898d3b2f637f4bf3b

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

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Raymond Yau]

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=bbe959733a719ecffda8ecd7d4b9631a2745e8b4;hp=6650d30dfe1cf9ef6e639bd898d3b2f637f4bf3b
>
> 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]

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Mark Goldstein]

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=bbe959733a719ecffda8ecd7d4b9631a2745e8b4;hp=6650d30dfe1cf9ef6e639bd898d3b2f637f4bf3b
>>
>> 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

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Raymond Yau]

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=bbe959733a719ecffda8ecd7d4b9631a2745e8b4;hp=6650d30dfe1cf9ef6e639bd898d3b2f637f4bf3b
> >>
> >> 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

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Mark Goldstein]

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=bbe959733a719ecffda8ecd7d4b9631a2745e8b4;hp=6650d30dfe1cf9ef6e639bd898d3b2f637f4bf3b
>> >>
>> >> 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,
-- 
Mark Goldstein

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Raymond Yau]

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=bbe959733a719ecffda8ecd7d4b9631a2745e8b4;hp=6650d30dfe1cf9ef6e639bd898d3b2f637f4bf3b
> >> >>
> >> >> 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=0c038a0767e71dcda4477479b9085853e6b4cd8b




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/alsa/HD-Audio.txt

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=0713efebfa1a1878feeeb17cbadc3d2d2c9e9ed2

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

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Mark Goldstein]

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=0c038a0767e71dcda4477479b9085853e6b4cd8b
>

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/alsa/HD-Audio.txt
>
> 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=0713efebfa1a1878feeeb17cbadc3d2d2c9e9ed2
>
> 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,
-- 
Mark Goldstein

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Raymond Yau]

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),

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Mark Goldstein]

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,
-- 
Mark Goldstein

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Raymond Yau]

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.
>
> 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.
>
>
Do you mean that regiession is caused by this patch ?

http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=f3268512c3a5dea587cfe875b8bca98d9e164cd9;hp=73413b120d5d6eb6c98451bbc19acf43e0e300ae


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

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Mark Goldstein]

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.
>>
>> 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.
>>
>>
> Do you mean that regiession is caused by this patch ?
>
> http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=f3268512c3a5dea587cfe875b8bca98d9e164cd9;hp=73413b120d5d6eb6c98451bbc19acf43e0e300ae

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,
-- 
Mark Goldstein

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Raymond Yau]

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.
> >>
> >> 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.
> >>
> >>
> > Do you mean that regiession is caused by this patch ?
> >
> >
> http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=f3268512c3a5dea587cfe875b8bca98d9e164cd9;hp=73413b120d5d6eb6c98451bbc19acf43e0e300ae
>
> 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

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Mark Goldstein]

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.
>> >>
>> >> 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.
>> >>
>> >>
>> > Do you mean that regiession is caused by this patch ?
>> >
>> >
>> http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=f3268512c3a5dea587cfe875b8bca98d9e164cd9;hp=73413b120d5d6eb6c98451bbc19acf43e0e300ae
>>
>> 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.

-- 
Mark Goldstein

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Mark Goldstein]

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.


-- 
Mark Goldstein

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Mark Goldstein]

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) ?




-- 
Mark Goldstein

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Mark Goldstein]

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.

-- 
Mark Goldstein

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Raymond Yau]

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:
> 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.
>
>
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);

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Mark Goldstein]

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:
>> 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.
>>
>>
> 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.



-- 
Mark Goldstein

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Raymond Yau]

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:
> >> 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.
> >>
> >>
> > 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

Re: Problem with VIA VT1708S and git versions of alsa-driver.

[Mark Goldstein]

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:
>> >> 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.
>> >>
>> >>
>> > 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,
-- 
Mark Goldstein