Browse Prior Art Database

Real Time Audio Conferencing Under Windows 3.1

IP.com Disclosure Number: IPCOM000114391D
Original Publication Date: 1994-Dec-01
Included in the Prior Art Database: 2005-Mar-28
Document File: 4 page(s) / 181K

Publishing Venue

IBM

Related People

Homewood, B: AUTHOR [+3]

Abstract

In order to conduct real time audio conferences between two or more PC's connected by a shared packet switched network where one or all of the PC's is running Windows* 3.1, the following problems have to be addressed: 1. Windows 3.1 is a non-preempting operating system environment which requires the participating applications to collaborate to the extent that each will yield control at "convenient" intervals to allow other applications to gain control via the Windows messaging process.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 29% of the total text.

Real Time Audio Conferencing Under Windows 3.1

      In order to conduct real time audio conferences between two or
more PC's connected by a shared packet switched network where one or
all of the PC's is running Windows* 3.1, the following problems have
to be addressed:
  1.  Windows 3.1 is a non-preempting operating system environment
       which requires the participating applications to collaborate
to
       the extent that each will yield control at "convenient"
intervals
       to allow other applications to gain control via the Windows
       messaging process.  This environment does not look kindly on
an
       application that is trying to perform real time audio transfer
       between a voice card and the network because once the
application
       relinquishes control to Windows there is no guarantee that it
       will regain control within the necessary time interval to
allow
       the continuous transfer of audio between the various buffers
to
       be maintained.  This time delay can be anything from a
       millisecond to 20 seconds or more depending on Windows
loading;
       to set this in context, the basic rate to support a 64
Kbits/sec
       audio stream using a buffer size of say 512 bytes is 64 msecs.
  2.  The only way of getting around the preemption problem is to
       become interrupt driven and do the audio transfers within a
       suitable interrupt.  However this approach must be used with
       great care as the standard Windows 3.1 library functions are
not
       guaranteed to be reentrant and can not therefore be used in
       interrupt code.  This places severe restrictions on what can
be
       done in an interrupt.

      These problems are successfully addressed in the arrangement
described below by using a combination of interrupt based processing
and the DMA process which transfers audio packets between the host
application and the voice card.  This is a general purpose solution
applicable to all multimedia cards which support DMA, and the NetBios
and Novell network protocols.  The following describes the three key
areas:
  1.  The multiMedia Card DMA
  2.  The multiMedia MCI Timer Callback
  3.  The NetBios Receive Postback

      MultiMedia Card DMA - The Figure shows the Record and Play
paths for a typical duplex multimedia card such as MWave.  The
multimedia card interfaces to the application via a DMA process for
Record and Play.  The DMA rate depends on the card and the audio
stream rate.  For MWave, the audio stream runs at the standard audio
rate of 8 KHz, i.e., 8 bytes/msec, and the DMA transfers 64 bytes
every 8 msecs.

      On the Record side, audio from the voice card is addressed by
the DMA directly into the network send buffers at the index DMA_TO
which is then incremented to indicate the index for the next DMA.
The DMA_TO index act...