- Triforce คือ บีมฟอร์เมอร์แบบปรับตัวได้ ที่พัฒนาด้วย Rust เพื่อใช้ประโยชน์จากชุดไมโครโฟนของแล็ปท็อป Apple Silicon แม้อยู่นอก macOS
- รุ่นที่รองรับจำกัดอยู่ที่ M1/M2 MacBook Air·Pro 13", M2 MacBook Air 15", และ M1/M2 Pro·Max MacBook Pro 14"·16"
- ชุดไมโครโฟนแบบสามเหลี่ยมหรือแบบเส้นตรง ของอุปกรณ์เหล่านี้ หากไม่มีการทำบีมฟอร์มมิงจะไวเกินไปและรับเสียงรอบทิศทางมากเกิน จึงแยกสัญญาณที่ต้องการได้ยาก
- โครงสร้างพยายามลด dependency ให้เหลือเพียง LV2 เพิ่มเติม นอกเหนือจาก crate ที่ระบุไว้ใน Cargo.lock
- การใช้งานปัจจุบันยังคาดหวังได้ยากว่าจะเหนือกว่าการใช้งานของ Apple และไม่รองรับ wideband decomposition กับเอาต์พุตสเตอริโอ เนื่องจากไม่มี SIMD/NEON
บีมฟอร์เมอร์สำหรับชุดไมโครโฟนของ Apple Silicon
- Triforce ใช้งานบีมฟอร์เมอร์แบบปรับตัวได้ชนิด Minimum Variance Distortionless Response สำหรับชุดไมโครโฟนของแล็ปท็อป 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)
- ชุดไมโครโฟนของแล็ปท็อปเป้าหมายถูกจัดวางเป็นรูป สามเหลี่ยม หรือ เส้นตรง
- หากใช้งานชุดไมโครโฟนนี้โดยไม่มีบีมฟอร์มมิง จะไวเกินไปและทำงานแบบรอบทิศทาง ทำให้มีประโยชน์น้อยลง และหากต้องการใช้นอก macOS ก็จำเป็นต้องมีบีมฟอร์เมอร์
- dependency เพิ่มเติมที่ต้องใช้ นอกเหนือจาก crate ที่ระบุใน Cargo.lock คือ LV2
สถานะการใช้งานและข้อจำกัดที่ทราบ
- เนื่องจากหาเอกสารอ้างอิงที่เข้าถึงได้เกี่ยวกับ DSP และบีมฟอร์มมิงแบบปรับตัวได้สำหรับสัญญาณแถบกว้างได้ยาก การใช้งานปัจจุบันจึงเป็นความพยายามที่อิงจากคณิตศาสตร์วิศวกรรมระดับปีหนึ่งและหลักการที่ได้จากเว็บเพจ·PDF หลายแหล่ง
- คาดหวังได้ยากว่าประสิทธิภาพจะดีกว่าการใช้งานของ Apple และยินดีรับแพตช์เพื่อปรับปรุง
- ข้อจำกัดที่ทราบมีดังนี้
- nalgebra ไม่ได้ทำการปรับแต่ง SIMD แบบชัดเจน แต่พึ่งพา auto-vectorization ของ LLVM ทำให้ประสิทธิภาพและความคุ้มค่าของ routine คณิตศาสตร์เมทริกซ์ไม่ดีนัก
- หากไม่มีการรองรับ SIMD/NEON จะช้าเกินไปสำหรับปลั๊กอินเสียงแบบเรียลไทม์ จึงไม่ทำ wideband decomposition
- เอาต์พุตรองรับเฉพาะ โมโน และการประมวลผลเมทริกซ์เพิ่มเติมเพื่อสร้างเอาต์พุตสเตอริโอจำลองมีภาระคำนวณสูงเกินไป
- ตามสถิติของ crates.io จำนวนดาวน์โหลดรวมคือ 4,247 ครั้ง และมีเวอร์ชันที่เผยแพร่แล้ว 7 เวอร์ชัน
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
บล็อกโพสต์ที่มีคำอธิบายพื้นหลังอยู่ที่นี่: https://asahilinux.org/2025/03/progress-report-6-14/#is-this...
Toshiba Tablet PC convertible ที่ใช้กันเมื่อกว่า 20 ปีก่อนมีอาร์เรย์ไมโครโฟนแบบ beamforming และยังมีซอฟต์แวร์ให้ระบุได้ว่าจะบันทึกเสียงจากทิศทางไหนด้วย
การใช้งานหลักคือบันทึกเสียงบรรยาย และสามารถตั้งค่าให้หันบีมไปทางอาจารย์ที่อยู่ด้านหลังโน้ตบุ๊ก เพื่อบันทึกเฉพาะเสียงจากด้านนั้นได้
เป็นไอเดียที่น่าทึ่ง แต่หลังจากนั้นก็ไม่เคยเห็นอีกเลย
นี่ก็เป็นไอเดียที่ยอดเยี่ยม และผลิตภัณฑ์ลักษณะคล้ายกันก็ยังมีอยู่: https://electronics.sony.com/imaging/imaging-accessories/all...
อาร์เรย์ไมโครโฟนในห้องประชุมจะระบุว่าใครกำลังพูด แล้วแยกเสียงของคนนั้นออกมา
การประชุมวิดีโอในห้องประชุมขนาดใหญ่ใช้วิธีเลือกไมโครโฟนที่เสียงดังที่สุดในขณะนั้นมานานแล้ว เพื่อไม่ให้เสียงรบกวนจากไมโครโฟนหลายตัวปนกัน และถ้าเพิ่ม beamforming เข้าไปก็จะดีขึ้นมาก
ถ้าไมโครโฟนอยู่บนระนาบของหน้าจอ ไม่ใช่ตัวเครื่อง ก็น่าจะแยก “ด้านหน้า” กับ “ด้านหลังตรง ๆ” ไม่ได้
อาจมีการใช้งานดี ๆ หลายอย่าง เช่น รถไร้คนขับ “มองเห็น” คนเดินถนนหลังพุ่มไม้ ตรวจจับรถฉุกเฉินที่กำลังเข้ามาได้เร็วขึ้น และได้ยินเสียงจักรยานก่อนที่จะมองเห็น
สงสัยมาตลอดว่าเขานำไปใช้งานอย่างไร
วิทยานิพนธ์ปริญญาโทที่ผมทำไม่เสร็จก็เป็นหัวข้อคล้าย ๆ กัน
ผมพยายามใช้ประโยชน์จากข้อเท็จจริงที่ว่าสมาร์ตโฟนแทบทั้งหมดมีไมโครโฟนอย่างน้อย 2 ตัว เพื่อ ระบุตำแหน่งผู้พูดแบบ 3 มิติ และแยกเสียงออกมา
บทเรียนที่ได้คือ: อัตราการสุ่มตัวอย่างระหว่างอุปกรณ์จะคลาดเคลื่อนกันเล็กน้อย ประมาณ ±1 sample ต่อวินาที ซึ่งไม่มากแต่ต้องนำมาคิดด้วย
คุณลักษณะทางสเปกตรัมของไมโครโฟนสำหรับผู้บริโภคแตกต่างกันไป แม้หยิบโทรศัพท์รุ่นเดียวกันสองเครื่องออกมา ก็มีทั้งความต่างที่วัดได้และความต่างที่ได้ยินจริง
เสียงสะท้อนจากทุกที่ โดยเฉพาะผนังคอนกรีต
ในบรรดาสถานที่ที่เข้าถึงได้ง่าย ภายในรถใกล้เคียงกับห้องไร้เสียงสะท้อนมากที่สุด
Fourier transform ของ Gaussian ยังคงเป็น Gaussian ดังนั้นจึงมีประโยชน์มากเวลาประเมินความถี่ของสัญญาณฮาร์มอนิกอย่างเสียงพูด ในกรณีที่ความยาวคลื่นสั้นกว่าครึ่งหนึ่งของความยาวหน้าต่างเล็กน้อย
นอกจากพื้นแล้วแทบไม่มีอะไรให้สะท้อน และอาจปูโฟมไว้ใต้การทดลองด้วย
แน่นอนว่าวิธีนี้กำจัดเสียงรบกวนจากสภาพแวดล้อมไม่ได้ แต่บอกกันว่าใช้ลดเสียงสะท้อนจากอุปกรณ์ของตัวเองได้ค่อนข้างดี
ทำให้รู้สึกได้เลยว่าการทำให้ Linux รันบน Apple Silicon Mac ต้องใช้แรงงานมากแค่ไหน แม้แต่ส่วนที่ดูเล็กน้อยก็ตาม
คำว่า “เล็กน้อย” ในที่นี้พูดด้วยความเคารพเต็มที่ เพราะไมโครโฟนในตัวแทบไม่ได้ใช้ เว้นแต่จะลืมหยิบเฮดเซ็ตมา
อ้างจากรายงานความคืบหน้า(https://asahilinux.org/2025/03/progress-report-6-14/#is-this...): “แต่ก็อย่างว่า นี่คือ Apple ไม่มีอะไรที่เรียบง่ายเลย”
ถ้าเป็นหูฟังไมค์แบบ wraparound ที่มีแขนไมค์แยกต่างหากอาจดีกว่า แต่หูฟังที่ใช้ทั่วไปมีข้อจำกัดเพราะตำแหน่งไมโครโฟน
ไมโครโฟน MBP มีระบบตัดเสียงรบกวนที่ดีด้วย จึงน่าเลือกใช้มากกว่าไมค์บูมของเฮดเซ็ตส่วนใหญ่
ยังมีข้อดีคือเก็บเสียงไม่จำเป็นใกล้ปากได้น้อยกว่า เช่น เสียงเคี้ยวหมากฝรั่งหรือเสียงดื่มกาแฟ
รู้สึกว่า 99% ของคนที่ประชุมใช้หูฟังทั่วไปคู่กับไมโครโฟน MBP
ปัญหาหลักของชุดนี้คือไม่ได้ยินเสียงตัวเองในหูฟัง ซึ่งบางครั้งอาจน่ารำคาญพอสมควรถ้าใช้หูฟังตัดเสียงรบกวน
แต่ระยะหลัง Apple ก็เริ่มออกนอกเส้นทางที่ตัวเองเคยปูไว้
ประเด็นสำคัญคือทุกอย่างที่ Apple ทำล้วนเป็นแบบ vertical integration
หากต้องการให้ฟีเจอร์อย่าง AirDrop หรือ Continuity ทำงาน ก็ต้องนำไปใช้งานข้ามทั้งสแตก
ถ้าเลือกเส้นทาง DIY ซึ่งเป็นแนวทางที่ Asahi มุ่งไปโดยพฤตินัย ก็ต้องสร้างชิ้นส่วนซอฟต์แวร์ที่ขาดหายไปเองด้วย
ข้อดีคือทั้งระบบนิเวศจะได้รับประโยชน์จากงานนั้น ตัวอย่างเช่น DSP ใหม่ของ PipeWire
ฮาร์ดแวร์ PC โดยรวมค่อนข้างแย่ และถ้าตัดองค์ประกอบเสริมเหล่านี้ออก ฮาร์ดแวร์ของ Apple ก็เหมือนกัน
แต่ “แพ็กเกจทั้งหมด” ได้ยกระดับมาตรฐานไว้ค่อนข้างสูง และผมอยากเห็นระบบนิเวศโอเพนซอร์สเสรีไปถึงมาตรฐานนั้น
Retina MacBook Pro รุ่นแรก ๆ บางรุ่นมีเพียงอาร์เรย์ไมโครโฟน 2 ตัว แต่ส่วนใหญ่มีอาร์เรย์ไมโครโฟน 3 ตัวครบถ้วน
ไม่อย่างนั้นมันจะลดลงไปใช้โหมดโค้เดกบิตเรตต่ำที่เก่ามาก ทำให้แม้แต่อินพุตเสียงที่ได้ยินในหูก็แย่มาก
ดังนั้นถ้าเป็นไปได้ ผมจึงใช้ไมโครโฟนของ Mac เสมอ
แม้บนฮาร์ดแวร์โน้ตบุ๊กราคาถูก และแน่นอนว่ารวมถึงฮาร์ดแวร์ระดับสูงอย่าง MBP ก็สามารถได้ผลลัพธ์ที่ดีจนน่าทึ่งด้วยเทคนิค DSP ฝั่งซอฟต์แวร์
ชอบตรงที่งานด้านเสียงส่วนใหญ่ของ Asahi สามารถนำไปใช้กับโน้ตบุ๊กทั่วไปได้แทบตรง ๆ ไม่ใช่แค่ Mac
ตอนนี้ใช้ปลั๊กอินสังเคราะห์ฮาร์มอนิกเสียงเบส Bankstown กับคอนโวลูชันอีควอไลเซอร์ที่พัฒนาสำหรับ Asahi บนโน้ตบุ๊ก HP ราคาถูกอยู่ และผลลัพธ์ก็น่าประทับใจอย่างไม่น่าเชื่อ
สิ่งนี้ก็ใช้ฟีเจอร์โหลดเชนปลั๊กอิน PipeWire อัตโนมัติที่พัฒนาสำหรับ Asahi เช่นกัน
บีมฟอร์เมอร์ ตัวนี้ก็น่าจะมีที่ให้ใช้นอกอีโคซิสเต็มของ 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 มีสตรีมแยกเฉพาะของไมค์แต่ละตัวให้หรือเปล่า
macOS ทำการคำนวณบีมฟอร์มมิงที่คล้ายกันมากภายในระบบ และแสดงให้ผู้ใช้เห็นเป็นไมโครโฟนรวมตัวเดียวเท่านั้น
M3 ยังไม่รองรับโดย Asahi Linux ดังนั้นการที่ไม่มีอยู่ในรายการเป็นคนละเรื่องกับว่า M3 มีไมโครโฟนแบบนี้หรือไม่
macOS มีซอฟต์แวร์ของตัวเองที่จัดการเรื่องนี้อยู่ลึกในระบบ และเปิดเผยต่อแอปพลิเคชันเป็นแค่ไมโครโฟนปกติ
ในรายงานความคืบหน้าล่าสุดของ Asahi Linux มีการพูดคุยเรื่องนี้แบบทั่วไปมากขึ้น
“น่าเสียดายที่ไมโครโฟน PDM เป็นแบบรับเสียงรอบทิศทางมากและไวมาก หากไม่มีบีมฟอร์มมิงในรูปแบบใดรูปแบบหนึ่งก็เอาไม่อยู่”
https://asahilinux.org/2025/03/progress-report-6-14/
อีกอย่างพบว่างานบางส่วนที่เคยทำไว้สำหรับเอาต์พุตลำโพงถูกนำกลับมาใช้กับอินพุตไมโครโฟนด้วย
“ด้วยรากฐานที่วางไว้ใน PipeWire และ WirePlumber สำหรับการรองรับลำโพง การต่อเชน DSP รวมถึง Triforce เข้ากับไมโครโฟนจึงง่ายมากจริง ๆ แค่อัปเดตไฟล์ตั้งค่า แล้วปล่อยให้ WirePlumber จัดการส่วนที่เหลือ!”
สำหรับประโยคที่ว่า “เช่นเดียวกับลำโพง Apple พยายามทำให้ดูหรูเกินไปในเรื่องนี้ด้วย” ถ้าผู้เขียนแพ็กเกจนี้ออกความเห็นให้ฟังคงน่าสนใจมาก
โดยเฉพาะอยากรู้ว่าคิดอย่างไรกับ การอิมพลีเมนต์ลำโพง
อะไรที่ซับซ้อนเกินไป? ฮาร์ดแวร์หรือซอฟต์แวร์?
ในฐานะผู้ใช้ MBP และคนที่เล่นเสียงเป็นงานอดิเรก ผมรู้สึกว่าการอิมพลีเมนต์ลำโพง โดยเฉพาะในรุ่น MBP ที่ใหญ่กว่า น่าประทับใจมากจริง ๆ
แต่ผมก็แค่ระดับงานอดิเรก และรู้อยู่แค่เรื่องทวีตเตอร์กับการจัดวูฟเฟอร์คู่แบบหันสวนกันเท่านั้น
ดูเหมือน Apple ก็ใช้เทคนิคอย่างอีควอไลเซอร์แบบปรับตามสภาพ ที่นักออกแบบลำโพง Bluetooth “ดี ๆ” ใช้เพื่อรีดประสิทธิภาพและการขยายย่านเบสที่พอใช้ได้จากลำโพงขนาดเล็ก
ปัญหาหนึ่งคือถ้าจะจำกัดการใช้พลังงานเพื่อป้องกันความร้อนเกิน ก็ต้องใช้ DSP ที่ซับซ้อน
ถ้าไม่มีสิ่งนั้น ระดับเสียงที่ทำได้ภายในขีดจำกัดความปลอดภัยจะถูกจำกัดมาก
ถ้าอยากรู้เพิ่มเติม ที่นี่น่าจะเป็นภาพรวมที่ดีที่สุด: https://github.com/AsahiLinux/asahi-audio
เรื่องนี้เป็นจริงมาหลายเจเนอเรชันแล้ว
ตอนใช้ MBP รุ่นปี 2014 เวลาดูหนังระหว่างเดินทาง เพื่อนหลายคนก็ทึ่งกับเสียง
M4 MBP ก็เหมือนกัน คุณภาพเสียงลำโพงอยู่ในระดับที่จริง ๆ แล้วเกินความจำเป็นด้วยซ้ำ
ทุกวันนี้ อย่างน้อยบนฮาร์ดแวร์ระดับพรีเมียม “spatial audio” ของลำโพงและไมโครโฟนบีมฟอร์มมิงเริ่มให้ความรู้สึกเหมือนเป็นมาตรฐานแล้ว
เสียงที่ทึบ หนวกหู อึดอัด และไม่สมดุลใช้ไม่ได้อีกต่อไป