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

Raymond Yau superquad.vortex2 at gmail.com
Sun Oct 10 15:19:01 CEST 2010


2010/10/10 Mark Goldstein <goldstein.mark at gmail.com>

> Hi,
>
> On Wed, Sep 29, 2010 at 4:33 PM, Raymond Yau
> <superquad.vortex2 at gmail.com> wrote:
> > 2010/9/29 Mark Goldstein <goldstein.mark at gmail.com>
> >
> >> Hi,
> >>
> >> On Wed, Sep 29, 2010 at 5:06 AM, Raymond Yau
> >> <superquad.vortex2 at gmail.com> wrote:
> >> > 2010/9/28 Mark Goldstein <goldstein.mark at 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


More information about the Alsa-devel mailing list