MixMonitor not recording with Opus

[arthurpro]

Recently compiled Asterisk 11.17 with this patch.
The codec itself works great, no issues so far.
However, when MixMonitor starts recording my outgoing calls when I'm using Opus codec the recorded .wav file appears to be empty.
When I'm making calls with any other codec the recordings are ok.
What can be wrong with Opus?

[lminiero]

Not sure how MixMonitor is used with Dial (assuming you're recording regular calls, right?), maybe it creates a fake "call"/channel to do Opus->slin transcoding? It appears to be working fine when we use it with ConfBridge, but in that case the media MixMonitor is receiving from the bridge is plain sln16 so easy to manage.

[arthurpro]

I'm debugging MixMonitor and Opus now.
On outgoing calls I have the following

  == Begin MixMonitor Recording SIP/alex-000000a0
    -- SIP/gv15xxxx-000000a1 is ringing
    -- SIP/gv15xxxx-000000a1 is making progress passing it to SIP/alex-000000a0
    -- SIP/gv15xxxx-000000a1 answered SIP/alex-000000a0
[Opus] Created decoder #86 (opus->48000)
[Opus] Created encoder #715 (48000->opus)

On incoming calls I have the following:

== Begin MixMonitor Recording SIP/127.0.0.1-000000a6
  == Using SIP RTP CoS mark 5
    -- Called SIP/arthur
    -- SIP/arthur-000000a7 is ringing
    -- SIP/arthur-000000a7 is ringing
    -- SIP/arthur-000000a7 is ringing
[Opus] Created decoder #93 (opus->8000)
[Opus] Created encoder #718 (8000->opus)

You should see the difference.
On outgoing transcoding is opus<->48000
On incoming it's opus<->8000 (originated from outside via trunk)
So I guess MixMonitor cannot deal with 48000

[arthurpro]

and 48000 and 8000 is a sampling rate according to the source code

[arthurpro]

After extensive debugging I found out that MixMonitor cannot be used for call recording of calls when caller uses Opus with sample rate other than 8000 if you start MixMonitor before the call has been connected.
MixMonitor is an Asterisk application.
On the other hand Monitor works because it creates additional instance of Opus decoder to decode and resample channel audio. And Monitor is an Asterisk resource, not application.
So I suppose in this case Monitor solves the problem.

[bennnjamin]

@lminiero I've also been doing some testing with ConfBridge and MixMonitor as well. Do you know why MixMonitor receives slin16 audio? I have specified a ConfBridge sample rate of 48kHz and an output file of .slin48 yet the resulting file is still slin16 audio when I analyze it using a spectrogram. If I can narrow down the issue I may try to fix it or put in a request to have it fixed in Asterisk.

[lminiero]

IIRC it depends on what you use as the MixMonitor target. If you specify a .wav filename, you'll get a narrowband (8khz) file. If you ask for a .wav16 file, you'll get a wideband (16khz) recording. So it's MixMonitor that asks for lower sampling rates according to what it requires, and the Opus codec just reacts accordingly.

[bennnjamin]

Interesting. I have been specifying .slin48 for a 48kHz file yet the resulting recording is never any higher than 16kHz. I've done some research on Asterisk issues and the source code and from what I can tell MixMonitor just uses the sample rate of the specified file format however the issue may be deeper (audiohook.c maybe) in that Asterisk may not support 48kHz internally. The initial fix for MixMonitor here https://reviewboard.asterisk.org/r/1314/ was not tested thoroughly as the author used a qualitative test (the audio sounds betters) versus a quantitative test (frequency domain analysis).

I understand this is getting out of the scope of the Opus codec but I would like to thank you for what you've done with this patch. I really appreciate it.

[lminiero]

Thanks for your kind words!