IQinVision iq510 Reference Guide
Page 44 of 60
11. Two-way Audio Support
Specific IQinVision cameras are capable of receiving digital audio data via an Ethernet TCP connection and
playing it via the sound output device. The setup, data format and transport mechanism are documented in
the following sections.
playing it via the sound output device. The setup, data format and transport mechanism are documented in
the following sections.
11.1. Camera setup
To setup the camera to play audio data the output device must first be enabled by configuring the Audio
Output State, OID 1.9.6, to “enabled”. This turns on the audio output hardware.
Output State, OID 1.9.6, to “enabled”. This turns on the audio output hardware.
Next the Audio Output Gain, OID 1.9.4 can be configured. The default gain value is “medium” which is
adequate for most installations. Please check the actual audio levels in the installation environment to decide
how to configure this value.
adequate for most installations. Please check the actual audio levels in the installation environment to decide
how to configure this value.
11.2. Sending audio data
IQinVision cameras support playing mono, ulaw encoded, 16 bit PCM audio data sampled at 8 KHz.
Audio is sent to the camera by doing an HTTP POST to audiorx.cgi. Basic authentication credentials need to
be supplied. The default audio username is “audio” and the default password is “sound”. Note that the
username cannot be changed, but the administrator can change the audio password using OID 1.9.10.
be supplied. The default audio username is “audio” and the default password is “sound”. Note that the
username cannot be changed, but the administrator can change the audio password using OID 1.9.10.
The audio data must be delivered to the camera at a real-time rate of 8 KHz. There is a four second audio
buffer in the camera, so each individual HTTP POST should only contain several seconds of data. The host
sending the audio data must manage the transmission of the data so that the audio buffer does not underflow
or overflow.
buffer in the camera, so each individual HTTP POST should only contain several seconds of data. The host
sending the audio data must manage the transmission of the data so that the audio buffer does not underflow
or overflow.
A sample audio post could look like:
POST /audiorx.cgi HTTP/1.1
Authorization: Basic <audio:sound base64-encoded>
User-Agent: myclient
Host: mycamera
Authorization: Basic <audio:sound base64-encoded>
User-Agent: myclient
Host: mycamera
<ulaw-encoded 8khz mono data>
<end of connection>
If eight seconds of audio data needs to be transmitted the host should manage the data to attempt to keep the
audio buffer half full, i.e. with two seconds of audio data always waiting to be played. For example:
audio buffer half full, i.e. with two seconds of audio data always waiting to be played. For example:
Post two seconds of data from 0 to 2 seconds
Wait one second
Post two seconds of data from 2 to 4 seconds
Wait two seconds
Post two seconds of data from 4 to 6 seconds
Wait two seconds
Post two seconds of data from 6 to 8 seconds
Wait one second
Post two seconds of data from 2 to 4 seconds
Wait two seconds
Post two seconds of data from 4 to 6 seconds
Wait two seconds
Post two seconds of data from 6 to 8 seconds