지금까지 저는 tts-bench(https://github.com/5uck1ess/tts-bench)와 블라인드 투표 아레나(https://5uck1ess-tts-arena.hf.space)를 유지 관리해 왔습니다. 이곳에서 사람들은 어떤 모델인지 모른 채 오픈 텍스트-투-스피치 (TTS) 모델을 A/B 테스트합니다. 제가 항상 해결하고 싶었던 문제 중 하나는, 작업이 완료된 후 에이전트가 저에게 말하거나(실제로 저를 부르거나) 하는 것입니다. /voice (Claude 코드 기능)나 어떤 받아쓰기(Whispr Flow 등)도 일방적입니다. 그래서 이 프로젝트는 양방향 대화 시스템입니다: https://github.com/5uck1ess/cicero Hermes Agent(https://github.com/nousresearch/hermes-agent)와 매우 잘 작동하며, 여러 프로필을 가질 수 있습니다 (각 프로필은 자체 TTS 음성 및 개성을 가질 수 있음). Claude Code, Codex, Gemini CLI 등 ACP(Agent Client Protocol)를 말하는 모든 것 또는 OpenAI 호환 엔드포인트에서 작동합니다. 만약 스피치-투-텍스트 (STT)와 TTS를 로컬에서 실행한다면, 오디오가 기기를 벗어나지 않습니다. 텔레그램 봇 메시지를 보내거나 텔레그램을 통해 전화를 걸 수 있습니다. 또한 로컬 또는 브라우저(원격 서버)를 통해 상호 작용할 수도 있습니다. 아마도 아직 버그가 있을 것이니, 자유롭게 풀 리퀘스트(PRs)나 이슈를 제출해 주세요. 이것을 구축하면서 놀라웠던 몇 가지 점들이 있었습니다: 약 1초의 응답 시간은 더 빠른 TTS 음성에서 온 것이 아니라 답변 문장을 스트리밍하는 것에서 나왔습니다. 클론팅이 안 좋은 이유는 참조 클립 때문이지 모델 때문이 아닙니다. 앞부분의 침묵을 1초 잘라내는 것이 모델을 바꾸는 것보다 훨씬 효과적이었습니다. 에너지 VAD(음량만 감지하는 음성 활동 감지)를 사용하여 에이전트가 문장 도중에 끊기는 바지인(barge-in)은 쓸모가 없습니다. 타이핑이 이를 유발합니다. 실제 발화에 의해서만 트리거되도록 앞에 작은 스피치 모델이 필요했습니다 /u/UkieTechie [링크] [댓글]