Created attachment 119241 [details] alsa_info output from linux 3.13rc4 No sound from the speakers, headphones. Activating "automute" while playing (aplay) fades in sound on headphones (the sound fades in without volume levels changing in alsamxer; the fade in time is about 2 seconds). When automute is activated, after aplay stops playing, the volume alternates between muted/unmuted at about 2 times per second. Killing pulseaudio doesn't change anything. Last known working kernel is 3.11. With that version, alsamixer is showing a lot of externally non-existing outputs for surround, LFE etc, but the front speakers and the headphones work as intended. The breakage appears first in 3.12 where I could locate commits such as fc39a7ea: "ALSA: hda - Drop static quirk for Toshiba Satellite L40-10Q The BIOS provides good pin-configurations, so we can drop the static quirk now." For this reason I went to the lengths of updating the bios to the latest available for this machine from Toshiba's archives, which is V2.30 dated 2008-03-18, but it brought no improvement. I've seen the bug 64971, so I tried linux 3.13rc4, which contains the fixes for it, but they don't help. They do change thigs a little compared to 3.12, but not much. Still no sound.
Created attachment 119251 [details] alsa_info output from linux 3.11 - last known working version
When the auto-muting is disabled, do the outputs from the headphone and the speaker work as expected? And, can they be muted and adjusted individually via "Headphone" and "Speaker" mixer mute/volume? If both are yes, the problem is likely the headphone jack detection and its auto-muting. Also, with 3.11 kernel, did the machine mute the speaker output automatically when the headphone is plugged? If so, we can simply disable the jack detection on this machine. The BIOS pin already looks good in 3.11, so it's no issue of BIOS, but most likely just the unexpected behavior of the hardware.
When auto-muting is disabled nothing works at all. Enabling it, makes the sound strangely "fade in" on the headphones. Nothing on the speakers.
With 3.11, the speaker output does seem to be automatically muted when headphone is plugged, as the speakers stop playing but nothing is changed in alsamixer.
OK, then create a file containing the following as /lib/firmware/alsa/laptop: [codec] 0x11d41986 0x1179ff40 0 [hint] jack_detect = false Then, pass patch=alsa/laptop option to snd-hda-intel module. This will remove the unnecessary auto-mute feature, at least. (It'll remove the auto-mic selection as well, but let's sort out the output problems at first.) If the above still doesn't work, please give alsa-info.sh output at this state. Thanks.
It doesn't work. The auto-mute option is gone from alsamixer and there is no sound from the speakers or from the headphones.
Created attachment 119261 [details] alsa_info output from 3.13rc4 with fix1 - the jack-detect removal
Created attachment 123401 [details] alsa_info output from linux 3.13.0 Hi there, On 3.13 the sound is still not coming from the speakers. The headphones do work if the automute is on (it still does the fading in at the beggining of playback).
Please give alsa-info.sh output while you're playing from the speaker. The attached alsa-info looks at the state with the headphone plugged, thus PA muted the speaker.
Created attachment 123591 [details] alsa_info output from linux 3.13.0 without headphones plugged
speakers were still muted when headphone not plugged use alsamixer -c0 to unmute speaker playback switch Simple mixer control 'Speaker',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 0 [0%] [-46.50dB] [off] Front Right: Playback 0 [0%] [-46.50dB] [off] Node 0x1b [Pin Complex] wcaps 0x400185: Stereo Amp-Out Control: name="Speaker Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Speaker Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Speaker Phantom Jack", index=0, device=0 Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=1 Amp-Out vals: [0x80 0x80] https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/?id=ba579eb7b30791751f556ee01905636cda50c864 what is the exact meaning of "Make this change so that manual corrections to module-init-tools file(s) are not required." ?
the amp out of node 3 was above 0dB on kernel 3.11 Node 0x03 [Audio Output] wcaps 0x44d: Stereo Amp-Out Device: name="AD198x Analog", type="Audio", device=0 Amp-Out caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-Out vals: [0x1e 0x1e]
Created attachment 123681 [details] alsa_info output from linux 3.13.0, no headphones, no mute, no sound No sound from speakers no matter what.
The Speaker mixer element is still muted in comment 13. But, at the same time, "Headphone Jack" element reports true. So, the driver believes the headphone being plugged. If it's incorrect, it means that the jack detection is broken on your machine. Then the question is why jack_detect = false didn't work. Did you try without PulseAudio, such as aplay -Dplughw -vv foo.wav ??
seem suspend resume problem [ 404.134452] PM: early resume of devices complete after 0.304 msecs [ 404.136902] snd_hda_intel 0000:00:1b.0: irq 43 for MSI/MSI-X [ 404.137018] usb usb2: root hub lost power or was reset -- [ 542.591105] PM: early resume of devices complete after 0.304 msecs [ 542.593628] snd_hda_intel 0000:00:1b.0: irq 43 for MSI/MSI-X [ 542.593947] usb usb2: root hub lost power or was reset -- [37531.784080] PM: early resume of devices complete after 0.305 msecs [37531.784735] snd_hda_intel 0000:00:1b.0: irq 43 for MSI/MSI-X [37531.785283] usb usb2: root hub lost power or was reset
I always killed pulseaudio and played with aplay (with no options). So far playback with pulseudio is identical to the one from asound. Suspend is not yet in the question as I normally test after clean reboot (I start to the 3.13 kernel as I use 3.11.10 daily where the sound works). $ aplay -Dplughw -vv adele.wav Playing WAVE 'adele.wav' : Signed 32 bit Little Endian, Rate 22050 Hz, Mono Plug PCM: Route conversion PCM (sformat=S32_LE) Transformation table: 0 <- 0 1 <- 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S32_LE subformat : STD channels : 1 rate : 22050 exact rate : 22050 (22050/1) msbits : 32 buffer_size : 11024 period_size : 2756 period_time : 124988 tstamp_mode : NONE period_step : 1 avail_min : 2756 period_event : 0 start_threshold : 11024 stop_threshold : 11024 silence_threshold: 0 silence_size : 0 boundary : 1444937728 Slave: Hardware PCM card 0 'HDA Intel' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S32_LE subformat : STD channels : 2 rate : 22050 exact rate : 22050 (22050/1) msbits : 32 buffer_size : 11024 period_size : 2756 period_time : 124988 tstamp_mode : NONE period_step : 1 avail_min : 2756 period_event : 0 start_threshold : 11024 stop_threshold : 11024 silence_threshold: 0 silence_size : 0 boundary : 1444937728 appl_ptr : 0 hw_ptr : 0 #### + | 09%^C Aborted by signal Interrupt...
Takashi, as I mentioned eralier, the jack detection works fine in 3.11.10, so the hardware is fine. You suspected the jack is hardware switched, not software switched and I noticed that in 3.11 it mutes speakers without changing sound levels, so it is likely hardware switched indeed.
https://bugzilla.kernel.org/show_bug.cgi?id=66621#c39 try hda_jack_sense_test.py which require hda-analyzer and python pd should be 1 when headphone or Mic is plugged and 0 when unplugged the previous 3stack model didn't enable unsolicited event
(In reply to misieck from comment #17) > Takashi, as I mentioned eralier, the jack detection works fine in 3.11.10, > so the hardware is fine. Not really -- the hardware doesn't report the jack detection although it advertises it would do. Instead, the hardware does switch the audio by itself and keep reporting the wrong jack state. That's the problem. > You suspected the jack is hardware switched, not software switched and I > noticed that in 3.11 it mutes speakers without changing sound levels, so it > is likely hardware switched indeed. In that case, we need to tell the driver to ignore the jack detection. That's the hint string does basically. So, the remaining question is why it still doesn't work well even with the hint string. Could you double-check with the patching mentioned in comment 5 with the latest driver, and see whether the raw ALSA aplay still has the same problem? At testing, make sure that the speaker is properly muted. In doubt, run like: amixer -c0 set Speaker 0dB unmute If the problem persists, please upload the alsa-info.sh output again. This is the only trace we can see remotely. Thanks.
Good news everyone! I was playing around with the hda_analyser (great tool) and encouraged by https://bbs.archlinux.org/viewtopic.php?pid=1109929 I located EAPD in my configuration to enable it (node 0x1b - Speaker Playback Volume) - voila, the sound started to flow from the speakers. I also had to unmute the outputs in pin 0x1a - Headphone Playback Volume. For some reason it was muted. Node 0x13 - Mic Playback Volume is also interesting (it is muted and does not change through alsamixer). I would really like for it to work properly trough alsamixer. After changing the two mentioned nodes, speakers work, on headphone insertion, the speakers stop and the headphones work - just as it should be. Changing volume on the speakers in alsamixer works well. Changing volume on the headphone output causes it to be muted until I change it in hda_analyser again (the same goes for the mic playback). Testing with hda_jack_sense_test.py showed that the jack insertion is indeed detected correctly. Attached are: -alsa_info for a configuration where sound works on speakers and headphones. -output from hda_jack_sense_test.py -a diff from hda_analyser -an export from hda_analyser
Created attachment 124151 [details] alsa_info output from linux 3.13.0 - with modifications from hda_analyser to make the sound work again!
Created attachment 124161 [details] output from jack_sense tool: plug in/ plug out
Created attachment 124171 [details] diff from hda_analyser
Created attachment 124181 [details] the script exported from hda_analyser to make the sound work again!
A good hunt! So, EAPD plays the key role here? Interesting that this didn't show up in the diff with the previous alsa-info.sh outputs. In anyway, below is a test fix patch. It adds: - disablement of the software jack detection - keep EAPD bit on on NID 0x1b Please give it a try.
Created attachment 124191 [details] Test fix patch
Ok, so that patch makes things much more pallateble. The sound comes out of the speakers when it should and from the headphones when it should. A few issues: why codec->no_jack_detect = 1; Testing with hda_jack_sense_test.py showed that the jack is detected correctly (see a previous attachment) and it is confirmed by pulse audio correctly detecting the correct output as well. There is also a peculiarity that I could notice while running with pulseaudio: Amongst the audio devices I can select are "Analog Output" and either "Headphones" or "Speakers" (or both if the patch from comment 5 is applied, which I think shouldn't be), depending on what is plugged. Pulseaudio will switch between using the headphones or the speakers device, applying volume levels remembered for the given output, but always muting the opposing source (when "speakers" is selected, "headphones" get muted). So all that is great I guess, but what's up with the "analog output" device? Its not very useful.
Created attachment 124351 [details] alsa_info output from linux 3.13.0 with fix2 modified This is with your patch modified to remove the line about no_jack_detect. I also did not apply the fix from comment 5. All seems fine.
OK, if the software jack detection works as expected, that's even better. I added the disablement just because of your information that the machine worked without it in the earlier driver code, and it reported wrongly in comment 13. But this might be all due to the EAPD. I'm going to add the patch without the jack detection disablement line to the upstream code.
Either way, it works nice now. Recording too. So unless you think it's worth doing anything about that redundant "analog output" that shows up in pulseaudio, I consider this bug is fixed. Thank you very much.