|Robust Audio Tool||UCL Multimedia|
RAT Frequently Asked QuestionsFor IPv6 related problems, please also see the IPv6 FAQ.
RAT is a multicast (or unicast) audio tool. It is best to start it using a session directory tool, like sdr. RAT does not do call or session invitation for two reasons. There are several alternative protocols for performing call setup and negotiation, and adding code to the audio tool to do so encumbers the tool unnecessarily. In addition, these call setup and negotiation is reasonably complex and best handled elsewhere so that video, whiteboard, etc, can all leverage the same functionality if desired.
If desired RAT can be launched from the command line as described below.
You can start it from the command line using an IP address and port number as arguments. The syntax is:
To join a multicast group (address range 126.96.36.199 to 188.8.131.52 - i.e. an address that starts with "1110" - see RFC1112) just enter the group address and a port number.
To connect to two unicast hosts, goldfinger and jaws, on jaws type:
and on goldfinger type:
Recent versions of rat allow you to omit the port number, and default to using port 5004. This is primarily useful when using rat in unicast mode, since you simply start it with the name of the remote machine.
The email@example.com mailing list is an open list, for general discussion and feedback related to rat. If you use rat, you are encouraged to subscribe. Bugs should be reported to this list, in the first instance.
The firstname.lastname@example.org mailing list is for feedback directed at the tool developers only.
When reporting problems please detail:
The more information you provide, the quicker we are to be able to assist you.
You may also find the essay How to Report Bugs Effectively useful.
All code contributions are welcomed. The preferred source code to use is in the UCL CVS repository since this is the code that is going to be the next release. Please send patches and the version of the source code used to email@example.com.
The list below details cards we have tested. If you are using different hardware we would be interested to know how it performs.
The current release version of RAT will pick the first enabled soundcard that it discovers. If you have multiple soundcards, select the properties of the card you do not wish to use on the (Control Panel->Multimedia->AudioDevices) and select "Do not map through this device". Then enable mapping through the device you want to use and then reboot.
It maybe that RAT does not work with one of your cards, but other conferencing software does. In this case you will need to select the appropriate card in each case.
Thanks to Steve Morgan, Computer Services Dept, University of Liverpool, for raising and resolving this problem.
Some network adapter drivers are not able to take direction from more than one application at a time. This is either a hardware or driver bug in the network adapter. This used to be a common problem when multicast was a novelty. Updating the driver for the adaptor may fix the problem, otherwise a new adapter is necessary.
We have had a report that the Linksys PC100 Ethernet card will only take direction from one Windows application. The remedy was to replace it with a Linksys Cardbus 10/100.
We have endevoured to make the PC silence suppression algorithm perform better. The problem with some PC hardware is the amount of noise present in the signal. The algorithm has been tested with the Daytona, Monster Sound, and SoundBlaster-16 soundcards with three different microphones. However, this is no guarantee that it will work with other hardware. If you have a problem use push-to-talk.
There is considerable crosstalk between the analog microphone and headset interfaces when operating in full duplex mode on some SGI hardware (i.e. Indy's). This breaks the silence suppression algorithm, although we really ought to be able to build a more robust algorithm. SGI are aware of the problem, but it is unlikely to be fixed on existing hardware (the O2 machines do not have this problem).
RAT 3.2.0 and later require a full duplex soundcard (i.e. one able to record and playback simultaneously) and will not function with older, half-duplex, cards. The single most common reason why RAT will not detect your soundcard is because the card either does not support full duplex, or is misconfigured.
If you are using PC hardware, you should check that the DMA channels are configured correctly. This is a common error on Linux, since the RedHat sndconfig program can report a working configuration, even if these are set up wrongly.
Note also that being able to play CDs or MP3 files on the machine is not an indication that your sound card is configured correctly for rat. Playing out audio is a half-duplex operation, rat requires that your card runs in full duplex mode.
If versions of rat prior to 3.2.0 work on your machine, but later versions do not, it is likely that you have a half-duplex soundcard. Older versions of rat will work with these cards - but we do not support them now.
Some versions of the Linux driver for the ESS Maestro 2E card have bugs which prevent them from working with rat. You need to use v0.14 of the maestro driver (linux 2.2.16) or above.
By default VAT is not RTP compliant. When invoking VAT use the -r command line flag to enable RTP packet formating.
In some cases vat will generate invalid RTCP packets when encryption is being used. RAT has strict packet validation, and so discards these packets, resulting in those participants not being visible in the RAT window.
This bug has been demonstrated in vat-4.0pre8 and earlier, and may exist in other releases.
The current RTP payload type for redundant audio is derived from that presented at the Montreal IETF meeting. It is currently supported by the following tools:
Earlier versions of these tools used a different packet format, and are not compatible.
If you know of additional tools to this list, please mail rat-trap.
The RTP payload format for redundant audio is described in RFC2198.
If running on solaris 2.5.1 RAT fails with the error:
ld.so.1: rat-4.0.1: fatal: relocation error:
file rat-4.0.1: symbol vsnprintf: referenced symbol not found
This is due to changes in the libraries Sun provide. The fix is either to recompile RAT from source on a solaris 2.5.1 machine, or to upgrade to a newer version of Solaris.
This seems to be a bug in some versions of Linux libc. Try doing:
setenv MALLOC_CHECK_ 0
before running RAT, which solves the problem in many cases.
Some people have reported problems if RAT is not installed in /usr/bin. This appears to be a feature of RedHat 4.1, and we've not been able to duplicate this with the Debian installation we use.
It has been reported that these problems persist on Red Hat Linux 5.0.
On Red Hat Linux 6.0 you may see the message "No locks available" on starting RAT. This occurs when running with your home directory on an NFS mounted filestore, if you are not running lockd. Ensure that lockd is running before using RAT (the NFS package must be started in /etc/rc.d/rc5.d). Similar problems have been reported with SuSE 6.2.
This appears to be due to a bug in the FreeBSD networking code. Upgrade to a more recent version of FreeBSD (FreeBSD 3.x or later work).
This appears to be due to a bug in the FreeBSD audio driver code. It is hoped that this will be fixed in a future version of FreeBSD.
Some versions of the winsock library have bugs which cause this behaviour, try upgrading. We have found that winsock2.2 works correctly.
Note that, starting with RAT v3.0.31 you are required to have version 2 (or later) of the winsock library to use RAT.
The ws2_32.dll is Microsoft's winsock2 dynamic link library. The were a number of serious flaws in the multicast support provided by earlier versions. If it is not present on your system you upgrade your Windows installation. Service packs may be downloaded from the Microsoft web site - Windows 95/NT updates.
RAT versions 3.0.31-3.0.33 require Winsock2. Later versions will work with both Winsock 1 and Winsock 2. Thanks to Ross Finlayson for highlighting that this was possible.
There is a known bug in the Microsoft's IP stack which means that TTL zero IP packets (such as those used in the mbus) escape onto the network. There is a hotfix for Windows NT 4.0 (ask Microsoft technical support about article Q234980 in the Microsoft Product Support Services Knowledgebase), but no fix exists for other versions of Windows. It is believed that Windows NT 4.0 service pack 6 and Windows 2000 also fix this problem.
RAT-3.0.x has a bug in the device control settings which means that it sometimes controls the wrong audio channel. This is fixed in RAT-4.0.x and later.
If you have trouble with earlier versions of RAT, you can adjust the gain via the Windows audio control panel. By double-clicking on the yellow loudspeaker icon in the tray at the right hand end of the task-bar, a panel called Volume Control appears. In the context of RAT, this handles the "received" audio, via the "Wave" section and mixed into the main "volume control" at the left. The "line-in" here must be muted and/or slid to minimum, otherwise the microphone is being mixed into the loudspeakers with the obvious consequences.
The less obvious part of this is that if you take Options/Properties you can click on the "recording" button and then the panel will turn into a Recording Control. In the context of the RAT this is the "transmit" section, and you could inject CD Audio, or MIDI sound from the Mixer, into the transmitted stream. Normally of course you will want to select the Line-in here (or Microphone if you are using that input).
Contributed by Alan Flavell.
Starting with version 4.1.0, RAT has comprised three processes which communicate with each other using a shared message bus. These processes are called, for example, rat-4.1.2, rat-4.1.2-ui and rat-4.1.2-media. This error occurs when the main process cannot start one (or both) of the other processes.
Check that all three programs are installed in a directory which is in your search path. Also check that the -media and -ui programs have not been renamed.
RAT v4 uses a locally scoped multicast group as a message bus (MBUS) to communicate between the user interface and the audio engine. The same message bus is incorporated in UCL versions of VIC with the intention of providing lip-synchronization. For lip-sychronization to be effective the audio and video tools need to negotiate appropriate playout delays.
Unfortunately there are versions of UCL tools in circulation that do not have the same configuration file format, and backwards compatibility has not been added. Thus the reason for the assertion failure. It is now possible to get versions of the UCL tools with the same mbus file format - the latest vic and rat releases have this.
In addition, it is necessary to clean out persistent MBUS state. Make sure none of the UCL applications are running and then:
RAT4 uses locally scoped multicast to communicate between the user interface and the media engine. On Windows machines without a network adapter a loopback adapter needs to be installed to enable locally scoped multicast to work.
The loopback adapter may be installed by clicking on:
Select any MS Loopback adapter and configure with an IP address, and do not configure DHCP, WINS, etc. Restart the machine and bingo!
Contributed by S.Varakliotis
It means that RAT is trying to use multicast but the network interface doesn't support it (note that the conference bus uses multicast even if you start RAT with a unicast address). There are two likely causes:
See previous question.
It may be that you have the windows firewall configured to block udp packets - Rat requires that udp packets can be transmitted and received on port 47000 on your local interface.
You can control the firewall on your machine by using the network properties GUI and going to the advanced tab.
You can also use the netsh command to control various network parameters, including the firewall. e.g. to list firewall status from a dos window:
You may also want to check you have a route for multicast installed on your machine. This should normally be there as default, but to check use:
You should see a line that says something like:
If you don't see it then you'll need to add one, like this:
The recorded file, foo.dat, contains raw data of the audio samples you have received during a session. At the time of writing RAT uses 16-bit 8-kHz mono linear PCM. We are moving towards variable sampling frequencies and stereo sound.
To replay the sample you will need an audio program that can play raw data, or you will need a program that can place a header on the raw data so that your audio program can read the data. We use Sun's audioconvert program, but recommend Sound eXchange for more general audio file conversion.
The current development version understands .wav and .au files. If you would be interested in adding other file types please email firstname.lastname@example.org
When you play an audio file the sound content of the audio file replaces your microphone input. The other participants hear the sound, but you do not as RAT does not loopback your input. NB use the command line flag -allow_loopback to enable loopback.
RAT uses raw 8-KHz 16-bit mono linear PCM internally. If the file contains data of this kind, but has a header, e.g. a .AU file, then it will interpret the header as audio data and play it.
To evaluate the loss mitigation functions of RAT it should be run against a packet reflector that can add jitter, loss, and packet duplication. The source code for the application we use for this can be found here.
The packet reflector application that we use for debugging may also be used as a packet forwarder between multiple unicast hosts. Documentation is included in the package. This is not incorporated in the application as this mode of operation is evil and should be discouraged unless used for really small groups.