Re: New speech sample code issues

rporter · ‎10-28-2005

I've run into a few compilation/link issues that I figured I'd share. I was trying to drop the new codec code (not application items or make files) into my work environment. I'm still using the old IPP v4 library--I wanted to limit the amount of simultaneous change. Previously, I was running with my own USC wrapper around some of the codec API (e.g. g728, gsmfr), so the USC wrappers will replace mine.

Most of these compiler complaints can be eliminated by adjusting warnings, but I don't plan to do that since they can be fixed in the code (and must be in my code base). I'm using i386-redhat-* version 3.3.2 for compilation.

NOTE: the line numbers below are not exact, since some warnings were not realized until after I added lines to correct other warnings that my compiler was choking on.

I will post more (on this thread) after I run some tests, especially if I run into runtime errors or functionality problems. I'm almost at the point of being able to run my tests, but I didn't want to delay waiting for test results.

FYI - I changed the name of a couple files for consistency (usc729fp.c=uscg729fp.c; gain_util.c=gaingsmamr.c)

Enjoy,
Rick

==============================

1. G711 tied to G729? why? silence detection? so you can detect silence and suppress frames?

2. Comments within comments: "//*********/" (usc.h, usc_base.h)

3. Issues common to most of usc*.c:
a) Function prototypes expect "void *", and declarations have non-void (e.g. in uscg711.c, declare and try to assign GetInfoA(USC_Handle, USC_CodecInfo *) to (*GetInfo)(USC_Handle, void *)). I added a thin wrapper around each and initialize the structures with those (e.g. _GetInfoA(USC_Handle h, void *i) { return GetInfoA(h,i); }).

b) params and pcmType are defined and never used

c) function structure (e.g. USC_G722_Fxns) defined as extern (remove USCFUN)

4. Unused variables:
./decg711.c:36: warning: `tab1' defined but not used
./decg711.c:40: warning: `tab2' defined but not used
./uscg722sb.c:179: warning: unused variable `mode'
./uscg722sb.c:211: warning: unused variable `mode'
./owng723.c:357: warning: `GenPostFiltTable' defined but not used
./owng723.c:455: warning: `GetAverScaleTable' defined but not used
./utilamrwb.c:491: warning: unused variable `f3'

5. Unitialized variables
./encamrwb.c:235: warning: `valStabFac' might be used uninitialized in this function
./decamrwb.c:178: warning: `valPastPitchGain' might be used uninitialized in this function
./encg729fp.c:314: warning: `pZero' might be used uninitialized in this function
./encg729fp.c:315: warning: `pError' might be used uninitialized in this function
./encg729fp.c:316: warning: `pSynth' might be used uninitialized in this function
./encg729fp.c:974: warning: `pError' might be used uninitialized in this function
./encg729fp.c:975: warning: `pSynth' might be used uninitialized in this function
./decg729fp.c:223: warning: `badPitch' might be used uninitialized in this function
./decg729fp.c:228: warning: `highStatIndicator' might be used uninitialized in this function
./owng729fp.c:1101: warning: `pTable' might be used uninitialized in this function
Set above values to zero/NULL during or right after declaration.

6. Missing return
./uscg728.c:400: warning: statement with no effect

7. Missing typecast
./decamrwb.c:744: warning: passing arg 1 of `amrExtractBits' from incompatible pointer type

8. Missing enum in switch:
./encg729fp.c:93: warning: enumeration value `G729I_CODEC' not handled in switch
./encg729fp.c:814: warning: enumeration value `G729I_CODEC' not handled in switch
In first case, return -1. In second case, just added a "default" that does nothing; should we error out?

9. Brace/parentheses issues:
./owng729fp.c:888: warning: suggest parentheses around && within ||
Open paren after frame>128, extending to end of conditional--not sure if this is right...
./uscgsmfr.c:613: warning: missing braces around initializer
Added braces around the arrays.

10. Undefined (but unused) functions
./uscgsmfr.c:70: warning: `ownTestPCMFrameHoming' declared `static' but never defined
./uscgsmfr.c:71: warning: `ownTestBitstreamFrameHoming' declared `static' but never defined

11. Bad comparison/data type
./gain_util.c:342: warning: comparison is always false due to limited range of data type
Not sure what to do--eliminated test to allow compilation

12. New library required (acceptable excuse):
./encg722sb.c - missing lots of ipp function prototypes, plus other compiler complaints
./owng729fp.c:764: undefined reference to `ippsSignChangeRate_32f

Message Edited by rporter@covergence.com on 10-28-2005 02:07 PM

rporter · ‎10-31-2005

These results are from basic unit tests, and were NOT tested with live traffic (yet).

Most sample code modifications were made were to get the code to compile in my environment (as described earlier in this thread). The only additional change was to add "NO_SCRATCH_MEM..." to scratchmem.h, since my runtime environment does not like the scratch memory stuff (caused g711/g729, and g723 seg faults).

The unit test involves inserting two frames of PCM tone at a given frequency, encode them, decode them, and test the frequency of the second frame. Two frames are used because some of the codecs inject lag/delay.

Bottom line: we're going to continue to use my original work until I can resolve the issues with the most common codes (G711 and G729).

I'm interested in hear other people's experience...

Regards,

Rick

G711 (replaces mine) - fails - get back all zero data when tone is inserted.

G722.1 (replaces mine) - pass; have not tried siren

G723 (replaces mine) - pass

G726 (new) - needs some massaging to fit into my framework--frame sizes are too small for frequency checking.

G728 (replaces mine)- pass

G729/G729A - appears to be a slight frequency problem (too high) that was not previously exhibited.

GSM-FR (replaces mine) - fails: output appears to be half the frequency

GSM-AMR - pass

AMR-WB - pass

napoleon9th · ‎11-02-2005

Hi, Rick. Have you gotten around to testing the samples "with live traffic" yet? ;)

I think a lot of the issues you provided earlier are quite serious and should have generated SOME kind of response from the coders of those samples... Thank you for your dedication towards improving the code samples.

PS I forgot to add that I've had quite a bit of trouble due to the fact that there are no USC wrapper header files for G711 and G729fp. They were so easy to do, if only i knew that they needed to be done! :(

Message Edited by Napoleon9th on 11-02-2005 08:21 PM

rporter · ‎11-04-2005

Sorry to take so long to answer your simple question; other things have become higher priority for me... The short answer is, "No."

I ran some quick tests against previously recorded calls. Unfortunately, I don't currently have the resources (time being the most important) to produce calls in some of the codecs. And, my environment requires some work. In my wideband codec implemenation(s), I was doing sample rate conversion to 8kHz inside my USC functions--I need to change that so I don't detect gaps and/or discard frames.

The whole G711 dependence on G729 raises questions to me about the intent of the sample code. Is it supposed to process single RTP frames? Or, it is supposed to process codec dependent chunks (e.g. code words, vectors, samples). Right now, I'd say the library is not completely consistent as I outline below.

The G711 packet time is negotiable--although typically 20 msec or 160 samples, some phones/configurations negotiate to other sizes (e.g. 30 msec or 240 samples). The important G711 relationship is the decoded data is twice the size of the encoded data; it should not constrain the G711 packet size to a typical RTP frame size. With a dependence on G729 (fixed 20 msec frame), I'm not sure what the codec will do with a 30 msec RTP frame.

The G726 code seems (at a quick glance to me) to deal with single codewords, of which there are 2-5 in an RTP frame. A single decoded codeword does not produce enough PCM data for me to run my frequency test.

I'm not sure (have not looked at the G729 code) about support for multiple G729 frames in a single RTP frame. Per spec, a single RTP frame of G729 can support zero or more "regular" frames and optionally one silence frame at the end.

Well, back to other work.

Enjoy,
Rick

Igor_B_Intel1 · ‎11-09-2005

Hi,

Let me clarifybuilding of RTP packets for G711 and G726 coders.

Neither G711 nor G711 don't produce full RTP packet.

Our inplementation of G711 codec conforms to ITU G.711/G.711.I/G.711.II standards and able to detect VAD, do PLC. It uses VAD module from G729 codecs. Thats why it requests VAD functions from G729. So the length of input frame is 10 ms. RTP stream of G711 codec usually doesn't contain CN packets. So if you would like to use G711 codec for it, you should turn off VAD (pInfo.params.modes.vad = 0) andconcatenateframes in the lenght of 10ms. So for 20 ms packet - 2 frames, for 30 ms - 3 frames. On the other hand you should divide RTP packet by 10 ms frames. I succsessfully tested this mechanism withdifferent soft phones.

For the G726 codec input frame length is 1ms. It is minimal lenght to composepacked bitsteam. So as in G711 you shold concatenate coded frames in the length of 1ms to build full RTP packet. In IPP5.0 there is new function in USC interface - SetFrameSize(). For the G726 codec you can change coded frame length.

G729 also operate with single frame in the length of 10 ms. You should devide RTP packet as it written in RFC3551.

Igor S. Belyakov

Vyacheslav_Baranniko · ‎11-09-2005

The latest IPP 5.0 might solve some of this issues. Now all speech-coding specs enabled in IPP are supported in one USC sample which encodes WAV file and produces output in Intel in-homeUSCcompressed fileformat.

Vyacheslav

rporter · ‎02-09-2006

Hi Igor,

I finally got around to looking at G726, again.

Let me confess, that I have slightly hacked up the IPPv5 USC code to fit into the IPPv4--not much hacking required... Based on your guidance (thank you), I actually used core of the "CalsOutStreamSize()" to set the framesize based on how many bytes I receive on each encode/decode. I can pass my unit tests (simple frequency tests), and I work with-16 and -32bitrates.

However, the -24 and -40 bitrates produce nothing but static... I want to do some further testing with another client that does G726 to see whether or not it is compatible with another implementation. Has anyone else used IPPv4 to decode "live" G726 traffic? If so, which implementations? I've tested with Sipura (-16, -24, -32, and -40) and Snom (-32 only) phones. I hope to be able to test with a new X-ten softphone (eyebeam).

Is this what http://softwareforums.intel.com/ids/board/message?board.id=IPP&message.id=3046refers to? I'm guessing it is. Why does it work for -16 and -32? Byte ordering is the same for AAL2 and RTP?

Thanks,

Rick

Message Edited by rporter@covergence.com on 02-09-2006 03:37 PM

rporter · ‎07-19-2006

Also posted in http://softwareforums.intel.com/en-us/forums/showthread.php?t=49922#32089

I had gone back thru recent IPPv5.1 sample code and compared to RTP bit-packing defined in RFC-3551--everything in the sample code looked to follow the spec.

I recently saw a note regarding the G726 bit-packing in the Asterisk web site (http://www.asterisk.org/doxygen/Config_sip.html). In the Asterisk config it says that some phones use the AAL2 packing instead of the RTP packing. I'm not sure if there is a good catalog of which phones do which flavor of G726 bit-packing. It may be a good idea to provide both in the sample code, please. :)

stas · ‎04-02-2008

Igor, can you please comment if the resulting IPP G.729 bit stream needs additional conversion to big endian as rfc3551 demands?

I have the G.729 streamer that strips the header from each packet and sends 1 or 2 frames per RTP packet. I also wrote receiver side and everything works but now I need to send my stream to the other receivers (AudioCodes gateway) and want to be sure that the bitstream will be accepted.

Also, do you know if there is a VS2005 workspace for the IPP5.3 speech-codecs samples?

Igor_B_Intel1 · ‎04-04-2008

Hi,

Noreasons to do additional bitstream convertion for G.729 codec. You need just concatenate active 10 ms frames to form RTP packet. The default RTP packet size for G.729 is 20 ms (IPP G.729 codec operates with 10 ms frames).

On the reciever side, bitrate and number of frames in the packet can be calculated through RTP payload length.

Unfortunally, we don't provide solution and project files for IPP speech samples.Pleasetake a look into the provided makefile, to set up correct defines in your project file or let me know what problems do you have.

Igor S. Belyakov