Hi all,
What would cause the audio file to become inaudible when using the “D” flag with mixmonitor (asterisk 20.14.1), please see the dialplan below and attached audio file. I also see the file is still recorded in mono
Dialplan:
exten => s,n,MixMonitor(${FILE_NAME},D)
soxi output:
Input File : ‘/var/spool/asterisk/monitor/pbx01-1750400511.59-E1750400512R1560064782.WAV’
Channels : 1
Sample Rate : 8000
Precision : 16-bit
Duration : 00:00:29.16 = 233280 samples ~ 2187 CDDA sectors
File Size : 47.4k
Bit Rate : 13.0k
Sample Encoding: GSM
Audio File:
I can’t seem to upload the WAV but will be made available on request via GDrive link or alternate means
jcolp
June 20, 2025, 8:13am
2
opened 03:59PM - 12 Jun 25 UTC
bug
support-level-core
### Severity
Minor
### Versions
22.4.1
### Components/Modules
MixMonitor
#… ## Operating Environment
Linux, x86_64, Fedora 42, Asterisk 22.4.1 built from sources locally
### Frequency of Occurrence
Constant
### Issue Description
The new 'D' option for MixMonitor, which is supposed to produce interleaved stereo raw files, sounds great in theory, but unfortunately it produces corrupt files in practice. The files, when processed (e.g. imported into Audacity, or converted by ffmpeg, as 2 channel, 8 kHz alaw raw files) are half as long as they should be and the sound is garbled, clipped, too fast. Looking at the waveforms and the code in app_mixmonitor.c, it appears that the latter half of each frame is not written to the file.
```
short stereo_buf[SAMPLES_PER_FRAME * 2];
struct ast_frame stereo_frame = {
.frametype = AST_FRAME_VOICE,
.datalen = sizeof(stereo_buf),
.samples = SAMPLES_PER_FRAME,
};
```
Given that in this mode the file pretends to be a single channel output that contains samples from both actual channels, shouldn't that be `.samples = SAMPLES_PER_FRAME * 2`? (Or perhaps it's not that simple and two fake frames of interleaved content should be constructed for each pair of incoming read and write frames?)
I rate this bug as not particularly severe, because existing functionality is not affected. Without the 'D' option the application works as before, and the 't' and 'r' options (and the separate files created by them) are also fine. But the new interleaved mode is unusable in its current implementation.
I can provide sample files if requested.
### Relevant log output
```shell
```
### Asterisk Issue Guidelines
- [x] Yes, I have read the Asterisk Issue Guidelines
It only supports .raw files currently.
It is in the documentation, but the documentation site isn’t pulling it out - so we’ll be fixing it so it does show up.
This is probably a noob questions but I’m going cross-eyed, am I missing something?
jcolp
June 20, 2025, 11:00am
5
Is the format_sln module loaded?
jcolp
June 20, 2025, 11:09am
7
What does “core show file formats” show? If you use “sln” instead for the file extension does it work?
I restarted asterisk (must have done something goofy on my side), but it works with .raw now
Still getting “corrupt” audio though with .raw and with .sln using the “D” flag
Archive.zip (365.3 KB)
jcolp
June 20, 2025, 11:23am
10
And what does it sound like without using the “D” option?
jcolp
June 20, 2025, 11:27am
11
And what are the complete options you are giving to MixMonitor? The image is small and I can’t make things out completely. (Sharing images is not great for this reason, text is preferred)
Here’s the sln without the “D” option, audio is clear
pbx01-1750418871.94-E1750418872R672825345.sln.zip (150.9 KB)
Apologies, the full text is:
MixMonitor(pbx01-1750418871.94-E1750418872R672825345.sln,a) - Audio is clear
MixMonitor(pbx01-1750418871.94-E1750418872R672825345.sln,aD) - Audio is corrupt