Bridge sample rate downgrade problem (resampled to 8000Hz or 8kHz)s

Asterisk Asterisk Support
1

Asterisk version 18.13.0

Question:
Is there a way to prevent sample rate downgrading when bridging multiple channels that are muted.

Summary:
I’m trying to setup a softmix bridge (or holding bridge) using the ARI where there’s only one announcer and multiple participants (listeners). The problem I’m having is that the audio is downgraded to 8kHz when muting the channels (even when using the same codec which supports higher sampling rates).

Scenarios
The following assumes there are more than two endpoints, all endpoints are using the same codec (i.e. Opus) and have been created/originated and bridged using the ARI. Opus should be mixed using SLIN48.

Scenario 1 (works but not for my application):
If I originate a channel to each endpoint and add them to a softmix bridge, they will work as expected. However, I only want audio from the announcer and this will mix the audio from all endpoints.

Scenario 2 (downgraded):
If I originate a channel to each endpoint but mute them when adding them to the softmix bridge, the participant endpoints will have their audio down-sampled to 8kHz before being re-sampled back to 48kHz.

Scenario 3 (downgraded):
If I originate a channel to each endpoint, add them to the softmix bridge and then mute them within 2 seconds of being added to the bridge, the audio is down-sampled to 8kHz before being re-sampled back to 48kHz.

Scenario 4 (works but not for my application):
If I originate a channel to each endpoint, add them to the softmix bridge and then mute them 3 or more seconds after they were added to the bridge, the audio is the desired 48kHz sampling rate with no degradation. However, I will get audio from the endpoints mixed together during the beginning of the call when the channels are added to the bridge.

Scenario 5 (downgraded):
If I originate a channel to each endpoint, add them to a holding bridge and specify one as the announcer, the audio is down-sampled to 8kHz before being re-sampled back to 48kHz.

Note: All scenarios above work if only two endpoints are used

I have looked at the confbridge options but they seem to apply specifically to conference bridges which I don’t believe apply to bridges created on-the-fly via the ARI.

2

I’ve confirmed that disabling/suspending native_rtp doesn’t have any impact on the aforementioned behaviour by using the command: bridge technology suspend native_rtp

The normal bridge technology changes are: simple_bridge → native_rtp → softmix

Interestingly, when I disable native_rtp, and bridge three channels, it becomes: simple bridge → softmix → simple_bridge → softmix

This could be unrelated.

3

Given that 8khz is pretty much the standard for telephony; I think this is likely a limitation of softmix.

Opus is an odd codec…it only supports 48khz sample rate.

4

@dewdude, thanks for the response.

I’ve also tried g722 (G.722) but I was informed by someone on the IRC channel that there could be a legacy issue with that codec incorrectly being down-sampled to 8k (instead of using the native 16kHz) so I decided to use Opus for my testing to eliminate that as a possibility.

What I don’t understand is that if I don’t mute the audio channels, it works as expected. But, as soon as I try muting the channels when adding them to the bridge, that’s when it messes up. Also, using a holding bridge has the same effect (i.e. down-sampled).

5

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