Audio Manager Overview

What is Audio Manager
Audio manager is a core component for Moblin, it is able to manage all audio streams, audio applications and audio devices. And it is extendable for any specific hardware platforms. Hum, it is implemented by Bu, Long (long.bu@intel.com); Zhang, Xin (xing.z.zhang@intel.com); Zheng, Huan (huan.zheng@intel.com)

Audio manager is an extension for PulseAudio, it is implemented as PulseAudio modules. In order to be extendable to specific hardware platforms, Audio manager is designed to be module-based, there is a generic module which is platform independent, and there will be a platform dependant module which handles all platform related details, these two modules communicates in certain way which is defined in another document. E.g. For MRST platform, there will be a generic module and a MRST module. Any platform that needs Audio manager should implement a platform dependant module for its platform.

For audio applications, audio manager supports extracting configuration information from configuration file and bind the configuration info to audio applications as soon as audio applications start to render data to PulseAudio. The audio streams created by audio applications will inherit all the configure info from the audio applications that created them, thus audio manager could control them with regards to these configuration info. The configuration info basically contains media role, mixable, preferred device, etc.

Audio devices are managed by platform dependant module, the platform dependant module should provide device list to generic module, and provides callback functions to generic module to manage devices.

Audio manager provides a set API to write audio manager compliant applications, the detailed info about API is defined in “Moblin Audio Manager API”, the detailed info about how to write audio manager is defined in “Moblin Audio Manager Compliant Application Writer’s Guide”. Audio manager compliant applications
Audio manager also provides a set API to write audio manager controlling application, which could be used as a central point to manager all audio apps/streams/devices.

Above is an example of audio manager which supports a specific platform, as you can see, there are two PA modules, one is platform independent module which could be used among various platforms, the other is platform dependant module which is specific for that platform.

The platform in this example is different from common platform, this platform supports audio stream that does not go into PA, given AM controls audio streams by PA, in order to let AM to control these special audio streams, the platform dependant module need to provide stream control callback to generic module, so that generic module could able to control the special audio streams. And the platform dependant module needs to provide DBUS methods to audio applications, so that audio applications could notify the state change of the special audio streams to AM. If a specific platform does not have any special audio streams, which means all audio streams go into PA, then supporting this kind of platform would be easier.

Among the architecture, the policy manager is the most important part, it is in charge of all decisions based on configuration info, and current status of audio streams/devices.

Audio manager is driven by Pulse Audio messages, these Pulse Audio messages will trigger policy manager to perform reevaluation, and there are four places that could generate Pulse Audio messages.

• DBUS APIs. AM provides DBUS APIs to applications, if application uses these APIs, corresponding Pulse Audio messages will be emitted out to the message process thread. Then policy manager will reevaluate current status and make further decisions. E.g. Notify AM that the state of the stream of specific platform has changed.

• Hardware detection. When hardware changes, the platform dependant module will be able to detect and report to generic module, then policy manager will decide what to do.

• PA stream state change. When the state of the Pulse Audio streams changed, AM hooks for those state change will emit specific Pulse Audio messages which in turn may trigger reevaluation. Pulse Audio stream state change is detected by Pulse Audio hooks, while state change of streams which are platform specific need to notify Audio manager by DBUS method provided by the platform dependant module.

• org.freedesktop.DBus. When an application is killed, and this application previously registered itself by DBUS API. The AM callback of signal NameOwnerChanged of org.freedesktop.DBus will be triggered to clear the information of that app. This part is not drawn on the figure above. Because it’s small

Below is a simple example about how audio manager works with a compliant audio application, this application firstly has no priority to proceed playback, so that AM mutes its volume and send signal to notify app to pause, and then, AM finds out it could proceed playback (probably a stream of higher priority paused/dead), so AM unmutes its volume and send signal to notify app to resume.