No Sound in Fedora 23 Linux with ALC892 (Intel HDA)

tl;dr: show me the fix plz thx

Did your sound also just quit working in Fedora 23 or other Linux distribution? You are not alone. My sound issues seemed to line up with an unclean shutdown performed courtesy of my foot. First I thought I corrupted my Gnome profile, but looking in the Sound settings panel, I saw no output devices.

No output devices? My computer audio was working this morning. I’ve never heard of an integrated sound card getting damaged in an abrupt shutdown either – it just doesn’t make sense. So it had to be a Linux oddity.

Out of sheer curiosity, I tried uninstalling PulseAudio. I should still be able to get sound with just ALSA, yet this step had no effect.

Specifically, I have a Gigabyte GA-78LMT-USB3 motherboard with a quad-core 4.2 GHz AMD CPU, 16GB of RAM, and a Crucial SSD. If you also have the GA-78LMT-USB3 motherboard you likely have the same sound chipset as me – the Realtek ALC892 / ALC887. My first search now that I knew the chipset turned up this 2014 forum post. However, most of that is just bug reporting and trying several things that did not work.

It wasn’t until I found this Ask Fedora question that I got my solution. Simply creating a .conf file in /etc/modprobe.d with the following contents was sufficient to restore my audio functionality completely:

options snd_hda_intel single_cmd=1
options snd_hda_intel probe_mask=1

An effective one-liner to perform this fix would be as follows.

echo "options snd_hda_intel single_cmd=1\noptions snd_hda_intel probe_mask=1" > sudo tee /etc/modprobe.d/intel_hda_fix.conf

Cheers!

Update: an earlier version of this post referenced “snd-hda-intel” instead of “snd_hda_intel.” Underscores are the appropriate character here and dashes will not work.

Fix Broken “Mixed Content” WordPress 4.4 srcset (Responsive Images)

One of the newest features (and one of the coolest) to be introduced to WordPress core lately has been “responsive image support”. What does this really mean? To be specific, WP implemented the HTML5 <img> srcset (“source set”) attribute.

When it works properly, this attribute solves a couple common problems in web development. By providing the browser with a list of pre-scaled image resolutions it can choose from, a device can intelligently request the best image for the current screen resolution. If you’re using one of the currently supported browsers on a high-resolution screen, it should automatically opt to use one of the larger images specified in srcset. I’ve been doing a lot of testing on my Nexus 6P, which is nearly 520 PPI. You can really tell the difference on screens like that.

Here’s the problem. If you’re using HTTPS with WordPress, but it isn’t in your SITEURL or HOME variables, you will likely end up with plain old HTTP srcset paths. Visiting the site on unencrypted HTTP will work just fine, but the problems show when you try HTTPS. Suddenly, and only on devices that support and choose to use the srcset, most of your images will fail to load. This is called “Mixed Content” – loading insecure resources from a secure page. It’s a pretty bad thing to do, and because of the security hazards, almost all browsers will completely block requests like this to unencrypted HTTP from an HTTPS session.

So, yeah, great – browsers block your responsive images. You could go all-HTTPS, or go all-HTTP, but their is an option for your particular instance.

What do you do?

Solution A: filter wp_image_calculate_srcset and do an easy-peasy str_replace( ‘http://’, ‘https://’ ) making *all* your srcset images SSL. Use this for CloudFlare support.

add_filter( 'wp_get_attachment_url', 'set_url_scheme' );
add_filter( 'wp_calculate_image_srcset', function($sources) {
 $filtered_sources = array();
 foreach($sources as $source_key=>$source) {
  $source['url'] = str_replace('http://','https://', $source['url']);
  $filtered_sources[$source_key] = $source;
 }
 return $filtered_sources;
});

Solution B: filter wp_image_calculate_srcset and attempt to detect the protocol the page was requested with, then only rewrite to https if the page was loaded securely as well. This is nice if it works in your configuration since you don’t incur any HTTPS overhead loading images on an unencrypted page. However, it will not work with CloudFlare. If you’re using CloudFlare, you should make sure HTTPS is on and use Solution A.

add_filter( 'wp_get_attachment_url', 'set_url_scheme' );
add_filter( 'wp_calculate_image_srcset', function($sources) {
 $page_protocol = ( !empty( $_SERVER['HTTPS'] ) && $_SERVER['HTTPS'] !== 'off' || $_SERVER['SERVER_PORT'] == 443 ) ? "https" : "http";
 foreach ( $sources as $size => $source ) {
  if ( stripos( $source['url'], $page_protocol ) !== 0 ) {
   // we can't find the current page protocol at the beginning of the srcset...
   $new_url = str_replace( $source_protocol . '://', $page_protocol . '://', $url );
   $sources[$size]['url'] = $new_url;
  }
 }
 return $sources;
});

Solution C: update siteurl and home to start with https://. This will make your whole site SSL. Please make sure your certs and redirects are all okay before doing this, or there’s a good chance you’ll lock yourself out of your install.