| The Linux Audio Backstop | ||||||||||||||||||||||||
| Webcatcher Interface | ||||||||||||||||||||||||
| DECK | The deck parameter controls which audio device (soundcard) is used for the event. Anywhere from one to four such devices (numbered from '0' to '3') may be present on your system. The listbox will allow you to choose only values that are appropriate for your system. | |||||||||||||||||||||||
| FILENAME | The filename parameter determines the name of the audio file to be used for a Record or Playback event. You should include the file extension (e.g. '.wav') as part of the name. These files go in the directory that is configured as the AudioRoot directory (typically '/usr/snd'). Configuration macros can be used in this field. This value is ignored for all other type events. | |||||||||||||||||||||||
| LENGTH | The length parameter determines how long a file will be recorded, in the format MM:SS, where MM is minutes and SS is seconds. This value is ignored for all other type events. | |||||||||||||||||||||||
| SOURCE |
The source parameter determines which audio source (satellite feed,
switcher channel or whatever) will be used for a record event, or what
channel to switch to for a playback event. This value is ignored for
all other type events.
The values available in this field will vary depending upon the local installation. See your engineer for details! | |||||||||||||||||||||||
| EVENT TYPE | The event type parameter determines what type of event will be scheduled. At present, there are four choices available to you: Timed Record, Timed Playback, Timed Switch and Pulse Relay. All of these events are scheduled on the basis of the time of day, and are otherwise pretty obvious as to what they do. | |||||||||||||||||||||||
| PIN | The pin parameter controls which output relay on the GPIO board is associated with this event. Currently, this has meaning only to a Pulse Relay event, and is ignored by all other event types. | |||||||||||||||||||||||
| CHANNELS | The channels parameter controls how many channels of audio will be present in a recording. Setting this to Mono will record one channel, while Stereo will provide two. This parameter is ignored for all other type events. | |||||||||||||||||||||||
| DATE |
The date parameter can be used to specify a particular date or set of
dates at which the event is to take place, in the format MM-DD-YYYY
, where MM is the month, DD is the
day and YYYY is the four-digit year.
The most obvious use of date is to define a particular date for an event, as for example '05-04-2000'. This would cause the event to be run on that date and no other. While that's certainly possible, the date parameter is actually much more powerful than that. Date supports the notion of wildcards , special characters that match any value. For example, working from our date example above, suppose instead we entered '05-*-2000'. Instead of running on just a single day, the event would now be scheduled to run on every day of May 2000, as the wildcard character '*' matches every day of the month. To take another example, entering '*-05-2000' would cause the event to be run on the fifth day of every month of the year 2000. Entering '05-05-*' would run the event on the fifth of May every year. It's possible to use more than one wildcard in a single date. For example, '*-5-*' would run an event on the fifth day of every month, regardless of year. Putting wildcards in all the date fields (as in '*-*-*') invokes a special case: the system will now use the days of the week selected in the day of the week parameter to determine which days to run the event. See the Day Of The Week section for details on how this works. | |||||||||||||||||||||||
| TIME |
The time parameter defines the start time for an event, in the format
HH:MM:SS, where HH is the hours part
(in 24-hour military format), MM is the minutes and
SS is the seconds.
Just as with date, time supports the use of wildcards. For example, suppose you had a newscast that you needed to record every hour at 55:00 past the hour. Rather than define twenty-four seperate events, you could simply define one by using '*:55:00' for the time. The '*' matches every hour, so this event would be run every hour at 55:00 past, subject only to whatever other limitations you may have placed on it in the date or day of week parameters. | |||||||||||||||||||||||
| DAY OF THE WEEK |
The day of the week parameter controls what day of the week
(Monday, Tuesday, etc.) an event will run, if the date parameter is set
to all wildcards ('*-*-*'). Thus, checking only 'Monday' will cause the
event to be run on Monday of each week, regardless of the date. More than one
day can be checked at a time, so (for example) checking Monday, Tuesday,
Wednesday, Thursday and Friday would cause the event to be run on every
weekday.
If the date parameter is not set to all wildcards, than the choice made here in the day of the week will be ignored, and the date value used instead. | |||||||||||||||||||||||
| SAMPLE RATE | The sample rate parameter controls the sample rate (32 kHz, 44.1 kHz or 48 kHz) to be used for a recording. There is seldom a reason to use anything other than the default (44.1 kHz) here, which will give "CD Quality" audio. This parameter is ignored for playback events. | |||||||||||||||||||||||
| SAMPLE SIZE | The sample size parameter is used to control the number of bits per audio sample (eight or sixteen) to be used for a recording. For modern audio hardware, there is virtually never any reason to use anything other than the default (sixteen) here. This parameter is ignored for playback events. | |||||||||||||||||||||||
| AUTO TRIM |
The auto-trim parameters auto-trim holdoff and auto-trim
threshold are used to control how the beginning and end of a record-type
event will be handled. The default case (with both parameters set to zero)
is for the event to start and end as scheduled without reference to what the
audio input may be "hearing" at the time. However, it's possible to use these
parameters to program the system to wait until it "hears" audio at a certain
level before it begins recording. The auto-trim holdoff parameter
defines how long (in seconds) the system will wait for audio at the start of a
recording until it gives up. The auto-trim threshold parameter
determines what minimum audio
level needs to be detected before starting the recording (in dB below digital
zero, meaning that a higher number will make the input more
sensitive). If the AutoTrim is enabled for the start of the recording, then
audio at the end will be trimmed in a similar fashion --i.e. all trailing
silence will be removed, with "silence" being defined as an audio level below
that given in the threshold parameter.
In practice, you will likely need to experiment a bit to arrive at values that work well for your setup. A good place to start is with a hold off of 5 seconds and a threshold value of 40. | |||||||||||||||||||||||
| POST COMMAND | The Linux Audio Backstop will attempt to execute the shell command specified in the post command field after the associated event has completed. This can be useful for automating such processes as audio encoding or CD creation. Configuration macros can be used in this field. | |||||||||||||||||||||||
| DELETE SOURCE | Checking this box will cause Timed Record or Timed Playback events to delete the audio file referenced in the filename entry after completion of the associated post command. This entry has no effect on other types of events. | |||||||||||||||||||||||
| RELAY MAP |
The Linux Audio Backstop has the ability to record and then play back
out-of-band data in the form of closures (referred to as 'relays' for
the rest of this discussion) in syncronization with the audio. These
relays are commonly used in radio network operations to signal
affiliates that some sort of action needs to be taken, such as firing
a legal ID or starting a local break. The Relay Map section
controls how these relays will be routed, both during recording and
playback, on an event-by-event basis.
By default, on a new event, all relays will be set to off. For a record event, this means that any closures received on the corresponding relay inputs will be ignored, while for playback events, any relays previously recorded with the audio will be ignored. Setting a particular relay to a numeric value means that any relay events received on that line (relay inputs for a record event, or recorded relays for playback) will be routed to the selected relay. This combination of input and output relay mapping is designed to provide maximum flexibility for sites that may have need to record and play out programs on multiple channels. An example may be helpful. Say we wish to record a live program that needs to include a relay to indicate the start of a local break. A momentary button has been wired to relay input '4' of the computer that the show's host can press to indicate this. In order to set up a record event to capture this, we would set the '4:' relay map control to the logical relay number we want these button presses to appear as in our recording. For our example, we'll set it to '0'. Any button presses during the record event will now be recorded as a 'relay 0' in the resulting file. Now, it's time to play back the recording we've just made. For the purposes of our example, let's say that, due to the way the network uplink is configured, all local break relays need to be sent out relay output '2'. To accomplish this, we would set the '0:' control in the Playback Event Relay Map to '2'. | |||||||||||||||||||||||
| CONFIGRUATION MACROS |
Configuration macros can be used to specify parameters such
as the date, time and filename at runtime. The available macros are:
| |||||||||||||||||||||||