At the moment, the USB-C audio application case isn’t being implemented consistently across all mobile devices that rely solely on that connection form.
There are two operating modes – a “passive” accessory mode which creates inbound and outbound analogue audio paths as if it is a 3.5mm audio jack, and an “active” mode which uses USB Audio device classes and outboard digital-analogue audio circuitry to create the sound to be heard via the accessory.
The former passive setup is primarily exploited by USB-C jack adaptors and basic headset implementations, especially “earbud-style” headsets. Here, the host device which is typically the smartphone or tablet would use an onboard audio chipset to convert the sound between an analogue and digital representation.
If there is some form of remote control, a basic implementation may be in the form of a single button that starts and stops media or answers and ends calls. On the other hand, if the USB Human Interface Device specifications are implemented properly in mobile operating systems, it may allow for a device to support advanced multifunction remote control.
At the moment, it may be a case of trial-and-error to find out if a USB-C Audio passive-mode headset or adaptor will work across USB-C-equipped regular computers. So for, to my knowledge, recent iterations of the Apple MacBook lineup of laptops that use this connection will provide some support for this setup.
The latter active setup would be targeted at premium or audiophile applications such as highly-strung USB digital-analogue adaptors, noise-cancelling headsets or headsets with highly-strung digital-analogue circuitry. In some cases, this setup may also support accessory devices that implement multiple-microphone arrays.
It may also apply to wired setups involving home or car audio equipment. In this case, one would be thinking of this kind of equipment providing digital-analogue interface, power to the host device and remote-control / accessory-display abilities.
Here, they have to fully implement the USB Audio Device Class 3 peripheral class as expected in the “textbook”. As well, iOS and Android need to provide a native class driver for this device class and implement its code as expected for a mobile device which will do communications and / or multimedia. This would mean that microphones have to be used as an audio endpoint for communications purposes including regular telephony as well as for multimedia purposes. It may be a non-issue with regular computers running the Windows or MacOS desktop operating systems where it is easier for the operating system or application software to “purpose” an audio endpoint.
USB Audio Device Class 3 provides inherent support for audio-processing so accessory manufacturers don’t need to reinvent the wheel by creating their own software to implement any sort of sound processing. As well, Android and iOS need to support the inclusion of audio-processing logic in the inbound or outbound audio-signal paths in a purpose-specific manner.
Power and connectivity
There will be power and connectivity issues raised for both implementations of the USB-C Audio application. Active devices will need to draw power from the host unless they have their own battery. But with proper implementation of USB-C Power Delivery, it could allow a USB-C Audio accessory with a very high capacity battery to provide power to the host smartphone.
The passive setup wouldn’t work properly with USB-C hubs or devices that have this function unless it is assured that the hub will assure a proper clean electrical connection between the host and the accessory.
Remote control and accessory display
Another issue yet to be raised is implementation of USB Human-Interface-Device Classes and Usage Tables when it comes to using a USB-C accessory as a control surface for the host. The key issue here is whether there is proper operating-system support especially in the mobile operating systems. In the same context, there will be a market requirement for the accessory device to be able to view host-device-held lists like call lists, message lists and track lists.
The functions considered relevant to this usage case would be sound volume and transport control (play / pause / next track / previous track / etc) for multimedia; and caller volume, microphone mute and call control for communications. Accessory-based display would also need to be factored in with USB-C audio adaptors and in-line remote-control modules which implement an LCD or OLED display.
There may be use cases where multiple remote control devices are used in the same setup, typically to offer complementary functionality. Examples of this may include a USB headset with elementary remote-control for volume and a single-button control for multimedia “start-stop” or call “answer-end” functionality; along with a display-equipped inline remote control which allows for track navigation or advanced call-control.
There will also be an issue regarding use of the USB-C cable as an aerial (antenna) for broadcast-radio reception whether the tuner is built in to the smartphone or the accessory. It is because of a long-standing design factor for Walkman-type radios with separate headphones where the headphone cord served as the radio’s aerial. Similarly single-piece headphone-based personal radios implemented the headband as their aerial.
It also extends to the ability for mobile operating systems to control broadcast-radio tuners integrated within smartphones or accessories to the fullest extent possible. This would include preset-station management, “follow-this-station” operation for stations appearing at other broadcast locations, graphical identifiers amongst other things.
If the smartphone and audio-accessory industry wants us to think of using the USB-C connector as the point to connect all peripherals, they need iOS and Android to have full native USB Audio Device Class 3 support including support for advanced-audio modes. As well, the operating systems need to have USB Human Interface Device class support for remote-control and accessory display abilities. Similarly, there would have to be proper support for broadcast-radio operation with USB-C-based mobile-device setups.