ENABLING AUDIO ON THE CHROMIUM OS* TREE FOR CHROMEBOOKS* BASED ON INTEL® ARCHITECTURE
Audio solutions on Intel® architecture-based Chromebooks have evolved since the launch of the first Chromebook in 2009. Two different solutions have been used for Chrome OS* and Chromium* OS: HD Audio and Audio DSP.
HD Audio has been around for a long time and is still being used for the majority of Linux* desktop and laptop systems. The HD Audio solution, on the platforms that support it, provides basic playback and record functionality over internal speakers, a 3.5 mm analog jack, and an external monitor. It does not provide the advanced functionality that Low Power Engine (LPE) audio provides, such as Wake-On-Voice (WoV) and speaker protection algorithms.
The Audio DSP driver (aka ASoC Audio, LPE, cAVS, etc.) was first introduced to Chrome OS, Chromium OS, and Linux with Baytrail. The driver has since matured and from Intel’s 6th generation Core processors onward, LPE audio functionality was added in.
The algorithms for Audio DSP run on the Tensilica* DSP code, which is embedded in SoCs from Intel. Audio DSP started off as a very basic solution providing just the passthrough functionality and leaving all the processing to the codec and kernel/userspace. This has evolved to include support for different “modules” that run on the Tensilica DSP cores, such Wake-On-Voice, speaker protection, and waves post processing algorithm.
Until now, there has not been working audio on any Chromebooks based on the Chromium OS tree due to certain limitations.This document explains how we enabled LPE audio on the open source Chromium OS tree for actual products, such as the Google Pixelbook, the challenges we encountered, and how it helps customers quickly customize and scale audio solution for different Chromebook variants.
Chromium OS vs Chrome OS Audio
The key difference between Chromium OS and Chrome OS is that Chromium OS is a pure open source open source project, used primarily by developers, with code that is available for anyone to checkout, modify, and build. Chrome OS is the Google product that OEMs ship on Chromebooks for general consumer use. The two projects fundamentally share the same code base, but Chrome OS along with partner-private bits has some additional firmware features, including verified boot and easy recovery.
The diagram above shows that the topology binary file is absent in the Chromium OS tree compared to the Chrome OS tree, which is one of the main reasons that audio was not working.
Challenges We Faced while Enabling Audio
With the current topology architecture, we were using proprietary tools to manually generate the topology binary file for every Chromebook. Also, the vanilla kernel tree was moving much ahead of Google's kernel, hence some of the new development in kernel topology framework broke the audio, which thwarted our ability to verify audio on the vanilla kernel.
Manually Generating the Topology Binary File for Different Chromebooks
Chrome OS had become more famous and multiple Chromebooks were being produced by different OEMs. We had to manually generate the topology binary file for all these Chromebooks, which was difficult to scale for any new Chromebook derivatives.
Use of Proprietary Tools
The topology binary file for all Chromebooks was generated using proprietary tools, which doesn't give choices to the community for any customization related to audio.
Not Able to Cope with Upstream Changes
Since we manually generated the topology binary file, it was difficult to maintain working audio with regards to the vanilla kernel. That is because sometimes the ABI version upgrade in the kernel topology driver was not compatible with topology generated with an older ABI version, which was usually the case for Chrome OS.
To overcome the challenges listed above, the feasible solution was to automate the topology binary file generation from the Chromium tree. By that time, the open source community was supporting tools, such as alsatplg, which could be used to generate the topology binary file while building Chrome OS. This gave us some advantages:
● Scalability- since it is automated in builds, it can be extended to other boards
● Public topology binary file provided for each Chromebook
● Ease to enable audio for Reference Validation Platform (RVPs)
● Ease to customize text configuration files
● Open community support
To ensure we didn’t break working audio for an actual product, we followed a multiple-step process for integrating the support that is required to make audio work from the Chromium tree.
First, we made sure that the necessary tools, such as alsatplg, kernel support, and the configuration files were in place. Second, ebuilds scripts were written to impact only the public tree and not the working product.
At this step, all ebuilds scripts used to generate the topology binary file were in place. This meant that a build created the topology binary file, which meant working audio.
The diagram above shows how the tree looks after implementing this solution. At this point, we only checked the conf file, which is a simple text file and used the open source alsatplg tool— which is available in alsa-utils—to generate the topology binary file.
If you want to experiment on an actual product, you can modify the conf file, and the equivalent binary will be generated directly from the build.
Challenges and Resolutions
There were several challenges we encountered while integrating open source tools and ensuring the topology be compatible with the Chromium tree.
1. ALSA Update
Since there were dependencies and missing open source tools, such as alsatplg in the existing alsa-utils for Chrome, we had to upgrade alsa-lib, alsa-utils, and alsa-plugins in the Chrome tree. This update gave us all the necessary tools at the user-space level to use open source tools.
2. Mismatched ABI Versions
The targeted Chrome OS kernel was based on the v4.4 kernel, which has topology framework at ABI v4 version, while alsa-lib now that it was updated in the ALSA Update, has topology framework at ABI v5. This ABI mismatch caused an incompatible topology binary file when it is generated using the alsatplg tool. In order to make it compatible, kernel v4.4 was backported with additional backward-compatible patches. With this additional backport, we were then able to support the topology binary file based on ABI v4 and v5. This helped to maintain functional audio on products, as well functional audio on the public tree.
3. No Infrastructure
We developed scripts that generate the topology binary file without impacting existing products. This script is called whenever Chromium OS is built, putting the topology binary file directly into build packages.
Minimum work is needed to scale this solution for the Chrome OS tree. Ebuilds used in the Chromium tree will be used for the Chrome OS tree with a custom conf file that will generate the topology binary file for Chromebooks. It will be extended for feature products, such as Gemini Lake that will help the initial audio bring-up on RVPs.