On 05/07/07, Daniel J Blueman daniel.blueman@gmail.com 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