[Home]

Summary:ASTERISK-11413: [patch] DSP cleanup phase 2
Reporter:Dmitry Andrianov (dimas)Labels:
Date Opened:2008-02-10 15:57:49.000-0600Date Closed:2010-04-27 12:46:03
Priority:MinorRegression?No
Status:Closed/CompleteComponents:PBX/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) v1-dsp-cleanup.patch
( 1) v2-11968-dsp.patch
( 2) v2-11968-zap.patch
( 3) v3-11968-zap.patch
( 4) v4-11968-zap.patch
Description:NOTE: these changes ara made on top of http://bugs.digium.com/view.php?id=11796 so it must be applied first. Publishing changes mainly for review.

1. Removed MUTECONF/MUTEMAX options support from DSP code. The idea behind these is somewhat unclear and my analisys shows it is broken anyway - http://lists.digium.com/pipermail/asterisk-dev/2008-January/031650.html

2. The code now generated DTMF_BEGIN frames in addition to DTMF_END ones.

3. "quelching" rewritten - now each detector (MF/DTMF/generic tone) may mark fragment of a frame for suppression (squelching, muting) with a call to mute_fragment. Actual muting happens only once at the very end of ast_dsp_process where all marked fragments are zeroed. This way every detector sees original data in the frame without any piece of a frame being zeroed by a detector which was run before.

4. DTMF detector tries to "mute" one block before and one block after the block where actual tone was detected. Muting of previois block is something new for this patch. Obviously this operation is not always possible - if current frame does not contain data for previous block - it is too late. But at least we make our best.

Muting of next block was already done by the old code but it only affects part of the next block which is in the frame being processed. New code keeps this information in state structures so it will mute proper number of samples in the next frame(s) too.

5. Removed ast_dsp_digitdetect and ast_dsp_getdigits APIs because these are not used anyway but would made patch more complicated if kept.
Comments:By: Digium Subversion (svnbot) 2008-03-19 17:21:18

Repository: asterisk
Revision: 110161

U   trunk/channels/chan_h323.c
U   trunk/channels/chan_mgcp.c
U   trunk/channels/chan_misdn.c
U   trunk/channels/chan_sip.c
U   trunk/channels/chan_zap.c
U   trunk/include/asterisk/dsp.h
U   trunk/main/dsp.c

------------------------------------------------------------------------
r110161 | qwell | 2008-03-19 17:21:15 -0500 (Wed, 19 Mar 2008) | 5 lines

Rename DSP_FEATURE_DTMF_DETECT, because we are *NOT* only detecting DTMF digits.
This was very misleading.

Early cleanup for issue ASTERISK-11413

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=110161
By: Digium Subversion (svnbot) 2008-03-19 17:23:38

Repository: asterisk
Revision: 110162

_U  branches/1.6.0/

------------------------------------------------------------------------
r110162 | qwell | 2008-03-19 17:23:38 -0500 (Wed, 19 Mar 2008) | 12 lines

Blocked revisions 110161 via svnmerge

........
r110161 | qwell | 2008-03-19 17:25:34 -0500 (Wed, 19 Mar 2008) | 5 lines

Rename DSP_FEATURE_DTMF_DETECT, because we are *NOT* only detecting DTMF digits.
This was very misleading.

Early cleanup for issue ASTERISK-11413

........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=110162
By: Dmitry Andrianov (dimas) 2008-03-25 05:46:30

qwell,
it looks like I understand MUTECONF/MUTEMAX stuff now. My current understanding is that for MeetMe conferences (at least for Zap channels involved), mixing of the voice streams is done not by the MeetMe application itself but rather by TDMxxx board or by the Zaptel kernel module. (Not sure who exactly does that but it is not the MeetMe app). Because of this, all MeetMe participants hear DTMF tones geneated by Zap members even when dsp.c removes these tones. The only way to prevent this is to do zt_muteconf on Zap channel as soon as DTMF tone is detected. This is what the old dsp.c tried to do - it was generating DTMF mute/unmute frames which caused Zap channel driver to mute/unmute the conference. My patch removes this code so I need confirmation this is Ok.

Personally I think this is ok because:
1. The code was broken anyway. It _intended_ to do proper muting/unmuting but it did not work ( http://lists.digium.com/pipermail/asterisk-dev/2008-January/031650.html )
2. It looks like Digium wants to replace MeetMe with app_confbridge which does not do any special processing fo Zap channels.
3. Even if you really want to to zt_confmute it should be done differently - "generic" DSP should not generate some special frames. Instead it should provide some API to let calling code ask "do you think we are in the middle of some DTMF currently?" and Zap channel driver should query this API and do muting/unmuting. After all, DSPs business is detection only, not some channel-level control.

So if you can confirm that removal of this code is Ok, I will upload new patch with your changes applied.
By: Jason Parker (jparker) 2008-03-25 15:09:55

So, I tested the confmute stuff just now, and it does work - for the most part.  It's necessary to keep confmute to remove DTMF while still in zaptel, but the implementation of it could certainly use some work.

Maybe we should discuss how it could be implemented better, instead of removing it entirely (though, I probably wouldn't be against removing it, and starting over).
By: Jason Parker (jparker) 2008-03-25 15:20:03

note: when I tested this (without sending the confmute ioctl), I was still getting a short blip of the DTMF piped into the conference.  The blip seemed slightly longer from a zap channel than from a SIP phone.
By: Dmitry Andrianov (dimas) 2008-03-26 10:49:45

Updated the patch. Now it consists of two files:

v2-11968-dsp.patch
v4-11968-zap.patch

please ignore other files.

What is new;
1. DSP API extented a bit - ast_dsp_was_muted() function added which returns true if DSP code was muting any fragment in the last frame. chan_zap uses this function to decide it needs to turn on confmute on the channel.

This is to replace AST_FRAME_DTMF 'm'/'u' (mute/unmute) functionality.

2. dsp.c now has two new defines:

/* How many successive hits needed to consider begin of a digit */
#define DTMF_HITS_TO_BEGIN      2
/* How many successive misses needed to consider end of a digit */
#define DTMF_MISSES_TO_END      3

These will allow people easily patch the code and have reliable DTMF recognition in cases where signal is wobbling (like when GSM phone calls in). Increasing DTMF_MISSES_TO_END to 4-6 will allow DSP code to ignore long "dropouts" of DTMF within digit without ending it.
By: Digium Subversion (svnbot) 2008-03-26 14:01:28

Repository: asterisk
Revision: 111022

U   trunk/channels/chan_usbradio.c
U   trunk/channels/chan_vpb.cc
U   trunk/channels/chan_zap.c
U   trunk/include/asterisk/dsp.h
U   trunk/main/dsp.c

------------------------------------------------------------------------
r111022 | qwell | 2008-03-26 14:01:26 -0500 (Wed, 26 Mar 2008) | 23 lines

Large cleanup of DSP code

Per comments from dimas:
1. The code now generates DTMF_BEGIN frames in addition to DTMF_END ones.

2. "quelching" rewritten - now each detector (MF/DTMF/generic tone) may mark fragment of a frame for suppression (squelching, muting) with a call to mute_fragment. Actual muting happens only once at the very end of ast_dsp_process where all marked fragments are zeroed. This way every detector sees original data in the frame without any piece of a frame being zeroed by a detector which was run before.

3. DTMF detector tries to "mute" one block before and one block after the block where actual tone was detected. Muting of previois block is something new for this patch. Obviously this operation is not always possible - if current frame does not contain data for previous block - it is too late. But at least we make our best.
Muting of next block was already done by the old code but it only affects part of the next block which is in the frame being processed. New code keeps this information in state structures so it will mute proper number of samples in the next frame(s) too.

4. Removed ast_dsp_digitdetect and ast_dsp_getdigits APIs because these are not used.

5. DSP API extended a bit - ast_dsp_was_muted() function added which returns true if DSP code was muting any fragment in the last frame. chan_zap uses this function to decide it needs to turn on confmute on the channel.
This is to replace AST_FRAME_DTMF 'm'/'u' (mute/unmute) functionality.


(closes issue ASTERISK-11413)
Reported by: dimas
Patches:
     v2-11968-dsp.patch uploaded by dimas (license 88)
     v4-11968-zap.patch uploaded by dimas (license 88)
Tested by: dimas, qwell

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=111022
By: Digium Subversion (svnbot) 2008-03-26 14:04:40

Repository: asterisk
Revision: 111027

_U  branches/1.6.0/

------------------------------------------------------------------------
r111027 | qwell | 2008-03-26 14:04:39 -0500 (Wed, 26 Mar 2008) | 30 lines

Blocked revisions 111022 via svnmerge

........
r111022 | qwell | 2008-03-26 14:05:51 -0500 (Wed, 26 Mar 2008) | 23 lines

Large cleanup of DSP code

Per comments from dimas:
1. The code now generates DTMF_BEGIN frames in addition to DTMF_END ones.

2. "quelching" rewritten - now each detector (MF/DTMF/generic tone) may mark fragment of a frame for suppression (squelching, muting) with a call to mute_fragment. Actual muting happens only once at the very end of ast_dsp_process where all marked fragments are zeroed. This way every detector sees original data in the frame without any piece of a frame being zeroed by a detector which was run before.

3. DTMF detector tries to "mute" one block before and one block after the block where actual tone was detected. Muting of previois block is something new for this patch. Obviously this operation is not always possible - if current frame does not contain data for previous block - it is too late. But at least we make our best.
Muting of next block was already done by the old code but it only affects part of the next block which is in the frame being processed. New code keeps this information in state structures so it will mute proper number of samples in the next frame(s) too.

4. Removed ast_dsp_digitdetect and ast_dsp_getdigits APIs because these are not used.

5. DSP API extended a bit - ast_dsp_was_muted() function added which returns true if DSP code was muting any fragment in the last frame. chan_zap uses this function to decide it needs to turn on confmute on the channel.
This is to replace AST_FRAME_DTMF 'm'/'u' (mute/unmute) functionality.


(closes issue ASTERISK-11413)
Reported by: dimas
Patches:
     v2-11968-dsp.patch uploaded by dimas (license 88)
     v4-11968-zap.patch uploaded by dimas (license 88)
Tested by: dimas, qwell

........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=111027
By: Digium Subversion (svnbot) 2008-04-09 15:15:43

Repository: asterisk
Revision: 113924

U   team/group/NoLossCDR-Redux2/build_tools/cflags.xml
U   team/group/NoLossCDR-Redux2/pbx/pbx_ael.c
U   team/group/NoLossCDR-Redux2/phoneprov/000000000000-directory.xml
U   team/group/NoLossCDR-Redux2/phoneprov/polycom.xml
A   team/group/NoLossCDR-Redux2/phoneprov/polycom_line.xml

------------------------------------------------------------------------
r113924 | juggie | 2008-04-09 15:15:41 -0500 (Wed, 09 Apr 2008) | 211 lines

Merged revisions 110020,110023,110036,110084,110087,110132,110161,110164,110211,110237,110268,110270,110272,110303,110337,110339,110396,110444 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r110020 | file | 2008-03-19 14:25:33 -0400 (Wed, 19 Mar 2008) | 14 lines

Merged revisions 110019 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110019 | file | 2008-03-19 15:20:28 -0300 (Wed, 19 Mar 2008) | 6 lines

Make sure that the mark bit does not incorrectly cause video frame timestamps to be calculated as if they are audio frames.
(closes issue ASTERISK-10940)
Reported by: sperreault
Patches:
     11429-frametype.diff uploaded by qwell (license 4)

........

................
r110023 | russell | 2008-03-19 14:57:16 -0400 (Wed, 19 Mar 2008) | 2 lines

remove svnmerge-blocked property that is not supposed to be here

................
r110036 | file | 2008-03-19 15:13:39 -0400 (Wed, 19 Mar 2008) | 12 lines

Merged revisions 110035 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110035 | file | 2008-03-19 16:11:33 -0300 (Wed, 19 Mar 2008) | 4 lines

Add sanity checking for position resuming. We *have* to make sure that the position does not exceed the total number of files present, and we have to make sure that the position's filename is the same as previous. These values can change if a music class is reloaded and give unpredictable behavior.
(closes issue ASTERISK-11136)
Reported by: junky

........

................
r110084 | mmichelson | 2008-03-19 16:34:13 -0400 (Wed, 19 Mar 2008) | 12 lines

Merged revisions 110083 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110083 | mmichelson | 2008-03-19 15:33:03 -0500 (Wed, 19 Mar 2008) | 4 lines

Add a missing unlock in the case that memory allocation fails in app_chanspy.
Thanks to Russell for confirming that this was an issue.


........

................
r110087 | jpeeler | 2008-03-19 17:05:24 -0400 (Wed, 19 Mar 2008) | 2 lines

This change adds DNS manager support for registrations not referencing a peer entry. It looks like there is support for DNS manager for realtime peers as well, however it is not implemented correctly. The improper usage occurs when ast_dnsmgr_lookup is called with one of the arguments being an address from the stack to be continually updated. The variable from the stack will go out of scope and dnsmgr will continue to try and update the memory there, causing possible stack corruption. This problem will be worked on next as well as adding DNS manager support for peer entries.

................
r110132 | qwell | 2008-03-19 17:56:15 -0400 (Wed, 19 Mar 2008) | 1 line

Rename very poorly named function to reflect what it actually does.  This was causing quite a bit of confusion for me...
................
r110161 | qwell | 2008-03-19 18:25:34 -0400 (Wed, 19 Mar 2008) | 5 lines

Rename DSP_FEATURE_DTMF_DETECT, because we are *NOT* only detecting DTMF digits.
This was very misleading.

Early cleanup for issue ASTERISK-11413

................
r110164 | russell | 2008-03-19 18:58:33 -0400 (Wed, 19 Mar 2008) | 13 lines

Merged revisions 110163 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110163 | russell | 2008-03-19 17:57:59 -0500 (Wed, 19 Mar 2008) | 5 lines

Fix a bug where when calls on the trunk side hang up while on hold, the state
is not properly reflected.

(closes issue ASTERISK-11434, reported by anakaoka, patched by me)

........

................
r110211 | tilghman | 2008-03-19 23:14:59 -0400 (Wed, 19 Mar 2008) | 2 lines

Fix recent trunk breakage

................
r110237 | tilghman | 2008-03-20 01:06:12 -0400 (Thu, 20 Mar 2008) | 5 lines

Upgrade the sounds version; add several directory enhancements:
1) Number of digits to enter can now be configured
2) The digits can now match on both first AND last name, instead of only one or the other
(Closes issue ASTERISK-6965)

................
r110268 | russell | 2008-03-20 13:41:22 -0400 (Thu, 20 Mar 2008) | 27 lines

Add some fixes that I made in regards to wideband codec handling to get
G.722 music on hold working for me.

(issue ASTERISK-11594, reported by milazzo and jsmith, patches by me)

res/res_musiconhold.c:
- I moved a single line so that the sample queue update happened before
  ast_write().  The reason that this was a bug is that the G.722 frame
  originally says it has 320 samples in it (which is correct).  However,
  when the frame is written to a channel that uses RTP, main/rtp.c modifies
  the frame to cut the number of samples in half before it sends it on
  the wire.  This is to account for the stupid incorrect G.722 spec that
  makes it so we have to lie about the number of samples with RTP.  I should
  probably go and re-work the RTP code so it doesn't modify the frame so
  that a bug like this won't happen in the future.  However, this change to
  MOH is harmless.

main/channel.c:
- I made two fixes in regards to generator timing.  Generators use samples
  for timing.  However, this code assumed 8 kHz samples.  In one case, it was
  a hard coded 160 samples, that is now written as the sample rate / 50.  The
  other place was dealing with timing a generator based on frames coming from
  the other direction.  However, that would have only worked if the sample
  rates for the formats in both directions were the same.  The code now takes
  into account that the sample rates may differ, and scales the generator
  samples accordingly.

................
r110270 | russell | 2008-03-20 13:45:29 -0400 (Thu, 20 Mar 2008) | 2 lines

Remove astobj.h from some places where it wasn't needed

................
r110272 | mmichelson | 2008-03-20 14:01:36 -0400 (Thu, 20 Mar 2008) | 3 lines

Add missing unlock


................
r110303 | russell | 2008-03-20 16:08:26 -0400 (Thu, 20 Mar 2008) | 8 lines

Fix a bug when using zaptel timing for playing back files that have a sample rate
other than 8 kHz.  The issue here is that format modules give a "whennext" sample
value, which is used to calculate when to set a timer for to retrieve the next
frame.  However, the zaptel timer operates on 8 kHz samples, so this must be taken
into account.

(another part of issue ASTERISK-11594, reported by milazzo and jsmith, patch by me)

................
r110337 | russell | 2008-03-20 17:55:50 -0400 (Thu, 20 Mar 2008) | 22 lines

Merged revisions 110336 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

................
r110336 | russell | 2008-03-20 16:54:58 -0500 (Thu, 20 Mar 2008) | 14 lines

Merged revisions 110335 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r110335 | russell | 2008-03-20 16:53:27 -0500 (Thu, 20 Mar 2008) | 6 lines

Fix some very broken code that was introduced in 1.2.26 as a part of the security
fix.  The dnsmgr is not appropriate here.  The dnsmgr takes a pointer to an address
structure that a background thread continuously updates.  However, in these cases,
a stack variable was passed.  That means that the dnsmgr thread would be continuously
writing to bogus memory.

........

................

................
r110339 | russell | 2008-03-20 18:02:20 -0400 (Thu, 20 Mar 2008) | 3 lines

Use the correct buffer for g722tolin16_sample.  This shouldn't have caused any
problems, but Qwell noticed the typo here.

................
r110396 | russell | 2008-03-20 19:14:13 -0400 (Thu, 20 Mar 2008) | 17 lines

Merged revisions 110395 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110395 | russell | 2008-03-20 18:13:56 -0500 (Thu, 20 Mar 2008) | 9 lines

Shorten the ast_waitfor() timeout from 500 ms to 50 ms in the autoservice thread.
This really should not make a difference except in very rare cases.  That case would
be that all of the channels in autoservice are not generating any frames.  In that
case, this change reduces the potential amount of time that a thread waits in
ast_autoservice_stop() for the autoservice thread to wrap back around to the beginning
of its loop.

(closes issue ASTERISK-11689, reported by dimas)

........

................
r110444 | tilghman | 2008-03-20 21:44:38 -0400 (Thu, 20 Mar 2008) | 2 lines

Add note of the added Directory options, from commit 110237 (closes issue ASTERISK-6965)

................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=113924
By: Digium Subversion (svnbot) 2008-04-09 15:18:57

Repository: asterisk
Revision: 113925

U   team/group/NoLossCDR-Redux2/channels/chan_h323.c
U   team/group/NoLossCDR-Redux2/channels/chan_usbradio.c
U   team/group/NoLossCDR-Redux2/channels/misdn_config.c

------------------------------------------------------------------------
r113925 | juggie | 2008-04-09 15:18:55 -0500 (Wed, 09 Apr 2008) | 211 lines

Merged revisions 110020,110023,110036,110084,110087,110132,110161,110164,110211,110237,110268,110270,110272,110303,110337,110339,110396,110444 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r110020 | file | 2008-03-19 14:25:33 -0400 (Wed, 19 Mar 2008) | 14 lines

Merged revisions 110019 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110019 | file | 2008-03-19 15:20:28 -0300 (Wed, 19 Mar 2008) | 6 lines

Make sure that the mark bit does not incorrectly cause video frame timestamps to be calculated as if they are audio frames.
(closes issue ASTERISK-10940)
Reported by: sperreault
Patches:
     11429-frametype.diff uploaded by qwell (license 4)

........

................
r110023 | russell | 2008-03-19 14:57:16 -0400 (Wed, 19 Mar 2008) | 2 lines

remove svnmerge-blocked property that is not supposed to be here

................
r110036 | file | 2008-03-19 15:13:39 -0400 (Wed, 19 Mar 2008) | 12 lines

Merged revisions 110035 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110035 | file | 2008-03-19 16:11:33 -0300 (Wed, 19 Mar 2008) | 4 lines

Add sanity checking for position resuming. We *have* to make sure that the position does not exceed the total number of files present, and we have to make sure that the position's filename is the same as previous. These values can change if a music class is reloaded and give unpredictable behavior.
(closes issue ASTERISK-11136)
Reported by: junky

........

................
r110084 | mmichelson | 2008-03-19 16:34:13 -0400 (Wed, 19 Mar 2008) | 12 lines

Merged revisions 110083 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110083 | mmichelson | 2008-03-19 15:33:03 -0500 (Wed, 19 Mar 2008) | 4 lines

Add a missing unlock in the case that memory allocation fails in app_chanspy.
Thanks to Russell for confirming that this was an issue.


........

................
r110087 | jpeeler | 2008-03-19 17:05:24 -0400 (Wed, 19 Mar 2008) | 2 lines

This change adds DNS manager support for registrations not referencing a peer entry. It looks like there is support for DNS manager for realtime peers as well, however it is not implemented correctly. The improper usage occurs when ast_dnsmgr_lookup is called with one of the arguments being an address from the stack to be continually updated. The variable from the stack will go out of scope and dnsmgr will continue to try and update the memory there, causing possible stack corruption. This problem will be worked on next as well as adding DNS manager support for peer entries.

................
r110132 | qwell | 2008-03-19 17:56:15 -0400 (Wed, 19 Mar 2008) | 1 line

Rename very poorly named function to reflect what it actually does.  This was causing quite a bit of confusion for me...
................
r110161 | qwell | 2008-03-19 18:25:34 -0400 (Wed, 19 Mar 2008) | 5 lines

Rename DSP_FEATURE_DTMF_DETECT, because we are *NOT* only detecting DTMF digits.
This was very misleading.

Early cleanup for issue ASTERISK-11413

................
r110164 | russell | 2008-03-19 18:58:33 -0400 (Wed, 19 Mar 2008) | 13 lines

Merged revisions 110163 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110163 | russell | 2008-03-19 17:57:59 -0500 (Wed, 19 Mar 2008) | 5 lines

Fix a bug where when calls on the trunk side hang up while on hold, the state
is not properly reflected.

(closes issue ASTERISK-11434, reported by anakaoka, patched by me)

........

................
r110211 | tilghman | 2008-03-19 23:14:59 -0400 (Wed, 19 Mar 2008) | 2 lines

Fix recent trunk breakage

................
r110237 | tilghman | 2008-03-20 01:06:12 -0400 (Thu, 20 Mar 2008) | 5 lines

Upgrade the sounds version; add several directory enhancements:
1) Number of digits to enter can now be configured
2) The digits can now match on both first AND last name, instead of only one or the other
(Closes issue ASTERISK-6965)

................
r110268 | russell | 2008-03-20 13:41:22 -0400 (Thu, 20 Mar 2008) | 27 lines

Add some fixes that I made in regards to wideband codec handling to get
G.722 music on hold working for me.

(issue ASTERISK-11594, reported by milazzo and jsmith, patches by me)

res/res_musiconhold.c:
- I moved a single line so that the sample queue update happened before
  ast_write().  The reason that this was a bug is that the G.722 frame
  originally says it has 320 samples in it (which is correct).  However,
  when the frame is written to a channel that uses RTP, main/rtp.c modifies
  the frame to cut the number of samples in half before it sends it on
  the wire.  This is to account for the stupid incorrect G.722 spec that
  makes it so we have to lie about the number of samples with RTP.  I should
  probably go and re-work the RTP code so it doesn't modify the frame so
  that a bug like this won't happen in the future.  However, this change to
  MOH is harmless.

main/channel.c:
- I made two fixes in regards to generator timing.  Generators use samples
  for timing.  However, this code assumed 8 kHz samples.  In one case, it was
  a hard coded 160 samples, that is now written as the sample rate / 50.  The
  other place was dealing with timing a generator based on frames coming from
  the other direction.  However, that would have only worked if the sample
  rates for the formats in both directions were the same.  The code now takes
  into account that the sample rates may differ, and scales the generator
  samples accordingly.

................
r110270 | russell | 2008-03-20 13:45:29 -0400 (Thu, 20 Mar 2008) | 2 lines

Remove astobj.h from some places where it wasn't needed

................
r110272 | mmichelson | 2008-03-20 14:01:36 -0400 (Thu, 20 Mar 2008) | 3 lines

Add missing unlock


................
r110303 | russell | 2008-03-20 16:08:26 -0400 (Thu, 20 Mar 2008) | 8 lines

Fix a bug when using zaptel timing for playing back files that have a sample rate
other than 8 kHz.  The issue here is that format modules give a "whennext" sample
value, which is used to calculate when to set a timer for to retrieve the next
frame.  However, the zaptel timer operates on 8 kHz samples, so this must be taken
into account.

(another part of issue ASTERISK-11594, reported by milazzo and jsmith, patch by me)

................
r110337 | russell | 2008-03-20 17:55:50 -0400 (Thu, 20 Mar 2008) | 22 lines

Merged revisions 110336 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

................
r110336 | russell | 2008-03-20 16:54:58 -0500 (Thu, 20 Mar 2008) | 14 lines

Merged revisions 110335 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r110335 | russell | 2008-03-20 16:53:27 -0500 (Thu, 20 Mar 2008) | 6 lines

Fix some very broken code that was introduced in 1.2.26 as a part of the security
fix.  The dnsmgr is not appropriate here.  The dnsmgr takes a pointer to an address
structure that a background thread continuously updates.  However, in these cases,
a stack variable was passed.  That means that the dnsmgr thread would be continuously
writing to bogus memory.

........

................

................
r110339 | russell | 2008-03-20 18:02:20 -0400 (Thu, 20 Mar 2008) | 3 lines

Use the correct buffer for g722tolin16_sample.  This shouldn't have caused any
problems, but Qwell noticed the typo here.

................
r110396 | russell | 2008-03-20 19:14:13 -0400 (Thu, 20 Mar 2008) | 17 lines

Merged revisions 110395 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110395 | russell | 2008-03-20 18:13:56 -0500 (Thu, 20 Mar 2008) | 9 lines

Shorten the ast_waitfor() timeout from 500 ms to 50 ms in the autoservice thread.
This really should not make a difference except in very rare cases.  That case would
be that all of the channels in autoservice are not generating any frames.  In that
case, this change reduces the potential amount of time that a thread waits in
ast_autoservice_stop() for the autoservice thread to wrap back around to the beginning
of its loop.

(closes issue ASTERISK-11689, reported by dimas)

........

................
r110444 | tilghman | 2008-03-20 21:44:38 -0400 (Thu, 20 Mar 2008) | 2 lines

Add note of the added Directory options, from commit 110237 (closes issue ASTERISK-6965)

................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=113925