# Error recording using mixMonitor

**URL:** <https://community.asterisk.org/t/error-recording-using-mixmonitor/103948>\
**Category:** Asterisk Support\
**Created:** [August 19, 2024, 2:45am UTC](https://community.asterisk.org/t/error-recording-using-mixmonitor/103948 "2024-08-19T02:45:22Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![fish\_cat](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/fish_cat/32/8862_2.png) [@fish\_cat](https://community.asterisk.org/u/fish_cat)\
**Post date:** [August 19, 2024, 2:45am UTC](https://community.asterisk.org/t/error-recording-using-mixmonitor/103948/1 "2024-08-19T02:45:22Z")

</div>

Hi all,  
asterisk verison: Asterisk 20.9.1  
Problems with recording audio using mixMonitor: the recorded files are the same size, and passing two parameters will cause t to have no sound, or r to have no sound  
The execution plan is as follows：

s,n,MixMonitor(abcd.wav,r(abcd\_in.wav)t(abcd\_out.wav))  
Three files of the same size, there is no implementation of recording the received and played out results, what is wrong with my configuration

Or the following configuration is also problematic  
s,n,MixMonitor(abcd.wav,r(abcd\_in.wav))  
s,n,MixMonitor(abcd.wav,t(abcd\_out.wav))

Can anyone help or put me in the right direction?

Thanks

---

<div class="post-metadata">

**Author:** ![penguinpbx](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/penguinpbx/32/8856_2.png) [@penguinpbx](https://community.asterisk.org/u/penguinpbx)\
**Post date:** [September 12, 2024, 2:01pm UTC](https://community.asterisk.org/t/error-recording-using-mixmonitor/103948/2 "2024-09-12T14:01:14Z")

</div>

> [@fish\_cat](#):
>
> the recorded files are the same size

That is (generally) okay for wav files because they grow in size linearly with time.

Specifically, it holds true for MixMonitor() because all the “meta” stuff is the same - same encoding, same metadata, etc. The only thing that is different is the content. But for wav files, even recording silence is recording something. So, a file 10 seconds long full of “nothing” is the same size as 10 seconds of conversation.

Did you analyze all the way through to the end of file using something like [Audacity](https://www.audacityteam.org) ? Were you able to confirm there was actually somebody talking/singing/etc. on the call ?

> [@fish\_cat](#):
>
> t to have no sound, or r to have no sound

But the abcd.wav file does have sound ? So something like this works:

`exten = s,n,MixMonitor(abcd.wav)`

?

---

<div class="post-metadata">

**Author:** ![fish\_cat](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/fish_cat/32/8862_2.png) [@fish\_cat](https://community.asterisk.org/u/fish_cat)\
**Post date:** [September 13, 2024, 1:09am UTC](https://community.asterisk.org/t/error-recording-using-mixmonitor/103948/3 "2024-09-13T01:09:54Z")

</div>

same =\> n,MixMonitor(abcd.wav,r(abcd\_in.wav)t(abcd\_out.wav))  
The desired result should be:  
1: abcd.wav result should record the voices of both parties to the call;  
2: abcd\_in.wav results should be the voice of the called party (including the silence duration);  
3: abcd\_out.wav results should be only the sound emitted by the call including the silence duration);  
But it didn’t turn out the way I wanted

I am now using same =\> n,MixMonitor(,r(${aaa}.wav))  
can record only the audio of the other party,

exten = s,n,MixMonitor(abcd.wav)  
Able to record both voices

---

<div class="post-metadata">

**Author:** ![david551](https://avatars.discourse-cdn.com/v4/letter/d/3bc359/32.png) [@david551](https://community.asterisk.org/u/david551)\
**Post date:** [September 13, 2024, 11:22am UTC](https://community.asterisk.org/t/error-recording-using-mixmonitor/103948/4 "2024-09-13T11:22:59Z")

</div>

> [@penguinpbx](#):
>
> The only thing that is different is the content. But for wav files, even recording silence is recording something.

My impression was that Asterisk did not append to the file except when a frame was received, and I don’t think it fakes frames to fill the gap.

There is a difference between silence and a lack of media.

---

<div class="post-metadata">

**Author:** ![penguinpbx](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/penguinpbx/32/8856_2.png) [@penguinpbx](https://community.asterisk.org/u/penguinpbx)\
**Post date:** [September 13, 2024, 1:58pm UTC](https://community.asterisk.org/t/error-recording-using-mixmonitor/103948/5 "2024-09-13T13:58:17Z")

</div>

> [@david551](#):
>
> There is a difference between silence and a lack of media.

Agreed. Should have added to the general answer: wav files will be the same size over a given length of time as long as audio is being received and written to the file, even if the sounds are so quiet that they might sound silent.

And perhaps a better wav size-to-length analogy would be that of a magnetic cassette tape recorder - one hour of ambient nearly-silent nothingness would be the same physical length of tape as one hour of a rock and roll concert. 🎸

But for [MixMonitor](https://docs.asterisk.org/Latest_API/API_Documentation/Dialplan_Applications/MixMonitor/) specifically, things can be a little different, depending on the options used, for example the ‘n’ option:

> `n` - When the _r_ or _t_ option is used, MixMonitor will insert silence into the specified files to maintain synchronization between them. Use this option to disable that behavior.

There’s been some back-and-forth on this option – it started as ‘S’ in 2019 with Asterisk 18 and was _not on by default_:

> <https://github.com/asterisk/asterisk/commit/64906c4c9ba63e18f2c71310fdbf14450dac7b62>
>
> There are 4 scenarios to consider when capturing audio from a channel
> with an au…diohook:
> 
> 1. There is no rx and no tx audio, so return nothing.
> 2. There is rx but no tx audio, so return rx.
> 3. There is tx but no rx audio, so return tx.
> 4. There is rx and tx audio, so mix them and return.
> 
> The file passed as the primary argument to MixMonitor will be written to
> in scenarios 2, 3, and 4. However, if you pass the r() and t() options
> to MixMonitor, a frame will only be written to the r() file if there was
> rx audio and a frame will only be written to the t() file if there was
> tx audio.
> 
> If you subsequently take the r() and t() files and try to mix them, the
> sides of the conversation will 'drift' and be non-representative of the
> user experience.
> 
> This patch adds a new 'S' option to MixMonitor that injects a frame of
> silence on either the r() side or the t() side of the channel so that
> when later mixed, there is no such drift.
> 
> Change-Id: Ibf5ed73a811087727bd561a89a59f4447b4ee20e

But then it changed to active silence injection when ‘S’ was deprecated in favor of ‘n’ a year or so later:

> <https://github.com/asterisk/asterisk/commit/999fdef335ea9736c99f866ad965e04f7b3389ac>

Anyhow, that probably doesn’t help OP much. Something does seem buggy, though, as this _should_ work (but didn’t test it yet):

> [@fish\_cat](#):
>
> s,n,MixMonitor(abcd.wav,r(abcd\_in.wav)t(abcd\_out.wav))

OP you might want to try an earlier version of Asterisk 20, post some (privacy scrubbed) logs, trace the call and analyze packets in Wireshark, check the wav files in Audacity, etc.

---

<div class="post-metadata">

**Author:** ![david551](https://avatars.discourse-cdn.com/v4/letter/d/3bc359/32.png) [@david551](https://community.asterisk.org/u/david551)\
**Post date:** [September 13, 2024, 2:57pm UTC](https://community.asterisk.org/t/error-recording-using-mixmonitor/103948/6 "2024-09-13T14:57:36Z")

</div>

My guess would be that it only back fills missing frames when the next real frame arrives, a I think it relies on the frame arrival to schedule processing.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/asterisk/original/2X/4/475d0c889911cfb84ac4881ad6df8b523e3f9105.png) [@system](https://community.asterisk.org/u/system)\
**Post date:** [October 13, 2024, 2:58pm UTC](https://community.asterisk.org/t/error-recording-using-mixmonitor/103948/7 "2024-10-13T14:58:11Z")

</div>

Closed on October 13, 2024, 2:58pm UTC

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
