Audio is crackling

mediasoup libraries
1

Hey everyone,

We are having some problem and I was hoping somebody may have an idea what could be causing it.

We are getting audio with crackling noise from some people.

Is it is almost always only from specific people, but rarely may happen with people who did not have this problem before.

Everybody who is connected to the room hear the same crackling audio, i.e. it is on producer side.

The thing is the same people who consistently producing this noise, do not have this problem when using google hangout.

We are having this problem for quite some time already, but so far have not been able to pin point the issue.

Here is how we get user media:

this is chrome only, all those props are chrome specific, were copied from hangout and it was my attempt to fix the problem (i.e. we had it before this, when just using standard noisesuppresion):

    audio: {
      mandatory: {
        sourceId: deviceId
      },
      optional: [
        googEchoCancellation,
        googEchoCancellation2,
        googAutoGainControl,
        googNoiseSuppression,
        googHighpassFilter
      ]
    }

This is how we produce:

await room.produce({
      track,
      encodings: [{ maxBitrate: 80000, dtx: true, priority: 'high' }],
      codecOptions: {
        opusStereo: !!constraints.audio.channelCount,
        opusDtx: true,
        opusFec: true,
      },
      stopTracks: false
    });

I would appreciate any pointers, thank you!

2

Run trace-routes, it’s the only way to understand hops and if routes are doing poorly.

1 Like
3

thanks!

so you think poor routes are the most likely cause of this problem?

4

It truthfully depends on what you mean by crackling, dropped UDP packets make audio sound alien/distorted in many weird ways. Crackling is maybe a sign of audio setup/issues (do other users hear the same crackling?)

Do perform trace routes to narrow out network conditions! We can’t properly test other things without things in proper working condition. Just ensure server is working great then evaluate client code after.

5

You need to collect data, no way around it. Start with packet loss. If you manage to rule out network conditions issues, you can look into other issues after.

Google has media servers all over the world, and it would pipeline media streams to each other through a private network, so it pointless to compare your architecture to them.

6

It truthfully depends on what you mean by crackling, dropped UDP packets make audio sound alien/distorted in many weird ways.

this type of crackling: https://www.youtube.com/live/zB83CMqbnyo?feature=share&t=1380

Crackling is maybe a sign of audio setup/issues (do other users hear the same crackling?)

usually everybody in the room hears it. but usually it is coming only from some people, more or less consistently.

everybody in the room has the same setup, I mean the user media and webrtc transports etc are created and configured the same way.

Do perform trace routes to narrow out network conditions! We can’t properly test other things without things in proper working condition. Just ensure server is working great then evaluate client code after.

any idea how to do trace routes from browser to server?

I am not even sure what to look for. let’s say I see that this particular user has some poor routes to our servers. is it even possible to fix?

7

You need to collect data, no way around it. Start with packet loss. If you manage to rule out network conditions issues, you can look into other issues after.

that’s the thing. we collect data, we compare packets loss and other metrics between say user with this problem and without. not really much difference.

until this post it never even occured to me it could be network issue. we just don’t see much difference between “good” session and “bad” one.

Google has media servers all over the world, and it would pipeline media streams to each other through a private network, so it pointless to compare your architecture to them.

good point. although we connect users to closest aws datacenter and our nodes are in most of aws regions.

8

I would allow for users to change their audio enhancements as echo cancellation and other settings could cause similar issues. Whether this helps or not it’s a good idea.

That clip you sent just demonstrates that the user was running incorrect audio settings. As a good rule, recommend users are set to 16-bit or 24-bit @ 48KHz sample rate on both playback/recording devices and if they’re running any kind of DAC that it’s not the cause of failure due to drivers or latency settings.

That distortion can also come from a device over-loaded, I do see this sometimes on mobile devices in larger rooms with video and all sorts going.

9

@skavish were you able to fix this? What was the cause of it in your case?

10

it seems to be unrelated to webrtc or mediasoup. we allowed users to change the volume of their audio and we did it on the producer side just before sending it to mediasoup, basically just sending it through gainnode etc.
as soon as we removed it the issue has virtually disappeared.

looks like the implementation of audio api in chrome on some hardware is not perfect

1 Like
11

Ok thanks for the update