IPP v5.1 and GSM-FR

rporter · ‎05-08-2006

I found that using the new IPP v5.1 library causes a problem with older IPP GSM-FR sample code.

I'm attempting to upgrade my library from v4.1 (4.1.12 Build 51, name libippcore.so) to 5.1 (5.1.80 Build 182, name libippcore.so.5.1). I have some unit tests that encode a square wave, and then decode it. I check the output linear data to insure that it contains roughly the same number of zero-crossings. I expect 18 zero-crossings, and get 21! As a sanity check, I ran some previously captured voice samples and it does sound bad (tinny) with the new library. Has anyone else seen this?

All my other codecs seem to pass my unit tests.

Vyacheslav_Baranniko · ‎05-19-2006

Could you please clarify on following?

What is an environment you are working in? Linux version (I guess it is Linux), what Intel CPU.

Also, to narrow down the problem, could you perform some experiment like, for example, try IPP PX versions, i.e. ippspx.lib, ippscpx.lib (C-codec library). This can be done by using ippStaticInitCpu(ippCpuUnknown) to switch from optimized code to C-code (PX). Probably, with IPP PX GSMFR works well.

If not, can you please attach the problematic files in order we can reproduce the issue?

Thanks

Slava

rporter · ‎05-22-2006

Hi Slava,

Thanks for the response. We're running 32-bit Linux on dual Xeons:

Vendor: GenuineIntel
Family: 15
Model: 4
Model name: Intel Xeon CPU 3.20GHz
Stepping: 1
CPU speed: 3193.630 (3193 MHz)
Cache size: 1024 KB (1.00M)

I set the IPP library CPU type to use the non-optimized version, as you suggested. I wasn't sure whether the ippGetCpuType() reads CPU info or IPP variables, but it points at the CPU type. Is there a good way to verify the CPU type the IPP library is using?

codec[notice]: IPP Library version: 5.1.80 Build 182, name libippcore.so.5.1
codec[notice]: IPP processor: 32

With the above setting, I get the same results in my unit tests. I do not use a file for my unit tests. Once we can pass the unit tests, I can try some real voice--I expect that it will work since the voice seems to exhibit the same frequency problem (sounds tinny).

Below, I've included the results of my unit test. I generate 2 frames (160-samples, 16-bit samples) of a square wave, encode them, decode them, then check the number of zero-crossings in the second frame. I check the second frame since some codecs introduce a delay.

Again, all I have replaced is the IPP library (not the sample code).

Thanks,
Rick

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

codec[info]: Test: Tone Init
codec[debug]: _codec_test_tone: freq=440, volume=50
codec[info]: Test: Tone Coding
codec[debug]: _codec_test_tone: 320 byte tone frame: 9x-50*, 9x50*, 9x-50*, 9x50*, 9x-50*, 9x50*, 9x-50*, 9x50*, 9x-50*, 9x50*, 9x-50*, 9x50*, 9x-50*, 9x50*, 9x-50*, 9x50*, 9x-50*, 7x50
codec[debug]: _codec_test_linear_num_zero_crossings: detected 17 crossings in 160 samples (2-bytes) at 0x40998440
codec[debug]: _codec_test_linear_num_zero_crossings: detected 17 crossings in 160 samples (2-bytes) at 0x40998440
codec[debug]: GSMFR_Encode: got vad=-1242508888, frametype=1
codec[debug]: Codec_linear_in: inserted frame at 0x409980c0 with data 33@0x40998100 with ts=1000
codec[debug]: Codec_encoded_out: requested=1000, copying frame: 33@0x40998100, ts 1000
codec[debug]: Codec_encoded_in: inserted frame at 0x409a0620 with data 320@0x4099b7a0 with ts=1000
codec[debug]: _codec_test_tone: 33 byte encoded tone frame:
4099f9a0 d7 df a2 e1 62 77 80 96 - b4 81 ad 20 6d c0 ad 23 ....bw..... m..#
4099f9b0 71 b9 1c 91 80 36 eb 8d - ba a3 d9 80 39 1c 8e 45 q....6......9..E
4099f9c0 23 #
codec[debug]: _codec_test_tone: 320 byte tone frame: 2x50*, 9x-50*, 9x50*, 9x-50*, 9x50*, 9x-50*, 9x50*, 9x-50*, 9x50*, 9x-50*, 9x50*, 9x-50*, 9x50*, 9x-50*, 9x50*, 9x-50*, 9x50*, 9x-50*, 5x50
codec[debug]: _codec_test_linear_num_zero_crossings: detected 18 crossings in 160 samples (2-bytes) at 0x40998580
codec[debug]: _codec_test_linear_num_zero_crossings: detected 18 crossings in 160 samples (2-bytes) at 0x40998580
codec[debug]: GSMFR_Encode: got vad=-1242508888, frametype=1
codec[debug]: Codec_linear_in: inserted frame at 0x409a0660 with data 33@0x409980c0 with ts=2000
codec[debug]: Codec_encoded_out: requested=2000, copying frame: 33@0x409980c0 , ts 2000
codec[debug]: Codec_encoded_in: inserted frame at 0x409a0660 with data 320@0x409a0840 with ts=2000
codec[debug]: _codec_test_tone: 33 byte encoded tone frame:
4099f9a0 d7 df a2 e1 62 91 e0 37 - 24 71 c8 e3 6d e0 47 1c ....b..7$q..m.G.
4099f9b0 91 c8 e2 b5 c0 39 24 8e - 47 1b 6d a0 39 1d 6d b8 .....9$.G.m.9.m.
4099f9c0 e3 .
codec[info]: Test: Tone Check
codec[info]: Codec_linear_out: requested 2000, removing old frame: 320@0x4099b7a0, ts 1000
codec[debug]: Codec_linear_out: requested=2000, copying frame: 320@0x409a0840, ts 2000
codec[debug]: _codec_test_tone: 320 byte decoded tone frame: 1x-48, 3x-8, 1x-104, 2x-88, 1x-80, 1x-64, 1x-48, 1x-104, 1x-72, 1x-56*, 1x48*, 1x0*, 1x16, 1x24, 1x112, 1x96, 1x80, 2x72*, 1x-40, 1x-24, 1x-48, 1x-32, 1x-128, 1x-112, 1x-104, 1x-80, 1x-64, 1x-56, 1x-80, 1x-72, 1x-64*, 1x32, 3x40, 1x32*, 1x-72, 1x-56, 1x-72, 1x-56, 2x-40, 1x-80, 1x-72, 1x-56*, 3x48, 1x40, 2x32, 1x56, 1x40, 1x24*, 1x-64, 2x-56, 1x-40, 1x-32, 1x-16, 1x-88, 1x-64, 1x-48*, 1x64, 1x16, 1x24, 1x48, 1x136, 1x120, 1x88, 2x80*, 1x-24, 1x-16, 1x-32, 1x-4
409986e0 d0 ff f8 ff f8 ff f8 ff - 98 ff a8 ff a8 ff b0 ff ................
409986f0 c0 ff d0 ff 98 ff b8 ff - c8 ff 30 00 00 00 10 00 ..........0.....
40998700 18 00 70 00 60 00 50 00 - 48 00 48 00 d8 ff e8 ff ..p.`.P.H.H.....
40998710 d0 ff e0 ff 80 ff 90 ff - 98 ff b0 ff c0 ff c8 ff ................
40998720 b0 ff b8 ff c0 ff 20 00 - 28 00 28 00 28 00 20 00 ...... .(.(.(. .
40998730 b8 ff c8 ff b8 ff c8 ff - d8 ff d8 ff b0 ff b8 ff ................
40998740 c8 ff 30 00 30 00 30 00 - 28 00 20 00 20 00 38 00 ..0.0.0.(. . .8.
40998750 28 00 18 00 c0 ff c8 ff - c8 ff d8 ff e0 ff f0 ff (...............
40998760 a8 ff c0 ff d0 ff 40 00 - 10 00 18 00 30 00 88 00 ......@.....0...
40998770 78 00 58 00 50 00 50 00 - e8 ff f0 ff e0 ff d0 ff x.X.P.P.........
40998780 e8 ff 40 00 30 00 20 00 - 30 00 38 00 d8 ff e8 ff ..@.0. .0.8.....
40998790 e0 ff d0 ff 78 ff 90 ff - 98 ff b8 ff d0 ff d8 ff ....x...........
409987a0 b0 ff c0 ff c8 ff 30 00 - 28 00 28 00 20 00 20 00 ......0.(.(. . .
409987b0 20 00 38 00 30 00 20 00 - c0 ff c8 ff c0 ff d0 ff .8.0. .........
409987c0 e8 ff f0 ff b0 ff c0 ff - c8 ff 38 00 08 00 10 00 ..........8.....
409987d0 18 00 08 00 b0 ff b8 ff - b8 ff c8 ff e0 ff f8 ff ................
409987e0 b0 ff c0 ff c0 ff 30 00 - 00 00 20 00 30 00 90 00 ......0... .0...
409987f0 68 00 48 00 48 00 48 00 - e0 ff f0 ff d8 ff d0 ff h.H.H.H.........
40998800 70 ff 88 ff 90 ff b0 ff - d0 ff d8 ff b8 ff c0 ff p...............
40998810 c8 ff 30 00 30 00 28 00 - 28 00 20 00 20 00 38 00 ..0.0.(.(. . .8.
codec[debug]: _codec_test_linear_num_zero_crossings: detected 21 crossings in 160 samples (2-bytes) at 0x409986e0
100% 1/1 codec_gsm_fr_tone
FAILURE: codec_gsm_fr_tone
../../codec/codec_test.cpp:609: error: test codec_gsm_fr_tone failed
msg: Tone Check
expected:
<= freq=440 (0x000001b8)
actual:
_codec_test_linear_freq_lower_bound(Codec_frame_get_data(oFrame), Codec_frame_get_bytes(oFrame)/bytesPerSamp, 1)= 500 (0x000001f4)

total tests: 1
failures: 1
errors: 0
Failure! Not all tests passed!

Vyacheslav_Baranniko · ‎05-31-2006

Hi

You can use IppLibraryVersion function to know whatversion of each library your applicationis linked to

list: s, sc, i, ac, vc and many other

for example, ippscLibraryVersion() returns structure where you can findlibrary name and versions: example of code:

IppLibraryVersion *ver;

ver= ippscGetLibVersion();

fprintf(f_log,"The Intel IPP library used: %d.%d.%d Build %d, name %s ",

ver->major,ver->minor,ver->majorBuild,ver->build,ver->Name);

the output expected for example

The Intel IPP library used: 5.1.96 Build 196, name ippscw7.lib

so w7 means you run Pentium-4 ippsc library.

I think you first should try ippscpx.lib (not optimized).

To switch from defaulty chosen the bestlibrary for specific processor you need to link to either merged or dynamic IPP libraries.

As I wrote in previous my post, you canchose the unoptimized library to run on by usingippStaticInitCpu(ippCpuUnknown);

Please try PX library, and see if the issue gone.

Of course, this can not solve the issue as long as it is probably in optimized code and we have to fix it.Just knowing that noptimized code is good, can help us to differenciate where the bug is.

WBR

Vyacheslav

rporter · ‎06-01-2006

Hi,

Good news - with the non-optimized library did work (as you suggested).

In my previous attempt, I'm not completely sure what I missed (probably a library/link). I did call "ippStaticInitCpu(ippCpuUnknown);", but I think it could not find the non-optimized version. When I explicitly linked against the "px" libraries, I got the runtime warnings and created the links. With links for the non-optimized libraries, I was successful (even when not explicitly linking in those libraries, or even when NOT calling ippStaticInitCpu).

Here's the complete library info for the working case:

IPP Library version: 5.1.80 Build 182, name libippcore.so.5.1
IPP AC Library version: 5.1.80 Build 171, name libippacw7.so.5.1
IPP S Library version: 5.1.80 Build 219, name libippst7.so.5.1
IPP SC Library version: 5.1.80 Build 190, name libippscpx.so.5.1

Thank you for your attention on this matter. I do not feel a need to further debug this, since I have a combination of libraries that work.

Thanks,
Rick