[WebRTC Demo] macOS M4 部署踩坑汇总与修复：端口冲突 / 电流音 / No Speech Detected + 延迟分析

[seasidedog24]

概述

在 Mac mini M4 (24GB) 上完成 WebRTC Demo 本地部署后，遇到了多个问题并逐一排查修复。目前已可以正常跑通全双工视频通话，但存在明显的延迟卡顿（Token2Mel RTF > 1.0x）。本 Issue 汇总所有发现和修复方案，附带延迟录屏，供社区参考和官方改进。

⚠️ 关于 Issue #74 的重要更新: 之前在 #74 中建议增加心跳注册循环，但深入排查后发现 心跳注册会覆盖 Redis 中的服务锁状态，导致 "No Speech Detected"。请勿使用 while true; do curl register; sleep 30; done 循环！详见下方根因 3.1。

环境信息

项目	值
设备	Mac mini M4, 24GB
macOS	Darwin 25.2.0
Docker Desktop	4.59.1
Python	3.14.2
模型	MiniCPM-o-4_5 Q4_K_M
部署模式	duplex（全双工）
Docker 镜像	原始镜像（linux/amd64，通过 Rosetta 2 运行）

问题 1：macOS 端口 8021 被系统服务占用

症状

Docker 容器启动后，前端请求后端失败，前端显示 "体验人数已满" 等错误。

根因

macOS 自带的 launchpad 相关服务占用了 8021 端口，与 Docker 的宿主机端口映射冲突。

修复方案

修改 docker-compose.yml，将宿主机端口改为 8025：

# docker-compose.yml
backend:
  ports:
    - "8025:8021"   # 宿主机 8025 -> 容器 8021
frontend:
  environment:
    - NEXT_PUBLIC_API_URL=http://localhost:8025

同时修改 minicpmo_cpp_http_server.py 中的服务注册 URL 端口（或通过环境变量 BACKEND_API_PORT 配置）。

建议：macOS 上部署前，先用 lsof -i :8021 检查端口是否被占用。

---

问题 2：TTS 电流音 — Hamming 窗函数缺陷

症状

TTS 音频有规律的 "嘀嗒/电流" 声，约每秒出现 1 次。

根因

token2wav-impl.cpp 中 ensure_hamming_window_2n() 使用 Hamming 窗 做 overlap-add crossfade，存在两个数学缺陷：

1. 边界不归零: Hamming 窗两端值 ≈ 0.08，在 chunk 接缝处产生约 8% 的信号泄漏（幅度跳变）
2. 不互补: w[i] + w[i+n] ≠ 1，crossfade 中间区域能量下降约 8%，产生周期性音量凹陷

修复方案

替换为互补半 Hann 窗（complementary half-Hann），严格保证 fade_in[i] + fade_out[i] = 1.0：

 void ensure_hamming_window_2n(int64_t n, std::vector<float> & window_out) {
-    // Hamming window for overlap-add crossfade.
+    // Complementary half-Hann window for overlap-add crossfade.
     window_out.clear();
     if (n <= 0) { return; }
     const int64_t N     = 2 * n;
-    const double  denom = (N > 1) ? (double) (N - 1) : 1.0;
     const double  pi    = std::acos(-1.0);
+    const double  denom = (n > 1) ? (double) (n - 1) : 1.0;
 
     window_out.resize((size_t) N);
-    for (int64_t i = 0; i < N; ++i) {
-        const double a         = 2.0 * pi * (double) i / denom;
-        window_out[(size_t) i] = (float) (0.54 - 0.46 * std::cos(a));
+    for (int64_t i = 0; i < n; ++i) {
+        // fade_in: 0 → 1 平滑上升 (half-Hann)
+        const double fade_in = 0.5 * (1.0 - std::cos(pi * (double) i / denom));
+        window_out[(size_t) i]       = (float) fade_in;         // 前半段: fade in
+        window_out[(size_t) (i + n)] = (float) (1.0 - fade_in); // 后半段: fade out
     }
 }

涉及文件: llama.cpp-omni/tools/omni/token2wav/token2wav-impl.cpp，函数 ensure_hamming_window_2n()
修改后需重新编译: cmake --build build -j

---

问题 3："No Speech Detected" — 三层根因叠加

这是最复杂的问题，由三个独立根因叠加导致。

3.1 根因（致命）：心跳注册覆盖 Redis 服务锁状态

这也是 Issue #74 临时方案的副作用。

症状

会话开始约 20 秒后，前端显示 "No speech detected. Ending call..."（检测到长时间未说话，即将结束通话），机器人自动退出 LiveKit 房间。

根因

之前按 #74 的临时方案手动启动的 bash 心跳循环：

while true; do curl -X POST .../api/inference/register ...; sleep 30; done

每次调用后端的 register_service() 接口时，后端无条件创建新的 InferenceService 对象（status=AVAILABLE, locked_by=None），直接覆盖 Redis 中已有的 BUSY 状态。后端的 _resource_monitor 线程检测到服务不是 BUSY → 触发 robot_exit → 前端显示 "No speech detected"。

证据链（来自后端日志）：

07:17:22.831 - 服务锁定成功 (BUSY)
07:17:41.710 - renew_service_lock 成功 (最后一次成功续期)
07:17:42.150 - /api/inference/register 覆盖状态为 AVAILABLE ← 致命点
07:17:42.689 - renew_service_lock 失败 (服务已变为 AVAILABLE)
07:17:44.412 - _resource_monitor 触发 robot_exit

修复

• 不要运行心跳注册循环
• Python wrapper 启动时只注册一次即可
• 后端的 heartbeat_monitor 通过 健康检查端口（port+1，即 9061）检测服务是否存活，不依赖重复注册

建议

register_service() 接口应该判断服务是否已存在并处于 BUSY 状态，如果是则只更新 last_heartbeat 而不覆盖 status 和 locked_by。当前实现是"幂等但不安全的"。

3.2 根因（加重）：WAV Scanner 等待时间太短

症状

C++ decode SSE 流结束后，Python wrapper 只等 1 秒就放弃扫描 WAV 文件。

根因

minicpmo_cpp_http_server.py 中 _streaming_generate_duplex 的 final wait 阶段：

• no_new_wav_count >= 10 配合 asyncio.sleep(0.1) = 仅 1 秒耐心
• Token2Wav 在 M4 上需要 1.5-3 秒生成一个 chunk
• WAV 文件还没生成就被放弃了

修复

# 修改前
max_final_wait = 3.0   # 最多等 3 秒
if no_new_wav_count >= 10:  # 1 秒无新 WAV 就放弃
    break

# 修改后
max_final_wait = 15.0  # 最多等 15 秒
if no_new_wav_count >= 60:  # 6 秒无新 WAV 才放弃
    break
# 增加 generation_done.flag 检查，所有 WAV 生成完毕后提前退出

3.3 根因（加重）：is_listen 快速检查太短

症状

当 C++ 返回 is_listen=True（模型切换到聆听模式），Python wrapper 只做 50ms 的 quick check 就发送 is_listen 事件。

修复

# 修改前
while (time.time() - quick_check_start) < 0.05:  # 仅 50ms
    ...

# 修改后  
while (time.time() - quick_check_start) < 8.0:  # 最多等 8 秒
    ...
    if no_wav_count >= 60:  # 6 秒无新 WAV
        break
    # 同样增加 generation_done.flag 提前退出

涉及文件: cpp_server/minicpmo_cpp_http_server.py

---

问题 4：延迟卡顿 — Token2Mel RTF > 1.0x（未解决）

修复上述问题后，全双工通话可以正常进行，但存在明显的延迟卡顿。

延迟数据（Mac mini M4 24GB）

调用	Token2Mel	Vocoder	总计	RTF	说明
call=0	1013ms	992ms	2005ms	2.39x	冷启动
call=5	552ms	453ms	1005ms	1.01x	最佳情况
call=7	1888ms	843ms	2731ms	2.73x	GPU 竞争严重
call=14	2121ms	919ms	3039ms	3.04x	最差情况
平均	~1060ms	~640ms	~1700ms	~1.7x	无法实时

• RTF > 1.0 = 非实时（生成 1 秒音频需要 1.7 秒）
• Token2Mel 波动巨大（552ms ～ 2121ms），主要因为 LLM + TTS + Token2Mel 同时竞争 Metal GPU
• Token2Mel 使用 n_timesteps=10（与 prompt_cache.gguf 绑定，不可随意修改）

与其他设备的对比

指标	M4 Max（官方）	M4 Pro 64GB（社区）	M4 24GB（本机）
Token2Mel	~235ms	~1500ms	~1060ms（平均）
RTF	~0.47x	~2.0x	~1.7x
结论	✅ 实时	❌ 不实时	❌ 不实时

延迟录屏

录屏展示了实际通话中的延迟卡顿情况：

📹 延迟录屏下载

可能的优化方向

1. 降低 n_timesteps: 如果能重新生成 prompt_cache.gguf（用 n_timesteps=5），理论上可以将 Token2Mel 时间减半
2. GPU 调度优化: LLM / TTS / Token2Mel 三个模型竞争 Metal GPU，考虑错峰调度
3. 提供 ARM64 Docker 镜像: 当前前端/后端 Docker 镜像为 linux/amd64，通过 Rosetta 2 运行有额外开销

---

其他注意事项

• macOS 上部署前，用 lsof -i :8021 检查端口可用性
• n_timesteps 受 prompt_cache.gguf 绑定，不能通过 init 参数随意修改（否则 Token2Wav 初始化失败）
• 修改 C++ 代码后必须重新编译 并重启服务进程（旧进程使用内存中的旧代码）
• 健康检查服务器在 port+1（如 9061）独立运行，即使推理繁忙也能正常响应

修复文件汇总

文件	修改内容
docker-compose.yml	端口 8025:8021，NEXT_PUBLIC_API_URL
cpp_server/minicpmo_cpp_http_server.py	WAV Scanner 超时 + is_listen 等待 + 注册端口
llama.cpp-omni/tools/omni/token2wav/token2wav-impl.cpp	Hamming → 互补半 Hann 窗

[yaobaishen]

On my macbook pro (M3 max chip), it reports UDP port 50070 conflict with Microsoft Teams, anyone have ideas? thanks.

# 参考音频路径（默认使用本目录下的 cpp_server/assets/）
E486: Pattern not found: 50070
 ✔ Image livekit/livekit-server:v1.5.3 Pulled                               38.0s
[+] up 22/225b055                      Pull complete                         2.0s
 ✔ Image livekit/livekit-server:v1.5.3 Pulled                               38.0s
   ✔ 2ae81d15b055                      Pull complete                         2.0s
   ✔ bca4290a9639                      Pull complete                         0.8s
[+] up 22/2298a04                      Download complete                     0.0s
 ✔ Image livekit/livekit-server:v1.5.3 Pulled                               38.0s
   ✔ 2ae81d15b055                      Pull complete                         2.0s
   ✔ bca4290a9639                      Pull complete                         0.8s
   ✔ 8cadfa198a04                      Download complete                     0.0s
 ✔ Image redis:7-alpine                Pulled                               27.8s
   ✔ 7f2fe1f8dbe2                      Pull complete                         1.0s
   ✔ f94778f36502                      Pull complete                         0.8s
   ✔ 6a0931293cae                      Pull complete                         1.3s    ✔ 4f4fb700ef54                      Pull complete                         1.2s    ✔ a447a5de8f4e                      Pull complete                         2.0s    ✔ 7de5c848d52e                      Pull complete                         2.3s    ✔ db5340c14e8f                      Pull complete                         1.2s    ✔ 53be78603641                      Pull complete                         1.0s    ✔ db68f7ed3c4d                      Download complete                     0.0s    ✔ 4edf49ae71c1                      Download complete                     0.0s  ✔ Network omni_docker_minicpmo-net    Created                               0.0s  ✔ Container minicpmo-redis            Created                               0.1s  ✔ Container minicpmo-livekit          Created                               0.1s
 ✔ Container minicpmo-backend          Created                               4.1s
 ! backend                             The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested 0.0s
 ✔ Container minicpmo-frontend         Created                               0.3s
 ! frontend                            The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested 0.0s
Error response from daemon: ports are not available: exposing port UDP 0.0.0.0:50070 -> 127.0.0.1:0: listen udp 0.0.0.0:50070: bind: address already in use

The UDP 50070 is used by Microsoft Teams:

sudo lsof -iUDP:50070
Password:
COMMAND  PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
MSTeams 1587  admin   63u  IPv6 0x7eb107f2b0136495      0t0  UDP *:50070

[yaobaishen]

Workaround: Quit Microsoft Teams to release the ports for WebRTC.

[tc-mb]

@seasidedog24 很高兴收到您的issue，周末我正在改这些内容，没有第一时间看到这个issue。

1. 端口这个我改了一下，而且今天会发一个新docker，比之前轻量很多。
2. cpp的音质问题已经完全解决，问题出在几处算子上，tc-mb/llama.cpp-omni@6f370bbc8280caa49e05c2123baeaa4ade67cc3e。
3. 这个设计到和server的协同，我还没来得及全部调整，因为这个改动得整体测试一下，不像其他改动可以直接替换。这个会在接下来修复。
4. 延迟卡顿问题，我将 Token2Mel 使用改成 n_timesteps=5。

[liyimeng]

How do you fix the "Server at capacity" issue, in minicpmo_cpp_http_server.py?

[seasidedog24]

@liyimeng Hi! I encountered the same "Server at capacity" issue during my deployment. Here's what I found — it can be caused by multiple root causes depending on your deployment method:

---

Root Cause 1: Ghost session from LiveKit connection failure (Docker → native migration)

If you previously used Docker deployment and then switched to oneclick.sh (or manual native deployment), the backend config file config/local.yaml still contains the Docker-internal hostname:

livekit:
  url: "ws://livekit:7880"  # Docker Compose service name — won't resolve in native deployment!
  api_secret: "secret"       # Too short for LiveKit v1.9+ (requires >= 32 chars)

What happens: Backend tries to connect to LiveKit via ws://livekit:7880 → DNS resolution fails → the session slot gets occupied but never released → all subsequent login requests get 503: 没有可用的推理服务 → frontend shows "Server at capacity".

Fix: Either use oneclick.sh which correctly overrides via environment variables (LIVEKIT_URL=ws://localhost:7880), or manually update local.yaml:

livekit:
  url: "ws://localhost:7880"
  api_key: "devkey"
  api_secret: "secretsecretsecretsecretsecretsecret"

Full details in Issue #89 (Problem 2).

---

Root Cause 2: Heartbeat registration overwriting BUSY status

As documented in this issue (Problem 3.1), running a registration loop (while true; do curl register; sleep 30; done) will overwrite the service's BUSY status in Redis/memory, causing the resource monitor to trigger robot_exit. Don't do this. Register only once at startup.

---

Root Cause 3: Backend restart loses in-memory registration

In native deployment (non-Docker), the backend uses in-memory storage instead of Redis. If the backend process restarts for any reason, all service registrations are lost. The C++ inference server (registered at startup) won't know the backend restarted.

Quick fix: Re-register the C++ inference service manually:

LOCAL_IP=$(ipconfig getifaddr en0 2>/dev/null || hostname -I | awk '{print $1}')
curl -X POST http://localhost:8021/api/inference/register \
  -H 'Content-Type: application/json' \
  -d "{\"ip\": \"$LOCAL_IP\", \"port\": 9060, \"model_port\": 9060, \"model_type\": \"duplex\", \"session_type\": \"release\", \"service_name\": \"o45-cpp\"}"

Better fix: The minicpmo_cpp_http_server.py could implement a periodic health-check-based re-registration (not the aggressive register loop from #74, but a lightweight check: "is backend reachable AND am I not registered?" → then re-register).

---

Root Cause 4: Previous session not properly released (stuck BUSY)

The C++ inference server supports only 1 concurrent session. If a previous session crashed or the user disconnected without proper cleanup, the service stays BUSY until the heartbeat monitor's cleanup_interval (default 20s) expires.

Quick fix: Restart the C++ inference server to reset its state, then re-register:

# Kill and restart the C++ server
pkill -f minicpmo_cpp_http_server
pkill -f llama-server
# Then restart via oneclick.sh or manually

---

TL;DR: The "Server at capacity" error means the backend has no inference service with status=AVAILABLE. Check: (1) is the C++ server running and registered? (2) is LiveKit URL correct for your deployment method? (3) is there a stuck session?

[seasidedog24]

💡 Community FAQ: Common Questions & Solutions

Sharing solutions for two frequently asked questions from the community:

---

Q1: Interruption issues in duplex mode + How to default to English?

("o-4.5 with docker image. it runs fine, just some issues with interruption and I'd like to default it to English.")

Interruption fix

This is documented in this issue (Problem 3.2 & 3.3). The root cause is timing — the WAV scanner gives up too early (1s) and the is_listen detection window is too short (50ms).

Temporary fix in cpp_server/minicpmo_cpp_http_server.py:

# WAV Scanner: increase patience from 1s to 6s
max_final_wait = 15.0          # was 3.0
if no_new_wav_count >= 60:     # was 10 (= 1 second)
    break

# is_listen quick check: increase from 50ms to 8s max
while (time.time() - quick_check_start) < 8.0:   # was 0.05
    ...
    if no_wav_count >= 60:     # 6s with no new WAV → give up
        break

Note: @tc-mb mentioned in this comment that the server-side coordination changes for interruption are still being tested. The above is a temporary workaround.

Default to English

Option A — Modify system prompt (recommended):

In the C++ init flow, the system prompt is sent via /omni/init_sys_prompt. Find where system_prompt is defined (in minicpmo_cpp_http_server.py or passed as a parameter) and change it to:

Streaming Duplex Conversation! You are a helpful assistant. Always respond in English.

Option B — Frontend language parameter:

The login request includes a language field. In the frontend source (o45-frontend/), find the login API call and ensure language: "en" is being sent. This should already be the default, but check your local config.

---

Q2: Why doesn't it work on Google Colab or Kaggle?

("Would someone please explain to me why it doesn't work on Google Colab or Kaggle?")

It can work, but there are 3 major obstacles:

Obstacle	Why	Workaround
WebRTC requires HTTPS	Browsers enforce secure context for getUserMedia(). Colab can't natively serve HTTPS on custom ports.	Use ngrok / cloudflared to create an HTTPS tunnel
UDP ports blocked	LiveKit uses UDP 50000-50100 for WebRTC media transport. Colab/Kaggle restrict UDP.	Configure LiveKit to use TURN over TCP as fallback, or use LiveKit Cloud
Session instability	Colab sessions can be reclaimed at any time; model loading takes 2-3 min and would need to restart	Not fixable — it's a platform limitation

Minimal Colab approach (if you really want to try):

# 1. Install ngrok for HTTPS tunnel
!pip install pyngrok
from pyngrok import ngrok
ngrok.set_auth_token("YOUR_TOKEN")  # get from https://ngrok.com

# 2. Start services via oneclick.sh
!PYTHON_CMD=$(which python3) \
  GITHUB_PROXY="" HF_ENDPOINT="" \
  bash oneclick.sh start

# 3. Expose frontend via HTTPS tunnel
public_url = ngrok.connect(8088, "http").public_url
print(f"🌐 Access at: {public_url}")

⚠️ Realistically though, Colab/Kaggle is NOT recommended for WebRTC demos because:

• Tunnel adds 50-200ms latency on top of inference time
• UDP media transport is unreliable through tunnels
• Session can be killed mid-conversation

Better alternatives:

• GPU cloud server (AutoDL, vast.ai, Lambda) with public IP → oneclick.sh start directly
• Local machine with decent GPU (even Mac M-series works, as documented in this issue)
• Self-hosted server with Docker or native deployment

---

Hope this helps the community! For the full deployment troubleshooting guide, see:

• This issue ([WebRTC Demo] macOS M4 部署踩坑汇总与修复：端口冲突 / 电流音 / No Speech Detected + 延迟分析 #75) — macOS M4 comprehensive guide
• Issue #89 — Docker → oneclick.sh migration issues

[seasidedog24]

🔇 Noise Gate / High-Pass Filter for Duplex Mode Interruption Issues

In response to a community question about background noise causing false interruptions in duplex mode — wanting a high-pass filter or noise gate.

Problem

In duplex mode, background noise (keyboard typing, fan hum, ambient sounds) can trigger the model to think the user is speaking, causing false interruptions. The model stops its response mid-sentence.

What the code already has

Layer	Feature	Status
Frontend (useLiveKit.js L3493-3496)	WebRTC noiseSuppression: true, echoCancellation: true, autoGainControl: true	✅ Enabled
Backend (vad_utils.py L39)	Silero VAD threshold=0.7 (strict)	✅ But only used in simplex mode
Server-side audio preprocessing	High-pass filter, noise gate	❌ Not implemented

Key insight: In duplex mode, audio streams directly to the C++ inference server — it bypasses the backend's Silero VAD entirely. So the only noise protection in duplex mode is the browser's built-in WebRTC noiseSuppression, which varies in quality across browsers (Chrome > Safari > Firefox).

Solution 1: Verify browser noise suppression is working

The frontend has a built-in diagnostic. Open browser DevTools console and check the audio track settings:

// In browser console after joining a call:
const audioTrack = /* your local audio track */;
const settings = audioTrack.mediaStreamTrack.getSettings();
console.table({
    noiseSuppression: settings.noiseSuppression,  // should be true
    echoCancellation: settings.echoCancellation,   // should be true
    autoGainControl: settings.autoGainControl      // should be true
});

If noiseSuppression shows false, your browser may not support it. Try Chrome for best results.

Solution 2: Add server-side Noise Gate (amplitude-based)

Add this to the backend audio pipeline (in omni_stream.py, before sending audio to C++ server). This silences audio frames below a dB threshold — effectively a noise gate:

import numpy as np

def noise_gate(audio_bytes: bytes, threshold_db: float = -40.0) -> bytes:
    """Silence audio frames below threshold (noise gate).
    
    Args:
        audio_bytes: Raw PCM16 audio bytes
        threshold_db: Frames quieter than this (in dB) are silenced.
                     -40 dB is a good starting point.
                     Raise to -35 for noisier environments.
    """
    audio = np.frombuffer(audio_bytes, dtype=np.int16).astype(np.float32)
    if len(audio) == 0:
        return audio_bytes
    rms = np.sqrt(np.mean(audio ** 2))
    if rms == 0:
        return audio_bytes
    db = 20 * np.log10(rms / 32768.0)
    if db < threshold_db:
        return np.zeros(len(audio), dtype=np.int16).tobytes()
    return audio_bytes

Solution 3: Add High-Pass Filter (remove low-frequency noise)

Filters out frequencies below 80 Hz — eliminates air conditioner hum, fan rumble, and low-frequency vibrations that can confuse VAD:

from scipy.signal import butter, sosfilt
import numpy as np

# Pre-compute filter coefficients (do this once at startup)
_sos_cache = {}

def highpass_filter(audio_bytes: bytes, cutoff_hz: float = 80.0,
                    sample_rate: int = 48000, order: int = 4) -> bytes:
    """High-pass filter: remove low-frequency noise below cutoff.
    
    Args:
        cutoff_hz: Frequencies below this are removed. 
                   80 Hz is good for general noise.
                   300 Hz for aggressive filtering (may affect voice quality).
    """
    cache_key = (cutoff_hz, sample_rate, order)
    if cache_key not in _sos_cache:
        _sos_cache[cache_key] = butter(order, cutoff_hz, btype='highpass',
                                        fs=sample_rate, output='sos')
    audio = np.frombuffer(audio_bytes, dtype=np.int16).astype(np.float32)
    filtered = sosfilt(_sos_cache[cache_key], audio)
    return np.clip(filtered, -32768, 32767).astype(np.int16).tobytes()

Solution 4 (Recommended): Combine both

def preprocess_audio(audio_bytes: bytes, sample_rate: int = 48000) -> bytes:
    """Apply high-pass filter + noise gate before sending to C++ server."""
    audio_bytes = highpass_filter(audio_bytes, cutoff_hz=80.0, sample_rate=sample_rate)
    audio_bytes = noise_gate(audio_bytes, threshold_db=-40.0)
    return audio_bytes

Insert this into omni_stream.py's audio processing loop (_async_stream_detail), right before the audio data is forwarded to the C++ inference server.

About default language → English

To make the model respond in English by default, modify the system prompt. Find where the C++ server's system prompt is set (usually in minicpmo_cpp_http_server.py or passed via init config) and change it to:

Streaming Duplex Conversation! You are a helpful assistant. Always respond in English.

Or set the language parameter to "en" in the frontend login request.

---

Note: These audio preprocessing functions add minimal latency (~0.1ms per frame on modern hardware) and scipy is already a common dependency. For production deployment, consider using the noisereduce library for more sophisticated spectral noise reduction.

[liyimeng]

@seasidedog24 Thanks, I did a fully cleanup and run with oneclick.sh. Now I can make a call! You are a genius!

However, I am experiencing the same issue as you mentioned above. The conversation gets interrupted now and then, never get a full sentence spoke out. Do your improvements above fix the issue?