At Fri, 6 Jul 2007 00:19:29 +0100,
Daniel J Blueman wrote:
>
> On 05/07/07, Daniel J Blueman <daniel.blueman@xxxxxxxxx> wrote:
> > > > > > > > > > > > With both 2.6.20 and 2.6.22 kernels on Ubuntu 7.04 on my Sony Vaio
> > > > > > > > > > > > SZ240, I'm unable to get my mic connector working at any cost.
> > > > > > > > > > >
> > > > > > > > > > > First, show the contents of /proc/asound/card0/codec#* files...
> > > > > > [snip]
> > > > > > > > I have discovered the bug preventing me using the external mic socket
> > > > > > > > before: in the mixer, the user has to select the [internal] mic input,
> > > > > > > > then re-select the line-in (actually external mic) input; reading from
> > > > > > > > (eg) /dev/dsp while changing this, the output suddenly is as expected
> > > > > > > > when the line-in is re-selected.
> > > > > > >
> > > > > > > Could you elaborate? What do yo mean "output" here, and what did you
> > > > > > > expect?
> > > > > >
> > > > > > Looking at what is printed from the command 'cat /dev/dsp', what is
> > > > > > shown changes when I de-select 'line-in' and then reselect it. Let me
> > > > > > know if you're still unclear.
> > > > > >
> > > > > > > > Since we've got started, where should I look for the 'before' and
> > > > > > > > 'after' state to compare to see into this?
> > > > > > >
> > > > > > > Yes, comparing the codec dump file would be helpful.
> > > > > >
> > > > > > Changing from the initial mixer state of 'Line-in' being selected to
> > > > > > 'Microphone' does not change anything in the
> > > > > > /proc/asound/card0/codec#{0,1} files. After, changing the input back
> > > > > > to 'Line-in' does show a change [1] (which we'd expect).
> > > > > >
> > > > > > My interpretation of this is that (in the initial state) the STAC
> > > > > > registers are set to record from the internal mic (which doesn't
> > > > > > actually exist; there is a tiny amount of crosstalk) and the mixer
> > > > > > settings ALSA reports show the line-in/external mic selected [2].
> > > > >
> > > > > The problem sounds like a mismatch of initialization verb and the
> > > > > internal mixer state. If it's the case, the patch below should fix,
> > > > > then.
> > > >
> > > > This does indeed squarely address the problem I was having, and is a
> > > > good fix here!
> > > >
> > > > The 'Line in' and 'Mic' inputs are a little confusing still. Do you
> > > > think it's worth having 'Line/Mic in' or just 'External'?
> > > >
> > > > As there is no internal mic on this model the 'Mic' input is the
> > > > opposite of what needs selecting. Is there any way we can address this
> > > > at the same too? Perhaps 'Int mic' or similar would clarify it.
> > >
> > > OK, that makes sense. I'll fix them, too.
> > >
> > > BTW, does the "Capture Boost" volume by the earlier patch have any
> > > influence on the record quality?
> >
> > I didn't apply that patch, but will get back to you on this tonight.
>
> I added the new 'Capture Boost Volume' control to both structures [1]
> and see it in amixer [2], however I'm not able to tweak it in
> alsamixer or gnome-volume-control. The external mic input is already
> pretty crisp (with a good mic) both without and with these changes,
> and at the recording levels I'd expect.
My bad, the patch was wrong. Please try the one below instead.
Takashi
diff -r 1b353155ccc4 pci/hda/patch_sigmatel.c
--- a/pci/hda/patch_sigmatel.c Fri Jul 06 12:27:25 2007 +0200
+++ b/pci/hda/patch_sigmatel.c Fri Jul 06 12:37:45 2007 +0200
@@ -2430,6 +2430,7 @@ static struct snd_kcontrol_new vaio_mixe
.get = stac92xx_mux_enum_get,
.put = stac92xx_mux_enum_put,
},
+ HDA_CODEC_VOLUME("Capture Boost Volume", 0x15, 0, HDA_OUTPUT),
{}
};
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
