Test model

Test model

[Rimas Kudelis]

Hello jwoithe,

I'm now trying out the test model for ALC260. I've already managed to
get sound from the Line In jack and Microphone jack. I've also managed
to get the internal Mic working. However, I haven't heard any sound from
either integrated speakers nor the headphones jack. Even after switching
a lot of controls in mixer. I remembered you mentioning some nasty pin
that "should be better not be touched", and wanted to ask you if this
pin is available for control, if I choose the text model?

Good night...
Rimas



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Test model

[Jonathan Woithe]

Hi Rimas

> I'm now trying out the test model for ALC260. I've already managed to
> get sound from the Line In jack and Microphone jack. I've also managed
> to get the internal Mic working.

Excellent.  Out of interest, which control appears to be connected to
the internal mic?

> However, I haven't heard any sound from either integrated speakers nor the
> headphones jack. Even after switching a lot of controls in mixer.

Interesting.  Perhaps the easiest way forward in that case is to switch
every jack control to "line out" or "headphone out", unmute everything and
turn up every control to maximum. Then see if you get sound out in any form
from the internal speaker.  If we get sound at least we know it's possible
and you can then work backwards to find the controls which affect it.  If we
don't then there's some head-scratching to do.

> I remembered you mentioning some nasty pin that "should be better not be
> touched", and wanted to ask you if this pin is available for control, if I
> choose the text model?

It is available, yes.  It's pin widget 0x15, referred to as "LINE2" in
the mixer controls.  Including it in the test model didn't appear to cause
any trouble on my laptop during development so I left it in.  I'm yet to
revisit the reasons as to why I had trouble with this NID during the
initial S7020 development - currently I suspect a typo which I failed to
notice at the time.

Note also that the problem I had was that sending an initverb to this pin
caused *all* sound to stop.  Since you get sound out of other jacks when
using the test model I don't think your lack of sound from the headphone
jack is due to this problem.

Regards
  jonathan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Test model

[Rimas Kudelis]

Good morning,

On Thu, Feb 16, 2006 at 10:18:04AM +1030, Jonathan Woithe wrote:
> I'm now trying out the test model for ALC260. I've already managed to
> > get sound from the Line In jack and Microphone jack. I've also managed
> > to get the internal Mic working.
> 
> Excellent.  Out of interest, which control appears to be connected to
> the internal mic?

Well it's not too surprising. The internal microphone is connected to
the "MIC1" control. And the external too. Whenever I plug something into
the external microphone jack, the internal one gets automatically muted.

The Line In jack is connected to LINE1 control.

Master volume seems to be controlled by LOUT1 control. By muting this, i
get absolute silence.

And the last thing i've found so far is that PCM channel is the one that
Totem media player uses to play its sound. Also, it's used by Sound
Juicer to play the CD. I wonder though - why isn't a Mute control
available for it?


> > However, I haven't heard any sound from either integrated speakers nor the
> > headphones jack. Even after switching a lot of controls in mixer.
> 
> Interesting.  Perhaps the easiest way forward in that case is to switch
> every jack control to "line out" or "headphone out", unmute everything and
> turn up every control to maximum. Then see if you get sound out in any form
> from the internal speaker.  If we get sound at least we know it's possible
> and you can then work backwards to find the controls which affect it.  If we
> don't then there's some head-scratching to do.

That's what I tried yesterday. Switched all controls to Line Out. That's
how I found out what Mic and Line In jacks are connected to. Now these
two are set to Mic and Line In types, respectively. And everything else
is Line Out. Nothing... Same happens when everything else is set to
Headphones.

Btw, when I redirect the output to Line In, and make everything else
(HP-OUT, LINE-OUT, LINE2 and MIC2) be "Headphone" pins, I get a lot of noise 
from the speakers connected to the Line In jack. These seem to catch
some interference even from the video card (just noticed). That
electronic noise differs depending on what I see in the screen atm. Weird...

> It is available, yes.  It's pin widget 0x15, referred to as "LINE2" in
> the mixer controls.  Including it in the test model didn't appear to cause
> any trouble on my laptop during development so I left it in.  I'm yet to
> revisit the reasons as to why I had trouble with this NID during the
> initial S7020 development - currently I suspect a typo which I failed to
> notice at the time.
> 
> Note also that the problem I had was that sending an initverb to this pin
> caused *all* sound to stop.  Since you get sound out of other jacks when
> using the test model I don't think your lack of sound from the headphone
> jack is due to this problem.

Maybe. I just though that maybe it doesn't really mute all the sound,
but just some pins?

I'm almost out of any ideas. :/ Could it be that the notebook uses
digital i/o for its internal speakers/heaphone jack or something like
this?

Rimas



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Test model

[Rimas Kudelis]

On Thu, Feb 16, 2006 at 11:29:27AM +0200, Rimas Kudelis wrote:
> I'm almost out of any ideas. :/

Another wild guess: is it intended so, that I can feel absolutely no
difference when changing the LINE1 mode from Line Out to Headphones and
vice-versa? Would it be sane to try to apply Bias voltage to output
jacks too, not only the Mic jacks?.

Rimas



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Test model

[Jonathan Woithe]

> Another wild guess: is it intended so, that I can feel absolutely no
> difference when changing the LINE1 mode from Line Out to Headphones and
> vice-versa?

This is the pin you *can* get sound from, right?

Whether you notice a difference between the modes depends on the nature of
what you plug into the jack.  A cable going to a line-level input on some
other equipment is unlikely to cause much change beyond a *slight* increase
in the hiss level.  With high-impedence headphones you are also unlikely to
notice much difference.  The biggest difference comes if driving low
impedence headphones - 32 ohms or there abouts.  Most earbuds for example
are low impedence.

> Would it be sane to try to apply Bias voltage to output
> jacks too, not only the Mic jacks?.

The bias voltage is only needed for certain types of microphones which use
it to power small amplifiers/signal conditioners.  Applying a bias to
an output doesn't really make sense.  In the case of a jack it will simply
cause a DC offset which will either be ignored by connected gear or (in the
case of DC-coupled amplifiers) cause a lot of problems.  For the internal
speaker it makes no sense at all because any power the speaker amplifier
needs can be more efficiently taken from other sources within the computer.

So the short answer is that it should not be necessary to apply bias to
an output.  A good thought though.

Regards
  jonathan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Re: Test model

[Paulo Matias]

Hi,

Sorry for the delay again.

By the description of Rimas, I think we have the same Acer notebook,
or, at least, we've the same connections (mine is a TravelMate
4062WLMi, but I seriously suspect all TravelMate 4060 series has the
same hardware and connections, only varying in LCD size, RAM and HD
size, and presence of internal BlueTooth adapter). I had the same
problems he had and got sound from the same pins he got.

Jonathan, by your last email, I was thinking in a possibility. You
asked me about a external volume control. There are two keys at the
keyboard for increasing and decreasing the volume. They are Fn+Up
Arrow and Fn+Down Arrow. I was thinking in the possibility it
controls, via software, a volume control plugged in the out of the
codec. Is it possible?

Someone who has windows in this laptop could help, using this keyboard
controls and checking if it controls the mixer volume, or something
else. Rimas, do you have windows in your laptop? Can you please make
this check?

I've also taked a look at the windows drivers cd Acer provided. The
Realtek drivers installer has a directory called WDM that contains
.inf files that seems to contain the internal routings for varied
models. I haven't analysed it so much yet to confirm, but I can
provide the files on request.

Another thing I've perceived is that the drivers cd contains BlueTooth
drivers, and my model hasn't BlueTooth. This is an indication that the
same driver cd would be distributed for all TravelMate 4060 series, so
it would have the same hardware and same connections, and an ALSA
model for this notebook would work in all 4060 series.

Regards,
Paulo Matias


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642

Re: Re: Test model

[Rimas Kudelis]

Hi,


> By the description of Rimas, I think we have the same Acer notebook,
> or, at least, we've the same connections (mine is a TravelMate
> 4062WLMi, but I seriously suspect all TravelMate 4060 series has the
> same hardware and connections, only varying in LCD size, RAM and HD
> size, and presence of internal BlueTooth adapter). I had the same
> problems he had and got sound from the same pins he got.

Mine is TM4061 NLMi. But i think (i hope) you're right. I even think 
Acer Aspire (or whatever is the other series name, that is written on 
the cd/manual - i don't clearly remember) is similar enough to the 
TravelMate.


> Jonathan, by your last email, I was thinking in a possibility. You
> asked me about a external volume control. There are two keys at the
> keyboard for increasing and decreasing the volume. They are Fn+Up
> Arrow and Fn+Down Arrow. I was thinking in the possibility it
> controls, via software, a volume control plugged in the out of the
> codec. Is it possible?

I don't really get what you mean, but I guess you're wrong. I used 
them. They seem to be software keys, and Gnome treats them as such. As 
opposed to the brightness control keys (hardware), these are detected 
by `showkey`.

> Someone who has windows in this laptop could help, using this keyboard
> controls and checking if it controls the mixer volume, or something
> else. Rimas, do you have windows in your laptop? Can you please make
> this check?

I don't. But of course these keys would control the volume. That's a 
software, not hardware feature, though.


> I've also taked a look at the windows drivers cd Acer provided. The
> Realtek drivers installer has a directory called WDM that contains
> .inf files that seems to contain the internal routings for varied
> models. I haven't analysed it so much yet to confirm, but I can
> provide the files on request.

Do they? I doubt that. but if they do, that would make our enigma much 
easier to solve.

> Another thing I've perceived is that the drivers cd contains BlueTooth
> drivers, and my model hasn't BlueTooth. This is an indication that the
> same driver cd would be distributed for all TravelMate 4060 series, so
> it would have the same hardware and same connections, and an ALSA
> model for this notebook would work in all 4060 series.

My notebook does have bluetooth. :)

RQ


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Re: Test model

[Jonathan Woithe]

Hi Rimas

> > Jonathan, by your last email, I was thinking in a possibility. You
> > asked me about a external volume control. There are two keys at the
> > keyboard for increasing and decreasing the volume. They are Fn+Up
> > Arrow and Fn+Down Arrow. I was thinking in the possibility it
> > controls, via software, a volume control plugged in the out of the
> > codec. Is it possible?
> 
> I don't really get what you mean, but I guess you're wrong. I used 
> them. They seem to be software keys, and Gnome treats them as such. As 
> opposed to the brightness control keys (hardware), these are detected 
> by `showkey`.

Right - that confirms my suspicions as described in my previous post.

Regards
  jonathan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Re: Test model

[Jonathan Woithe]

Hi Paulo

> By the description of Rimas, I think we have the same Acer notebook,
> or, at least, we've the same connections (mine is a TravelMate
> 4062WLMi, but I seriously suspect all TravelMate 4060 series has the
> same hardware and connections, only varying in LCD size, RAM and HD
> size, and presence of internal BlueTooth adapter).

Sounds likely.

> I had the same problems he had and got sound from the same pins he got.

Excellent news - that at least rules out obscure hardware faults in 
Rimas' machine.

> Jonathan, by your last email, I was thinking in a possibility. You
> asked me about a external volume control. There are two keys at the
> keyboard for increasing and decreasing the volume. They are Fn+Up
> Arrow and Fn+Down Arrow. I was thinking in the possibility it
> controls, via software, a volume control plugged in the out of the
> codec. Is it possible?

My Fujitsu laptop has similar buttons and I must confess I've never tried
them.  I know the similarly labeled brightness buttons are trapped and
handled by the hardware since they work under Linux without me having to
tell the system about them.  I suspect however that the volume controls are
treated as just another key which can be used by software in whatever way it
chooses. Using showkey (or similar programs) would confirm this.  The reason
I say this is because in the case of the mixer, sofware must be informed of
any changed done behind its back by hardware whereas this isn't essential
for brightness.

> Someone who has windows in this laptop could help, using this keyboard
> controls and checking if it controls the mixer volume, or something
> else.

This test would only show what happens when windoze is booted.  It won't 
tell us whether it's doing it by directly talking to the hardware or whether
the windoze driver traps those keys and does the volume adjustments itself.

> I've also taked a look at the windows drivers cd Acer provided. The
> Realtek drivers installer has a directory called WDM that contains
> .inf files that seems to contain the internal routings for varied
> models. I haven't analysed it so much yet to confirm, but I can
> provide the files on request.

That's interesting.  I'd be interested in seeing these files.  Perhaps
email it/them privately.

Regards
  jonathan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Test model

[Jonathan Woithe]

Hi

> > Excellent.  Out of interest, which control appears to be connected to
> > the internal mic?
> 
> Well it's not too surprising. The internal microphone is connected to
> the "MIC1" control. And the external too. Whenever I plug something into
> the external microphone jack, the internal one gets automatically muted.

Right - it's as I suspected then: the switching between internal and external
microphone is done by hardware: there is no software control over this.

> The Line In jack is connected to LINE1 control.
> Master volume seems to be controlled by LOUT1 control. By muting this, i
> get absolute silence.

Good, that all makes sense.

> And the last thing i've found so far is that PCM channel is the one that
> Totem media player uses to play its sound. Also, it's used by Sound
> Juicer to play the CD. I wonder though - why isn't a Mute control
> available for it?

The "PCM" control is (AFAIK) a software control created when something opens
the ALSA driver for audio I/O.  I've never fully understood why this control
appears and I'm not entirely sure what it controls.  At some point I thought
it could be software-only (ie: having no connection to actual hardware) but
it might instead control the gain cell on the output of the DAC.  If this is
the case though I don't know why it only appears when something has used
ALSA for output - why not have it present in alsamixer at all times?  In any
case there's obviously something special about this particular control which
explains why there is no mute.

> > > However, I haven't heard any sound from either integrated speakers nor the
> > > headphones jack. Even after switching a lot of controls in mixer.
> > 
> > Interesting.  Perhaps the easiest way forward in that case is to switch
> > every jack control to "line out" or "headphone out", unmute everything and
> > turn up every control to maximum. Then see if you get sound out in any form
> > from the internal speaker.  If we get sound at least we know it's possible
> > and you can then work backwards to find the controls which affect it.  If we
> > don't then there's some head-scratching to do.
> 
> That's what I tried yesterday. Switched all controls to Line Out. That's
> how I found out what Mic and Line In jacks are connected to. Now these
> two are set to Mic and Line In types, respectively. And everything else
> is Line Out. Nothing... Same happens when everything else is set to
> Headphones.

Very interesting.  The only difference between the "line out" and "headphone"
setting is that the latter enables an onboard amplifier which allows it
to drive headphones to a louder volume.  On the headphones I've tried 
you still get adequate output when the pin is "lineout" - it's just slightly
louder when "headphone" mode is selected.

> Btw, when I redirect the output to Line In, and make everything else
> (HP-OUT, LINE-OUT, LINE2 and MIC2) be "Headphone" pins, I get a lot of
> noise from the speakers connected to the Line In jack. These seem to catch
> some interference even from the video card (just noticed). That electronic
> noise differs depending on what I see in the screen atm. Weird...

Which output - the headphone jack?  What kind of noise - squeals or hiss?

> > It is available, yes.  It's pin widget 0x15, referred to as "LINE2" in
> > the mixer controls.  Including it in the test model didn't appear to cause
> > any trouble on my laptop during development so I left it in.  I'm yet to
> > revisit the reasons as to why I had trouble with this NID during the
> > initial S7020 development - currently I suspect a typo which I failed to
> > notice at the time.
> > 
> > Note also that the problem I had was that sending an initverb to this pin
> > caused *all* sound to stop.  Since you get sound out of other jacks when
> > using the test model I don't think your lack of sound from the headphone
> > jack is due to this problem.
> 
> Maybe. I just though that maybe it doesn't really mute all the sound,
> but just some pins?

Not sure at this stage.  Feel free to comment out the things which touch
node ID 0x15 and try again (after recompiling/reboot), but based on
experience to date I don't think it will change things.  In the face of no
other suggestions however it might be worth trying.

> I'm almost out of any ideas. :/ Could it be that the notebook uses
> digital i/o for its internal speakers/heaphone jack or something like
> this?

That would be extremely strange - as a system designer, why require the use
of an external DAC when you have a perfectly servieable one already in the
laptop?

A couple of other random thoughts:

  1) You're not using a docking station, are you?

  2) Does the laptop have an external volume control?  If so, is it turned
     up to maximum?

Regards
  jonathan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Test model

[Rimas Kudelis]

Hi,


>> The internal microphone is connected to the "MIC1" control. And the external too.
>> The Line In jack is connected to LINE1 control.
>> Master volume seems to be controlled by LOUT1 control. By muting this, i
>> get absolute silence.

<...>

> Very interesting.  The only difference between the "line out" and "headphone"
> setting is that the latter enables an onboard amplifier which allows it
> to drive headphones to a louder volume.  On the headphones I've tried 
> you still get adequate output when the pin is "lineout" - it's just slightly
> louder when "headphone" mode is selected.

OK, then I hope it doesn't apply here, as I'm testing things with an 
external amplifier connected to big speakers.


>> Btw, when I redirect the output to Line In, and make everything else
>> (HP-OUT, LINE-OUT, LINE2 and MIC2) be "Headphone" pins, I get a lot of
>> noise from the speakers connected to the Line In jack. These seem to catch
>> some interference even from the video card (just noticed). That electronic
>> noise differs depending on what I see in the screen atm. Weird...
> 
> Which output - the headphone jack?  What kind of noise - squeals or hiss?

Hard to tell (English is not my native), but I think it's more like 
hiss. Actually, it sounds a bit similar to a TV with bad reception, 
except that in my case the noise is quiet enough.


> Not sure at this stage.  Feel free to comment out the things which touch
> node ID 0x15 and try again (after recompiling/reboot), but based on
> experience to date I don't think it will change things.  In the face of no
> other suggestions however it might be worth trying.

I don't actually understand a single line in the driver code. :)) But 
I'll try to find possible gotchas in it.


>> I'm almost out of any ideas. :/ Could it be that the notebook uses
>> digital i/o for its internal speakers/heaphone jack or something like
>> this?
> 
> That would be extremely strange - as a system designer, why require the use
> of an external DAC when you have a perfectly servieable one already in the
> laptop?
> 
> A couple of other random thoughts:
> 
>   1) You're not using a docking station, are you?

Of course I'm not. :) This laptop doesn't even have a docking station 
interface port.

>   2) Does the laptop have an external volume control?  If so, is it turned
>      up to maximum?

No, it doesn't. Just the keyboard controls that Paolo has mentioned.

BTW, could I catch you on IRC or MSN or some other real-time media? I 
hope that could make this discussion progress a little bit faster.

best regards,

Rimas



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Re: Test model

[Paulo Matias]

(Copy only of the body of the email I sent to Jonathan with the files)

Hi Jonathan,

These are the files of which I've said. I've diffed the .inf files at
the WDM directory and their differences are not in the part that
describes the codec pins, so I think I was wrong.

But, hey, I've looked better at the driver files and found an
AzMixerSel.ini. This file has clsids associated with mixer controls,
like this:

[008F1025&Dev0_{0A8C1AA2-42B0-11D2-95D2-00C04FB925D3}]
Name=Master Volume
DeviceName=Realtek HD Audio output
Volume=32845
Mute=0
SelectMode=0

I've installed the driver in my Wine and then looked for these clsids
in the drive_c directory of Wine, and found only one binary file that
references all these clsids: windows/system32/drivers/RtkHDAud.Sys.

I suspect all the manufacturers use the same driver provided by
Realtek and then change the AzMixerSel.ini for adjusting the internal
routings.

Now, how can we know what clsid refers to what?

1. by comparision with models we already know the routings, like Fujitsu
2. by contacting Realtek
3. maybe by reverse engineering?

Regards,
Paulo Matias


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642

Re: Re: Test model

[Rimas Kudelis]

Paulo Matias wrote:
> (Copy only of the body of the email I sent to Jonathan with the files)

Could you send a copy for me now? :) Well, OTOH, I can look them up on 
the Acer's website.

> But, hey, I've looked better at the driver files and found an
> AzMixerSel.ini. This file has clsids associated with mixer controls,
> like this:
> 
> [008F1025&Dev0_{0A8C1AA2-42B0-11D2-95D2-00C04FB925D3}]
> Name=Master Volume
> DeviceName=Realtek HD Audio output
> Volume=32845
> Mute=0
> SelectMode=0
> 
> I've installed the driver in my Wine and then looked for these clsids
> in the drive_c directory of Wine, and found only one binary file that
> references all these clsids: windows/system32/drivers/RtkHDAud.Sys.
> 
> I suspect all the manufacturers use the same driver provided by
> Realtek and then change the AzMixerSel.ini for adjusting the internal
> routings.

IMO, that would make a lot of sense, indeed.

> Now, how can we know what clsid refers to what?
> 
> 1. by comparision with models we already know the routings, like Fujitsu
> 2. by contacting Realtek
> 3. maybe by reverse engineering?

1 and 2 should be easiest (if effective), probably. It should be 
relatively easy to find the manufacturer's drivers for other ALC260 
laptops on the Internet. Then we could at least try to compare Acer's 
ini with Fujitsu's with HP's. Hopefully, that would help us. I'll try 
to dig into this right now. :)

Rimas


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Re: Test model

[Rimas Kudelis]

Hi again,

Rimas Kudelis wrote:
>> [008F1025&Dev0_{0A8C1AA2-42B0-11D2-95D2-00C04FB925D3}]
>> Name=Master Volume
>> DeviceName=Realtek HD Audio output
>> Volume=32845
>> Mute=0
>> SelectMode=0
>>
>> I've installed the driver in my Wine and then looked for these clsids
>> in the drive_c directory of Wine, and found only one binary file that
>> references all these clsids: windows/system32/drivers/RtkHDAud.Sys.
>>
>> I suspect all the manufacturers use the same driver provided by
>> Realtek and then change the AzMixerSel.ini for adjusting the internal
>> routings.
> 
> IMO, that would make a lot of sense, indeed.
> 
>> Now, how can we know what clsid refers to what?
>>
>> 1. by comparision with models we already know the routings, like Fujitsu
>> 2. by contacting Realtek
>> 3. maybe by reverse engineering?
> 
> 1 and 2 should be easiest (if effective), probably. It should be 
> relatively easy to find the manufacturer's drivers for other ALC260 
> laptops on the Internet. Then we could at least try to compare Acer's 
> ini with Fujitsu's with HP's. Hopefully, that would help us. I'll try to 
> dig into this right now. :)

I've compared the ini files for my Acer and a Fujitsu (Downloaded both 
drivers from the internet). As expected - there are some matching 
GUIDs, but also, quite a few are different (for example, the one 
labeled "CD volume"). It's a bit pity I couldn't find similarly 
distributed drivers for HP or Sony Vaio models (Along with Fujitsu, 
these are the only ones that are detected by the driver). Both HP and 
Sony distribute their drivers in exe format, and Sony requires you to 
enter your laptop serial number before giving you a link to the 
download. That sucks a little, as I'm not sure all that would install 
under Wine, or that it would have that ini file...

It would be great to get more ini files though. Or more information on 
them...

Rimas


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Re: Test model

[Paulo Matias]

Hi again,

> download. That sucks a little, as I'm not sure all that would install
> under Wine, or that it would have that ini file...

Rimas, I've installed successfuly the Acer driver in Wine 0.9.6,
without any tricks.
I will try to get these to analyse too.

Regards,
Paulo Matias


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642

Re: Re: Test model

[Rimas Kudelis]

hello,

>> download. That sucks a little, as I'm not sure all that would install
>> under Wine, or that it would have that ini file...
> 
> Rimas, I've installed successfuly the Acer driver in Wine 0.9.6,
> without any tricks.

:D you didn't need to. Acer driver has a "Config" directory in which 
the ini is located. ;) That's how I got it.

 > I will try to get these to analyse too.

Rimas


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Re: Test model

[Jonathan Woithe]

Hi Paulo

> But, hey, I've looked better at the driver files and found an
> AzMixerSel.ini. This file has clsids associated with mixer controls,
> like this:
> 
> [008F1025&Dev0_{0A8C1AA2-42B0-11D2-95D2-00C04FB925D3}]
> :
>
> I've installed the driver in my Wine and then looked for these clsids
> in the drive_c directory of Wine, and found only one binary file that
> references all these clsids: windows/system32/drivers/RtkHDAud.Sys.
> 
> I suspect all the manufacturers use the same driver provided by
> Realtek and then change the AzMixerSel.ini for adjusting the internal
> routings.

That would make sense.

> Now, how can we know what clsid refers to what?

It's probably a little tricky as you've eluded to.  I particular, we want
to know the NIDs of these controls.  We can eliminate a lot of the clsid
parts just by comparison though.

The "Wave" has a clsid of DFF21FE4-F70F-11D0-B917-00A0C9223196.
The "CD player" has clsid DFF220E3-F70F-11D0-B917-00A0C9223196.

>From these two se can see that the only differences between the two occur
in the first 8 characters (presumedly describing the first 4 bytes of
something).  Therefore *if* the clsid itself contains any information about
the NIDs I would expect it to be in this first section.

I then note the following:

  Dev 0 Mic Volume: 0A8C1A8D-42B0-11D2-95D2-00C04FB925D3
  Dev 0 Mic Volume: 185FEDED-9905-11D1-95A9-00C04FB925D3
  Dev 1 Mic Volume: 0A8C1A8D-42B0-11D2-95D2-00C04FB925D3
  Dev 1 Mic Volume: 185FEDED-9905-11D1-95A9-00C04FB925D3

If the clsids were in some way describing the NIDs and other things I cannot
work out why the mic volume would appear twice with two quite different
clsids.  Furthermore, I note the clsid for Dev 0 mic and Dev 1 mic are the
same.  This last point almost guarantees that the clsid itself does not
contain the NID information.  If it *is* used to get information about what
controls to offer I suspect it is used to allow the driver to make an
indirect lookup of the info.

So in summary I don't think this file is going to provide any clues.  It
was a good idea though.

Regards
  jonathan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Re: Test model

[Paulo Matias]

Hi,

> BTW, could I catch you on IRC or MSN or some other real-time media? I
> hope that could make this discussion progress a little bit faster.

Yeah, I know it was not for me, but if you like, you can find me at
irc.freenode.net or irc.openbrasil.org, nick thotypous :)

Regards,
Paulo Matias


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642

Re: Test model

[Jonathan Woithe]

> > Very interesting.  The only difference between the "line out" and "headphone"
> > setting is that the latter enables an onboard amplifier which allows it
> > to drive headphones to a louder volume.  On the headphones I've tried 
> > you still get adequate output when the pin is "lineout" - it's just slightly
> > louder when "headphone" mode is selected.
> 
> OK, then I hope it doesn't apply here, as I'm testing things with an 
> external amplifier connected to big speakers.

If this is how you're testing then I would expect there to be very little
difference in the audio through the speakers when the "lineout" and
"headphone" mode settings are used.

> >> Btw, when I redirect the output to Line In, and make everything else
> >> (HP-OUT, LINE-OUT, LINE2 and MIC2) be "Headphone" pins, I get a lot of
> >> noise from the speakers connected to the Line In jack. These seem to catch
> >> some interference even from the video card (just noticed). That electronic
> >> noise differs depending on what I see in the screen atm. Weird...
> > 
> > Which output - the headphone jack?  What kind of noise - squeals or hiss?
> 
> Hard to tell (English is not my native), but I think it's more like 
> hiss. Actually, it sounds a bit similar to a TV with bad reception, 
> except that in my case the noise is quiet enough.

Ok, that would be "hiss".

> >   2) Does the laptop have an external volume control?  If so, is it turned
> >      up to maximum?
> 
> No, it doesn't. Just the keyboard controls that Paolo has mentioned.

Right.  It was worth checking.

> BTW, could I catch you on IRC or MSN or some other real-time media?

Not at this stage.

Regards
  jonathan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Test model

[Rimas Kudelis]

Hi,

i've been looking at the hda driver on my acer for the past few days. 
I got almost no results, except one note. According to the datasheel, 
NID 0x05 accepts one more item as capture source, and values 0x05 and 
0x06 have different meanings from those for NID 0x04.

However, it looks like fixing this would require a little more 
knowledge than i've got. And my mom is taking her notebook from me 
today, so i won't be able to debug things untill the next weekend.

bye,
Rimas


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Test model

[Jonathan Woithe]

Hi Rimas

> i've been looking at the hda driver on my acer for the past few days. 
> I got almost no results, except one note. According to the datasheel, 
> NID 0x05 accepts one more item as capture source, and values 0x05 and 
> 0x06 have different meanings from those for NID 0x04.

This is true, and it is true that the test model doesn't account for this.
The reason is simple enough: the differences didn't affect the Fujitsu since
LINE-OUT and HP-OUT aren't actually used for anything you'd want to record. 
When I came to do the test model I therefore never gave the differences a
moment's thought.

> However, it looks like fixing this would require a little more 
> knowledge than i've got.

I think it's fairly simple to address this issue.  I'll see if I can do up a
patch sometime today to address this issue.

Note that this has nothing to do with the inability to make the internal
speaker play ball on your laptop - it affects only the ability to record
from certain widgets via the second ADC (0x05) since the existing capture list
is for NID 0x04.

Regards
  jonathan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Test model

[Rimas Kudelis]

Hello,

> Note that this has nothing to do with the inability to make the internal
> speaker play ball on your laptop - it affects only the ability to record
> from certain widgets via the second ADC (0x05) since the existing capture list
> is for NID 0x04.

I know that. BTW one of the actions I tried last weekend was recording 
something from the microphone. And it failed too. selecting one (don't 
remember which, though) of the capture channels for capture resulted 
in continuous noise being recorded, and selecting the other one 
resulted in silence. Also, selecting both resulted in sum of these, 
hence, noise again...

Also, not sure if it's alsamixer's or driver's fault, alsamixer always 
says "Input Source 1" is "1", even though it selects the required source.

Paulo, would you please confirm this too?

Jonathan, I think that maybe the "test" model should have even more 
controls to play with, even those that may seem like should never be 
used? For example, there seem to be no checkboxes or something similar 
to control S/PDIF NIDs, or jack (pin) widgets and so on. Such controls 
might be useful for testing, when nothing else seems to work out, like 
the Acer case at the moment. In order not to clutter the default 
tester's mixer interface, maybe this (at least partially) should go to 
some kind of an "extended test" model, i don't know.

BTW, if I haven't misunderstood the datasheet, I think it says that 
S/PDIF NIDs (0x03 and 0x06, if I remember correctly) can be told to 
output Analog audio, along with the other channels. Could this 
possibly be Acer's case? I'm asking this because these were probably 
the only NIDs that I didn't even try to play with...

Best regards,

Rimas



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Test model

[Jonathan Woithe]

> BTW one of the actions I tried last weekend was recording something from
> the microphone. And it failed too. selecting one (don't remember which,
> though) of the capture channels for capture resulted in continuous noise
> being recorded, and selecting the other one resulted in silence. Also,
> selecting both resulted in sum of these, hence, noise again...

What sort of noise - hiss I assume?  Secondly, what do you mean by
"selecting both"?  Do you mean that both capture sources were pointed at the
same source?  If so you wouldn't have recorded the sum; the two ADCs are on
separate pcms, so you would only have been recording one or the other in
this case.

What kind of microphone were you using?  Did you have a bias setting
configured for the jack the mic was connected to?

> Also, not sure if it's alsamixer's or driver's fault, alsamixer always 
> says "Input Source 1" is "1", even though it selects the required source.

I'm confused by this - "1" isn't an option AFAIK.  "MIC1", "MIC2", "LINE1",
"LINE2" etc are the options.

> Jonathan, I think that maybe the "test" model should have even more 
> controls to play with, even those that may seem like should never be 
> used? For example, there seem to be no checkboxes or something similar 
> to control S/PDIF NIDs

That's because I cannot test SPDIF inputs since they are not brought out
to the outside world on my laptop.  Therefore I can't test prospective
controls.

> or jack (pin) widgets and so on.

With the exception of the SPDIF pins, all output pins provided by the ALC260
are already available in the mixer controls of the test model.  In other
words, all the *analog* outputs should be present.  Have I missed some? 
Which NIDs in particular are you referring to?

> Such controls might be useful for testing, when nothing else seems to work
> out

If all analog pins are already catered for there's really no other options
left.  Again, perhaps if you could elaborate on which controls you're
thinking about things might become clearer.  In terms of the ongoing Acer
saga, we probably need to take a step back and recap between yourself,
Paulo and me precisely what works, what doesn't and what's been tried.  I'll
pick this up in a day or so after giving things a bit more thought.

> In order not to clutter the default tester's mixer interface, maybe this
> (at least partially) should go to some kind of an "extended test" model, i
> don't know.

No, all controls belong in the test model.  It's a *test* model, so
cluttering of the mixer isn't really a problem.

> BTW, if I haven't misunderstood the datasheet, I think it says that 
> S/PDIF NIDs (0x03 and 0x06, if I remember correctly) can be told to 
> output Analog audio, along with the other channels.

I never noticed this - what page(s) of the datasheet appear to suggest this
to you?

> Could this possibly be Acer's case? I'm asking this because these were
> probably the only NIDs that I didn't even try to play with...

Digital outputs are digital outputs I would have thought - I can't imagine
why they would be retaskable to analog, and I certainly didn't notice this
possibility myself when I went through the datasheet.  If you had a page
number I could look at I'll investigate further.

The only way I would have thought the digital outputs could come into play
is if for some reason the internal speaker and headphone jack were driven
off an external DAC.  As I mentioned in a previous post though this doesn't
seem sensible from where we stand.

Regards
  jonathan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Test model

[Rimas Kudelis]

Hello,
>> BTW one of the actions I tried last weekend was recording something from
>> the microphone. And it failed too. selecting one (don't remember which,
>> though) of the capture channels for capture resulted in continuous noise
>> being recorded, and selecting the other one resulted in silence. Also,
>> selecting both resulted in sum of these, hence, noise again...
>>     
> What sort of noise - hiss I assume? 
Yes, it was hiss.

> Secondly, what do you mean by
> "selecting both"?  Do you mean that both capture sources were pointed at the
> same source?  If so you wouldn't have recorded the sum; the two ADCs are on
> separate pcms, so you would only have been recording one or the other in
> this case.
>   
I think I pointed both capture sources at MIC1 (my internal/external
microphone), then selected both channels for capture in capture mixer.

> What kind of microphone were you using?  Did you have a bias setting
> configured for the jack the mic was connected to?
>   
I tried it with the internal mic. I could clearly hear in the speakers
when I tapped the computer with my fingers, so I assumed I should be
able to record that sound too. However, all I got was the hiss from one
channel, and absolute silence from the other.

>> Also, not sure if it's alsamixer's or driver's fault, alsamixer always 
>> says "Input Source 1" is "1", even though it selects the required source.
>>     
> I'm confused by this - "1" isn't an option AFAIK.  "MIC1", "MIC2", "LINE1",
> "LINE2" etc are the options.
>   
Right. So I can select MIC1, LINE1 etc in the alsamixer, but the
indicator at the top always says "1" no matter what I select.
Just to be clear: i'm referring to the console version of the alsamixer.
OTOH, I haven't recompiled ALSA utils (I think, Im using what Ubuntu has
provided me with), so it might just be version incompatibility.

>> Jonathan, I think that maybe the "test" model should have even more 
>> controls to play with, even those that may seem like should never be 
>> used? For example, there seem to be no checkboxes or something similar 
>> to control S/PDIF NIDs
>>     
> That's because I cannot test SPDIF inputs since they are not brought out
> to the outside world on my laptop.  Therefore I can't test prospective
> controls.
>   
Well, I think you could try adding those controls. Just the fact that
S/PDIF pins are not connected to anything on your laptop won't stop the
driver from err'ing in case you implement something in a wrong way. For
example, it err'ed for me when I tried to add volume controls for pins
0x0f - 0x15, and alsamixer wouldn't even load in these cases. :) So
basically, if alsamixer loads for you after adding the mixer controls in
question, you shouldn't have done anything wrong.

>> or jack (pin) widgets and so on.
>>     
>
> With the exception of the SPDIF pins, all output pins provided by the ALC260
> are already available in the mixer controls of the test model.  In other
> words, all the *analog* outputs should be present.  Have I missed some? 
> Which NIDs in particular are you referring to?
>   
NIDs 0x0f - 0x15 don't have input/output mute checkboxes. Of course, you
may say these are useless, and I would agree with you. :) Then again,
when it comes to a situation like mine where none of the sane options
are helpfull, it's better to have insane options available too, i think. :)

>> Such controls might be useful for testing, when nothing else seems to work
>> out
>>     
> If all analog pins are already catered for there's really no other options
> left.  Again, perhaps if you could elaborate on which controls you're
> thinking about things might become clearer.  In terms of the ongoing Acer
> saga, we probably need to take a step back and recap between yourself,
> Paulo and me precisely what works, what doesn't and what's been tried.  I'll
> pick this up in a day or so after giving things a bit more thought.
>   
OK. I'll just remind again, that I don't have direct access to the lappy
in question now. However, if we come up with something interesting to
test, I wouldn't mind visiting my mother and giving her speakers one
more chance to speak. ;) She'd be happy to see me anyways.

>> In order not to clutter the default tester's mixer interface, maybe this
>> (at least partially) should go to some kind of an "extended test" model, i
>> don't know.
>>     
> No, all controls belong in the test model.  It's a *test* model, so
> cluttering of the mixer isn't really a problem.
>   
OK.

>> BTW, if I haven't misunderstood the datasheet, I think it says that 
>> S/PDIF NIDs (0x03 and 0x06, if I remember correctly) can be told to 
>> output Analog audio, along with the other channels.
>>     
> I never noticed this - what page(s) of the datasheet appear to suggest this
> to you?
>   
Page 67 (marked as 60), first table (continued from the last page):
Bit: 0
Description: DigEn (Digital Enable).
          0: OFF (S/PDIF-OUT is in Hi-Z)
          1: ON

Now again, I'm not sure if I understood it correctly.

>> Could this possibly be Acer's case? I'm asking this because these were
>> probably the only NIDs that I didn't even try to play with...
>>     
> Digital outputs are digital outputs I would have thought - I can't imagine
> why they would be retaskable to analog, and I certainly didn't notice this
> possibility myself when I went through the datasheet.  If you had a page
> number I could look at I'll investigate further.
>
> The only way I would have thought the digital outputs could come into play
> is if for some reason the internal speaker and headphone jack were driven
> off an external DAC.  As I mentioned in a previous post though this doesn't
> seem sensible from where we stand.
Well, having no sound from internal speakers in Linux, while having it
in Windows, doesn't seem sensible too... ;) It's as I said - when no
sane options are left, it's probably the time to try those that seem
insane. Just to make sure.

Regards,
Rimas



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Test model

[Jonathan Woithe]

Hi

> >> BTW one of the actions I tried last weekend was recording something from
> >> the microphone. And it failed too. selecting one (don't remember which,
> >> though) of the capture channels for capture resulted in continuous noise
> >> being recorded, and selecting the other one resulted in silence. Also,
> >> selecting both resulted in sum of these, hence, noise again...
> >>     
> > What sort of noise - hiss I assume? 
> Yes, it was hiss.

Interesting.

> > Secondly, what do you mean by "selecting both"?  Do you mean that both
> > capture sources were pointed at the same source?  If so you wouldn't
> > have recorded the sum; the two ADCs are on separate pcms, so you would
> > only have been recording one or the other in this case.
> >   
> I think I pointed both capture sources at MIC1 (my internal/external
> microphone), then selected both channels for capture in capture mixer.

What program did you then use to do the recording?  In a vast majority of
cases this will only record from the first PCM, so even though alsamixer had
both ADCs selected, odds are you were still only recording one of them.
This probably explains the silence in your initial test - you were still
only recording ADC0, but in that case it didn't have any source enabled.

Therefore the only odd thing about that test is the fact that you didn't
get any signal from the mic.

> > What kind of microphone were you using?  Did you have a bias setting
> > configured for the jack the mic was connected to?
> >   
> I tried it with the internal mic. I could clearly hear in the speakers
> when I tapped the computer with my fingers, so I assumed I should be
> able to record that sound too. However, all I got was the hiss ...

I would have expected that to work.  Which speakers did you hear the tapping
in?  The internal ones and the headphone jack aren't currently functional,
so that leaves only the external mic jack operating as an output, doesn't
it?  If so then perhaps it's some kind of coupling.

> >> Also, not sure if it's alsamixer's or driver's fault, alsamixer always 
> >> says "Input Source 1" is "1", even though it selects the required source.
> >>     
> > I'm confused by this - "1" isn't an option AFAIK.  "MIC1", "MIC2", "LINE1",
> > "LINE2" etc are the options.
> >   
> Right. So I can select MIC1, LINE1 etc in the alsamixer, but the
> indicator at the top always says "1" no matter what I select.

I'll have to check this on my laptop tonight - in particular, I'm not sure
what the "indicator at the top" is off-hand.

> Just to be clear: i'm referring to the console version of the alsamixer.

Sure.

> OTOH, I haven't recompiled ALSA utils (I think, Im using what Ubuntu has
> provided me with), so it might just be version incompatibility.

Which version of alsautils is that - the version number should be at the top
of alsamixer.

> >> Jonathan, I think that maybe the "test" model should have even more 
> >> controls to play with, even those that may seem like should never be 
> >> used? For example, there seem to be no checkboxes or something similar 
> >> to control S/PDIF NIDs
> >>     
> > That's because I cannot test SPDIF inputs since they are not brought out
> > to the outside world on my laptop.  Therefore I can't test prospective
> > controls.
> >   
> Well, I think you could try adding those controls. Just the fact that
> S/PDIF pins are not connected to anything on your laptop won't stop the
> driver from err'ing in case you implement something in a wrong way.

That wasn't the point.  The issue was that I couldn't test them to see if
they did what I expected - they would just be a stab in the dark.  Someone
trying them and getting no effect therefore would not know if the failure
was due to their hardware or a bug in the driver.

However, since there seems to be a call for this I'll look at adding
*something* for the SPDIF pins tonight.

> >> or jack (pin) widgets and so on.
> > With the exception of the SPDIF pins, all output pins provided by the ALC260
> > are already available in the mixer controls of the test model.  In other
> > words, all the *analog* outputs should be present.  Have I missed some? 
> > Which NIDs in particular are you referring to?
> >   
> NIDs 0x0f - 0x15 don't have input/output mute checkboxes. Of course, you
> may say these are useless, and I would agree with you. :)

The initverbs for the test model unmute both the input and output of NIDs
0x0f to 0x15, so they are ready for whichever mode is configured by the mode
switch.  This is why there are no explicit switches in the mixer for this.
Having switches for this would add significantly to the number of things a
tester would have to think about.  It was clear from my tests that having
both input and output unmuted didn't cause any trouble (beyond perhaps
contributing to a slight increase in the noise level when sampling), so
there was no basis to include manual switches for these.

Having said all that, I think it's actually possible to include manipulation
of these mute switches as part of the jack mode control.  Doing so will reduce
the ADC noise level slightly.

> Then again, when it comes to a situation like mine where none of the sane
> options are helpfull, it's better to have insane options available too, i
> think. :)

No arguments there in principle.

> > In terms of the ongoing Acer saga, we probably need to take a step back
> > and recap between yourself, Paulo and me precisely what works, what
> > doesn't and what's been tried.  I'll pick this up in a day or so after
> > giving things a bit more thought.
> >
> OK. I'll just remind again, that I don't have direct access to the lappy
> in question now. However, if we come up with something interesting to
> test, I wouldn't mind visiting my mother and giving her speakers one
> more chance to speak. ;) She'd be happy to see me anyways.

No worries.  We'll see how we go.

> >> BTW, if I haven't misunderstood the datasheet, I think it says that 
> >> S/PDIF NIDs (0x03 and 0x06, if I remember correctly) can be told to 
> >> output Analog audio, along with the other channels.
> >>     
> > I never noticed this - what page(s) of the datasheet appear to suggest this
> > to you?
> >   
> Page 67 (marked as 60), first table (continued from the last page):
> Bit: 0
> Description: DigEn (Digital Enable).
>           0: OFF (S/PDIF-OUT is in Hi-Z)
>           1: ON
> 
> Now again, I'm not sure if I understood it correctly.

This is simply to enable or disable the SPDIF control.  Having it disabled 
puts it into the Hi-Z state, which is short for "high impedence".  Essentially
this means that the current driver/receiver is disconnected from the pin.
It doesn't mean that analog audio is enabled.

> > The only way I would have thought the digital outputs could come into play
> > is if for some reason the internal speaker and headphone jack were driven
> > off an external DAC.  As I mentioned in a previous post though this doesn't
> > seem sensible from where we stand.
>
> Well, having no sound from internal speakers in Linux, while having it
> in Windows, doesn't seem sensible too... ;) It's as I said - when no
> sane options are left, it's probably the time to try those that seem
> insane. Just to make sure.

No arguments there.  I can't help but think that we're missing something
though.

Regards
  jonathan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Test model

[Rimas Kudelis]

Hello,

>> I think I pointed both capture sources at MIC1 (my internal/external
>> microphone), then selected both channels for capture in capture mixer.
>>     
> What program did you then use to do the recording? 
Gnome sound recorder.

> In a vast majority of
> cases this will only record from the first PCM, so even though alsamixer had
> both ADCs selected, odds are you were still only recording one of them.
> This probably explains the silence in your initial test - you were still
> only recording ADC0, but in that case it didn't have any source enabled.
>
> Therefore the only odd thing about that test is the fact that you didn't
> get any signal from the mic.
>   
Yes, and I also wonder, where could that hiss have come from...

>>> What kind of microphone were you using?  Did you have a bias setting
>>> configured for the jack the mic was connected to?
>>>       
>> I tried it with the internal mic. I could clearly hear in the speakers
>> when I tapped the computer with my fingers, so I assumed I should be
>> able to record that sound too. However, all I got was the hiss ...
>>     
> I would have expected that to work.  Which speakers did you hear the tapping
> in?  The internal ones and the headphone jack aren't currently functional,
> so that leaves only the external mic jack operating as an output, doesn't
> it?  If so then perhaps it's some kind of coupling.
>   
No, I used the Line-In jack (LINE1 channel) operating as output. Mic
(MIC1 channel) was set to 50pc or 80pc mic, of course. I could clearly
hear my tapping from the external amplified speakers connected to the
Line-In jack, but nothing was recorded no matter which ADC(s) I selected
for capture.

>>>> Also, not sure if it's alsamixer's or driver's fault, alsamixer always 
>>>> says "Input Source 1" is "1", even though it selects the required source.
>>>>         
>>> I'm confused by this - "1" isn't an option AFAIK.  "MIC1", "MIC2", "LINE1",
>>> "LINE2" etc are the options.
>>>       
>> Right. So I can select MIC1, LINE1 etc in the alsamixer, but the
>> indicator at the top always says "1" no matter what I select.
>>     
> I'll have to check this on my laptop tonight - in particular, I'm not sure
> what the "indicator at the top" is off-hand.
>   
There's an informational block at top-left of alsamixer.

>> OTOH, I haven't recompiled ALSA utils (I think, Im using what Ubuntu has
>> provided me with), so it might just be version incompatibility.
>>     
> Which version of alsautils is that - the version number should be at the top
> of alsamixer.
>   
I can't check it now.

> The initverbs for the test model unmute both the input and output of NIDs
> 0x0f to 0x15, so they are ready for whichever mode is configured by the mode
> switch.  This is why there are no explicit switches in the mixer for this.
> Having switches for this would add significantly to the number of things a
> tester would have to think about.  It was clear from my tests that having
> both input and output unmuted didn't cause any trouble (beyond perhaps
> contributing to a slight increase in the noise level when sampling), so
> there was no basis to include manual switches for these.
>   
That's why I said it should probably go to the extended test model.
However, on the other hand, if unmuting those ports indeed increases
noise level, maybe it would indeed be better to mute certain unused
ports in certain models that don't have anything connected to them anyways.

> Having said all that, I think it's actually possible to include manipulation
> of these mute switches as part of the jack mode control.  Doing so will reduce
> the ADC noise level slightly.
>   
That's a positive effect.

> This is simply to enable or disable the SPDIF control.  Having it disabled 
> puts it into the Hi-Z state, which is short for "high impedence".  Essentially
> this means that the current driver/receiver is disconnected from the pin.
> It doesn't mean that analog audio is enabled.
>   
Oh, I see.

Another thing: hda_local.h defines six pinctl values:
#define PIN_IN 0x20
#define PIN_VREF80 0x24
#define PIN_VREF50 0x21
#define PIN_OUT 0x40
#define PIN_HP 0xc0
#define PIN_HP_AMP 0x80
Did you miss the PIN_HP_AMP option when adding channel mode switchers,
or is it not available for ALC260, or what? If it's available in ALC260,
I think it should be added to the list of options. Just to make sure
we're not missing anything...

Another weird detail. Look at the picture here:
http://notebooky.idnes.cz/obrazek/acer_tm4600_aspire1690_09.jpg. On my
mothers notebook (which is almost identical to the one in the pic), the
outside of Line In and Mic jacks is made of metal, while the outside of
Headphones jack is made of black plastic. I wonder what is the reason
for this...

>>> The only way I would have thought the digital outputs could come into play
>>> is if for some reason the internal speaker and headphone jack were driven
>>> off an external DAC.  As I mentioned in a previous post though this doesn't
>>> seem sensible from where we stand.
>>>       
>> Well, having no sound from internal speakers in Linux, while having it
>> in Windows, doesn't seem sensible too... ;) It's as I said - when no
>> sane options are left, it's probably the time to try those that seem
>> insane. Just to make sure.
>>     
> No arguments there.  I can't help but think that we're missing something
> though.
I think so too. However, there's one weird thing - one user of a similar
laptop said on Ubuntu forums that the sound worked for him initially.
However, it seems like he's too „untechnical“ and unmotivated to give
any detail or even engage into a dialog... :( I wouldn't even be
surprised to find out that his notebook is not a member of the
Travelmate 4060 series at all...

RQ



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642

Re: Test model

[Jonathan Woithe]

> > In a vast majority of cases this will only record from the first PCM, so
> > even though alsamixer had both ADCs selected, odds are you were still
> > only recording one of them. This probably explains the silence in your
> > initial test - you were still only recording ADC0, but in that case it
> > didn't have any source enabled.
> >
> > Therefore the only odd thing about that test is the fact that you didn't
> > get any signal from the mic.
> >   
> Yes, and I also wonder, where could that hiss have come from...

At this stage, anywhere.  If a relevant gain control was turned up
high you'll get plenty of hiss if that signal is then selected as an ADC
input.  Again, the odd thing is that the signal didn't show at the ADC,
not the fact that there was a lot of hiss.

> >> I tried it with the internal mic. I could clearly hear in the speakers
> >> when I tapped the computer with my fingers, so I assumed I should be
> >> able to record that sound too. However, all I got was the hiss ...
> >>     
> > I would have expected that to work.  Which speakers did you hear the tapping
> > in?  The internal ones and the headphone jack aren't currently functional,
> > so that leaves only the external mic jack operating as an output, doesn't
> > it?  If so then perhaps it's some kind of coupling.
> >   
> No, I used the Line-In jack (LINE1 channel) operating as output. Mic
> (MIC1 channel) was set to 50pc or 80pc mic, of course. I could clearly
> hear my tapping from the external amplified speakers connected to the
> Line-In jack, but nothing was recorded no matter which ADC(s) I selected
> for capture.

Hmm, ok.  So for this test we had:
 - MIC1 pin mode set to 50pc / 80pc
 - The mode of the pin we've worked out previously is connected to the 
   Line-In jack was set to line-out or headphone (it wouldn't matter which)
 - The "MIC1 Playback Volume" was set high-ish and "MIC1 Playback Switch"
   was unmuted (so you can hear it through your speakers)
 - The "Input Source" was set to "MIC1"
 - The "Input Source" volume control was turned up high and was unmuted.
 - "Input Source" *might* have to be enabled too - I can't recall if alsamixer
   has a control for this or not.

If you can't recall for sure, it might be worth running through this
checklist next time you have access to the computer.

Also note that alsamixer does not select any particular ADC for capture.  All
it does is sets up up the signal routing to the available ADCs.  "Input
Source" refers to pcm0 while "Input Source 1" refers to pcm1.  Unless
otherwise instructed, capture programs will *always* capture from "Input
Source", not "Input Source 1" - that is, it will always capture from pcm0
unless you tell it otherwise.  The method of "telling it otherwise" depends
on the recording program and is a function which must be provided by the
program.  If the program doesn't allow you to select the pcm to use as
source then it's stuck with pcm0.

> >>>> Also, not sure if it's alsamixer's or driver's fault, alsamixer always 
> >>>> says "Input Source 1" is "1", even though it selects the required source.
> >>>>         
> >>> I'm confused by this - "1" isn't an option AFAIK.  "MIC1", "MIC2", "LINE1",
> >>> "LINE2" etc are the options.
> >>>       
> >> Right. So I can select MIC1, LINE1 etc in the alsamixer, but the
> >> indicator at the top always says "1" no matter what I select.
> >>     
> > I'll have to check this on my laptop tonight - in particular, I'm not sure
> > what the "indicator at the top" is off-hand.
> >   
> There's an informational block at top-left of alsamixer.

Ah, right, up there.  Thanks - I'll check it out.

> > The initverbs for the test model unmute both the input and output of NIDs
> > 0x0f to 0x15, so they are ready for whichever mode is configured by the mode
> > switch.  This is why there are no explicit switches in the mixer for this.
> > Having switches for this would add significantly to the number of things a
> > tester would have to think about.  It was clear from my tests that having
> > both input and output unmuted didn't cause any trouble (beyond perhaps
> > contributing to a slight increase in the noise level when sampling), so
> > there was no basis to include manual switches for these.
> >   
> That's why I said it should probably go to the extended test model.
> However, on the other hand, if unmuting those ports indeed increases
> noise level, maybe it would indeed be better to mute certain unused
> ports in certain models that don't have anything connected to them anyways.

Let's put this into perspective: we're talking about an *inaudible* increase
in the noise floor - probably much less than 1 dB, although I am yet to
measure it explicitly.  This is why there is really no practically
observable problem in enabling both the input and output simultaneously.

> > This is simply to enable or disable the SPDIF control.  Having it disabled 
> > puts it into the Hi-Z state, which is short for "high impedence".  Essentially
> > this means that the current driver/receiver is disconnected from the pin.
> > It doesn't mean that analog audio is enabled.
> >   
> Oh, I see.

And by "current" here I was referring to electrical current (in case the
sentence didn't read right for some).

> Another thing: hda_local.h defines six pinctl values:
> #define PIN_IN 0x20
> #define PIN_VREF80 0x24
> #define PIN_VREF50 0x21
> #define PIN_OUT 0x40
> #define PIN_HP 0xc0
> #define PIN_HP_AMP 0x80
> Did you miss the PIN_HP_AMP option when adding channel mode switchers,
> or is it not available for ALC260, or what? If it's available in ALC260,
> I think it should be added to the list of options. Just to make sure
> we're not missing anything...

It wasn't missed.  You'll notice that PIN_HP_AMP sets a single bit (bit 7)
while PIN_HP sets two (bits 6 and 7).  Bit 7 enables the headphone amp in a
retasking pin while bit 6 enables the pin's output.  PIN_HP_AMP is provided
for convenience for those times when the amp bit itself needs to be directly
manipulated - it's not actually a completely specified mode since it doesn't
make practical sense to enable the power amplifier without also enabling
output (otherwise the amplifier would be amplifying a muted signal).  To
perhaps make this clearer, the PIN_HP definition could be thought of as
being

  #define PIN_HP (PIN_OUT | PIN_HP_AMP)

> Another weird detail. Look at the picture here:
> http://notebooky.idnes.cz/obrazek/acer_tm4600_aspire1690_09.jpg. On my
> mothers notebook (which is almost identical to the one in the pic), the
> outside of Line In and Mic jacks is made of metal, while the outside of
> Headphones jack is made of black plastic. I wonder what is the reason
> for this...

No idea.  Someone in the design section obviously had a reason.  Perhaps
they've done some odd ground isolation arrangement for the headphone output,
but I think it's more likely to be either purely for looks.  Either that or
space constrains required that they use sockets with different dimensions,
and those with a size suitable for the headphone socket only came in plastic.
In any case I very much doubt that this is relevant to the problems at hand.

> >> Well, having no sound from internal speakers in Linux, while having it
> >> in Windows, doesn't seem sensible too... ;) It's as I said - when no
> >> sane options are left, it's probably the time to try those that seem
> >> insane. Just to make sure.
> >>     
> > No arguments there.  I can't help but think that we're missing something
> > though.
> I think so too. However, there's one weird thing - one user of a similar
> laptop said on Ubuntu forums that the sound worked for him initially.

Do you have a URL to the post?

Regards
  jonathan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Test model

[Rimas Kudelis]

Hello,
> Hmm, ok.  So for this test we had:
>  - MIC1 pin mode set to 50pc / 80pc
>  - The mode of the pin we've worked out previously is connected to the 
>    Line-In jack was set to line-out or headphone (it wouldn't matter which)
>  - The "MIC1 Playback Volume" was set high-ish and "MIC1 Playback Switch"
>    was unmuted (so you can hear it through your speakers)
>  - The "Input Source" was set to "MIC1"
>  - The "Input Source" volume control was turned up high and was unmuted.
>  - "Input Source" *might* have to be enabled too - I can't recall if alsamixer
>    has a control for this or not.
>
> If you can't recall for sure, it might be worth running through this
> checklist next time you have access to the computer.
>
> Also note that alsamixer does not select any particular ADC for capture.  All
> it does is sets up up the signal routing to the available ADCs.  "Input
> Source" refers to pcm0 while "Input Source 1" refers to pcm1.  Unless
>   
I'd vote for "Input Source 0" and "Input Source 1" though. Numbering
both controls would make sense, imho.

> otherwise instructed, capture programs will *always* capture from "Input
> Source", not "Input Source 1" - that is, it will always capture from pcm0
> unless you tell it otherwise.  The method of "telling it otherwise" depends
> on the recording program and is a function which must be provided by the
> program.  If the program doesn't allow you to select the pcm to use as
> source then it's stuck with pcm0.
>   
Ah. I thought that it's enough to select it for capture in alsamixer...

>>> The initverbs for the test model unmute both the input and output of NIDs
>>> 0x0f to 0x15, so they are ready for whichever mode is configured by the mode
>>> switch.  This is why there are no explicit switches in the mixer for this.
>>> Having switches for this would add significantly to the number of things a
>>> tester would have to think about.  It was clear from my tests that having
>>> both input and output unmuted didn't cause any trouble (beyond perhaps
>>> contributing to a slight increase in the noise level when sampling), so
>>> there was no basis to include manual switches for these.
>>>       
>> That's why I said it should probably go to the extended test model.
>> However, on the other hand, if unmuting those ports indeed increases
>> noise level, maybe it would indeed be better to mute certain unused
>> ports in certain models that don't have anything connected to them anyways.
>>     
> Let's put this into perspective: we're talking about an *inaudible* increase
> in the noise floor - probably much less than 1 dB, although I am yet to
> measure it explicitly.  This is why there is really no practically
> observable problem in enabling both the input and output simultaneously.
>   
Nor is there a problem in disabling them for models known not to use
relevant pins at all.

>> Another thing: hda_local.h defines six pinctl values:
>> #define PIN_IN 0x20
>> #define PIN_VREF80 0x24
>> #define PIN_VREF50 0x21
>> #define PIN_OUT 0x40
>> #define PIN_HP 0xc0
>> #define PIN_HP_AMP 0x80
>> Did you miss the PIN_HP_AMP option when adding channel mode switchers,
>> or is it not available for ALC260, or what? If it's available in ALC260,
>> I think it should be added to the list of options. Just to make sure
>> we're not missing anything...
>>     
>
> It wasn't missed.  You'll notice that PIN_HP_AMP sets a single bit (bit 7)
> while PIN_HP sets two (bits 6 and 7).  Bit 7 enables the headphone amp in a
> retasking pin while bit 6 enables the pin's output.  PIN_HP_AMP is provided
> for convenience for those times when the amp bit itself needs to be directly
> manipulated - it's not actually a completely specified mode since it doesn't
> make practical sense to enable the power amplifier without also enabling
> output (otherwise the amplifier would be amplifying a muted signal).  To
> perhaps make this clearer, the PIN_HP definition could be thought of as
> being
>
>   #define PIN_HP (PIN_OUT | PIN_HP_AMP)
>   
Oh, I see.

>> Another weird detail. Look at the picture here:
>> http://notebooky.idnes.cz/obrazek/acer_tm4600_aspire1690_09.jpg. On my
>> mothers notebook (which is almost identical to the one in the pic), the
>> outside of Line In and Mic jacks is made of metal, while the outside of
>> Headphones jack is made of black plastic. I wonder what is the reason
>> for this...
>>     
> No idea.  Someone in the design section obviously had a reason.  Perhaps
> they've done some odd ground isolation arrangement for the headphone output,
> but I think it's more likely to be either purely for looks.  Either that or
> space constrains required that they use sockets with different dimensions,
> and those with a size suitable for the headphone socket only came in plastic.
>   
Well that would be a weird reason IMO.

> In any case I very much doubt that this is relevant to the problems at hand.
>
>   
>>>> Well, having no sound from internal speakers in Linux, while having it
>>>> in Windows, doesn't seem sensible too... ;) It's as I said - when no
>>>> sane options are left, it's probably the time to try those that seem
>>>> insane. Just to make sure.
>>>>     
>>>>         
>>> No arguments there.  I can't help but think that we're missing something
>>> though.
>>>       
>> I think so too. However, there's one weird thing - one user of a similar
>> laptop said on Ubuntu forums that the sound worked for him initially.
>>     
>
> Do you have a URL to the post?
>   
http://ubuntuforums.org/showthread.php?t=99222

Bye,

Rimas.



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Test model

[Jonathan Woithe]

Hi

> > Hmm, ok.  So for this test we had:
> >  - MIC1 pin mode set to 50pc / 80pc
> >  - The mode of the pin we've worked out previously is connected to the 
> >    Line-In jack was set to line-out or headphone (it wouldn't matter which)
> >  - The "MIC1 Playback Volume" was set high-ish and "MIC1 Playback Switch"
> >    was unmuted (so you can hear it through your speakers)
> >  - The "Input Source" was set to "MIC1"
> >  - The "Input Source" volume control was turned up high and was unmuted.
> >  - "Input Source" *might* have to be enabled too - I can't recall if alsamixer
> >    has a control for this or not.
> >
> > If you can't recall for sure, it might be worth running through this
> > checklist next time you have access to the computer.
> >
> > Also note that alsamixer does not select any particular ADC for capture.  All
> > it does is sets up up the signal routing to the available ADCs.  "Input
> > Source" refers to pcm0 while "Input Source 1" refers to pcm1.  Unless
> >   
> I'd vote for "Input Source 0" and "Input Source 1" though. Numbering
> both controls would make sense, imho.

That's not up to the driver - that's the way the alsa mixer API enumerates
the two controls the driver says it needs.

> > otherwise instructed, capture programs will *always* capture from "Input
> > Source", not "Input Source 1" - that is, it will always capture from pcm0
> > unless you tell it otherwise.  The method of "telling it otherwise" depends
> > on the recording program and is a function which must be provided by the
> > program.  If the program doesn't allow you to select the pcm to use as
> > source then it's stuck with pcm0.
> >   
> Ah. I thought that it's enough to select it for capture in alsamixer...

Um, no.  All that effectively does (as far as I can tell) is unmute the
ADC input.  It doesn't connect that ADC to pcm0 or make it the default
ADC for recording applications (or whatever).

I did some more tests overnight with the "test" model which will hopefully
assist in clearing some points up.  Below are the mixer settings I needed
to use to get sound happening to/from the various points on my S7020.

 1) Playing to a jack:
     * set the pin's mode to "headphone" or "lineout".  For me, "line-out"
       jack is connected to the "LINE1" pin.
     * LOUT1: unmute *and* turn up.  If no sound, try the same for LOUT2.

 2) Playing to the internal speaker:
     * set the mode of the pin connected to the internal speaker to
       "headphone".  On the S7020, this is the HP-OUT pin.
     * LOUT2: unmute *and* turn up.  If no sound, try the same for LOUT1.

 3) Recording from mic jack.  For the S7020 this is the MIC1 pin which 
    is assumed below.  Substitute whichever pin is appropriate in your
    situation.
     * In the "playback" view in alsamixer:
        - "Input source" control: select MIC1.
        - "MIC1": unmute, turn volume up (if you want to hear the mic signal 
          through the card's output).  This shouldn't affect the recording 
          of the signal though.
        - "MIC1" pin mode: "mic bias 80pc", "mic bias 50pc" or "line-in"
          depending on what you're using as the source.  If it's a mic,
          perhaps try "mic bias 80pc" first.
     * In the "capture" view in alsamixer:
        - enable the "Capture" channel by highlighting it and pressing 
          <space>.
        - turn the "Capture" volume up.

My laptop doesn't have an internal mic, so I couldn't test that.  I would
expect it to be similar for (3) except the pin in question may be different.

In addition, when playing a sound to the "mic" jack (which on the S7020 is
actually a stereo line-in jack) the sound lacked bass - as if a high-pass
filter was active on that channel.  I noticed this earlier in my development
too and didn't pursue it at the time because the ALC260 only has one DAC so
there was no real need to retask the "mic/line" input on my laptop.  At this
stage I've been putting this down to the details of the circuitry used on
that pin, but there are a small number of ALC260 things I still want to
check yet.  I'll do this soon hopefully.

Finally, if there's still no joy recording (and to make sure we're not
dealing with some other strange alsalib thing), maybe grab batchrec from
my website:

  http://www.physics.adelaide.edu.au/~jwoithe/batchrec-1.2.0.tgz

Run it in NULL mode initially:

  batchrec -n foo.wav

It's a text-mode program using the OSS API, so you'll need the alsa oss
emulation modules loaded for it to work.  This opens pcm0 effectively and
will display some simple level meters which should be sufficient to indicate
whether you're seeing signal from the mic.  <Ctrl>C will quit.  This is the
program I used to test the recording configuration described above, and using
it will remove one more variable from the equation.

Actually, I've just had another thought: you said you used gnome-recorder.
I've never used it, but I wonder if it has its own input volume control
which is being made active when you run the program.  If so and it's set to
a minimum that may explain why you're not recording any signal.

> > Let's put this into perspective: we're talking about an *inaudible* increase
> > in the noise floor - probably much less than 1 dB, although I am yet to
> > measure it explicitly.  This is why there is really no practically
> > observable problem in enabling both the input and output simultaneously.
> >   
> Nor is there a problem in disabling them for models known not to use
> relevant pins at all.

Most (if not all) models currently do this, including "fujitsu".

> >> Another weird detail. Look at the picture here:
> >> http://notebooky.idnes.cz/obrazek/acer_tm4600_aspire1690_09.jpg. On my
> >> mothers notebook (which is almost identical to the one in the pic), the
> >> outside of Line In and Mic jacks is made of metal, while the outside of
> >> Headphones jack is made of black plastic. I wonder what is the reason
> >> for this...
> >>     
> > No idea.  Someone in the design section obviously had a reason.  Perhaps
> > they've done some odd ground isolation arrangement for the headphone output,
> > but I think it's more likely to be either purely for looks.  Either that or
> > space constrains required that they use sockets with different dimensions,
> > and those with a size suitable for the headphone socket only came in plastic.
> >   
> Well that would be a weird reason IMO.

Strange, but not unheard of, especially if there are space constraints at
different points inside the laptop.  These sockets come in all sorts of
shapes, sizes and configurations (in terms of internal switches etc) - some
with plastic surrounds, others with metal.  However, not all combinations
are made, obviously.  Therefore if there was a space constraint for one of
the sockets the manufacturer might have had to move to a plastic one because
there were none with metal in a sutiable size and configuration to fit. 
These kinds of compromises are made all the time in manufacturing.  I admint
that it would be odd, but I can quite believe that this could be the case.

> >> I think so too. However, there's one weird thing - one user of a similar
> >> laptop said on Ubuntu forums that the sound worked for him initially.
> > Do you have a URL to the post?
> http://ubuntuforums.org/showthread.php?t=99222

You're right.  Not a lot of detail there unfortunately.

Regards
  jonathan


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642