DataTime Processing Framework
Description of Existing and Potentially Useful Software

 |  Users
 |  Programmers  |  Project Developers
 |  SourceForge Project Page
 |  Resources

i. Contents

II. Multimedia and Simulation Frameworks

System Abstraction Frameworks

Development Tools
V. References

I. Introduction

    While this project intends to create a new framework, considering existing software is important. Existent software can reveal successful design approaches and desirable functionality, as well as drawbacks and potential pitfalls. We are also interested in software toolkits that may be useful in creating the DTPF and facilitating future projects. This document makes some reference to material discussed in the background section of the project requirements document. Readers are advised to review this material for context.

II. Multimedia and Simulation Frameworks

The BeOS MediaKit
   The BeOS MediaKit is a framework for real-time processing of audio and video data, paying particular attention to the timing and delivery of the data. Processing in this system is based around 'nodes' which are modules of processing that can be producers of data, consumers of data, or both. The MediaKit makes heavy use of threading, and is designed so that the nodes can be dynamically connected at run-time. A server application allows client programs to make use of common system nodes (audio input, audio mixing, video output, etc.), load plug-in nodes, and also make their nodes available to other programs. The Cortex program was created as a graphical interface to the MediaKit server application services and allows users to manipulate nodes and their connections. Be Inc. which developed the BeOS and its MediaKit was unable to continue and sold its intellectual property to Palm in late 2001. Since then, a team of open-source software developers have created a compatible implementation of the MediaKit but this still has the limitation of being dependent on the BeOS platform.
    While the specific platform dependency precludes direct use of the MediaKit, the overall design appears attractive for DTPF. The modular organization of processing into nodes that can be dynamically connected allows reuse of a node's functionality in many different settings. The focus on threaded processing and asynchronous messaging allows greater utilization of hardware parallelism. The client-server arrangement allows separate processes to makes use of nodes and other resources. These higher level aspects of the MediaKit cover much of what we wish to achieve with DTPF.

DataTime 0
    The SoundStream software used a processing model similar to the node-based modular model of the MediaKit, although without most of the flexibility and generality. While the audio-visual processing system was successful for the SoundStream project, it was implemented without a formal design or clear plans for enhancement to address its shortcomings, and has been disused. This software is interesting in that the knowledge gained implementing it is directly applicable to DTPF in both concept (both projects deal with similar data processing problems) and ability (both projects share common developers). The name 'DataTime' also originates with this software (DataTime 0). The DataTime 0 source is available here.

The Java Media Framework
    The Java Media Framework (JMF) is the Java language package for processing audio and video data. The framework is specified through a series of interfaces for which a particular JMF distribution will provide implementations. Processing is organized similar to many other media processing frameworks, allowing pipe and filter connections and providing default components to handle tasks such as playback. A plug-in API provides another mechanism for extensibility. As the JMF is a Java language API, properly written programs using it can be expected to run on platforms where the JMF is available. However the JMF is a Java API and we desire a solution more compatible with C++. While performance of Java programs has improved, and subsets and extensions of Java for real-time purposes exist, writing high performance code in Java is not as simple as it might be in C++. Approaches to real-time programming in Java impose strict constraints on the language features and classes that can be used (Wellings 2004; [ToDo: Need to add link/reference to a nice DrDobbs Journal article on real-time Java, unfortunately the article can not be located at this time...]), resulting in a programming model that is drastically different from traditional Java programming (in many approaches to real-time Java the indeterminancy of garbage collection is avoided by strictly avoiding any dynamic allocation during real-time operation with the result that the new operator and any method that uses it must be avoided). Making use of hardware specific resources is also more difficult in Java. As an example, accessing a device driver in Java would require implementing the desired operations in a C/C++ shared library and providing a Java class with native methods that call the implementation in the C/C++ shared library. With future application to robotics envisioned for DTPF, issues of performance and flexible access to system services become even more important. While not directly used for DTPF, the JMF is valuable as another perspective on the problems approached here.

    IKAROS is an ongoing research project, with the goal "to develop an open infrastructure for system level modeling of the brain including databases of experimental data, computational models and functional brain data. The system will make heavy use of the emerging standards for Internet based information and will make all information accessible through an open web-based interface. In addition, Ikaros can be used as a control architecture for robots." (IKAROS web page). While the intended domain of Ikaros has some overlap with the domain considered here, the focus on brain modeling is a limitation for our purposes, and some of the features (the web-based interface) are beyond our needs. Further, Ikaros is in a development phase which could lead to problems with unstable programming interfaces and possibly incomplete, untested or missing functionality. Nevertheless, the approach taken by Ikaros in relation to the goals of DTPF should be investigated further in the design stages of this project.

    OpenHRP is a simulator and motion control library for humanoid robotics. This system focuses on the problems involved in implementing robotic control software. Included in the system is a robot simulator to allow development and evaluation of the control software before it is used with a physical robot. At this point in time OpenHRP appears to have been applied to work on a specific robot so it is unclear how well the success reported will generalize to other robots. This focus on robotic control could be useful as we become more involved with robotic hardware. For the modeling purposes considered here this focus may actually be constraining and introduce unneeded complexity. Support for OSX is also an issue. While OpenHRP appears unsuitable for direct use in the core of DTPF, this does not necessarily preclude the use of OpenHRP for future projects concerned more with robotics and where platform constraints aren't such an issue.

III. System Abstraction Frameworks

The Adaptive Communication Environment
    The Adaptive Communication Environment (ACE) "is a freely available, open-source object-oriented (OO) framework that implements many core patterns for concurrent communication software. ACE provides a rich set of reusable C++ wrapper facades and framework components that perform common communication software tasks across a range of OS platforms. The communication software tasks provided by ACE include event demultiplexing and event handler dispatching, signal handling, service initialization, interprocess communication, shared memory management, message routing, dynamic (re)configuration of distributed services, concurrent execution and synchronization." (ACE Overview).
    "ACE is targeted for developers of high-performance and real-time communication services and applications. It simplifies the development of OO network applications and services that utilize interprocess communication, event demultiplexing, explicit dynamic linking, and concurrency. In addition, ACE automates system configuration and reconfiguration by dynamically linking services into applications at run-time and executing these services in one or more processes or threads." (ACE Overview).
    Another possibly attractive feature of ACE is The ACE ORB (TAO) which is an RT CORBA implementation tuned for soft real-time tasks (Nagel, 2004). Direct use of such a CORBA implementation may not be suitable for the various stakeholders involved here. Knowledge of CORBA programming is not to be expected of model programmers or project developers. There are also some configuration issues involved that may be an inappropriate burden on end-users of models.

Yet Another Robot Platform
    Yet Another Robot Platform (YARP) is a framework intended for developing software for modular distributed real-time robot systems. YARP uses and extends ACE to provide object-oriented abstractions over system services such as multi-threading, distributed processing, flexible message based IPC, wrappers over some hardware devices, and some mathematical and image processing algorithms. The modular, port-based messaging is particularly interesting. Ports are created in read or write modes, with a name to allow identification. Once connected a writer port can be used to send arbitrary data to reader ports using multiple transport mechanisms. A shared memory based scheme is used for communication within local computers and various network protocols are available for communication across computers.

    MUSCLE "is a robust, somewhat scalable, cross-platform client-server solution for dynamic distributed applications for BeOS and other operating systems. It's distributed in source code form, and includes a ready-to-compile server, utility classes, and example clients. Tested under BeOS and Linux, but should compile and run under any POSIX compliant OS with a C++ compiler." (MUSCLE Home Page). While MUSCLE provides yet another set of distributed programming functionality, the interest for DTPF lies in its utility and messaging functionality. Specifically MUSCLE provides a generic message class which functions as a container for name/value pairs of data. Objects of this message class can be 'flattened' ('serialized' in Java parlance) to an array of bytes suitable for transmission over any number of IPC facilities (TCP/UDP sockets, SysV message queues, etc.). The flattening process automatically handles endian related issues for built-in language data types.

    Another advantage of ACE, YARP and MUSCLE is portability. YARP supports Linux, Windows (NT, 2K, XP) and QNX OS platforms. In the DTPF project, the Mac OSX platform is an intended target. While ACE supports OSX, YARP does not have full support for OSX at this time and may not be appropriate for direct use in DTPF. Developing on Linux using YARP and porting YARP/DTPF to OSX later is possible, but this is likely to be more work than developing DTPF directly on OSX using ACE. The major concern in moving DTPF/YARP to OSX would be endian issues. Pointer and other type size differences should not be an issue if reasonable coding practices are followed (i.e., never cast a pointer to an integer, never make assumptions about the size of 'long', etc.).

IV. Development Tools

Add a discusion of useful tools such as Doxygen?

V. References


BeOS MediaKit:

DataTime 0:

  • Home Page:
  • Williams, A. (2004). Examining Doxygen. Dr. Dobb's Journal, October 2004 (pp. 52-56). CMP Media LLC, San Francisco.







Hosted on Logo

© 2005 Eric J. Mislivec, Last Modified: 22 June, 2005