> > 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.
With the new patch, anything above Capture Boost at zero resulted in
the microphone signal saturating and being clipped; the levels I were
seeing without the Capture Boost patch applied seemed optimal.
Thanks again,
Daniel
--
Daniel J Blueman
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
