| Summary: | ASTERISK-04491: [patch] speex dtx | ||
| Reporter: | James Cowling (jcowling) | Labels: | |
| Date Opened: | 2005-06-28 01:28:14 | Date Closed: | 2008-01-15 15:41:11.000-0600 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/CodecInterface |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) speex_dtx_cng_patch.txt ( 1) speex_dtx_patch.txt | |
| Description: | This will allow Speex to function with DTX enabled. Each DTX frame occupies only 5 bits (plus 5 bit terminator), rather than the 43+5 bits occupied by a Speex comfort-noise frame. Very minor code changes required. ****** ADDITIONAL INFORMATION ****** Took me a while to work it all out... Frames identified as DTX are encoded as 5 zero bits, which may be thought of as submode 0. This is now reflected in frame.c. This version is not as efficient as I would've liked - spent quite some time trying to avoid sending dtx frames *at all*, but couldn't get past all the timing/jitterbuffer issues. It's a shame to incur all the extra transmission overhead when no audible data is being sent. My Asterisk knowledge is fairly limited so if someone has any ideas let me know. (it's not as simple as setting frametype to AST_FRAME_CNG in lintospeex_frameout, since there may be multiple speex frames packaged into the single ast_frame, and we'll still get all the ast_frame overhead anyway) Note that you may notice a spike in bandwidth after a period of DTX silence when using ABR - I put this down to the ABR quality mechanism bumping up the quality during the quiet period to match the requested "available" bit rate, and then taking a while to settle back down. This isn't a problem with pure VBR. | ||
| Comments: | By: James Cowling (jcowling) 2005-07-12 03:48:06 speex_dtx_cng_patch.txt avoids sending dtx frames, and instead just sends a single AST_FRAME_CNG frame at the start of a silence period. This version saves a lot of bandwidth (and bandwidth will indeed go to 0 kbps during silence) but sometimes results in garbled audio after periods of silence when using trunking and jitter buffer. This appears to be a bug in the jitter buffer, where jitter is still sometimes being detected as, for example, 11000ms when there is an 11 second period of silence. I have verified that silence_begin_ts is being correctly registered in jitterbuf when a silence period begins, so this shouldn't be happening. By: James Cowling (jcowling) 2005-07-12 03:49:16 I've got a configurable Speex Preprocessor enabled version of codec_speex, with a few other mods (support for fixed-point mode etc), waiting for when the problems with the jitter buffer are sorted out. This incorporates *much* better voice detection but has quite a few code changes so I'm holding off submitting until the jitter buffer problems are fixed. By: Michael Jerris (mikej) 2005-07-12 08:34:02 To my knowledge, there are no outstanding jitterbuffer issues that have open bugs, other than implementing the new sip jitterbuffer. Are there other outstanding issues this is waiting on? By: stevekstevek (stevekstevek) 2005-07-12 17:22:10 jcowling: Try taking a look at how iaxclient handles this (I imagine that it would have saved you quite some time?). Iaxclient already supports DTX via VAD done by the speex preprocessor. I'm not sure what issues you're observing with the JB in this case. We have been using this (iaxclient with DTX and the new JB on both sides) for quite some time already. By: Kevin P. Fleming (kpfleming) 2005-07-12 18:12:19 Committed to CVS HEAD, thanks! By: Digium Subversion (svnbot) 2008-01-15 15:41:11.000-0600 Repository: asterisk Revision: 6113 U trunk/codecs/codec_speex.c U trunk/frame.c ------------------------------------------------------------------------ r6113 | kpfleming | 2008-01-15 15:41:10 -0600 (Tue, 15 Jan 2008) | 2 lines support DTX and CNG in speex (bug ASTERISK-4491) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=6113 | ||