← Docs hub

SoundFlow / Kardome Echo 테스트 데이터 전체 분석

이 문서는 지금까지 모은 AEC 녹음과 로그를 정리한 자료다. 2026-10-15에 실제 재생 구간의 억압량, 외부 자료에 근거한 성능 의견, 음성 LLM의 barge-in 구성과 판정 조건을 추가했다. 새 녹음이나 barge-in 실기기 시험 결과를 추가한 것은 아니다.

실제 음성 재생 구간: 약 43 dB는 어느 정도인가?

현재 의견: 약 43 dB의 입력 대비 출력 감소는 억압량 관점에서 좋은 성능을 기대하게 하는 긍정적인 결과다. 다만 순수 AEC 성능 인증이나 barge-in 동작 보장을 뜻하지 않는다. 여기서 활성 구간은 재생 기준 신호 REF가 활성인 구간이다. 사용자가 동시에 말하는 구간을 검증했다는 뜻은 아니다.

계산값은 20 log10(RMS_MIC4ch / RMS_Kardome)이다. 약 43 dB는 이 두 디지털 신호의 RMS 비로 약 141:1에 해당한다. raw MIC 4채널과 처리 후 mono 출력 사이의 빔포밍·전처리·게인 차이를 포함하므로 이를 에코만 99.995% 제거했다거나 사용자 음성이 그만큼 선명해졌다고 해석하지 않는다. 상세 수치와 선택 기준은 아래 기존 분석에 유지했다.

일반적인 에코캔슬 성능과 비교한 자료 기반 의견

공학적 판단: 같은 경로·게인에서 에코 성분의 43 dB 제거가 검증됐다면, 제조사 공개 사양과 비교해 억압량 측면에서 좋은 수준이라고 평가할 근거가 있다. 현재 우리 결과는 그 규모에 해당하는 입력/출력 감소를 보여 주므로 긍정적으로 평가하되, 동일한 ERLE 43 dB를 확보했다고 단정하지 않는다. 위 자료는 “43 dB 이상이면 모든 제품에서 barge-in 합격”이라는 공통 기준을 제시하지 않는다.

Barge-in 목적의 현재 판정

목적은 기기가 말하는 동안 사용자가 끼어들었을 때, 재생 에코 때문에 잘못 멈추지 않고 사용자 목소리를 놓치지 않으며 빠르게 재생을 중단하고 새 명령을 인식하는 것이다. 사용자 목소리까지 작게 만드는 처리는 출력 감소량이 커도 이 목적에 맞지 않는다.

판정: 에코 억압량은 긍정적이며 barge-in 통합 시험을 진행할 근거가 있다. Barge-in 제품 성능 보장은 아직 보류한다. 합격 수치는 제품의 허용 지연·오검출 수준에 맞춰 시험 전에 정해야 하며, 여기서는 검증되지 않은 공통 dB 합격선을 만들지 않는다.

음성 LLM 솔루션은 AEC만으로 barge-in을 처리하는가?

대표적인 음성 에이전트 프레임워크는 AEC만으로 처리하지 않는다. AEC는 입력에서 재생 에코를 줄이는 역할이고, 사용자 발화 감지·끼어들기 판단·진행 중 응답 중단은 별도 역할이다. 시장 전체의 채택 비율을 조사한 결론이 아니라, 아래 공식 문서에서 확인한 구성에 근거한 판단이다.

우리 제품에 권장하는 구성 — 설계 제안, 구현 완료 판정 아님

실제 재생 PCM → AEC reference와 MIC → Kardome 처리 → 사용자 발화 감지 → 끼어들기 정책 → 재생/생성 중단을 연결한다. 사용자 오디오는 별도로 계속 수집해 STT와 다음 LLM 요청으로 전달한다.

위 표의 선행 버퍼·응답 ID·로컬 중단 구성은 공식 프레임워크의 역할 분리를 우리 기기에 적용한 설계 제안이다. 라이브러리 기본값이나 우리 코드의 현재 동작을 확인했다는 뜻은 아니다. 초기 구성은 AEC + VAD + 단순한 끼어들기 정책 + 로컬 재생 중단/큐 정리 + 생성 취소/이력 동기화가 적절하다. 먼저 이 구성의 오검출과 누락을 측정하고, 필요할 때 의미 기반 판정이나 화자/방향 정보를 보조 신호로 추가한다. 긴 LLM 판단을 기다리느라 재생 중단이 늦어지지 않도록 한다.

턴 종료 감지는 “사용자가 말을 끝냈는가”, 끼어들기 감지는 “기기가 말하는 도중 사용자가 발화를 시작했는가”를 다룬다. 같은 모델로 처리할 수도 있지만 역할과 지연 예산은 구분해야 한다. Double-talk 구간에서는 총 출력 RMS 감소량을 최대화하지 말고 사용자 인식 성공·첫 음절 보존·오검출·실제 중단 지연으로 판정한다.

우선 확인할 세 가지 시험

1. TTS만 재생: 여러 문장·음량에서 자기 목소리에 의해 중단되는 횟수와 STT 오인식을 기록한다.
2. 사용자만 발화: 같은 거리·방향·문장으로 기본 명령 성공률과 첫 음절 보존 상태를 확보한다.
3. TTS + 사용자 동시 발화: TTS 시작 직후·중간·끝부분에 “멈춰”와 일반 명령으로 끼어들고, 2번 대비 인식 저하 및 발화 시작→실제 출력 중단 지연을 측정한다. 재생 음량·거리·방향·팬 소음·화자를 기록하고 조건별로 반복한다.

현재 보고서의 약 43 dB는 이 중 음향 전처리의 긍정적인 출발점이다. 최종 barge-in 성공 여부는 위 전체 경로의 시험으로 확정한다.

OpenAI Realtime의 barge-in: AI 발화 중 사용자 감지부터 다음 응답까지

여기서 barge-in은 AI 음성이 스피커에서 재생되는 동안 사용자가 말을 시작하고, 시스템이 AI 발화를 중단해 사용자의 말을 받아들이는 동작이다. AI 발화가 끝난 뒤 다음 질문을 받는 일반적인 턴 전환과 구분한다. 이전 절은 이 중 취소·이력 보정에 집중했으므로, 아래에서 실제 발화가 겹치는 순간부터 전체 흐름을 연결한다.

AI와 사용자의 말이 겹치는 순간의 처리 흐름

다음은 OpenAI의 공개 interruption 동작과 우리 기기에 필요한 음향 전처리를 연결한 구성이다. AEC와 기기 재생 큐 제어는 제품 구성에 관한 제안이며, OpenAI 서버가 우리 기기의 에코 제거를 보장한다는 뜻은 아니다.

OpenAI 공식 문서는 이를 Handling interruptions라는 이름으로 설명한다. VAD의 interrupt_response는 사용자 발화 시작에 따른 응답 중단을, create_response는 사용자 발화 종료 후 자동 응답 생성을 제어한다. OpenAI interruption 흐름, VAD 설정

따라서 프롬프트·이력 처리는 barge-in 전체 중 “중단된 응답을 정리하고 다음 대화를 이어가는 부분”이다. 사용자를 감지하고 스피커를 멈추는 기능까지 프롬프트만으로 구현하는 것은 아니다. 아래 내용은 2026-10-15에 확인한 공개 Realtime API 동작이며, ChatGPT 음성 모드의 비공개 내부 프롬프트를 확인한 것은 아니다.

공식 문서로 확인되는 처리

근거: Realtime conversations — 기본 conversation과 interruption, VAD — 자동 응답·중단 설정, Client events — response.cancel / conversation.item.truncate.

연결 방식에 따라 누가 처리하는가?

근거: OpenAI — Handling interruptions. 오디오와 텍스트가 정확히 정렬되지는 않으므로, truncate가 들은 부분의 정확한 문장 전사까지 반환한다고 가정하면 안 된다.

Barge-in 예시: AI가 말하는 도중 사용자가 발언권을 가져오는 경우

아래 문장과 시간은 동작 설명용 가상 예시이며 실측값이 아니다.

WebSocket에서 재생기가 실제 재생 위치를 1,500ms로 보고한 경우의 truncate 이벤트 예시는 다음과 같다. item_id는 실제 assistant 항목 ID로 바꿔야 하며, 시간은 수신량이나 생성량이 아닌 재생량을 기준으로 한다.

{
  "type": "conversation.item.truncate",
  "item_id": "item_assistant_example",
  "content_index": 0,
  "audio_end_ms": 1500
}

진행 중 생성이 있으면 설정에 따른 자동 취소 또는 response.cancel을 사용한다. 응답이 이미 모두 생성됐다면 로컬에 남은 오디오의 중단·이력 보정이 여전히 필요하다. truncate 성공은 conversation.item.truncated로 확인할 수 있다. 공식 이벤트 정의

프롬프트에는 무엇을 추가하는 것이 적절한가?

아래는 우리 제품에 적용할 수 있는 보조 지침 예시다. OpenAI의 숨겨진 프롬프트나 필수 표준 문구가 아니다.

사용자가 끼어들면 최신 요청을 우선해 답한다. 중단된 설명을 임의로 처음부터 반복하지 않는다. 전달 여부가 확인되지 않은 설명을 사용자가 이미 들었다고 가정하지 않는다. 실행 결과는 실제 도구 결과를 기준으로 설명한다.

이 지침은 답변 방식을 정할 뿐, 스피커 중단이나 이력 삭제를 실행하지 않는다. 자체 STT → LLM → TTS 구성에서는 다음 정보를 애플리케이션에서 관리하는 방식을 제안한다.

현재 약 43 dB의 감소량은 음향 입력 품질에 대한 근거다. 자연스러운 barge-in에는 여기에 발화 감지, 재생·생성 중단, 실제 전달 상태에 맞는 대화 이력 관리가 함께 필요하다. 위 구성은 설계 제안이며, 현재 제품 코드에 구현됐거나 실기기에서 검증됐다는 의미는 아니다.

기존 버전 비교와 상세 측정

먼저 보는 결론: 사용자는 실제 사용 중 Ding 효과음 뒤에 들리던 echo가 v1.1.18에서 많이 줄었다고 보고했다. 같은 명령으로 분류된 버전별 녹음 한 쌍에서도 v1.1.18 처리 출력이 더 작고, 전체 구간을 합친 계산값은 4.45 dB 높았다. 체감과 측정 신호가 모두 v1.1.18에 유리한 방향이다. 따라서 현재 Ding 사용에서는 v1.1.18을 더 나은 선택으로 판단한다. 아래 수치는 Ding만 따로 고정해 반복 비교한 결과가 아니므로, 개선량을 “항상 4.45 dB”라고 읽지는 않는다.

한눈에 보는 결과

1. 측정 숫자를 쉽게 읽는 법

재생 소리는 기준 신호(REF), 마이크에 들어온 소리는 MIC, Kardome가 처리해 내보낸 소리는 Kardome 출력으로 표시했다. 이 보고서의 dB 값은 같은 녹음 시점에서 MIC 소리 크기와 Kardome 출력 소리 크기를 비교한 값이다. 숫자가 크면 이 자료에서 Kardome 출력이 MIC 입력보다 작게 잡혔다는 뜻이다.

이 값은 표준 ERLE 그 자체가 아니다. 마이크 원본과 처리된 출력 사이에는 채널 수와 빔포밍·전처리·음량 차이도 있을 수 있기 때문이다. 아래에서는 계산에 사용한 정확한 이름을 “MIC 대비 Kardome 출력 레벨 차이”로 부른다. Ding 체감과 버전 비교를 이해하는 데 필요한 요약은 위 결론에 두고, 계산 세부사항은 이 절과 각 표에 남겼다.

2. 계산 방법

입력과 동기화

주요 버전 비교와 v1.1.18 명령 분석에는 통합 sndflow_allinout를 사용했다. 이 파일은 16 kHz, 8채널 float32이며 저장 경로 기준 채널 순서는 MIC 4채널, REF 2채널, outkardome 1채널, outuser 1채널이다. 같은 프레임 안의 채널을 비교해 별도 WAV 사이의 시작 시각 차이를 계산에 끌어들이지 않았다.

RMS와 REF 활성 프레임

각 250 ms 프레임(16 kHz에서 4,000 샘플)에 대해 다음 신호를 계산했다.

• MIC power: MIC 채널 4개의 제곱전력 평균
• REF: REF 두 채널을 샘플별 평균한 모노 신호
• Kardome out: outkardome 채널
• outuser: 보조 산출물이므로 MIC-to-Kardome proxy 계산에는 사용하지 않음

REF 모노 RMS가 0.01보다 큰 짧은 구간만 주 비교에 넣었다. 조용한 구간이 결과를 섞지 않게 하려는 이 분석의 선택 기준이다. 기준을 0.005로 낮춘 계산도 함께 제시해 선택에 따라 결과가 얼마나 달라지는지 확인했다.

RMS = sqrt(mean(x²))

MIC 대비 Kardome 출력 레벨 차이 (dB) = 20 log10(RMS_MIC4ch / RMS_Kardome)

주의: 이 dB는 Kardome 출력의 음량 자체가 아니라 MIC와 출력의 차이를 나타낸다. 그래서 이 비율은 숫자가 커질수록 분모인 Kardome 출력이 더 작다는 뜻이다. 출력 음량 자체를 비교할 때는 dBFS를 보며, 값이 더 낮고(더 음수이고) 작을수록 소리가 작다.

“전체 구간 합산”은 선택된 모든 샘플의 입력 전력과 출력 전력을 먼저 합쳐 비교한다. “짧은 구간 평균”은 각 250 ms 구간의 dB 값을 구한 다음 각 구간에 같은 비중을 줘 평균한다. 둘은 계산 순서가 달라 결과도 다를 수 있어 함께 표시했다.

재생 소리가 마이크에도 들어왔는지 확인

재생 신호와 마이크 파형이 얼마나 비슷하게 움직였는지 상관값으로 확인했다. 이 값은 재생음이 마이크에 들어왔는지를 살피는 참고 자료다. 상관값만으로 echo만 녹음됐거나 AEC 처리 전후의 동일 신호를 비교했다고 증명할 수는 없다.

3. v1.1.17과 v1.1.18: 같은 명령 녹음 비교

각각 공기 청정기 켜줘로 분류된 통합 WAV 한 개씩을 비교했다. v1.1.17은 2026-08-13, v1.1.18은 2026-09-02 녹음이며 REF RMS > 0.01 유효 시간은 각각 4.50초와 5.25초다.

두 번째 그래프는 50 ms 단위 REF/MIC/Kardome 출력 RMS envelope를 시간축으로 겹쳐 보여주며, 배경 음영은 REF 활성으로 선택한 구간이다. 특정 순간의 피크 한 개보다 발화 구간 전체의 레벨 변화가 보이도록 했다.

그래프 읽기: 전체 활성 구간을 합친 MIC 대비 출력 레벨 차이는 v1.1.18 쪽이 4.45 dB 더 크다. 이는 출력 음량이 커졌다는 뜻이 아니다. 바로 아래 RMS 표에서 Kardome 출력은 v1.1.18이 −86.51 dBFS, v1.1.17이 −83.54 dBFS로 v1.1.18 출력이 2.97 dB 더 작다. 짧은 250 ms 구간마다 같은 비중을 주면 레벨 차이의 차이는 0.42 dB로 작아지고, 조용한 구간을 더 포함하면 평균 방향이 달라질 수 있다. 즉 39.41 dB는 소리 크기 값이 아니라 이 두 녹음의 MIC 대비 출력 레벨 차이다.

활성 프레임 전체에서 REF RMS는 0.025305와 0.024997로 비슷했다. MIC 4ch RMS는 v1.1.18이 1.47 dB 높고, Kardome 출력 RMS는 2.97 dB 낮았다. REF–MIC 최대 지연 탐색 상관 중앙값은 각각 0.731, 0.740이며 중앙 지연은 두 자료 모두 약 2 ms였다. 각 파일 한 건이며 녹음 일자와 acoustic 조건도 고정됐다고 입증되지 않았다.

4. v1.1.18 명령 시나리오 다섯 건

2026-09-02 자료의 통합 WAV 5건을 REF RMS > 0.01 기준으로 각각 분석했다. 다섯 개는 서로 다른 발화이며 동일 음성의 반복 측정이 아니다.

구간 선택 기준을 REF RMS > 0.005로 낮추면 시나리오 평균은 42.34 dB, 전체 구간 합산값은 42.13 dB였다. 구간을 어디서부터 포함하는지에 따라 숫자가 달라질 수 있음을 보여준다. 다섯 로그 모두 녹음 파일 저장은 확인됐지만 Test KWS Count: 0이므로 음성 인식 성공을 측정한 자료는 아니다.

5. 사용자가 제공한 실제 녹음

입력은 2026-09-23의 46.144초 sndflow_allinout이고, 사용자가 지정한 4–9초·20–25초·35–40초를 그대로 비교했다.

두 유효 구간의 단순 평균은 43.57 dB다. 35–40초의 MIC RMS는 REF가 비활성인 기준 31–33초의 0.000412와 약 1.9 dB만 차이 난다. 초기 출력 과도 성분 이후 36–40초만 계산하면 30.55 dB이지만 MIC가 여전히 바닥에 있어 이를 유효 AEC 결과로 올리지 않았다. 여기서도 동일 녹음 내부 구간 두 개를 독립 반복 2회로 세지 않는다.

6. 앱 TTS 진단 녹음: 스피커 소리가 실제로 나왔는지

2026-09-23 TTS 진단은 기기 사용자가 스피커 소리를 듣지 못했다고 보고한 상태에서 이뤄졌다. AudioFlinger에는 speaker route와 디지털 출력 프레임이 있었지만, HAL underrun 및 speaker calibration 관련 경고도 남았다. 따라서 REF가 기록됐다는 사실만으로 실제 스피커에서 음향 출력이 났다고 보지 않았다.

MIC가 REF와 강하게 맞물리는 echo 성분을 보이지 않고 무음/바닥 수준에 가까웠다. 그러므로 이 캡처는 “AEC가 이 정도 감쇠했다”는 성능 지표가 아니라 스피커·음향 경로의 검증이 필요한 진단 자료다. 세 진단 녹음 모두 v1.1.18로 기록됐지만 TTS 문장 단독·고정 음량·사용자 발화 분리 조건은 충족하지 않았다.

7. Ding/효과음 버전 흐름: v1.1.14 → v1.1.17 → v1.1.18

과거 효과음 시험은 v1.1.14에서 약 34.0 dB, 연속성 패치가 적용된 v1.1.17에서 약 33.1 dB로 기록됐다. 실제 F2 캡처도 v1.1.17 패치 자료이며, 기준 신호 최대 구간 −50.84 dBFS와 처리 출력 −78.33 dBFS 사이에 27.49 dB 차이가 보고됐다. raw MIC와 기준 신호는 약 30–37.5 ms 지연에서 상관을 보였고, 처리 출력과 기준 신호의 상관은 0.04였다.

가장 최근 버전인 v1.1.18에서는 사용자가 실제 Ding echo가 많이 줄었다고 보고했다. 별도의 같은 명령 비교에서는 MIC 대비 출력 레벨 차이가 v1.1.17의 34.96 dB에서 v1.1.18의 39.41 dB로 커졌다. 이 값은 출력 음량 자체가 아니다. 실제 Kardome 출력 RMS는 v1.1.17 −83.54 dBFS, v1.1.18 −86.51 dBFS로 v1.1.18에서 더 작게 기록됐다. 다만 이 한 쌍은 Ding만 따로 반복 측정한 결과는 아니다.

읽는 법: 오른쪽은 같은 명령 비교에서 기록된 Kardome 출력 자체의 크기다. dBFS가 더 낮은 v1.1.18 막대가 더 조용한 출력이다. 왼쪽의 과거 dB 값은 다른 시험에서 계산한 출력 감소량이므로 오른쪽 값과 높이를 직접 비교하면 안 된다. 실제 F2 수치가 확보된 마지막 캡처는 v1.1.17이고, v1.1.18의 Ding echo 감소는 사용자의 체감 보고와 별도 비교 녹음으로 구분해 기록했다.

8. 최종 판단과 숫자의 범위

현재 결론

사용자가 들은 Ding echo 감소와 같은 명령 녹음의 출력 감소 방향을 함께 보면, 이번 실제 사용 조건에서는 Kardome v1.1.18이 v1.1.17보다 더 나은 것으로 판단한다. v1.1.18의 다섯 명령과 실제 녹음에서도 MIC 대비 Kardome 출력이 낮게 관측됐다. 따라서 현장 적용 판단은 v1.1.18을 우선하는 쪽이다.

숫자를 정확히 해석하기

보고서의 dB 수치는 MIC 대비 Kardome 출력 레벨 차이다. 표준 ERLE는 echo 제거 전후의 같은 처리 경로 신호를 비교해야 한다. 이번 계산의 raw MIC 4채널과 Kardome mono 출력 사이에는 빔포밍·전처리·음량 차이가 포함될 수 있어 이 값을 표준 ERLE와 같다고 부르지는 않는다. ITU-T G.168, AEC Challenge

기존 비교 파일은 v1.1.17과 v1.1.18 각각 한 건이며 폴더 이름을 기준으로 분류했다. v1.1.16과 v1.1.18의 직접 비교는 아니다. 지금 자료로는 “이번 Ding 사용 및 보유 녹음에서 v1.1.18이 더 나은 방향을 보였다”고 판단할 수 있고, +4.45 dB를 모든 환경의 고정 개선량이나 표준 ERLE로 해석하지 않는다.

9. 데이터 묶음과 재현 방법

현재 발견된 원본 WAV·동반 로그·분석 문서를 출처별 디렉터리에 복사하고 파일별 SHA-256을 포함한 아카이브를 만들었다. 캡처 원본은 변경하지 않았다. 이 공유 묶음은 내부 작업공간에 보관하며, 공개 Wiki에는 오디오 원본·logcat을 넣지 않고 요약·분석 그래프만 게시한다.

• 묶음 디렉터리: echo_test/share/kardome_echo_test_bundle_20261008/
• 압축 파일: echo_test/share/kardome_echo_test_bundle_20261008.zip
• 체크섬/파일 출처: MANIFEST.csv, SHA256SUMS.txt
• 1.1.17/1.1.18 분석 재실행: analysis/compare_kardome_v117_v118.py
• 전체 상세 분석 그래프 재생성: analysis/build_detailed_dataset_charts.py
• 이전 통합 결과: SoundFlow/Kardome 원본·Mesh Mini 분석

버전 폴더명은 캡처 파일의 분류 정보이지, 캡처 당시 라이브러리 버전의 런타임 readback은 아니다. 엄밀한 v1.1.16↔v1.1.18 비교에는 v1.1.16 녹음과 실행 당시 버전 증거를 추가해야 한다.