On Monday 25 February 2013, Alessio Elmi wrote: > CASE 1 (present situation): Computer A has installed > RDAirPlay and has audio card. Computer B has db and audio > storage. Basically input goes from A -> B, and then audio > come back B -> A. > > CASE 2 (alternative). Computer A has only RDAirPlay and > computer B has db, audio storage and audio card. Computer A > uses B's audio engine. By doing this I should save some > millisecond.. > > CASE 3: (not sure if possible). Each Rivendell workstation > has a local copy of audio storage which is synced > "continuously" with a master share. Each Rivendell /var/snd > is local.
We use (almost) a combination of 1 and 3. Two rooms at the same site share using case 1. Studio A has a full Rivendell system. Studio B uses A's db by NFS, and remote mysql. This is documented somewhere in the Rivendell wiki. Both rooms have full access, including import capability. There is also a remote studio that connects only through public internet. It shares by copying files over, and "backup-restore" of the database. To expedite copying the audio files, they are compressed (ogg-vorbis), with most (lasting) files compressed at a high quality setting, and the whole programs (carts 800000 and up) at lower quality. The sql is backed up at the master site, and restored at the remote site. This is not continuous, but happens often on a schedule. The remote site cannot import files, because they would be lost at the next sync. How well does it work? It would be nice if the remote site could import, so there would be no real master, all sites equal. Then I would change the main site over to use the copy method too. Users of the remote site often want to import. At the main site, the shared system is a single point of failure. Separation (like the remote site) would provide a backup that is always running. _______________________________________________ Rivendell-dev mailing list [email protected] http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
