오디오 인터페이스를 랜선으로 연결한다고?
오디오 인터페이스가 뭐냐면, 마이크나 기타 소리를 컴퓨터로 넣어주고 컴퓨터 소리를 스피커나 헤드폰으로 내보내주는 외부 장치예요. 홈레코딩이나 팟캐스트를 해봤다면 책상 위에 노브 달린 작은 박스 하나쯤 있으실 거예요. 보통은 USB나 썬더볼트로 연결하죠.
Natural Systems가 공개한 ETH-68은 이름처럼 이더넷(랜선)으로 연결하는 오디오 인터페이스인데, 무엇보다 처음부터 리눅스를 겨냥해서 만들었다는 점이 눈에 띄어요. 채널 구성, 가격, 지원 기능 같은 상세 사양은 원문 페이지에 정리돼 있으니 관심 있는 분은 직접 확인해보세요. 이 글에서는 이런 장비가 왜 의미 있는지, 이더넷 오디오가 어떻게 동작하는지를 풀어볼게요.
리눅스 음악 작업자들의 오랜 서러움
리눅스로 음악이나 오디오 작업을 해봤다면 공감하실 텐데요. 오디오 인터페이스 대부분이 USB 오디오 표준(UAC)을 따라서 꽂으면 소리는 일단 나요. 문제는 그다음이에요. 내부 믹서, 입력 라우팅, 이펙트 같은 설정은 제조사 전용 앱으로만 바꿀 수 있는데, 그 앱이 거의 다 윈도우와 맥용이거든요. 설정 하나 바꾸려고 다른 컴퓨터를 켜야 하는 웃픈 상황이 생기는 거죠. 리눅스를 '공식 지원 대상'으로 놓고 만든 장비가 귀한 이유예요.
이더넷 오디오는 어떻게 동작할까
디지털 오디오는 1초에 48,000번쯤 소리의 크기를 재서 숫자로 적어둔 데이터예요(이걸 샘플레이트라고 해요). 이걸 네트워크로 보내려면 큰 문제 두 가지를 풀어야 해요.
첫째는 늦게 오는 패킷이에요. 웹페이지는 데이터가 0.1초 늦게 와도 괜찮지만, 오디오는 제때 안 오면 '틱' 하고 끊겨버려요. 그래서 받는 쪽에 버퍼를 둬서 패킷이 좀 늦어도 버티게 해요. 물탱크를 생각하면 쉬운데, 탱크가 크면 물 공급이 잠깐 끊겨도 버티지만 수도꼭지를 틀고 물이 나오기까지는 오래 걸리죠. 버퍼가 크면 안정적이지만 지연(레이턴시)도 같이 늘어나는 거예요.
둘째는 시계 맞추기예요. 여러 장비가 각자 '1초에 48,000번'을 세는데, 시계가 조금만 달라도 시간이 갈수록 어긋나요. 그래서 PTP(Precision Time Protocol, IEEE 1588)라는 프로토콜로 네트워크에 있는 모든 장비의 시계를 마이크로초 이하 수준으로 맞춰요. 서버 시간 맞출 때 쓰는 NTP보다 훨씬 정밀한, 오케스트라 지휘자 같은 역할이죠.
이 원리 위에서 여러 표준이 경쟁하고 있어요.
- Dante: Audinate의 독점 프로토콜인데 공연장과 방송 현장에서는 사실상 표준이에요. 다만 리눅스용 공식 소프트웨어 지원이 약해서, 커뮤니티가 역설계로 구현을 만들어 쓰는 상황이에요.
- AES67: 누구나 구현할 수 있는 개방형 표준이에요. RTP로 오디오를 보내고 PTP로 시계를 맞춰요. Dante도 AES67 호환 모드를 지원해서 서로 연결할 수 있어요.
- AVB/Milan: IEEE 802.1 TSN 기반이라 네트워크 스위치도 이걸 지원해야 하지만, 그만큼 전송 타이밍을 확실하게 보장해줘요.
리눅스 오디오 스택과 만나는 지점
리눅스 오디오는 계층이 좀 복잡해요. 커널 레벨 드라이버인 ALSA, 저지연 프로 오디오용 JACK, 데스크톱용 PulseAudio가 따로 있었는데, 최근에는 JACK과 PulseAudio를 하나로 합친 PipeWire가 대부분 배포판의 기본이 됐어요. PipeWire는 RTP 기반 네트워크 오디오와 AES67 관련 설정도 지원해서, 예전보다 이더넷 오디오를 다루기가 훨씬 쉬워졌어요. 2024년 리눅스 6.12 커널에서 실시간 패치인 PREEMPT_RT가 메인라인에 들어간 것도 저지연 오디오 쪽에는 반가운 소식이었죠.
이더넷 방식의 진짜 장점은 드라이버 의존도가 낮아진다는 거예요. USB 장치는 OS마다 드라이버와 전용 앱이 필요하지만, 표준 네트워크 프로토콜로 오디오를 주고받고 설정은 웹 화면이나 API로 하면 OS를 가릴 이유가 줄어들거든요. 랜선 한 줄로 먼 거리까지 연결하고, 일반 스위치로 여러 장비를 묶을 수 있다는 것도 장점이고요.
한국 개발자에게 주는 시사점
음악을 안 하더라도 배워둘 만한 주제예요. 타이밍, 지터(패킷 도착 시간이 들쭉날쭉한 현상), 버퍼링 사이의 트레이드오프는 게임 서버, WebRTC 화상회의, 라이브 스트리밍에서도 똑같이 나오는 문제거든요. 국내 방송국과 공연장도 IP 기반 전송으로 빠르게 넘어가고 있어서, 방송·공연 IT 분야에서는 Dante나 AES67을 아는 개발자를 찾기가 쉽지 않아요.
리눅스 데스크톱을 쓰고 있다면 pw-top으로 PipeWire의 실시간 처리 상태를 보거나, qpwgraph 같은 도구로 오디오 라우팅을 눈으로 확인해보는 것부터 시작해보세요. 생각보다 재밌어요.
마무리
오디오 인터페이스를 'OS별 드라이버가 필요한 USB 장치'에서 '표준 네트워크에 붙는 장비'로 바꾸면, 리눅스 지원이라는 오래된 숙제가 훨씬 단순해질 수 있어요.
리눅스에서 음악이나 오디오 작업을 해보신 분 계신가요? 가장 크게 막혔던 벽이 뭐였는지, 이더넷 오디오 같은 방식이 해답이 될 수 있을지 의견 나눠주세요!
🔗 출처: Hacker News