g.722.2 Bit exact issue

Hi,

We are working on and we will get back to you with an update.

Thanks & regards,

Sivaraj K

Thanks a lot Sivaraj,

Just another update from my side.

The same test cases doen't have any issue with the AMR WB decoder. Its running fine without any bit exact issue.

Only Encoder has the issue of Bit Exactness.

Thanks & regards,

Ashok

Hello All...

Any update on this please...?

Regards,

Ashok

Can you confirm

the codecs is downloaded from: http://software-dl.ti.com/dsps/dsps_public_sw/codecs/C55X_Speech/index_FDS.html

test vectors from: http://www.itu.int/rec/T-REC-G.722.2-200307-I!AnnD/en

Of the test as defined in All_test_vectors_enc.txt, which rate and which vector is failing?

Do you have a CCS project or .out to share with us to reproduce the issue?

Thanks, Eric

Thanks Eric for the reply.

Yes I confirm that the codec and its test vectors were downloaded from the locations you have mentioned.

Every test case is failing for Encoder. But Decoder it is passing all the test cases.

I am attaching the complete AMREnc workspace for your reference.

Regards,

Ashok4705.wbAMREnc.rar

Thanks! I tested T00.inp with MR660 and DTX off, and test failed for the first frame at sample 14. Since failure for all mode and all vectors are unusual, I am checking with codec development team if any test methodology issue.

Regards, Eric

Thanks Eric.

I also saw that all the test cases fail exactly the same way...1st frame 14th sample. But the sample number varies with frame numbers if I continue with the test case instead of moving to a new test case for every failure.

I also thought of some basic configuration setting or something is the issue but could not find any.

Regards,

Ashok

Hi Eric / Sivaraj,

Any updates on this..?

Regards,

Ashok

Ashok,

Sorry, the codec developer is out of office this week but his colleague is looking at it. Some delay of response is expected.

Regards, Eric

Thanks Eric. Will wait. :-)

Hi Eric Any update..?

We are still debugging it, felt like a CCS/cgen tool issue. The cgen 2.78 and CCS 2.21 were used for the release and we are trying compare the tool.

Regards, Eric

But I don't see this issue with Decoder. All the test cases are passing. Even the decoder was built with CCS 2.21 and cgen 2.78 and now I'm using CCS 4 and cgen 4.41.

Regards

Ashok

This is a silicon issue. The library is working fine on C55x Rev 2.0 Simulator and on C5509A DSK, however, it is failing on C55x Rev 3.0 Simulator and C5515 EVM. I think the you are using C5535 DSP, which is a Rev 3 silicon.

What devleopment phase are you in? Are you able to test on Rev 2.0 temporarily? Publishing a WB-AMR C55x working on Rev 3.0 silicon needs go through some process.

Regards, Eric

Thanks Eric for the clarification.

We have zeroed on the 5535 DSP and are in the process of building our hardware system.

In the mean time while waiting for your answer I ran the WB-AMR encoder on one of the speech input signal and captured the output and fed it to the WB-AMR decoder. The resulting output speech though not bit exact with the corresponding reference output, did not give any issues while listening. Do you feel will there be any MOS issues if we go ahead with the code as it is..?

Regards,

Ashok

I would be suspicious of assembly instructions that do not take modify all 23-bits of the extended auxillary registers (XAR#). If instructions use auxillary register (AR#) instead of XAR, then only the LSB 16-bits are written. See this...

There is one instruction(mar(AR0=AR3)) to restore the pointer to XAR0. By using "mar", only lower part is copied. If AR0 has different higher address compared to AR3, results would be wrong. In a child function from these files, AR0 is used as index. It is initialized with -1(XAR0=0x00FFFF). After the first increment, XAR0 content becomes 0x010000(no roll back) on REV3 and  0x000000 on REV2. On REV2, higher address does not change in child function, hence code works. On REV3, since higher part changes to 1 from 0, copy instruction in the parent (mar(AR0=AR3)) results incorrect execution.

Hope this helps,
Mark

Hi Guys ..!!

Any update on this issue..? When will we get the fix for this WBAMR Encoder..? Is any one working on it..? Can some one take care of what Mark has written above and confirm the issue is due to the same reason..?

We are seeing some quality issues with real time testing and we don't want this issue of bit exactness to bite us in field trials.

Thanks & regards,

Ashok

Ashok,

Sorry for the late response. This is a silicon issue. The library is working fine on C55x Rev 2.0 Simulator and on C5509A DSK, however, it is failing on C55x Rev 3.0 Simulator and C5515 EVM. You are using C5535 DSP, which is a Rev 3 silicon, correct? Please confirm.

Further, We have an upgraded release of this codec for silicon revision 3.3. We are going to start the release process.

Regards, Eric

Yes Eric. We are using C5535 DSP (currently using the spectrum digital eZdsp eval board). Please let me know if this silicon rev 3.3 release for this codec can be used for C5535 DSp..? if yes when will the release be done..? If no then what do you suggest me to get things moving..?

Thanks & Regards,

Ashok

The new release is able to run on C5535 DSP. I will let you know when it can be published.

Regards, Eric

Thanks Eric.

Your help is appreciated.

Have one more question.

We are using the "volib_C55_CPU3_2_1_0_1" and "faxlib_C55_CPU3_2_1_0_1" also along with the WBAMR and the names of these package it self tells that it is for CPU rev 3. And I have run simulations of few of the components from each library on the target and they work fine.

My question is if this is an address generation issue as pointed out by Mark, then these components may not be encountering any such issue when tested individually as that may not be accessing any address beyond 16 bits and hence may be working fine.

But when we combine many components together what if the code encounters any address that is beyond 16 bits.? will it still work fine..? Has some one tested it that way..? Can some one give confirmation that these packages have a work around for this issue..?

Regards,

Ashok

Thanks a lot Eric. That was a big relief. Will be waiting for AMR till then...

Thanks a lot Eric.

Your help is tremendously appreciated. I have downloaded and installed the new package. Will test and confirm.

Thanks again..

Regards,

Ashok

Dear Eric,

I ran the new AMR Package (both encoder & Decoder) and they bother are bit exact with the reference vectors.

Thanks again for all the efforts of you and your team.

Regards,

Ashok

Any word on when the new release will be published? We believe that we are also seeing an issue using a C5505 DSP.

-Louis