Autres/Rivendellaudio
1
0
Fork 0
mirror of https://github.com/ElvishArtisan/rivendell.git synced 2025-11-26 23:30:20 +01:00
Code Issues Projects Releases Wiki Activity

2017-11-07 Fred Gleason <fredg@paravelsystems.com>

Browse Source 
* Removed 'docs/NOW+NEXT.txt'.
	* Removed 'docs/WIN32.txt'.
	* Removed 'docs/copy_split_format.odt'.
	* Moved remaining unformatted notes to 'docs/misc/.
This commit is contained in:
Fred Gleason
2017-11-07 07:43:59 -05:00
parent 0575739834
commit 1e0c305276
19 changed files with 53 additions and 109 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
docs/misc/ALSA.txt Normal file
View File

@@ -0,0 +1,42 @@
ALSA Support in Rivendell
Rivendell can optionally be compiled to provide direct support for
soundcards using the Advanced Linux Sound Architecture (ALSA).
Instructions on enabling such support can be found in the INSTALL
file. Information about ALSA itself can be found at:
http://www.alsa-project.org/
STARTING UP RIVENDELL WITH ALSA
When Rivendell's audio daemon, caed(8) is started, and ALSA support is
enabled, caed(8) will look for PCM devices named rd<n>, where <n> is a
number between 0 and 7. If it finds one or more, it will attempt to
open the devices(s) for both playback and capture. If successful, the
devices will then be available as Rivendell virtual 'card' resources,
starting with the next available card number after any HPI or JACK
devices have been started.
CONFIGURING PCM DEVICE NAMES
PCM device names for ALSA can be configured by means of entries in the ALSA
configuration file. The ALSA configuration file can either be an '.asoundrc'
file in the home directory of the user running the Rivendell daemons (normally
'root') or an '/etc/asound.conf' file which will apply to all users. For the
simple case of a single ALSA soundcard to be made visible to Rivendell, one
would create an ALSA configuration file containing the following lines:
pcm.rd0 {
type hw
card 0
}
ctl.rd0 {
type hw
card 0
}
This would create an 'alias' for the first ALSA soundcard in the
system, called 'rd0'.
More details regarding the syntax and uses of .asoundrc can be found
on the ALSA web site in the documentation section.

36
docs/misc/Makefile.am Normal file
View File

@@ -0,0 +1,36 @@
## Makefile.am
##
## docs/misc/Makefile.am for Rivendell
##
## (C) Copyright 2017 Fred Gleason <fredg@paravelsystems.com>
##
## This program is free software; you can redistribute it and/or modify
## it under the terms of the GNU General Public License version 2 as
## published by the Free Software Foundation.
##
## This program is distributed in the hope that it will be useful,
## but WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
## GNU General Public License for more details.
##
## You should have received a copy of the GNU General Public
## License along with this program; if not, write to the Free Software
## Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
##
## Use automake to process this into a Makefile.in
EXTRA_DIST = ALSA.txt\
ando_interface.odt\
colors\
pam_rd.txt\
PODCASTING.txt\
RDMONITOR.txt\
reports.txt\
SAGE_ENDEC.txt\
scheduler_formats.ods
CLEANFILES = *~
MAINTAINERCLEANFILES = *~\
aclocal.m4\
configure\
Makefile.in

132
docs/misc/PODCASTING.txt Normal file
View File

@@ -0,0 +1,132 @@
Rivendell has the ability to manage multiple RSS audio feeds, including
capabilities for posting and expiring audio automatically as well as updating
associated cast metadata.
CREATING AND POPULATING RSS FEEDS
--------------------------------
Setting up a new RSS feed is a matter of accomplishing the following steps:
1) Create and configure the feed in RDAdmin
2) Schedule the audio posts by means of one or more Upload Events in RDCatch.
3) Manage the metadata in RDCastManager.
We'll cover each of these steps in turn.
1) Creating RSS Feeds
Base parameters for each RSS feed are configured in RDAdmin->ManageFeeds. The
'CHANNEL VALUES' section shows metadata values that will be common to the feed
as a whole (as opposed to specific podcasts within it). The other parameters
are used as follows:
Key Name - A unique name, eight-characters or less in length, used to
identify the feed within Rivendell.
Audio Upload URL - This is the URL of the directory to which the audio
files will be uploaded. It is also the URL that the
system will use when deleting expired audio from the
system (e.g. by means of an FTP 'DELETE' command);
hence the specified 'Username' and 'Password' should grant
sufficient rights to allow contents in the directory
to be deleted. Currently supported protocols are
'file:', 'ftp:' and 'smb:'.
Audio Download URL - This is the URL of the directory from which the audio
files will be downloaded. The URL listed should be
world-readable by 'anonymous' users. Often, this will
be the same as the 'Audio Upload URL' above.
Enable AutoPost - If enabled, each new cast in the feed will become
'visible' immediately following upload, using the
default metadata as configured in the channel values.
If not enabled, then all new casts are placed on hold
pending the customization of the metadata for the
particular cast in RDCastManager.
Audio Extension - The file extension to use for files posted to the feed
(default: 'mp3'). NOTE: when using a non-default value,
it is necessary to manually create a corresponding
symbolic link on the web server running the 'rdfeed.xml'
script with the appropriate extension that points to the
script. For example, if using an extension of 'aac', one
would do:
cd <rd-bin-dir>
ln -s rdfeed.xml rdfeed.aac
Max. Shelf Life - Sets the maximum period (in days) that a piece of audio
can be set in RDCastManager to remain in the feed until
purged. If set to 'None', then no limit is enforced.
This value also establishes the default expiration date
for each cast (with 'Off' resulting in no expiration
date being set --i.e. the cast remains TFN).
XML Data Fields - The various 'XML' fields contain customizable templates that
Rivendell uses to construct the actual XML code that goes into the RSS file.
The following variables are automatically substituted on-the-fly when the XML
is rendered by the 'rdfeed.xml' script:
CHANNEL PARAMETERS (from CHANNEL PARAMETERS)
-- VARIABLE -- -- Meaning -------------------
----------------------------------------------
%TITLE% Channel Title
%CATEGORY% Channel Category
%LINK% Channel Link
%COPYRIGHT% Channel Copyright Notice
%WEBMASTER% Channel Webmaster Address
%DESCRIPTION% Channel Description
%BUILD_DATE% Last Build Date
%PUBLISH_DATE% Date of feed creation
%GENERATOR% Name and Version of RSS Generator
ITEM PARAMETERS (from individual cast record in RDCastManager)
-- VARIABLE ------- -- Meaning -----------------------------
-------------------------------------------------------------
%ITEM_TITLE% Item Title
%ITEM_CATEGORY% ITem Category
%ITEM_DESCRIPTION% Item Description
%ITEM_LINK% Item Link
%ITEM_AUTHOR% Item Author
%ITEM_SOURCE_TEXT% Item Third-Party Source - Human Readable
%ITEM_SOURCE_URL% Item Third-Party Source - URL Link
%ITEM_COMMENTS% Item Comments
%ITEM_AUDIO_URL% Item Audio Download URL
%ITEM_AUDIO_LENGTH% Item Audio File Length in bytes
%ITEM_AUDIO_TIME% Item Audio Playout Time in MM:SS format
%ITEM_PUBLISH_DATE% Date of cast creation
%ITEM_GUID% Globally Unique ID String
2) Posting Audio
Once the RSS feed(s) are set up, individual podcasts can be added by
scheduling one or more Upload events in RDCatch. To associate a given upload
to a particular feed, simply select the desired feed in the 'RSS Feed'
control of the Edit Upload dialog, being sure that it gets uploaded to the
location specified in the 'Audio Base URL' for the feed. RDCatch will
automatically add the audio to the feed's XML file after the upload.
3) Editing Podcast Metadata
The metadata for individual podcasts (including the cast's expiration date and
posting status) can be edited by means of the RDCastManager module. Operation
of the module should be largely self-explanatory.
POSTING THE RSS FEED FILE
-------------------------
The RSS file for each feed is generated dynamically by the RDFeed
script. The specific location of the script is determined by the value
given in the '--libexecdir=' parameter to './configure' (see the
'INSTALL' file for more details) and will also be influenced by the specific
configuration used by the web server. A typical link would looks as
follows:
http://www.example.com/rd-bin/rdfeed.xml?TEST
This link would serve the RSS file for the feed with the Key Name 'TEST'.

58
docs/misc/RDMONITOR.txt Normal file
View File

@@ -0,0 +1,58 @@
RDMonitor / RDSelect Configuration
The Rivendell RDMonitor module can be used to monitor the health state
(Database + Audio Store) of a system. Optionally, it can also be used
with RDSelect to allow a host to be switched between multiple Database +
AudioStore setups. This document describes the procedure for converting
an existing Rivendell setup to allow this functionality.
1) OVERVIEW
Rivendell requires that a configuration file exist at '/etc/rd.conf'
that describes basic parameters (such as login information for the MySQL
database server). RDMonitor/RDSelect build on this foundation by
utilizing a set of one or more configuration files located in the
'/etc/rivendell/' directory, with the 'current' configuration indicated
by a symbolic link at '/etc/rd.conf' that points to the desired configuration
in '/etc/rivendell.d/'. Several new parameters have been added to
rd.conf(5) to support this mode of operation, including:
[Identity]
Label=<label>
[AudioStore]
MountSource=<mnt-src>
MountType=<mnt-type>
MountOptions=<mnt-opts>
Where:
<label> - A text string that is displayed to indicate the overall name
of this configuration.
<mnt-src> - The filesystem to be mounted at '/var/snd' when using this
configuration, such as would be provided in fstab(5). If the desired
audio store resides on the root filesystem, then this field should be
left blank.
<mnt-type> - The type of audio store mount, such as would be specified in
fstab(5).
<mnt-opts> - The mount point options for the audio store, such as would
be specified in fstab(5).
2) CONVERTING AN OLD-STYLE SETUP
An 'old-style' setup --i.e. one that consists of a single configuration
file at '/etc/rd.conf'-- can be converted to the new layout through the
following steps:
A) Create the configuration directory:
mkdir -p /etc/rivendell.d
B) Move the original configuration file:
mv /etc/rd.conf /etc/rivendell.d/rd-default.conf
C) Create the symbolic link:
ln -s /etc/rivendell.d/rd-default.conf /etc/rd.conf

24
docs/misc/SAGE_ENDEC.txt Normal file
View File

@@ -0,0 +1,24 @@
Automating Required Weekly Tests on a Sage Digital ENDEC
Rivendell can be configured to allow Required Weekly Tests (RWTs) for the
Emergency Alert System (EAS) to be executed directly from a macro cart,
using the Digital ENDEC Emergency Alert (EAS) Unit Manufactured by Sage
Systems.
PROCEDURES
Create a macro cart and populate it with the following RML:
RN sage_endec_rwt.sh <ip-addr> <web-user> <web-password>!
where:
<ip-addr> - The IP address of the ENDEC system..
<web-user> - The name used to log in to the ENDEC's web interface.
<web-password> - The password used to log into the ENDEC's web interface.
For example, for an ENDEC at 192.168.0.1 with a login name of 'admin'
and a login password of 'letmein', you'd use:
RN sage_endec_rwt.sh 192.168.0.1 admin letmein!
Whenever this macro cart is executed, the ENDEC will run an RWT.

BIN
docs/misc/ando_interface.odt Normal file
View File

Binary file not shown.

44
docs/misc/colors Normal file
View File

@@ -0,0 +1,44 @@
System Color Table
RDAirPlay
StartButton
---------------------------------------------------
Playable green
OnAir red
Disabled darkGray
Add yellow
Delete blue
Move magenta
FullLog / Log Source
---------------------------------------------------
Playing pale green
Selected blue
Traffic pale cyan
Music pale yellow
Template pale magenta
Manual white
Error red
Cart Label
---------------------------------------------------
Playing pale green
Loaded white
Error red
Macro pale blue
LogNote lightGray
Empty darkGray
Operation Mode
---------------------------------------------------
Manual red
Automatic green
RDLibrary
Marker Colors
---------------------------------------------------
Start/End red
FadeUp/Down yellow
TalkStart/End blue
SegueStart/End cyan
HookStart/End magenta

62
docs/misc/pam_rd.txt Normal file
View File

@@ -0,0 +1,62 @@
PAM and multi-user support in Rivendell
In order to support a multi-user environment, the PAM (Pluggable
Authentication Module) infrastructure is used to activate a Rivendell
user.
First of all, a distinction should be made between *nix user accounts
and Rivendell user accounts. The former are accounts used by the
operating system; they may be local accounts in the /etc/passwd file
or they may be centraly administered accounts such as in an LDAP
server. The Rivendell user accounts are used only within the
Rivendell system and are stored within the Rivendell SQL database.
Rivendell users can be used to distinguish what groups of audio a user
can create or delete within Rivendell.
For the multi-user Rivendell environment, users should each have a
unique *nix system account and a matching Rivendell account. The *nix
user accounts should be members of a "rivendell" *nix system group and
also any group required to access audio hardware devices (ex: the
"audio" group on a debian system). The files in the Rivendell system
(/var/snd, PID files, log files) will be owned by "foouser.rivendell"
with appropiate group writable permissions. Commands to create the
*nix accounts are:
adduser foouser # create a new *nix user called foouser
adduser foouser rivendell # add foouser to the rivendll *nix group
adduser foouser audio # add foouser to the audio *nix group
Rivendell user accounts can be added with the "rdadmin" utility.
Instead of requiring users to log in multiple times (once for their
*nix account and again for their Rivendell account), the pam_rd module
allows for the Rivendell user to be set during the authentication
process of PAM.
Options the pam_rd module recognizes include:
debug - to increase logging to syslog
use_first_pass - to use only the first password entered by the
try_first_pass - to try the first password, and if that is not
found succeed prompt the user to enter their
password.
kill_rd_daemons - kill any previously running rivendell daemons
(caed, ripcd, rdcatchd)
destroy_shm - destroy and release the rivendell shared memory
segment, id "0x5005
ignore_pass - log a valid Rivendell user account into Rivendell,
ignoring any password check. the idea is to "trust"
the network logon credentials and ignore the
rivendell credentials
fail_default_user - if a corresponding Rivendell user account is not found
or if the entered password does not authenticate a
Rivendell user, the Rivendell user account is set to
the the user specified by this option (defaults to
"user").
We have had success tying the pam_rd module into the "kdm" PAM module.
The following entry was added as the last "auth" entry for "kdm" in
/etc/pam.d/kdm:
auth required pam_rd.so debug kill_rd_daemons destroy_shm ignore_pass fail_default_user=user

95
docs/misc/reports.txt Normal file
View File

@@ -0,0 +1,95 @@
Configuring Reports in Rivendell
Following are some filter-specific notes concerning configuring
reports in Rivendell:
CBSI DeltaFlex
Report files should be named according to the following scheme:
<ii><yy><mm><dd>.201
where:
<ii> -- the two digit Station ID of the corresponding CBSI system.
This same value should be set in the 'Station ID' field of the
report configuration.
<yy> -- The last two digits of the year.
<mm> -- The two digit month, in the range 01 - 12.
<dd> -- The two digit day, in the range 01 - 31.
Thus, for example, for a system with a station ID of '01', the name
part of the export path would be: '01%y%m%d.201'.
ASCAP/BMI Electronic Music Reports
Sometimes also known as the "Paris" format, these reports can be
directly submitted to ASCAP/BMI as part of their EMR (Electronic Music
Reporting) initiatives. For more information, see:
http://www.ascap.com/licensing/radio/
http://emr.bmi.com/
When setting up generation of an ASCAP/BMI Music Report, output files
should be named in the scheme:
<id><yy><mm>.emr
where:
<id> -- Your identifier string (assigned by ASCAP/BMI). Normally,
this will be a station's call letters.
<yy> -- The last two digits of the year for the data covered in the
report.
<mm> -- The two digit month for the data covered in the report, in
the range 01 - 12.
Thus, for a station called 'WAVA', the 'Station ID' box in the Edit
Report dialog would be set to 'WAVA', and the name part of the export
path would be: 'wava%y%m.emr'.
You will also need to specify a 'Station Type' and 'Station Format'
for the report. 'Station Type' is self-explanatory, while 'Station
Format' is simply a phrase describing the programming format of the
station --e.g. "Jazz", "Top Country", etc.
Another setting that will effect any Music Reports generated is the
'Usage' field on the Cart Label in RDLibrary. You should set the
value for each cart to best reflect the use that is made of the
material in it.
Music Reports are customarily generated on a monthly basis, so when
generating one in RDLogManger, be sure to select the first and last
days of the month in question for the 'Start Date' and 'End Date'
respectively, otherwise the resulting report may not include all of
the relevant playout activity.
SoundExchange Statutory License Report
This report can be imported into a spreadsheet program (such as
OpenOffice.org or Excel) and then saved as an 'XLS' file, which can then be
directly submitted to SoundExchange to satisfy their reporting
requirements for streaming music on the Internet. When configuring
the report in RDAdmin->ManageReports, fill in the fields as follows:
Station ID: The "Name of Service" as assigned by SoundExchange.
This will normally be the name of the entity operating
the service -- e.g. "SALEM COMMUNICATIONS".
Service Name: The "Channel Name" of the service, as assigned by
SoundExchange. For radio staions, this will normally be
the station's call letters -- e.g. "WAVA-FM".
Station Format: The "Transmission Category" of the service. This is
a single-letter code assigned by the U.S. Copyright
Office. For a list of possible values, see:
http://www.copyright.gov/fedreg/2004/69fr11515.pdf
When generating a report in RDLogManager->ManageReports, the system
will prompt for an 'Aggreggate Tuning Hours (ATH)' value for the
report period. This is a measure of the total amount of listenership
to the audio stream, and can normally be obtained from your streaming
provider.

BIN
docs/misc/scheduler_formats.ods Normal file
View File

Binary file not shown.