Summary: | ASTERISK-19727: MixMonitor does not work on local channels | ||||||
Reporter: | Mark Murawski (kobaz) | Labels: | |||||
Date Opened: | 2012-04-15 13:41:35 | Date Closed: | 2012-04-27 14:28:19 | ||||
Priority: | Minor | Regression? | |||||
Status: | Closed/Complete | Components: | Applications/app_mixmonitor | ||||
Versions: | SVN 1.8.11.0 | Frequency of Occurrence | Constant | ||||
Related Issues: |
| ||||||
Environment: | Attachments: | ( 0) 32-bit-time-overflow-2012-04-27.diff ( 1) ASTERISK-19727-2012-04-26.diff ( 2) mixmonitor_debug_trunk.txt ( 3) scrollback-kobaz-1BUC | |||||
Description: | I don't recall which version this used to work on, but it doesn't on 1.8-svn r362145 context services { 7060 => { Answer(); MeetMe(112,d); } 8070 => { Answer(); MeetMe(112,d); } 8080 => { Answer(); MixMonitor(${UNIQUEID}.WAV); Wait(1000); } } [2012-04-15 14:34:36] -- <SIP/6200-00000000> Executing [7060@services:2] MeetMe(112,d) [2012-04-15 14:34:39] -- <SIP/6850-00000001> Executing [7060@services:2] MeetMe(112,d) channel originate Local/8070@services extension 8080@services [2012-04-15 14:35:12] -- <Local/8070@services-6301;2> Executing [8070@services:1] Answer() [2012-04-15 14:35:12] -- <Local/8070@services-6301;1> Executing [8080@services:1] Answer() [2012-04-15 14:35:12] -- <Local/8070@services-6301;1> Executing [8080@services:2] MixMonitor(1334514912.3.WAV) [2012-04-15 14:35:12] -- <Local/8070@services-6301;1> Executing [8080@services:3] Wait(1000) [2012-04-15 14:35:12] == <Local/8070@services-6301;1> Begin MixMonitor Recording: /var/spool/asterisk/monitor/1334514912.3.WAV [2012-04-15 14:35:12] -- <Local/8070@services-6301;2> Executing [8070@services:2] MeetMe(112,d) # ls -al /var/spool/asterisk/monitor/1334514912.3.WAV ls: cannot access /var/spool/asterisk/monitor/1334514912.3.WAV: No such file or directory Using Monitor() in the same fashion does work. I did some poking around and MixMonitor gets hung up in mixmonitor_thread doing if (!(fr = ast_audiohook_read_frame(&mixmonitor->audiohook, SAMPLES_PER_FRAME, AST_AUDIOHOOK_DIRECTION_BOTH, AST_FORMAT_SLINEAR))) { fr is always null, MixMonitor never gets a frame when using a local channel. MixMonitor in this fashion works fine: MixMonitor(${UNIQUEID}.WAV); Dial(SIP/6881); | ||||||
Comments: | By: Matt Jordan (mjordan) 2012-04-20 12:48:44.506-0500 Mark: I set up a similar test and wasn't able to reproduce this. Do you mind attaching a DEBUG log? I'm curious to see if it looks similar to some of the other MixMonitor related issues as well. Thanks Matt By: Mark Murawski (kobaz) 2012-04-20 13:18:12.067-0500 debug log By: Mark Murawski (kobaz) 2012-04-20 13:24:20.082-0500 If you want access to the box in question, I can set that up for you. By: Matt Jordan (mjordan) 2012-04-26 11:16:37.354-0500 Mark - I've attached a patch (ASTERISK-19727-2012-04-26) for 1.8 that may fix this problem, although it contains a bunch of debug stuff, and is *not* the correct solution. Its mostly just to verify that what I think is happening is actually happening. Let me know what happens with this one - the extra DEBUG stuff should help clarify exactly what the audiohook is doing if it chooses to ignore samples from the read/write factories. Matt By: Michael L. Young (elguero) 2012-04-27 09:56:23.779-0500 I applied your patch to a 32 bit machine running trunk since I am curious as to what is going on as well. I had to make two changes to the debug string format placeholders, write_diff and read_diff needed %lld since they are int64_t. I have things setup like what was mentioned in a comment in the related issue, ASTERISK-19426, https://issues.asterisk.org/jira/browse/ASTERISK-19426?focusedCommentId=189761&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-189761. I will attach some of the debug info. Hope this helps in tracking down the issue. By: Matt Jordan (mjordan) 2012-04-27 10:30:09 Mark/Michael: Yeah, that patch might have trouble compiling due to machine dependent interpretations as to what an int64_t actually is. That patch was merely to confirm the behavior that was happening - (I posted a long description of it on ASTERISK-19497) - I've attached a patch that should fix this for 1.8 on this issue. Matt By: Matt Jordan (mjordan) 2012-04-27 10:30:40.269-0500 I should note - the patch that fixes the root cause of the problem is 32-bit-time-overflow-2012-04-27.diff. By: Michael L. Young (elguero) 2012-04-27 14:03:02.428-0500 I can confirm that the patch appears to solve the problem. It is great when things work out "positively" instead of "negatively" :) The times are now positive numbers and the recording is created with audio being written to it. By: Mark Murawski (kobaz) 2012-05-02 09:34:47.202-0500 Confirmed fixed for me too. |