Development direction of Rivendell

Rivendell is developed on a "two-track" system: a "stable" series of releases (currently numbered 1.x.x), which are well tested and generally reliable; and a "development" series (currently only available as the head branch in Rivendell CVS) that is undergoing active development and may be in various states of testing and reliablility, including totally broken. Instructions for checking out copies of each from CVS can be found in Downloading Rivendell Source from CVS.

Current Development Roadmap

This is a list of current enhancements slated to be worked on by the project developers for deployment in the upcoming Rivendell 2.x.x.

Qt 4 Support

The first order of business. The thinking at this point is that a basic port using the Qt3 compatibility library will be adequate, as removing that will require some very major reworking of large parts of the system.

Proper UniCode Support

No more (const char *)s! This will (possibly) also require tweaking charsets on MySQL to work properly. Another big job, as this will require recasting virtually every SQL statement in the codebase.

CAE Service Methods

Currently /var/snd/ needs to be writable to all Rivendell users. By modifying caed(8) to provide a set of audio import/export "services", eliminate this requirement, which is a big security hole. This would also make all the ugly import/export stuff in 'scripts/' go away.

Inter-Host/Module Event Notification

Some sort of inter-host and inter-module general update notification method is needed for cases where changes in one object/module can cause side effects in others (e.g. changing a cart in RDLibrary referenced by a running log in RDAirPlay). We currently brute-force this case by polling the DB for changes -- a big scalability bottleneck. The current thinking is to designate a privately-scoped multicast address for this (basically, similar to how RDCatch deck updates are now handled, but much more efficiently as we wouldn't need to maintain one-to-one connection states).

Proper Log Machine Abstraction

The log machine logic at present is tightly bound to GUI rendering code, making log machine operation with realtime permissions extremely problematic. The plan is to abstract the basic machine operation away from any presentation code (essentially, what we now do with RDCatch(1)/RDCatchd(8). This would also make it possible to develop multiple front ends for RDAirPlay (e.g. Ajax, Ncurses, etc).

Library Storage Formats

Adding FLAC support seems a natural choice. OggVorbis may be possible as well, but CPU requirements for encoding remain high even with current-generation CPUs. A generalized method of storing peak-value data will be needed, as the current method is dependent on the MS RIFF WAVE format, which is not definied for any of the open source encodings.

Surround-Sound Support

Both 5.1 and 5.1/2.0 (Fraunhofer's "HD Radio") modes.

Remote Operation

Operation from remote environments is a frequently requested feature, especially for Library managment and Voicetracking. Some general system infrastructure will be required (e.g. audio "thumbnails", low-bitrate renditions of content suitable for streaming over remote connections).

Improved Stream Management

At present a playback stream is obtained at load playback time and held until the playback is unloaded. Given that some ASI cards have as few as 4 available playback streams, it is not hard to run the system out of available playbacks when pausing a few files. We need to free streams on paused events.

My proposed fix is to retire 'unload playback' and to add a 'pause' rml instead. Thus a stopped playback is automatically unloaded and a loaded playback can be made to time out after a few minutes to avoid any chance of leaking playbacks. The pause state will release the stream (if these are limited resorces) while keeping the file open.

Further the return code for load playback should differentiate between no file, invalid file and no available stream so that rdairplay can avoid the death spiral if it does run out of streams.