[alsa-devel] Jack sense fails on Fujitsu p7120
I posted regarding this issue to alsa-users, but haven't had any response. I've come to the conclusion that I will have to modify the driver myself to rectify this problem, so I would appreciate some pointers as to how to get started with that.
Running Xubuntu 10.10 with Alsa 1.0.23
The sound chip is Intel HDA, ALC260. I have tried setting
options snd-hda-intel model=fujitsu
in /etc/modprobe.d/alsa-base.conf, but this hasn't made any difference. There is no "Jack Sense" option in alsamixer. I've also tried a couple of values for fix_position.
I've tried following the ubuntu wiki pages for Intel HDA and sound debugging in general, to no avail. When doing the jack sense test recommended on https://wiki.ubuntu.com/ALSA/JackSense the two files generated with and without the headphones plugged in were identical. This makes me think it is a driver problem. I pasted the output of `cat /proc/asound/card*/codec*` at http://pastebin.com/4NyvdsXf in case this is of any help.
Hi again,
I'm just wondering if this is the wrong venue for this question? If so please could someone direct me to a more appropriate place to ask?
Thanks
On Wed, Jan 19, 2011 at 10:32 AM, Robin Neatherway neatherway@gmail.com wrote:
I posted regarding this issue to alsa-users, but haven't had any response. I've come to the conclusion that I will have to modify the driver myself to rectify this problem, so I would appreciate some pointers as to how to get started with that. Running Xubuntu 10.10 with Alsa 1.0.23 The sound chip is Intel HDA, ALC260. I have tried setting options snd-hda-intel model=fujitsu in /etc/modprobe.d/alsa-base.conf, but this hasn't made any difference. There is no "Jack Sense" option in alsamixer. I've also tried a couple of values for fix_position. I've tried following the ubuntu wiki pages for Intel HDA and sound debugging in general, to no avail. When doing the jack sense test recommended on https://wiki.ubuntu.com/ALSA/JackSense the two files generated with and without the headphones plugged in were identical. This makes me think it is a driver problem. I pasted the output of `cat /proc/asound/card*/codec*` at http://pastebin.com/4NyvdsXf in case this is of any help.
2011/1/19 Robin Neatherway neatherway@gmail.com
I posted regarding this issue to alsa-users, but haven't had any response. I've come to the conclusion that I will have to modify the driver myself to rectify this problem, so I would appreciate some pointers as to how to get started with that.
Running Xubuntu 10.10 with Alsa 1.0.23
The sound chip is Intel HDA, ALC260. I have tried setting
options snd-hda-intel model=fujitsu
in /etc/modprobe.d/alsa-base.conf, but this hasn't made any difference. There is no "Jack Sense" option in alsamixer. I've also tried a couple of values for fix_position.
If you compiled the driver in debug mode, you can select model=test for alc260
http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=7cf51e48315d87b4c1...
If you compiled the driver in debug mode, you can select model=test for alc260
http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=7cf51e48315d87b4c1...
Thanks for the suggestion. I tried compiling both the stable versions and the latest snapshots. The result was that new modules appeared in /lib/modules/`uname -r`/updates/alsa, which I think is the idea. However, when trying to use these modules, I received
$ sudo modprobe snd-hda-intel FATAL: Error inserting snd_hda_intel (/lib/modules/2.6.35-24-generic/updates/alsa/pci/hda/snd-hda-intel.ko): Unknown symbol in module, or unknown parameter (see dmesg)
And dmesg contains the following: syslog:Jan 23 16:47:03 baldur kernel: [ 23.389315] snd: Unknown symbol unregister_sound_special (err 0) syslog:Jan 23 16:47:03 baldur kernel: [ 23.390067] snd: Unknown symbol register_sound_special_device (err 0)
After reinstalling the alsa and linux-sound packages for Ubuntu, I recovered sound, but I can't try the "test" parameter without being able to load the module.
Do you know what this error means?
Robin
2011/1/24 Robin Neatherway neatherway@gmail.com
If you compiled the driver in debug mode, you can select model=test for alc260
http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=7cf51e48315d87b4c1...
Thanks for the suggestion. I tried compiling both the stable versions and the latest snapshots. The result was that new modules appeared in /lib/modules/`uname -r`/updates/alsa, which I think is the idea. However, when trying to use these modules, I received
$ sudo modprobe snd-hda-intel FATAL: Error inserting snd_hda_intel (/lib/modules/2.6.35-24-generic/updates/alsa/pci/hda/snd-hda-intel.ko): Unknown symbol in module, or unknown parameter (see dmesg)
And dmesg contains the following: syslog:Jan 23 16:47:03 baldur kernel: [ 23.389315] snd: Unknown symbol unregister_sound_special (err 0) syslog:Jan 23 16:47:03 baldur kernel: [ 23.390067] snd: Unknown symbol register_sound_special_device (err 0)
After reinstalling the alsa and linux-sound packages for Ubuntu, I recovered sound, but I can't try the "test" parameter without being able to load the module.
Do you know what this error means?
Because ubuntu had disabled OSS emulation , you have to disable OSS emulation too.
./configure --with-oss=no
Because ubuntu had disabled OSS emulation , you have to disable OSS emulation too.
./configure --with-oss=no
Thanks for the tip. I've compiled the 1.0.24 drivers tarball using ./configure --with-debug=full --with-oss=no and it now loads correctly. I have a large number of controls in alsamixer, having set model=test in /etc/modprobe.d/alsa-base.conf.
The control names are now generic, but I have found that LOUT1 is the headphones and LOUT2 is the speakers. There are also GPIO pins 0-3 available. I have tried toggling these, but it does not affect the jack sense, which still does not operate.
The new alsa-info is at the following URL: http://www.alsa-project.org/db/?f=3fb1a67066b9d06ac8405685ff7358af053e2668
How should I proceed? I've looked at the pci/drivers/hda_intel.c, and I notice that several "quirk" modes are enabled for particular models. Is it sensible to try enumerating these on my laptop, or are tables like this:
SND_PCI_QUIRK(0x1025, 0x009f, "Acer Aspire 5110", POS_FIX_LPIB), SND_PCI_QUIRK(0x1025, 0x026f, "Acer Aspire 5538", POS_FIX_LPIB), SND_PCI_QUIRK(0x1028, 0x01cc, "Dell D820", POS_FIX_LPIB), SND_PCI_QUIRK(0x1028, 0x01de, "Dell Precision 390", POS_FIX_LPIB), SND_PCI_QUIRK(0x1028, 0x01f6, "Dell Latitude 131L", POS_FIX_LPIB),
changing different addresses for each laptop model?
Thanks again for your help so far.
2011/2/1 Robin Neatherway neatherway@gmail.com
Because ubuntu had disabled OSS emulation , you have to disable OSS emulation too.
./configure --with-oss=no
Thanks for the tip. I've compiled the 1.0.24 drivers tarball using ./configure --with-debug=full --with-oss=no and it now loads correctly. I have a large number of controls in alsamixer, having set model=test in /etc/modprobe.d/alsa-base.conf.
The control names are now generic, but I have found that LOUT1 is the headphones and LOUT2 is the speakers. There are also GPIO pins 0-3 available. I have tried toggling these, but it does not affect the jack sense, which still does not operate.
The new alsa-info is at the following URL: http://www.alsa-project.org/db/?f=3fb1a67066b9d06ac8405685ff7358af053e2668
Do you mean
LOUT1 playback volume control at node 0x8 affect the volume of your headphone and LOUT2 playback volume control at node 0x9 affect the volume of your speakers ?
If you look at 4.1 Block Diagram of alc260 datasheet ,
LOUT1 is connected to 0xf Line Out and LOUT2 is connected to 0x10 HP
Do you mean
LOUT1 playback volume control at node 0x8 affect the volume of your headphone and LOUT2 playback volume control at node 0x9 affect the volume of your speakers ?
If you look at 4.1 Block Diagram of alc260 datasheet ,
LOUT1 is connected to 0xf Line Out and LOUT2 is connected to 0x10 HP
Having looked at the datasheet I agree with you, this seems surprising. However, if I run speaker-test and then toggle the mutes of LOUT1 and LOUT2 one by one, they toggle the headphones and speakers respectively.
Additionally, to hear output on each device I have to set the following pin modes:
Headphones: LINE1 pin mode at node 0x14 must be set to line out (quieter)/headphones (louder) Speakers: HP-OUT pin mode at node 0x10 must be set to line out/headphones (same volume)
This bears little relationship to the datasheet.
_From the datasheet it looks like:
Node 0x1b [Volume Knob Widget] wcaps 0x600080: Mono Volume-Knob: delta=0, steps=64, direct=0, val=48 Unsolicited: tag=00, enabled=0 Connection: 0
should be responsible for the jack detection. I have noticed in my testing that the "val" is sometimes 48 and sometimes 49, but I haven't been able to correlate this with presence of headphones or otherwise.
2011/2/2 Robin Neatherway neatherway@gmail.com
Do you mean
LOUT1 playback volume control at node 0x8 affect the volume of your headphone and LOUT2 playback volume control at node 0x9 affect the volume
of
your speakers ?
If you look at 4.1 Block Diagram of alc260 datasheet ,
LOUT1 is connected to 0xf Line Out and LOUT2 is connected to 0x10 HP
Having looked at the datasheet I agree with you, this seems surprising. However, if I run speaker-test and then toggle the mutes of LOUT1 and LOUT2 one by one, they toggle the headphones and speakers respectively.
Additionally, to hear output on each device I have to set the following pin modes:
Headphones: LINE1 pin mode at node 0x14 must be set to line out (quieter)/headphones (louder) Speakers: HP-OUT pin mode at node 0x10 must be set to line out/headphones (same volume)
hp_automute work only when it get the correct position of HP and speaker [Pin complex]
Can you post the output of alsa-info.sh using model=auto after a cold boot to find out whether BIOS setup pin default of node 0x0f and 0x10 to HP and Speakers ?
if not, you will need to find any alc269 model which create "Headphone Playback Volume" at node 0x8 and "Speaker Playback volume" at node 0x09
At Wed, 2 Feb 2011 11:14:19 +0800, Raymond Yau wrote:
2011/2/2 Robin Neatherway neatherway@gmail.com
Do you mean
LOUT1 playback volume control at node 0x8 affect the volume of your headphone and LOUT2 playback volume control at node 0x9 affect the volume
of
your speakers ?
If you look at 4.1 Block Diagram of alc260 datasheet ,
LOUT1 is connected to 0xf Line Out and LOUT2 is connected to 0x10 HP
Having looked at the datasheet I agree with you, this seems surprising. However, if I run speaker-test and then toggle the mutes of LOUT1 and LOUT2 one by one, they toggle the headphones and speakers respectively.
Additionally, to hear output on each device I have to set the following pin modes:
Headphones: LINE1 pin mode at node 0x14 must be set to line out (quieter)/headphones (louder) Speakers: HP-OUT pin mode at node 0x10 must be set to line out/headphones (same volume)
hp_automute work only when it get the correct position of HP and speaker [Pin complex]
Can you post the output of alsa-info.sh using model=auto after a cold boot to find out whether BIOS setup pin default of node 0x0f and 0x10 to HP and Speakers ?
if not, you will need to find any alc269 model which create "Headphone Playback Volume" at node 0x8 and "Speaker Playback volume" at node 0x09
Or set up the pins dynamically via sysfs and reconfigure. If you find out a working setup, it can be initialized automatically via patch option of snd-hda-intel module.
More details are found in HD-Audio.txt.
Takashi
hp_automute work only when it get the correct position of HP and speaker [Pin complex]
Can you post the output of alsa-info.sh using model=auto after a cold boot to find out whether BIOS setup pin default of node 0x0f and 0x10 to HP and Speakers ?
if not, you will need to find any alc269 model which create "Headphone Playback Volume" at node 0x8 and "Speaker Playback volume" at node 0x09
OK, this produced some interesting behaviour, new alsa info at: http://www.alsa-project.org/db/?f=bdb19d75e4147d3ee294f2150db8b723e3ad3527
Headphone volume appears at node 0x8 and speakers at 0x9, however there is no sound over the speakers now, possibly related to this dmesg output: [ 25.417568] ALSA hda_codec.c:4633: autoconfig: line_outs=2 (0x10/0x15/0x0/0x0/0x0) [ 25.417575] ALSA hda_codec.c:4637: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 25.417581] ALSA hda_codec.c:4641: hp_outs=1 (0x14/0x0/0x0/0x0/0x0)
Or set up the pins dynamically via sysfs and reconfigure. If you find out a working setup, it can be initialized automatically via patch option of snd-hda-intel module.
More details are found in HD-Audio.txt.
I've had a read through HD-Audio.txt and a quick look at the HD audio spec from Intel. It isn't clear to me how the pin configs relate to the way things are set up. The /sys/class/sound/hwC0D0/init_pin_configs file looks like this:
0x0f 0x411111f0 0x10 0xb7031110 0x11 0x411111f0 0x12 0x02a11820 0x13 0xb7831121 0x14 0x0221101f 0x15 0x21011010 0x16 0x411111f0 0x17 0xb7931122 0x18 0x2145111e 0x19 0x411111f0
Does each of the hex values on the left refer to a node? If so, where are those before 0xf and after 0x19?
Thanks, Robin
At Wed, 2 Feb 2011 23:38:19 +0000, Robin Neatherway wrote:
hp_automute work only when it get the correct position of HP and speaker [Pin complex]
Can you post the output of alsa-info.sh using model=auto after a cold boot to find out whether BIOS setup pin default of node 0x0f and 0x10 to HP and Speakers ?
if not, you will need to find any alc269 model which create "Headphone Playback Volume" at node 0x8 and "Speaker Playback volume" at node 0x09
OK, this produced some interesting behaviour, new alsa info at: http://www.alsa-project.org/db/?f=bdb19d75e4147d3ee294f2150db8b723e3ad3527
Headphone volume appears at node 0x8 and speakers at 0x9, however there is no sound over the speakers now, possibly related to this dmesg output: [ 25.417568] ALSA hda_codec.c:4633: autoconfig: line_outs=2 (0x10/0x15/0x0/0x0/0x0) [ 25.417575] ALSA hda_codec.c:4637: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 25.417581] ALSA hda_codec.c:4641: hp_outs=1 (0x14/0x0/0x0/0x0/0x0)
Or set up the pins dynamically via sysfs and reconfigure. If you find out a working setup, it can be initialized automatically via patch option of snd-hda-intel module.
More details are found in HD-Audio.txt.
I've had a read through HD-Audio.txt and a quick look at the HD audio spec from Intel. It isn't clear to me how the pin configs relate to the way things are set up. The /sys/class/sound/hwC0D0/init_pin_configs file looks like this:
0x0f 0x411111f0 0x10 0xb7031110 0x11 0x411111f0 0x12 0x02a11820 0x13 0xb7831121 0x14 0x0221101f 0x15 0x21011010 0x16 0x411111f0 0x17 0xb7931122 0x18 0x2145111e 0x19 0x411111f0
Does each of the hex values on the left refer to a node?
Yes.
If so, where are those before 0xf and after 0x19?
Others are no pin widgets. See HD-audio specification for more details.
Takashi
if not, you will need to find any alc269 model which create "Headphone Playback Volume" at node 0x8 and "Speaker Playback volume" at node 0x09
With model=auto, these appear at the correct nodes, but I no longer get any sound over the speakers. How can I control where these appear, or add an EAPD pin to try and reenable the speakers?
Others are no pin widgets. See HD-audio specification for more details.
OK, I've found "7.3.3.31 Configuration Default" in the spec which describes the meaning of the pin config register. From the discussion so far I think I need to change node 0x1B to be a jack sense pin. I must misunderstand though because a) Configuration Default has nothing to do with whether it is a jack sense pin and b) 0x1B is not a pin widget anyway.
At Thu, 3 Feb 2011 23:49:55 +0000, Robin Neatherway wrote:
if not, you will need to find any alc269 model which create "Headphone Playback Volume" at node 0x8 and "Speaker Playback volume" at node 0x09
With model=auto, these appear at the correct nodes, but I no longer get any sound over the speakers. How can I control where these appear, or add an EAPD pin to try and reenable the speakers?
Others are no pin widgets. See HD-audio specification for more details.
OK, I've found "7.3.3.31 Configuration Default" in the spec which describes the meaning of the pin config register. From the discussion so far I think I need to change node 0x1B to be a jack sense pin. I must misunderstand though because a) Configuration Default has nothing to do with whether it is a jack sense pin and b) 0x1B is not a pin widget anyway.
The auto codec parser reads the default config values of all pin widgets, and enables the jack sense when a pin is a HP jack. That's why it's important to figure out which pin widget corresponds to which actual I/O.
Takashi
The auto codec parser reads the default config values of all pin widgets, and enables the jack sense when a pin is a HP jack. That's why it's important to figure out which pin widget corresponds to which actual I/O.
Right. With "auto", the jack sense might well be working then, but I can't tell because there is no output over the speakers. Unless there is another way of telling?
I'm pretty confused right now. Raymond suggested that the important thing is to ensure that the nodes 0x8 and 0x9 are HP and Speaker volume respectively, while you are suggesting that I should alter the pin configuration, which only affects pin widgets and these are only from 0xF to 0x19. The pin configuration doesn't seem to contain anything to do with jack sense, so I'm not sure what I should change there.
How do you normally figure out which pin widget corresponds to which I/O? Is it just trial and error?
The ALC260 datasheet (http://realtek.info/pdf/alc260.pdf section 4.1, page 4) seems to make it pretty clear that the jack sense is at node 0x1b, and the block diagram indicates that it is a pin, so why is it not showing up as a pin widget?
Thanks, Robin
2011/2/4 Robin Neatherway neatherway@gmail.com
if not, you will need to find any alc269 model which create "Headphone Playback Volume" at node 0x8 and "Speaker Playback volume" at node 0x09
With model=auto, these appear at the correct nodes, but I no longer get any sound over the speakers. How can I control where these appear, or add an EAPD pin to try and reenable the speakers?
If you look at the datasheet LOUT1 and LOUT2 can be connected to 0xf, 0x10, 0x12 , 0x13, 0x14 and 0x15
So you have to find out which pin complex is your speaker by mute/unmute the mute switch of those pin complex
participants (3)
-
Raymond Yau -
Robin Neatherway -
Takashi Iwai