[Home]

Summary:ASTERISK-11394: MixMonitor - Out Of Sync Audio With Zap Channels
Reporter:Jeff Iddings (xheliox)Labels:
Date Opened:2008-02-07 08:44:41.000-0600Date Closed:2008-12-10 11:54:03.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_mixmonitor
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Since upgrading to 1.4.18-rc4, MixMonitor seems to be producing files that are out of sync. You hear the caller and then several seconds later, you hear the response.

This appears to only be happening on Zap (both analog and digital) channels, SIP is unaffected.
Comments:By: Joshua C. Colp (jcolp) 2008-02-08 09:54:41.000-0600

What was the previous version that worked fine?
By: Holger Hornung (netview) 2008-02-08 10:19:17.000-0600

The latest version which has syncing correctly was before the "audio-hook"-Implementation.
By: Evandro César Arruda (ecarruda) 2008-02-14 06:26:35.000-0600

Hi People,

I'm using Asterisk with IAX Channels and i'm getting the same problem, most records are out of sync, in other versions I didin't have this problem.

Thanks
By: Evandro César Arruda (ecarruda) 2008-02-14 06:27:45.000-0600

Sorry,

But i didin't read the answer of the latest version worked fine, in my company is this 1.4.17.

Sorry and Thanks again.
By: Jeff Iddings (xheliox) 2008-02-14 06:28:42.000-0600

I upgraded from 1.4.12..  a bit of a jump.
By: Eric Dantie (edantie) 2008-02-16 01:12:46.000-0600

I have the same problem. It's effectively since audiohook. It's not a always problem. The problem is with 1.4.18+ but not with 1.4.17-
Will tell later if stopping ntpd server will correct the problem.
By: Eric Dantie (edantie) 2008-02-18 02:10:21.000-0600

Still happen without ntpd
By: Doug (doug) 2008-03-10 10:55:54

We having the same problem on 1.4.18. We using only SIP channels so its not specific to Zap and SIP but SIP to SIP aswell. 1.4.17 works fine.
By: Joshua C. Colp (jcolp) 2008-03-12 10:49:41

DougUDI: What is the call flow like? Can you provide console output? What codecs are in use? Are you using a different framing then default?
By: Joshua C. Colp (jcolp) 2008-03-12 11:04:15

Nevermind, figured out the cause.
By: Digium Subversion (svnbot) 2008-03-12 13:22:36

Repository: asterisk
Revision: 108083

U   branches/1.4/apps/app_mixmonitor.c
U   branches/1.4/include/asterisk/audiohook.h
U   branches/1.4/main/audiohook.c

------------------------------------------------------------------------
r108083 | file | 2008-03-12 13:22:35 -0500 (Wed, 12 Mar 2008) | 4 lines

Add a trigger mode that triggers on both read and write. The actual function that returns the combined audio frame though will wait until both sides have fed in audio, or until one side stops (such as the case when you call Wait).
(closes issue ASTERISK-11394)
Reported by: xheliox

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

http://svn.digium.com/view/asterisk?view=rev&revision=108083
By: Digium Subversion (svnbot) 2008-03-12 13:25:29

Repository: asterisk
Revision: 108084

_U  trunk/
U   trunk/apps/app_mixmonitor.c
U   trunk/include/asterisk/audiohook.h
U   trunk/main/audiohook.c

------------------------------------------------------------------------
r108084 | file | 2008-03-12 13:25:28 -0500 (Wed, 12 Mar 2008) | 12 lines

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

........
r108083 | file | 2008-03-12 15:26:37 -0300 (Wed, 12 Mar 2008) | 4 lines

Add a trigger mode that triggers on both read and write. The actual function that returns the combined audio frame though will wait until both sides have fed in audio, or until one side stops (such as the case when you call Wait).
(closes issue ASTERISK-11394)
Reported by: xheliox

........

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

http://svn.digium.com/view/asterisk?view=rev&revision=108084
By: Digium Subversion (svnbot) 2008-03-12 13:27:11

Repository: asterisk
Revision: 108085

_U  branches/1.6.0/
U   branches/1.6.0/apps/app_mixmonitor.c
U   branches/1.6.0/include/asterisk/audiohook.h
U   branches/1.6.0/main/audiohook.c

------------------------------------------------------------------------
r108085 | file | 2008-03-12 13:27:11 -0500 (Wed, 12 Mar 2008) | 20 lines

Merged revisions 108084 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r108084 | file | 2008-03-12 15:29:33 -0300 (Wed, 12 Mar 2008) | 12 lines

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

........
r108083 | file | 2008-03-12 15:26:37 -0300 (Wed, 12 Mar 2008) | 4 lines

Add a trigger mode that triggers on both read and write. The actual function that returns the combined audio frame though will wait until both sides have fed in audio, or until one side stops (such as the case when you call Wait).
(closes issue ASTERISK-11394)
Reported by: xheliox

........

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

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

http://svn.digium.com/view/asterisk?view=rev&revision=108085
By: Digium Subversion (svnbot) 2008-03-17 13:03:40

Repository: asterisk
Revision: 109173

_U  team/murf/bug11210/
U   team/murf/bug11210/apps/app_chanspy.c
U   team/murf/bug11210/apps/app_mixmonitor.c
U   team/murf/bug11210/channels/chan_sip.c
U   team/murf/bug11210/funcs/func_config.c
U   team/murf/bug11210/include/asterisk/astobj2.h
U   team/murf/bug11210/include/asterisk/audiohook.h
U   team/murf/bug11210/include/asterisk/pbx.h
U   team/murf/bug11210/main/astobj2.c
U   team/murf/bug11210/main/audiohook.c
U   team/murf/bug11210/main/channel.c
U   team/murf/bug11210/main/pbx.c

------------------------------------------------------------------------
r109173 | murf | 2008-03-17 13:03:22 -0500 (Mon, 17 Mar 2008) | 105 lines

Merged revisions 107998,108032,108034,108084,108137 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r107998 | tilghman | 2008-03-12 01:43:03 -0600 (Wed, 12 Mar 2008) | 7 lines

Deadlock fixes
(closes issue ASTERISK-11576)
Reported by: kactus
Patches:
      20080312__bug12143__2.diff.txt uploaded by Corydon76 (license 14)
Tested by: kactus

................
r108032 | russell | 2008-03-12 11:02:57 -0600 (Wed, 12 Mar 2008) | 12 lines

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

........
r108031 | russell | 2008-03-12 11:59:07 -0500 (Wed, 12 Mar 2008) | 4 lines

Destroy the channel lock after the channel datastores.

(inspired by issue ASTERISK-11617)

........

................
r108034 | russell | 2008-03-12 11:06:37 -0600 (Wed, 12 Mar 2008) | 4 lines

- Add Tilghman to the copyright info ... he wrote the hard part :)
- Remove some magic in unload_module that isn't needed.  Module use counts
  already ensure that the function isn't going to be in use at this point.

................
r108084 | file | 2008-03-12 12:29:33 -0600 (Wed, 12 Mar 2008) | 12 lines

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

........
r108083 | file | 2008-03-12 15:26:37 -0300 (Wed, 12 Mar 2008) | 4 lines

Add a trigger mode that triggers on both read and write. The actual function that returns the combined audio frame though will wait until both sides have fed in audio, or until one side stops (such as the case when you call Wait).
(closes issue ASTERISK-11394)
Reported by: xheliox

........

................
r108137 | russell | 2008-03-12 13:59:05 -0600 (Wed, 12 Mar 2008) | 50 lines

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

........
r108135 | russell | 2008-03-12 14:57:42 -0500 (Wed, 12 Mar 2008) | 40 lines

(closes issue ASTERISK-11617, reported by atis, fixed by me after some brainstorming
on the issue with mmichelson)

- Update copyright info on app_chanspy.

- Fix a race condition that caused app_chanspy to crash.  The issue was that
 the chanspy datastore magic that was used to ensure that spyee channels did
 not disappear out from under the code did not completely solve the problem.
 It was actually possible for chanspy to acquire a channel reference out of
 its datastore to a channel that was in the middle of being destroyed.  That
 was because datastore destruction in ast_channel_free() was done near the
 end.  So, this left the code in app_chanspy accessing a channel that was
 partially, or completely invalid because it was in the process of being free'd
 by another thread.  The following sort of shows the code path where the race
 occurred:

 =============================================================================
 Thread 1 (PBX thread for spyee chan)  ||   Thread 2 (chanspy)
 --------------------------------------||-------------------------------------
 ast_channel_free()                    ||
   - remove channel from channel list  ||
   - lock/unlock the channel to ensure ||
     that no references retrieved from ||
     the channel list exist.           ||
 --------------------------------------||-------------------------------------
                                       || channel_spy()
   - destroy some channel data         ||  - Lock chanspy datastore
                                       ||  - Retrieve reference to channel
                                       ||  - lock channel
                                       ||  - Unlock chanspy datastore
 --------------------------------------||-------------------------------------
    - destroy channel datastores       ||
       - call chanspy datastore d'tor  ||  
         which NULL's out the ds'      ||  - Operate on the channel ...
         reference to the channel      ||    
                                       ||
   - free the channel                  ||
                                       ||
                                       ||  - unlock the channel
 --------------------------------------||-------------------------------------
 =============================================================================

........

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

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

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