Hi, we are using videoroom for video streams and ab in parallel for audio. We are getting random crackling noise on clients from AB. if we publish audio to VR we don’t have this cracklings on client side.
Can you advice how to debug this problem? We don’t have any anomalities in chrome://webrtc-internal when this is happening.
I’m trying to specify audiobridge parameter default_prebuffering mentioned in audiobridge plugin doc but in janus_audiobridge.c I don’t see any usages of it.
https://groups.google.com/g/meetecho-janus/c/_6BFdoL-ANE?pli=1 this discussion also mentioned this parameter.
That parameter doesn’t exist anymore, since we now use the speex-dsp jitterbuffer.
any advices to debug it?
You can monitor the values of the buffer/queue values when querying the related handle via Admin API, to inspect the internal status of the jitter buffer.
Dear team,
We are working on android and iOS application audio only. We are facing similar kind of audio crackling and clicking issue using janus audioBridge.
I will post my detailed analysis here in terms of audio being received on janus media server as well as after mixing of audio packets.
Janus Media Server: Branch: master
Janus version: 1202 (1.2.2)
Janus commit: 15ef4d6cde38ea8d441f7e27eba298265c2a7358
Compiled on: Thu Jan 4 11:14:47 UTC 2024
** AWS EC2 Instance: C5.2xlarge - Mumbai Region **
Android side Janus Payload for Create/Join Room:
createRoom {"janus":"message","body":{"request":"create","is_private":false,"audiolevel_event":true,"audio_level_average":100,"default_expectedloss":20,"audio_active_packets":200,"description":"My awesome room","sampling_rate":48000,"record":true,"record_dir":"\/home\/admin\/janus-record","mjrs":true,"mjrs_dir":"\/home\/admin\/janus-record\/mjrs"},"transaction":"lT6fclBcj9GA","session_id":8573312763821879,"handle_id":7927896452164538}
publisher joiningRoom {"janus":"message","body":{"request":"join","room":"3b3a1de1-7704-4cf0-b896-f4072c9174df","ptype":"publisher","display":"pixel 4a ufone","quality":9,"audio_level_average":100,"audio_active_packets":200,"expected_loss":20,"sampling_rate":48000},"transaction":"h5ajkOi8YEol","session_id":8573312763821879,"handle_id":7927896452164538}
I have obtained the wav files for individual participants as well as after mixed audio wav file from janus server side. Here is the analysis of 1v1 audio call using janus AudioBridge.
I am posting screenshots for better understanding in this google drive link:
Janus AudioBridge | Audio Analysis using Audacity
Here is single screenshot from my above analysis using Audacity tool:
In each of the above screenshot it can be seen that audio which is being sent by android endpoints and being received on janus media server is perfectly clean but after mixing, there are some random delays where mixed audio become disappeared and causing cracking and clicking sounds on android side.
One thing to clear, there is no load on janus media server in terms of concurrent calls and we are not using any video streams at all. This is audio only application for android and during our testing only single audio call was happening. We haven’t changed any janus stack at all.
Can anyone please assist in this regard?
Thanks
Janus AudioBridge | Audio Analysis using Audacity
https://drive.google.com/drive/folders/1ubcQpxr5j2PykffSpXMVpG0KW_AY7iHt?usp=drive_link
@mailtousman did you tried latest janus versions after merging plc support? In our production env all issues with crackling noise is solved now
@spscream Hey, have you tried using audiobridge with “denoise” flag? We’re still getting cracklings there
I have also some issues with audiobridge/rnnoise.
Here are two spectrograms: top - audio that I send to audiobridge, bottom - what I get from audiobridge. It’s clearly seen that some noise is removed, but also some full-spectrum stripes introduced. It sounds like a crack. Not sure if it’s related to this topic (if it’s not, I can start a new one).
Any ideas where to start investigation? (Maybe some known issues with rnnoise at d98345814b0531e61bf10d463be21fa94b352f9c ?)
@lorenzo, please give a hint
Denoising is meant to be used only for removal of environmental noise (crowd, traffic etc.) and not for generic “crackling”. Crackling related to network issues or mic malfunctions will never be solved by denoising.
If used improperly, denoising might sometimes negatively affect the input in particular scenarios, like voice with background music.
@m08pvv Try with different sampling rates. Also make sure to use the latest rnnoise tag.
We haven’t tested the denoiser in many scenarios unfortunately. We are using the library default model. There is still a chance that something is not perfect.
@atoppi, I’m not trying to get rid of crackling noise, I’m just trying to avoid it. The original sound doesn’t have this noise, it has only some background noise (top spectrogram on my screenshot) and I just use that .wav file as input for audiobridge. I.e. I use a file instead of microphone (for consistent testing and to eliminate influence of frontend).
What I already tried: explicit sampling rates for audiobridge (48kHz, 24kHz, 16kHz, 8kHz), latest commit of rnnoise (f6662ad41f5bf7bf244967a04e95334c81e5af4c, it’s 2 weeks ago)
So the issue is that in some cases solid spectral stripes appears.
Small update: excluded rnnoise to check if the issue is somwhere in audiobridge or webrtc/networking.
Here is spectrogram of the file that I use for test
So it seems that libopus introduces some encoding artifacts (barely audible) which later cause issues with rnnoise (rnnoise makes these spikes audible)
Which encoding is causing the artifacts?
The encoding on your webrtc peer or the encoding of the audiobridge?
Recorded mjr’s and it seems that Janus receives already an audio with encoding artifacts which later will be promoted to audible noise by rnnoise.
Scratching head over how to get rid of that artifacts. Any ideas? Or maybe there is some extension point in Janus so I can try to filter on server side (I don’t have control over browsers so I have to do it either on Janus or in some web audio js but afaik encoding is done after all web audio and there is no option to filter it)
Small update: added a dynamics compressor (audioContext.createDynamicsCompressor) on client side and managed to reduce encoding artifacts on test recording to 0(!)
On live check found a couple cases when they still appear, but already working on adding high-pass/low-pass filters with proper values and adjusting compressor’s settings.
So yep, it was browser’s encoder who introduced artifacts (which later rnnoise turned into audible crackling) because of high dynamic range.
