The player service uses the internal API to communicate with the playlist service. It understands the following requests in addition to the core requests mentioned earlier:
play — Plays the currently loaded file;
stop — Stops the currently loaded file;
load — Loads a new file;
eject — Unloads the currently loaded file;
seek — Seeks to a new position in the currently loaded file;
It emits the following non-core responses:
END — The file has ended of its own accord (not via user intervention);
FILE — The currently loaded file;
STATE — A state change has occurred;
TIME — The current position in the loaded file, sent periodically.
The player must implement, as a minimum, the End,
FileLoad, PlayStop, Seek, and
TimeReport features.
The player must implement the above interface. It may implement a superset of the interface, in order to implement more features than those required by the player.
The player must be able to load and play files, given their absolute path on the local filesystem.
The player must allow its audio sink to be configured. This allows a playout machine to direct each player to a separate physical or logical sound-card, which is important for allowing each playback channel to be routed to a separate mixing desk fader.
The player must allow its API end-point to be set up so as not to conflict with other BAPS3 services on the same machine. For example, if it exposes a TCP socket, the port should be configurable; if it exposes a stdin/stdout interface, then no action is needed as this cannot conflict with other services. This is to allow multiple such services to co-exist on the same machine, which is important for the multiple-output-channel use case mentioned above.