|Summary:||ASTERISK-16237: [patch] Speex Wideband Support|
|Reporter:||Timo Teräs (fabled)||Labels:|
|Date Opened:||2010-06-12 10:32:21||Date Closed:||2010-06-19 13:06:53|
|Environment:||Attachments:||( 0) asterisk-trunk-speex-wideband.patch|
( 1) asterisk-trunk-speex-wideband-v2.patch
( 2) speex-nb.pcap
( 3) speex-wb.pcap
|Description:||Add support for Speex Wideband (16 kHz) codec.|
|Comments:||By: Malcolm Davenport (mdavenport) 2010-06-14 10:21:00|
X-Lite Beta 4.0 Beta 2 56233 (configured for Speex Wideband) or X-Lite 3.0 56125 (configured for Speex Wideband)or Ekiga 3.2.7 - all on Windows Vista
sflphone-client-gnome 0.9.8 (configured for Speex 16kHz) - on Ubuntu 10.04
with Asterisk-trunk and both set for disallow=all allow=speex_wb in sip.conf, I can introduce an error when the X-Lite or Ekiga clients place the sflphone client on hold (but not the other way around). The errors are:
frame.c:1375 speex_get_wb_sz_at: Encountered corrupt speex frame; too many wideband frames in a row
frame.c:1405 speex_samples: Had error while reading wideband frames for speex samples
Can you duplicate?
By: Timo Teräs (fabled) 2010-06-14 15:05:30
I will try to reproduce this. However, the speex specific code in frame.c does account for wideband frames properly. It would look like as either of the clients is sending corrupted stuff (like the error indicates). I checked and the limit of two wideband frames in row is imposed by libspeex too.
Do you get the same error if you use the speex narrowband mode (allow=speex)?
Would it be possible to get tcpdump capture of the packets when this happens?
By: Malcolm Davenport (mdavenport) 2010-06-14 16:54:46
Negative. I only get the error when using wideband Speex mode.
I have attached two packet captures made using Wireshark.
speex-nb is the narrowband capture.
speex-wb is the 16kHz capture.
10.24.13.230 represents the Asterisk server.
10.24.13.224 represents the sflphone client.
10.24.12.239 represents the Xlite client.
By: Timo Teräs (fabled) 2010-06-15 01:24:00
Thank you for the capture. There's one bit of speex frame parsing in the asterisk core code, and it had some bugs in it. It should now properly decode the wideband silence frames.
The three changes to speex frame decoder in main/frame.c are as follows:
1. Remove "not enough bits" warning. It's perfectly acceptable for the stream to end without the 5-bit terminator. This becomes evident if you look at libspeex/bits.c how the terminator is encoded: it's one 0-bit followed by 1-bits until byte boundary and only if we were not byte aligned in the first place. Thus, when stream ends termination is implicit. This caused problems in wideband due to different bit length wideband frames causing different termination patterns. Proper solution is just to remove the check for enough bits. (Present in patch v1.)
And the following added to patch v2:
2. Modification to SpeexWBSubModeSz in speex_get_wb_sz_at(). Wideband subtype #0 is valid: it's used as silence indicator, and needs the header bits to be skipped (length 4 instead of 0). This is the bug that caused the errors for you.
3. Handling of user in-band signals in narrowband submode 13. libspeex/speex_callbacks.c has speex_default_user_handler() that does the winding of bits differently. The code is fixed to follow libspeex. This probably does not matter since I haven't seen any one use user in-band signals.
Please test again to confirm that the bug is fixed.
By: Malcolm Davenport (mdavenport) 2010-06-15 08:03:50
I can confirm that I can no longer reproduce the issue identified before. Progress. :)
By: Timo Teräs (fabled) 2010-06-15 08:25:25
Good. Unless there's new immediate issues, I'd say this is "Ready for Testing" / to be posted on review board. Thanks.
By: Digium Subversion (svnbot) 2010-06-17 12:23:43
r271231 | dvossel | 2010-06-17 12:23:43 -0500 (Thu, 17 Jun 2010) | 9 lines
adds speex 16khz audio support
(closes issue ASTERISK-16237)
Reported by: fabled
asterisk-trunk-speex-wideband-v2.patch uploaded by fabled (license 448)
Tested by: malcolmd, fabled, dvossel