Development direction of Rivendell

Note: This article is somewhat historical. Rivendell development is now (in 2020) guided by using the Issues page on GitHub. Feel free to post a bug report or a feature request there.

Rivendell is developed using the source code management tool git and stored at GitHub. The master branch contains the "stable" source code on which releases are based. New features (may be in various states of testing and reliability, including totally broken), and bug fixes are developed on different git "branches", and may be merged into the master branch when they are deemed stable.

Current Development Roadmap

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

Qt 4 Support (Mostly COMPLETE as of Version 3)

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.

As of Version 3.4.1 (and prior), the QT3 code has been removed. There exist some remaining use of QT3 in QT4's "QT3 Compatibility Mode".

Proper UniCode Support (COMPLETE as of Version 3)

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 (COMPLETE)

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 (COMPLETE)

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 (COMPLETE as of Version 2.19)

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 management and voice tracking. 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 (COMPLETE?)

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.