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

요약

리눅스에서 따로 드라이버를 설치하지 않고 이더넷으로 연결하는 6입력·8출력 오디오 인터페이스 ETH-68이 공개됐습니다.

개발자 알렉스 로웰이 개인 프로젝트로 만든 1U 크기의 19인치 랙 장비입니다. STM32H7 마이크로컨트롤러의 펌웨어가 netJACK1(JACK 오디오 서버를 네트워크로 잇는 방식)의 마스터처럼 동작해서 커널 드라이버 없이 JACK과 PipeWire에 바로 연결됩니다.

왜 중요한가

리눅스에서 오디오 장비를 쓸 때 걸림돌인 드라이버 개발을 기존 네트워크 방식을 흉내 내는 것으로 피했습니다.
64샘플 버퍼에서 왕복 지연이 3.62ms입니다. 작성자는 RME HDSPe AIO Pro 같은 PCIe 카드와 비슷한 수준이라고 밝혔습니다.
AVB/TSN(오디오 전송용 네트워크 표준) 장비 없이 일반 스위치와 Intel I210 랜카드로 구성할 수 있습니다.

핵심 내용

1/4인치 TRS 밸런스 입력 6개와 출력 8개, DIN MIDI 단자를 갖췄고 48kHz와 96kHz를 지원합니다.
JACK은 jackd -d netone으로, PipeWire는 전용 클라이언트 pw-eth68로 연결하며 두 방식의 지연은 같았습니다.
여러 대를 쓸 때는 BNC 단자로 클록을 이어 맞추며, 두 대로 시험했을 때 출력 사이 어긋남이 1µs 미만이었습니다.
입력 THD+N(왜곡과 잡음을 합친 지표)은 1kHz에서 -94.8dBFS로 데이터시트의 일반값보다 조금 나았습니다.
다른 트래픽이 오디오 패킷을 늦추지 않도록 오디오 전용 네트워크를 따로 두기를 권합니다.

HN 반응

작성자는 ETH-68의 클록 하나에 모든 처리를 맞춘다고 설명했지만, 다른 인터페이스와 함께 쓰면 리샘플러를 거쳐 지연이 늘 수 있다는 지적이 나왔습니다.
오래된 PCM3168A 코덱과 44.1kHz 미지원을 아쉬워하는 댓글에, 작성자는 다음 버전에서 44.1/88.2kHz를 지원하고 다른 코덱도 검토하겠다고 답했습니다.

30개 표시 · 전체 100개

alowell1일 전 HN

안녕하세요, ETH-68을 만든 Alex입니다. 이 글을 HN에 올린 건 제가 아니지만, 댓글에 나온 질문들에는 제가 답해 보겠습니다.
Gracana12시간 전 HN
참고로 말씀드리면, 이 도메인이 클라우드플레어에서 "newly seen(새로 확인된 도메인)"으로 분류돼 있어서 Ubiquiti Unifi 도메인 필터링에 차단됩니다.
```
  $ dig NS naturalsystems.io @1.1.1.1
  [...]
  ;; WARNING: recursion requested but not available
  [...]
  ;; AUTHORITY SECTION:
  naturalsystems.io.      3600    IN      SOA     block.unifi.local. 0. 7200 900 1209600 86400 0
```
아래 링크에서 재분류를 신청하실 수 있습니다.

https://radar.cloudflare.com/domains/feedback/naturalsystems.io
alfanick12시간 전 HN

그건 사용자 쪽 문제 아닌가요? 작은 틈새 사이트 운영자가 왜 Ubiquiti 같은 독점 시스템까지 신경 써야 하죠?
Gracana11시간 전 HN

글쎄요, 제가 싫어하는 한심한 상황이고 저희 회사(그리고 비슷하게 구성한 다른 많은 곳)가 만든 문제인 건 맞습니다. 그래도 클릭 두 번이면 카테고리를 골라서, 이런 방화벽 뒤에 있는 사람들도 접속할 수 있게 해 줄 수 있어요.

블로그처럼 보여서 "blog"를 골라 뒀습니다. "newly seen domains" 카테고리는 30일이 지나면 저절로 풀린다고 하니 어차피 해결되긴 했겠지만, 그때는 "uncategorized(미분류)"가 되어서 여전히 차단됐을 거예요.
olpad11시간 전 HN

이거 오픈 소스인가요? 저는 좀 더 전통적인 USB 오디오 인터페이스 쪽에서 https://codeberg.org/olpad/openmic 을 만들고 있는데, ETH-68의 내부 구조를 한번 보고 싶습니다.
NewJazz18시간 전 HN

실제로 판매하나요? 아니면 구할 방법이 따로 있나요?
jhallenworld1일 전 HN

수신 쪽은 송신 쪽의 샘플 클럭을 어떻게 복원하나요? "여러 대"가 클럭을 공유하도록 BNC 단자가 달려 있던데, 송신과 수신 사이에서도 그게 쓰이는지, 꼭 필요한지는 잘 모르겠습니다.

아니면 그런 동기화가 아예 없어서 장시간 쓰면 드리프트가 생기나요?
alowell1일 전 HN

클럭 관련 질문이 계속 나오니 이 부분을 다루는 블로그 글을 써야 할 것 같습니다. 일단 간단히 답하면, 클럭은 ETH-68의 클럭 하나뿐입니다. 전체 데이터 흐름이 푸시 방식이라, 새 데이터 버퍼가 리눅스 호스트에 도착하는 것 자체가 오디오 그래프 평가를 예약하는 클럭 이벤트입니다. 리눅스 호스트에 다른 클럭은 필요 없습니다.
pajko16시간 전 HN

오디오를 ETH-68의 클럭으로 샘플링하지 않는 이상 오래 쓰면 안 됩니다. 예를 들어 Farrow 필터로 계속 리샘플링하면서 루프를 끊임없이 조정해 주는 경우라면 모를까요.
zokier1일 전 HN

리눅스 호스트에 다른 클럭은 필요 없습니다

그건 eth68이 유일한 인터페이스일 때만 되는 얘기 아닌가요? 다른 인터페이스도 같이 쓰고 싶을 때가 많은데, 그런 것들은 원래 자기 클럭을 갖고 있잖아요.
alowell23시간 전 HN

어느 정도는 맞습니다. 다만 PipeWire나 JACK의 리샘플러(zalsa_in/zalsa_out)를 활용하면 여러 인터페이스를 같은 그래프에서 쓸 수 있을 겁니다. 리샘플러를 거치면 오디오 지연 시간이 어느 정도 늘어나리라 예상합니다.
delis-thumbs-7e15시간 전 HN

제대로 동작하는 오픈 소스 Dante가 있다면 아주 멋질 겁니다. 하드웨어가 항상 종속시키니 얼마나 쓰일지는 모르겠지만, 소규모 스튜디오나 연구용으로는 괜찮을 수 있겠네요. 어쨌든 흥미로운 프로젝트입니다.
blep-arsh13시간 전 HN

AVB도 있긴 한데, 이것도 네트워크 스위치에 특정 기능이 있어야 합니다...
lukeh12시간 전 HN

그리고 AES67도 있죠. PipeWire가 지원하는 걸로 알고 있습니다.
Neywiny1일 전 HN

H7으로 만든 걸 말리려는 건 아니지만, 코덱 선택은 의문입니다. 최상급과는 거리가 먼 데다 설계가 공간에 쪼들리는 것도 아니잖아요. TI에는 훨씬 나은 제품이 있습니다(ADC는 SNR이 거의 20dB 더 높습니다). 2세대에서는 더 좋은 코덱을 쓰면 좋겠네요.
mrheosuper20시간 전 HN

TI 연산 증폭기 소동을 겪고 나서는, TI 부품은 절대 못 믿겠어요.

수정: 맥락은 이쪽을 보세요: https://www.eevblog.com/forum/chat/ti-ne5532-audio-opamp-changes/
alowell18시간 전 HN

5532를 망친 건 저도 압니다. 하지만 TI 부품을 전부 보이콧하면 살기가 퍽퍽해질 겁니다.
RobotToaster11시간 전 HN

연산 증폭기를 엔시티피케이션(enshittification)할 방법을 기어이 찾아냈다고요?
MrBuddyCasino17시간 전 HN

세상에. TI가 이런 짓을 할 줄은 몰랐네요. 말도 안 돼요.
alowell1일 전 HN

네, 오래된 코덱이긴 하지만 약 20년 동안 안정적으로 양산돼 왔고, 비용 대비 채널 수가 많습니다. 사양이 최신은 아니어도, 제가 오래 써 온 Saffire Pro 40과 비슷한 성능이 나옵니다.

다음 프로젝트에는 다른 코덱들을 눈여겨보고 있습니다.
alowell22시간 전 HN

STM32H7에 대해 하신 말씀이 어떤 뜻인지 궁금합니다. 제 경험으로는 다루기 까다로운 부품이었거든요. HAL 버그 탓이 적지 않았고, 특히 이더넷 구현이 그랬습니다. 하지만 일단 제대로 돌아가기 시작하면 성능은 꽤 좋습니다.
Neywiny12시간 전 HN

아, 그냥 대학 때 써 봤고, 그걸로 설계도 하나 만들었고(조립은 안 해서 부품은 아직 봉투에 들어 있어요), 몇 년째 업무에서도 써 왔다는 얘기입니다. HAL에 버그가 있는 건 분명한데 저는 우회하기 쉬웠어요. 다만 이더넷 주변장치는 써 본 적이 없습니다. 그 외에는 필요하면 레지스터를 직접 다루는 것도 어렵지 않았고요.
lukeh22시간 전 HN

이것도 관심 있으실 만합니다: https://github.com/kebag-logic/pipewire
landgenoot18시간 전 HN

정말 멋지네요. 다만 어디에 쓰는 건지 잘 모르겠습니다. 별도의 LAN이 필요하다는 건, 결국 CAT6로 오디오를 보내는 거라는 말인가요?

오해는 마세요. 진심으로 이해해 보려는 겁니다.

이더넷을 통한 pipewire와는 어떻게 다른가요? 실시간 방식과 버퍼링 방식의 차이인가요?
nine_k18시간 전 HN

하드웨어 오디오 인터페이스입니다. 지연 시간이 아주 짧고(버퍼 64샘플, 3.6ms), 글에 있는 사진처럼 이더넷으로 PipeWire와 JACK을 모두 지원합니다. 말씀하신 대로 CAT6로 오디오를 보내는 건데, 그 양이 상당합니다. 48kHz나 96kHz로 입력 6채널에 출력 8채널(TRS 밸런스드)이에요.

무대 위 아날로그 장비 바로 옆에 이걸 두고, 컴퓨터는 50m 떨어진 곳에 둔다고 상상해 보세요.

(논의 중인 페이지를 직접 열어 보니 도움이 됐습니다. 이런 내용이 맨 위에 다 나와 있거든요.)
NewJazz18시간 전 HN

네, 저는 전통적인 USB 오디오 인터페이스 중에서 USB4의 PCIe 지원을 써서 지연 시간을 극단적으로 낮춘 제품이 나오기를 기다리고 있었어요.

하지만 이쪽이 더 효과적일 수도 있겠네요.

라이브용 오디오 DSP 말고도 비주얼라이저 용도가 있겠고요.
iso163117시간 전 HN

이건 아래 같은 표준 기반 시스템과는 뭐가 다른가요?

https://github.com/bondagit/aes67-linux-daemon
zokier16시간 전 HN

제가 알기로 프로 오디오 표준은 거의 다 타이밍에 ptp가 필요하고, 그러면 NIC와 스위치에도 요구 사항이 생길 수 있습니다. 반면 글에 언급된 i210 NIC는 (g)ptp/phc/tsn 등을 완전히 지원합니다.
justincormack12시간 전 HN

NIC의 ptp 지원은 점점 널리 퍼지고 있는데, 스위치는 아직 그렇지 않은 것 같습니다.
iso163113시간 전 HN

서로 다른 장치 사이에서 낮고 일정한 지연 시간을 원한다면 ptp가 필요합니다.

Hacker News에서 보기 ↗