MixMonitor, is this appending from both channels?

[bkervaski]

Good Morning!

I’m diagnosing an issue where MixMonitor (Asterisk 18.3) is being used to append to a file and noticed this. In the case below, is Asterisk appending audio from both channels to the same file? Or is it muxing and then writing?

I can’t tell from the recording, I guess if it was appending fast enough it wouldn’t be noticeable but if there were lag from one side there would be some jitter like audio.

Thanks for any enlightenment

dev*CLI> mixmonitor list PJSIP/mypeer-0000036b
MixMonitor ID	File	Receive File	Transmit File
=========================================================================
0x7f8c140446d0	1617711171.1494		
0x7f8c240038a0	1617711171.1494		

[jcolp]

This would make it seem as though you have two MixMonitor instances on the same channel recording to the same file.

[bkervaski]

Yep, it’s an edge case and was wondering if MixMonitor was actually appending the audio twice? Or perhaps someone thought of this and it’s only being written once.

[jcolp]

It’d be appending twice most likely. Protecting against this is not something anyone would have done, and certainly not something I see in the code.

[bkervaski]

Okay, thanks for the confirmation, big thanks

[david551]

I think the real answer is that the behaviour is undefined, however, I think it potentially depends on format module used (i.e. the file type). I think the most likely outcome, if both were the same, is that the same date would get written to the same place in file, twice. However, if there were a time skew in when they were started, I’m not sure if the same one would always write second, including the meta data fixup at the end, so I’m not sure if you could end up with different buffers being from different streams.

It doesn’t open in append mode, and I don’t think it can, because that would stop the meta data fixup, so I’d expect both open files to track the file position independently.

I’m not sure how the actual writes are done, but it is quite possible that the write system call is called on units larger than a frame, and possibly not frame aligned, and it is only at the level of the write system call that changes to the underlying file are consolidated.