[alsa-devel] Internal speaker output from Sony Vaio Z (2010 model) lost somewhere between 3.1.0 and 3.2.6
Welp, pretty much as the topic says.
I just noticed today that sound is no longer playing from the internal speakers of my laptop, a 2010 model Sony Vaio Z. Plugging in headphones causes sound to be played fine through those. There are three possible choices for 'Connector' - 'Analog Speakers', 'Analog Output', and 'Analog Headphones' - but none of these seems to make sound come out of the internal speakers. The default is 'Analog Speakers', and when it's set to this, headphone output does work when headphones are plugged in.
I've verified that it's broken on Fedora 16 kernels 3.2.6-4, 3.2.8-3 and 3.2.10-1. It's also broken in a very recent Fedora 17 kernel, 3.3.0rc6 or so. It works on a Fedora 16 live image, with kernel 3.1.0-1. Unfortunately the kernels before 3.2.6 have been trashed from Fedora's buildsystem archives, I think, so it's hard to narrow things down any further :/
the alsa-info output is http://www.alsa-project.org/db/?f=368e2359757b537d4daa0f5399830d3942540196 .
Thanks!
2012/3/17, Adam Williamson awilliam@redhat.com:
Welp, pretty much as the topic says.
I just noticed today that sound is no longer playing from the internal speakers of my laptop, a 2010 model Sony Vaio Z. Plugging in headphones causes sound to be played fine through those. There are three possible choices for 'Connector' - 'Analog Speakers', 'Analog Output', and 'Analog Headphones' - but none of these seems to make sound come out of the internal speakers. The default is 'Analog Speakers', and when it's set to this, headphone output does work when headphones are plugged in.
I've verified that it's broken on Fedora 16 kernels 3.2.6-4, 3.2.8-3 and 3.2.10-1. It's also broken in a very recent Fedora 17 kernel, 3.3.0rc6 or so. It works on a Fedora 16 live image, with kernel 3.1.0-1. Unfortunately the kernels before 3.2.6 have been trashed from Fedora's buildsystem archives, I think, so it's hard to narrow things down any further :/
the alsa-info output is http://www.alsa-project.org/db/?f=368e2359757b537d4daa0f5399830d3942540196 .
it is a bug if sound preference allow user to select speaker when auto-mute mode is enabled (the speaker is automatically muted by the driver when you plug the headphone)
Does the laptop surround51 by retasking two mic jacks and headphone ?
Simple mixer control 'Auto-Mute Mode',0 Capabilities: enum Items: 'Disabled' 'Enabled' Item0: 'Enabled' Simple mixer control 'Channel Mode',0 Capabilities: enum Items: '2ch' '4ch' '6ch' Item0: '2ch' Simple mixer control 'Input Source',0 Capabilities: cenum Items: 'Internal Mic' 'Mic' 'Mic 1' Item0: 'Internal Mic'
On Sat, 2012-03-17 at 10:04 +0800, Raymond Yau wrote:
2012/3/17, Adam Williamson awilliam@redhat.com:
Welp, pretty much as the topic says.
I just noticed today that sound is no longer playing from the internal speakers of my laptop, a 2010 model Sony Vaio Z. Plugging in headphones causes sound to be played fine through those. There are three possible choices for 'Connector' - 'Analog Speakers', 'Analog Output', and 'Analog Headphones' - but none of these seems to make sound come out of the internal speakers. The default is 'Analog Speakers', and when it's set to this, headphone output does work when headphones are plugged in.
I've verified that it's broken on Fedora 16 kernels 3.2.6-4, 3.2.8-3 and 3.2.10-1. It's also broken in a very recent Fedora 17 kernel, 3.3.0rc6 or so. It works on a Fedora 16 live image, with kernel 3.1.0-1. Unfortunately the kernels before 3.2.6 have been trashed from Fedora's buildsystem archives, I think, so it's hard to narrow things down any further :/
the alsa-info output is http://www.alsa-project.org/db/?f=368e2359757b537d4daa0f5399830d3942540196 .
it is a bug if sound preference allow user to select speaker when auto-mute mode is enabled (the speaker is automatically muted by the driver when you plug the headphone)
Then I guess that's another bug :) Because yes, the laptop does auto-mute by default. When the speakers are actually working, if I plug in headphones, the speakers get muted and the headphones work. No need to manually select an output.
Does the laptop surround51 by retasking two mic jacks and headphone ?
I don't _think_ so. AFAICS it only has two jacks - one headphone/speaker, one mic. There's no third jack anywhere that I can see.
2012/3/17, Adam Williamson awilliam@redhat.com:
On Sat, 2012-03-17 at 10:04 +0800, Raymond Yau wrote:
2012/3/17, Adam Williamson awilliam@redhat.com:
Welp, pretty much as the topic says.
I just noticed today that sound is no longer playing from the internal speakers of my laptop, a 2010 model Sony Vaio Z. Plugging in headphones causes sound to be played fine through those. There are three possible choices for 'Connector' - 'Analog Speakers', 'Analog Output', and 'Analog Headphones' - but none of these seems to make sound come out of the internal speakers. The default is 'Analog Speakers', and when it's set to this, headphone output does work when headphones are plugged in.
I've verified that it's broken on Fedora 16 kernels 3.2.6-4, 3.2.8-3 and 3.2.10-1. It's also broken in a very recent Fedora 17 kernel, 3.3.0rc6 or so. It works on a Fedora 16 live image, with kernel 3.1.0-1. Unfortunately the kernels before 3.2.6 have been trashed from Fedora's buildsystem archives, I think, so it's hard to narrow things down any further :/
the alsa-info output is http://www.alsa-project.org/db/?f=368e2359757b537d4daa0f5399830d3942540196 .
it is a bug if sound preference allow user to select speaker when auto-mute mode is enabled (the speaker is automatically muted by the driver when you plug the headphone)
Then I guess that's another bug :) Because yes, the laptop does auto-mute by default. When the speakers are actually working, if I plug in headphones, the speakers get muted and the headphones work. No need to manually select an output.
http://www.intel.com/support/motherboards/desktop/sb/cs-020642.htm#multistre...
AFAIK, multistreaming is not yet implemented for desktop using realtek codecs
The ALC889 provides ten DAC channels that simultaneously support 7.1 sound playback, plus 2 channels of independent stereo sound output (multiple streaming) through the front panel stereo outputs.
On Sat, 2012-03-17 at 10:40 +0800, Raymond Yau wrote:
2012/3/17, Adam Williamson awilliam@redhat.com:
On Sat, 2012-03-17 at 10:04 +0800, Raymond Yau wrote:
2012/3/17, Adam Williamson awilliam@redhat.com:
Welp, pretty much as the topic says.
I just noticed today that sound is no longer playing from the internal speakers of my laptop, a 2010 model Sony Vaio Z. Plugging in headphones causes sound to be played fine through those. There are three possible choices for 'Connector' - 'Analog Speakers', 'Analog Output', and 'Analog Headphones' - but none of these seems to make sound come out of the internal speakers. The default is 'Analog Speakers', and when it's set to this, headphone output does work when headphones are plugged in.
I've verified that it's broken on Fedora 16 kernels 3.2.6-4, 3.2.8-3 and 3.2.10-1. It's also broken in a very recent Fedora 17 kernel, 3.3.0rc6 or so. It works on a Fedora 16 live image, with kernel 3.1.0-1. Unfortunately the kernels before 3.2.6 have been trashed from Fedora's buildsystem archives, I think, so it's hard to narrow things down any further :/
the alsa-info output is http://www.alsa-project.org/db/?f=368e2359757b537d4daa0f5399830d3942540196 .
it is a bug if sound preference allow user to select speaker when auto-mute mode is enabled (the speaker is automatically muted by the driver when you plug the headphone)
Then I guess that's another bug :) Because yes, the laptop does auto-mute by default. When the speakers are actually working, if I plug in headphones, the speakers get muted and the headphones work. No need to manually select an output.
http://www.intel.com/support/motherboards/desktop/sb/cs-020642.htm#multistre...
AFAIK, multistreaming is not yet implemented for desktop using realtek codecs
The ALC889 provides ten DAC channels that simultaneously support 7.1 sound playback, plus 2 channels of independent stereo sound output (multiple streaming) through the front panel stereo outputs.
I think maybe you're misunderstanding the problem?
It's a very simple, straightforward problem. In the simplest possible configuration - I turn the laptop on, with absolutely default settings of everything (I've tested from a clean boot of a freshly written F17 live image), and nothing connected to *any* of the jacks, and attempt to play any kind of sound - I hear nothing. PA is running and shows the app playing sound, everything reports as if sound was being played, but no sound is heard over the internal speakers.
With kernel 3.1.0, it works fine: I do the above, and I hear sound. It's simply some kind of regression in the mapping for this chipset that occurred between 3.1.0 and 3.2.6.
I am not expecting to hear sound through both the internal speakers and the headphone jack. That's not what I'm saying.
2012/3/17, Adam Williamson awilliam@redhat.com:
On Sat, 2012-03-17 at 10:04 +0800, Raymond Yau wrote:
Does the laptop surround51 by retasking two mic jacks and headphone ?
I don't _think_ so. AFAICS it only has two jacks - one headphone/speaker, one mic. There's no third jack anywhere that I can see. --
you may need to use hda-analyzer to find out which ext mic is correct ?
does the internal mic work or not ?
[ 31.866570] ALSA sound/pci/hda/hda_codec.c:4927 autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker [ 31.866575] ALSA sound/pci/hda/hda_codec.c:4931 speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 31.866579] ALSA sound/pci/hda/hda_codec.c:4935 hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 31.866583] ALSA sound/pci/hda/hda_codec.c:4936 mono: mono_out=0x0 [ 31.866587] ALSA sound/pci/hda/hda_codec.c:4940 inputs: [ 31.866591] ALSA sound/pci/hda/hda_codec.c:4944 Internal Mic=0x12 [ 31.866595] ALSA sound/pci/hda/hda_codec.c:4944 Mic=0x18 [ 31.866598] ALSA sound/pci/hda/hda_codec.c:4944 Mic=0x19 [ 31.866601] ALSA sound/pci/hda/hda_codec.c:4946
Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out Control: name="Surround Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Mic Boost Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Mic Jack", index=0, device=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0000373c: IN OUT HP Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x04a1102e: [Jack] Mic at Ext Right Conn = 1/8, Color = Black DefAssociation = 0x2, Sequence = 0xe Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=02, enabled=1 Connection: 5 0x0c 0x0d 0x0e 0x0f 0x26*
Node 0x19 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out Control: name="Center Playback Switch", index=0, device=0 ControlAmp: chs=1, dir=Out, idx=0, ofs=0 Control: name="LFE Playback Switch", index=0, device=0 ControlAmp: chs=2, dir=Out, idx=0, ofs=0 Control: name="Mic Boost Volume", index=1, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Mic Jack", index=1, device=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0000373c: IN OUT HP Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x04a11030: [Jack] Mic at Ext Right Conn = 1/8, Color = Black DefAssociation = 0x3, Sequence = 0x0 Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=03, enabled=1 Connection: 5 0x0c 0x0d 0x0e 0x0f 0x26*
On Sat, 2012-03-17 at 11:10 +0800, Raymond Yau wrote:
2012/3/17, Adam Williamson awilliam@redhat.com:
On Sat, 2012-03-17 at 10:04 +0800, Raymond Yau wrote:
Does the laptop surround51 by retasking two mic jacks and headphone ?
I don't _think_ so. AFAICS it only has two jacks - one headphone/speaker, one mic. There's no third jack anywhere that I can see. --
you may need to use hda-analyzer to find out which ext mic is correct ?
I don't really care about the microphone socket. I just want the speakers to work. Or is it important for me to figure that out?
does the internal mic work or not ?
Yep - the GNOME sound settings 'Input level' meter shows a correct response when I talk or tap the chassis.
2012/3/17, Adam Williamson awilliam@redhat.com:
On Sat, 2012-03-17 at 11:10 +0800, Raymond Yau wrote:
2012/3/17, Adam Williamson awilliam@redhat.com:
On Sat, 2012-03-17 at 10:04 +0800, Raymond Yau wrote:
Does the laptop surround51 by retasking two mic jacks and headphone ?
I don't _think_ so. AFAICS it only has two jacks - one headphone/speaker, one mic. There's no third jack anywhere that I can see. --
you may need to use hda-analyzer to find out which ext mic is correct ?
I don't really care about the microphone socket. I just want the speakers to work. Or is it important for me to figure that out?
The auto parser also provide auto mic detection, external mic is used automatically selected.when you have one ext mic and one int mic.
you need a pin fixup or early patch to remove this redundant jack
Since the two mic jacks are capable of retasking as output jacks
This change the logic of auto mic detection.for those laptop with three/four audio jacks which support surround51/surround71
On Sat, 2012-03-17 at 13:11 +0800, Raymond Yau wrote:
2012/3/17, Adam Williamson awilliam@redhat.com:
On Sat, 2012-03-17 at 11:10 +0800, Raymond Yau wrote:
2012/3/17, Adam Williamson awilliam@redhat.com:
On Sat, 2012-03-17 at 10:04 +0800, Raymond Yau wrote:
Does the laptop surround51 by retasking two mic jacks and headphone ?
I don't _think_ so. AFAICS it only has two jacks - one headphone/speaker, one mic. There's no third jack anywhere that I can see. --
you may need to use hda-analyzer to find out which ext mic is correct ?
I don't really care about the microphone socket. I just want the speakers to work. Or is it important for me to figure that out?
The auto parser also provide auto mic detection, external mic is used automatically selected.when you have one ext mic and one int mic.
you need a pin fixup or early patch to remove this redundant jack
Since the two mic jacks are capable of retasking as output jacks
This change the logic of auto mic detection.for those laptop with three/four audio jacks which support surround51/surround71
oh, okay. so you need me to figure out which is the actual, physical mic jack so the other one can be masked. I suppose the third one might actually exist on a docking station, or something?
At Fri, 16 Mar 2012 16:10:09 -0700, Adam Williamson wrote:
Welp, pretty much as the topic says.
I just noticed today that sound is no longer playing from the internal speakers of my laptop, a 2010 model Sony Vaio Z. Plugging in headphones causes sound to be played fine through those. There are three possible choices for 'Connector' - 'Analog Speakers', 'Analog Output', and 'Analog Headphones' - but none of these seems to make sound come out of the internal speakers. The default is 'Analog Speakers', and when it's set to this, headphone output does work when headphones are plugged in.
I've verified that it's broken on Fedora 16 kernels 3.2.6-4, 3.2.8-3 and 3.2.10-1. It's also broken in a very recent Fedora 17 kernel, 3.3.0rc6 or so. It works on a Fedora 16 live image, with kernel 3.1.0-1. Unfortunately the kernels before 3.2.6 have been trashed from Fedora's buildsystem archives, I think, so it's hard to narrow things down any further :/
the alsa-info output is http://www.alsa-project.org/db/?f=368e2359757b537d4daa0f5399830d3942540196 .
At best, please provide the alsa-info.sh on the working kernel, too. You could install 3.1.x in addition to the current one just to check whether it works (i.e. no user-space side problem).
The codec amp values for the speaker pin in the alsa-info.sh output above looks OK, so the problem is something else such as GPIO. In the case of GPIO, it can be turned on/off by hda-verb, e.g.
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x01 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x01 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
and/or
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x02 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x02 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
Takashi
At Sat, 17 Mar 2012 11:00:33 +0100, Takashi Iwai wrote:
At Fri, 16 Mar 2012 16:10:09 -0700, Adam Williamson wrote:
Welp, pretty much as the topic says.
I just noticed today that sound is no longer playing from the internal speakers of my laptop, a 2010 model Sony Vaio Z. Plugging in headphones causes sound to be played fine through those. There are three possible choices for 'Connector' - 'Analog Speakers', 'Analog Output', and 'Analog Headphones' - but none of these seems to make sound come out of the internal speakers. The default is 'Analog Speakers', and when it's set to this, headphone output does work when headphones are plugged in.
I've verified that it's broken on Fedora 16 kernels 3.2.6-4, 3.2.8-3 and 3.2.10-1. It's also broken in a very recent Fedora 17 kernel, 3.3.0rc6 or so. It works on a Fedora 16 live image, with kernel 3.1.0-1. Unfortunately the kernels before 3.2.6 have been trashed from Fedora's buildsystem archives, I think, so it's hard to narrow things down any further :/
the alsa-info output is http://www.alsa-project.org/db/?f=368e2359757b537d4daa0f5399830d3942540196 .
At best, please provide the alsa-info.sh on the working kernel, too. You could install 3.1.x in addition to the current one just to check whether it works (i.e. no user-space side problem).
The codec amp values for the speaker pin in the alsa-info.sh output above looks OK, so the problem is something else such as GPIO. In the case of GPIO, it can be turned on/off by hda-verb, e.g.
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x01 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x01 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
and/or
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x02 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x02 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
Or, it might be some ALC889 COEF fixup. In anyway, try sound git tree, too git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
Or you can build alsa-driver externally without upgrading the whole kernel. I don't know the status of Fedora, but SUSE or Ubuntu provide the update kernel module from the latest alsa-driver snapshot.
The latest alsa-driver snapshot tarball is found at ftp://ftp.suse.com/pub/people/tiwai/snapshot/alsa-driver-snapshot.tar.gz
Takashi
On Sat, 2012-03-17 at 11:00 +0100, Takashi Iwai wrote:
At Fri, 16 Mar 2012 16:10:09 -0700, Adam Williamson wrote:
Welp, pretty much as the topic says.
I just noticed today that sound is no longer playing from the internal speakers of my laptop, a 2010 model Sony Vaio Z. Plugging in headphones causes sound to be played fine through those. There are three possible choices for 'Connector' - 'Analog Speakers', 'Analog Output', and 'Analog Headphones' - but none of these seems to make sound come out of the internal speakers. The default is 'Analog Speakers', and when it's set to this, headphone output does work when headphones are plugged in.
I've verified that it's broken on Fedora 16 kernels 3.2.6-4, 3.2.8-3 and 3.2.10-1. It's also broken in a very recent Fedora 17 kernel, 3.3.0rc6 or so. It works on a Fedora 16 live image, with kernel 3.1.0-1. Unfortunately the kernels before 3.2.6 have been trashed from Fedora's buildsystem archives, I think, so it's hard to narrow things down any further :/
the alsa-info output is http://www.alsa-project.org/db/?f=368e2359757b537d4daa0f5399830d3942540196 .
At best, please provide the alsa-info.sh on the working kernel, too. You could install 3.1.x in addition to the current one just to check whether it works (i.e. no user-space side problem).
The codec amp values for the speaker pin in the alsa-info.sh output above looks OK, so the problem is something else such as GPIO. In the case of GPIO, it can be turned on/off by hda-verb, e.g.
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x01 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x01 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
and/or
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x02 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x02 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
Sorry for the very very late reply on this - I just worked back around to it on my non-urgent todo list :/
So, the situation is unchanged all the way up to kernel 3.4.6: basic playback through the laptop speakers does not work. I re-installed kernel 3.1.0 to verify that it still works there, it does.
I'm attaching the alsa-info output from working 3.1.0 and still-not-working 3.4.6. Remember, alsa-info output from not-working 3.2.6 is still available at http://www.alsa-project.org/db/?f=368e2359757b537d4daa0f5399830d3942540196 .
I installed hda-verb and ran the commands suggested by tiwai (above) after booting 3.4.6. It doesn't appear to make any difference (I tested sound before running any commands, after running the first three, and after running all six; didn't work in any case).
I would need more guidance to try and "use hda-analyzer to find out which ext mic is correct", as Raymond Yau suggested. Don't let the @redhat.com fool you, I'm not a guru =) I have hda-analyzer installed and working but I couldn't tell one end of it from the other without help, I'm afraid.
I don't know if tiwai's later suggestion to try the sound.git tree is still relevant, since I expect all of the stuff there that was 'new' back in March has been merged into later kernels since, and it's still broken. But if so, send me the word and I'll try it.
Thanks! I promise to reply more promptly for the next few weeks at least.
At Wed, 25 Jul 2012 14:52:53 -0700, Adam Williamson wrote:
On Sat, 2012-03-17 at 11:00 +0100, Takashi Iwai wrote:
At Fri, 16 Mar 2012 16:10:09 -0700, Adam Williamson wrote:
Welp, pretty much as the topic says.
I just noticed today that sound is no longer playing from the internal speakers of my laptop, a 2010 model Sony Vaio Z. Plugging in headphones causes sound to be played fine through those. There are three possible choices for 'Connector' - 'Analog Speakers', 'Analog Output', and 'Analog Headphones' - but none of these seems to make sound come out of the internal speakers. The default is 'Analog Speakers', and when it's set to this, headphone output does work when headphones are plugged in.
I've verified that it's broken on Fedora 16 kernels 3.2.6-4, 3.2.8-3 and 3.2.10-1. It's also broken in a very recent Fedora 17 kernel, 3.3.0rc6 or so. It works on a Fedora 16 live image, with kernel 3.1.0-1. Unfortunately the kernels before 3.2.6 have been trashed from Fedora's buildsystem archives, I think, so it's hard to narrow things down any further :/
the alsa-info output is http://www.alsa-project.org/db/?f=368e2359757b537d4daa0f5399830d3942540196 .
At best, please provide the alsa-info.sh on the working kernel, too. You could install 3.1.x in addition to the current one just to check whether it works (i.e. no user-space side problem).
The codec amp values for the speaker pin in the alsa-info.sh output above looks OK, so the problem is something else such as GPIO. In the case of GPIO, it can be turned on/off by hda-verb, e.g.
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x01 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x01 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
and/or
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x02 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x02 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
Sorry for the very very late reply on this - I just worked back around to it on my non-urgent todo list :/
So, the situation is unchanged all the way up to kernel 3.4.6: basic playback through the laptop speakers does not work. I re-installed kernel 3.1.0 to verify that it still works there, it does.
I'm attaching the alsa-info output from working 3.1.0 and still-not-working 3.4.6. Remember, alsa-info output from not-working 3.2.6 is still available at http://www.alsa-project.org/db/?f=368e2359757b537d4daa0f5399830d3942540196 .
I installed hda-verb and ran the commands suggested by tiwai (above) after booting 3.4.6. It doesn't appear to make any difference (I tested sound before running any commands, after running the first three, and after running all six; didn't work in any case).
I would need more guidance to try and "use hda-analyzer to find out which ext mic is correct", as Raymond Yau suggested. Don't let the @redhat.com fool you, I'm not a guru =) I have hda-analyzer installed and working but I couldn't tell one end of it from the other without help, I'm afraid.
I don't know if tiwai's later suggestion to try the sound.git tree is still relevant, since I expect all of the stuff there that was 'new' back in March has been merged into later kernels since, and it's still broken. But if so, send me the word and I'll try it.
Thanks! I promise to reply more promptly for the next few weeks at least.
OK, then try the following two patches. The first one is to make the speaker-pin as the primary output like the earlier kernel (3.1.x), and the second one is to add the COEF setup for ALC889. Check each of them alone gives any difference.
Takashi
---
On Thu, 2012-07-26 at 07:47 +0200, Takashi Iwai wrote:
I don't know if tiwai's later suggestion to try the sound.git tree is still relevant, since I expect all of the stuff there that was 'new' back in March has been merged into later kernels since, and it's still broken. But if so, send me the word and I'll try it.
Thanks! I promise to reply more promptly for the next few weeks at least.
OK, then try the following two patches. The first one is to make the speaker-pin as the primary output like the earlier kernel (3.1.x), and the second one is to add the COEF setup for ALC889. Check each of them alone gives any difference.
First patch on its own - alc-no-primary-hp-out.diff - fixes the bug. Output through the speakers works. I also tested that it doesn't do anything bad to the speaker/headphone output: plugging in headphones routes the output through that socket automatically, no need to change any PA setting, and unplugging the headphones sends it back through the internal speakers again. The internal mic works fine in all cases. So with just the first patch, everything works correctly as far as I can test (I don't have an external mic to check).
Didn't try the other patch on its own or in combination yet. I'll do so tomorrow, unless you tell me it's not necessary. Thanks!
At Thu, 26 Jul 2012 22:26:42 -0700, Adam Williamson wrote:
On Thu, 2012-07-26 at 07:47 +0200, Takashi Iwai wrote:
I don't know if tiwai's later suggestion to try the sound.git tree is still relevant, since I expect all of the stuff there that was 'new' back in March has been merged into later kernels since, and it's still broken. But if so, send me the word and I'll try it.
Thanks! I promise to reply more promptly for the next few weeks at least.
OK, then try the following two patches. The first one is to make the speaker-pin as the primary output like the earlier kernel (3.1.x), and the second one is to add the COEF setup for ALC889. Check each of them alone gives any difference.
First patch on its own - alc-no-primary-hp-out.diff - fixes the bug. Output through the speakers works. I also tested that it doesn't do anything bad to the speaker/headphone output: plugging in headphones routes the output through that socket automatically, no need to change any PA setting, and unplugging the headphones sends it back through the internal speakers again. The internal mic works fine in all cases. So with just the first patch, everything works correctly as far as I can test (I don't have an external mic to check).
OK, then it becomes interesting. It seems that the hardware has some hard-coded pin assignment and doesn't allow to use the different route.
Could you verify that the following patch works? Drop the previous patches when you apply this.
thanks,
Takashi
--- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Workaround for silent output on VAIO TT-Z with ALC889
On recent kernels, Realtek codec parser tries to optimize the routing aggressively and take the headphone output as primary at first. This caused a regression on VAIO TT-Z with ALC889, the silent output from the speaker.
The problem seems that the speaker pin must be connected to the first DAC (0x02) on this machine by some reason although the codec itself advertises the flexible routing with any DACs.
This patch adds a fix-up for choosing the speaker pin as the primary so that the right DAC is assigned on this device.
Reported-by: Adam Williamson awilliam@redhat.com Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/pci/hda/patch_realtek.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index f141395..59c9594 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -203,6 +203,7 @@ struct alc_spec { unsigned int shared_mic_hp:1; /* HP/Mic-in sharing */ unsigned int inv_dmic_fixup:1; /* has inverted digital-mic workaround */ unsigned int inv_dmic_muted:1; /* R-ch of inv d-mic is muted? */ + unsigned int no_primary_hp:1; /* Don't prefer HP pins to speaker pins */
/* auto-mute control */ int automute_mode; @@ -4323,7 +4324,8 @@ static int alc_parse_auto_config(struct hda_codec *codec, return 0; /* can't find valid BIOS pin config */ }
- if (cfg->line_out_type == AUTO_PIN_SPEAKER_OUT && + if (!spec->no_primary_hp && + cfg->line_out_type == AUTO_PIN_SPEAKER_OUT && cfg->line_outs <= cfg->hp_outs) { /* use HP as primary out */ cfg->speaker_outs = cfg->line_outs; @@ -5050,6 +5052,7 @@ enum { ALC889_FIXUP_MBP_VREF, ALC889_FIXUP_IMAC91_VREF, ALC882_FIXUP_INV_DMIC, + ALC882_FIXUP_NO_PRIMARY_HP, };
static void alc889_fixup_coef(struct hda_codec *codec, @@ -5171,6 +5174,17 @@ static void alc889_fixup_imac91_vref(struct hda_codec *codec, spec->keep_vref_in_automute = 1; }
+/* Don't take HP output as primary + * strangely, the speaker output doesn't work on VAIO TT Z through DAC 0x05 + */ +static void alc882_fixup_no_primary_hp(struct hda_codec *codec, + const struct alc_fixup *fix, int action) +{ + struct alc_spec *spec = codec->spec; + if (action == ALC_FIXUP_ACT_PRE_PROBE) + spec->no_primary_hp = 1; +} + static const struct alc_fixup alc882_fixups[] = { [ALC882_FIXUP_ABIT_AW9D_MAX] = { .type = ALC_FIXUP_PINS, @@ -5357,6 +5371,10 @@ static const struct alc_fixup alc882_fixups[] = { .type = ALC_FIXUP_FUNC, .v.func = alc_fixup_inv_dmic_0x12, }, + [ALC882_FIXUP_NO_PRIMARY_HP] = { + .type = ALC_FIXUP_FUNC, + .v.func = alc882_fixup_no_primary_hp, + }, };
static const struct snd_pci_quirk alc882_fixup_tbl[] = { @@ -5391,6 +5409,7 @@ static const struct snd_pci_quirk alc882_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x1971, "Asus W2JC", ALC882_FIXUP_ASUS_W2JC), SND_PCI_QUIRK(0x1043, 0x835f, "Asus Eee 1601", ALC888_FIXUP_EEE1601), SND_PCI_QUIRK(0x104d, 0x9047, "Sony Vaio TT", ALC889_FIXUP_VAIO_TT), + SND_PCI_QUIRK(0x104d, 0x905a, "Sony Vaio Z", ALC882_FIXUP_NO_PRIMARY_HP),
/* All Apple entries are in codec SSIDs */ SND_PCI_QUIRK(0x106b, 0x00a0, "MacBookPro 3,1", ALC889_FIXUP_MBP_VREF),
On Fri, 2012-07-27 at 09:58 +0200, Takashi Iwai wrote:
First patch on its own - alc-no-primary-hp-out.diff - fixes the bug. Output through the speakers works. I also tested that it doesn't do anything bad to the speaker/headphone output: plugging in headphones routes the output through that socket automatically, no need to change any PA setting, and unplugging the headphones sends it back through the internal speakers again. The internal mic works fine in all cases. So with just the first patch, everything works correctly as far as I can test (I don't have an external mic to check).
OK, then it becomes interesting. It seems that the hardware has some hard-coded pin assignment and doesn't allow to use the different route.
Could you verify that the following patch works? Drop the previous patches when you apply this.
The patch fails utterly to apply against 3.5 - 6 out of 6 hunks failed. What's it against? 3.4? Fedora went to 3.5 yesterday...I guess I can re-diff.
On Fri, 2012-07-27 at 11:20 -0700, Adam Williamson wrote:
On Fri, 2012-07-27 at 09:58 +0200, Takashi Iwai wrote:
First patch on its own - alc-no-primary-hp-out.diff - fixes the bug. Output through the speakers works. I also tested that it doesn't do anything bad to the speaker/headphone output: plugging in headphones routes the output through that socket automatically, no need to change any PA setting, and unplugging the headphones sends it back through the internal speakers again. The internal mic works fine in all cases. So with just the first patch, everything works correctly as far as I can test (I don't have an external mic to check).
OK, then it becomes interesting. It seems that the hardware has some hard-coded pin assignment and doesn't allow to use the different route.
Could you verify that the following patch works? Drop the previous patches when you apply this.
The patch fails utterly to apply against 3.5 - 6 out of 6 hunks failed. What's it against? 3.4? Fedora went to 3.5 yesterday...I guess I can re-diff.
Oh, I just noticed, there's a Launchpad report for the same/very similar bug here:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/960124
which has some discussion that may be interesting (apparently the extra mic pin exists because the 'headphone' output can actually handle headsets, or something). This bug seems possibly to be discussing a newer model of the Z (Z13), but it certainly looks very similar.
On Fri, 2012-07-27 at 09:58 +0200, Takashi Iwai wrote:
At Thu, 26 Jul 2012 22:26:42 -0700, Adam Williamson wrote:
On Thu, 2012-07-26 at 07:47 +0200, Takashi Iwai wrote:
I don't know if tiwai's later suggestion to try the sound.git tree is still relevant, since I expect all of the stuff there that was 'new' back in March has been merged into later kernels since, and it's still broken. But if so, send me the word and I'll try it.
Thanks! I promise to reply more promptly for the next few weeks at least.
OK, then try the following two patches. The first one is to make the speaker-pin as the primary output like the earlier kernel (3.1.x), and the second one is to add the COEF setup for ALC889. Check each of them alone gives any difference.
First patch on its own - alc-no-primary-hp-out.diff - fixes the bug. Output through the speakers works. I also tested that it doesn't do anything bad to the speaker/headphone output: plugging in headphones routes the output through that socket automatically, no need to change any PA setting, and unplugging the headphones sends it back through the internal speakers again. The internal mic works fine in all cases. So with just the first patch, everything works correctly as far as I can test (I don't have an external mic to check).
OK, then it becomes interesting. It seems that the hardware has some hard-coded pin assignment and doesn't allow to use the different route.
Could you verify that the following patch works? Drop the previous patches when you apply this.
OK, a re-diffed version of that patch against 3.5 works. (For the record, it looks like it's against a newer version of the file than is included in 3.5, and also it seems to have spaces in place of tabs - not sure if that's a problem on your end or on mine). So that looks good to me, assuming none of the stuff on the Launchpad bug is a roadblock. Thanks! One small nit: it's just the 'Vaio Z', not 'Vaio TT Z'. 'Vaio TT' is a separate (rather older) system; there's no such thing as a 'TT Z', to my knowledge. You might want to say 'some Vaio Zs', or something like that, since there have been several generations of the Z, some of which this won't apply to...
At Fri, 27 Jul 2012 15:55:41 -0700, Adam Williamson wrote:
On Fri, 2012-07-27 at 09:58 +0200, Takashi Iwai wrote:
At Thu, 26 Jul 2012 22:26:42 -0700, Adam Williamson wrote:
On Thu, 2012-07-26 at 07:47 +0200, Takashi Iwai wrote:
I don't know if tiwai's later suggestion to try the sound.git tree is still relevant, since I expect all of the stuff there that was 'new' back in March has been merged into later kernels since, and it's still broken. But if so, send me the word and I'll try it.
Thanks! I promise to reply more promptly for the next few weeks at least.
OK, then try the following two patches. The first one is to make the speaker-pin as the primary output like the earlier kernel (3.1.x), and the second one is to add the COEF setup for ALC889. Check each of them alone gives any difference.
First patch on its own - alc-no-primary-hp-out.diff - fixes the bug. Output through the speakers works. I also tested that it doesn't do anything bad to the speaker/headphone output: plugging in headphones routes the output through that socket automatically, no need to change any PA setting, and unplugging the headphones sends it back through the internal speakers again. The internal mic works fine in all cases. So with just the first patch, everything works correctly as far as I can test (I don't have an external mic to check).
OK, then it becomes interesting. It seems that the hardware has some hard-coded pin assignment and doesn't allow to use the different route.
Could you verify that the following patch works? Drop the previous patches when you apply this.
OK, a re-diffed version of that patch against 3.5 works. (For the record, it looks like it's against a newer version of the file than is included in 3.5, and also it seems to have spaces in place of tabs - not sure if that's a problem on your end or on mine). So that looks good to me, assuming none of the stuff on the Launchpad bug is a roadblock. Thanks! One small nit: it's just the 'Vaio Z', not 'Vaio TT Z'. 'Vaio TT' is a separate (rather older) system; there's no such thing as a 'TT Z', to my knowledge. You might want to say 'some Vaio Zs', or something like that, since there have been several generations of the Z, some of which this won't apply to...
OK, I fixed the comment and applied the patch now to sound git tree.
thanks,
Takashi
On Sun, 2012-07-29 at 10:09 +0200, Takashi Iwai wrote:
OK, I fixed the comment and applied the patch now to sound git tree.
Thanks a lot! Did you take a look at the info in the launchpad thread just to see if any of it made the problem look more complex or anything?
On Sun, 2012-07-29 at 10:09 +0200, Takashi Iwai wrote:
OK, a re-diffed version of that patch against 3.5 works. (For the record, it looks like it's against a newer version of the file than is included in 3.5, and also it seems to have spaces in place of tabs - not sure if that's a problem on your end or on mine). So that looks good to me, assuming none of the stuff on the Launchpad bug is a roadblock. Thanks! One small nit: it's just the 'Vaio Z', not 'Vaio TT Z'. 'Vaio TT' is a separate (rather older) system; there's no such thing as a 'TT Z', to my knowledge. You might want to say 'some Vaio Zs', or something like that, since there have been several generations of the Z, some of which this won't apply to...
OK, I fixed the comment and applied the patch now to sound git tree.
Any chance this'll make it to 3.5 upstream? It'd be nice to have it fixed for the distros using that kernel series. I'm on 3.5.4 now and it still doesn't seem to be in.
At Wed, 19 Sep 2012 13:47:09 -0700, Adam Williamson wrote:
On Sun, 2012-07-29 at 10:09 +0200, Takashi Iwai wrote:
OK, a re-diffed version of that patch against 3.5 works. (For the record, it looks like it's against a newer version of the file than is included in 3.5, and also it seems to have spaces in place of tabs - not sure if that's a problem on your end or on mine). So that looks good to me, assuming none of the stuff on the Launchpad bug is a roadblock. Thanks! One small nit: it's just the 'Vaio Z', not 'Vaio TT Z'. 'Vaio TT' is a separate (rather older) system; there's no such thing as a 'TT Z', to my knowledge. You might want to say 'some Vaio Zs', or something like that, since there have been several generations of the Z, some of which this won't apply to...
OK, I fixed the comment and applied the patch now to sound git tree.
Any chance this'll make it to 3.5 upstream? It'd be nice to have it fixed for the distros using that kernel series. I'm on 3.5.4 now and it still doesn't seem to be in.
I submitted the rebased patch to stable kernel right now.
thanks,
Takashi
On Thu, 2012-09-20 at 07:44 +0200, Takashi Iwai wrote:
At Wed, 19 Sep 2012 13:47:09 -0700, Adam Williamson wrote:
On Sun, 2012-07-29 at 10:09 +0200, Takashi Iwai wrote:
OK, a re-diffed version of that patch against 3.5 works. (For the record, it looks like it's against a newer version of the file than is included in 3.5, and also it seems to have spaces in place of tabs - not sure if that's a problem on your end or on mine). So that looks good to me, assuming none of the stuff on the Launchpad bug is a roadblock. Thanks! One small nit: it's just the 'Vaio Z', not 'Vaio TT Z'. 'Vaio TT' is a separate (rather older) system; there's no such thing as a 'TT Z', to my knowledge. You might want to say 'some Vaio Zs', or something like that, since there have been several generations of the Z, some of which this won't apply to...
OK, I fixed the comment and applied the patch now to sound git tree.
Any chance this'll make it to 3.5 upstream? It'd be nice to have it fixed for the distros using that kernel series. I'm on 3.5.4 now and it still doesn't seem to be in.
I submitted the rebased patch to stable kernel right now.
Got the mail for that, thanks a lot!
participants (3)
-
Adam Williamson -
Raymond Yau -
Takashi Iwai