Hi List,

Is there any chance that this bug will be fixed soon?

I did some C/C++ progtramming in the last years and i'm willing to help where possible. But I am new to Open Source Development with a community of developers and users.

Regards, Rene Dohmen

Op Feb 23, 2008, om 3:29 AM heeft Matthew R. Hurne het volgende geschreven:

Matthew R. Hurne wrote:

...

Rene Dohmen wrote:

...

Dear List,

I have a problem with an Intel HDA soundcard lspci output:

---

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)

The sound volume is very very low when i use the headphone output. The device has integrated speakers but i don't hear any sound coming out of them (maybe because the volume is so low...). I've put all the mixer channels to the maximum values. When booted in Win XP the soundcard works correctly.

Is see one line in my logs that indicate that something is wrong: hda_codec: Unknown model for ALC262, trying auto-probe from BIOS...

I didn't have it working with other versions of ALSA. Tested with 1.0.14(provided with ubunty gutsy), then started reading, lots of suggestions stated that the problem would be solved in 1.0.15, so i compiled 1.0.16 from src and replaced the default alsa modules with the new ones.

De device i 'm using is supplied by tangent ( http://www.tangent.com/t_all_in_one_LCDPC/vita_8000s.htm) its an all in one solution with touchscreen and speakers integrated in one small cabinet.

I runned the alsa-info.sh script output and uploaded it: http://pastebin.ca/913865

I don't know if this is the correct place for getting help but all help is appreciated,

I have the exact same issue, Rene. So far not much progress has been made - unfortunately I'm an ALSA user, not an ALSA developer. I did create a bug here:

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3725 (that's bug ID 0003725)

I suspect the issue boils down to the driver not recognizing the way things are "wired" together. See the bug report for more details about what I've done thus far, which is essentially collection of as much information as possible for the ALSA developers to use in troubleshooting the issue.

Regards, Matt Hurne

I added your message to the mailing list as a note on the bug report as well, Rene.

Thanks, Matt

Thnx for your answer. The preset models ( i tested the ones in 1.0.16 didn't work so i'll have a try with the latest HG version)

Having fun,

Rene

Op Feb 26, 2008, om 1:10 PM heeft Takashi Iwai het volgende geschreven:

At Mon, 25 Feb 2008 13:49:43 +0100, Rene Dohmen wrote:

...

Hi List,

Is there any chance that this bug will be fixed soon?

Well, it's up to you.

One of the problems is that BIOS on your machine doesn't give the useful information for auto-probing at all. A typical workaround in such a case is to try the existing preset models. Pass model=basic or model=benq to snd-hda-intel module, for example. The available model values can be found in ALSA-Configuration.txt. Don't forget to check and adjust the mixer status again after changing the model because the mixers appear completly differently depending on the model.

If none of the existing models doesn't match with your device, we have to figure out the exact codec configuration. For some codecs like ALC880 or ALC260, you have model=test option that allows you to test all codec configurations via mixer interface. Unfortunately, ALC262 has no model=test support, so you have to do check it literally manually. Below is a brief instruction how to explore the mysterious world of HD-audio codecs.

First of all, install the very latest ALSA HG version. Don't stick with 1.0.16 release. You can use the daily snapshot tarball instead, too.

Then, get hda-verb program found on ftp://ftp.suse.com/pub/people/tiwai/misc/ Extract the tarball, run make. Install it or invoke it locally. This program can be usable only as root.

The next step is to get ALC262 datasheet from Realtek web site. Take a look at the block diagram page. There are pins in the right side and two DACs in the left side. We have to set up the correct pins and connect to the DAC properly.

Now, assume the port-D (NID 0x14) is the speaker output. Check /proc/asound/card0/codec#0 and look for Node 0x14. It may have the entry like the following:

Node 0x14 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x083e: IN OUT HP Detect Trigger Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN Unsolicited: tag=00, enabled=0 Connection: 2 0x0c* 0x0d

For this widget, we have a couple of things to do: fix the pin type, adjust the amp and check the connection. First, change the pin type to the correct one, the output type. Usually, it's either 0x40 or 0xc0. The latter type is with a headphone amplifier. Let's take 0xc0 as an example. Call hda-verb like below (as root user):

# hda-verb /dev/snd/hwC0D0 0x14 SET_PIN_WID 0xc0

Check /proc/asound/card0/codec#0 again whether the pin-ctls is changed properly. Similarly, unmute the output volume of this widget with hda-verb. For this, pass 0xb000 to SET_AMP verb:

# hda-verb /dev/snd/hwC0D0 0x14 SET_AMP 0xb000

0xb000 means to set the AMP-output to 0x00. The mute bit is 0x80, so 0x00 means to unmute and set the volume 0. (The volume 0 doesn't matter because this widget has no volume but only mute control.)

In the example above, this pin is connected from the NID 0x0c, which is a mixer amp. That's fine and let's keep as is. Check this widget 0x0c whether the first Amp-In vals is unmuted (i.e. has *no* 0x80 bit mask). The first element of 0x0c is connected to the DAC, 0x02, directly. If it's muted, call like below

# hda-verb /dev/snd/hwC0D0 0x0c SET_AMP 0x7000

0x7000 means to set the AMP-input of the first element (index 0) to 0x00. For the second element, it'd be 0x7100.

OK, all set ready. Try aplay and pray. If this doesn't work, try other ports as well until you find a gold mine.

You could check the inputs similarly if anything doesn't work. Once after you figure out all pin configurations, we can create a new model (or fix the existing model) to adapt your device.

Have fun,

Takashi

At Wed, 27 Feb 2008 00:19:58 +0100, Rene Dohmen wrote:

Hi,

I compiled the HG version. The driver behaves in the exact same way as the 1.0.16 version. Very very low volume on the headphone output, like hearing sound form another channel on a mixer because of crosstalk (i don't know is this is the correct translation).

And is it so with all module options?

I also compiled hda_verb and used it to twiddle around with some of the connections. So far no luck.

Can I do something to boost the volume level? Or is this also caused by the incorrect pin wiring of the device? Maybe the speakers do output some sound but because of the the low soundlevel i can't hear it.

EAPD might be the case. Set via "SET_EAPD 0x02" to turn on the amplifier (if any).

Takashi

Thanks,

Rene

On Tue, Feb 26, 2008 at 1:21 PM, Rene Dohmen acidjunk@gmail.com wrote:

Thnx for your answer.
The preset models ( i tested the ones in 1.0.16 didn't work so i'll
have a try with the latest HG version)

Having fun,

       Rene

Op Feb 26, 2008, om 1:10 PM heeft Takashi Iwai het volgende geschreven:

> At Mon, 25 Feb 2008 13:49:43 +0100,
> Rene Dohmen wrote:
>>
>> Hi List,
>>
>> Is there any chance that this bug will be fixed soon?
>
> Well, it's up to you.
>
> One of the problems is that BIOS on your machine doesn't give the
> useful information for auto-probing at all.  A typical workaround in
> such a case is to try the existing preset models.  Pass model=basic or
> model=benq to snd-hda-intel module, for example.  The available model
> values can be found in ALSA-Configuration.txt.  Don't forget to
> check and adjust the mixer status again after changing the model
> because the mixers appear completly differently depending on the
> model.
>
> If none of the existing models doesn't match with your device, we have
> to figure out the exact codec configuration.  For some codecs like
> ALC880 or ALC260, you have model=test option that allows you to test
> all codec configurations via mixer interface.  Unfortunately, ALC262
> has no model=test support, so you have to do check it literally
> manually.  Below is a brief instruction how to explore the mysterious
> world of HD-audio codecs.
>
> First of all, install the very latest ALSA HG version.  Don't stick
> with 1.0.16 release.  You can use the daily snapshot tarball instead,
> too.
>
> Then, get hda-verb program found on
>       ftp://ftp.suse.com/pub/people/tiwai/misc/
> Extract the tarball, run make.  Install it or invoke it locally.  This
> program can be usable only as root.
>
> The next step is to get ALC262 datasheet from Realtek web site.  Take
> a look at the block diagram page.  There are pins in the right side
> and two DACs in the left side.  We have to set up the correct pins and
> connect to the DAC properly.
>
> Now, assume the port-D (NID 0x14) is the speaker output.  Check
> /proc/asound/card0/codec#0 and look for Node 0x14.  It may have the
> entry like the following:
>
>       Node 0x14 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
>         Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
>         Amp-In vals:  [0x00 0x00] [0x00 0x00]
>         Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
>         Amp-Out vals:  [0x80 0x80]
>         Pincap 0x083e: IN OUT HP Detect Trigger
>         Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
>           Conn = 1/8, Color = Black
>           DefAssociation = 0xf, Sequence = 0x0
>           Misc = NO_PRESENCE
>         Pin-ctls: 0x20: IN
>         Unsolicited: tag=00, enabled=0
>         Connection: 2
>            0x0c* 0x0d
>
> For this widget, we have a couple of things to do: fix the pin type,
> adjust the amp and check the connection.  First, change the pin type
> to the correct one, the output type.  Usually, it's either 0x40 or
> 0xc0.  The latter type is with a headphone amplifier.  Let's take
> 0xc0 as an example.  Call hda-verb like below (as root user):
>
>       # hda-verb /dev/snd/hwC0D0 0x14 SET_PIN_WID 0xc0
>
> Check /proc/asound/card0/codec#0 again whether the pin-ctls is changed
> properly.  Similarly, unmute the output volume of this widget with
> hda-verb.  For this, pass 0xb000 to SET_AMP verb:
>
>       # hda-verb /dev/snd/hwC0D0 0x14 SET_AMP 0xb000
>
> 0xb000 means to set the AMP-output to 0x00.  The mute bit is 0x80, so
> 0x00 means to unmute and set the volume 0.  (The volume 0 doesn't
> matter because this widget has no volume but only mute control.)
>
> In the example above, this pin is connected from the NID 0x0c, which
> is a mixer amp.  That's fine and let's keep as is.
> Check this widget 0x0c whether the first Amp-In vals is unmuted
> (i.e. has *no* 0x80 bit mask).  The first element of 0x0c is connected
> to the DAC, 0x02, directly.  If it's muted, call like below
>
>       # hda-verb /dev/snd/hwC0D0 0x0c SET_AMP 0x7000
>
> 0x7000 means to set the AMP-input of the first element (index 0) to
> 0x00.  For the second element, it'd be 0x7100.
>
> OK, all set ready.  Try aplay and pray.  If this doesn't work, try
> other ports as well until you find a gold mine.
>
> You could check the inputs similarly if anything doesn't work.
> Once after you figure out all pin configurations, we can create a new
> model (or fix the existing model) to adapt your device.
>
> Have fun,
>
>
> Takashi

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

At Wed, 27 Feb 2008 19:16:23 +0100, Rene Dohmen wrote:

I tried it with all avalialable NIDS:

sudo ./hda-verb /dev/snd/hwC0D0 0x14 SET_EAPD 0x02 Is this correct?

Looks OK. Check /proc/asound/card0/codec#0 after you run the command. The EAPD value shown there must be changed.

And is it so with all module options?

Yes with all tested codecs: are there any more options that i can use?

Did you figure out that 0x14 is really the speaker output? You can check it by muting the AMP of this widget manually via hda-verb command.

Takashi

Takashi Iwai wrote:

At Mon, 25 Feb 2008 13:49:43 +0100, Rene Dohmen wrote:

...

Hi List,

Is there any chance that this bug will be fixed soon?

Well, it's up to you.

One of the problems is that BIOS on your machine doesn't give the useful information for auto-probing at all. A typical workaround in such a case is to try the existing preset models. Pass model=basic or model=benq to snd-hda-intel module, for example. The available model values can be found in ALSA-Configuration.txt. Don't forget to check and adjust the mixer status again after changing the model because the mixers appear completly differently depending on the model.

If none of the existing models doesn't match with your device, we have to figure out the exact codec configuration. For some codecs like ALC880 or ALC260, you have model=test option that allows you to test all codec configurations via mixer interface. Unfortunately, ALC262 has no model=test support, so you have to do check it literally manually. Below is a brief instruction how to explore the mysterious world of HD-audio codecs.

First of all, install the very latest ALSA HG version. Don't stick with 1.0.16 release. You can use the daily snapshot tarball instead, too.

Then, get hda-verb program found on ftp://ftp.suse.com/pub/people/tiwai/misc/ Extract the tarball, run make. Install it or invoke it locally. This program can be usable only as root.

The next step is to get ALC262 datasheet from Realtek web site. Take a look at the block diagram page. There are pins in the right side and two DACs in the left side. We have to set up the correct pins and connect to the DAC properly.

Now, assume the port-D (NID 0x14) is the speaker output. Check /proc/asound/card0/codec#0 and look for Node 0x14. It may have the entry like the following:

Node 0x14 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x083e: IN OUT HP Detect Trigger Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN Unsolicited: tag=00, enabled=0 Connection: 2 0x0c* 0x0d

For this widget, we have a couple of things to do: fix the pin type, adjust the amp and check the connection. First, change the pin type to the correct one, the output type. Usually, it's either 0x40 or 0xc0. The latter type is with a headphone amplifier. Let's take 0xc0 as an example. Call hda-verb like below (as root user):

# hda-verb /dev/snd/hwC0D0 0x14 SET_PIN_WID 0xc0

Check /proc/asound/card0/codec#0 again whether the pin-ctls is changed properly. Similarly, unmute the output volume of this widget with hda-verb. For this, pass 0xb000 to SET_AMP verb:

# hda-verb /dev/snd/hwC0D0 0x14 SET_AMP 0xb000

0xb000 means to set the AMP-output to 0x00. The mute bit is 0x80, so 0x00 means to unmute and set the volume 0. (The volume 0 doesn't matter because this widget has no volume but only mute control.)

In the example above, this pin is connected from the NID 0x0c, which is a mixer amp. That's fine and let's keep as is. Check this widget 0x0c whether the first Amp-In vals is unmuted (i.e. has *no* 0x80 bit mask). The first element of 0x0c is connected to the DAC, 0x02, directly. If it's muted, call like below

# hda-verb /dev/snd/hwC0D0 0x0c SET_AMP 0x7000

0x7000 means to set the AMP-input of the first element (index 0) to 0x00. For the second element, it'd be 0x7100.

OK, all set ready. Try aplay and pray. If this doesn't work, try other ports as well until you find a gold mine.

You could check the inputs similarly if anything doesn't work. Once after you figure out all pin configurations, we can create a new model (or fix the existing model) to adapt your device.

Have fun,

Takashi

Thanks, Takashi! If it so happens I have the time, I will try to play with this in tandem to Rene.

Regards,

I am finishing up my current course tomorrow night, and the next {required} course I am taking is "Linux Fundamentals" - which is to say I will have spare cycles to help out again on this.

Going through the message thread, you mentioned a Crystal A410 system that works, whereas your Tangent 8000S does not. It would be interesting to recompile the drivers with "--with-debug=detect" and see what shows up in dmesg (for alsa only, not the entire boot log). Based on that, we may be able to construct a driver model. Also, if you have access to the Crystal still, could you run alsa-info.sh on it as well? I'd like to verify the audio subsystem ID.

In reviewing an earlier alsa-info posting, it shows your mixer as all channels muted. I'm assuming you tried changing the volume levels in alsamixer?

At any rate, they list a 30 day trial unit. I'll see if I can get one for driver development. Nothing ventured, nothing gained.

Tobin

On Mon, 2008-03-17 at 13:07 -0400, Matthew R Hurne wrote:

Takashi Iwai wrote:

...

At Mon, 25 Feb 2008 13:49:43 +0100, Rene Dohmen wrote:

...

Hi List,

Is there any chance that this bug will be fixed soon?

Well, it's up to you.

One of the problems is that BIOS on your machine doesn't give the useful information for auto-probing at all. A typical workaround in such a case is to try the existing preset models. Pass model=basic or model=benq to snd-hda-intel module, for example. The available model values can be found in ALSA-Configuration.txt. Don't forget to check and adjust the mixer status again after changing the model because the mixers appear completly differently depending on the model.

If none of the existing models doesn't match with your device, we have to figure out the exact codec configuration. For some codecs like ALC880 or ALC260, you have model=test option that allows you to test all codec configurations via mixer interface. Unfortunately, ALC262 has no model=test support, so you have to do check it literally manually. Below is a brief instruction how to explore the mysterious world of HD-audio codecs.

First of all, install the very latest ALSA HG version. Don't stick with 1.0.16 release. You can use the daily snapshot tarball instead, too.

Then, get hda-verb program found on ftp://ftp.suse.com/pub/people/tiwai/misc/ Extract the tarball, run make. Install it or invoke it locally. This program can be usable only as root.

The next step is to get ALC262 datasheet from Realtek web site. Take a look at the block diagram page. There are pins in the right side and two DACs in the left side. We have to set up the correct pins and connect to the DAC properly.

Now, assume the port-D (NID 0x14) is the speaker output. Check /proc/asound/card0/codec#0 and look for Node 0x14. It may have the entry like the following:

Node 0x14 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x083e: IN OUT HP Detect Trigger Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN Unsolicited: tag=00, enabled=0 Connection: 2 0x0c* 0x0d

For this widget, we have a couple of things to do: fix the pin type, adjust the amp and check the connection. First, change the pin type to the correct one, the output type. Usually, it's either 0x40 or 0xc0. The latter type is with a headphone amplifier. Let's take 0xc0 as an example. Call hda-verb like below (as root user):

# hda-verb /dev/snd/hwC0D0 0x14 SET_PIN_WID 0xc0

Check /proc/asound/card0/codec#0 again whether the pin-ctls is changed properly. Similarly, unmute the output volume of this widget with hda-verb. For this, pass 0xb000 to SET_AMP verb:

# hda-verb /dev/snd/hwC0D0 0x14 SET_AMP 0xb000

0xb000 means to set the AMP-output to 0x00. The mute bit is 0x80, so 0x00 means to unmute and set the volume 0. (The volume 0 doesn't matter because this widget has no volume but only mute control.)

In the example above, this pin is connected from the NID 0x0c, which is a mixer amp. That's fine and let's keep as is. Check this widget 0x0c whether the first Amp-In vals is unmuted (i.e. has *no* 0x80 bit mask). The first element of 0x0c is connected to the DAC, 0x02, directly. If it's muted, call like below

# hda-verb /dev/snd/hwC0D0 0x0c SET_AMP 0x7000

0x7000 means to set the AMP-input of the first element (index 0) to 0x00. For the second element, it'd be 0x7100.

OK, all set ready. Try aplay and pray. If this doesn't work, try other ports as well until you find a gold mine.

You could check the inputs similarly if anything doesn't work. Once after you figure out all pin configurations, we can create a new model (or fix the existing model) to adapt your device.

Have fun,

Takashi

Takashi, For my part, I have no idea what you're talking about. That's not a criticism of you, its a criticism of myself. :-) Is there somewhere where things like "verb" and "NID" and "widget" are documented? I skimmed through the driver development guide and didn't see such references. I played with hda-verb briefly, but since I have no clue what I'm doing, decided that I'm better off trying to learn the fundamentals I need to understand before messing with hda-verb. I know its tough dealing with someone like myself who is a user, not a developer (well, not a hardware driver developer, anyway). I apologize for that. Perhaps my company could send you a unit? I'd have to discuss with them, but I suspect they would be willing to do so.

Thanks,