TAPI 3.1 ITMediaRecord, ITMediaPlayback

TAPI 3.1 ITMediaRecord, ITMediaPlayback

Post by M Jeffcoa » Fri, 01 Feb 2002 14:56:56



The new TAPI 3.1 objects ITMediaPlayback and ITMediaRecord
work properly when you playback a WAV file using
ITMediaPlayback that has been recorded using
ITMediaRecord. However you can't use the ITMediaPlayback
object to playback a WAV file that has been created
elsewhere. Can you advise the WAV and AVI formats that
ITMediaRecord and ITMediaPlayback use, and if possible how
to define alternative formats?
 
 
 

TAPI 3.1 ITMediaRecord, ITMediaPlayback

Post by Semenov Vladimi » Sat, 02 Feb 2002 21:49:16


Why do not try to open WAV-file created via ITMediaRecord via any media
player (even MS) and read property there?
In TAPI 3.0 it works well only with 16bit 8kHz PCM.


Quote:> The new TAPI 3.1 objects ITMediaPlayback and ITMediaRecord
> work properly when you playback a WAV file using
> ITMediaPlayback that has been recorded using
> ITMediaRecord. However you can't use the ITMediaPlayback
> object to playback a WAV file that has been created
> elsewhere. Can you advise the WAV and AVI formats that
> ITMediaRecord and ITMediaPlayback use, and if possible how
> to define alternative formats?


 
 
 

TAPI 3.1 ITMediaRecord, ITMediaPlayback

Post by David Janson [M » Sun, 03 Feb 2002 12:02:35


Hey Mark,

*ov  is correct.  8KHz 16 bit mono PCM is the standard that all of our TSPs (Unimodem and H.323 use).  The reason
is because this is *the* standard of the telephony industry.   G.711, modems and in fact, the telephony backbone all
basically use this.  Sure, other formats get used also, but this one is the common ground and the only one Microsofts
TSP/MSPs use.

Note that "on the wire" this is really 8KHz, 16 bit mono PCM ULaw.  This means that it is a 16 bit sampling, but with
an 8 bit logarithmic encoding.  So the math works out to 64KBit of data per second.  Which explains why it is so common
(64Kbit is handy), but at the API level, you need to stick to normal 16 bit PCM.

The ITMediaPlayback and ITMediaRecord don't have any limitations at all wrt data format, but you will have to worry
about the format that the MSP you are using has.  Since all the TSP/MSPs you are using are probably Microsofts, you
need to stick with the above format.

If you *really* need to know what formats are supported programmatically, you can always select the media streaming
terminal onto the call first and use its ITAMMediaFormat interface.

David Janson (djanson)
Windows Developers Support
This posting is provided "AS IS" with no warranties, and confers no rights.

 
 
 

TAPI 3.1 ITMediaRecord, ITMediaPlayback

Post by Michael Dun » Sun, 10 Feb 2002 07:06:29



> Hey Mark,

> *ov  is correct.  8KHz 16 bit mono PCM is the standard that all of our TSPs (Unimodem and H.323 use).  The reason
> is because this is *the* standard of the telephony industry.   G.711, modems and in fact, the telephony backbone all
> basically use this.  Sure, other formats get used also, but this one is the common ground and the only one Microsofts
> TSP/MSPs use.

> Note that "on the wire" this is really 8KHz, 16 bit mono PCM ULaw.  This means that it is a 16 bit sampling, but with
> an 8 bit logarithmic encoding.  So the math works out to 64KBit of data per second.  Which explains why it is so common
> (64Kbit is handy), but at the API level, you need to stick to normal 16 bit PCM.

David, I was always under the impression that internally the telephone
system used either 7 or 8 bit encoding at 8000 samples per second, in
PCM.  At least, thats what Tanenbaum says in my copy of Computer
Networks 3rd Edition.  I admit I don't understand all of the math, but
is my information out of date or is there more going on than I know about?

8KHz * 8 bit = 64 Kbit/sec

--
Michael Dunn (Microsoft MVP) is a TAPI Developer and Tester
TAPI web page:  http://www.veryComputer.com/
TAPI discussions belong in the newsgroup, and not in private email.
"Time is just an illusion, lunchtime doubly so."

 
 
 

TAPI 3.1 ITMediaRecord, ITMediaPlayback

Post by David Janson [M » Wed, 13 Feb 2002 12:40:46


Hey Michael,

Good to talk to you again :)

| > Note that "on the wire" this is really 8KHz, 16 bit mono PCM ULaw.  This means that it is a 16 bit sampling, but
with
| > an 8 bit logarithmic encoding.  So the math works out to 64KBit of data per second.  Which explains why it is so
common
| > (64Kbit is handy), but at the API level, you need to stick to normal 16 bit PCM.
|
| David, I was always under the impression that internally the telephone
| system used either 7 or 8 bit encoding at 8000 samples per second, in
| PCM.  At least, thats what Tanenbaum says in my copy of Computer
| Networks 3rd Edition.  I admit I don't understand all of the math, but
| is my information out of date or is there more going on than I know about?
|
| 8KHz * 8 bit = 64 Kbit/sec

Exactly, it has to use an 8bit encoding.  However, the standard encoding is a logarithmic encoding, not a linear one.  
This allows the 8 bits to represent a fairly wide frequency range, but to provide a higher amount of discertion in the
frequencies where we are good at.

At the API level, we only support "8KHz, 16 bit mono PCM" where the 16 bit PCM means linear coding since PCM has been
on the PC long before telephony reached it.  But "8KHz, 8 bit mono Mu-law PCM" is G.711 and what actually hits the
wire.  

http://www.course.molina.com.br/Topics/127.htm
http://www.rcsavt.bee.qut.edu.au/people/jwilliams/dspfaq/2.htm
 -> Q2.7: What is mu-law encoding? Where can I get source for it?
http://www.tml.hut.fi/Opinnot/Tik-110.551/1997/seminar_paper.html

Note that I do not work for a phone company (and never have), so the above is all "As per my understanding".  The ISDN
standard specifies G.711 for media (as well as plenty of other standards) and I know that ISDN came out of what phone
companies already used on their backend.  But I really can't say exactly what phone companies actually use.  

David Janson
Windows Developers Support
This posting is provided "AS IS" with no warranties, and confers no rights.