User's Manual

40 Voice API Programming Guide — June 2005
Application Development Guidelines
With some applications, this may cause slow device-initialization performance. You can avoid this
problem in one of several ways, depending on the type of application:
• In multithreaded applications, you can reorganize the way the application opens and then
configures devices. The recommendation is to do as many xx_open( ) functions as possible
(grouping the devices) in one thread arranging them in a loop before proceeding with the next
function. For example, you would have one loop through the grouping of devices do all the
xx_open( ) functions first, and then start a second loop through the devices to configure them,
instead of doing one single loop where an xx_open( ) is immediately followed by other API
functions on the same device. With this method, by the time all xx_open( ) commands are
completed, the first channel will be initialized, so you won't experience problems.
This change is not necessary for all applications, but if you experience poor initialization
performance, you can gain back speed by using this hint.
• Develop your application using a single thread per span or a single thread per board. This way,
device initialization can still be done in a loop, and by the time the subsequent function is
called on the first device, initialization on that device has completed.
6.4.6 TDM Bus Time Slot Considerations
In a configuration where a network interface device listens to the same TDM bus time slot device
as a local, on board voice device (or other media device such as fax, IP, conferencing, and
continuous speech processing), the sharing of time slot (SOT) algorithm applies. This algorithm
imposes limitations on the order and sequence of “listens” and “unlistens” between network and
media devices. This section gives general guidelines. For details on application development rules
and guidelines regarding SOT, see the technical note posted on the Intel telecom support web site:
http://resource.intel.com/telecom/support/tnotes/tnbyos/2000/tn043.htm.
Note: These considerations apply to DMV, DM/V-A, DM/IP, and DM/VF boards. They do not apply to
DM/V-B, DI series, and DMV160LP boards.
• If you call a listen function (dt_listen( ) or gc_Listen( )) on a network interface device to
listen to an external TDM bus time slot device, followed by one or more listen functions
(dx_listen( ), ec_listen( ), fx_listen( ), or other related functions), to a local, on-board voice
device in order to listen to the same external TDM bus time slot device, then you must break
(unlisten) the TDM bus voice connection(s) first, using an unlisten function (dx_unlisten( ),
ec_unlisten( ), fx_unlisten( ), etc.), prior to breaking the local network interface connection
(dt_unlisten( ) or gc_UnListen( )). Failure to do so will cause the latter call or subsequent
voice calls to fail. This scenario can arise during recording (or transaction recording) of an
external source, during a two-party tromboning (call bridging) connection.
• If more than one local, on-board network interface device is listening to the same external
TDM bus time slot device, the network interface devices must undo the TDM bus connections
(unlisten) in such a way that the first network interface to listen to the TDM bus time slot
device is the last one to unlisten. This scenario can arise during broadcasting of an external
source to several local network interface channels.
These considerations can be avoided by routing media devices before network interface devices,
which forces all time slots to be routed externally; however, density limitations for transaction
record and CSP with external reference signals apply. For more information on how to program
using external reference signals, see the technical notes posted on the Intel telecom support web
site. For transaction record, see