MLow: โค้ดเสียงบิตเรตต่ำของ Meta

• Meta ได้พัฒนาโค้ดเสียงบิตเรตต่ำตัวใหม่ MLow เพื่อรักษาคุณภาพการโทรแบบเรียลไทม์บน WhatsApp, Instagram และ Messenger แม้ในเครือข่ายที่ช้าหรือบนอุปกรณ์รุ่นเก่า
• Opus เดิมทำงานแบบ NarrowBand ที่ 6 kbps ทำให้ครอบคลุมย่านความถี่เสียงพูดได้ไม่เพียงพอ และเมื่อเครือข่ายแย่ลงระหว่างวิดีโอคอล บิตเรตที่จัดสรรให้เสียงก็จะลดลงอีก
• โค้ดเสียงแบบ ML สามารถให้คุณภาพที่ดีที่บิตเรตต่ำได้ แต่มีต้นทุนด้านการคำนวณสูง จึงมักเหมาะกับอุปกรณ์พกพารุ่นใหม่ประสิทธิภาพสูงมากกว่า
• MLow ให้คุณภาพระดับ POLQA MOS 3.9 ที่ 6 kbps แบบ WideBand สูงกว่า Opus ที่ 1.89 เกือบ 2 เท่า และมีความซับซ้อนในการคำนวณ ต่ำกว่า Opus 10%
• มีการใช้งานครอบคลุมการโทรบน Instagram และ Messenger แล้ว และกำลังทยอยปล่อยบน WhatsApp โดยสามารถใส่ FEC ได้มีประสิทธิภาพขึ้นที่บิตเรตต่ำ จึงช่วยกู้คืนเสียงได้ดีขึ้นในสถานการณ์แพ็กเก็ตสูญหาย

---

เหตุผลที่ Meta สร้างโค้ดตัวใหม่

• แอปของ Meta รวมถึง WhatsApp, Instagram และ Messenger ให้บริการฟีเจอร์ การสื่อสารแบบเรียลไทม์ (RTC) แก่ผู้ใช้หลายพันล้านคน
• ใน RTC โค้ดเสียงและวิดีโอเป็นองค์ประกอบหลักที่ใช้บีบอัดข้อมูลที่จับมาเพื่อส่งผ่านอินเทอร์เน็ต และคงการสนทนาให้เป็นแบบเรียลไทม์
• เสียงดิบของการโทรทั่วไป หากอิงที่การสุ่มตัวอย่าง 48kHz, 16 บิต, โมโน จะมีบิตเรต 768 kbps และโค้ดสมัยใหม่สามารถบีบอัดลงได้ถึง 25~30 kbps
• ในกระบวนการบีบอัดอาจเกิดคุณภาพลดลงจากการสูญเสียข้อมูล แต่โค้ดที่ดีจะใช้ทั้งคุณลักษณะของสัญญาณเสียงและความรู้ด้าน psychoacoustics เพื่อสร้างสมดุลระหว่างคุณภาพ บิตเรต และความซับซ้อน
• Opus เป็นโค้ดโอเพนซอร์สที่เป็นที่รู้จักอย่างกว้างขวางและเปิดตัวในปี 2012 โดย Meta ใช้ Opus มาตลอดเพื่อตอบโจทย์ความต้องการด้าน RTC

ข้อจำกัดของบิตเรตต่ำและอุปกรณ์รุ่นเก่า

• ในสภาพแวดล้อม RTC ขนาดใหญ่ของ Meta บริษัทสามารถเห็นได้โดยตรงว่าสภาพเครือข่ายที่หลากหลายส่งผลต่อประสบการณ์การโทรอย่างไร
• การโทรจำนวนไม่น้อยเผชิญกับ การเชื่อมต่อเครือข่ายที่ไม่ดี ตลอดทั้งสายหรือบางช่วง
  • โมดูลประเมินแบนด์วิดท์ (BWE) จะตรวจจับคุณภาพเครือข่าย
  • เมื่อคุณภาพเครือข่ายแย่ลง ต้องลดบิตเรตของโค้ดเพื่อหลีกเลี่ยงความแออัดและรักษาการไหลของเสียง
  • ในวิดีโอคอล พื้นที่ที่เหลือให้เสียงจะยิ่งลดลงภายใต้สภาพเครือข่ายที่ไม่ดี
• จุดทำงานต่ำสุดของ Opus คือ 6 kbps และในกรณีนั้นจะทำงานในโหมด NarrowBand ที่ 0~4kHz
  • ช่วงนี้ไม่สามารถเก็บความถี่ทั้งหมดที่เกิดจากเสียงมนุษย์ได้เพียงพอ
  • ส่งผลให้เสียงพูดฟังชัดน้อยลงและไม่เป็นธรรมชาติเท่าเดิม
• โค้ดเสียงแบบ ML อย่าง Encodec ที่ Meta เปิดตัวในเดือนตุลาคม 2022 สามารถให้คุณภาพเสียงชัดเจนได้แม้ที่บิตเรตต่ำมาก
  • แต่ต้นทุนการคำนวณสูง จึงมักรันได้อย่างเสถียรเฉพาะบนอุปกรณ์พกพาระดับสูงและราคาสูง
  • ผู้ใช้อุปกรณ์สเปกต่ำยังคงเจอปัญหาคุณภาพเสียงเมื่ออยู่ในสภาวะบิตเรตต่ำ
• มากกว่า 20% ของการโทรบน Meta เกิดขึ้นบนอุปกรณ์ ARMv7 และบน WhatsApp มีการโทรหลายสิบล้านครั้งต่อวันจากอุปกรณ์ที่มีอายุมากกว่า 10 ปี

ประสิทธิภาพของ MLow และสถานะการใช้งาน

• Meta เริ่มพัฒนาโค้ดตัวใหม่ช่วงปลายปี 2021 และหลังจากการพัฒนาและทดสอบเกือบ 2 ปี ก็ได้ประกาศ Meta Low Bitrate audio codec หรือ MLow
• คุณภาพที่ 6 kbps แบบ WideBand อยู่ที่ POLQA MOS 3.9 ซึ่งสูงกว่า 1.89 ของ Opus เกือบ 2 เท่า
• ความซับซ้อนในการคำนวณ ต่ำกว่า Opus 10%
• เมื่อเทียบในสเกล MOS (Mean Opinion Score) 1~5 คะแนน MLow เหนือกว่า Opus อย่างชัดเจนในช่วงบิตเรตต่ำ และคุณภาพเข้าสู่ภาวะอิ่มตัวได้เร็วกว่า Opus
• มีการใช้งานครอบคลุมการโทรทั้งหมดบน Instagram และ Messenger แล้ว และกำลังทยอยปล่อยอย่างจริงจังบน WhatsApp
• ยังพบด้วยว่าคุณภาพเสียงที่ดีขึ้นเชื่อมโยงกับการมีส่วนร่วมของผู้ใช้ที่ดีขึ้น

FEC ในสถานการณ์แพ็กเก็ตสูญหาย

• หากเข้ารหัสเสียงคุณภาพสูงได้ที่บิตเรตต่ำ ก็จะสามารถใช้กลยุทธ์ Forward Error Correction(FEC) ได้อย่างมีประสิทธิภาพมากขึ้นด้วย
• เมื่อเทียบกับ Opus, MLow มีพื้นที่ให้ใส่ FEC ได้แม้ที่บิตเรตต่ำกว่า
• คุณสมบัตินี้ช่วยปรับปรุงคุณภาพเสียงในสถานการณ์ แพ็กเก็ตสูญหาย
• มีตัวอย่างเปรียบเทียบในสถานการณ์ที่บิตเรต 14 kbps และฝั่งรับมีอัตราแพ็กเก็ตสูญหายสูงถึง 30%
• Opus ไม่สามารถเข้ารหัส in-band FEC ได้ที่บิตเรตดังกล่าว
  • หาก Opus ต้องการเข้ารหัส in-band FEC ที่การสูญหายของแพ็กเก็ต 10% จะต้องใช้ขั้นต่ำ 19 kbps
  • ข้อจำกัดนี้ส่งผลเสียต่อการกู้คืนเสียง

โครงสร้างภายในของ MLow

• MLow มีพื้นฐานจากแนวคิดของโค้ด CELP(Code Excited Linear Prediction) แบบดั้งเดิม
• จุดที่ปรับปรุงหลักอยู่ที่การสร้าง excitation, การ quantize พารามิเตอร์ และวิธีการ coding
• ตัวเข้ารหัสรับสัญญาณอินพุตซึ่งเป็นเสียง PCM ดิบ แล้วแยกเป็นย่านความถี่ต่ำและย่านความถี่สูง
• แต่ละย่านถูกเข้ารหัสแยกกัน แต่ใช้ข้อมูลร่วมกันเพื่อให้บีบอัดได้ดีขึ้น
• เอาต์พุตจะผ่าน range encoder เพื่อบีบอัดเพิ่มเติม และสร้าง payload ที่เข้ารหัสแล้ว
• ตัวถอดรหัสรับ payload แล้วทำกระบวนการย้อนกลับเพื่อสร้างสัญญาณเสียงขาออก
• MLow สามารถเข้ารหัสย่านความถี่สูงโดยใช้บิตน้อยมากผ่าน การเพิ่มประสิทธิภาพแบบแบ่งย่านความถี่
• ด้วยโครงสร้างนี้ จึงสามารถให้เสียงแบบ SuperWideBand หรือเสียงที่สุ่มตัวอย่างที่ 32kHz ได้แม้ที่บิตเรตต่ำกว่า

งานถัดไป

• MLow ช่วยยกระดับคุณภาพเสียงอย่างมากบนอุปกรณ์สเปกต่ำ พร้อมทั้งคง การเข้ารหัสแบบ end-to-end ของการโทรไว้
• เนื่องจากสามารถใส่ข้อมูลเสียงส่วนเกินได้อย่างมีประสิทธิภาพที่บิตเรตต่ำ งานปรับปรุงการกู้คืนเสียงบนเครือข่ายที่มีการสูญหายของแพ็กเก็ตรุนแรงจึงยังดำเนินต่อไป

[GN⁺]

ความคิดเห็นจาก Hacker News

• โคเดกบิตเรตต่ำ รุ่นใหม่ ๆ นั้นน่าทึ่ง แต่ในสถานการณ์ส่วนใหญ่ที่ Meta น่าจะนำไปใช้ ดูเหมือนว่าอาจไม่ได้มีประโยชน์มากนักในทางปฏิบัติ
  หากต้องการลดดีเลย์ในการสื่อสารแบบเรียลไทม์ ความถี่ในการส่งแพ็กเก็ตต้องค่อนข้างสูง และเมื่อถึงจุดหนึ่ง โอเวอร์เฮดของ UDP, IP และเลเยอร์ที่ต่ำกว่าจะเริ่มครอบงำมากกว่าเพย์โหลดจริง
  ตัวอย่างเช่น (S)RTP บน UDP/IP จะมีโอเวอร์เฮดรวม 40 ไบต์ โดย RTP อย่างน้อย 12 ไบต์, UDP 8 ไบต์ และ IPv4 20 ไบต์ หากอิงที่ 50 แพ็กเก็ตต่อวินาที หรือดีเลย์จากการ serialize 20ms แค่โอเวอร์เฮดก็อยู่ที่ 16kbps แล้ว
  หากลดลงเหลือ 25 แพ็กเก็ตต่อวินาที โอเวอร์เฮดจะเป็น 8kbps แต่ก็ยังคิดเป็นสัดส่วนใหญ่ของอัตราส่งข้อมูลรวมอยู่ดี
  จุดที่โคเดกแบบนี้เปล่งประกายจริง ๆ คือการสื่อสารแบบ circuit-switched ที่ใช้ราว 2kbps อย่างโทรศัพท์ดาวเทียมบางประเภท หรือระบบ VoIP ที่รับรู้โปรโตคอลอย่าง LTE/5G IMS ซึ่งใช้การบีบอัดเฮดเดอร์ โดยเฮดเดอร์ส่วนใหญ่ 40 ไบต์ต่อเฟรมนั้นคาดเดาได้

  • เวลาแฝง เป็นเรื่องสำคัญถึงขั้นชี้เป็นชี้ตาย แต่หากแบนด์วิดท์ที่ใช้ได้ต่ำ การรวมตัวอย่างเสียง 20ms จำนวน 2~5 ชุดแล้วส่งพร้อมกัน ก็ช่วยลดโอเวอร์เฮดได้มาก
    แพ็กเก็ต 100ms จะเพิ่มดีเลย์มาก แต่เมื่อถึงระดับนั้น ผลประหยัดจากโคเดกก็เริ่มมีความหมาย ระบบที่ซับซ้อนกว่านี้สามารถปรับทั้งโคเดกและจำนวนตัวอย่างต่อแพ็กเก็ตตามสภาพปัจจุบันได้
    ระบบที่ผมดูแลใช้โคเดกคงที่และมีเสียง 60ms ต่อแพ็กเก็ต จึงไม่ถึงกับเหมาะที่สุด แต่ทำงานได้ดีกว่ามากบนแบนด์วิดท์ต่ำเมื่อเทียบกับแพ็กเก็ต 20ms
    Meta มีการกระจายตัวของเซิร์ฟเวอร์ฟอร์เวิร์ดกว้างมาก จึงพอมีที่ว่างให้เพิ่มดีเลย์จากการสุ่มตัวอย่างอีกเล็กน้อยได้ สามารถฟอร์เวิร์ดผ่านอุปกรณ์คอนเทนต์ที่อยู่ภายใน ISP หลายราย ทำให้ลดดีเลย์เครือข่ายได้เมื่อเทียบกับบริการคู่แข่งที่มีความสามารถในการโฮสต์ฟอร์เวิร์ดทั่วโลกจำกัดกว่า P2P ก็ไม่ได้ทำงานได้เสมอไป และไม่ได้มีดีเลย์ต่ำกว่าการวิ่งผ่านเซิร์ฟเวอร์ฟอร์เวิร์ดใกล้ ๆ เสมอไปด้วย
  • เมื่อดูจากขนาดงานเสียง/ออดิโอที่ Meta จัดการอยู่แล้วบน Facebook, Facebook Live, Instagram และ WhatsApp การประเมินแบบนั้นมีโอกาสสูงที่จะผิด
    โดยเฉพาะข้อความเสียงและการโทรของ WhatsApp มีส่วนแบ่งสูงมากในประเทศที่สภาพเครือข่ายไม่ต่อเนื่องและไม่น่าเชื่อถือ หากทนต่อ packet loss และ jitter ได้ดีขึ้น ก็สามารถพึ่งพาโปรโตคอลที่มีโอเวอร์เฮดด้านการแก้ไขข้อผิดพลาด การแบ่งส่วน และการตอบรับการรับข้อมูลน้อยลงได้
    จึงไม่เกินจริงที่จะมองว่าเทคโนโลยีนี้สามารถลดการใช้แบนด์วิดท์รวมที่เกิดจากออดิโอได้พอสมควร ขณะยังคงรักษาหรือปรับปรุงความน่าเชื่อถือและ คุณภาพ ที่ผู้ใช้รับรู้ได้
    ตอนดูสาย WhatsApp ที่กำลังใช้งานด้วย Wireshark พบว่าในการโทร 1 นาที มีแพ็กเก็ต UDP จากผู้ส่งไปยังผู้รับประมาณ 380 แพ็กเก็ต และมีแพ็กเก็ต TCP ไปยังเซิร์ฟเวอร์ WhatsApp อีกไม่กี่แพ็กเก็ต แบบนี้โอเวอร์เฮดในการส่งอยู่ราว 2.2kbps
    เพิ่มเหตุผลอีกอย่างคือ ptime เริ่มต้นในที่นี้ หรือขนาดออดิโอต่อแพ็กเก็ต ถูกตั้งไว้ที่ 20ms แต่ maxptime ถูกตั้งไว้ที่ 150ms ไคลเอนต์สามารถใช้ค่านี้แบบฉวยโอกาส โดยพิจารณาดีเลย์ของทั้งสองฝั่งและแบนด์วิดท์ที่ใช้ได้ เพื่อลดจำนวนแพ็กเก็ตที่ส่ง
    รูปภาพ: https://www.twilio.com/content/dam/twilio-com/global/en/blog...
  • อีกการใช้งานที่น่าสนใจของ การบีบอัดเสียงพูดบิตเรตต่ำมาก แบบนี้คือระบบวิทยุดิจิทัล
    โคเดกเสียงพูดอย่าง AMBE+2 ที่ใช้กันทั่วไปในระบบวิทยุมีคุณภาพเสียงค่อนข้างแย่ และรับมือกับ packet loss ได้ไม่สวยงามเท่าโคเดกรุ่นใหม่ ๆ
  • ตามบทความบล็อก นี่เป็นงานวิจัยเชิงปฏิบัติที่ Meta ทำเพื่อปรับปรุงบริการของตัวเอง
    อาจเป็นการคุยโตก็ได้ แต่เมื่อดูว่า Meta เป็นหนึ่งในผู้ให้บริการรายใหญ่ที่สุดด้านการโทรเสียงและวิดีโอบนอุปกรณ์แบนด์วิดท์ต่ำ โอกาสแบบนั้นดูจะน้อย
    ผมไม่รู้ว่ามีหลักฐานอะไรที่บอกได้ว่า Meta เข้าใจผิดกันเองมาตลอด
  • ผมไม่ค่อยรู้จักการตั้งค่าที่รองรับ มัลติเพล็กซ์ แบบเดียวกับที่ผมคิดไว้ แต่กรณีที่เซิร์ฟเวอร์มีสตรีมออดิโอขาเข้าหลายสายที่ไม่ควรผสมกัน ก็เป็นการใช้งานที่น่าสนใจเช่นกัน
    เช่น ในกรณีที่ไม่ควรให้เซิร์ฟเวอร์มิกซ์เสียงเพราะมีการเข้ารหัสแบบปลายทางถึงปลายทาง ก็สามารถใส่ข้อมูลจากหลายสตรีมไว้ในแพ็กเก็ตเดียวได้ การโทรเสียงแบบเข้ารหัสปลายทางถึงปลายทางตอนนี้แพร่หลายพอสมควรแล้ว และ Facebook ก็ดูอยู่ในตำแหน่งที่ดีสำหรับทำมัลติเพล็กซ์แบบกำหนดเองในผลิตภัณฑ์ของตัวเอง

• มีแค่ผมหรือเปล่าที่รู้สึกว่า Meta กลับมาดูเท่อีกครั้ง เพราะแชร์งานวิจัยและโอเพนซอร์ส หรือผลงานที่มี น้ำหนักโมเดลสาธารณะ ออกมามากมาย
  ชื่อเสียงของ Facebook เคยตกต่ำสุด ๆ แต่ตอนนี้ดูเหมือนกู้กลับมาได้บ้างแล้ว

  • ผมก็รู้สึกแบบเดียวกัน
    ชื่อเสียงของ Facebook ในฐานะโซเชียลเน็ตเวิร์กอาจไม่ได้สดใสนัก แต่ชื่อเสียงของ Meta ในฐานะบริษัทวิศวกรรม ผมว่าค่อนข้างสูง
    คล้ายกับ IBM อยู่บ้าง ในฐานะผู้ให้บริการฮาร์ดแวร์หรือซอฟต์แวร์โซลูชัน อาจดูไม่ได้ยอดเยี่ยมมาก แต่ฝ่ายวิจัยและไมโครอิเล็กทรอนิกส์ยังคงเท่มากทีเดียว
  • ฝ่ายวิจัย กับฝ่ายผลิตภัณฑ์ไม่ใช่สิ่งเดียวกัน
    Microsoft Research ก็ปล่อยของเจ๋ง ๆ ออกมามาก แต่ไม่ได้หมายความว่า Microsoft เดียวกันนั้นจะไม่ใส่โฆษณาไว้ในเมนูเริ่มของระบบปฏิบัติการ
    เมื่อหลายปีก่อน ตอนเป็นวัยรุ่น ผมเห็นความแตกต่างอันน่าสนใจแบบนี้ที่ Microsoft และก็ไม่แปลกใจเลยที่ใน Facebook จะมีทั้งแผนกที่ทำงานเจ๋ง ๆ อย่าง zstandard กับคนอีกกลุ่มที่แยกกันโดยสิ้นเชิงและทำงานเพื่อเป้าหมายต่างกันโดยสิ้นเชิงอยู่พร้อมกัน อาจเป็นไปได้ว่าบริษัทส่วนใหญ่ที่มีคนเกินหลักร้อยก็มีความแตกต่างระหว่างแผนกแบบนี้
  • ผมมองในแง่ดีมากกับวิธีที่ Meta แชร์งานวิจัยและเปิดเผยซอฟต์แวร์เป็นโอเพนซอร์ส
    แต่ผมมองในแง่ลบมากกับท่าทีของ Meta ต่อ ความเป็นส่วนตัว, ความปลอดภัย และความรับผิดชอบต่อสังคม
  • อย่าโดนหลอกจะดีกว่า สุดท้ายผู้เล่นที่ทรงอำนาจก็จะหาวิธีเอาเปรียบผู้ใช้เพื่อเศษเงินอยู่ดี
  • Meta มีประวัติการเปิดซอร์สระบบที่สร้างขึ้นเพื่อขับเคลื่อนบริการของตัวเอง
    นึกถึง CassandraDB และ (Py)Torch

• ไม่มีการกล่าวถึงหรือเปรียบเทียบกับ Codec2 เลย ทำให้คุณค่าจริงและแรงจูงใจของงานนี้น่าสงสัยขึ้นมาทันที
  ในพื้นที่นี้เราไม่จำเป็นต้องมีโค้ดเสียงอีกตัวที่ถูกผูกด้วยสิทธิ์ในทรัพย์สินทางปัญญา

  • ไม่ได้เปรียบเทียบกับ Lyra ด้วย: https://github.com/google/lyra
  • ยังมี LPCNet Codec ที่ออกมาในปี 2019 ด้วย ใช้ recurrent neural network เพื่อประมวลผลเสียงพูดแบบ wideband ที่ 1.6kb/s
    https://jmvalin.ca/demo/lpcnet_codec/

• สงสัยว่ามันดีกว่าเมื่อเทียบกับสิ่งที่ Google Meet ใช้อยู่หรือไม่
  แม้บนอินเทอร์เน็ตช้าที่กระตุกจนแทบใช้ไม่ได้ Google Meet ก็ยังทำหน้าที่สำหรับการคุยเสียงได้สำเร็จ ขณะที่บริการคู่แข่งอื่น ๆ ล้มเหลว เช่น เคยทดสอบบนอินเทอร์เน็ตที่แย่มากบนเกาะห่างไกลในฟิลิปปินส์
  แต่เท่าที่ฉันรู้ เทคโนโลยีของ Google Meet ไม่ได้เผยแพร่ไว้ที่ไหนเลย

  • ถ้าโพสต์ประชาสัมพันธ์นี้ไม่มี โค้ด ก็แทบจะทดสอบไม่ได้
    จากตัวอย่างไม่กี่อย่างที่เผยแพร่ เราก็ตัดสินได้แค่ในระดับเดียวกันเท่านั้น

• ไม่ได้เปรียบเทียบกับ Pied Piper ด้วย

  • คะแนน Weissman อาจจะอยู่แถว ๆ 5 แต่ยังไม่เคยเห็นการใช้งานจริง ใช้ middle-out compression หรือเปล่า?

• ออกนอกประเด็นเล็กน้อย แต่ทำไมการโทรศัพท์ทั่วไปสมัยนี้ถึงฟังรู้เรื่องยากกว่า 8kHz 8-bit μ-law กับ ADPCM ในยุค 90
  แก้ไข: เปลี่ยน “เสียงแย่กว่า” เป็น “ฟังรู้เรื่องยากกว่า”

  • ขึ้นอยู่กับว่าเป็นการโทรแบบไหน μ-law มี frequency response แย่และ dynamic range พอใช้
    ไม่ค่อยเหมาะกับเพลง แต่กับเสียงพูดก็พอใช้ได้ และเหนือสิ่งอื่นใดคือสม่ำเสมอมาก การโทรในยุค 90 ช่วงปลายทางแทบทั้งหมดเป็น circuit switching และบนสายดิจิทัลก็ multiplex กันในระดับ sample ส่วน T1 ขึ้นไปเป็นแบบนั้น
    ดังนั้น latency จึงต่ำมากและ jitter เป็น 0 เมื่อเทียบกับการโทรแบบ circuit switching อนาล็อกทั้งสองฝั่ง แม้จะมี latency ที่วัดได้ แต่แทบรู้สึกไม่ได้ในทางปฏิบัติ และเพราะสุ่มตัวอย่างดิจิทัลใกล้ปลายทั้งสองฝั่ง noise จึงน้อยกว่ามาก circuit switching ยังหมายความว่า sample จะไม่สูญหายด้วย คือเชื่อมต่อได้หรือไม่ได้อย่างใดอย่างหนึ่ง แม้บางครั้งจะมีกรณีได้แค่ทิศทางเดียว
    การโทรสมัยใหม่มักใช้ sample 20ms บนเครือข่าย packet switching จึงมี sampling latency, jitter และ jitter buffer เพิ่มเข้ามา ตัว codec เองก็ทำงานมากกว่าแค่ ADC/DAC พร้อม log ธรรมดา จึงมี latency จากการ encode/decode ด้วย codec ส่วนใหญ่ใช้บิตต่อ sample น้อยกว่า μ-law มาก และสิ่งนั้นไม่ได้มาฟรี
    HD Voice (G.722.2 AMR-Wideband) มีย่านความถี่ที่ผ่านได้กว้างกว่ามาก จึงฟังดีกว่า GSM, Opus และ codec แบนด์วิดท์ต่ำส่วนใหญ่มาก แต่ latency ก็ยังมีอยู่ บางคนอาจบอกว่า latency 20–100ms ไม่รู้สึก แต่ถ้าให้ฟังแบบ A/B ระหว่างสายที่ latency 0ms กับ 20ms ก็น่าจะบอกว่าสาย 0ms ดีกว่า
  • ลำโพงหูฟังของมือถือสมัยนี้เบากว่าเมื่อก่อน ทำให้ถ้าอีกฝ่ายไม่พูดใส่ไมค์ให้ชัด ก็เร่งเสียงได้ยาก
    ปี 2013 ฉันเปลี่ยนจากโทรศัพท์ฝาพับมาเป็น iPhone และความต่างใหญ่มาก จากนั้นก็หันไปใช้เอียร์บัดหรือสปีกเกอร์โฟนทันที ตอนนั้นฉันยังเป็นวัยรุ่น
  • อายุมากขึ้น การได้ยินก็ลดลง
  • Packet switching ทำ packet หล่น ส่วน circuit switching ทำให้ความพยายามโทรไม่สำเร็จ เช่น ถ้าทุกวงจรไม่ว่างก็เชื่อมต่อไม่ได้
    การโทรส่วนใหญ่ในยุค 90 ไม่ได้ใช้ ADPCM แต่ใช้ PCM ธรรมดา คงสับสนตรงนั้น
    และไม่ได้ใช้ไร้สายด้วย จากไมค์ของฉันไปถึงหูฟังของอีกฝ่ายมีสายทองแดงแข็ง ๆ เชื่อมอยู่ ไร้สาย ไม่ว่าจะเป็นโทรศัพท์มือถือ, Wi‑Fi หรือโทรศัพท์ไร้สาย โดยเนื้อแท้แล้วมีความน่าเชื่อถือต่ำกว่า
    โทรศัพท์สมัยก่อนมี sidetone แต่แอป VoIP หลายตัวไม่มี
    สุดท้าย ตอนนี้การใช้สปีกเกอร์โฟนแพร่หลายมากขึ้น ซึ่งสปีกเกอร์โฟนไม่เข้ากับ sidetone และเพิ่ม audio multipath fading เข้ามามาก

• ไม่มีการกล่าวถึง NoLACE ทำให้ความมีประโยชน์ของตัวอย่างเปรียบเทียบลดลงเล็กน้อย: https://opus-codec.org/demo/opus-1.5/

  • อันนี้ยอดเยี่ยมจริง ๆ และชื่นชม Xiph อย่างมากที่ทุ่มเทแรงมากขนาดนี้กับการทำให้เป็นมาตรฐาน
    https://datatracker.ietf.org/wg/mlcodec/documents/
    ถ้า Meta บริจาคสิ่งนี้ให้โลก ก็คงช่วยลดการขัดขวางจาก patent troll และพาเราไปสู่อนาคตที่เราควรได้มีได้

• นี่จะเปิดเผยให้ใช้งานหรือเปล่า หรือเป็นแค่การอวดผลงานวิศวกรรม? นอกจากบล็อกโพสต์นี้แล้ว หา reference อื่นเกี่ยวกับ MLow ไม่เจอเลย
  Facebook/Meta AI Research ทำงานเจ๋ง ๆ และเปิดเผยผลงานจำนวนไม่น้อย ฉันไม่ชอบ Facebook แต่ยอมรับได้ว่าในด้าน AI พวกเขามีนวัตกรรมสูงมาก

  • ถ้าหมายถึงว่าได้นำอัลกอริทึมไป implement ในผลิตภัณฑ์แล้ว ก็น่าจะเป็นแบบนั้น
    ในบทความเขียนว่า “เราดีใจมากกับความสำเร็จที่ทำได้ตลอด 2 ปีที่ผ่านมา ตั้งแต่พัฒนา codec ใหม่ไปจนถึง deploy ให้ผู้ใช้หลายพันล้านคนทั่วโลกได้สำเร็จ”

• ขอถามแบบตรง ๆ ว่า ทำไมต้องปรับให้เหมาะกับ ต่ำกว่า 10kbps ด้วย
  การทำได้ขนาดนี้ที่ 6kbps นั้นน่าประทับใจมากก็จริง แต่ LTE ก็รองรับได้มากกว่า 32kbps อยู่แล้ว และในช่วงนั้นก็มี AMR-WB หรือ Opus อยู่ Opus ยังมีการแก้ไขข้อผิดพลาดแบบไปข้างหน้าในแบนด์ที่บิตเรตนี้ด้วย ดังนั้นการสูญเสียแพ็กเก็ตจึงไม่ได้ร้ายแรงขนาดนั้น
  อาจมีประโยชน์สำหรับการใช้งานอย่างดาวเทียมเชื่อมตรงถึงมือถือก็ได้

  • ส่วน “แรงจูงใจในการสร้างโคเดกใหม่” ในบทความตอบคำถามนี้โดยตรง
    การสมมติว่ามี แบนด์วิดท์เกิน 32kbps เป็นสมมติฐานที่ไม่ดี
  • ยังมีคนอีกหลายพันล้านคนที่ไม่มี LTE Meta ไม่ใช่บริษัทที่ดำเนินงานเฉพาะในโลกตะวันตก
  • การใช้งานของ Meta คือแอปพลิเคชัน OTT บนอินเทอร์เน็ต และโดยปกติคิดค่าบริการตามจำนวนไบต์ที่ส่ง
    ถ้าลดบิตเรตของโคเดกเสียงที่ใช้ ก็จะโทรได้นานขึ้นในหนึ่งเดือนด้วยแพ็กเกจดาต้าเดิม
    อย่างไรก็ตาม ในพื้นที่นี้ผลตอบแทนจะลดลงเพราะโอเวอร์เฮดของ RTP, UDP, IP รายละเอียดอยู่ในคอมเมนต์อื่นที่ฉันเขียนไว้
  • มีประโยชน์
    พื้นที่นี้ตอนนี้ถูก AMBE ครองแน่นอยู่ และ AMBE นั้นแย่มากในทุกตัวชี้วัดที่วัดได้ ถึงขั้นควรถูกเผาในไฟนรกชั้นลึกสุดและลบออกจากประวัติศาสตร์
  • การเชื่อมต่ออินเทอร์เน็ตมักมีเส้นโค้งความสัมพันธ์ระหว่างปริมาณงานกับเวลาแฝง
    ถ้าต้องการเวลาแฝงต่ำที่เสถียรเหมือนการคุยโทรศัพท์ ปริมาณงานที่ได้จะน้อยมาก
    ตัวอย่างเช่น Wi-Fi ที่ขอบระยะสัญญาณ หรือการเชื่อมต่อ LTE ที่มีสัญญาณแค่หนึ่งขีด
    ในกรณีแบบนี้ การทดสอบความเร็วอาจบอกว่าได้หลายเมกะบิต แต่ถ้าต้องการความหน่วงต่ำที่เสถียร แบนด์วิดท์ที่ใช้ได้จริงน่าจะอยู่ในระดับกิโลบิต

• อยากรู้ว่าถ้าเทียบกับ G.729 แล้วจะฟังเป็นอย่างไร
  บริษัทที่เคยทำงานเมื่อ 20 ปีก่อนมี โคเดก G.729 ที่ปรับแต่งแล้ว ซึ่งแม้จะลงไปต่ำกว่า 8kbps ก็ยังฟังดูค่อนข้างดี เราใช้กับ VoIP บนอินเทอร์เน็ตแบบ dial-up ดังนั้นเป็นแบนด์วิดท์ต่ำจริง ๆ
  ปรากฏว่าบางส่วนที่น่าสนใจกว่านั้นอยู่ที่จิตเตอร์บัฟเฟอร์และวิธีจัดการบัฟเฟอร์ การเชื่อมต่อที่ไม่เสถียรจะส่งแพ็กเก็ตเมื่อทำได้ และต้องใช้เทคนิคในการจัดการความต่างระหว่างประสบการณ์ของเครือข่ายกับประสบการณ์ของผู้ใช้ ในงานสื่อสาร ต้องจัดการประสบการณ์ผู้ใช้ให้ดี