为iOS arm64编译的G729编解码器无法正常运行

概述我在我的VOIP应用程序中使用了G729编解码器,当应用程序仅定位armv7时,它工作正常.被叫者可以清楚地听到我的声音.然后我转向arm64,被叫方不再清楚地听到我的声音.我在呼叫方的armv7设备和arm64设备上记录G729编解码器之前和之后的输入语音原始数据,然后将G729编码数据转换回来.我发现armv7设备转换后的语音比arm64设备要好得多. 这取决于您使用的G729实现,但如果您使 我在我的VOIP应用程序中使用了G729编解码器,当应用程序仅定位armv7时,它工作正常.被叫者可以清楚地听到我的声音.然后我转向arm64,被叫方不再清楚地听到我的声音.我在呼叫方的armv7设备和arm64设备上记录G729编解码器之前和之后的输入语音原始数据,然后将G729编码数据转换回来.我发现armv7设备转换后的语音比arm64设备要好得多.解决方法 这取决于您使用的G729实现,但如果您使用的是Samuel Vinson,我相信我发现了问题.

在lpc.c中,分别在第643行和第698行的两个值之间的结果和减法进行了比较：

lpc.c:643  if ((UWord32)(t0 - 0xfe000000L) < 0x01ffffffL -  0xfe000000L)lpc.c:698  if ((UWord32)(t0 - 0xff000000L) < 0x00ffffffL -  0xff000000L)

0x00ffffffL – 0xff000000L的结果是32位为1ffffff(33554431),而64位为ffffffff01ffffff(-4261412865),因为ARM处理器上64位的长度较大(我正在测试iPhone 4,armv7,32位和iPhone 5s,arm64,64位).

因此,基本上在64位上,比较将始终无法通过检查,因为第二项始终为负且UWord32将始终为正.

我的解决方案是使用32位减法的硬编码结果,所以
使用0x3ffffffL作为第一个条件,使用0x1ffffffL作为第二个,修复了我的语音质量问题：

lpc.c:643  if ((UWord32)(t0 - 0xff000000L) < 0x3ffffffL)lpc.c:698  if ((UWord32)(t0 - 0xfe000000L) < 0x1ffffffL)

希望这可以帮助.

总结

以上是内存溢出为你收集整理的为iOS arm64编译的G729编解码器无法正常运行全部内容，希望文章能够帮你解决为iOS arm64编译的G729编解码器无法正常运行所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。