Hi Nanang, > IIRC, the story behind that fix was: according to (our understanding > of) G722 spec, G722 input/output is 14 bits. So, r2342 basically > converts audio sample from 16-bits to 14-bits before encoding and > "returns back" the 14-bits to 16-bits after decoding. And after this > fix, pjmedia G722 seems to work fine with VoiceAge implementation of > G722. > > IIRC again, some other implementations don't do 16<->14 bits > conversions, so when pjmedia G722 is talking to those G722 > implementations, such problems of over-driven level and audio clipping > may occur. In this case, *reverting* (instead of including:) ) r2342 > will resolve the problem. > We got some feedback from Kevin Fleming (Asterisk) and Steve Underwood (author of SpanDSP). Both Asterisk and FreeSWITCH use Steve's g722 implementation and according to tho their answers, that g722 implementation doesn't shift those last 2 bits, instead it uses the first 14. I did the following tests: - Reverted r2342 and called ZipDX wideband demo. Audio was ok. - Reverted r2342 and played back a g722 file in Asterisk 1.6.2. Audio was ok. If I applied r2342 the audio was distorted and overdriven so you got it right, this is the issue. > However, I'm afraid that we may prefer to stay with r2342. > I truly don't know the current status of other implementations but with the ones I tried (couldn't try FreeSWITCH, but according to Steve it's the same as Asterisk) r2342 makes audio quality not good. > Any feedbacks or suggestions are welcome. > As I don't know if this can be detected at runtime, I suggest this fix was applied according to a configuration option (if possible) or a define which can be selected at compile time. What are your thoughts on this? Best regards, -- Saul Ibarra Corretge AG Projects
