Sound Manager Application Guide

Revision: 0.3alpha
TOYOTA MOTOR CORPORATION
Advanced Driver Information Technology
11th/Dec/2017

Table of content

Target reader of this document

Application developer whose software uses sound output.

Overview

The sound manager is the service which provides sound-right management for multiple sound sources. This service is based on GENIVI Audio Manager, and this package contains service binding and library for API calling. The reason why this service is based on GENIVI Audio Manager is because GENIVI Audio Manager supports highly strong and flexible sound-right management function.

In order to understand, the below figure shows the one of typical usecases. In this example, there are four sound mode.

  1. Audio Off
  2. Media Player
  3. Tel (Ring and talking)
  4. TTS (Text To Speech; typically it's used by Navigation sound)

Figure: Typical usecase

The important points are:

  • There is a priority for each sound source. In this example, the priority of "Tel" and "TTS" is higher than "MediaPlayer". Therefore when the system got incoming call, all four outputs of MediaPlayer are muted automatically by Sound Manager. And in this timing, Sound Manager will issue the event to Media Player, then Media Player can stop the music. (Because depending on OEM's requirement, "Stop" is required.) "Tel" and "TTS" have the same priority. So if TTS event happened on talking, each sound will output from independent speaker. If on-hook button is touched, Sound Manager will resume previous sound mode. In this example, basically it's MediaPlayer sound. But if TTS still playing, three speaker will output MediaPlayer sound but one speaker will continue to output TTS sound.
  • Sound mode transition should be done by Sound Manager not Applications. Actually application cannot recognize all sound source and its priority, so some centerized manager is required. Sound Manager provides this function. Sound Manager has a database for usecase and priority and in line with this policy Sound Manager controls proper sound mode.

The below links show the example of Sound/Window mode transition.

  • Single window application This transition assumes target IVI system support only one window on screen. It's a similar transition to CES2017 demo.
  • Dual window application This transition assumes target IVI system support two window (split screen) on screen.

Of course user can customize shortcut menu, but since it's too many states so this example limits shortcut menu as "Home", "MediaPlayer", "HVAC" and "Navigation".

Getting Start

Supported environment

Item Description
AGL version Electric Eel
Hardware Renesas R-Car Starter Kit Pro(M3)

Build

You can make Sound Manager object files by the following two stage operations.

Download recipe

If repo is already done, please start with git clone

mkdir WORK
cd WORK
repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo
repo sync

Bitbake

source meta-agl/scripts/aglsetup.sh -m m3ulcb agl-demo agl-devel agl-appfw-smack agl-hmi-framework
bitbake agl-demo-platform

Configuring

To use Sound Manager API, an application shall paste the following configuration definition into "config.xml" of application.

<feature name="urn:AGL:widget:required-api">
    <param name="soundmanager" value="ws" />
</feature>

Additional work

Add Policy file

To add Sound Manager Domain into policy, put the following file to /etc/audiomanager/control on the target rootfs.

${SOUNDMANAGER_DIR}/conf/audiomanager-config-sample/configuration.xml

This is a sample configuration.

Remove Module router of Pulse Audio

Because the module rounter accesses Audio manager for getting sound right instead of application in CES2017, after you changed your application code for Sound manager, you shall modify the configuration for puluse audio not to load module router. To do this, you shall comment out line.143 of /etc/pulse/default.pa on the target rootfs as below.

.ifexists module-router.so
#load-module module-router
.endif

How to call Sound Manager APIs from your Application?

Sound Manager provides a library which is called "libsoundmanager". This library provides function style API calling interface. So you can include libsoundmanager.hpp headerfile, and can link this library. Please also refer sample application and template.

See also our Sample code.

Supported usecase

  1. Active source change
  2. When user choose different audio source with current one, IVI system stop or pause current source and activate new one.
  3. When user connect external device e.g. iPhone, USB memory IVI system change active source automatically to connected one.
  4. Active source locking
  5. When user is in phone call, IVI restrict to change active source.
  6. Interrupt source mixing
  7. When car close to cross road IVI system reduce the volume of current source and mix with interrupt source e.g. Navigation Guidance.
  8. Volume change
  9. User can change the volume of active source or sink.
  10. When user change volume during interruption e.g. Navigation Guidance, IVI system change its volume temporary or permanently.
  11. Mute/unmute
  12. User can mute/unmute current active source.
  13. Volume management
  14. When user change active source, IVI system mute/unmute to avoid distortion of sound.
  15. Volume acceleration
  16. When road noise is increased by speed, IVI system automatically change the volume of active source.
  17. Routing sound
  18. System needs to route sound stream to proper zones. (driver zone, passenger zone, rear seat zone)

See also this page

Software Architecture

The architecture of Sound Manager is shown below. Sound Manager is the service designed to be used by multiple applications. Therefore Sound Manager framework consists of two binder layers. Please refer the following figure. The upper binder is for application side security context. The lower binder is for server side security context. Usually an application side binder has some business logic for each application, so the number of binders depend on the number of applications which use Sound Manager. On the other hand, regarding lower binder there is only one module in the system. This binder receives messages from multiple applications (in detail, it comes from upper layer binder).

The communication protocols between libsoundmanager and upper binder, upper binder and lower binder, are WebSocket. The protocols between lower binder (soundmanager-binding) and AudioManager is D-Bus.

software-stack.png

API reference

"libsoundmanager" and "soundmanager_binding" provides several kinds of APIs, and these APIs basically correspond to GENIVI Audio Manager API. (Some APIs are Sound Manager original functions.)

For understanding, GENIVI Audio Manager stands for one core module and three plug-ins.

  1. AudioManagerDaemon This is a core module of Audio Manager.
  2. AudioManagerCommandPlugin This is a command interface for Audio Manager.
  3. AudioManagerController This plug-in can be used for sound-right management.
  4. AudioManagerRountingPlugin This plug-in abstracts the hardware and software. And sometimes there may be multiple plug-ins.

*) See also GENIVI AudioManager Components

See also GENIVI AudioManager Components (This figure was copied from GENIVI Web page.)

APIs

  • init(int port, const std::string& token)
  • registerSource(const std::string& sourceName)
  • connect(int sourceID, int sinkID)
  • connect(int sourceID, const std::string& sinkName)
  • disconnect(int connectionID)
  • ackSetSourceState(int handle, int err)
  • registerCallback( void (event_cb)(const std::string& event, struct json_object event_contents), void (reply_cb)(struct json_object reply_contents), void (*hangup_cb)(void) = nullptr)

Regarding more detail, please refer doxygen documents.

Events

"libsoundmanager" provides the feature which receives the events which an app subscribes with "subscribe" API. An application can get events to register a callback function with "registerCallback" API.

And this event is subscribed automatically. (See below Note)

  • asyncSetSourceState

The below events are available but not mandatory.

  • newMainConnection
  • removedMainConnection
  • mainConnectionStateChanged
  • volumeChanged
  • sinkMuteStateChanged
  • setRoutingReady
  • asyncConnect
  • asyncDisconnect

Note:

"asyncSetSourceState" is always subscribed in init phase because this is the most important event for audio policy management. This event indicates the approval/disapproval/pause.

Regarding more detail, please refer doxygen documents.

Sequence

StartUp

seq_startup.png

Registration

seq_registration.png

Request Sound Right

seq_requestsoundmode.png

Connect Sound Route

seq_connectsoundroute.png

Start Sound Streaming

seq_startsoundstreaming.png

Stop Sound Streaming

seq_stopsoundstreaming.png

Disconnect Sound Route

seq_disconnectsoundroute.png

Change Volume

seq_changevolume.png

Set Mute State

seq_setmutestate.png

Release Sound Right

seq_releasesoundmode.png

Audio Domain

One of the most important concept of Audio Manager is Audio Domain. To use GENIVI Audio Manager based system, it may be better to understand this concept. The below document should bring good understanding.

GENIVI Audio Manager: Generic Controller Plug-in

Although strongly recommended to read whole pages, but you can get quick understanding by page.10 to 14.

Sample code

You can find samples using Sound Manager as below.

  • apps/agl-service-homescreen-2017/sample/template
  • apps/radio (branch=sandbox/knimitz/hmi-framework)

Limitation

  • Sound of application is not automatically muted for now because Audio Manager doesn't stop with current plugins. Just notify stop/pause/play.