Changes between Version 1 and Version 2 of PlayerProtocol


Ignore:
Timestamp:
12/14/10 19:06:44 (9 years ago)
Author:
masc01
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • PlayerProtocol

    v1 v2  
    11[[PageOutline]] 
    22 
    3 == Protocol for the Player in SEMAINE == 
     3= Protocol for the Player in SEMAINE = 
    44Any player component in SEMAINE must follow the following protocol so that it supports ahead-of-time preparation of possible utterances. The player must keep a collection of "Animations" which can be played by a "playCommand". 
    55 
    66This protocol is currently implemented by two players: The audio-visual Windows native Player­Ogre using the Greta agent, and the speech-only player in Java class [source:trunk/java/src/eu/semaine/components/mary/QueuingAudioPlayer.java QueuingAudioPlayer]. 
    77 
    8 === Data flow === 
     8== Data flow == 
    99Low-level player data is sent to the player via the Topics 
    1010 
     
    2727 * a content ID and a content creation time         (obtained by message.getContentID() and         message.getContentCreationTime()) which are used to assemble an         Animation, to match data and command messages, and to identify the         content item in callback and log messages. 
    2828 
     29 * optionally, a contentType, such as "utterance" or "listener-vocalisation". 
     30 
    2931The idea is that a unit of player data (an "Animation") is assembled in the player from the individual data items that are coming in (currently, AUDIO, FAP and BAP). Certain data types are optional (currently: AUDIO). A message can either contain the complete data of the given type (currently the case for AUDIO) or it can contain a chunk of data (currently the case for FAP and BAP). A chunk contains information about its position in the Animation; it can be dynamically added even if the Animation is already playing. 
    3032 
    31 === Command messages === 
     33== Command messages == 
    3234There are two types of command messages: messages with data typesdataInfoandplayCommand. 
    3335 
     
    7779Every player command must contain all features of its respective type. 
    7880 
    79 === Callback messages === 
     81== Callback messages == 
    8082Event-based callback messages are sent when certain conditions are met for a given Animation. The messages go to Topic 
    8183 
     
    8789{{{ 
    8890<callback xmlns="http://www.semaine-project.eu/semaineml"> 
    89    <event id="CONTENT_ID" time="META_TIME" type="EVENT_TYPE"/> 
     91   <event id="CONTENT_ID" contentType="CONTENT_TYPE" time="META_TIME" type="EVENT_TYPE"/> 
    9092</callback> 
    9193}}} 
     
    102104 * `end` means the Animation has         finished playing. 
    103105 
    104 === Error conditions === 
     106The `contentType` attribute is present only if the incoming messages had a content type, and reproduces that content type. 
     107 
     108== Error conditions == 
    105109The content ID must be unique for the lifetime of a system. This leads to the following error conditions. 
    106110