Sound on the Intel Compute Stick (Sterling City)

Post date: Feb 24, 2016 4:49:47 PM

Update: This work is superseded by my 'isorespin.sh' script which can respin an official ISO suitable for use on Intel Atom devices.

If you ever needed to understand the concept 'kernel mainlining' then you should look no further than the issue of HDMI audio support for Linux on Intel's Atom Bay Trail and Cherry Trail CPUs.

Intel developed a source code patch for Ubuntu 14.04 to provide for Low Power Engine (LPE) Audio support on Bay Trail High-Definition Multimedia Interface (HDMI) (see https://01.org/ubuntu-hdmi). At the time the mainline kernel was 3.16.7-ckt3 and the patch was for the Ubuntu 'trusty linux-lts-utopic ' kernel 3.16.0-30.40. But because the source code was developed as a patch to a specific kernel, when Ubuntu 14.04 moved to the 'trusty linux-lts-vivid' kernel (or 3.19.0) it meant no more LPE Audio support for HDMI as the source code was a classic example of out-of-tree code.

Had the code been merged into the mainline kernel (the "mainline" being the kernel maintained by Linus Torvalds and used as a base by Linux distributors) then the code would have been available to all Linux users and more importantly would have been available in new kernels going forward.

Now it would be easy to therefore blame Intel for the lack of audio support given how these CPUs are being used in mini PCs however it must be remembered that companies have to make commercial decisions as contributing code incurs cost and expense. And Intel's current processor strategy excludes Linux support on “tablet” processors. Furthermore Intel is no exception in making decisions and reviewing them as required so we have to accept any implications for mini PCs at this time. Also there is also nothing to stop developers working with the kernel community to get the code into the mainline kernel. Except in this case we've kind of missed the boat. There's a lot of effort required now to port that patch ready for the current mainline kernel. And then the code would have to be back-ported to all the other kernel versions used by different distros, releases and development projects: like Android, OpenELEC, Chromium OS etc. But given that mini PCs have been in a steep development curve there is also question mark of whether it is worth it when a new CPU is just around the corner.

So for me it was a set of circumstances that has led me to an alternative solution. Having just replaced a monitor I noticed that the new one came with an audio 'line-in' allowing a 3.5mm jack to be inserted to enable the use of the monitor's internal speakers. And a local IT shop just happened to email a flyer that included a relatively cheap ($15) USB audio adapter claiming to be plug-and-play and supported by Linux. Well there was only one way to find out. Having bought the adapter pictured here:

I discovered it is just sufficiently wide to overlap the other USB port when plugged in. A solution was to either use an extension able such as:

USB3.0 USB2.0

or plug the adapter into the USB hub I had connected to support my wired keyboard and mouse. Having side-stepped that drama the big question was would it work? This is what I saw in Ubuntu:

A quick speaker test confirmed that both left and right were working in Ubuntu. So then I tried with Android-x86 and yes there was ... sound.

Although not technically much of an achievement at least I have working audio. Which means that I can still try to get HDMI audio working through writing code but the pressure or urgency is no longer there. Plus I get to listen to some music now while I hack away at the code regardless of the OS I'm running.