[asterisk-dev] Opus and VP8

Wed May 29 09:18:44 CDT 2013

Hi James,

I've added some comments inline.

2013/5/28 James Mortensen <james.mortensen at voicecurve.com>

> Hi Lorenzo,
>
> Not trying to hijack the thread, but Andrea appears to be away for the
> next few days, and I'm experiencing the same exact problem with the audio
> issues and want to help move us both forward.  So I can answer the
> questions below to get you more data. Please see below:
>
>
> [May 28 11:17:40] DEBUG[16613][C-00000000] channel.c: Scheduling timer at
>> (50 requested / 50 actual) timer tic
>>
>>
>>> That said, I'm not sure what the cause of the issue could be. What ptime
>>> are the two peers using?
>>> What is the transcoding path
>>> as displayed on the Asterisk console? Does the same happen in other
>>> scenarios as well, e.g., the browser interacting with another
>>> browser, or a softphone using a different codec (e.g., speex) at
>>> different rates (e.g., 16kHz vs 8kHz)?
>>>
>>
>> now I'm out of office I will be able to provide this info
>> only on Thursaday.
>>
>>
> I assume the ptime is this maxptime value we see in the SDP from the
> Chrome to Asterisk call leg:
>
> a=rtpmap:111 opus/48000/2
> a=maxptime:60
> a=fmtp:111 maxplaybackrate=16000; stereo=0; sprop-stereo=0; useinbandfec=0
>
> If that's not the ptime, please let me know where I might find that and
> I'll get it for you.
>
>
By ptime I mean how many milliseconds of audio are contained in a single
RTP packet. Usually this is 20ms for most codecs but that's not always the
case: Opus, for instance, supports a wide range of different ones, which is
why in the SDP we report that the maximum ptime that is supported in the
implementation is 60ms.

The Asterisk codec encoding/decoding infrastructure should already
transparently take care of this, considering that when encoding and
decoding you always know how many samples are involved, but I didn't test
this intensively, and so a difference in how the two "legs" do this (e.g.,
20 ms for the Opus leg, 10 ms for the G.729 leg) may in some cases cause
hiccups.

> And here you can see the call leg from the Chrome to Asterisk portion of
> the call is opus, with the other leg using ulaw.  I've tried with g729 on
> the Bandwidth to Asterisk leg and still hear the same underwater-like call
> audio that Andrea describes.
>
> ip-10-188-135-200*CLI> sip show channels
> Peer             User/ANR         Call ID          Format           Hold
>   Last Message    Expiry     Peer
> 54.X.X.X    1000            55srb9arjvh7rnv  (opus)           No       Rx:
> ACK                    ws-Opensip
> 67.231.X.X     +15036XXXXXX     48c000dd54ba525  (ulaw)           No
> Tx: ACK                    BANDWIDTH
> 2 active SIP dialogs
> ip-10-188-135-200*CLI>
>
>
> Also, here is the output from opus set debug huge:
>
>  [Opus] [Encoder #9 (8000)]   >> Got 960 samples, 18 bytes
> [Opus] [Decoder #12 (8000)] 960 samples, 72 bytes
> [Opus] [Decoder #12 (8000)]   >> Got 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)]   >> Got 960 samples, 20 bytes
> [Opus] [Decoder #12 (8000)] 960 samples, 77 bytes
> [Opus] [Decoder #12 (8000)]   >> Got 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)]   >> Got 960 samples, 19 bytes
> [Opus] [Decoder #12 (8000)] 960 samples, 67 bytes
> [Opus] [Decoder #12 (8000)]   >> Got 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)]   >> Got 960 samples, 17 bytes
> [Opus] [Decoder #12 (8000)] 960 samples, 71 bytes
> [Opus] [Decoder #12 (8000)]   >> Got 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)]   >> Got 960 samples, 21 bytes
> [Opus] [Decoder #12 (8000)] 960 samples, 72 bytes
> [Opus] [Decoder #12 (8000)]   >> Got 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)]   >> Got 960 samples, 21 bytes
> [Opus] [Decoder #12 (8000)] 960 samples, 72 bytes
> [Opus] [Decoder #12 (8000)]   >> Got 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)]   >> Got 960 samples, 23 bytes
> [Opus] [Decoder #12 (8000)] 960 samples, 69 bytes
> [Opus] [Decoder #12 (8000)]   >> Got 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)]   >> Got 960 samples, 19 bytes
> [Opus] [Decoder #12 (8000)] 960 samples, 72 bytes
> [Opus] [Decoder #12 (8000)]   >> Got 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)]   >> Got 960 samples, 21 bytes
> [Opus] [Decoder #12 (8000)] 960 samples, 74 bytes
> [Opus] [Decoder #12 (8000)]   >> Got 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)]   >> Got 960 samples, 23 bytes
> [Opus] [Decoder #12 (8000)] 960 samples, 74 bytes
> [Opus] [Decoder #12 (8000)]   >> Got 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)]   >> Got 960 samples, 21 bytes
> [Opus] [Decoder #12 (8000)] 960 samples, 75 bytes
> [Opus] [Decoder #12 (8000)]   >> Got 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
> [Opus] [Encoder #9 (8000)]   >> Got 960 samples, 25 bytes
>
>
The "huge" debug doesn't seem to report anything wrong: the encoder gets
160 samples in 320 bytes (8kHz slin) and encodes them correctly, and at the
same time the decoder gets 960 samples (as in Opus the reference rate is
always 48kHz) and decodes them to 160 samples/320 bytes (8kHz slin). So
apparently no encoding/decoding error is reported from the library.

What about the transcoding path in Asterisk, though? e.g.

     core show translation paths opus

should tell you how Asterisk is going to take care of the transcoding
between Opus and different codecs.

> Unlike Andrea, who applied the patch to 11.3.0, I successfully applied the
> patch to Asterisk 11.4.0, but the issues we're both experiencing appear to
> be the same. If that's not the case, I can start a new thread.  Hope this
> helps! :)
>
>
I'm not sure how much those two versions of Asterisk differ from each
other, so I'm afraid I cannot answer you with respect to that: anyhow, I
guess that there's no need to open a new thread. But just out of curiosity,
did you try to replicate the same scenarios with Asterisk 11.1.2 as well?
Just to understand whether or not I can focus on the latest changes to
investigate what's wrong in the current Opus implementation.

Lorenzo

-- 
> James Mortensen
> Project Manager, VoiceCurve, Inc.
> 866-707-4590
> james.mortensen at voicecurve.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130529/3a2b598a/attachment-0001.htm>