$ lspci -nn | grep -i audio 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06) 00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller [8086:8c20] (rev 05) This is a Dell Alienware 15 (Early 2015) laptop. Problem happens roughly between 10-20% of cold power on. When performing a cold power on sometimes the main input (microphone) or output (speaker) channel doesn't work. The channel seems to be detected as present but no input is captured or no sound is coming out from the speakers. Note I used pasuspender -- speaker-test -c2 -twav -Dhw:PCH to get pulseaudio out of the equation and this can reproduce the issue as well. On kernel 4.0 the microphone was getting garbage instead of being simply silent. With 4.1 I get a silent microphone. This might be also due to me experimenting with alsamixer siwtches, but it's hard to tell. The few times I tried a simple reboot the issue didn't gone away. To get rid of it I have to to a shutdown and power on the system again. I'm going to attach the output of alsa-info.sh [1] for working condition, silent microphone condition and silent speakers condition shortly. OS is Fedora 22 and I tried kernel 4.0 (from .4 to .8) and recently also switched to 4.1.2 from updates-testing repo. [1] https://wiki.ubuntu.com/Audio/AlsaInfo
Created attachment 183691 [details] alsa-info working condition This is the outout of alsa-info.sh when audio is working as expected
Created attachment 183701 [details] alsa-info silent mic condition This is the output of alsa-info.sh when microphone is silent
Created attachment 183711 [details] alsa-info silent speakers condition This is the output of alsa-info.sh when speakers are silent. All three times alsa-info was executed with kernel 4.1.2, no packages changed between the three power cycles. It happened by luck I was able to reproduce them in a row.
Please check with 4.2-rc. A different headphone pin is used for this machine (NID 0x0f) while others use NID 0x10. A workaround patch was merged in 4.2-rc1.
Created attachment 183841 [details] alsa-info headphones plugged in, kernel 4.2 rc3, working Very much better now. Audio switches to the headphones when plugged in and again to the speakers when unplugged. However the functionality seems to not be completely exposed. I'm not really sure here, but other systems seems to have a dedicated volume in alsamixer showing up for headphones, so you hears are not blasted by the high volume you keep for the speakers I suppose. There is also a second problem: pulseaudio doesn't seems to know about jack being plugged or not, possibly due to the former?
The problem is that BIOS advertises completely wrong pin configurations. We need to fix them up manually. Which audio I/O does this machine have? Please list up: e.g., one headphone jack at left, one built-in speaker, one mic jack, etc. Also, check which pin corresponds to each jack. The headphone jack is supposed to be 0x0f and the mic 0x12. These should be clarified. You can check it via hda-verb like: hda-verb /dev/snd/hwC1D0 0x18 GET_PIN_SENSE 0 This will give a value with bit 31 depending on the jack plug state if the jack detection works. Try to change 0x18 to a different node id until it hits.
*facepalm* damn BIOS. Ok what I/O are available: - 1 headphones 3.5 mm jack on the left - 1 mic 3.5 mm jack on the left next to the headphone one. - one built-in speaker (stereo) - HDMI on the back (and this seems to be detected already, but I never tried) - display port on the back (not sure if this carries audio as well, never used it to date) Since pulseaudio lists 3 HDMI / Displayport ports I guess those probably work already. Unfortunately I have no monitor / TV to connect the laptop to try. I can confirm 0x0f is the headphones # unplugged root@alientux ~ # hda-verb /dev/snd/hwC1D0 0x0f GET_PIN_SENSE 0 nid = 0xf, verb = 0xf09, param = 0x0 value = 0x0 # plugged in root@alientux ~ # hda-verb /dev/snd/hwC1D0 0x0f GET_PIN_SENSE 0 nid = 0xf, verb = 0xf09, param = 0x0 value = 0x80000000 Mic however seems not to be 0x12 (note I don't have a mic, I plugged in the headphones here as well, but it should not matter right?): # unplugged nid = 0x10, verb = 0xf09, param = 0x0 value = 0x0 nid = 0x11, verb = 0xf09, param = 0x0 value = 0x0 nid = 0x12, verb = 0xf09, param = 0x0 value = 0x0 # plugged in nid = 0x10, verb = 0xf09, param = 0x0 value = 0x80000000 nid = 0x11, verb = 0xf09, param = 0x0 value = 0x80000000 nid = 0x12, verb = 0xf09, param = 0x0 value = 0x0 0x10 and 0x11 are changing. I tried up to 0xff and nothing else changes for both mic and headphones.
Interesting... So two mic pins are used. Not sure whether this is a quad mic, or two mono mic, or whatever. I suppose it has a built-in mic? Does it work at all? And there are no SPDIF I/O, right?
Apologize, it the hot. Of course there is a built-in microphone, just next to the webcam. I looked at the Windows Soundblaster software as provided with the computer. There is the noise reduction option (exposed in alsamixer as well). No idea if this is based on a second microphone, similar to smartphones, or pure software. The built-in mic works like a charm, I use it daily for conference calls (firefox hello mainly) and works with all kernel tested, from 4.0 to 4.2 rc3. As reported already sometimes it is silent or outputting high noise after a cold boot (not very frequent, like 10-20%). Solution is to do a full power cycle (shutdown and power on again, reboot might not solve, but more testing is required for this tbo). While in Windows I looked at SPDIF and I see it mentioned nowhere. Also by peeking into the jack I can't see the typical red light. If it's off by default and you have to trigger it somehow I have no idea, but in the SPDIF enabled system I had in the past it was always on. While peeking I noticed the mic jack seems to be stereo. Metal connectors inside are the same as the stereo headphones one. This might explain the double pin?
Oh btw it looks like all of the soundblaster options are exposed via alsamixer. Some definitely do, like the crystalvoice (very appreciated), some just kill the audio like the sorround (for some reason it mutes the card). In the Soundblaster software for Windows some options depends on other, so this might also be the reason why some do not work. Just mentioning it in case that's important / interesting / related to the issue
Then let's forget about SPDIF. Below is a quick test fix for overriding the pincfgs. This might make also the mic jack working. Let's see. The pin 0x10 is an output pin, so a possible explanation is that the mic jack is a headset jack that can drive output, too. In the patch, it's disabled for now.
Created attachment 183951 [details] Test patch for pincfgs
(In reply to Takashi Iwai from comment #12) > Created attachment 183951 [details] > Test patch for pincfgs Well WOW. Recompiled exactly the same kernel (4.2 rc3) with the patch applied. Pulseaudio now correctly shows the speakers / headphones and detect when they are plugged and keeps two different volumes based on which one is in use. If I really need to find a glitch I can only say there is a very short delay when switching between HP and Speakers, but ok that's really being mean now. Thank you very much Takashi, this is much appreciated, hope to see this merged soon. Basci functionality for this sound card + laptop combo should be in place with this.
The delay of the headphone detection is expected. The hardware seems to have a problem of the immediate jack detection, thus the driver delays the execution intentionally. We may adjust it depending on the hardware, but let's do it later. Do you have any chance to test the mic, too? If the mic is confirmed to (more or less) work, I can merge the fix patch to the upstream.
(In reply to Takashi Iwai from comment #14) > The delay of the headphone detection is expected. The hardware seems to > have a problem of the immediate jack detection, thus the driver delays the > execution intentionally. We may adjust it depending on the hardware, but > let's do it later. > > Do you have any chance to test the mic, too? If the mic is confirmed to > (more or less) work, I can merge the fix patch to the upstream. Apologize again, I got exited and forgot about the mic. I don't have a proper standalone mic to test with. I have the headphones of my smartphone which includes a mic on a single jack (so 4 metal contact in the same size of the normal 3.5 mm jack. However I think I can say something is wrong with the mic: if I plugin the HP in the mic slot pavucontrol detects the plug and switches to the microphone (vs the "internal microphone" when no jack is plugged), however it also shows some signal. I verified with audacity by recording from the pulse source. I always get the internal microphone of the laptop. Just to be sure I gave a shot also with my smartphone HP + mic, same result. The Internal Microphone still works like a charm (but the user needs to find the correct switch combo in alsamixer to remove background noise: CrystalVoice + Noise Reduction enabled. This is not a regression, I'm pretty sure it was like this also before, but I tried recording myself only now).
Ok some more information: I checked in Windows again, both in Windows sound settings in the control panel and from the Soundblaster software itself: there are three sources for recording: 1. external microphone (the 3.5 mm jack) 2. microphone array (this is the internal microphones). So there is more than just one. This seems to be related to the CrystalVoice feature 3. What U hear (which is actually available in alsamixer volumes), which is a way of capturing what's heard by the user Hope this helps
(In reply to Enrico Tagliavini from comment #15) > (In reply to Takashi Iwai from comment #14) > > The delay of the headphone detection is expected. The hardware seems to > > have a problem of the immediate jack detection, thus the driver delays the > > execution intentionally. We may adjust it depending on the hardware, but > > let's do it later. > > > > Do you have any chance to test the mic, too? If the mic is confirmed to > > (more or less) work, I can merge the fix patch to the upstream. > > Apologize again, I got exited and forgot about the mic. I don't have a > proper standalone mic to test with. I have the headphones of my smartphone > which includes a mic on a single jack (so 4 metal contact in the same size > of the normal 3.5 mm jack. > > However I think I can say something is wrong with the mic: if I plugin the > HP in the mic slot pavucontrol detects the plug and switches to the > microphone (vs the "internal microphone" when no jack is plugged), however > it also shows some signal. I verified with audacity by recording from the > pulse source. I always get the internal microphone of the laptop. > > Just to be sure I gave a shot also with my smartphone HP + mic, same result. > > The Internal Microphone still works like a charm (but the user needs to find > the correct switch combo in alsamixer to remove background noise: > CrystalVoice + Noise Reduction enabled. This is not a regression, I'm pretty > sure it was like this also before, but I tried recording myself only now). Could you try adjust some knobs to see whether the mic works at all or not? You have "AMic1/DMic Auto Detect" switch, and this should turn on/off the automatic switching per mic jack in the driver side (this isn't about the PA's behavior, though). Then, there is "AMic1/DMic" capture switch. And there are "Analog-Mic2" capture switch *and* volume. (Also "What U Hear" variants of controls.) And, "Mic1-Boost (30dB)". This isn't clear for which input. Last but not least, there are master "Capture" switch and volume. I'd like to know which controls do for which input and how... About testing the mic: it would be best if you have a microphone, but just testing can be done via a headphone, not the headset with mic. The most important point is to identify whether the signal comes really from the mic or from the built-in mic. You can brush the mic (or the built-in mic) by a finger while recording, so that only mic or built-in mic can pick up the direct noise.
Yeah I was brushing the builtin mic. The location is pretty clear, it is just next to the webcam. - "AMic1/DMic Auto Detect": seems to have no effect at all. I tried switching it while both recording from main mic or mic2 - "AMic1/DMic": ditto - "Analog-Mic2": BINGO! This is where the input from the jack is going. If I plug the headphones and I tap on one of them I can see signal in audacity, if I tap the other the signal is on the other channel. Confirmed this is a stereo mic. - "Analog-Mic2" volume: this is the caputure volume associated with mic2 - the m ain capture volume affects only the builtin mic. - mic boost seems to have no effect on any - "What U Hear" seems to work as expected, but the volume switch doesn't actually change the output volume of this. I tried the other two capture and the output coming out from this is always the same. This is also missing from pulse. Did I covered all of your questions? So the problem might just be pulse not switching to mic2 when the jack is plugged, but I have no idea if this is because of an issue with alsa or in pulse. For sure mic2 doesn't show up in pavucontrol.
OK, then I'm going to merge the patch, despite of it being imperfect. There are way too many crappy codes in ca0132 driver, and we need to fix them in a better way... In anyway, I'll skip for 4.2 but target for 4.3 kernel, as this is still a test fix.
Makes sense, at least the headphones will work out of the box with kernel 4.3+ if this code will be merged. For now thank you for your help.
(In reply to Takashi Iwai from comment #8) > Interesting... So two mic pins are used. Not sure whether this is a quad > mic, or two mono mic, or whatever. > > I suppose it has a built-in mic? Does it work at all? > > And there are no SPDIF I/O, right? I think I just discovered why there are two pins for the MIC. I forgot my headphones home, I borrowed a couple of apple. They are for an iphone, so mic + headphones, I plugged them in the headphone jack: nid = 0xf, verb = 0xf09, param = 0x0 value = 0x80000000 nid = 0x10, verb = 0xf09, param = 0x0 value = 0x0 nid = 0x11, verb = 0xf09, param = 0x0 value = 0x0 nid = 0x12, verb = 0xf09, param = 0x0 value = 0x80000000 Looks like this jack can be used with TRRS. I'm unable to record any sound from it with audacity however. All three input channel are flat (for one of them audacity seems to show a glitch and is unable to record even the flat input, the other two are the builtin mic and the dedicated jack mic input). This is with kernel 4.2.5-201.fc22.x86_64
Some updates with kernels 4.3 and 4.4 series (4.4.4 as found in Fedora 22 right now is the current running one). Headphones, speakers and internal mic are detected as expected out of the box, that's very nice. Thank you again for fixing this. Unfortunately the internal microphone doesn't work well most of the times. Garbage sounds are present, sometimes at super high volume, sometimes just as a background noise. It happens very rarely they are not present. With kernel 4.2 suspending to RAM and resuming was helping most of the times, but with kernel 4.3 and 4.4 the main effect is just to have the mic volume dropped, but background noise is still there, as if I disabled the mic boost switch (which doesn't have any effect when toggled from alsamixer). Sometimes audio output is also lost when suspend resuming (not very often though). However with the volume dropped it kind of helps a bit to hear the noise less. Also when switching off the 'Noise Reduction' switch in alsamixer garbage output skyrockets (like to near the possible maximum input volume) and changes tone / pitch completely. Maybe the original problem is that there is an high artificial noise generated, noise reduction removes most of it, but due to the massive amount of noise something manage to squeeze in. The most effective way to get rid of this is to perform a cold restart (so full shutdown, not a reboot) and keep trying until a working boot is met. This is unfortunate if you have input 3 very long passwords to boot the system (various level of encryption) :). I will also note I update the firmware of the laptop to the very latest version (updates Intel ME FW, Intel VBIOS, GOP were included, no idea if related, but I tried), situation didn't change much unfortunately. There are also rare problems with output every now and then, but they are not frequent, and still have to see if they happen again with the new BIOS (well firmware). The mic problem happens very frequently, as in more than 50% of boots.
So the alienware 15 (early 2015) model being discussed has a TRRS (labeled with a headset icon) and TRS (labeled with a mic icon) port. Under windows, you can plug in a phone-style headset with speakers+mic into the TRRS and it will detect it as a "headset". Alternatively, you can connect a typical computer headset via two 3.5mm jacks and it will detect as "mic" on one port, and "headphones" on the other. It's my guess that this behavior is why you saw the odd behavior when testing this previously. It sounds Enrico was able to get his phone-style (TRRS) headset working in linux (I haven't tested this yet, I'll try to get around to that tomorrow), but I'm so far unable to get the two-plug style (TRS + TRS) typical computer headset to work. Everything else works out of the box (I'm on kernel 4.6.0, ubuntu 16.04 + linux-image-4.6.0-040600-generic installed from http://ppa.launchpad.net/kernel-ppa/pre-proposed/ubuntu). I've tried using hdajackretask to override and try several different configurations (like setting the 0x10 to mic and disabling 0x11) but no matter what I do, I only ever get audio from the internal mic. I have Analog-Mic2 port, and pulse audio shows the audio devices switching between being unavailable and active as I plug in and unplug the mic, but I don't get audio. Same mic works great in windows plugged in the same way :( Any ideas? anything else I can attach to help troubleshoot? mic plugged in: --- Pin 0x0b (Internal Speaker): present = Yes Pin 0x0c (Not connected): present = No Pin 0x0d (Not connected): present = No Pin 0x0e (Not connected): present = No Pin 0x0f (Black Headphone, Left side): present = Yes Pin 0x10 (Not connected): present = Yes Pin 0x11 (Black Mic, Left side): present = Yes Pin 0x12 ( Mic, Top): present = No Pin 0x13 (Not connected): present = No Pin 0x18 (Not connected): present = No --- mic not plugged in: Pin 0x0b (Internal Speaker): present = Yes Pin 0x0c (Not connected): present = No Pin 0x0d (Not connected): present = No Pin 0x0e (Not connected): present = No Pin 0x0f (Black Headphone, Left side): present = Yes Pin 0x10 (Not connected): present = No Pin 0x11 (Black Mic, Left side): present = No Pin 0x12 ( Mic, Top): present = No Pin 0x13 (Not connected): present = No Pin 0x18 (Not connected): present = No
Just tested and found that when using a TRRS headset (phone-style) it doesn't detect that a mic is plugged in.
Log time no update, so I thought about saying something. As of today with kernel 4.8.10 (Fedora 24) situation is unchanged compared to what I said in comment #22 . Issue still exists, audio (input or output) is frequently broken (no signal or garbage noise) and a suspend resume is needed. In the worst cases only a cold boot fixes it.
Now on Fedora 25 and kernel 4.10: it is better. I honestly don't recall the last time speakers were not working. Headphones or microphone are still non functional occasionally. They are correctly detected, but no sound is going out or coming in. As before suspend to RAM and resume helps solving the issue. Thank you for the improvements!
as of latest 4.12.0, still the same for me. Everything is so close, only thing that doesn't work is the pesky issue with always using the built-in mic even when you plug in an external one (either into the dedicated external mic port or to the TRRS port). In windows the driver detects the plug-in and switches to it. If anyone is still monitoring this and has the expertise and interest to look into it, I'm a willing test victim. :)
I see the issue with disappearing sound on the Gigabyte GA-Z170X-Gaming 7 motherboard (Creative Sound Core 3D chip). My computer is working 24/7, but occasionally, the sound stops playing through headphones. Audio device disappears from Pulse Audio. After doing "pulseaudio -k", sound device reappears, and music seems to play according to Volume Control. But headphones do not play. Reboot does not solve the issue. But turning computer and power off and then on solves the issue. My kernel is a default 4.13.0-36-generic Ubuntu kernel.
(In reply to Dmitriusan from comment #28) > I see the issue with disappearing sound on the Gigabyte GA-Z170X-Gaming 7 > motherboard (Creative Sound Core 3D chip). My computer is working 24/7, but > occasionally, the sound stops playing through headphones. > Audio device disappears from Pulse Audio. After doing "pulseaudio -k", sound > device reappears, and music seems to play according to Volume Control. But > headphones do not play. Reboot does not solve the issue. But turning > computer and power off and then on solves the issue. > My kernel is a default 4.13.0-36-generic Ubuntu kernel. Sounds like a different bug from the one I see. I don't loose output during use, if it doesn't work it's from the moment I turn on the PC and I have to turn it off and on again to get it back. Supend and resume also works most of the time, but not all the time. Also nothing disappears from pulseaudio for me. Do you still see your soundcard in lspci when it happens? If not it's most likely an hardware issue, which I would not exclude anyway. I would recommend you open a new bug and attach dmesg and alsa-info.sh output (also check dmesg when the issue happens). You can reference to this bug in the "See also" section to relate them.
What ca0132 card do you have, Enrico? I recently fixed this issue with the Sound Blaster Z, and would like to know if you perhaps have the same issue on your card, and if you do, if I should include whatever card you have under the fix. In my case, it's like part of the DSP isn't initialized properly. It's hard to reproduce. But, I found what isn't initialized properly, and my driver includes a check, and reloads the driver on startup if the issue is detected. Maybe this can work for your issue as well.
(In reply to Connor M from comment #30) > What ca0132 card do you have, Enrico? Hi, sorry for the delay in answering. According to the Specification of the laptop it's a "Creative Sound Core3D-EX with Creative Sound Blaster X-Fi MB3". I guess it's also an hardware initialization issue as suspend / resume and power cycle are fixing the issue (the latter being more reliable then the former).