This article provides guidance to developers of iOS audio streaming applications about how to enable and support playback of Dolby Atmos content over CarPlay.

Note that streaming of Dolby Atmos content via CarPlay to a Dolby Car Experience enabled head unit requires running on iOS version 17.3 or higher. Several updates are required in the iOS application, which are described in this article.

Dolby Car Experience is a technology designed to deliver immersive audio experiences in vehicles. It integrates Dolby technologies such Dolby Atmos and Dolby Digital Plus to provide enhanced audio playback of streaming music content through a car's audio system, aiming to recreate the artist's intended sound with greater clarity, detail and dimensionality even while on the go.

This article addresses only the required delta for the enablement of Dolby Atmos. Existing CarPlay support in the iOS application is expected and assumed. For details about how to add general CarPlay support to your application, refer to these materials: Apple documentation: Accelerate your app and Apple documentation: CarPlay App Programming Guide.

General prerequisites

To support Dolby Atmos playback over CarPlay, your iOS application must support AirPlay enhanced audio buffering. For details about how to add this support, refer to the Apple documentation: Streaming and AirPlay.

Enabling Dolby Atmos over CarPlay

The following sequence diagram shows the high level overview of interaction between the streaming application and iOS that are required to enable Dolby Atmos over CarPlay.

Figure 1: Interaction between the streaming application and iOS

 

Detecting Dolby Atmos playback capability

As of iOS 17.3, the AVAudioSession object has been extended with means to detect the capability for playback of multichannel audio and to indicate it accordingly.

The AVAudioSession object can be used to:
• Detect if the CarPlay endpoint supports multichannel audio output layouts and specify them.
• Indicate the currently resolved audio rendering mode (described in Badging Dolby Atmos/Dolby Audio playback section)
• Determining if the car supports immersive multichannel layouts

Determining if the car supports immersive multichannel layouts

Use the AVAudioSession.supportedOutputChannelLayouts array property to determine if the car supports immersive multichannel output channel layouts.
These immersive multichannel layout tags might be reported by a CarPlay endpoint:

- kAudioChannelLayoutTag_Atmos_7_1_4
- kAudioChannelLayoutTag_Atmos_7_1_2
- kAudioChannelLayoutTag_Atmos_5_1_4
- kAudioChannelLayoutTag_Atmos_5_1_2

Note: Additional configurations specifying surround sound configurations, such as MPEG_7_1_C or MPEG_5_1_D may be reported but are not suitable for Dolby Atmos.

iOS does not provide a specific API for applications to query whether the connected car supports Dolby Atmos playback or not.

Instead, the presence of one of the AVAudioChannelLayout objects containing the AudioChannelLayoutTags listed above will indicate that the connected car supports immersive audio playback.

Note that a Dolby Car Experience enabled car will report support for one of the following layout tags for Dolby Atmos:

kAudioChannelLayoutTag_Atmos_7_1_4
kAudioChannelLayoutTag_Atmos_5_1_4

The array might contain other layout tags, indicating support for Dolby Audio (with 5.1 and/or 7.1 layout tags) and other supported audio channel layouts.

You can enable your application to use the AVAudioSession.renderingCapabilitiesChangeNotification to report changes of this property.

The AVAudioSession.supportedOutputChannelLayouts array will only be non-empty if the AVAudioSession is active and the audio output is routed to AVAudioSessionPortCarAudio.

This information should be used in the iOS application to determine which audio asset variant will be used for playback.

Note: The presence of Dolby Atmos LayoutTags in supportedOutputChannelLayouts is a necessary condition, but it is not sufficient to guarantee that the connected endpoint is a Dolby Car Experience enabled car. The application should not rely on this to inform playback badging behavior in its user interface. Rather, the application should rely on the resolved rendering mode provided by iOS after playback has been initiated (AVAudioSession.RenderingMode).

Figure 2: Does the car support immersive audio layouts?

 

 

Playing Dolby Atmos content

Dolby Atmos content can be played over CarPlay using two available application programming interface (API) sets for enhanced buffering:
• Using simple enhanced buffering API: AVPlayer or AVQueuePlayer Apple documentation: Implementing simple enhanced buffering for your content.
• Using flexible enhanced buffering API: AVSampleBufferAudioRenderer and AVSampleBufferRenderSynchronizer Apple documentation: Implementing flexible enhanced buffering for your content.

The application is able to choose which APIs to use, depending on the current audio route. For example, use one API for local or bluetooth playback and a different one for a CarPlay endpoint (AVAudioSessionPortCarAudio).

This should be handled with routeChangeNotification, and is described in this article: Apple documentation: Responding to Audio Route Changes.

The updates that have to be made in the iOS application depend on whether the decoding of the Dolby Atmos content takes place in the application or in iOS (in-app decoding versus native decoding).

Supported Dolby formats

This table provides an overview about the delivery formats that are currently supported by Dolby for playback in iOS applications over CarPlay.

Table 1: Delivery formats for Dolby Audio and Dolby Atmos

In-app decoding with Dolby Audio for Applications

Applications that use Dolby AC-4 for content delivery must use in-app decoding, since iOS does not support decoding of Dolby AC-4 content at this time.

In this case, the application must decode and render the content to one of the supported audio layouts (described in Detecting Dolby Atmos playback capability section), depending on the source of the content. Note that Dolby AC-4 IMS (Immersive Stereo) content is not suitable for playback over CarPlay and cannot be used.

Dolby Atmos content must be rendered to the 7.1.x or 5.1.x layout supported by the car, while Dolby Audio content must be rendered to 5.1, unless it is a 7.1 Dolby Audio content and the car declares support for 7.1 audio channel layout.

The decoded and rendered pulse code modulation (PCM) audio samples must be passed to the AVSampleBufferAudioRenderer and AVSampleBufferRenderSynchronizer API of the AVFoundation framework and tagged with the proper AudioChannelLayoutTag.

Please note that in the current version of CarPlay, Dolby Atmos and Dolby Audio content provided as decoded PCM audio samples will not be able to be badged correctly by iOS on the head unit display, since the system is not able to confirm the source format at this time.

Native decoding

If the decoding takes place in iOS, the application must use the AVFoundation framework and the preferred API that supports enhanced buffering to provide Dolby Atmos or Dolby Audio content as a Dolby Digital Plus bitstream. iOS will then decode and render the content to the optimal audio channel layout, based on the supported layouts of the car.

The application must follow the resolved value of AVAudioSession.RenderingMode to reflect correct badging of Dolby Audio or Dolby Atmos content in the user interface (UI), as described in Badging Dolby Atmos/Dolby Audio playback.

Badging Dolby Atmos/Dolby Audio playback

iOS 17.3 or later indicates the current rendering mode of the audio based on a combination of the variant of the audio asset that is fed to or picked up by the chosen playback API and the supported audio output channel layouts of the car.

Use the AVAudioSession.renderingMode property to check if the currently played-back content is rendered as Dolby Atmos or Dolby Audio and to badge it accordingly in the UI of your application on the iPhone screen. The badge on the head unit screen will be automatically applied by iOS. For details, refer to the Dolby Atmos Automotive UI/UX Guidelines.

Note: Please note that in this CarPlay release if your app is performing in-app decoding and providing rendered PCM to the playback API, iOS will not indicate it as either Dolby Atmos or Dolby Audio on the head unit display. You should still provide a correct Dolby Audio or Dolby Atmos badge on the iPhone
screen part of your UI.

You can enable your application to use AVAudioSession.renderingModeChangeNotification to report changes of this property.

Defined rendering modes:

 

Figure 3: Dolby Atmos badging

 

 

Loudness management

In the current release, there is no built-in support for active loudness management in the Apple CarPlay pipeline. As a result, we expect that Dolby content (Dolby Atmos and Dolby Audio) and stereo content will be played back at the level it was mastered in the studio without automatic volume normalization.

Note that Dolby Atmos music content is typically mastered at a maximum of -18 LKFS, while stereo content could be mastered at higher levels (and with less dynamic range).

For applications that implement their own in-app audio decoding and processing pipeline (for example, by using Dolby Audio for Applications or other), we recommend that all Dolby Atmos and Dolby Audio content is normalized in the application to a target level of -20 LKFS after decoding. Matching the playback level between Dolby Atmos and stereo content is currently handled through static gain adjustment inside the car head unit (implemented by car OEMs or Tier 1 suppliers).

For applications that leverage native decoders in iOS, you may see some variations in playback volume between tracks or between Dolby Atmos and stereo content. We are working with Apple on improvements for this behavior. Please test with your application and service and send feedback about any issues or feature requests related to loudness management.