LuneOS Communication Infrastructure

Audio
Audio within LuneOS will be handled by PulseAudio (http://www.freedesktop.org/wiki/Software/PulseAudio). It offers a great integration in into the Linux system and with the software we're using for communication purpose (ofono, bluez). Handling audio on an embedded device is different than on a desktop system. [...]

ALSA Use Case Manager

 * http://www.slimlogic.co.uk/2009/02/alsa-use-case-manager/
 * alsaucm command line utility is available in version 1.0.25 of alsa-utilities which is already available in oe-core

UCM support in PulseAudio
Basic UCM support is in Pulseaudio HEAD available but not released. Latest version is 2.0.

Links:


 * Linaro Blueprint: https://blueprints.launchpad.net/linaro-ubuntu/+spec/enable-update-alsa-pulseaudio-ucm
 * Linaro Multimedia UCM integration: https://launchpad.net/linaro-multimedia-ucm/2011.11/2011.11
 * PulseAudio UCM mapping: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs/1111/AudioIntegration/UCMPulseAudio/Analyzation
 * https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs/1111/AudioIntegration/UCMPulseAudio

Using PulseAudio with UCM
Setting card profile (HiFi or Voice Call):

Communication Daemon
The communication daemon will offer interfaces for the different communication interfaces like


 * bluetooth
 * network
 * telephony
 * NFC

The UI can access the different interfaces via various service interfaces


 * org.webosports.Bluetooth
 * org.webosports.Network
 * org.webosports.Telephony
 * org.webosports.NFC

The communication daemon is just a thin wrapper for different service daemons providing the real functionality:


 * bluetooth: BlueZ
 * network: ConnMan
 * telephony: oFono, mmsd
 * NFC: neard

Design
Communications between native services and userland applications is generally handled through dbus. This is great, until your userland applications exist in a JavaScript VM. The easiest way to get data in and out of JavaScript applications right now appears to be WebSockets, so let's use that.


 * Applications speak WebSockets
 * Services speak DBus

NodeJS can do both of these nicely, and lets our frontend guys have a bit of say in how they expect their data, since it's the same language they speak. After evaluating a handful of DBus libraries for NodeJS, dbus-native seems to be our best bet: It's actively developed, pure javascript and has a nice clean API:

var dbus = require('dbus-native');

var bus = dbus.systemBus; var nm = bus.getInterface('org.freedesktop.NetworkManager', '/org/freedesktop/NetworkManager', 'org.freedesktop.NetworkManager'); nm.Enable(true, function(err, res) {     console.log(err, res);  });

There will be a basic router daemon which will require in the actual models which speak DBus; this lets us keep a single endpoint and also do service-name-based routing (ie: org.webosports.NFC, rather than ws://localhost:12345).

Caveats
Node has to be run with --harmony_proxies to support the ECMAScript 6 Proxy objects which dbus-native relies on.