Difference between revisions of "LuneOS Communication Infrastructure"

From WebOS-Ports
Jump to navigation Jump to search
(Created page with "== Overview == == Audio == Audio within openwebos-ports will be handled by PulseAudio (http://www.freedesktop.org/wiki/Software/PulseAudio). It offers a great integration in in...")
 
Line 3: Line 3:
 
== Audio ==
 
== Audio ==
  
Audio within openwebos-ports 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. [...]
+
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 ===
 
=== ALSA Use Case Manager ===
Line 48: Line 48:
 
The UI can access the different interfaces via various service interfaces
 
The UI can access the different interfaces via various service interfaces
  
* org.openwebosports.Bluetooth
+
* org.webosports.Bluetooth
* org.openwebosports.Network
+
* org.webosports.Network
* org.openwebosports.Telephony
+
* org.webosports.Telephony
* org.openwebosports.NFC
+
* org.webosports.NFC
  
 
The communication daemon is just a thin wrapper for different service daemons providing the real functionality:
 
The communication daemon is just a thin wrapper for different service daemons providing the real functionality:
  
* bluetooth: bluez
+
* bluetooth: BlueZ
* network: connman
+
* network: ConnMan
* telephony: ofono, mmsd
+
* telephony: oFono, mmsd
 
* NFC: neard
 
* NFC: neard
  
Line 79: Line 79:
 
</pre>
 
</pre>
  
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.openwebosports.NFC, rather than ws://localhost:12345).
+
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 ====
 
==== Caveats ====
  
 
Node has to be run with --harmony_proxies to support the ECMAScript 6 Proxy objects which dbus-native relies on.
 
Node has to be run with --harmony_proxies to support the ECMAScript 6 Proxy objects which dbus-native relies on.

Revision as of 10:27, 20 November 2014

Overview

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

 The ALSA Use Case Manager (UCM) is a LGPL library designed to allow high
 level control of audio use cases in sound device hardware. It is intended
 to be used by applications to quickly and easily change the hardware audio
 use case of a device in a generic and portable manner.

UCM support in PulseAudio

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

Links:

Using PulseAudio with UCM

Setting card profile (HiFi or Voice Call):

  1. pactl set-card-profile 0 HiFi
  2. pactl set-card-profile 0 "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.