Description of problem: Audio cable is plugged into ultra dock and into amplifier. Kernel thinks it's a headphone but no audio is output (both are wrong) Works on kernel 3.18.8-201.fc21.x86_64, there the kernel thinks nothing special of it (considers it the same as the built-in speakers) and audio is output (both are correct). Version-Release number of selected component (if applicable): 3.19.1-201 How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
A small mistake: on the 3.18 kernel the audio output of the dock is also seen as a headphone, but sound _is_ produced
Also occurs on the 3.19.2-201 update
Also occurs on the kernel-3.19.3-200.fc21.x86_64 update This is on a Lenovo thinkpad T440s
Similar problem, Lenovo T420s with docking station, kernel-3.19.3-200.fc21.x86_64 No audio output through docking station, only output sound device listed is headphones, audio will work with laptop headphone jack but not through docking station. This is a regression.
Same here with Lenovo T540p and kernels 3.19.3-200.fc21.x86_64 and 3.19.4-200.fc21.x86_64. Kernels 3.17.7-300.fc21.x86_64 and 3.18.9-200.fc21.x86_64 work fine. I'll attach outputs of `alsa-info.sh --no-upload --output alsa-info-$(uname -r).txt` for mentioned kernels.
Created attachment 1015994 [details] Output of alsa-info.sh on 3.17.7-300.fc21.x86_64 kernel (audio working)
Created attachment 1015995 [details] Output of alsa-info.sh on kernel-3.19.4-200.fc21.x86_64 kernel (audio not working)
still true on 3.19.5-200.fc21.x86_64
*** Bug 1205073 has been marked as a duplicate of this bug. ***
This is still issue with kernel-4.0.4-301.fc22.x86_64
Hi! I don't know if I am stating the obvious here - if so, please ignore: It seems to me that the problem is not a real regression. I do believe, that the changes to the kernel (I am guessing here, that the kernel now does not send sound to audio outputs that have no connected headphones) just made a previously existing problem visible: When headphones are connected to the audio jack of the dock, pavucontrol lists them as "Headphones" an states that the Speakers are unavailable. This is the same behaviour as when the headphones are connected to the audio jack of the laptop itself. In the case of connecting to the audio jack of the laptop, it makes sense to disable the speakers, however the same behaviour makes no sense when the headphones are connected to the audio jack of the dock - as in this case no sound will be hearable. However if you use pavucontrol to switch back to the Speaker (which is marked as unavailable) you can hear the sound again - using headphones connecting to the dock). So to me this seems to be either a driver issue that cannot distinguish between the laptop audio jack and the dock audio jack. They are listed as separate jacks in my alsa-info output: --- excerpt from the output of alsa-info.sh ---- Node 0x15 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Headphone Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Headphone Jack", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0001001c: OUT HP EAPD Detect EAPD 0x2: EAPD Pin Default 0x0321101f: [Jack] HP Out at Ext Left Conn = 1/8, Color = Black DefAssociation = 0x1, Sequence = 0xf Pin-ctls: 0xc0: OUT HP Unsolicited: tag=01, enabled=1 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 2 0x0c 0x0d* Node 0x16 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Line Out Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Dock Headphone Jack", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0001001c: OUT HP EAPD Detect EAPD 0x2: EAPD Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Unsolicited: tag=02, enabled=1 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 2 0x0c* 0x0d Unfortunately I cannot test my hypothesis any more, as I upgraded to F22 (problem still persists with kernel-4.04) and do not have a 3.18 kernel installed any longer.
Rex, any thoughts on comment 11, please?
Maybe technically it's not a regression. However, from a user perspective (the one that counts IMHO) is really is. It worked correctly before, now it doesn't ==> regression. pavucontrol detects plugging in the speakers into the dock as 'headphones'. When I switch them to 'speakers' the speakers work and the headphones plug on the laptop itself is switched off. When I switch them to 'headphones' the headphones plug on the laptop itself is switched on and the speakers don't work. Seems to me that the detection logic was messed up. IMHO it should do: 1- if something plugged in on laptop: use 'headphones', else 2- if something plugged in on dock: use 'speakers', else 3- use 'headphones'
Actually: Number 3- should be use 'speakers' as default Is there any additional info or help that I can give maybe?
I have this problem as well. I don't know on which kernel it started, because I just assumed the audio port on the dock had died. I'm on 4.0.4-202.fc21.x86_64 now. Using pavucontrol, I can switch the "built-in analog stereo" device to "Speakers (unavailable)" and sound comes from speakers connected to the dock audio port. If I open the Gnome sound setting app and click output device listed there, it switches the pavucontrol display back to "Headphones" and sound does not work. --Guy
Re: comment #11 I don't know, but other pulseaudio maintainers might, we can reassign to pulseaudio to see.
The problem appeared after the following kernel commit: commit 3abb4f4d0e7aaad0d12004b5057f4486a688752b Author: David Henningsson <david.henningsson> Date: Thu Oct 16 15:33:46 2014 +0200 ALSA: hda - Use "Line Out" name instead of "PCM" when there are other outputs In case there are speakers or headphones as well, anything that only covers the line out should not be labelled "PCM". Let's name it "Line Out" instead for clarity. Signed-off-by: David Henningsson <david.henningsson> Signed-off-by: Takashi Iwai <tiwai> diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index dc13cce..06d7210 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -1055,7 +1055,7 @@ static const char *get_line_out_pfx(struct hda_codec *codec, int ch, /* for a single channel output, we don't have to name the channel */ if (cfg->line_outs == 1 && !spec->multi_ios) - return "PCM"; + return "Line Out"; if (ch >= ARRAY_SIZE(channel_name)) { snd_BUG(); When laptop is docked, audio output goes through "Speaker+LO" instead of PCM as was before. To workaround this I run after docking: $ amixer -c 1 sset "Speaker+LO" 100 > /dev/null
(In reply to Viktor Ashirov from comment #17) > The problem appeared after the following kernel commit: > commit 3abb4f4d0e7aaad0d12004b5057f4486a688752b So lets say this was bug in Kernel/Alsa and it got fixed, where it should be adjusted now? Is is PA issue or not? > To workaround this I run after docking: > $ amixer -c 1 sset "Speaker+LO" 100 > /dev/null This works for me.
Hi! As the following works for me too, > $ amixer -c 1 sset "Speaker+LO" 100 > /dev/null My current workaround is: I added this to a script that is executed by a udev-rule whenever the dock is connected: $ cat /usr/local/sbin/thinkpad-dock.sh #!/bin/bash sleep 0.5 DOCKED=$(cat /sys/devices/platform/dock.0/docked) if [ $DOCKED ]; then amixer -c 1 sset "Speaker+LO" 100 > /dev/null # touch /tmp/DOCKED.test #else # touch /tmp/NOT_DOCKED.test fi $cat /etc/udev/rules.d/81-thinkpad-dock.rules SUBSYSTEM=="usb",ATTRS{product}=="Lenovo ThinkPad Dock", ACTION=="add", RUN+="/usr/local/sbin/thinkpad-dock.sh" Maybe this helps others. Use at your own risk.
I experience the same bug with a new Thinkpad T450s and a Lenovo Pro Dock. For me the following commands temporarily fix the problem: amixer -c 1 cset numid=5,iface=MIXER,name='Speaker Playback Switch' on amixer -c 1 cset numid=1,iface=MIXER,name='Speaker+LO Playback Volume' 100% Hope that helps somebody. The above did not work for me as "Speaker+LO" did not exist.
This issue appears to be fixed for me. Not sure what was the actual fix, but most recently, I updated the kernel to 4.1.3 version.
Ah cool, just tried it and works for me too. kernel 4.1.3-200.fc22.x86_64
I'm running F21 and uname sez my kernel version is 4.1.5-100.fc21.x86_64 Should not 4.1.5-100 include 4.1.3-200 fixes? Or am totally misunderstanding the release numbering scheme? Because when I plug my speakers into my UltraDock audio jack, I still get nothing. When I plug them into the W541 audio jack, pavucontrol notices that the 'headphones' are in use and the speakers work. Nothing appears to change if anything's plugged into the dock audio jack.
Hi, I have never docked my lenovo z40-70. Was OK in Fedora 22 but after a fresh Fedora 23 install speaker is unavailable and headphone plugged every time I boot. Hitting the same bug. [root@lenovoz40 rules.d]# uname -a Linux lenovoz40 4.2.3-300.fc23.x86_64 #1 SMP Mon Oct 5 15:42:54 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux [root@lenovoz40 rules.d]# cat /etc/fedora-release Fedora release 23 (Twenty Three) [root@lenovoz40 rules.d]#
Hi, Upgraded to last kernel and issue remains. I altered in bios setup the DISCRETE (internal Intel and NVIDIA cards) to Internal only and issue remains. [root@lenovoz40 ~]# uname -a Linux lenovoz40 4.3.3-300.fc23.x86_64 #1 SMP Tue Jan 5 23:31:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Hi, I have uploaded alsa-info.sh to alsaproject. http://www.alsa-project.org/db/?f=e4292679b2dc1d066e4a4db9c0e81325c8d6b169 [root@lenovoz40 Backups]# uname -a Linux lenovoz40 4.3.3-300.fc23.x86_64 #1 SMP Tue Jan 5 23:31:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Created attachment 1116739 [details] output for alsactl -d init output for alsactl -d init [root@lenovoz40 Backups]# alsactl -v alsactl version 1.0.29 [root@lenovoz40 Backups]# uname -a Linux lenovoz40 4.3.3-300.fc23.x86_64 #1 SMP Tue Jan 5 23:31:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux