DEV Community: snowlyg

Debugging Android WebRTC Audio 3A with AEC_DUMP and Audacity

snowlyg — Mon, 15 Jun 2026 12:59:53 +0000

Android WebRTC audio problems often start as a vague report: call quality is bad. The root cause may be echo, background noise, howling feedback, unstable loudness, near-end speech being over-suppressed, or far-end playback leaking back into the microphone.

If the only test method is asking two people to make calls repeatedly and remember whether this build sounds better than the previous one, the result drifts quickly. Human listening gets tired, room noise changes, and firmware or parameter changes are hard to compare without durable evidence.

The practical goal is to turn subjective listening into inspectable audio material. WebRTC AEC_DUMP can record Audio Processing Module inputs, reverse playback reference, processed output, and runtime settings. After unpacking it with unpack_aecdump, the generated WAV files can be inspected in Audacity or a similar audio tool.

Background: Listening Memory Is Not Enough

This case came from an Android 14 WebRTC call scenario. The device hardware platform included RK3562, and the application used WebRTC's Audio Processing Module for audio processing. In this article, 3A mainly refers to:

AEC: Acoustic Echo Cancellation.
AGC: Automatic Gain Control.
NS / ANS: Noise Suppression.

In a real product, audio quality is not determined by the WebRTC algorithm alone. Enclosure design, microphone openings, speaker loudness, Audio HAL gain, sample rate, channel layout, playback delay, and scheduling can all affect the final call.

Listening-only testing has several weaknesses:

it is difficult to reproduce the same speech, loudness, and distance;
people cannot reliably remember small differences between builds;
it is hard to distinguish bad raw microphone input from bad 3A output;
it is hard to know whether AEC received a valid far-end reference signal.

Audio debugging needs evidence that can be saved and compared. That is where AEC_DUMP helps.

What AEC_DUMP Gives You

AEC_DUMP records key inputs and settings around the WebRTC audio processing path. It is not a complete replacement for real call testing, but it helps answer concrete questions:

Is the raw microphone input already broken?
Did the far-end playback reference reach AEC?
What changed before and after WebRTC audio processing?
Do sample rate, channel count, and APM switches match the expected device path?

This changes the debugging conversation from "it sounds different" to "we can compare the same captured material."

Test Environment and Boundary

A minimal test setup can use two Android devices:

Android device A
  -> WebRTC call
  -> Android device B

The test application can be based on the public sample project:

https://github.com/snowlyg/AndroidWebRTCGradle

Treat the sample build as a debugging tool, not as a production client. Public notes do not need real device identifiers, deployment details, test accounts, or complete field configuration.

One practical warning: if both devices use speaker mode, are too close to each other, and the volume is high, they can form a strong acoustic loop and produce harsh feedback. Keep volume and distance controlled, and use headphones or a fixed playback source when needed. Otherwise, an extreme acoustic feedback case may be mistaken for a pure software issue.

Capturing AEC_DUMP

A typical capture flow is:

Prepare two Android devices with USB debugging enabled.
Install a WebRTC test application that can save AEC_DUMP.
Enable AEC_DUMP file saving on both devices.
Start a WebRTC call.
Run a fixed test sequence: far-end speech, near-end silence, near-end speech, and double talk.
Hang up the call so the application closes the dump file.
Pull audio.aecdump from the device.

Example command:

adb pull /sdcard/Download/audio.aecdump ./audio.aecdump

The path is only an example. A real application can write the file to its own debug directory, but public material should avoid production paths.

Unpacking audio.aecdump

WebRTC source can build the unpack_aecdump tool. Build directories and target names can vary by WebRTC version, but a common command in an existing WebRTC build environment is:

ninja -C out/Default unpack_aecdump

After the tool is available, unpack the captured file:

./unpack_aecdump audio.aecdump

The common output files are:

input.wav
reverse.wav
ref_out.wav
settings.txt

Each file represents a different kind of evidence. They should not be interpreted as the same signal.

reverse.wav: The Far-End Reference for AEC

reverse.wav is the far-end playback reference that is fed into AEC. In practical terms, it represents what the local speaker side is expected to play.

Use it to check:

whether AEC received a far-end reference signal;
whether the reference audio is empty, intermittent, or abnormally low/high;
whether the reference could plausibly align with the real playback path.

If reverse.wav has no useful content, AEC does not have enough information to cancel speaker audio that leaks back into the microphone. In that case, tuning AEC delay or NS parameters is usually not the first priority.

If reverse.wav looks healthy but echo remains strong, continue with acoustic path, speaker volume, capture gain, delay alignment, and microphone input.

input.wav: Near-End Audio Before 3A

input.wav is the near-end microphone audio before WebRTC APM processing. It is the key file for judging the hardware capture and system input path.

Look for:

raw capture level being too low;
clipping;
obvious noise floor during silence;
far-end playback already overloading the microphone input;
hardware, Audio HAL, capture gain, or microphone path problems before WebRTC processing.

If input.wav is already heavily clipped, AEC, NS, and AGC cannot reliably repair it. Clipping means information has already been lost. Start with hardware gain, system capture path, microphone placement, and speaker volume.

ref_out.wav: Output After 3A Processing

ref_out.wav is the processed near-end reference output reconstructed from the dump inputs and settings. It is useful when compared with input.wav:

input.wav
  -> WebRTC APM
  -> ref_out.wav

Inspect whether:

background noise is reduced;
echo components are weaker;
near-end speech is over-suppressed;
AGC makes loudness unstable;
NS introduces obvious distortion or cuts speech tails.

If input.wav has clear speech but ref_out.wav severely suppresses the near-end speaker, check 3A settings, double-talk behavior, NS strength, AGC behavior, and AEC delay alignment.

settings.txt: Verify Configuration Before Tuning

settings.txt records WebRTC APM initialization and reconfiguration information. At minimum, check:

input / output / reverse sample rate;
input / output / reverse channels;
whether AEC is enabled;
whether AECM is enabled;
whether NS is enabled;
whether AGC is enabled;
whether HPF is enabled.

If sample rate, channel count, or 3A switches do not match expectations, fix configuration first. Otherwise, waveform analysis may be based on the wrong assumptions.

For example, if capture and reverse playback have mismatched sample-rate assumptions, AEC delay reasoning becomes unreliable. If channel count is different from the expected device path, APM output may not represent the real product behavior.

Using Audacity for Engineering Judgment

Audacity should not be treated as an absolute scoring system. Its value is in practical inspection:

waveform height for loudness and dynamic range;
flat tops for clipping;
silence thickness for noise floor;
spectrogram brightness for noise distribution;
same-time comparison between input.wav and ref_out.wav;
far-end playback sections to see whether reverse.wav leaks into input.wav.

A fixed test sequence helps:

0-5s: near-end silence, far-end speech
5-10s: near-end speech, far-end silence
10-15s: double talk
15-20s: near-end silence, room noise only

After each firmware or parameter change, compare the same type of segment instead of relying on a full-call impression.

Common Decision Paths

An AEC_DUMP review can be organized as several decision paths:

reverse.wav is empty or broken
  -> check render path and AEC reverse stream first

input.wav is clipped
  -> check microphone gain, Audio HAL, speaker volume, acoustic path

input.wav is clean but ref_out.wav is damaged
  -> check APM settings, AGC/NS strength, double-talk behavior, delay

settings.txt is unexpected
  -> fix sample rate, channels, and 3A switches before tuning

The point is not to solve everything in one pass. The point is to locate the layer first: capture is bad, reverse reference is missing, APM configuration is wrong, or the processing strategy needs tuning.

Relationship to Device Acoustic Tuning

AEC_DUMP is not isolated from device acoustic work. It belongs to the same loop as enclosure tuning, sample-rate adaptation, and AEC delay adjustment.

If input.wav shows a large amount of speaker energy entering the microphone, changing AEC parameters may only reduce the symptom. The device structure may need attention: speaker outlet, microphone sealing, enclosure reflection, pickup distance, and playback loudness.

If settings.txt shows sample-rate or channel assumptions that do not match the real device path, align software configuration before evaluating AEC delay. Otherwise, parameter tuning becomes guesswork.

A safer order is:

capture AEC_DUMP
  -> inspect input / reverse / ref_out / settings
  -> fix obvious capture or config problems
  -> adjust acoustic structure or playback level
  -> tune AEC delay and 3A parameters
  -> capture again and compare

For embedded WebRTC audio work, the reusable rule is simple: visualize first, tune second.

Conclusion

AEC_DUMP does not replace real call testing, and it does not prove that a device sounds good in every environment. But it makes Android WebRTC audio problems recordable, comparable, and reviewable.

For Android WebRTC devices, input.wav, reverse.wav, ref_out.wav, and settings.txt represent different layers of evidence. First confirm that the far-end reference exists, then check whether raw microphone input is healthy, compare audio before and after 3A, and finally verify sample rate, channels, and processing switches.

The value is not adding more ceremony to debugging. The value is avoiding the vague conclusion that "AEC is bad" whenever audio quality fails. The actual issue may be microphone gain, enclosure acoustics, sample-rate assumptions, render reference, delay alignment, or APM configuration. Splitting the evidence makes the fix path much more stable.

Debugging WebRTC Audio Playback Latency on OpenHarmony 5.0: ArkWeb, AudioRenderer Underrun, and Native SDK Comparison

snowlyg — Wed, 10 Jun 2026 15:28:36 +0000

This case happened in a WebRTC call running inside nweb / ArkWeb on an OpenHarmony 5.0 device. The peer side was Chrome, and the call could be established normally. The OpenHarmony side was also receiving audio data, but playback was clearly wrong: speech became choppy, delayed audio kept accumulating, and the user experience turned into "the peer finishes speaking, then the device plays it several seconds later."

At first glance, this kind of symptom can look like a network or WebRTC ICE problem. In this case, the useful evidence pointed in a different direction. WebRTC stats showed a connected media path, low round-trip time, low jitter, no packet loss, and continuously increasing send/receive bytes. The more important failure was in the local playback path: ArkWeb supplied decoded audio to the system playback path too slowly, AudioRenderer underrun appeared continuously, and old PCM data kept queuing instead of being dropped.

The native ohos_webrtc project is still relevant in this investigation, but not because it directly patches ArkWeb's internal audio sink. Its value is as a comparison path: if the same call works through native WebRTC, the problem is more likely inside ArkWeb/nweb playback. If native WebRTC also fails, the investigation moves lower into AudioServer, audio host, HAL, driver, or scheduling.

Background: WebRTC in nweb / ArkWeb

The affected scenario used a web-side WebRTC call on OpenHarmony 5.0. The application path looked like this:

Chrome peer
    -> WebRTC network and media path
    -> nweb / ArkWeb on OpenHarmony
    -> AudioRendererSinkInner
    -> AudioRenderer / AudioServer
    -> audio host / HAL / device speaker

The peer side could establish a call normally. The OpenHarmony side could receive audio, but playback had several visible symptoms:

speech was choppy.
AudioRenderer underrun appeared repeatedly.
older audio continued to queue.
the perceived playback became several seconds late.

That last symptom matters. If audio packets were simply missing, the result would be gaps or silence. In this case, old audio continued playing late, which suggested that the local playback path was falling behind real time.

Why the Network Was Not the First Suspect

WebRTC stats did not show a broken media path. The observed values were in a healthy range:

connectionState: connected
iceConnectionState: connected
packetsLost: 0
roundTripTime: 0.002 ~ 0.021 seconds
jitter: 0.022 ~ 0.031 seconds
bytesReceived / bytesSent: increasing continuously

These numbers do not prove that the network is perfect, but they make it unlikely that network loss, ICE failure, or remote-side media starvation is the primary cause of a multi-second playback delay.

The key distinction is this:

network problem:
  packets are lost, delayed heavily, or ICE state degrades

local playback problem:
  media arrives, but decoded audio is not delivered to the playback device in real time

In this case, the second explanation matched the logs better.

Key Logs: RenderFrame Was Too Slow

The most important device-side evidence came from the audio rendering logs:

AudioRendererSinkInner: [RenderFrame] RenderFrame len[7056] cost[100~106]ms
RendererInServer: Underrun
PaRendererStreamImpl underrun: 5757, 5758, 5759...
Buffer is not empty

The important details are:

a single RenderFrame call cost around 100 ms.
the playback side reported underrun.
the upper buffer was still not empty.

That combination is very different from "no audio data arrived." It means audio data existed above the playback layer, but the data was not reaching the low-level playback device at a real-time pace.

For a real-time call, a 100 ms render operation is too expensive. If this repeats, AudioServer runs out of data at the playback deadline, underrun is reported, and the remaining old PCM continues to queue. The user then hears delayed speech instead of live speech.

Failure Chain: Data Exists, Playback Falls Behind

The practical failure chain can be summarized like this:

nweb / ArkWeb audio supply is slow
  -> AudioServer playback buffer runs dry
  -> AudioRenderer underrun appears
  -> old PCM is still queued above the sink
  -> playback delay grows to several seconds

This explains why the call can look connected and still sound unusable. WebRTC may continue to receive packets, decode audio, and update stats, while the local playback sink fails to keep up with real time.

It also explains why simply waiting does not recover the call. If old PCM is not dropped when the renderer falls behind, the playback queue can preserve outdated audio. The device then keeps playing history instead of catching up to the live stream.

For communication products, that behavior is usually worse than a short dropout. A short dropout is noticeable, but delayed conversation breaks turn-taking and makes the call unusable.

What the Native ohos_webrtc Project Provides

The relevant native project is:

https://gitcode.com/openharmony-sig/ohos_webrtc

This project is based on WebRTC m120 for OpenHarmony adaptation. From the project history and exposed SDK surface, its work is mainly around:

ArkTS SDK wrapping.
native WebRTC integration.
audio and video capture/rendering.
AudioDeviceModule adaptation and optimization.
video hardware encode/decode support.
screen capture.
system audio capture.
memory and stability fixes.

That means the project already provides a native WebRTC SDK path for OpenHarmony. It is useful for building a comparison test against the ArkWeb path:

web path:
  Chrome -> nweb / ArkWeb -> AudioRendererSinkInner

native path:
  ArkTS UI -> native ohos_webrtc -> AudioDeviceModule -> AudioRenderer

The native path does not directly repair ArkWeb's internal AudioRendererSinkInner, but it can help answer a critical question: is the playback problem specific to ArkWeb's WebRTC sink, or does it still happen when the media path is moved to native WebRTC?

Hardware Audio Codec Is Not an Existing Project Capability

The current project evidence does not show an implemented hardware audio encoder/decoder path.

The audio codec path still appears to use WebRTC's built-in software factories:

CreateBuiltinAudioEncoderFactory()
CreateBuiltinAudioDecoderFactory()

The typical supported audio codecs in that path are:

Opus
G722
iLBC
G711
L16

The OpenHarmony AVCodec adaptation in the project is mainly visible on the video side:

HardwareVideoEncoderFactory
HardwareVideoDecoderFactory
H264 / H265

The current material does not show a matching hardware audio factory layer such as:

HardwareAudioEncoderFactory
HardwareAudioDecoderFactory
OH_AudioEncoder
OH_AudioDecoder

This should be stated carefully. It does not mean the platform can never support hardware audio codecs. It only means that this project, as observed, should not be treated as already having a hardware audio encode/decode path comparable to its video hardware codec path.

Why Hardware Audio Codec Is Not the First Fix

More importantly, the observed failure does not first point to compressed-audio codec performance.

Hardware audio encoding/decoding mainly affects this boundary:

compressed audio <-> PCM

The logs point to a later boundary:

decoded PCM -> AudioRendererSinkInner -> AudioRenderer -> AudioServer -> HAL

The actual symptoms were:

RenderFrame taking around 100 ms.
AudioRenderer underrun.
upper buffer not empty.
old PCM continuing to queue.
playback delay growing to seconds.

Even if hardware audio codec support were added later, it would not necessarily fix a renderer that cannot deliver PCM to the playback device in real time. The first priority is the playback scheduling and buffer behavior after audio has already reached PCM form.

Native SDK as a Comparison Experiment

The most useful short-term experiment is to run the same call scenario through native ohos_webrtc.

If the native path is smooth:

native ohos_webrtc works normally
  -> the problem is more likely in nweb / ArkWeb audio sink behavior
  -> business logic can consider bypassing web-side WebRTC for calls

If the native path also has underrun and delayed playback:

native ohos_webrtc also stutters
  -> the problem is more likely below ArkWeb
  -> inspect AudioServer, audio_host, HAL, driver, thread priority, and CPU scheduling

This comparison is valuable because it avoids arguing from one log stream. It turns the question into a controlled boundary test:

same device
same network
same call scenario
different WebRTC playback path

That is a better isolation strategy than immediately tuning codec parameters or changing ICE configuration.

AEC Dump Capability and Its Boundary

The native project exposes AEC dump controls through PeerConnectionFactory:

startAecDump(fd: number, max_size_bytes: number): boolean;
stopAecDump(): void;

A typical native SDK usage pattern is:

const file = fs.openSync(`${context.filesDir}/call_debug.aecdump`,
  fs.OpenMode.READ_WRITE | fs.OpenMode.CREATE | fs.OpenMode.TRUNC);

pcf.startAecDump(file.fd, -1);

This is useful for debugging the native WebRTC audio-processing path. It can help inspect audio processing behavior in the native SDK call path.

The boundary is equally important:

it applies to the native ohos_webrtc SDK path.
it does not directly capture nweb / ArkWeb internal WebRTC AEC dump.
after the file descriptor is handed to native/WebRTC, ownership must be handled carefully; do not close or reuse it from the application side in a way that breaks the native dump writer.

So AEC dump is useful for the comparison path, but it is not direct visibility into ArkWeb's internal playback sink.

Recommended Direction

The short-term direction is:

Reproduce the same call through native ohos_webrtc.
Compare playback behavior with the nweb / ArkWeb path.
If native playback is smooth, evaluate moving the call path to the native SDK.
If native playback also fails, move the investigation to the system audio stack.

System-side investigation should focus on:

AudioRendererSinkInner RenderFrame calls taking around 100 ms.
low-latency AudioRenderer path.
AudioServer and audio host thread priority.
HAL period and buffer configuration.
CPU governor and big/little core scheduling.
dropping old PCM when playback is already behind real time.

That last point is important for real-time communication. When the renderer is late, preserving all old PCM may be technically faithful, but it makes conversation worse. A real-time call usually needs a catch-up strategy that favors current audio over stale audio.

Conclusion

This OpenHarmony WebRTC issue was not primarily a classic network problem. The call was connected, ICE stayed connected, packets were not being lost, RTT and jitter were low, and bytes continued to move.

The strongest evidence pointed to local audio playback real-time failure. AudioRendererSinkInner::RenderFrame cost around 100 ms, AudioServer reported underrun, and the upper buffer was still not empty. That means the system was not simply missing audio data. It had audio data, but it was not being delivered to the playback device fast enough, and old PCM kept accumulating.

The native ohos_webrtc project provides an important comparison path. It already covers ArkTS SDK wrapping, native WebRTC integration, AudioDeviceModule work, video hardware codec support, screen capture, system audio capture, and AEC dump controls. But it should not be described as having hardware audio encode/decode support based on the current evidence.

For this specific issue, hardware audio codec work is not the first fix. The first priority is to verify whether native WebRTC can bypass the ArkWeb audio sink and then determine whether the remaining bottleneck belongs to ArkWeb, AudioRenderer, AudioServer, audio host, HAL, or scheduling.

WebRTC Echo and Noise Optimization on Android 14 Bedside Devices

snowlyg — Sat, 06 Jun 2026 07:28:45 +0000

This article looks at WebRTC audio tuning on Android 14 bedside devices.

The target scenario is not a consumer video-call app. It is closer to shared institutional devices that need to stay online for long periods, support hands-free calls, capture speech from a practical distance, and still keep the conversation intelligible in noisy rooms.

The important lesson from this case is that echo and noise tuning was not only a WebRTC AEC parameter problem. The physical acoustic path, microphone sealing, sample-rate behavior, and AEC delay setting all had to be handled together.

What changed on the hardware side

The first change was around the speaker output path. Part of the enclosure near the speaker was opened so playback was less blocked by the shell. That improved perceived loudness and reduced the amount of sound energy trapped inside the small cavity.

The second change was around the microphone path. A small seal pad was added near the microphone opening. The goal was to reduce leakage and structural echo pickup, so the microphone input became closer to the intended acoustic path.

This made the later software tuning more meaningful. If the input signal is already dominated by leakage and enclosure reflection, the echo canceller has to solve a harder problem than necessary.

What changed on the WebRTC side

The software work focused on two areas:

adapting the WebRTC audio path to the actual sample-rate behavior of the device;
tuning the AEC delay value against the real capture/playback path.

In an embedded terminal, the real delay is not only an algorithm parameter. It includes capture buffering, playback buffering, resampling, scheduling, and the physical distance between speaker and microphone.

How I validated it

The validation setup kept variables stable:

same device placement;
same speaker volume;
same speaking distance;
same background-noise condition;
same test phrase or playback source;
same recording and comparison method.

The goal was not to produce a perfect lab metric. The goal was to confirm that playback became louder, residual echo became lower, speech stayed understandable, and AEC was no longer fighting a mismatched sample-rate or delay assumption.

Takeaway

For embedded WebRTC devices, tune the physical acoustic path first. Then tune AEC parameters against that real path.

If the enclosure reflects too much speaker energy back toward the microphone, software tuning alone starts from a bad signal. A cleaner acoustic path makes WebRTC audio processing more effective and easier to validate.

WebSocket Half-Open Connections and gRPC Gateway Discovery in Complex LAN WebRTC Systems

snowlyg — Thu, 04 Jun 2026 14:26:37 +0000

The target scenario is not consumer calling. It is closer to B2B institutional device fleets: many shared devices, long-running uptime, centralized operations, noisy rooms, and a need to preserve both pickup distance and speech quality.

In constrained LAN environments, the hardest WebRTC failure is not always a clean disconnect. The more dangerous state is a control connection that still appears alive while application messages no longer move.

The media path can still be WebRTC. The question is how to design the control plane around it.

The Failure Mode

A WebSocket-centered signaling path can work well in a simple network. Each client connects to a central service, receives call events, and forwards offer, answer, and ICE candidate messages.

In constrained networks, long-lived connections may become stale. A client can stay alive while its upstream connection is no longer useful. The server may still hold old state. The UI may still show the peer as online.

For a WebRTC call system, that can mean:

call events do not reach the callee
timeout does not close all affected UI
stale sessions block new calls
group-call media state is not cleaned up correctly

The Gateway Boundary

The design I prefer is to keep media on WebRTC and move control recovery into a gateway layer.

A Go/gRPC gateway can own:

device registration
gateway discovery
heartbeat and reachability state
call session routing
offer, answer, and ICE candidate forwarding
timeout and hangup convergence
cleanup after abnormal state

Audio observability also belongs in the reliability model. In shared rooms, the system has to handle background noise while preserving enough pickup distance. That means call state, recovery state, and audio state should be debugged together instead of treated as unrelated problems.

The key is bidirectional reachability. Recovery should not depend only on a stale client-initiated connection noticing that it is broken.

Session State Matters

A primary node or discovery service needs a state table:

gateway id
current reachability
latest heartbeat time
current call state
active session ids
gateway version
latest error reason

This table answers operational questions: which gateway should receive a call event, whether a peer is actually reachable now, and whether an old session must be closed before a new call starts.

Call Lifecycle Convergence

Timeout and hangup should be converged by server-side state.

For one-to-one calls, either side can request hangup. The primary node should notify both gateways, remove media mappings, and mark the session as ended.

For group calls, one participant leaving should remove only that participant's media. A full hangup should close the entire session. Without explicit participant and media mapping, group cleanup becomes either too weak or too destructive.

What to Validate

The useful tests are forced failures:

Stop one gateway while the call is ringing.
Drop the network path between two gateways.
Keep the UI open while the control stream becomes unusable.
Make one participant leave a group call.
Trigger timeout and manual hangup at nearly the same time.

The goal is not that nothing ever disconnects. The goal is that every abnormal path reaches a clear state and leaves no stale UI, stale session, or stale media mapping.

Takeaway

This is not simply replacing WebSocket with gRPC. It is designing a stronger recovery model:

gateways can discover each other
the primary node owns session state
both sides can be reached by control events
timeout and hangup are explicit
group-call media mappings are tracked

For WebRTC systems in constrained LANs, recovery has to be part of the architecture, not an afterthought.

Connecting Android WebRTC to a Go gRPC Signaling Gateway

snowlyg — Tue, 02 Jun 2026 13:23:05 +0000

This is a sanitized engineering recap about connecting Android WebRTC clients to a Go gRPC signaling gateway.

Source article:
https://www.lodan.me/posts/golang-grpc-webrtc-android/

The main boundary

The important part is not only creating a PeerConnection. The harder part is keeping signaling, Android lifecycle, and WebRTC media state separated enough to debug.

The boundary I use is:

Go/gRPC owns registration, call control, callbacks, and signaling events.
Android owns permissions, UI lifecycle, local audio/video resources, and cleanup.
WebRTC owns offer/answer, ICE candidates, tracks, and connection state.

Why logs matter

When a call fails, the log needs to connect all layers. Useful fields include:

call id
peer id
action
signaling state
ICE state
selected candidate pair
local and remote lifecycle state

Without these fields, the same failure can look like a network issue, a device issue, or a WebRTC SDK issue.

Full article

The full write-up covers gateway startup, device registration, callback boundaries, SdpObserver, PeerConnection.Observer, single-call and multi-call lifecycle, hold, hangup, broadcast, and cleanup:

https://www.lodan.me/posts/golang-grpc-webrtc-android/

Server-Side WebRTC Noise Reduction with Pion, FFmpeg, and RNN Models

snowlyg — Sat, 30 May 2026 15:22:56 +0000

This is a sanitized engineering note about server-side audio noise reduction for WebRTC calls.

Source article:
https://www.lodan.me/posts/server-side-webrtc-noise-reduction-pion-ffmpeg-rnn/

What the prototype tests

The goal is not to replace WebRTC's built-in audio processing. The narrower test is:

receive a WebRTC Opus track with Pion
read RTP packets in OnTrack
decode Opus payloads to PCM
pipe raw PCM into FFmpeg
apply the arnndn RNN noise reduction filter
validate the output as a file before considering real-time forwarding

Why this boundary matters

RTP, Opus, PCM, and FFmpeg raw audio input are different boundaries. If the PCM format is wrong, FFmpeg may still produce a file, but the result should not be trusted.

For example, if the Go side writes int16 PCM, the FFmpeg input format should be reviewed as s16le, not casually treated as s32le.

Production concerns

The prototype is useful because it isolates the audio path, but production use needs more work:

buffering and latency
CPU and memory isolation
FFmpeg process lifecycle
model choice
packet loss and jitter
RTP timestamps
audio/video sync
whether the processed audio is returned to WebRTC or only recorded

The full article has diagrams and the longer explanation:

https://www.lodan.me/posts/server-side-webrtc-noise-reduction-pion-ffmpeg-rnn/

WebRTC + Go gRPC Call Architecture for Constrained LAN Environments

snowlyg — Wed, 27 May 2026 14:29:46 +0000

I published a new architecture recap on building WebRTC calls around a Go gRPC signaling layer and Android clients in constrained LAN environments.

The design is intentionally split into clear ownership boundaries:

gRPC signaling handles device state, session control, and event delivery.
WebRTC owns SDP/ICE negotiation, media tracks, selected candidate pairs, and transport state.
Android clients own runtime permissions, audio/video resource management, UI state, and lifecycle cleanup.
An RTC Gateway gives the system a place for discovery, recovery, session mapping, and observability.

The main lesson is that call setup is only the beginning. The real engineering work is in recovery and observability: LAN paths can change, devices can restart, sessions can become stale, audio quality can degrade, and gateway state can drift away from client state.

Full write-up:
https://www.lodan.me/posts/webrtc-grpc-lan-call-architecture/

This is part of a longer series on WebRTC reliability, AEC dump debugging, server-side noise suppression, and RTC Gateway concurrency issues.

Debugging Android 14 WebRTC Disconnects on a coturn Relay Path

snowlyg — Sat, 23 May 2026 09:14:29 +0000

I recently wrote up a debugging case around Android WebRTC, coturn, TURN relay, and ICE failures. This is the anonymized version because the useful part is the debugging method, not the original environment.

Context

Android WebRTC audio/video call.
The service originally worked mostly on an internal network.
A TURN relay path through coturn was introduced for more complex network boundaries.
Older Android devices were mostly stable.
Android 14 devices often disconnected after 30-60 seconds.
Forcing the media path through TURN relay made the failure much easier to reproduce.

The Misleading Clue

The first clue looked obvious: a repeated timeout around a local relay-related address. It appeared near the disconnect window, so it was tempting to treat it as the cause.

That was not enough.

In WebRTC debugging, a noisy log line can be real without being the root cause. The better starting point was the ICE state transition:

IceConnectionChange -> DISCONNECTED / FAILED
StandardizedIceConnectionChange -> DISCONNECTED / FAILED

That moved the investigation away from "why does this timeout appear?" and toward "why does the selected media path fail?"

What Helped Narrow It Down

Force the path through coturn so direct LAN candidates did not hide the issue.
Test a newer WebRTC build to rule out a simple SDK version mismatch.
Expand the device matrix until the issue narrowed around Android 14 behavior.
Re-check TURN-side certificate/security settings and required port exposure.
Re-test the same matrix after adjusting the TURN-side configuration.

After the TURN-side changes, the 30-60s disconnect stopped reproducing in the same test matrix.

Takeaways

For WebRTC production issues, I would rather start from:

ICE state transitions.
Selected candidate pair.
Whether the call is using host, srflx, or relay candidates.
TURN server logs and port exposure.
Client-side network and app lifecycle events.

The loudest log line is useful, but it should not be allowed to define the investigation by itself.

WebRTC reliability is usually a system problem: client version, network path, TURN configuration, device behavior, and application state handling all interact. Treating it as a single log-line problem can waste a lot of time.

Full write-up:
https://www.lodan.me/posts/android14-coturn-webrtc-disconnect/