Chapter 1. System Overview

Table of Contents

1.1. Introducing Rivendell
1.1.1. The Rivendell Object Paradigm
1.1.2. The Rivendell Hardware Paradigm

1.1. Introducing Rivendell

Rivendell is a digital audio content management and delivery system that is targeted for use in professional radio broadcast environments. It includes robust tools for the acquisition, organization, management and play out of audio material from and to a diverse array of sources and destinations. Support for a wide variety of external third party hardware devices and software packages commonly used in the radio industry is featured, including interfaces for:

  • Audio Routing Switchers
  • Satellite Downlink Receivers
  • Audio Mixing Consoles
  • Commercial Traffic and Music Scheduling Systems

Rivendell is made available under the terms of the GNU General Public License, version 2. As such, it comes with absolutely no warranty, not even the implied warranties of merchantability or fitness for a particular purpose. See the full text of the GPLv2 for details.

Rivendell has been designed and developed from the ground up to run on the popular and highly stable GNU/Linux™ operating system. Full source code is available online at https://github.com/ElvishArtisan/rivendell.

Rivendell has been designed to be able to operate in a wide variety of roles, ranging from single, self-contained workstations to large, multi-station clusters consisting of multiple workstations and centralized servers. Also included are redundancy and hot-standby capabilities to allow for reliable operation even in the face of hardware faults.

Rivendell is implemented as a set of interactive tools or 'modules' that collectively provide the complete functionality of the system. Briefly, these modules and their functions are:

RDLibrary
Library content management
RDCatch
Automatic time-driven event scheduler
RDAirPlay
On-air play out application
RDLogEdit
Log editing and voicetracking tool
RDLogManager
Automated log generation and interface utility
RDLogin
Set the current user on a Rivendell host
RDCartSlots
Emulate a traditional broadcast cart machine
RDPanel
Large "cart wall" application
RDCastManager
Podcast feed manager
RDAdmin
System wide configuration

The operation of each of these modules is explained in detail in the chapters that follow. However, we first need to cover some basic concepts common to all Rivendell modules.

1.1.1. The Rivendell Object Paradigm

All Rivendell modules make use of the following classes of system resources:

We'll cover each of these concepts in turn.

1.1.1.1. Realms

A Rivendell realm is a set of one or more hosts that utilize a common Rivendell database. Each such realm has its own, independent set of objects, such as cart library, RDCatch event list, set of hosts, etc. Different Rivendell realms are effectively isolated from each other at the application level.

Caution

If more than one Rivendell realm will be residing in a single IP multicast domain, then each realm must be assigned a unique multicast notification address. See "Multicast Address for Notifications" in the Section 12.6, “Managing System Settings”.

1.1.1.2. Hosts

Every physical or virtual computer that is running Rivendell software is referred to as a host. Any host in a Rivendell network can be individually configured and controlled from any other host within the same realm (provided the system administrator has enabled this capability). Hosts can be used for a wide variety of applications, including content ingestion and management, automatic recording (sometimes referred to as "netcatching"), on-air play out or log (sometimes also referred to as a playlist) generation. It is also possible for a single host to perform all of these functions.

Each Rivendell host is a member of precisely one Rivendell realm. Each host within a given realm must be reachable from all other hosts in that realm and reside within the same IP multicast domain. In most cases, this can be ensured by connecting all hosts to the same network switch and configuring them to use the same IP subnet. If this is not feasible, then special arrangements, such as installation of a network bridge or multicast router between the host subnets may be necessary.

1.1.1.3. Users

Every host on a Rivendell network has one or more users available to it. In this context, a 'user' is merely a set of access policies established by the system administrator that defines what tasks that user is or is not allowed to perform. The set of available users is global to every host in a given Rivendell system; with each host operating under exactly one user at a time. Each host also has one user designated to be the default user. As the name suggests, this is the set of user policies that are loaded by default when the system starts up. It is also possible to change the user currently in use on a given host by running the RDLogin module.

1.1.1.4. Groups

A Rivendell group is a system of categories that is used by the audio library to classify and organize the audio within the library. Groups are a very powerful capability, and many operations within Rivendell can be specified on the basis of group membership. The actual classification scheme, including the number of available groups and their names, is completely arbitrary so as to allow each facility to tailor a schema that best fits its own operational requirements. Designing and implementing the group schema is one of the most important tasks facing the Rivendell system administrator, as a well-designed schema can make long-term maintenance and management of the system substantially easier vis-a-vis a poorly thought out one. We will cover groups in detail in the chapters devoted to the RDLibrary and RDAdmin modules.

1.1.1.5. Services

Every facility at which Rivendell is deployed is presumed to have one or more ultimate destinations for which audio is intended. These could be radio stations --e.g. WAVA--, satellite uplink channels, live Internet audio streams, or any mix of the above. Each of these sorts of destinations is referred to in Rivendell as a service, and certain parameters, particularly as regards audio play out and log (playlist) creation, can be configured on the basis of what particular service is being referenced.

1.1.2. The Rivendell Hardware Paradigm

In addition to the core computer hardware (CPU, motherboard, etc), each Rivendell host typically interacts with specialized hardware required to accomplish the task at hand. Three main categories of such 'special' hardware are of interest to us here, the three being audio adapters, serial ports and GPIO/switcher devices. We'll cover each below.

1.1.2.1. Audio Adapters

An audio adapter in Rivendell is simply a device or facility for getting audio into and/or out of a host on a realtime basis. Often this will be a sound card, although other possibilities (such as AoIP or direct routing to other audio applications) also exist. The three main classes of audio adapters supported by Rivendell are:

Advanced Linux Sound Architecture (ALSA)

The standard Linux sound card driver starting with the 2.6.x kernel series, ALSA supports a huge array of commercially available sound cards, ranging from entry level 'game' cards to high-end cards aimed at professional audio uses. More information, including a current list of supported cards, is available at the ALSA web site, http://www.alsa-project.org/.

HPI Adapters

These are high-performance sound cards manufactured by AudioScience Corporation. Designed and built specifically for broadcast automation applications, many feature advanced capabilities (such as on-board MPEG codecs and AES3 i/o) specially aimed for use in that setting. They are so-called because Rivendell uses AudioScience's special 'HPI' driver to access and control them. More information is available at AudioScience's web site at http://www.audioscience.com/.

JACK Audio Interconnect Kit

JACK is not a class of hardware devices, but rather an audio 'framework' that allows compliant applications to share audio resources and route audio in realtime amongst themselves. JACK is different from similar efforts within the Linux realm in that it was designed from the ground up for professional audio work, with particular focus upon low-latency operation and synchronous execution of all clients. More information can be found at the JACK web site, https://jackaudio.org/.

1.1.2.2. Serial Ports

Commonly known in the DOS/Windows world as 'COM ports', serial ports are often used to communicate with outboard gear, such as satellite receivers and audio switchers. Up to eight serial ports can be accessed simultaneously by each Rivendell host.

1.1.2.3. GPIO/Switcher Devices

Because these capabilities are often (although not always) bundled together in the same device, Rivendell lumps GPIO and switcher devices together within the same class. GPIO stands for 'General Purpose Input Output'. As the name implies, these devices can be used to interface to a huge variety of outboard equipment by means of control lines. GPI (General Purpose Input) lines can be used to sense changes in an outboard system's state (and Rivendell programmed to take various actions on the basis of that), while GPO (General Purpose Output) lines can be used to send commands to an outboard system. The actual physical interfacing of GPIO devices is complex and generally beyond the scope of this document. Readers are encouraged to consult a good handbook on radio engineering for more information. A current list of GPIO/Switcher devices supported by Rivendell can be found in Appendix C, Supported GPIO/Switcher Devices.