.. _enable-uac3:
Enabling USB Audio Class 3.0 audio in |C|
#########################################
Introduction
************
There has been an increasing trend of adopting USB digital audio among hardware manufacturers. Even Google has done away with the 3.5mm radio jack in its latest `Pixel 2 `_ phone series. This is because USB digital audio will considerably increase the music quality and also eliminate the need for a separate audio jack, making the form factors thinner. The Android Compatibility Definition Document (CDD) version 9.0 mandates that the devices without the 3.5mm audio jack must implement the USB Audio Class [1]_ [2]_. The only major drawback with the USB digital audio is its higher power consumption relative to analog audio. To address this issue, USB-IF has come up with a new specification - USB Audio Class 3.0 specification (UAC3), which primarily focuses on optimizing power consumption over USB audio.
USB Audio Class 3.0 specification (UAC3)
****************************************
`USB Audio Class Specification 3.0 `_ was released by USB-IF with an aim to provide power-saving features and support new codec types and data formats for consumer audio applications. Some of its salient features are:
#. Support for LPM (link power management) L1 mode
#. Support for new power domains where we can selectively turn off certain
components to save power
#. New cluster descriptors, high capability descriptors and class-specific
descriptors
#. Support for basic audio device definition (BADD) profiles
#. Support for new codecs and data formats
:abbr:`BADD (basic audio device definition)` is a subset of
:abbr:`UAC3 (USB Audio Class 3.0 specification)` and it is strongly
recommended to have the BADD configuration implemented in the audio devices
that are compliant with :abbr:`UAC3 (USB Audio Class 3.0 specification)`.
BADD defines three types of audio functions:
#. Basic audio output function (BAOF)
#. Basic audio input function (BAIF)
#. Basic audio I/O function (BAIOF)
It includes the following profiles:
* Generic I/O
* Headphone
* Speaker
* Microphone
* Headset
* Headset adapter
* Speakerphone
Enabling UAC3 configuration in |C|
==================================
To maintain backward-compatibility with older host software which may not
support UAC3, the specification mandates that the first configuration in the
audio device should be compatible with either UAC1 (USB Audio Class 1.0) or
UAC2 (USB Audio Class 2.0). The next configuration will be a BADD-compliant
configuration. Selecting this configuration will enable the system to save
power by leveraging the new power domains and LPM (link power management)
L1 capability of the audio device. Support for this configuration is
available in |C|. Make sure that the following patches are in your build:
1. Patch to add support for USB Audio Class 3.0
.. code-block:: console
commit 9a2fe9b801f585baccf8352d82839dcd54b300cf
Author: Ruslan Bilovol
Date: Wed Mar 21 02:03:59 2018 +0200
ALSA: usb: initial USB Audio Device Class 3.0 support
Recently released USB Audio Class 3.0 specification
introduces many significant changes comparing to
previous versions, like
- new Power Domains, support for LPM/L1
- new Cluster descriptor
- changed layout of all class-specific descriptors
- new High Capability descriptors
- New class-specific String descriptors
- new and removed units
- additional sources for interrupts
- removed Type II Audio Data Formats
- ... and many other things (check spec)
It also provides backward compatibility through
multiple configurations, as well as requires
mandatory support for BADD (Basic Audio Device
Definition) on each ADC3.0 compliant device
This patch adds initial support of UAC3 specification
that is enough for Generic I/O Profile (BAOF, BAIF)
device support from BADD document.
Signed-off-by: Ruslan Bilovol
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Takashi Iwai
2. Patch to add support for BADD profiles
.. code-block:: console
commit 17156f23e93c0f59e06dd2aaffd06221341caaee
Author: Ruslan Bilovol
Date: Fri May 4 04:24:04 2018 +0300
ALSA: usb: add UAC3 BADD profiles support
Recently released USB Audio Class 3.0 specification
contains BADD (Basic Audio Device Definition) document
which describes pre-defined UAC3 configurations.
BADD support is mandatory for UAC3 devices, it should be
implemented as a separate USB device configuration.
As per BADD document, class-specific descriptors
shall not be included in the Deviceâ<80><99>s Configuration
descriptor ("inferred"), but host can guess them
from BADD profile number, number of endpoints and
their max packed sizes.
This patch adds support of all BADD profiles from the spec
Signed-off-by: Ruslan Bilovol
Tested-by: Jorge Sanjuan
Signed-off-by: Takashi Iwai
3. Other patches adding additional features for UAC3:
.. code-block:: console
ALSA: usb-audio: Operate UAC3 Power Domains in PCM callbacks
ALSA: usb-audio: Add UAC3 Power Domains to suspend/resume
ALSA: usb-audio: Unify virtual type units type to UAC3 values
ALSA: usb-audio: Add support for Processing Units in UAC3
ALSA: usb-audio: Add support for Selector Units in UAC3
ALSA: usb-audio: Add insertion control for UAC3 BADD
ALSA: usb-audio: UAC3: Parse Input Terminal number of channels.
ALSA: usb-audio: UAC3 Add support for connector insertion.
ALSA: usb-audio: UAC3. Add support for mixer unit.
ALSA: usb-audio: Use Class Specific EP for UAC3 devices.
ALSA: usb-audio: Add sanity checks in UAC3 clock parsers
4. Selecting UAC3 configuration for audio:
.. code-block:: console
commit 084d710fc377bf1d32d67c000590d9d1ab37d375
Author: Saranya Gopal
Date: Wed Sep 12 01:03:57 2018 +0530
usbcore: Select UAC3 configuration for audio if present
USB audio class 3.0 specification introduced many significant
changes like
- new power domains, support for LPM/L1
- new cluster descriptor
- new high capability and class-specific string descriptors
- BADD profiles
- ... and many other things (check spec from link below:
http://www.usb.org/developers/docs/devclass_docs/USB_Audio_v3.0.zip)
Now that UAC3 is supported in linux, choose UAC3
configuration for audio if the device supports it.
Selecting this configuration will enable the system to
save power by leveraging the new power domains and LPM L1
capability and also support new codec types and data formats
for consumer audio applications.
Signed-off-by: Saranya Gopal
Reviewed-by: Felipe Balbi
Enabling LPM in extensible host controller interface (XHCI)
===========================================================
:abbr:`XHCI (extensible host controller interface)` is capable of supporting
hardware :abbr:`LPM (link power management)`
in modern Intel® architecture platforms. For example, the following *sysfs*
entry confirms that the hardware USB port **3-1** is capable of supporting
hardware LPM, you can get the port information for your system from the
audio device enumeration logs in the ``dmesg`` output.
.. code-block:: bash
$ cat /sys/bus/usb/devices/3-1/power/usb2_hardware_lpm
enabled
If the output value is **disabled**, you could enable LPM by writing **1** to the entry. The transition into LPM L1 mode can be confirmed through protocol traces.
The following snapshot shows Lecroy traces of LPM transaction on a Kaby Lake
platform with a UAC3-compliant audio device:
.. figure:: images/uac3-usb-protocol-trace.png
:align: center
Here, the LPM L1 residency is 252 us. The service interval in this configuration is 1 ms. The USB host is required to request LPM/L1 state after servicing the device in each service interval. In our case, the device was entering LPM L1 with around 250 us L1 residency during every 1 ms service interval.
Conclusion
**********
We have enabled **USB Audio Class 3.0** in |C| which helps us to leverage the power-saving features of USB digital audio. In future, USB audio power can be further optimized by offloading USB audio to an offload-engine, thereby allowing the processor to go into deeper sleep states.
.. [1] Android 9 Compatibility Definition - `Professional Audio `_
.. [2] Android 9 Compatibility Definition - `Audio `_