Triforce - 애플 실리콘 노트북용 빔포머

• Triforce는 Apple Silicon 노트북의 마이크 배열을 macOS 밖에서도 활용하기 위한 Rust 기반 적응형 빔포머임
• 지원 대상은 M1/M2 MacBook Air·Pro 13", M2 MacBook Air 15", M1/M2 Pro·Max MacBook Pro 14"·16"로 한정됨
• 해당 기기들의 삼각형 또는 직선 마이크 배열은 빔포밍 없이는 너무 민감하고 전방위적이라 원하는 신호 분리가 어려움
• 의존성은 Cargo.lock에 명시된 crate 외에 LV2만 필요하도록 최소화하려는 구조임
• 현재 구현은 Apple 구현을 능가한다고 기대하기 어렵고, SIMD/NEON 부재로 광대역 분해와 스테레오 출력은 지원하지 않음

---

Apple Silicon 마이크 배열을 위한 빔포머

• Triforce는 Apple Silicon 노트북의 마이크 배열을 위한 Minimum Variance Distortionless Response 적응형 빔포머를 구현함
• 지원 기기는 다음과 같음
  • MacBook Pro 13" (M1/M2)
  • MacBook Air 13" (M1/M2)
  • MacBook Pro 14" (M1 Pro/Max, M2 Pro/Max)
  • MacBook Pro 16" (M1 Pro/Max, M2 Pro/Max)
  • MacBook Air 15" (M2)
• 대상 노트북의 마이크 배열은 삼각형 또는 직선 형태로 배치돼 있음
• 이 배열은 빔포밍 없이 쓰면 너무 민감하고 전방위적으로 동작해 유용성이 떨어지며, macOS 밖에서 활용하려면 빔포머가 필요함
• Cargo.lock에 지정된 crate 외에 추가로 필요한 의존성은 LV2임

구현 상태와 알려진 한계

• DSP와 광대역 적응형 빔포밍 관련 접근 가능한 문헌을 찾기 어려워, 현재 구현은 학부 1학년 수준의 공학 수학과 여러 웹페이지·PDF에서 얻은 원리를 바탕으로 한 시도임
• Apple의 구현보다 성능이 좋을 것으로 기대하기는 어려우며, 개선 패치는 환영됨
• 알려진 한계는 다음과 같음
  • nalgebra는 명시적 SIMD 최적화를 하지 않고 LLVM 자동 벡터화에 의존해 행렬 수학 루틴의 성능과 효율이 좋지 않음
  • SIMD/NEON 지원 없이는 실시간 오디오 플러그인에 너무 느려서 광대역 분해를 하지 않음
  • 출력은 모노만 지원하며, 가짜 스테레오 출력을 위한 추가 행렬 처리는 계산량이 너무 큼
• crates.io 통계상 전체 다운로드 수는 4,247회, 게시된 버전은 7개임

[GN⁺]

Hacker News 의견들

• 배경 설명이 담긴 블로그 글은 여기 있음: https://asahilinux.org/2025/03/progress-report-6-14/#is-this...

• 20년도 더 전에 쓰던 Toshiba Tablet PC 컨버터블에는 마이크 빔포밍 배열이 있었고, 어디에서 나는 소리를 녹음할지 지정하는 소프트웨어도 포함돼 있었음
  강의 녹음이 주요 용도였고, 노트북 뒤쪽의 교수 방향으로 빔을 향하게 해서 그쪽 소리만 녹음하도록 설정할 수 있었음
  놀라운 아이디어였는데 그 이후로는 본 적이 없음

  • 미니 캠코더 전성기에는 일부 Sony Handycam에 “줌” 마이크가 있었고, 빔포밍으로 센서가 보는 영역과 대략 맞는 범위의 소리만 모으도록 했음
    이것도 훌륭한 아이디어였고, 비슷한 제품은 아직도 나옴: https://electronics.sony.com/imaging/imaging-accessories/all...
  • 고급 화상회의 장비에서는 널리 쓰이고 있음
    회의실 마이크 배열이 누가 말하는지 파악해서 그 사람의 오디오를 분리함
    큰 회의실 화상회의는 오래전부터 여러 마이크의 잡음이 섞이지 않게 그때그때 가장 큰 마이크를 골라 썼는데, 여기에 빔포밍이 들어가면 훨씬 좋아짐
  • 그게 어떻게 동작했는지 궁금함
    마이크가 본체가 아니라 화면 평면에 있었다면, “정면”과 “바로 뒤”를 구분하지 못했을 것 같음
  • 몇 년째 생각만 하고 계산 자원이 부족해서 시험해 보지 못한 아이디어가 있음: 마이크 배열과 LIDAR를 정답 데이터로 쓰고, 마이크 데이터의 신호 변환만 조건으로 삼아 세상이 어떻게 생겼을지 “상상”하는 확산 모델을 학습시키는 것
    자율주행차가 덤불 너머 보행자를 “보고”, 다가오는 긴급차량을 더 일찍 감지하고, 자전거가 보이기 전에 소리를 듣는 등 여러 좋은 용도가 있을 수 있음
  • Samsung S10 이후부터는 줌 모드로 동영상을 녹화할 때 이 기능이 있음
    항상 어떻게 구현했는지 궁금했음

• 끝내 완성하지 못한 석사 논문이 비슷한 주제였음
  거의 모든 스마트폰에 마이크가 최소 2개 있다는 점을 이용해, 화자를 3차원 위치 추정하고 분리하려고 했음
  얻은 교훈은 이렇다: 기기 간 표본화율은 약간 어긋나며 대략 초당 ±1샘플 정도라 크지는 않지만 고려해야 함
  소비자용 마이크의 스펙트럼 특성은 제각각이라 같은 모델 휴대폰 두 대를 막 꺼내도 측정 가능한 차이뿐 아니라 들리는 차이까지 있음
  소리는 특히 콘크리트 벽을 포함해 온갖 곳에서 반사됨
  쉽게 접근 가능한 것 중 차 안이 무향실에 가장 가까움
  가우시안의 푸리에 변환은 가우시안이라, 음성처럼 고조파 신호의 주파수를 추정할 때 파장이 창 길이의 절반보다 조금 짧은 경우에 매우 유용함

  • “차 안이 쉽게 접근 가능한 것 중 무향실에 가장 가깝다”는 부분에 대해, 어떤 YouTuber는 큰 빈 들판을 찾아 무향실 문제를 해결했던 기억이 남
    바닥 말고는 반사될 것이 없고, 실험 아래쪽에 폼을 깔았을 수도 있음
    물론 환경 소음을 없애지는 못하지만, 자기 장비에서 나오는 반사를 줄이는 데는 꽤 잘 먹혔다고 함
  • 옷이 가득 찬 카펫 깔린 옷장이 차보다 낫지 않을까
  • 가우시안 관련은 이해되는데, 그 요지를 좀 더 자세히 설명해 줄 수 있을까

• Linux를 Apple Silicon Mac에서 돌아가게 하려면 사소해 보이는 부분에도 얼마나 많은 작업이 필요한지 실감됨
  여기서 “사소하다”는 말은 최대한 존중을 담은 표현임. 내장 마이크는 헤드셋을 잊고 오지 않는 한 거의 안 쓰기 때문임
  진행 보고서(https://asahilinux.org/2025/03/progress-report-6-14/#is-this...)를 인용하면: “그래도 Apple이다. 단순한 것은 아무것도 없다”

  • 내장 마이크는 실제로 훌륭해서, AirPods Pro를 끼고 있어도 음질이 훨씬 좋아서 종종 내장 마이크를 씀
    별도 암이 달린 랩어라운드 마이크 헤드폰이라면 더 나을 수도 있지만, 일상적인 헤드폰은 마이크 위치 때문에 한계가 있음
  • 내 경험과는 전혀 다름
    MBP 마이크는 좋은 잡음 제거까지 있어서 대부분의 헤드셋 붐 마이크보다 선호할 만했음
    껌 씹는 소리나 커피 마시는 소리 같은 불필요한 입 주변 소리를 덜 잡는 장점도 있음
    회의하는 사람들의 99%는 일반 헤드폰과 MBP 마이크 조합을 쓰는 느낌임
    이 구성의 주된 문제는 헤드폰에서 자기 목소리를 들을 수 없다는 점인데, 잡음 제거 헤드폰을 쓰면 가끔 꽤 거슬릴 수 있음
  • 제품으로 받은 전체 패키지를 그대로 쓰면 단순하긴 함
    다만 Apple은 한동안 스스로 닦아 둔 길에서도 벗어나고 있음
    핵심은 Apple이 만드는 모든 것이 수직 통합돼 있다는 점임
    AirDrop이나 Continuity 같은 기능을 제공하려면 스택 전체를 가로질러 구현함
    DIY 경로, 즉 Asahi가 사실상 지향하는 방식을 택하면 빠진 소프트웨어 조각도 직접 만들어야 함
    장점은 그 작업의 혜택을 전체 생태계가 누릴 수 있다는 것임. 예를 들면 PipeWire의 새 DSP가 그렇다
    PC 하드웨어는 대체로 별로고, 이런 추가 구성요소를 빼면 Apple 하드웨어도 마찬가지임
    하지만 “전체 패키지”는 기준을 꽤 높여 놓았고, 자유 오픈소스 생태계가 그 기준에 도달하는 모습을 보고 싶음
  • 3마이크 배열은 Intel 기반 Retina MacBook에도 있으므로, 이 작업은 해당 구형 하드웨어의 제대로 된 오디오 지원에도 유용할 수 있음
    일부 초기 Retina MacBook Pro는 2마이크 배열뿐이지만, 대부분은 완전한 3마이크 배열을 갖고 있음
  • 대부분의 마이크가 아직 Bluetooth 5.0을 쓰기 때문에, 헤드셋을 끼고 있어도 Mac 마이크를 사용함
    그렇지 않으면 아주 오래된 저비트레이트 코덱 모드로 내려가서, 귀로 듣는 오디오 입력까지 끔찍해짐
    그래서 가능하면 항상 Mac 마이크를 씀

• 저렴한 노트북 하드웨어에서도, 물론 MBP 같은 고급 하드웨어에서도, 소프트웨어 DSP 기법으로 놀랄 만큼 좋은 결과를 얻을 수 있음
  Asahi의 오디오 작업 상당 부분이 Mac뿐 아니라 일반 노트북에도 그대로 적용 가능하다는 점이 마음에 듦
  이미 Asahi용으로 개발된 Bankstown 저음 고조파 합성 플러그인과 컨볼루션 이퀄라이저를 저렴한 HP 노트북에서 쓰고 있는데, 결과가 놀라울 정도로 인상적임
  이것도 Asahi용으로 개발된 PipeWire 플러그인 체인 자동 로드 기능을 이용함
  이 빔포머도 Asahi 생태계 밖에서 쓸 곳이 꽤 많을 것 같음

• SIMD 최적화와 관련해서는 작성자들이 faer를 살펴보면 좋겠음
  기반 라이브러리인 pulp는 선형대수 범위를 넘어서는 작업을 하려다 보니 개인적으로는 경험이 아주 좋지는 않았지만, 목표가 주로 선형대수 연산 가속이라면 잘 맞을 것 같음
  Rust SIMD에 관한 블로그 글과 관련 팟캐스트를 준비 중이고, 여기서 이 내용을 다룰 예정임
  [1]: https://docs.rs/faer/latest/faer/

• GitHub 저장소: https://github.com/chadmed/triforce

• “다음 Apple Silicon 노트북에 있는 마이크 배열”이라고 하면서 MacBook Pro 13" M1/M2, MacBook Air 13" M1/M2, MacBook Pro 14" M1 Pro/Max·M2 Pro/Max, MacBook Pro 16" M1 Pro/Max·M2 Pro/Max, MacBook Air 15" M2를 나열했는데, M2/M3에는 비슷한 마이크 배열이 없다는 뜻인지 아니면 테스트되지 않았다는 뜻인지 궁금함
  이게 Linux에서만 지원되는지도 궁금함
  macOS에서도 가능한지, Apple이 각 마이크별 전용 스트림을 제공하는지 잘 모르겠음

  • 이건 Asahi Linux용으로 만든 것임
    macOS는 내부에서 매우 비슷한 빔포밍 계산을 수행하고, 사용자에게는 하나의 통합 마이크로만 보여줌
  • 목록에 M2 기기는 들어 있음
    M3는 Asahi Linux가 아직 지원하지 않으므로, 목록에 없다는 사실은 M3에 이런 마이크가 있는지와 별개의 문제임
    macOS는 시스템 깊숙한 곳에 이를 처리하는 자체 소프트웨어가 있고, 애플리케이션에는 일반 마이크로만 노출됨
  • Asahi Linux는 아직 M3와 M4 프로세서를 지원하지 않음

• 최신 Asahi Linux 진행 보고서에 더 일반적인 논의가 있음
  “안타깝게도 PDM 마이크는 매우 전방위적이고 매우 민감하다. 어떤 형태로든 빔포밍 없이는 버틸 수 없다”
  https://asahilinux.org/2025/03/progress-report-6-14/
  또 스피커 출력을 위해 이전에 해 둔 작업 일부가 마이크 입력에도 재사용된 것으로 드러남
  “스피커 지원을 위해 PipeWire와 WirePlumber에 깔아 둔 기반 덕분에, Triforce를 포함한 DSP 체인을 마이크에 연결하는 일은 정말 간단했다. 설정 파일만 업데이트하고 나머지는 WirePlumber가 알아서 하게 하면 됐다!”

• “스피커와 마찬가지로 Apple은 여기서도 너무 멋을 부리려고 한다”는 문장에 대해, 이 패키지 작성자가 의견을 밝혀 주면 정말 흥미로울 것 같음
  특히 스피커 구현에 대해 어떻게 생각하는지 궁금함
  무엇이 지나치게 복잡한가? 하드웨어인가, 소프트웨어인가?
  MBP 사용자이자 취미로 오디오를 다루는 입장에서는, 특히 더 큰 MBP 모델의 스피커 구현이 정말 인상적이었음
  다만 나는 취미 수준이고, 트위터와 이중 대향 우퍼 구성 말고는 아는 것이 없음
  작은 스피커에서 괜찮은 성능과 저음 확장을 끌어내기 위해 “좋은” Bluetooth 스피커 설계자들이 쓰는 적응형 이퀄라이저 같은 요령을 Apple도 쓰는 것처럼 보임

  • Asahi Linux에서 괜찮은 스피커 지원을 확보하는 건 큰 일이었음
    문제 중 하나는 과열을 막기 위해 전력 사용을 제한하려면 정교한 DSP가 필요하다는 점임
    그게 없으면 안전 한계 안에서 낼 수 있는 음량이 매우 제한됨
    더 알고 싶다면 아마 여기가 가장 좋은 개요임: https://github.com/AsahiLinux/asahi-audio
  • “스피커와 마찬가지로 Apple이 너무 멋을 부린다”는 말은 Apple 노트북 스피커가 경쟁 제품보다 훨씬 앞서 있다는 의미로 보임
    이건 여러 세대 동안 사실이었음
    2014년형 MBP를 썼을 때도 이동 중 영화를 보면 친구 여럿이 소리에 놀랐음
    M4 MBP도 마찬가지로, 스피커 음질이 실제로는 필요 이상일 정도의 수준임
  • 가치판단 없이 추측하자면, 그런 소프트웨어 없이는 제대로 동작하지 않는다는 점을 가리킨 것 같음
  • 이 패키지는 노트북에서 Linux 배포판을 쓰면서 네이티브 macOS와 같은 기능을 이용하고 싶은 사람들을 위한 것 같음
  • 나도 혼란스러움
    요즘은 적어도 프리미엄 하드웨어에서는 스피커의 “공간 오디오”와 빔포밍 마이크가 표준처럼 느껴지기 시작했음
    둔하고 시끄럽고 비좁고 균형이 안 맞는 오디오는 이제 통하지 않음