This project, developed with C, allows us to establish a point-to-point audio conference between two systems (called conf entities). In this implementation, we use RTP over UDP.
The application could be started in two ways: In first mode, where the process waits indefinitely for the other conf entity ("second") to send data. In second mode, conf initiates communication by sending immediately an audio packet to "first".
gcc -o exec_conf conf.c confArgs.c configureSndcard.c circularBuffer.c
exec_conf first [-pLOCAL_RTP_PORT] [-vVOL] [-c] [-kACCUMULATED_TIME] [-mMULTICAST_ADDR]
exec_conf second addressOfFirst [-pLOCAL_RTP_PORT] [-vVOL] [-c] [-lPACKET_DURATION] [-kACCUMULATED_TIME] [-yPAYLOAD]
This parameter exists for both first and second. With –c (verbose mode), a dot (“.”) shall be printed each time a packet is sent and a “+” each time a packet is inserted in the circular buffer to be played. Besides (each of these cases is explained below in the specification),
- every time packet loss is detected while checking the RTP sequence number, an ‘s’ (for sequence) is printed. If packets are played-out due to this event, an ‘x’ is printed
- every time the select timer expires, a ‘t’ (for timer) is printed
- every time a packet arrives after the timer (programmed for the case this packet would not arrive) expires, a ‘d’ (for delayed) is printed.
Examples that may occur are the following (note that ‘.’ are not relevant here):
- Packet 11 arrives, 12 is lost, and the timer for 12 expires before 13 arrives: ‘+.t+’. Each t displayed indicates a packet has been generated to substitute the packet expected but not received
- Packet 11 arrives, 12 is lost, 14 arrives before expiring 12’s timer: ‘+..sx.x+’. s indicates there are missing packets before number 14 was received; x stands for packets number 12, other x for packet 13, then + indicates that 14 is appropriately played
- Packet 11 arrives, the timer for 12 expires, then 12 arrives, 13 arrives on time: ‘+.t.d+’ (d is generated by 12 arriving when conf has already ‘created’ a packet with sequence 12)
When the execution in verbose mode finishes, it must show the theoretical time required to playout the content, as well as the actual time required to perform the playout: time elapsed since the playout of the first packet to the playout of the last one (or a good approximation possible to that time); the comparison between the theoretical and actual playout times can be used to evaluate the quality of an implementation. -c can be independently activated in first or second.
This parameter exists for both first and second. The ports to use can be configured using –p, with a default value of 5004. Port numbers must be the same for both first and second modes.
This parameter exists for both first and second. It allows setting the local volume for both recording and playout, which can have different values at first and at second.
This parameter exists for both first and second. –kACCUMULATED_TIME is used to indicate that ACCUMULATED_TIME milliseconds of data must be stored in the circular buffer before starting the playout. This time is internally rounded down by conf to a multiple of the actual playout time of a packet, so that an integer number of packets are buffered. For example, if –k90 is specified, and a packet has an actual duration of 16.00 ms, the accumulated data will correspond to 80 ms (5 16-ms packets). 100 ms is the default value for this parameter. Note that when allocating memory, the circular buffer must be sized to store 200 milliseconds in addition to the buffering time specified in this command, to cope with possible delay variations caused by the network. For example, for –k50, the buffer will be sized to be able to store the data corresponding to 250 ms of playout (rounded down to the multiple of the actual playout time of a packet). -k may have different values for first and second.
The application running as first must be able to use a multicast address to receive the data, as an alternative to receiving it from its unicast address. This is achieved by means of the –mMulticastAddr optional parameter for first mode (for example, -m226.0.0.100), and the addressOfFirst for second mode configured to the same multicast address. In the following example, first listens at multicast address 226.0.0.100 (using –m), which is the same address to which second sends its data.
Host1: ~> ./conf first -m 226.0.0.100
Host2: ~> ./conf second 226.0.0.100
Remember, that the range of valid multicast addresses is 224.0.0.0 to 239.255.255.255 (we recommend you to use an address in the range 226.0.x.x). You can verify if the association is correct by executing a ping to the address. -m can only be used with first. If –m is not used, then second is started with the IP unicast address of first, as in the following example.
Host1: ~> ./conf first
Host2: ~> ./conf second 168.117.144.7
This parameter is only available with second. The option –l allows specifying the duration in milliseconds of the play-out of the data being carried by a packet. By default, this value is 20 ms. The value of –l is just a hint, since the actual length used by first for the audio blocks will be rounded down to the immediately inferior power of 2 number of bytes, to comply with the fragment size restrictions imposed by the soundcard operation.first learns the audio block length when it receives the first audio packet from second, by processing the byte length of the UDP packet received (recvfrom system call).
This parameter is only available with second. Two values are allowed: -y100 indicates L8 format, and –y11 indicates L16 format. The default value is L8. L8 refers to a linear coding of 8 bit per sample, single channel, sampling frequency of 8000 Hz; L16 to linear coding of 16 bit per sample, single channel at 44100 Hz. They are partially defined in RTP profiles for audio and video (RFC3551), sections 4.5.10, 4.5.11 y 6. Values of 100 and 11 are the payload type values to be carried in the corresponding RTP packet. In order to configure the format of soundcard playing and recording, by means of the SNDCTL_DSP_SETFMT command with the ioctl call), you should use format value 8 for L8, and format value 16 for L16. (Note that the format value refers to the value used to configure the soundcard). first learns the payload, and therefore the audio format to be used in the communication, when it receives the first audio packet from second, by reading it from the RTP header.
The main logic of this code can be found in the file "conf.c"