[alsa-devel] No sound from speakers with Realtek ALC3226
I posted this on the alsa-user list, but did not get a reply.
Although it occasionally works, I am usually unable to get any sound out of the speakers on a dell latitude e7240 using alsa-1.0.28 and linux-3.16.6 - see details at the end of the post.
1. HDMI is the default sound device - why, the analogue device would make more sense?
2. On the analogue sound device, the headphones are the default instead of the speakers. On the few occasions I get sound out of the speakers, the headphones need to be muted first - even though no headphones are connected.
3. Shutting windows 7 64bit down with "shutdown.exe -s" seems to help with getting sound from the speakers with linux on the same machine.
Most of the time, I see the error:
snd_hda_intel 0000:00:1b.0: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj.
I've tried various module options:
options snd_hda_intel probe_only=0,1 options snd-hda-intel enable_msi=1 bdl_pos_adj=1,32 [and 48 and 64] options snd-hda-intel id=PCH index=1
..all to no avail.
Any additional troubleshooting suggestions (or a patch) would be much appreciated.
John
---------- $ lspci | grep -i audio 00:03.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev0b) 00:1b.0 Audio device: Intel Corporation 8 Series HD Audio Controller (rev04)
$ cat /proc/asound/cards 0 [HDMI ]: HDA-Intel - HDA Intel HDMI HDA Intel HDMI at 0xf7e34000 irq 65 1 [PCH ]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xf7e30000 irq 64
$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: HDMI [HDA Intel HDMI], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: PCH [HDA Intel PCH], device 0: ALC3226 Analog [ALC3226 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0
$ cat /proc/asound/card*/codec* | grep Codec Codec: Intel Haswell HDMI Codec: Realtek ALC3226
At Tue, 24 Feb 2015 13:14:38 +0400, John Frankish wrote:
I posted this on the alsa-user list, but did not get a reply.
Although it occasionally works, I am usually unable to get any sound out of the speakers on a dell latitude e7240 using alsa-1.0.28 and linux-3.16.6 - see details at the end of the post.
Try the later version of Linux kernel at first. 3.16 is way too old for debugging in the era of 4.x kernel :)
- HDMI is the default sound device - why, the analogue device would make
more sense?
It's just an order of PCI devices on the bus. PulseAudio would choose the analog usually as default.
- On the analogue sound device, the headphones are the default instead of
the speakers. On the few occasions I get sound out of the speakers, the headphones need to be muted first - even though no headphones are connected.
- Shutting windows 7 64bit down with "shutdown.exe -s" seems to help with
getting sound from the speakers with linux on the same machine.
If so, Windows or BIOS is the problem. It doesn't set up the pin configuration properly Linux driver relies on.
Most of the time, I see the error:
snd_hda_intel 0000:00:1b.0: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj.
This is likely irrelevant. The message is only about the DMA timing issue, which can be almost ignored.
I've tried various module options:
options snd_hda_intel probe_only=0,1 options snd-hda-intel enable_msi=1 bdl_pos_adj=1,32 [and 48 and 64] options snd-hda-intel id=PCH index=1
..all to no avail.
You really understand what you're trying here. probe_only option would make the driver only probing the driver and skipping the configuration, i.e. you won't get any sound from it.
The enable_msi is in anyway true as default. bdl_pos_adj is irrelevant for your problem, as mentioned. The index option would break the operation if you pass only a single value for the multiple devices.
Any additional troubleshooting suggestions (or a patch) would be much appreciated.
If you get the status where the speaker works (e.g. after Windows clean reboot), try to take alsa-info.sh snapshot. Run alsa-info.sh with --no-upload option, and save the generated output. Then, take another alsa-info.sh snapshot while the speaker doesn't work. Compare these two outputs. (At best, attach both (compressed) files.)
Takashi
I posted this on the alsa-user list, but did not get a reply.
Although it occasionally works, I am usually unable to get any sound out of the speakers on a dell latitude e7240 using alsa-1.0.28 and linux-3.16.6 - see details at the end of the post.
If so, Windows or BIOS is the problem. It doesn't set up the pin
configuration properly Linux driver relies on.
I just updated the bios to the latest version, but no change :(
If you get the status where the speaker works (e.g. after Windows clean
reboot), try to take alsa-info.sh snapshot. Run alsa-> info.sh with --no-upload option, and save the generated output. Then, take another alsa-info.sh snapshot while the speaker > doesn't work. Compare these two outputs. (At best, attach both (compressed) files.)
Alsa_info_works and alsa_info_no_works attached - diff didn't show an obvious difference between getting sound from the speakers and not getting sound from the speakers.
At Wed, 25 Feb 2015 13:08:29 +0400, John Frankish wrote:
I posted this on the alsa-user list, but did not get a reply.
Although it occasionally works, I am usually unable to get any sound out of the speakers on a dell latitude e7240 using alsa-1.0.28 and linux-3.16.6 - see details at the end of the post.
If so, Windows or BIOS is the problem. It doesn't set up the pin
configuration properly Linux driver relies on.
I just updated the bios to the latest version, but no change :(
If you get the status where the speaker works (e.g. after Windows clean
reboot), try to take alsa-info.sh snapshot. Run alsa-> info.sh with --no-upload option, and save the generated output. Then, take another alsa-info.sh snapshot while the speaker > doesn't work. Compare these two outputs. (At best, attach both (compressed) files.)
Alsa_info_works and alsa_info_no_works attached - diff didn't show an obvious difference between getting sound from the speakers and not getting sound from the speakers.
OK, then this is not about the pin configuration, but likely the EAPD setup BIOS does.
Did you try the newer kernels? There has been a fix for EAPD control, and this might already fix your problem.
Takashi
I posted this on the alsa-user list, but did not get a reply.
Although it occasionally works, I am usually unable to get any sound out of the speakers on a dell latitude e7240 using alsa-1.0.28 and linux-3.16.6 - see details at the end of the post.
If so, Windows or BIOS is the problem. It doesn't set up the pin
configuration properly Linux driver relies on.
I just updated the bios to the latest version, but no change :(
If you get the status where the speaker works (e.g. after Windows
clean
reboot), try to take alsa-info.sh snapshot. Run alsa-> info.sh with --no-upload option, and save the generated output. Then, take another alsa-info.sh snapshot while the speaker > doesn't work. Compare these two outputs. (At best, attach both (compressed) files.)
Alsa_info_works and alsa_info_no_works attached - diff didn't show an obvious difference between getting sound from the speakers and not getting sound from the speakers.
OK, then this is not about the pin configuration, but likely the EAPD
setup BIOS does.
Did you try the newer kernels? There has been a fix for EAPD control, and
this might already fix your problem.
I'd rather patch my current kernel if possible - do you know where the EPAD control patch is by any chance?
At Wed, 25 Feb 2015 13:25:35 +0400, John Frankish wrote:
I posted this on the alsa-user list, but did not get a reply.
Although it occasionally works, I am usually unable to get any sound out of the speakers on a dell latitude e7240 using alsa-1.0.28 and linux-3.16.6 - see details at the end of the post.
If so, Windows or BIOS is the problem. It doesn't set up the pin
configuration properly Linux driver relies on.
I just updated the bios to the latest version, but no change :(
If you get the status where the speaker works (e.g. after Windows
clean
reboot), try to take alsa-info.sh snapshot. Run alsa-> info.sh with --no-upload option, and save the generated output. Then, take another alsa-info.sh snapshot while the speaker > doesn't work. Compare these two outputs. (At best, attach both (compressed) files.)
Alsa_info_works and alsa_info_no_works attached - diff didn't show an obvious difference between getting sound from the speakers and not getting sound from the speakers.
OK, then this is not about the pin configuration, but likely the EAPD
setup BIOS does.
Did you try the newer kernels? There has been a fix for EAPD control, and
this might already fix your problem.
I'd rather patch my current kernel if possible - do you know where the EPAD control patch is by any chance?
Look through git log of sound/pci/hda/patch_realtek.c. But beware that the patches won't be applied cleanly; otherwise I would have marked them for stable.
But I'll ask for testing with the newer kernels in anyway if patching fails, so...
Takashi
I posted this on the alsa-user list, but did not get a reply.
Although it occasionally works, I am usually unable to get any sound out of the speakers on a dell latitude e7240 using alsa-1.0.28 and linux-3.16.6 - see details at the end of the post.
If so, Windows or BIOS is the problem. It doesn't set up the pin configuration properly Linux driver relies on.
I just updated the bios to the latest version, but no change :(
I'd rather patch my current kernel if possible - do you know where the EPAD control patch is by any chance?
Look through git log of sound/pci/hda/patch_realtek.c. But beware that
the patches won't be applied cleanly; otherwise I would have marked them for stable.
But I'll ask for testing with the newer kernels in anyway if patching
fails, so...
Thanks
The first hunk of the patch applies cleanly, but...
CC [M] sound/pci/hda/patch_realtek.o sound/pci/hda/patch_realtek.c: In function 'alc_fill_eapd_coef': sound/pci/hda/patch_realtek.c:234:2: error: implicit declaration of function 'alc_get_coef0' [-Werror=implicit-function-declaration] coef = alc_get_coef0(codec); ^ sound/pci/hda/patch_realtek.c:238:2: error: implicit declaration of function 'alc_update_coef_idx' [-Werror=implicit-function-declaration] alc_update_coef_idx(codec, 0x7, 0, 1<<5); ^ sound/pci/hda/patch_realtek.c: At top level: sound/pci/hda/patch_realtek.c:695:21: error: conflicting types for 'alc_get_coef0' static unsigned int alc_get_coef0(struct hda_codec *codec) ^ sound/pci/hda/patch_realtek.c:234:9: note: previous implicit declaration of 'alc_get_coef0' was here coef = alc_get_coef0(codec); ^ sound/pci/hda/patch_realtek.c:230:13: warning: 'alc_fill_eapd_coef' defined but not used [-Wunused-function] static void alc_fill_eapd_coef(struct hda_codec *codec) ^ cc1: warning: unrecognized command line option "-Wno-errors" cc1: some warnings being treated as errors scripts/Makefile.build:257: recipe for target 'sound/pci/hda/patch_realtek.o' failed make[1]: *** [sound/pci/hda/patch_realtek.o] Error 1 Makefile:1333: recipe for target '_module_sound/pci/hda' failed make: *** [_module_sound/pci/hda] Error 2
I posted this on the alsa-user list, but did not get a reply.
Although it occasionally works, I am usually unable to get any sound out of the speakers on a dell latitude e7240 using alsa-1.0.28 and linux-3.16.6 - see details at the end of the post.
If so, Windows or BIOS is the problem. It doesn't set up the pin
configuration properly Linux driver relies on.
I just updated the bios to the latest version, but no change :(
If you get the status where the speaker works (e.g. after Windows
clean
reboot), try to take alsa-info.sh snapshot. Run alsa-> info.sh with --no-upload option, and save the generated output. Then, take another alsa-info.sh snapshot while the speaker > doesn't work. Compare these two outputs. (At best, attach both (compressed) files.)
Alsa_info_works and alsa_info_no_works attached - diff didn't show an obvious difference between getting sound from the speakers and not getting sound from the speakers.
OK, then this is not about the pin configuration, but likely the EAPD
setup BIOS does.
Did you try the newer kernels? There has been a fix for EAPD control, and this might already fix your problem.
I'd rather patch my current kernel if possible - do you know where the
EPAD control patch is by any chance?
I forgot to mention that if I run gnome-3.10.x, without using alsamixer to unmute the master or mute the headphones, I can almost always get sound from the speakers.
If I don't use gnome, then usually no amount of fiddling with alsa/pulseaudio will get sound out of the speakers, though it's looking more and more likely that exiting win7 64bit with "shutdown.exe -s" fixes things (using alsamixer to unmute the master or mute the headphones) until I next boot into windows.
participants (2)
-
John Frankish -
Takashi Iwai