ETH-68: Linux용 이더넷 오디오 인터페이스

ETH-68을 만든 Alex임. HN에 글을 올린 당사자는 아니지만 댓글에 나온 질문에 답하려고 함.

앞으로 PTP를 통한 클록 동기화도 지원할 계획인지?

실제로 판매 중인지, 아니면 다른 방법으로 구할 수 있는지?

XLR을 쓰지 않은 이유가 무엇인지?

글의 마지막 사진에 나온 키보드는 어떤 제품인지?

MIDI도 탑재한 이유가 무엇인지?

흥미롭지만 사용 목적을 잘 이해하지 못하겠음. 별도 LAN이 필요하다면 결국 CAT6로 오디오를 보내는 장치인지?
실제로 이해하고 싶어서 묻는 질문임. 이더넷을 통한 PipeWire와는 어떻게 다른지? 실시간 처리와 버퍼링의 차이인지?

64샘플 버퍼, 3.6ms의 낮은 지연을 제공하는 하드웨어 오디오 인터페이스임. 본문 사진처럼 이더넷을 통해 PipeWire와 JACK을 모두 지원하며, CAT6로 48kHz 또는 96kHz의 입력 6채널·출력 8채널을 전송함. 단자는 밸런스드 TRS임.
무대의 아날로그 장비 바로 옆에 이 장치를 두고, 컴퓨터는 50m 떨어진 곳에 둔다고 생각하면 됨. 본문 맨 위에도 이 정보가 나와 있음.

별도 LAN이 필수는 아님. 다만 전용 LAN을 쓰면 다른 트래픽이 시간에 민감한 오디오 패킷을 지연시키는 일을 줄일 수 있음.
ETH-68은 PipeWire나 Linux를 실행하지 않으므로 질문을 제대로 이해했는지 모르겠음. 실시간과 버퍼링의 차이라는 표현도 조금 더 설명해 줄 수 있는지?

전문 음향에서는 네트워크 오디오를 점점 더 많이 사용함. 무대의 악기와 마이크 신호를 관객석 중간의 메인 믹싱 위치, 무대 옆 모니터 믹싱 위치, 중계차 등으로 보내는 데 유용함.
기존의 아날로그 분배 방식은 마이크 등을 스테이지 박스에 연결하고, 신호별 전선 쌍이 들어 있는 굵은 케이블과 분배함을 거쳐 각 믹서까지 전달함. 케이블이 수백 미터에 달하고 매우 무거워 제작·유지보수·취급 비용이 크지만, 여러 장비가 무대의 마이크 신호를 병렬로 받는 단순한 구조임.
네트워크 방식은 무대의 장치가 아날로그 오디오를 디지털 오디오가 담긴 프레임으로 바꿔 스위치에 보냄. 이더넷이나 유사 기술을 쓰지만 반드시 IP를 사용하는 것은 아님. 가는 네트워크 케이블로 여러 목적지에 연결하고, 스위치를 연쇄 연결하거나 중간에 채널을 추가할 수 있으며 양방향 전송도 가능함. 단말 장비는 여전히 비싸지만 Cat6나 광케이블은 거대한 아날로그 케이블보다 저렴하고, 신뢰할 수 있는 공연장 배선도 활용할 수 있음. 여건이 맞으면 외부 스튜디오까지 광회선으로 연결하거나, 위험을 감수하고 공유 IP 회선을 쓸 수도 있음.
대신 지연과 클록 동기화가 복잡해짐. 가수가 자신의 목소리를 듣는 모니터에 지연이 크면 노래에 직접 지장을 줌. 패킷을 연속적인 아날로그 신호로 바꾸려면 거의 항상 버퍼가 필요하며, 이를 작게 유지하려면 모든 지점이 정밀한 타이밍을 공유해야 함. 기존 시스템은 PTP 등을 사용하고, 단말의 핵심 처리는 FPGA가 맡는 경우가 많음. 그 대가로 Dante처럼 기가비트 이더넷 한 회선에 48kHz·24비트 오디오 수백 채널을 실을 수 있음.
ETH-68은 더 작고 저렴한 접근법임. STM32H7으로 네트워크 전송과 ADC·DAC 사이를 연결하고, Linux 녹음·공연 환경에서 흔히 쓰는 오픈소스 JACK과 연동하도록 설계되어 Reaper 같은 소프트웨어와 통합하기 쉬움. 명시된 3.620ms 지연은 소리가 공기 중에서 약 1.2m 이동하는 시간으로, 충분히 실용적임. 직접 쓸 일은 없을 듯하지만 멋진 프로젝트임.

수신 측은 송신 측의 샘플 클록을 어떻게 복원하는지? 여러 장치의 클록 공유용 BNC는 있지만 송수신 사이에서도 쓰는지, 필수인지 모르겠음.
동기화하지 않는다면 장기적으로 클록이 어긋나지 않는지?

클록 관련 질문을 정리한 블로그 글을 써야 할 듯함. 짧게 답하면 클록은 ETH-68의 것 하나뿐임.
전체 데이터 흐름은 밀어넣기 방식이며, Linux 호스트에 새 데이터 버퍼가 도착하는 사건 자체가 오디오 그래프 연산을 예약하는 클록 역할을 함. 따라서 Linux 호스트에 별도 클록이 필요하지 않음.

H7 프로젝트를 말리고 싶지는 않지만 코덱 선택에는 의문이 듦. 최상급과는 거리가 있고 공간이 빠듯한 설계도 아닌데, TI에는 ADC 신호 대 잡음비가 거의 20dB 더 높은 제품도 있음. 2세대에서는 더 좋은 코덱을 쓰면 좋겠음.

https://semiengineering.com/latency-considerations-for-1-6t-...를 보면, 적어도 글에서 말하는 16000TbaseT에서는 해당 대역폭의 데이터 처리 때문에 구리·광섬유 전파 지연과 전송 시간에 약 150%의 추가 지연이 붙는 듯함.
100·1000·2500·10000에서도 같은 현상이 있는지 궁금함. DDR 성능 조정에서도 응답 시간 증가를 감수하면 최대 속도를 얻고, 지연을 줄이려면 대역폭을 포기하는 절충이 존재함. 둘 다 구리선을 통한 통신에 사실상 같은 전략을 사용함.

안타깝게도 H7에는 기가비트 MAC이 없음. USB 고속 호스트를 통해 구현해도 도움이 안 될 듯하지만, 흥미로운 실험은 될 것 같음.

1G는 오디오 지연이 아니라 처리 지연을 상당히 줄여줄 것임. STM32H7에는 1G MAC이 없고, 다루기 쉬운 마이크로컨트롤러에서도 드문 기능임. 다만 다음 프로젝트를 위해 최소 두 제품을 검토 중임.