Opus: decoding: buffer too small

Asterisk Asterisk Support
1

I am using Opus codec 48kHz when calling into a confbrige and I often get Opus: decoding: buffer too small, accompanied by audio distortion

What does that mean and what do I need to do to change this?

[musicbridge]
type=bridge
max_members=20
mixing_interval=10
internal_sample_rate=48000
video_mode=first_marked

[musicuser]
type=user
denoise=no
dsp_drop_silence=no
dtmf_passthrough=no
jitterbuffer=no
quiet=yes
startmuted=no
talk_detection_events=no

[opus]
type=opus
bitrate=512000
signal=music
application=low_delay
cbr=yes
1 Like
2

My guess as to why you are seeing the error is that the buffer to hold the decoded audio is not large enough to hold it all. Now as to why that is happening I’m not entirely sure.

Using the settings you specified I ran a scenario where I had two calls call into the confbridge and did not see the error. Can you give more information about the scenario you are running and when you first see the error?

For instance, does it happen after 2 calls are added, 5, etc…? What’s the most simple case you can run where it happens. As well does it happen every time? Please also also post a SIP trace of the negotiation that takes place between Asterisk and the endpoint in question.

1 Like
3

I think the OP is the person who has been asking about setting very high bit rates and I seem to remember them saying something about the peer accepting them. Given that the 512kbs is more than the absolute maximum bit rate of of 510kbs, for Opus (and a lot more than the recommended maximum rate for mono audio), my guess is the peer is actually sending at that rate and overwhelming a system that can only cope with in specification bit rates.

(It’s also possible that Asterisk is requesting a lower bit rate in the SDP and the peer is ignoring it.)

2 Likes
4

I have found that when mixing_interval=10 is set, audio breaks down when a 3rd party calls into the conference. Two is fine, but as soon as the 3rd party calls in, audio destorts immediately. (If Opus is being used, if 3rd party calls in using a different codec, audio remains fine).

This I can replicate each time. When I comment out the mixing_interval=10, the problem doesn’t happen.

This is the SIP trace from the 3rd party calling into the confbridge, right before audio destortion occurs:

<--- SIP read from UDP:192.168.1.254:38768 --->
INVITE sip:5915@10.1.1.178;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.1.254:38768;branch=z9hG4bK-524287-1---e261f3a97a37d07f;rport
Max-Forwards: 70
Contact: <sip:5319@192.168.1.254:38768;transport=UDP>
To: <sip:5915@10.1.1.178;transport=UDP>
From: <sip:5319@10.1.1.178;transport=UDP>;tag=327f1109
Call-ID: w6jxGmgoUyCZhA4r4RVQMA..
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Content-Type: application/sdp
User-Agent: Z 5.2.28 rv2.8.115
Allow-Events: presence, kpml, talk
Content-Length: 264

v=0
o=Z 478315223 0 IN IP4 10.40.0.84
s=Z
c=IN IP4 10.40.0.84
t=0 0
m=audio 8000 RTP/AVP 106 98
a=rtpmap:106 opus/48000/2
a=fmtp:106 minptime=20; cbr=1; maxaveragebitrate=40000; useinbandfec=1
a=rtpmap:98 telephone-event/48000
a=fmtp:98 0-16
a=sendrecv
<------------->
--- (13 headers 11 lines) ---
Sending to 192.168.1.254:38768 (NAT)
Sending to 192.168.1.254:38768 (NAT)
Using INVITE request as basis request - w6jxGmgoUyCZhA4r4RVQMA..
Found peer '5319' for '5319' from 192.168.1.254:38768

<--- Reliably Transmitting (NAT) to 192.168.1.254:38768 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.254:38768;branch=z9hG4bK-524287-1---e261f3a97a37d07f;received=192.168.1.254;rport=38768
From: <sip:5319@10.1.1.178;transport=UDP>;tag=327f1109
To: <sip:5915@10.1.1.178;transport=UDP>;tag=as1869acaf
Call-ID: w6jxGmgoUyCZhA4r4RVQMA..
CSeq: 1 INVITE
Server: FPBX-13.0.195.4(13.18.3)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="6c6ba1f2"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog 'w6jxGmgoUyCZhA4r4RVQMA..' in 32000 ms (Method: INVITE)

<--- SIP read from UDP:192.168.1.254:38768 --->
ACK sip:5915@10.1.1.178;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.1.254:38768;branch=z9hG4bK-524287-1---e261f3a97a37d07f;rport
Max-Forwards: 70
To: <sip:5915@10.1.1.178;transport=UDP>;tag=as1869acaf
From: <sip:5319@10.1.1.178;transport=UDP>;tag=327f1109
Call-ID: w6jxGmgoUyCZhA4r4RVQMA..
CSeq: 1 ACK
Content-Length: 0

<------------->
--- (8 headers 0 lines) ---

<--- SIP read from UDP:192.168.1.254:38768 --->
INVITE sip:5915@10.1.1.178;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.1.254:38768;branch=z9hG4bK-524287-1---ee94496fc7c37539;rport
Max-Forwards: 70
Contact: <sip:5319@192.168.1.254:38768;transport=UDP>
To: <sip:5915@10.1.1.178;transport=UDP>
From: <sip:5319@10.1.1.178;transport=UDP>;tag=327f1109
Call-ID: w6jxGmgoUyCZhA4r4RVQMA..
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Content-Type: application/sdp
User-Agent: Z 5.2.28 rv2.8.115
Authorization: Digest username="5319",realm="asterisk",nonce="6c6ba1f2",uri="sip:5915@10.1.1.178;transport=UDP",response="4e4205df257c0b46128b4bdbd79eb9c9",algorithm=MD5
Allow-Events: presence, kpml, talk
Content-Length: 264

v=0
o=Z 478315223 0 IN IP4 10.40.0.84
s=Z
c=IN IP4 10.40.0.84
t=0 0
m=audio 8000 RTP/AVP 106 98
a=rtpmap:106 opus/48000/2
a=fmtp:106 minptime=20; cbr=1; maxaveragebitrate=40000; useinbandfec=1
a=rtpmap:98 telephone-event/48000
a=fmtp:98 0-16
a=sendrecv
<------------->
--- (14 headers 11 lines) ---
Sending to 192.168.1.254:38768 (NAT)
Using INVITE request as basis request - w6jxGmgoUyCZhA4r4RVQMA..
Found peer '5319' for '5319' from 192.168.1.254:38768
Found RTP audio format 106
Found RTP audio format 98
Found audio description format opus for ID 106
Found unknown media description format telephone-event for ID 98
Capabilities: us - (g722|ulaw|g729|opus|h264|mpeg4|vp8), peer - audio=(opus)/video=(nothing)/text=(nothing), combined - (opus)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x0 (nothing), combined - 0x0 (nothing)
Peer audio RTP is at port 10.40.0.84:8000
Peer doesn't provide video
Looking for 5915 in from-internal (domain 10.1.1.178)
sip_route_dump: route/path hop: <sip:5319@192.168.1.254:38768;transport=UDP>

<--- Transmitting (NAT) to 192.168.1.254:38768 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.254:38768;branch=z9hG4bK-524287-1---ee94496fc7c37539;received=192.168.1.254;rport=38768
From: <sip:5319@10.1.1.178;transport=UDP>;tag=327f1109
To: <sip:5915@10.1.1.178;transport=UDP>
Call-ID: w6jxGmgoUyCZhA4r4RVQMA..
CSeq: 2 INVITE
Server: FPBX-13.0.195.4(13.18.3)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:5915@10.1.1.178:5060>
Content-Length: 0


<------------>
Audio is at 19418
Adding codec opus to SDP

<--- Reliably Transmitting (NAT) to 192.168.1.254:38768 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.254:38768;branch=z9hG4bK-524287-1---ee94496fc7c37539;received=192.168.1.254;rport=38768
From: <sip:5319@10.1.1.178;transport=UDP>;tag=327f1109
To: <sip:5915@10.1.1.178;transport=UDP>;tag=as2c3dfeb2
Call-ID: w6jxGmgoUyCZhA4r4RVQMA..
CSeq: 2 INVITE
Server: FPBX-13.0.195.4(13.18.3)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:5915@10.1.1.178:5060>
Content-Type: application/sdp
Content-Length: 241

v=0
o=root 676310438 676310438 IN IP4 10.1.1.178
s=Asterisk PBX 13.18.3
c=IN IP4 10.1.1.178
t=0 0
m=audio 19418 RTP/AVP 106
a=rtpmap:106 opus/48000/2
a=fmtp:106 maxaveragebitrate=40000;cbr=1;useinbandfec=1
a=maxptime:20
a=sendrecv

<------------>

<--- SIP read from UDP:192.168.1.254:38768 --->
ACK sip:5915@10.1.1.178:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.254:38768;branch=z9hG4bK-524287-1---b715da7971ecf63e;rport
Max-Forwards: 70
Contact: <sip:5319@192.168.1.254:38768;transport=UDP>
To: <sip:5915@10.1.1.178;transport=UDP>;tag=as2c3dfeb2
From: <sip:5319@10.1.1.178;transport=UDP>;tag=327f1109
Call-ID: w6jxGmgoUyCZhA4r4RVQMA..
CSeq: 2 ACK
User-Agent: Z 5.2.28 rv2.8.115
Content-Length: 0

The bitrates are around 65kb/s in each direction.

Linphone, one of the soft clients I am using allows the upload bitrate to be set to higher rates, I have also tried that and I can see it get up to 200kb/s, but the problem above occurs independent of the bitrate I set, at least on the client side.
Bitrate from Asterisk is constant at around 60 to 65 kb/s.

5

I am still unable to duplicate this unfortunately.

I’m not entirely familiar with what the mixing_interval does (would have to look closer at the code). I suspect if it’s creating (mixing) signed linear audio frames with a size based on that number, and those get passed to the codec translation core it could maybe cause a problem with opus.

The opus codec module for Asterisk likes a ptime set to 20, so there could be a frame size mismatch here between the underlying expected frame sizes.

I didn’t see the same error per se, but bumping the mixing_interval higher than 20 for me resulted in a “Out of buffer space” being reported from the translation core (which fits with what I was saying above). Going lower didn’t because the incoming data would be smaller in that case, so would fit in the buffer space. So somewhat different, but could be similar going on?

I’d suggest just leaving the mixing_interval at 20 if you are able as it seems to not cause the problem.

1 Like
6

The setting bitrate=512000 I got from the asterisk wiki on opus:
https://wiki.asterisk.org/wiki/display/AST/Codec+Opus

So if the maximum Opus bitrate is only 510000, maybe that needs correction on the wiki.

7

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