2010/10/10 Mark Goldstein goldstein.mark@gmail.com
Hi,
On Wed, Sep 29, 2010 at 4:33 PM, Raymond Yau superquad.vortex2@gmail.com wrote:
2010/9/29 Mark Goldstein goldstein.mark@gmail.com
Hi,
On Wed, Sep 29, 2010 at 5:06 AM, Raymond Yau superquad.vortex2@gmail.com wrote:
2010/9/28 Mark Goldstein goldstein.mark@gmail.com
Hi,
In theory, a motherboard with 6 audio jacks at back panel does not
need
retasking pink and blue jacks as output pins , it seem to me that
the
"smart5.1" switch is redundant for your motherboard.
it seem this patch may has side effect on those via codec since
they
need
to
differentate the front mic and mic at rear panel for retasking
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=bbe959733a719e...
Looks like a possibility.
What bothers me is the fact that with git version the card is not detected properly (on oS 11.1). I missed this detail in my report
just
because I did not try alsaconf after the problem first occurred. That is, alsaconf does not show it in the list of cards. So I guess that the sound driver uses some defaults (it does indicate the this is hda-intel) that just does not match the actual codec. While when I use stable 1.0.23 version card is detected by alsaconf and works correctly.
From the other side, the problem on oS 11.3 looks very different. I did not update driver there, just installed additional kernel that also has alsa 1.0.23.
How it could lead to "Capture1" switch "reversing"? And now when I found it out and set it to "mute", Mic works correctly with recording SW and produces distorted audio in Skype in exactly the same configuration where it worked perfectly a couple of weeks ago.
Regards,
Mark Goldstein
How did you perform the recording since there are two capturing
subdevices ?
When I played with alsamixer before, I saw that only Capture1 works for me. This time I set both Capture1 and Capture2 levels to some high value and saw that Capture2 does not change anything. From the other side, using hda_analyzer I noticed that that MSB of the volume actually means "mute", that is when I see something like 9f there is no sound recored, while 1f produces sound. And then I saw that this bit reflects the "Mute" checkbox state.
Are you sure that Skype/pulseaudo open the same subdevice ?
I think so. First, It worked before. I have no pulseaudio. Skype just uses hw:0 device. It does some recording, but the audio is very distorted (low volume, no high frequencies, kind of clipped). I disabled the Skype option to adjust mixer volumes and play with it myself.
"Capture1" switch is associated with Node 0x14 [Audio Input]
Refer to the graph in hda_analyzer , when you place the mouse cursor
inside
the "out" box of the Node 0x1e (Front Mic Pin) , there are three red
lines
indicate the possible connections to 0x14, 0x16 and 0x17
Unlike the other HDA codec , your vt1708s has only one "Input Souce"
control
and two ADC
For the other HDA codec, the number of "Input Source" controls is
usually
equal to the number of ADC, this mean that some input sources (e.g.
mic
)
can only be connected to one ADC .
As you can see in the graph, node 0x14 can be connected to 0x1e only
All the connected audio path are displayed as blue line and it is
strange
there are no blue line connected to both the node 0x13 and 0x14
[Audio
Input]
I will not be able to check it for about a week. When I'll have access to my PC again, I'll re-check and let you know what I see. Thanks a lot. -- Mark Goldstein
if you can run hda-emu on another PC , you can compare the read/write of
HDA
codec during driver initialization , capturing , set the contents of the given control element in working and non-working version of alsa-driver
To emulate the capturing using subdevice 1 in hda-emu , you need to use
the
undocumented parameter "c:1" instead of c
as you can see the output of hda-emu , recording through hw:0,0,0 use
Node
0x13 and hw:0,0,1 use Node 0x14
Attach PCM dev 0, name VT1708S Analog, type audio, play #2, capture #2 send: NID=0x12, VERB=0xf00(get_parameters), PARM=0xa(PCM) receive: 0xe05e0 send: NID=0x12, VERB=0xf00(get_parameters), PARM=0xb(stream) receive: 0x1 Attach PCM dev 1, name VT1708S Digital, type SPDIF, play #1, capture #0
PCM 0 c 44100 2 16
Open PCM VT1708S Analog for capt send: NID=0x16, VERB=0xf02(get_connect_list), PARM=0x0 receive: 0x1b1a1f10 send: NID=0x1, VERB=0xf73(unknown), PARM=0xe1 invalid command: NID=0x1, verb=0xf73, parm=0xe1 Available PCM parameters: channels: 2/2 formats: S16_LE S32_LE rates: 44100 48000 96000 192000 Prepare PCM, rate=44100, channels=2, format=16 bits PCM format_val = 0x4011 hda_codec_setup_stream: NID=0x13, stream=0x1, channel=0, format=0x4011 send: NID=0x13, VERB=0xf06(get_channel_streamid), PARM=0x0 receive: 0x0 send: NID=0x13, VERB=0x706(set_channel_streamid), PARM=0x10 send: NID=0x13, VERB=0xa00(get_stream_format), PARM=0x0 receive: 0x0 send: NID=0x13, VERB=0x240(set_stream_format), PARM=0x11 PCM Clean up hda_codec_cleanup_stream: NID=0x13 Close PCM send: NID=0x16, VERB=0xf02(get_connect_list), PARM=0x0 receive: 0x1b1a1f10 send: NID=0x1, VERB=0xf73(unknown), PARM=0xe1 invalid command: NID=0x1, verb=0xf73, parm=0xe1
PCM 0 c:1 44100 2 16
Open PCM VT1708S Analog for capt send: NID=0x16, VERB=0xf02(get_connect_list), PARM=0x0 receive: 0x1b1a1f10 send: NID=0x1, VERB=0xf73(unknown), PARM=0xe1 invalid command: NID=0x1, verb=0xf73, parm=0xe1 Available PCM parameters: channels: 2/2 formats: S16_LE S32_LE rates: 44100 48000 96000 192000 Prepare PCM, rate=44100, channels=2, format=16 bits PCM format_val = 0x4011 hda_codec_setup_stream: NID=0x14, stream=0x1, channel=0, format=0x4011 send: NID=0x14, VERB=0xf06(get_channel_streamid), PARM=0x0 receive: 0x0 send: NID=0x14, VERB=0x706(set_channel_streamid), PARM=0x10 send: NID=0x14, VERB=0xa00(get_stream_format), PARM=0x0 receive: 0x0 send: NID=0x14, VERB=0x240(set_stream_format), PARM=0x11 PCM Clean up hda_codec_cleanup_stream: NID=0x14 Close PCM send: NID=0x16, VERB=0xf02(get_connect_list), PARM=0x0 receive: 0x1b1a1f10 send: NID=0x1, VERB=0xf73(unknown), PARM=0xe1 invalid command: NID=0x1, verb=0xf73, parm=0xe1
Raymond, I probably misled you by mentioning Capture1 control. I actually meant 1st Capture control, associated with node 0x13. It is called just "Capture" in mixer. Apologies for mistake. I could see that node 0x13 is connected to node 0x17 (AUD_SEL - Input source). And node 0x1e is one of the possible inputs to 0x17. Playing with Capture2 (Node 0x14) does not change a thing.
it is strange to find "Independent HP" on Line In at Ext Rear , seem something wrong in creating "Independent HP" control
Node 0x1b [Pin Complex] wcaps 0x400581: Stereo Control: name="Independent HP", index=0, device=0 Pincap 0x00002334: IN OUT Detect Vref caps: HIZ 50 100 Pin Default 0x0181303e: [Jack] Line In at Ext Rear Conn = 1/8, Color = Blue DefAssociation = 0x3, Sequence = 0xe Pin-ctls: 0x21: IN VREF_50 Unsolicited: tag=04, enabled=1 Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 1 0x18
Now, I did another additional experiment. I installed latest git version of alsa driver from openSUSE 11.3 multimedia repository and got the same issue I had with 11.1 before: Line In control did not work while Front Mic control actually controls Line In. So at least this is consistent :-(
Do you mean you have already tested this patch ?
http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=0c038a0767e71dcda4...
Node 0x16 [Audio Mixer] wcaps 0x20050b: Stereo Amp-In Control: name="Master Front Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Master Front Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Mic Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=1, ofs=0 Control: name="Mic Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=1, ofs=0 Control: name="Line Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=2, ofs=0 Control: name="Line Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=2, ofs=0 Control: name="Front Mic Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=3, ofs=0 Control: name="Front Mic Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=3, ofs=0 Control: name="CD Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="CD Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x16 0x16] [0x19 0x19] [0x10 0x10] [0x1c 0x1c] [0x00 0x00] [0x97 0x97] [0x97 0x97] Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 7 0x10 0x1f 0x1a 0x1b 0x1e 0x1d 0x25
Node 0x17 [Audio Selector] wcaps 0x300501: Stereo Control: name="Input Source", index=0, device=0 Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 6 0x1f 0x1a 0x1b 0x1e* 0x1d 0x16
Simple mixer control 'Input Source',0 Capabilities: cenum Items: 'Stereo Mixer' 'Mic' 'Line' 'Front Mic' 'CD' Item0: 'Front Mic'
What is hda-emu you mentioned? I tried searching alsa site and got nothing.
Regards,
Mark Goldstein
http://git.alsa-project.org/?p=alsa-kernel.git;a=blob;f=Documentation/sound/...
hda-emu is a tool which just dumps the codec register changes and the ALSA-driver internal changes at probing and operating the HD-audio driver
You can easily know any difference in codec register changes in the working version/non working version
e.g. the codec read/write when you change "input source" from mic to front mic or line in
The driver deactivate "Headphone Playback Volume" and "Headphone Playback Mute" control if "Independent HP" mode is OFF.
http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=0713efebfa1a1878fe...
control.13 { iface MIXER name 'Headphone Playback Volume' value.0 33 value.1 33 comment { access 'read write inactive' type INTEGER count 2 range '0 - 42' dbmin -6300 dbmax 0 dbvalue.0 -1350 dbvalue.1 -1350 } } control.14 { iface MIXER name 'Headphone Playback Switch' value.0 true value.1 true comment { access 'read write inactive' type BOOLEAN count 2 } }
Does alsamixer or amixer allow you to change the value of headphone volume/switch when they are inactive ?
why the driver does not deactivate "Side Playback Volume" when independent phone is ON since via_independent_put() increase/decrease spec->multiout.num_dacs ?
Node 0x1d [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Headphone Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Independent HP", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0000233c: IN OUT HP Detect Vref caps: HIZ 50 100 Pin Default 0x0221401f: [Jack] HP Out at Ext Front Conn = 1/8, Color = Green DefAssociation = 0x1, Sequence = 0xf Pin-ctls: 0xc0: OUT HP VREF_HIZ Unsolicited: tag=05, enabled=1 Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 2 0x16* 0x25
Node 0x25 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Side Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Headphone Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x2a, nsteps=0x2a, stepsize=0x05, mute=0 Amp-Out vals: [0x21 0x21] Converter: stream=0, channel=0 PCM: rates [0x5e0]: 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0
Node 0x27 [Audio Selector] wcaps 0x30050d: Stereo Amp-Out Control: name="Side Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 1 0x25