More detailed Acer (Intel HDA)

More detailed Acer (Intel HDA)

[Rimas Kudelis]

[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]

Hi Jonathan, Takashi, and others,

I asked a user on Ubuntu forums to test Acer jack modes more
extensively. The results are a bit surprising. You may want to check
out http://ubuntuforums.org/showthread.php?p=825101#post825101.

It's strange for me that it seems like Mic Preamplifier seems to be
always off for LINE1 channel.
It's also a bit strange that a jack connected to MIC1 always outputs
in mono when set as output, but maybe that's just how Acer engineers
decided it should be.
And the third interesting thing is that the user could not select Mic
modes at all for LINE-OUT channel. Did I skip this part in the
datasheet, or is it undocumented?

Also, is there really a difference between Mic 50% and Mic 80%? Maybe
it's enough to only make one of these modes available in the mixer if
there's no big difference between them? Same goes for
Headphone/Line–Out modes. What airbuds did you mention previously (you
said Headphone mode might be useful for them)? Is it those small
headphones that one can put INTO their ear and then hear poor sound?
:) I don't have them handy ATM, so I can't test if there's any
difference between Line-Out and Headphones modes for them...

regards,
Rimas



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: More detailed Acer (Intel HDA)

[Lee Revell]

On Sun, 2006-03-19 at 14:47 +0200, Rimas Kudelis wrote:
> Hi Jonathan, Takashi, and others,
> 
> I asked a user on Ubuntu forums to test Acer jack modes more
> extensively. The results are a bit surprising. You may want to check
> out http://ubuntuforums.org/showthread.php?p=825101#post825101.

Breezy is too old, that driver had many bugs fixed lately.  How does it
work with the latest ALSA CVS version?

Lee



-------------------------------------------------------
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

Re: More detailed Acer (Intel HDA)

[Rimas Kudelis]

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

Hi,

>> I asked a user on Ubuntu forums to test Acer jack modes more
>> extensively. The results are a bit surprising. You may want to check
>> out http://ubuntuforums.org/showthread.php?p=825101#post825101.
> 
> Breezy is too old, that driver had many bugs fixed lately.  How does it
> work with the latest ALSA CVS version?

He IS using the latest ALSA CVS version with Breezy. ;) That's why the
sound does work for him. Just some of the details of HOW it works are
quite interesting...

Rimas


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: More detailed Acer (Intel HDA)

[Lee Revell]

On Mon, 2006-03-20 at 01:19 +0200, Rimas Kudelis wrote:
> Hi,
> 
> >> I asked a user on Ubuntu forums to test Acer jack modes more
> >> extensively. The results are a bit surprising. You may want to check
> >> out http://ubuntuforums.org/showthread.php?p=825101#post825101.
> > 
> > Breezy is too old, that driver had many bugs fixed lately.  How does it
> > work with the latest ALSA CVS version?
> 
> He IS using the latest ALSA CVS version with Breezy. ;) That's why the
> sound does work for him. Just some of the details of HOW it works are
> quite interesting...

That thread is too long.  Please describe briefly exactly what the
unexpected behavior is and how you think it should work and file an ALSA
bug report.

Lee



-------------------------------------------------------
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

Re: More detailed Acer (Intel HDA)

[Rimas Kudelis]

Hola,
>>>> I asked a user on Ubuntu forums to test Acer jack modes more
>>>> extensively. The results are a bit surprising. You may want to check
>>>> out http://ubuntuforums.org/showthread.php?p=825101#post825101.
>>>>         
>>> Breezy is too old, that driver had many bugs fixed lately.  How does it
>>> work with the latest ALSA CVS version?
>>>       
>> He IS using the latest ALSA CVS version with Breezy. ;) That's why the
>> sound does work for him. Just some of the details of HOW it works are
>> quite interesting...
>>     
> That thread is too long.  Please describe briefly exactly what the
> unexpected behavior is and how you think it should work and file an ALSA
> bug report.
>   

That thread was started long before the acer model was actually added to
hda-intel driver. Everything that I find unexpected is written in the
exact post I linked to.

I'm not going to file a bug. Just asking for Jonathan's opinion about
this (i.e., why doesn't LINE-OUT allow choosing Mic modes, but allows
Line In). After I check everything, i'm willing to write a small patch
that removes all non-working features (like CD and Beep controls) from
the current acer model and, maybe, adds one or two that are not
currently in.

Rimas




-------------------------------------------------------
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

Re: More detailed Acer (Intel HDA)

[Takashi Iwai]

At Mon, 20 Mar 2006 08:50:14 +0200,
Rimas Kudelis wrote:
> 
> Hola,
> >>>> I asked a user on Ubuntu forums to test Acer jack modes more
> >>>> extensively. The results are a bit surprising. You may want to check
> >>>> out http://ubuntuforums.org/showthread.php?p=825101#post825101.
> >>>>         
> >>> Breezy is too old, that driver had many bugs fixed lately.  How does it
> >>> work with the latest ALSA CVS version?
> >>>       
> >> He IS using the latest ALSA CVS version with Breezy. ;) That's why the
> >> sound does work for him. Just some of the details of HOW it works are
> >> quite interesting...
> >>     
> > That thread is too long.  Please describe briefly exactly what the
> > unexpected behavior is and how you think it should work and file an ALSA
> > bug report.
> >   
> 
> That thread was started long before the acer model was actually added to
> hda-intel driver. Everything that I find unexpected is written in the
> exact post I linked to.
> 
> I'm not going to file a bug. Just asking for Jonathan's opinion about
> this (i.e., why doesn't LINE-OUT allow choosing Mic modes, but allows
> Line In). After I check everything, i'm willing to write a small patch
> that removes all non-working features (like CD and Beep controls) from
> the current acer model and, maybe, adds one or two that are not
> currently in.

Great.  Please pass it to me as soon as finished, not to miss 2.6.17
kernel development window.  We have to push the patches in the right
time.

Besides, a summary post would be really appreciated.  (I like ML much
better than BTS :)


Takashi


-------------------------------------------------------
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

Re: More detailed Acer (Intel HDA)

[Jonathan Woithe]

Hi guys

Sorry for the delay in responding - I was out of the office for a few days.

> I asked a user on Ubuntu forums to test Acer jack modes more
> extensively. The results are a bit surprising. You may want to check
> out http://ubuntuforums.org/showthread.php?p=3D825101#post825101.

This URL seemed to point to a thread discussing Java things.  I can't
see anything in there related to audio.

> It's strange for me that it seems like Mic Preamplifier seems to be
> always off for LINE1 channel.

Without being able to see the post it's difficult to comment.  What lead
to this conclusion?

> It's also a bit strange that a jack connected to MIC1 always outputs
> in mono when set as output, but maybe that's just how Acer engineers
> decided it should be.

A vast majority of laptops only have a mono jack in use for anything labeled
"mic".  I guess the reasoning is that microphones are mono by nature so they
can save a few cents and have only a mono jack.  Unless anyone can come up
with evidence to the contrary, I would say that the reason the sound only
comes out in mono out of the Acer "mic" jack is because it's only a mono
jack.

> And the third interesting thing is that the user could not select Mic
> modes at all for LINE-OUT channel. Did I skip this part in the
> datasheet, or is it undocumented?

I have found that some of the ALC260 pin widgets don't allow one to choose
the mic modes - see the comments above the alc_pin_mode_names[] definition
in patch_realtek.c (at or around line 237).  The widgets appear to accept
the message selecting these modes, but when you request the pin mode status
you see that it has been ignored.  NIDs 0x0f and 0x10 have been observed to
suffer from the problem; there might be more.  If either 0x0f or 0x10 are
used for the LINE-OUT channel (and there's every likelihood that they are)
then this would explain the observation.

In other words, it appears to be an undocumented hardware "feature" which we
can do nothing about.

> Also, is there really a difference between Mic 50% and Mic 80%? Maybe
> it's enough to only make one of these modes available in the mixer if
> there's no big difference between them?

The difference is the voltage level output by the pin widget.  50% is 50% of
the ADC supply voltage; 80% is 80% of the supply voltage.  50% is
technically better since it's symmetric - negative and positive signals will
clip at the same amplitude.  It also gives more headroom so the potential
exists for one to achieve a higher signal-to-noise ratio (SNR).  The problem
is that for some mics, the 50% voltage level is not sufficient to power the
mic; they need the 80% level instead.  However, the trade-off is that the
maximum positive input voltage is now quite a bit less than the maximum
negative input voltage, so clipping is far more likely in the presence of
higher level signals.

In this respect I would argue that it is best to keep both levels.  People
can use the superior 50% if it works for them, but fall back to 80% if their
particular microphones need it.

> Same goes for Headphone/Line-Out modes.

There is a big difference; "headphone" enables an on-chip power amplifier
(PA) while "line-out" does not.  The PA allows the chip to drive low
impedence headphones (8-32 ohms for example) to a "reasonable" volume (for
some definition of "reasonable").  However, being an on-chip amplifier its
noise level is quite high - when feeding a line-level input of an external
amplifier or mixer (for example), using the onboard amplifier is less than
optimal.

Therefore both settings should remain; they are both needed since they allow
for two very different ways of using the outputs.  More technically, they
allow the chip to optimally drive two very different types of loads: low
impedence headphones and higher impedence equipment inputs.

Technically, "line-out" mode has a higher output impedence with higher SNR
while "headphone out" activates an amplifier with a much lower output
impedence but with a lower SNR.  "line-out" mode is therefore suitable for
driving high impedence loads such as the line-level inputs of mixing desks,
minidisc decks etc (which have input impedences of the order to 1-10
k-ohms).  "Headphone" mode is best matched to low impedence (8-32 ohm) loads
such as most headphones; the noise floor is elevated but that's not usually
an issue for general listening.

Finally, it should be noted that normally low impedence outputs are best
in terms of noise performance.  The reason that's different in this case
is that the low impedence mode corresponds with an additional voltage gain
stage which itself is housed in a very electrically noisy environment.

> What airbuds did you mention previously (you said Headphone mode might be
> useful for them)? Is it those small headphones that one can put INTO their
> ear and then hear poor sound? :) I don't have them handy ATM, so I can't
> test if there's any difference between Line-Out and Headphones modes for
> them...

Any headphone-type thing with an impedence less than (say) 100 ohms will
benefit from "headphone" mode (I can't give exact figures since I haven't
measured the output impedence of line-out mode).  BTW, while it is true that
typical consumer earbuds sound pretty ordinary, there are units designed for
in-ear monitoring systems which sound awesome.

So in conclusion, based on the information I have at hand I suspect that the
limitations reported by the Ubantu user come about due to hardware issues;
as far as I can tell things seem to be behaving pretty much as I would
expect.  Furthermore, I would argue very strongly that the pin mode choices
need to remain as they are for the reasons detailed above.  The different
modes are optimised for different uses and I see no reason to lock
particular users out of their optimal configuration just to save an entry in
a mode list.

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

Re: More detailed Acer (Intel HDA)

[Jonathan Woithe]

Hi again.

> > That thread is too long.  Please describe briefly exactly what the
> > unexpected behavior is and how you think it should work and file an ALSA
> > bug report.
> 
> That thread was started long before the acer model was actually added to
> hda-intel driver. Everything that I find unexpected is written in the
> exact post I linked to.

Ah, found it now.  That "=3D" thing caused the forum website to do something
odd.  Anyway, having now read the forum post most of my comments in my
previous posting still stand.  In short, the driver and the hardware appear
to be operating pretty much as expected.

Running through that post:

> For [Headphone Jack Mode]
> ->Mic 50 bias or Mic 80 bias: you can not select them at all. They apear 
>   in the drop down list but when you try to select one it changes 
>   automatically to "Line in" option.

This is most likely due to the hardware limitation of the ALC260 chip I 
mentioned in my earlier post.  If either NID 0x0f or 0x10 is the pin 
widget used for the headphone jack on these laptops then the mic modes
are not activated by the hardware when selected.  This is not mentioned
in the datasheet.

The driver checks for the success of the mode setting and if it doesn't
work it will revert to a mode which does.  If the user selected a "mic"
mode then presumedly they want to record something, so "line-in" is the 
next best alterative that the hardware supports.

> ->"Line in": it doesn't work. In fact it can't work since you haven't got 
>   a "Headphone" option in Input source.

"Line in" would work if the input source for the Acer model included the
headphone jack as an option.  However, one would have to test it with a
source which did not require a bias voltage since as already explained
this pin widget can't provide one.  A CD player or something like that 
would have to be used.

Adding a "headphone" option to the input sources for the acer model will
probably have to wait until I've got my patch in order which adds the
ability to have different input source lists for different ADCs.  The
datasheet shows that NIDs 0x0f and 0x10 feed different inputs on the
different ADCs.  To avoid confusion, we need the ability to define separate
input source lists for different ADCs.  I shall endevour to get this patch
in order by early next week.

> ->"Line out" or "Headphone out": work ok but without any difference on 
>   their output level (1 volt RMS).

Based on the test method described it seems the output voltage was measured
across an unloaded jack.  If so then I would not expect any difference
between the "line out" and "headphone" modes since the difference comes
about due to the impedence presented by the load.  If this was measured with
a 22 ohm resistor connected across the jack I expect one will find a
substancial level difference.

> For [Line Jack Mode]
> ->"Mic 50 bias" or "Mic 80 bias" or "Line in": work ok when you plug a 
>   line signal without any difference on their recording level. Plugging a 
>   mic here only records background noise.

For a line-level signal the "mic" and "line" modes won't make a great deal
of difference, although the noise level is likely to be higher with the "mic"
mode.  The presence of the bias voltage might also have some interesting
interactions with the output circuitry of some devices.

As to the mic, I can't explain that.  I'm guessing it was one of those cheap
so-called "computer" mics.  If so, "Line in" mode will certainly not work
since these mics require a bias voltage in order to function.  You will
indeed record only background noise.  One (or both) of the "mic" modes
should work though, and people have certainly reported mics working in these
modes when using the "Acer" model.  I wonder whether things were perhaps not
set up correctly for recording?  In addition to selecting the this input as
the input source for "Capture" (not "Capture 1" since most recording
programs don't allow one to select the ADC if there's more than one, and
default to the first one), one also has to enable "Capture" by finding it in
the Capture section of alsamixer, highlighting "Capture" and pressing
<space>.

Another possibility is that Acer have included series blocking capacitors
between the ALC260 and the physical jack (this is probably more likely since
the post indicates that recording was successfully done later on).  Such
capacitors would block any bias voltage sent by the ALC260 and thus stop any
condensor microphones from working. This can be easily tested: put a
volt-meter onto the unloaded/undriven jack and observe the output DC voltage
in the three input modes ("mic 50%", "mic 80%" and "line in").  For "line
in" it will be close to 0.  For the other two it should be around 1.65V and
2.64V respectively (assuming the ALC260 is being fed with 3.3V).  If both
mic modes result in very little voltage then that probably confirms that
there's a DC block in place within the laptop which will prevent condensor
mics from working in this jack unless they have provision for their own
power supply.

On reflection this second option is probably more likely.  Acer probably
summised that mics can go into the "mic" jack while line-level sources can
go into the "line in" jack.  As such the "line in" jack has no need of bias
voltages, so they block DC to prevent any bias voltages produced by the
ALC260 from having any interaction with connected sources.

> ->"Line out" and "Headphone out" work ok in stereo with just the same 
>   output level in both cases (1.2 volts).

I suspect the reason the output level doesn't change is the same as for the
"headphone" jack before: either a low impedence load was not in use when the
voltage was measured or the headphones being used to do the loading are of
the high-impedence type.

> For [Mic Jack Mode]
> ->"Mic 50 bias" or "Mic 80 bias" or "Line in": plugging a mic you record 
>   with first and second options just with the same level.With "Line in" 
>   you only record noise. Plugin a line signal you get just the same 
>   recording level in the three cases.

Completely expected on all counts.  In this case the person's mic is happy
with the 50% voltage bias so I would be inclined to use that.  As explained
before, "Line in" mode removes the bias voltage, so condensor-type
microphones will no longer operate.

An interesting question: I wonder whether a stereo line-in source recorded
in mono or stereo via this jack.  Given the next comments (see below) I
suspect the summed left and right signal would have been sent to both input
channels.

> ->"Line out" and "Headphone out" work ok but in mono (only outputs the 
>   mixed two stereo channels to left channel) with just the same output 
>   level in both cases (1.2 volts).

In terms of the output voltage measurement the same comment applies here as
to the other pins.

The presence of the mono signal in the left channel almost certainly
confirms that the jack is actually a mono jack.  This would not be all that
surprising since most jacks labelled "mic" on laptops are in fact mono. 
It's interesting that left and right are mixed; Acer presumedly has
connected the pin widget's left and right channels together, possibly via
low-value isolation resistors.  The rationale for this would be along the
lines I mentioned in my previous post: "most computer-consumer mics are mono,
so let's make the mic jack mono but feed the signal to the ADC's left and
right inputs to avoid confusing the consumer".

A comment on the test method: was the AC voltmeter in use reliable at a
frequency of 440 Hz.  For most voltmeters the AC scale is calibrated to read
RMS of a sine wave at 50 Hz.  Many cheaper models fall off quite badly at
frequencies higher than 100 Hz.  Since a reasonable reading was achieved
it's probably academic, but it's worth considering.

Again from the Ubantu forum post:

> Second Input source does nothing. You only record silence if you select
> only the second Input source.

No mention was made of the recording software used.  However, I suspect this
is because the software cannot be told to use the second ADC as its input
source.  Simply enabling the second ADC in alsamixer will not make it the
default ADC of recording software - this actually only unmutes the input to
the second ADC.  The first ADC is always pcm0c while the second is always
pcm1c.  If the software cannot be told to use pcm1c as its source then it
will never be able to record from the second ADC.  This is most likely the
reason why the second ADC couldn't be recorded from since a vast majority
of the audio recording software doesn't allow the source to be changed.

To test the second ADC, the user must get software which allows the capture
device to be changed, and then they must change the capture device within
that application.  Simply unmuting the second capture device in alsamixer 
is not sufficient.

> After I check everything, i'm willing to write a small patch that removes
> all non-working features (like CD and Beep controls) from the current acer
> model and, maybe, adds one or two that are not currently in.

I'm not entirely sure that there are any missing since the test results in
so far indicate that everything's covered.  There might be a corner case
though.

On these Acer laptops the evidence thus far indicates that there is no audio
connection between the CD drive and the sound card.  Therefore the CD
control could possibly be removed, but ONLY from the "acer" model.  The beep
control could be removed from the "acer" model if you like too; leave it
on the fujitsu model at least for the moment.

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

Re: More detailed Acer (Intel HDA)

[Lee Revell]

On Wed, 2006-03-22 at 11:11 +1030, Jonathan Woithe wrote:
> On these Acer laptops the evidence thus far indicates that there is no
> audio connection between the CD drive and the sound card. 

I haven't seen any evidence at all, just speculation, apparently no one
is willing to try Windows to verify this.  Until there's some evidence
IMHO the CD control should stay.

Lee



-------------------------------------------------------
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

Re: More detailed Acer (Intel HDA)

[Jonathan Woithe]

Hi Lee

> On Wed, 2006-03-22 at 11:11 +1030, Jonathan Woithe wrote:
> > On these Acer laptops the evidence thus far indicates that there is no
> > audio connection between the CD drive and the sound card. 
> 
> I haven't seen any evidence at all, just speculation, apparently no one
> is willing to try Windows to verify this.  Until there's some evidence
> IMHO the CD control should stay.

Hmm, perhaps I should have called it "circumstancial evidence".  That's what
I meant.

Anyway, I don't really have strong views either way for the "CD" controls
under the "acer" model - just so long as they are not removed in the
Fujitsu model since they work in those laptops.

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

Re: More detailed Acer (Intel HDA)

[Rimas Kudelis]

Good morning,
>> On these Acer laptops the evidence thus far indicates that there is no
>> audio connection between the CD drive and the sound card. 
>>     
>
> I haven't seen any evidence at all, just speculation, apparently no one
> is willing to try Windows to verify this.  Until there's some evidence
> IMHO the CD control should stay.
The fact is that the CD control doesn't work now. And I didn't manage to 
find a way to make any control in the test model influence CD playback 
volume. Why would you want a non-working control to stay?

I actually wanted to test everything on Windows, and was going to 
install it to my linux swap partition temporarily, but I only had an XP 
compact disc and it said the partition is too small by.... err.... 14 
megabytes... :D, so I didn't install it there.

I thought we've agreed it's impractical to play CD's at 1x speed on a 
notebook, so I don't see a problem at all. However, if somebody would 
test the CD playback in windows with appropriate software on such 
notebook, it would be nice.

Rimas



-------------------------------------------------------
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

Re: More detailed Acer (Intel HDA)

[Lee Revell]

On Wed, 2006-03-22 at 09:22 +0200, Rimas Kudelis wrote:
> Good morning,
> >> On these Acer laptops the evidence thus far indicates that there is no
> >> audio connection between the CD drive and the sound card. 
> >>     
> >
> > I haven't seen any evidence at all, just speculation, apparently no one
> > is willing to try Windows to verify this.  Until there's some evidence
> > IMHO the CD control should stay.
> The fact is that the CD control doesn't work now. And I didn't manage to 
> find a way to make any control in the test model influence CD playback 
> volume. Why would you want a non-working control to stay?
> 

Because it may work on some other laptops, and it's better for people to
be able to test it.

> I actually wanted to test everything on Windows, and was going to 
> install it to my linux swap partition temporarily, but I only had an XP 
> compact disc and it said the partition is too small by.... err.... 14 
> megabytes... :D, so I didn't install it there.
> 
> I thought we've agreed it's impractical to play CD's at 1x speed on a 
> notebook, so I don't see a problem at all. However, if somebody would 
> test the CD playback in windows with appropriate software on such 
> notebook, it would be nice.

That was just speculation on my part about why the vendor may have left
the CD connection disabled, but we don't know that's the case.  Until we
have more information the control should stay.

Lee



-------------------------------------------------------
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

Re: More detailed Acer (Intel HDA)

[Rimas Kudelis]

Hi,
>>>> On these Acer laptops the evidence thus far indicates that there is no
>>>> audio connection between the CD drive and the sound card. 
>>>>         
>>> I haven't seen any evidence at all, just speculation, apparently no one
>>> is willing to try Windows to verify this.  Until there's some evidence
>>> IMHO the CD control should stay.
>>>       
>> The fact is that the CD control doesn't work now. And I didn't manage to 
>> find a way to make any control in the test model influence CD playback 
>> volume. Why would you want a non-working control to stay?
>>     
> Because it may work on some other laptops, and it's better for people to
> be able to test it.
>   
It may or may not work. And people can still use the test model for testing.

>> I actually wanted to test everything on Windows, and was going to 
>> install it to my linux swap partition temporarily, but I only had an XP 
>> compact disc and it said the partition is too small by.... err.... 14 
>> megabytes... :D, so I didn't install it there.
>>
>> I thought we've agreed it's impractical to play CD's at 1x speed on a 
>> notebook, so I don't see a problem at all. However, if somebody would 
>> test the CD playback in windows with appropriate software on such 
>> notebook, it would be nice.
>>     
> That was just speculation on my part about why the vendor may have left
> the CD connection disabled, but we don't know that's the case.  Until we
> have more information the control should stay.
I would report a bug the next day I find it doesn't let me hear the CD 
i'm playing at all. Who would fix it? Because I would not.

OTOH, I just remembered I know one guy who has windows (hopefully, XP) 
on a similar notebook. Maybe he'll test it, if I catch him online. What 
app should he use for that?

Rimas



-------------------------------------------------------
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

Re: More detailed Acer (Intel HDA)

[Lee Revell]

On Wed, 2006-03-22 at 10:48 +0200, Rimas Kudelis wrote:
> OTOH, I just remembered I know one guy who has windows (hopefully,
> XP) 
> on a similar notebook. Maybe he'll test it, if I catch him online.
> What 
> app should he use for that? 

I don't know, anything that lets you play CDs in analog mode.



-------------------------------------------------------
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

Re: More detailed Acer (Intel HDA)

[Lee Revell]

On Wed, 2006-03-22 at 10:48 +0200, Rimas Kudelis wrote:
> Hi,
> >>>> On these Acer laptops the evidence thus far indicates that there is no
> >>>> audio connection between the CD drive and the sound card. 
> >>>>         
> >>> I haven't seen any evidence at all, just speculation, apparently no one
> >>> is willing to try Windows to verify this.  Until there's some evidence
> >>> IMHO the CD control should stay.
> >>>       
> >> The fact is that the CD control doesn't work now. And I didn't manage to 
> >> find a way to make any control in the test model influence CD playback 
> >> volume. Why would you want a non-working control to stay?
> >>     
> > Because it may work on some other laptops, and it's better for people to
> > be able to test it.
> >   
> It may or may not work. And people can still use the test model for testing.
> 

Yes exactly, and a missing control is much worse than a control that
does nothing.

There just needs to be some shred of evidence beyond my speculation
about the CD pins not being connected before controls are removed from a
driver.

Lee 



-------------------------------------------------------
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

Re: More detailed Acer (Intel HDA)

[Rimas Kudelis]

Hi,

>> OTOH, I just remembered I know one guy who has windows (hopefully,
>> XP) 
>> on a similar notebook. Maybe he'll test it, if I catch him online.
>> What 
>> app should he use for that? 
>>     
> I don't know, anything that lets you play CDs in analog mode.
>   
I just talked to him and asked him to test CD playback using Microsoft's 
FlexiCD tray utility (distributed along with Windows 95 Powertoys 
package [1]; I've also put the FlexiCD binary to [2]). The results 
surprise me - it seems like analog CD playback indeed works on Windows. 
Or maybe it's just Windows XP pretending to do analog playback while 
actually playing digitally?

[1] 
http://www.microsoft.com/windows95/downloads/contents/WUToys/W95PwrToysSet/Default.asp
[2] http://jazz.lmta.lt/~rq/pub/flexicd.exe

If you insist, the CD control widgets may be left in the mixer, but I 
can't send a corrected patch today. Can someone else do that? However, I 
really doubt that in the current state it would work for anyone.

Rimas




-------------------------------------------------------
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

Re: More detailed Acer (Intel HDA)

[Rimas Kudelis]

[-- Attachment #1: Type: text/plain, Size: 122 bytes --]

BTW, i've also got the windows mixer screenshots. They're not big, so 
attaching here. Might be interesting to someone.



[-- Attachment #2: recording mixer.png --]
[-- Type: image/png, Size: 6963 bytes --]

[-- Attachment #3: playback mixer.png --]
[-- Type: image/png, Size: 9232 bytes --]

Re: More detailed Acer (Intel HDA)

[Takashi Iwai]

At Wed, 22 Mar 2006 12:55:55 +0200,
Rimas Kudelis wrote:
> 
> Hi,
> 
> >> OTOH, I just remembered I know one guy who has windows (hopefully,
> >> XP) 
> >> on a similar notebook. Maybe he'll test it, if I catch him online.
> >> What 
> >> app should he use for that? 
> >>     
> > I don't know, anything that lets you play CDs in analog mode.
> >   
> I just talked to him and asked him to test CD playback using Microsoft's 
> FlexiCD tray utility (distributed along with Windows 95 Powertoys 
> package [1]; I've also put the FlexiCD binary to [2]). The results 
> surprise me - it seems like analog CD playback indeed works on Windows. 

OK, then let's postpone the merge of your patch until the situation is
clear.


Takashi


-------------------------------------------------------
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

[PATCH] HDA/Realtek: multiple input mux definitions and pin mode additions

[Jonathan Woithe]

Hi everyone

The following patch relative to CVS from 20060324 adds the following
features to the Realtek HDA codec.

1) Define two new pin modes: ALC_PIN_DIR_IN_NOMICBIAS and
   ALC_PIN_DIR_INOUT_NOMICBIAS.  These can be used with jack mode switch
   definitions in mixers to prevent the user being offered the mic bias
   options if the hardware doesn't support it.

2) Add the ability to have different input mux definitions for different
   ADCs.  This is needed because the ALC260 chip uses different mux layouts
   for the two onboard ADCs.  A new field (num_mux_defs) was added to the
   alc_spec and alc_config_preset structures to support this.

3) Adjust numerous comments to make them consistent with the above changes.

4) Utilise the new multi-mux definition functionality for the ALC260 fujitsu
   model to allow recording of the mixer output.

5) Utilise the new multi-mux definition functionality for the ALC260 test
   model to make the mux selections a little less confusing.

6) Allow the headphone jack of the ALC260 acer model to be retasked in
   the mixer.

6) Utilise the new multi-mux definition functionality for the ALC260 acer
   model to give access to the mixer output and the retasked headphone
   jack.

At this stage the *_NOMICBIAS modes are not used.  We have reports that the
"Line" jack of at least some Acer models doesn't pass the bias out, and we
also know that NIDs 0x0f and 0x10 don't seem to accept the mic bias requests
at all.  However, I feel we need to collect more evidence on both counts
before committing to the use of *_NOMICBIAS.  In the case of the Acers, it's
not clear whether this issue (probably caused by the inclusion of DC
blocking capacitors) affects all Acer models or just a small number.  With
the issue with NIDs 0x0f and 0x10 it's unclear whether this is a hardware
bug which will be addressed in later chip revisions or if it's an
intentional restriction.  The datasheet makes no mention of the restriction
so at this stage I'm inclined to consider it a hardware bug.  Comments in
the source reflect this reasoning.

On a similar theme, the headphone jack of the Fujitsu S7020 also doesn't
appear to pass mic bias voltage.  I'm still investigating this however.

With the ability to retask the headphone jack, owners of ALC260-based Acer
laptops should now be able to record 4 channels of audio if they desire. The
multiple mux definitions allow this jack to be presented from both ADCs
(since this mux input is one of those which differs between the muxes).

This patch has been tested on a Fujitsu S7020 laptop and appears to behave
itself both for the "test" and "fujitsu" models.  Definitions using only a
single mux specification also work.  Other ALC chips should be fine but I
cannot test these myself.  The "auto" modes should also continue to function
but again I have not verified this.

I apologise that this patch does so much (although note that a majority
of the patch is consumed by comment revision).  The major problem was that
many of these changes were inter-related and the changes were done in an
order which did not facilitate sensible splitting of the patch.  If this
is a problem let me know and I'll try to split it up, but it could be fiddly.

Regards
  jonathan

--- patch_realtek.c-orig	2006-03-24 16:49:31.000000000 +1030
+++ patch_realtek.c	2006-03-26 21:53:03.000000000 +0930
@@ -132,6 +132,7 @@
 	hda_nid_t dig_in_nid;		/* digital-in NID; optional */
 
 	/* capture source */
+	unsigned int num_mux_defs;
 	const struct hda_input_mux *input_mux;
 	unsigned int cur_mux[3];
 
@@ -173,6 +174,7 @@
 	hda_nid_t dig_in_nid;
 	unsigned int num_channel_mode;
 	const struct hda_channel_mode *channel_mode;
+	unsigned int num_mux_defs;
 	const struct hda_input_mux *input_mux;
 	void (*unsol_event)(struct hda_codec *, unsigned int);
 	void (*init_hook)(struct hda_codec *);
@@ -186,7 +188,10 @@
 {
 	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
 	struct alc_spec *spec = codec->spec;
-	return snd_hda_input_mux_info(spec->input_mux, uinfo);
+	unsigned int mux_idx = snd_ctl_get_ioffidx(kcontrol, &uinfo->id);
+	if (mux_idx >= spec->num_mux_defs)
+		mux_idx = 0;
+	return snd_hda_input_mux_info(&spec->input_mux[mux_idx], uinfo);
 }
 
 static int alc_mux_enum_get(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol)
@@ -204,7 +209,8 @@
 	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
 	struct alc_spec *spec = codec->spec;
 	unsigned int adc_idx = snd_ctl_get_ioffidx(kcontrol, &ucontrol->id);
-	return snd_hda_input_mux_put(codec, spec->input_mux, ucontrol,
+	unsigned int mux_idx = (adc_idx>=spec->num_mux_defs?0:adc_idx);
+	return snd_hda_input_mux_put(codec, &spec->input_mux[mux_idx], ucontrol,
 				     spec->adc_nids[adc_idx], &spec->cur_mux[adc_idx]);
 }
 
@@ -246,7 +252,8 @@
  * states other than HiZ (eg: PIN_VREFxx) and revert to HiZ if any of these
  * are requested.  Therefore order this list so that this behaviour will not
  * cause problems when mixer clients move through the enum sequentially.
- * NIDs 0x0f and 0x10 have been observed to have this behaviour.
+ * NIDs 0x0f and 0x10 have been observed to have this behaviour as of
+ * March 2006.
  */
 static char *alc_pin_mode_names[] = {
 	"Mic 50pc bias", "Mic 80pc bias",
@@ -256,19 +263,27 @@
 	PIN_VREF50, PIN_VREF80, PIN_IN, PIN_OUT, PIN_HP,
 };
 /* The control can present all 5 options, or it can limit the options based
- * in the pin being assumed to be exclusively an input or an output pin.
- */
-#define ALC_PIN_DIR_IN    0x00
-#define ALC_PIN_DIR_OUT   0x01
-#define ALC_PIN_DIR_INOUT 0x02
+ * in the pin being assumed to be exclusively an input or an output pin.  In
+ * addition, "input" pins may or may not process the mic bias option
+ * depending on actual widget capability (NIDs 0x0f and 0x10 don't seem to
+ * accept requests for bias as of chip versions up to March 2006) and/or
+ * wiring in the computer.
+ */
+#define ALC_PIN_DIR_IN              0x00
+#define ALC_PIN_DIR_OUT             0x01
+#define ALC_PIN_DIR_INOUT           0x02
+#define ALC_PIN_DIR_IN_NOMICBIAS    0x03
+#define ALC_PIN_DIR_INOUT_NOMICBIAS 0x04
 
-/* Info about the pin modes supported by the three different pin directions. 
+/* Info about the pin modes supported by the different pin direction modes. 
  * For each direction the minimum and maximum values are given.
  */
-static signed char alc_pin_mode_dir_info[3][2] = {
+static signed char alc_pin_mode_dir_info[5][2] = {
 	{ 0, 2 },    /* ALC_PIN_DIR_IN */
 	{ 3, 4 },    /* ALC_PIN_DIR_OUT */
 	{ 0, 4 },    /* ALC_PIN_DIR_INOUT */
+	{ 2, 2 },    /* ALC_PIN_DIR_IN_NOMICBIAS */
+	{ 2, 4 },    /* ALC_PIN_DIR_INOUT_NOMICBIAS */
 };
 #define alc_pin_mode_min(_dir) (alc_pin_mode_dir_info[_dir][0])
 #define alc_pin_mode_max(_dir) (alc_pin_mode_dir_info[_dir][1])
@@ -330,9 +345,10 @@
 		 * input modes.
 		 *
 		 * Dynamically switching the input/output buffers probably
-		 * reduces noise slightly, particularly on input.  However,
-		 * havingboth input and output buffers enabled
-		 * simultaneously doesn't seem to be problematic.
+		 * reduces noise slightly (particularly on input) so we'll
+		 * do it.  However, having both input and output buffers
+		 * enabled simultaneously doesn't seem to be problematic if
+		 * this turns out to be necessary in the future.
 		 */
 		if (val <= 2) {
 			snd_hda_codec_write(codec,nid,0,AC_VERB_SET_AMP_GAIN_MUTE,
@@ -484,6 +500,7 @@
 	spec->multiout.dig_out_nid = preset->dig_out_nid;
 	spec->multiout.hp_nid = preset->hp_nid;
 	
+	spec->num_mux_defs = preset->num_mux_defs;
 	spec->input_mux = preset->input_mux;
 
 	spec->num_adc_nids = preset->num_adc_nids;
@@ -2177,6 +2194,7 @@
 		.dac_nids = alc880_dac_nids,
 		.num_channel_mode = ARRAY_SIZE(alc880_threestack_modes),
 		.channel_mode = alc880_threestack_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc880_capture_source,
 	},
 	[ALC880_3ST_DIG] = {
@@ -2187,6 +2205,7 @@
 		.dig_out_nid = ALC880_DIGOUT_NID,
 		.num_channel_mode = ARRAY_SIZE(alc880_threestack_modes),
 		.channel_mode = alc880_threestack_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc880_capture_source,
 	},
 	[ALC880_TCL_S700] = {
@@ -2199,6 +2218,7 @@
 		.hp_nid = 0x03,
 		.num_channel_mode = ARRAY_SIZE(alc880_2_jack_modes),
 		.channel_mode = alc880_2_jack_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc880_capture_source,
 	},
 	[ALC880_5ST] = {
@@ -2208,6 +2228,7 @@
 		.dac_nids = alc880_dac_nids,
 		.num_channel_mode = ARRAY_SIZE(alc880_fivestack_modes),
 		.channel_mode = alc880_fivestack_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc880_capture_source,
 	},
 	[ALC880_5ST_DIG] = {
@@ -2218,6 +2239,7 @@
 		.dig_out_nid = ALC880_DIGOUT_NID,
 		.num_channel_mode = ARRAY_SIZE(alc880_fivestack_modes),
 		.channel_mode = alc880_fivestack_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc880_capture_source,
 	},
 	[ALC880_6ST] = {
@@ -2227,6 +2249,7 @@
 		.dac_nids = alc880_6st_dac_nids,
 		.num_channel_mode = ARRAY_SIZE(alc880_sixstack_modes),
 		.channel_mode = alc880_sixstack_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc880_6stack_capture_source,
 	},
 	[ALC880_6ST_DIG] = {
@@ -2237,6 +2260,7 @@
 		.dig_out_nid = ALC880_DIGOUT_NID,
 		.num_channel_mode = ARRAY_SIZE(alc880_sixstack_modes),
 		.channel_mode = alc880_sixstack_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc880_6stack_capture_source,
 	},
 	[ALC880_W810] = {
@@ -2248,6 +2272,7 @@
 		.dig_out_nid = ALC880_DIGOUT_NID,
 		.num_channel_mode = ARRAY_SIZE(alc880_w810_modes),
 		.channel_mode = alc880_w810_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc880_capture_source,
 	},
 	[ALC880_Z71V] = {
@@ -2259,6 +2284,7 @@
 		.hp_nid = 0x03,
 		.num_channel_mode = ARRAY_SIZE(alc880_2_jack_modes),
 		.channel_mode = alc880_2_jack_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc880_capture_source,
 	},
 	[ALC880_F1734] = {
@@ -2269,6 +2295,7 @@
 		.hp_nid = 0x02,
 		.num_channel_mode = ARRAY_SIZE(alc880_2_jack_modes),
 		.channel_mode = alc880_2_jack_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc880_capture_source,
 	},
 	[ALC880_ASUS] = {
@@ -2279,6 +2306,7 @@
 		.dac_nids = alc880_asus_dac_nids,
 		.num_channel_mode = ARRAY_SIZE(alc880_asus_modes),
 		.channel_mode = alc880_asus_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc880_capture_source,
 	},
 	[ALC880_ASUS_DIG] = {
@@ -2290,6 +2318,7 @@
 		.dig_out_nid = ALC880_DIGOUT_NID,
 		.num_channel_mode = ARRAY_SIZE(alc880_asus_modes),
 		.channel_mode = alc880_asus_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc880_capture_source,
 	},
 	[ALC880_ASUS_DIG2] = {
@@ -2301,6 +2330,7 @@
 		.dig_out_nid = ALC880_DIGOUT_NID,
 		.num_channel_mode = ARRAY_SIZE(alc880_asus_modes),
 		.channel_mode = alc880_asus_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc880_capture_source,
 	},
 	[ALC880_ASUS_W1V] = {
@@ -2312,6 +2342,7 @@
 		.dig_out_nid = ALC880_DIGOUT_NID,
 		.num_channel_mode = ARRAY_SIZE(alc880_asus_modes),
 		.channel_mode = alc880_asus_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc880_capture_source,
 	},
 	[ALC880_UNIWILL_DIG] = {
@@ -2322,6 +2353,7 @@
 		.dig_out_nid = ALC880_DIGOUT_NID,
 		.num_channel_mode = ARRAY_SIZE(alc880_asus_modes),
 		.channel_mode = alc880_asus_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc880_capture_source,
 	},
 	[ALC880_CLEVO] = {
@@ -2333,6 +2365,7 @@
 		.hp_nid = 0x03,
 		.num_channel_mode = ARRAY_SIZE(alc880_threestack_modes),
 		.channel_mode = alc880_threestack_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc880_capture_source,
 	},
 	[ALC880_LG] = {
@@ -2344,6 +2377,7 @@
 		.dig_out_nid = ALC880_DIGOUT_NID,
 		.num_channel_mode = ARRAY_SIZE(alc880_lg_ch_modes),
 		.channel_mode = alc880_lg_ch_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc880_lg_capture_source,
 		.unsol_event = alc880_lg_unsol_event,
 		.init_hook = alc880_lg_automute,
@@ -2357,6 +2391,7 @@
 		.dig_out_nid = ALC880_DIGOUT_NID,
 		.num_channel_mode = ARRAY_SIZE(alc880_2_jack_modes),
 		.channel_mode = alc880_2_jack_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc880_lg_lw_capture_source,
 		.unsol_event = alc880_lg_lw_unsol_event,
 		.init_hook = alc880_lg_lw_automute,
@@ -2370,6 +2405,7 @@
 		.dig_out_nid = ALC880_DIGOUT_NID,
 		.num_channel_mode = ARRAY_SIZE(alc880_test_modes),
 		.channel_mode = alc880_test_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc880_test_capture_source,
 	},
 #endif
@@ -2686,6 +2722,7 @@
 
 	spec->init_verbs[spec->num_init_verbs++] = alc880_volume_init_verbs;
 
+	spec->num_mux_defs = 1;
 	spec->input_mux = &spec->private_imux;
 
 	return 1;
@@ -2815,30 +2852,56 @@
 };
 
 /* On Fujitsu S702x laptops capture only makes sense from Mic/LineIn jack,
- * headphone jack and the internal CD lines.
+ * headphone jack and the internal CD lines since these are the only pins at
+ * which audio can appear.  For flexibility, also allow the option of
+ * recording the mixer output on the second ADC (ADC0 doesn't have a
+ * connection to the mixer output).
  */
-static struct hda_input_mux alc260_fujitsu_capture_source = {
-	.num_items = 3,
-	.items = {
-		{ "Mic/Line", 0x0 },
-		{ "CD", 0x4 },
-		{ "Headphone", 0x2 },
+static struct hda_input_mux alc260_fujitsu_capture_sources[2] = {
+	{
+		.num_items = 3,
+		.items = {
+			{ "Mic/Line", 0x0 },
+			{ "CD", 0x4 },
+			{ "Headphone", 0x2 },
+		},
+	},
+	{
+		.num_items = 4,
+		.items = {
+			{ "Mic/Line", 0x0 },
+			{ "CD", 0x4 },
+			{ "Headphone", 0x2 },
+			{ "Mixer", 0x5 },
+		},
 	},
+
 };
 
-/* Acer TravelMate(/Extensa/Aspire) notebooks have similar configutation to
- * the Fujitsu S702x, but jacks are marked differently. We won't allow
- * retasking the Headphone jack, so it won't be available here.
+/* Acer TravelMate(/Extensa/Aspire) notebooks have similar configuration to
+ * the Fujitsu S702x, but jacks are marked differently.
  */
-static struct hda_input_mux alc260_acer_capture_source = {
-	.num_items = 3,
-	.items = {
-		{ "Mic", 0x0 },
-		{ "Line", 0x2 },
-		{ "CD", 0x4 },
+static struct hda_input_mux alc260_acer_capture_sources[2] = {
+	{
+		.num_items = 4,
+		.items = {
+			{ "Mic", 0x0 },
+			{ "Line", 0x2 },
+			{ "CD", 0x4 },
+			{ "Headphone", 0x5 },
+		},
+	},
+	{
+		.num_items = 5,
+		.items = {
+			{ "Mic", 0x0 },
+			{ "Line", 0x2 },
+			{ "CD", 0x4 },
+			{ "Headphone", 0x6 },
+			{ "Mixer", 0x5 },
+		},
 	},
 };
-
 /*
  * This is just place-holder, so there's something for alc_build_pcms to look
  * at when it calculates the maximum number of channels. ALC260 has no mixer
@@ -2899,6 +2962,9 @@
 	{ } /* end */
 };
 
+/* Fujitsu S702x series laptops.  ALC260 pin usage: Mic/Line jack = 0x12, 
+ * HP jack = 0x14, CD audio =  0x16, internal speaker = 0x10.
+ */
 static struct snd_kcontrol_new alc260_fujitsu_mixer[] = {
 	HDA_CODEC_VOLUME("Headphone Playback Volume", 0x08, 0x0, HDA_OUTPUT),
 	HDA_BIND_MUTE("Headphone Playback Switch", 0x08, 2, HDA_INPUT),
@@ -2915,9 +2981,28 @@
 	{ } /* end */
 };
 
+/* Mixer for Acer TravelMate(/Extensa/Aspire) notebooks.  Note that current
+ * versions of the ALC260 don't act on requests to enable mic bias from NID
+ * 0x0f (used to drive the headphone jack in these laptops).  The ALC260
+ * datasheet doesn't mention this restriction.  At this stage it's not clear
+ * whether this behaviour is intentional or is a hardware bug in chip
+ * revisions available in early 2006.  Therefore for now allow the
+ * "Headphone Jack Mode" control to span all choices, but if it turns out
+ * that the lack of mic bias for this NID is intentional we could change the
+ * mode from ALC_PIN_DIR_INOUT to ALC_PIN_DIR_INOUT_NOMICBIAS.
+ *
+ * In addition, Acer TravelMate(/Extensa/Aspire) notebooks in early 2006
+ * don't appear to make the mic bias available from the "line" jack, even
+ * though the NID used for this jack (0x14) can supply it.  The theory is
+ * that perhaps Acer have included blocking capacitors between the ALC260
+ * and the output jack.  If this turns out to be the case for all such
+ * models the "Line Jack Mode" mode could be changed from ALC_PIN_DIR_INOUT
+ * to ALC_PIN_DIR_INOUT_NOMICBIAS.
+ */
 static struct snd_kcontrol_new alc260_acer_mixer[] = {
 	HDA_CODEC_VOLUME("Master Playback Volume", 0x08, 0x0, HDA_OUTPUT),
 	HDA_BIND_MUTE("Master Playback Switch", 0x08, 2, HDA_INPUT),
+	ALC_PIN_MODE("Headphone Jack Mode", 0x0f, ALC_PIN_DIR_INOUT),
 	HDA_CODEC_VOLUME("CD Playback Volume", 0x07, 0x04, HDA_INPUT),
 	HDA_CODEC_MUTE("CD Playback Switch", 0x07, 0x04, HDA_INPUT),
 	HDA_CODEC_VOLUME("Mic Playback Volume", 0x07, 0x0, HDA_INPUT),
@@ -3131,7 +3216,8 @@
 };
 
 /* Initialisation sequence for ALC260 as configured in Fujitsu S702x
- * laptops.
+ * laptops.  ALC260 pin usage: Mic/Line jack = 0x12, HP jack = 0x14, CD
+ * audio = 0x16, internal speaker = 0x10.
  */
 static struct hda_verb alc260_fujitsu_init_verbs[] = {
 	/* Disable all GPIOs */
@@ -3278,10 +3364,10 @@
 	{0x04, AC_VERB_SET_CONNECT_SEL, 0x00},
 
 	/* Do similar with the second ADC: mute capture input amp and
-	 * set ADC connection to line (on line1 pin)
+	 * set ADC connection to mic to match ALSA's default state.
 	 */
 	{0x05, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)},
-	{0x05, AC_VERB_SET_CONNECT_SEL, 0x02},
+	{0x05, AC_VERB_SET_CONNECT_SEL, 0x00},
 
 	/* Mute all inputs to mixer widget (even unconnected ones) */
 	{0x07, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)}, /* mic1 pin */
@@ -3306,26 +3392,35 @@
 static hda_nid_t alc260_test_adc_nids[2] = {
 	0x04, 0x05,
 };
-/* This is a bit messy since the two input muxes in the ALC260 have slight
- * variations in their signal assignments.  The ideal way to deal with this
- * is to extend alc_spec.input_mux to allow a different input MUX for each
- * ADC.  For the purposes of the test model it's sufficient to just list
- * both options for affected signal indices.  The separate input mux
- * functionality only needs to be considered if a model comes along which
- * actually uses signals 0x5, 0x6 and 0x7 for something which makes sense to
- * record.
+/* For testing the ALC260, each input MUX needs its own definition since
+ * the signal assignments are different.  This assumes that the first ADC 
+ * is NID 0x04.
  */
-static struct hda_input_mux alc260_test_capture_source = {
-	.num_items = 8,
-	.items = {
-		{ "MIC1 pin", 0x0 },
-		{ "MIC2 pin", 0x1 },
-		{ "LINE1 pin", 0x2 },
-		{ "LINE2 pin", 0x3 },
-		{ "CD pin", 0x4 },
-		{ "LINE-OUT pin (cap1), Mixer (cap2)", 0x5 },
-		{ "HP-OUT pin (cap1), LINE-OUT pin (cap2)", 0x6 },
-		{ "HP-OUT pin (cap2 only)", 0x7 },
+static struct hda_input_mux alc260_test_capture_sources[2] = {
+	{
+		.num_items = 7,
+		.items = {
+			{ "MIC1 pin", 0x0 },
+			{ "MIC2 pin", 0x1 },
+			{ "LINE1 pin", 0x2 },
+			{ "LINE2 pin", 0x3 },
+			{ "CD pin", 0x4 },
+			{ "LINE-OUT pin", 0x5 },
+			{ "HP-OUT pin", 0x6 },
+		},
+        },
+	{
+		.num_items = 8,
+		.items = {
+			{ "MIC1 pin", 0x0 },
+			{ "MIC2 pin", 0x1 },
+			{ "LINE1 pin", 0x2 },
+			{ "LINE2 pin", 0x3 },
+			{ "CD pin", 0x4 },
+			{ "Mixer", 0x5 },
+			{ "LINE-OUT pin", 0x6 },
+			{ "HP-OUT pin", 0x7 },
+		},
         },
 };
 static struct snd_kcontrol_new alc260_test_mixer[] = {
@@ -3337,7 +3432,17 @@
 	HDA_CODEC_VOLUME("LOUT1 Playback Volume", 0x08, 0x0, HDA_OUTPUT),
 	HDA_BIND_MUTE("LOUT1 Playback Switch", 0x08, 2, HDA_INPUT),
 
-	/* Modes for retasking pin widgets */
+	/* Modes for retasking pin widgets
+	 * Note: the ALC260 doesn't seem to act on requests to enable mic
+         * bias from NIDs 0x0f and 0x10.  The ALC260 datasheet doesn't
+         * mention this restriction.  At this stage it's not clear whether
+         * this behaviour is intentional or is a hardware bug in chip
+         * revisions available at least up until early 2006.  Therefore for
+         * now allow the "HP-OUT" and "LINE-OUT" Mode controls to span all
+         * choices, but if it turns out that the lack of mic bias for these
+         * NIDs is intentional we could change their modes from
+         * ALC_PIN_DIR_INOUT to ALC_PIN_DIR_INOUT_NOMICBIAS.
+	 */
 	ALC_PIN_MODE("HP-OUT pin mode", 0x10, ALC_PIN_DIR_INOUT),
 	ALC_PIN_MODE("LINE-OUT pin mode", 0x0f, ALC_PIN_DIR_INOUT),
 	ALC_PIN_MODE("LINE2 pin mode", 0x15, ALC_PIN_DIR_INOUT),
@@ -3699,6 +3804,7 @@
 
 	spec->init_verbs[spec->num_init_verbs++] = alc260_volume_init_verbs;
 
+	spec->num_mux_defs = 1;
 	spec->input_mux = &spec->private_imux;
 
 	/* check whether NID 0x04 is valid */
@@ -3766,6 +3872,7 @@
 		.adc_nids = alc260_adc_nids,
 		.num_channel_mode = ARRAY_SIZE(alc260_modes),
 		.channel_mode = alc260_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc260_capture_source,
 	},
 	[ALC260_HP] = {
@@ -3779,6 +3886,7 @@
 		.adc_nids = alc260_hp_adc_nids,
 		.num_channel_mode = ARRAY_SIZE(alc260_modes),
 		.channel_mode = alc260_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc260_capture_source,
 	},
 	[ALC260_HP_3013] = {
@@ -3792,6 +3900,7 @@
 		.adc_nids = alc260_hp_adc_nids,
 		.num_channel_mode = ARRAY_SIZE(alc260_modes),
 		.channel_mode = alc260_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc260_capture_source,
 	},
 	[ALC260_FUJITSU_S702X] = {
@@ -3804,7 +3913,8 @@
 		.adc_nids = alc260_dual_adc_nids,
 		.num_channel_mode = ARRAY_SIZE(alc260_modes),
 		.channel_mode = alc260_modes,
-		.input_mux = &alc260_fujitsu_capture_source,
+		.num_mux_defs = ARRAY_SIZE(alc260_fujitsu_capture_sources),
+		.input_mux = alc260_fujitsu_capture_sources,
 	},
 	[ALC260_ACER] = {
 		.mixers = { alc260_acer_mixer,
@@ -3816,7 +3926,8 @@
 		.adc_nids = alc260_dual_adc_nids,
 		.num_channel_mode = ARRAY_SIZE(alc260_modes),
 		.channel_mode = alc260_modes,
-		.input_mux = &alc260_acer_capture_source,
+		.num_mux_defs = ARRAY_SIZE(alc260_acer_capture_sources),
+		.input_mux = alc260_acer_capture_sources,
 	},
 #ifdef CONFIG_SND_DEBUG
 	[ALC260_TEST] = {
@@ -3829,7 +3940,8 @@
 		.adc_nids = alc260_test_adc_nids,
 		.num_channel_mode = ARRAY_SIZE(alc260_modes),
 		.channel_mode = alc260_modes,
-		.input_mux = &alc260_test_capture_source,
+		.num_mux_defs = ARRAY_SIZE(alc260_test_capture_sources),
+		.input_mux = alc260_test_capture_sources,
 	},
 #endif
 };
@@ -3921,7 +4033,6 @@
 		{ "CD", 0x4 },
 	},
 };
-
 #define alc882_mux_enum_info alc_mux_enum_info
 #define alc882_mux_enum_get alc_mux_enum_get
 
@@ -4255,6 +4366,7 @@
 		.dig_in_nid = ALC882_DIGIN_NID,
 		.num_channel_mode = ARRAY_SIZE(alc882_ch_modes),
 		.channel_mode = alc882_ch_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc882_capture_source,
 	},
 	[ALC882_6ST_DIG] = {
@@ -4268,6 +4380,7 @@
 		.dig_in_nid = ALC882_DIGIN_NID,
 		.num_channel_mode = ARRAY_SIZE(alc882_sixstack_modes),
 		.channel_mode = alc882_sixstack_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc882_capture_source,
 	},
 };
@@ -4823,6 +4936,7 @@
 		spec->mixers[spec->num_mixers++] = spec->kctl_alloc;
 
 	spec->init_verbs[spec->num_init_verbs++] = alc262_volume_init_verbs;
+	spec->num_mux_defs = 1;
 	spec->input_mux = &spec->private_imux;
 
 	return 1;
@@ -4861,6 +4975,7 @@
 		.hp_nid = 0x03,
 		.num_channel_mode = ARRAY_SIZE(alc262_modes),
 		.channel_mode = alc262_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc262_capture_source,
 	},
 	[ALC262_FUJITSU] = {
@@ -4872,6 +4987,7 @@
 		.dig_out_nid = ALC262_DIGOUT_NID,
 		.num_channel_mode = ARRAY_SIZE(alc262_modes),
 		.channel_mode = alc262_modes,
+		.num_mux_defs = 1,
 		.input_mux = &alc262_fujitsu_capture_source,
 		.unsol_event = alc262_fujitsu_unsol_event,
 	},
@@ -5499,6 +5615,7 @@
 
 	spec->init_verbs[spec->num_init_verbs++] = alc861_auto_init_verbs;
 
+	spec->num_mux_defs = 1;
 	spec->input_mux = &spec->private_imux;
 
 	spec->adc_nids = alc861_adc_nids;
@@ -5540,6 +5657,7 @@
 		.channel_mode = alc861_threestack_modes,
 		.num_adc_nids = ARRAY_SIZE(alc861_adc_nids),
 		.adc_nids = alc861_adc_nids,
+		.num_mux_defs = 1,
 		.input_mux = &alc861_capture_source,
 	},
 	[ALC861_3ST_DIG] = {
@@ -5552,6 +5670,7 @@
 		.channel_mode = alc861_threestack_modes,
 		.num_adc_nids = ARRAY_SIZE(alc861_adc_nids),
 		.adc_nids = alc861_adc_nids,
+		.num_mux_defs = 1,
 		.input_mux = &alc861_capture_source,
 	},
 	[ALC861_6ST_DIG] = {
@@ -5564,6 +5683,7 @@
 		.channel_mode = alc861_8ch_modes,
 		.num_adc_nids = ARRAY_SIZE(alc861_adc_nids),
 		.adc_nids = alc861_adc_nids,
+		.num_mux_defs = 1,
 		.input_mux = &alc861_capture_source,
 	},
 };	


-------------------------------------------------------
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

Re: [PATCH] HDA/Realtek: multiple input mux definitions and pin mode additions

[Takashi Iwai]

At Mon, 27 Mar 2006 09:06:43 +0930 (CST),
Jonathan Woithe wrote:
> 
> Hi everyone
> 
> The following patch relative to CVS from 20060324 adds the following
> features to the Realtek HDA codec.
> 
> 1) Define two new pin modes: ALC_PIN_DIR_IN_NOMICBIAS and
>    ALC_PIN_DIR_INOUT_NOMICBIAS.  These can be used with jack mode switch
>    definitions in mixers to prevent the user being offered the mic bias
>    options if the hardware doesn't support it.
> 
> 2) Add the ability to have different input mux definitions for different
>    ADCs.  This is needed because the ALC260 chip uses different mux layouts
>    for the two onboard ADCs.  A new field (num_mux_defs) was added to the
>    alc_spec and alc_config_preset structures to support this.

I'd use num_mux_defs = 0 as if = 1 if input_mux is defined.
Then we don't have to patch all over places (and avoid carelessness).

Otherwise the patch looks OK.  Could you fix the above and repost?
I'd like to put this into 1.0.11-final, too.


Thanks,

Takashi


-------------------------------------------------------
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

Re: [PATCH] HDA/Realtek: multiple input mux definitions and pin mode additions

[Jonathan Woithe]

Hi Takashi

> > The following patch relative to CVS from 20060324 adds the following
> > features to the Realtek HDA codec.
> > 
> > 1) Define two new pin modes: ALC_PIN_DIR_IN_NOMICBIAS and
> >    ALC_PIN_DIR_INOUT_NOMICBIAS.  These can be used with jack mode switch
> >    definitions in mixers to prevent the user being offered the mic bias
> >    options if the hardware doesn't support it.
> > 
> > 2) Add the ability to have different input mux definitions for different
> >    ADCs.  This is needed because the ALC260 chip uses different mux layouts
> >    for the two onboard ADCs.  A new field (num_mux_defs) was added to the
> >    alc_spec and alc_config_preset structures to support this.
> 
> I'd use num_mux_defs = 0 as if = 1 if input_mux is defined.
> Then we don't have to patch all over places (and avoid carelessness).
> 
> Otherwise the patch looks OK.  Could you fix the above and repost?
> I'd like to put this into 1.0.11-final, too.

The original patch would do the right thing with num_mux_defs = 0.  The
attached revised patch simply removes the unnecessary initialisation of
num_mux_defs in the presets.  This is untested since I don't have the laptop
with me at present, but given the trivial nature of the change I don't
foresee a problem.

I've left the initialisations in the alc*_parse_auto_config() functions for
the moment since it's not clear to me that it will otherwise be initialised
to something sensible in this context.

Regards
  jonathan

--- patch_realtek.c-orig	2006-03-24 16:49:31.000000000 +1030
+++ patch_realtek.c	2006-03-28 09:03:39.000000000 +0930
@@ -132,6 +132,7 @@
 	hda_nid_t dig_in_nid;		/* digital-in NID; optional */
 
 	/* capture source */
+	unsigned int num_mux_defs;
 	const struct hda_input_mux *input_mux;
 	unsigned int cur_mux[3];
 
@@ -173,6 +174,7 @@
 	hda_nid_t dig_in_nid;
 	unsigned int num_channel_mode;
 	const struct hda_channel_mode *channel_mode;
+	unsigned int num_mux_defs;
 	const struct hda_input_mux *input_mux;
 	void (*unsol_event)(struct hda_codec *, unsigned int);
 	void (*init_hook)(struct hda_codec *);
@@ -186,7 +188,10 @@
 {
 	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
 	struct alc_spec *spec = codec->spec;
-	return snd_hda_input_mux_info(spec->input_mux, uinfo);
+	unsigned int mux_idx = snd_ctl_get_ioffidx(kcontrol, &uinfo->id);
+	if (mux_idx >= spec->num_mux_defs)
+		mux_idx = 0;
+	return snd_hda_input_mux_info(&spec->input_mux[mux_idx], uinfo);
 }
 
 static int alc_mux_enum_get(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol)
@@ -204,7 +209,8 @@
 	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
 	struct alc_spec *spec = codec->spec;
 	unsigned int adc_idx = snd_ctl_get_ioffidx(kcontrol, &ucontrol->id);
-	return snd_hda_input_mux_put(codec, spec->input_mux, ucontrol,
+	unsigned int mux_idx = (adc_idx>=spec->num_mux_defs?0:adc_idx);
+	return snd_hda_input_mux_put(codec, &spec->input_mux[mux_idx], ucontrol,
 				     spec->adc_nids[adc_idx], &spec->cur_mux[adc_idx]);
 }
 
@@ -246,7 +252,8 @@
  * states other than HiZ (eg: PIN_VREFxx) and revert to HiZ if any of these
  * are requested.  Therefore order this list so that this behaviour will not
  * cause problems when mixer clients move through the enum sequentially.
- * NIDs 0x0f and 0x10 have been observed to have this behaviour.
+ * NIDs 0x0f and 0x10 have been observed to have this behaviour as of
+ * March 2006.
  */
 static char *alc_pin_mode_names[] = {
 	"Mic 50pc bias", "Mic 80pc bias",
@@ -256,19 +263,27 @@
 	PIN_VREF50, PIN_VREF80, PIN_IN, PIN_OUT, PIN_HP,
 };
 /* The control can present all 5 options, or it can limit the options based
- * in the pin being assumed to be exclusively an input or an output pin.
- */
-#define ALC_PIN_DIR_IN    0x00
-#define ALC_PIN_DIR_OUT   0x01
-#define ALC_PIN_DIR_INOUT 0x02
+ * in the pin being assumed to be exclusively an input or an output pin.  In
+ * addition, "input" pins may or may not process the mic bias option
+ * depending on actual widget capability (NIDs 0x0f and 0x10 don't seem to
+ * accept requests for bias as of chip versions up to March 2006) and/or
+ * wiring in the computer.
+ */
+#define ALC_PIN_DIR_IN              0x00
+#define ALC_PIN_DIR_OUT             0x01
+#define ALC_PIN_DIR_INOUT           0x02
+#define ALC_PIN_DIR_IN_NOMICBIAS    0x03
+#define ALC_PIN_DIR_INOUT_NOMICBIAS 0x04
 
-/* Info about the pin modes supported by the three different pin directions. 
+/* Info about the pin modes supported by the different pin direction modes. 
  * For each direction the minimum and maximum values are given.
  */
-static signed char alc_pin_mode_dir_info[3][2] = {
+static signed char alc_pin_mode_dir_info[5][2] = {
 	{ 0, 2 },    /* ALC_PIN_DIR_IN */
 	{ 3, 4 },    /* ALC_PIN_DIR_OUT */
 	{ 0, 4 },    /* ALC_PIN_DIR_INOUT */
+	{ 2, 2 },    /* ALC_PIN_DIR_IN_NOMICBIAS */
+	{ 2, 4 },    /* ALC_PIN_DIR_INOUT_NOMICBIAS */
 };
 #define alc_pin_mode_min(_dir) (alc_pin_mode_dir_info[_dir][0])
 #define alc_pin_mode_max(_dir) (alc_pin_mode_dir_info[_dir][1])
@@ -330,9 +345,10 @@
 		 * input modes.
 		 *
 		 * Dynamically switching the input/output buffers probably
-		 * reduces noise slightly, particularly on input.  However,
-		 * havingboth input and output buffers enabled
-		 * simultaneously doesn't seem to be problematic.
+		 * reduces noise slightly (particularly on input) so we'll
+		 * do it.  However, having both input and output buffers
+		 * enabled simultaneously doesn't seem to be problematic if
+		 * this turns out to be necessary in the future.
 		 */
 		if (val <= 2) {
 			snd_hda_codec_write(codec,nid,0,AC_VERB_SET_AMP_GAIN_MUTE,
@@ -484,6 +500,7 @@
 	spec->multiout.dig_out_nid = preset->dig_out_nid;
 	spec->multiout.hp_nid = preset->hp_nid;
 	
+	spec->num_mux_defs = preset->num_mux_defs;
 	spec->input_mux = preset->input_mux;
 
 	spec->num_adc_nids = preset->num_adc_nids;
@@ -2686,6 +2703,7 @@
 
 	spec->init_verbs[spec->num_init_verbs++] = alc880_volume_init_verbs;
 
+	spec->num_mux_defs = 1;
 	spec->input_mux = &spec->private_imux;
 
 	return 1;
@@ -2815,30 +2833,56 @@
 };
 
 /* On Fujitsu S702x laptops capture only makes sense from Mic/LineIn jack,
- * headphone jack and the internal CD lines.
+ * headphone jack and the internal CD lines since these are the only pins at
+ * which audio can appear.  For flexibility, also allow the option of
+ * recording the mixer output on the second ADC (ADC0 doesn't have a
+ * connection to the mixer output).
  */
-static struct hda_input_mux alc260_fujitsu_capture_source = {
-	.num_items = 3,
-	.items = {
-		{ "Mic/Line", 0x0 },
-		{ "CD", 0x4 },
-		{ "Headphone", 0x2 },
+static struct hda_input_mux alc260_fujitsu_capture_sources[2] = {
+	{
+		.num_items = 3,
+		.items = {
+			{ "Mic/Line", 0x0 },
+			{ "CD", 0x4 },
+			{ "Headphone", 0x2 },
+		},
+	},
+	{
+		.num_items = 4,
+		.items = {
+			{ "Mic/Line", 0x0 },
+			{ "CD", 0x4 },
+			{ "Headphone", 0x2 },
+			{ "Mixer", 0x5 },
+		},
 	},
+
 };
 
-/* Acer TravelMate(/Extensa/Aspire) notebooks have similar configutation to
- * the Fujitsu S702x, but jacks are marked differently. We won't allow
- * retasking the Headphone jack, so it won't be available here.
+/* Acer TravelMate(/Extensa/Aspire) notebooks have similar configuration to
+ * the Fujitsu S702x, but jacks are marked differently.
  */
-static struct hda_input_mux alc260_acer_capture_source = {
-	.num_items = 3,
-	.items = {
-		{ "Mic", 0x0 },
-		{ "Line", 0x2 },
-		{ "CD", 0x4 },
+static struct hda_input_mux alc260_acer_capture_sources[2] = {
+	{
+		.num_items = 4,
+		.items = {
+			{ "Mic", 0x0 },
+			{ "Line", 0x2 },
+			{ "CD", 0x4 },
+			{ "Headphone", 0x5 },
+		},
+	},
+	{
+		.num_items = 5,
+		.items = {
+			{ "Mic", 0x0 },
+			{ "Line", 0x2 },
+			{ "CD", 0x4 },
+			{ "Headphone", 0x6 },
+			{ "Mixer", 0x5 },
+		},
 	},
 };
-
 /*
  * This is just place-holder, so there's something for alc_build_pcms to look
  * at when it calculates the maximum number of channels. ALC260 has no mixer
@@ -2899,6 +2943,9 @@
 	{ } /* end */
 };
 
+/* Fujitsu S702x series laptops.  ALC260 pin usage: Mic/Line jack = 0x12, 
+ * HP jack = 0x14, CD audio =  0x16, internal speaker = 0x10.
+ */
 static struct snd_kcontrol_new alc260_fujitsu_mixer[] = {
 	HDA_CODEC_VOLUME("Headphone Playback Volume", 0x08, 0x0, HDA_OUTPUT),
 	HDA_BIND_MUTE("Headphone Playback Switch", 0x08, 2, HDA_INPUT),
@@ -2915,9 +2962,28 @@
 	{ } /* end */
 };
 
+/* Mixer for Acer TravelMate(/Extensa/Aspire) notebooks.  Note that current
+ * versions of the ALC260 don't act on requests to enable mic bias from NID
+ * 0x0f (used to drive the headphone jack in these laptops).  The ALC260
+ * datasheet doesn't mention this restriction.  At this stage it's not clear
+ * whether this behaviour is intentional or is a hardware bug in chip
+ * revisions available in early 2006.  Therefore for now allow the
+ * "Headphone Jack Mode" control to span all choices, but if it turns out
+ * that the lack of mic bias for this NID is intentional we could change the
+ * mode from ALC_PIN_DIR_INOUT to ALC_PIN_DIR_INOUT_NOMICBIAS.
+ *
+ * In addition, Acer TravelMate(/Extensa/Aspire) notebooks in early 2006
+ * don't appear to make the mic bias available from the "line" jack, even
+ * though the NID used for this jack (0x14) can supply it.  The theory is
+ * that perhaps Acer have included blocking capacitors between the ALC260
+ * and the output jack.  If this turns out to be the case for all such
+ * models the "Line Jack Mode" mode could be changed from ALC_PIN_DIR_INOUT
+ * to ALC_PIN_DIR_INOUT_NOMICBIAS.
+ */
 static struct snd_kcontrol_new alc260_acer_mixer[] = {
 	HDA_CODEC_VOLUME("Master Playback Volume", 0x08, 0x0, HDA_OUTPUT),
 	HDA_BIND_MUTE("Master Playback Switch", 0x08, 2, HDA_INPUT),
+	ALC_PIN_MODE("Headphone Jack Mode", 0x0f, ALC_PIN_DIR_INOUT),
 	HDA_CODEC_VOLUME("CD Playback Volume", 0x07, 0x04, HDA_INPUT),
 	HDA_CODEC_MUTE("CD Playback Switch", 0x07, 0x04, HDA_INPUT),
 	HDA_CODEC_VOLUME("Mic Playback Volume", 0x07, 0x0, HDA_INPUT),
@@ -3131,7 +3197,8 @@
 };
 
 /* Initialisation sequence for ALC260 as configured in Fujitsu S702x
- * laptops.
+ * laptops.  ALC260 pin usage: Mic/Line jack = 0x12, HP jack = 0x14, CD
+ * audio = 0x16, internal speaker = 0x10.
  */
 static struct hda_verb alc260_fujitsu_init_verbs[] = {
 	/* Disable all GPIOs */
@@ -3278,10 +3345,10 @@
 	{0x04, AC_VERB_SET_CONNECT_SEL, 0x00},
 
 	/* Do similar with the second ADC: mute capture input amp and
-	 * set ADC connection to line (on line1 pin)
+	 * set ADC connection to mic to match ALSA's default state.
 	 */
 	{0x05, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)},
-	{0x05, AC_VERB_SET_CONNECT_SEL, 0x02},
+	{0x05, AC_VERB_SET_CONNECT_SEL, 0x00},
 
 	/* Mute all inputs to mixer widget (even unconnected ones) */
 	{0x07, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)}, /* mic1 pin */
@@ -3306,26 +3373,35 @@
 static hda_nid_t alc260_test_adc_nids[2] = {
 	0x04, 0x05,
 };
-/* This is a bit messy since the two input muxes in the ALC260 have slight
- * variations in their signal assignments.  The ideal way to deal with this
- * is to extend alc_spec.input_mux to allow a different input MUX for each
- * ADC.  For the purposes of the test model it's sufficient to just list
- * both options for affected signal indices.  The separate input mux
- * functionality only needs to be considered if a model comes along which
- * actually uses signals 0x5, 0x6 and 0x7 for something which makes sense to
- * record.
+/* For testing the ALC260, each input MUX needs its own definition since
+ * the signal assignments are different.  This assumes that the first ADC 
+ * is NID 0x04.
  */
-static struct hda_input_mux alc260_test_capture_source = {
-	.num_items = 8,
-	.items = {
-		{ "MIC1 pin", 0x0 },
-		{ "MIC2 pin", 0x1 },
-		{ "LINE1 pin", 0x2 },
-		{ "LINE2 pin", 0x3 },
-		{ "CD pin", 0x4 },
-		{ "LINE-OUT pin (cap1), Mixer (cap2)", 0x5 },
-		{ "HP-OUT pin (cap1), LINE-OUT pin (cap2)", 0x6 },
-		{ "HP-OUT pin (cap2 only)", 0x7 },
+static struct hda_input_mux alc260_test_capture_sources[2] = {
+	{
+		.num_items = 7,
+		.items = {
+			{ "MIC1 pin", 0x0 },
+			{ "MIC2 pin", 0x1 },
+			{ "LINE1 pin", 0x2 },
+			{ "LINE2 pin", 0x3 },
+			{ "CD pin", 0x4 },
+			{ "LINE-OUT pin", 0x5 },
+			{ "HP-OUT pin", 0x6 },
+		},
+        },
+	{
+		.num_items = 8,
+		.items = {
+			{ "MIC1 pin", 0x0 },
+			{ "MIC2 pin", 0x1 },
+			{ "LINE1 pin", 0x2 },
+			{ "LINE2 pin", 0x3 },
+			{ "CD pin", 0x4 },
+			{ "Mixer", 0x5 },
+			{ "LINE-OUT pin", 0x6 },
+			{ "HP-OUT pin", 0x7 },
+		},
         },
 };
 static struct snd_kcontrol_new alc260_test_mixer[] = {
@@ -3337,7 +3413,17 @@
 	HDA_CODEC_VOLUME("LOUT1 Playback Volume", 0x08, 0x0, HDA_OUTPUT),
 	HDA_BIND_MUTE("LOUT1 Playback Switch", 0x08, 2, HDA_INPUT),
 
-	/* Modes for retasking pin widgets */
+	/* Modes for retasking pin widgets
+	 * Note: the ALC260 doesn't seem to act on requests to enable mic
+         * bias from NIDs 0x0f and 0x10.  The ALC260 datasheet doesn't
+         * mention this restriction.  At this stage it's not clear whether
+         * this behaviour is intentional or is a hardware bug in chip
+         * revisions available at least up until early 2006.  Therefore for
+         * now allow the "HP-OUT" and "LINE-OUT" Mode controls to span all
+         * choices, but if it turns out that the lack of mic bias for these
+         * NIDs is intentional we could change their modes from
+         * ALC_PIN_DIR_INOUT to ALC_PIN_DIR_INOUT_NOMICBIAS.
+	 */
 	ALC_PIN_MODE("HP-OUT pin mode", 0x10, ALC_PIN_DIR_INOUT),
 	ALC_PIN_MODE("LINE-OUT pin mode", 0x0f, ALC_PIN_DIR_INOUT),
 	ALC_PIN_MODE("LINE2 pin mode", 0x15, ALC_PIN_DIR_INOUT),
@@ -3699,6 +3785,7 @@
 
 	spec->init_verbs[spec->num_init_verbs++] = alc260_volume_init_verbs;
 
+	spec->num_mux_defs = 1;
 	spec->input_mux = &spec->private_imux;
 
 	/* check whether NID 0x04 is valid */
@@ -3804,7 +3891,8 @@
 		.adc_nids = alc260_dual_adc_nids,
 		.num_channel_mode = ARRAY_SIZE(alc260_modes),
 		.channel_mode = alc260_modes,
-		.input_mux = &alc260_fujitsu_capture_source,
+		.num_mux_defs = ARRAY_SIZE(alc260_fujitsu_capture_sources),
+		.input_mux = alc260_fujitsu_capture_sources,
 	},
 	[ALC260_ACER] = {
 		.mixers = { alc260_acer_mixer,
@@ -3816,7 +3904,8 @@
 		.adc_nids = alc260_dual_adc_nids,
 		.num_channel_mode = ARRAY_SIZE(alc260_modes),
 		.channel_mode = alc260_modes,
-		.input_mux = &alc260_acer_capture_source,
+		.num_mux_defs = ARRAY_SIZE(alc260_acer_capture_sources),
+		.input_mux = alc260_acer_capture_sources,
 	},
 #ifdef CONFIG_SND_DEBUG
 	[ALC260_TEST] = {
@@ -3829,7 +3918,8 @@
 		.adc_nids = alc260_test_adc_nids,
 		.num_channel_mode = ARRAY_SIZE(alc260_modes),
 		.channel_mode = alc260_modes,
-		.input_mux = &alc260_test_capture_source,
+		.num_mux_defs = ARRAY_SIZE(alc260_test_capture_sources),
+		.input_mux = alc260_test_capture_sources,
 	},
 #endif
 };
@@ -3921,7 +4011,6 @@
 		{ "CD", 0x4 },
 	},
 };
-
 #define alc882_mux_enum_info alc_mux_enum_info
 #define alc882_mux_enum_get alc_mux_enum_get
 
@@ -4823,6 +4912,7 @@
 		spec->mixers[spec->num_mixers++] = spec->kctl_alloc;
 
 	spec->init_verbs[spec->num_init_verbs++] = alc262_volume_init_verbs;
+	spec->num_mux_defs = 1;
 	spec->input_mux = &spec->private_imux;
 
 	return 1;
@@ -5499,6 +5589,7 @@
 
 	spec->init_verbs[spec->num_init_verbs++] = alc861_auto_init_verbs;
 
+	spec->num_mux_defs = 1;
 	spec->input_mux = &spec->private_imux;
 
 	spec->adc_nids = alc861_adc_nids;


-------------------------------------------------------
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

Re: [PATCH] HDA/Realtek: multiple input mux definitions and pin mode additions

[Takashi Iwai]

At Tue, 28 Mar 2006 09:24:33 +0930 (CST),
Jonathan Woithe wrote:
> 
> Hi Takashi
> 
> > > The following patch relative to CVS from 20060324 adds the following
> > > features to the Realtek HDA codec.
> > > 
> > > 1) Define two new pin modes: ALC_PIN_DIR_IN_NOMICBIAS and
> > >    ALC_PIN_DIR_INOUT_NOMICBIAS.  These can be used with jack mode switch
> > >    definitions in mixers to prevent the user being offered the mic bias
> > >    options if the hardware doesn't support it.
> > > 
> > > 2) Add the ability to have different input mux definitions for different
> > >    ADCs.  This is needed because the ALC260 chip uses different mux layouts
> > >    for the two onboard ADCs.  A new field (num_mux_defs) was added to the
> > >    alc_spec and alc_config_preset structures to support this.
> > 
> > I'd use num_mux_defs = 0 as if = 1 if input_mux is defined.
> > Then we don't have to patch all over places (and avoid carelessness).
> > 
> > Otherwise the patch looks OK.  Could you fix the above and repost?
> > I'd like to put this into 1.0.11-final, too.
> 
> The original patch would do the right thing with num_mux_defs = 0.  The
> attached revised patch simply removes the unnecessary initialisation of
> num_mux_defs in the presets.  This is untested since I don't have the laptop
> with me at present, but given the trivial nature of the change I don't
> foresee a problem.
> 
> I've left the initialisations in the alc*_parse_auto_config() functions for
> the moment since it's not clear to me that it will otherwise be initialised
> to something sensible in this context.

Thanks, I applied it to CVS with a minor change (the explicit
initialization to num_mux_defs = 1 if it's zero, and white space
fixes).


Takashi


-------------------------------------------------------
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