針對iOS arm64編譯的G729編解碼器無法正常工作

我在我的VOIP應用中使用了G729編解碼器，當應用程序目標只有armv7時，它工作正常。被叫方可以清楚地聽到我的聲音。然後我轉向arm64，被叫不再清楚地聽到我的聲音。我在G729編解碼器之前和之後在來電端的armv7設備和arm64設備上錄製輸入語音原始數據，然後將G729編碼數據轉回。我發現從armv7設備轉換回來的聲音比arm64設備好得多。針對iOS arm64編譯的G729編解碼器無法正常工作

來源

2015-05-08 Liangxiu

與論壇網站不同，我們不使用「謝謝」或「任何幫助表示讚賞」，或在[so]上簽名。請參閱「[應該'嗨'，'謝謝'，標語和致敬從帖子中刪除？]（http://meta.stackexchange.com/questions/2950/should-hi-thanks-taglines-and-salutations-be - 刪除 - 從帖子）。 –

可以üPLZ分享你的代碼嗎？ – DareDevil

這取決於您正在使用的G729實現，但如果您使用的是Samuel Vinson's，我相信我發現了這個問題。

在lpc.c有一個結果，並分別在線路643的兩個值和698之間的減法之間的比較：

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

的0x00ffffffL - 0xff000000L結果是1ffffff（33554431）在32位，但ffffffff01ffffff（-4261412865 ），因爲在ARM處理器（我正在測試iPhone 4，armv7,32位和iPhone 5s，arm64,64位）上64位長度較長。

因此，基本上在64位上，比較總是會失敗，因爲第二項總是負值，並且UWord32總是正值。

我的解決方案是使用32位減法的硬編碼的結果，所以使用0x3ffffffL爲第一條件和0x1ffffffL第二，修復了語音質量問題對我來說：

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

希望這幫助。

來源

2015-07-22 16:29:27 clawoo

是的，那是'對，非常感謝 – Liangxiu

你救了我的生命的兄弟！挖了近一個月，謝謝你!! :) – Erfan

非常感謝 - 希望我能給出這個答案更多upvotes –

針對iOS arm64編譯的G729編解碼器無法正常工作

回答

相關問題