การปรับแต่ง Bluetooth stack เพื่อยกระดับคุณภาพเสียงของหูฟังที่ไม่มี AAC, aptX, LDAC

 (habr.com)
1 คะแนน โดย GN⁺ 2023-11-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • คุณภาพเสียงที่ต่ำของ SBC codec มาตรฐานไม่ได้เกิดจากข้อจำกัดของ codec เพียงอย่างเดียว แต่ยังมาจากข้อจำกัดแบบอนุรักษ์นิยมของ Bluetooth stack และการตั้งค่าหูฟัง ทำให้อุปกรณ์เดิมยังมีช่องทางปรับปรุงได้ด้วยการแก้ซอฟต์แวร์
  • Bluetooth stack ทั่วไปมักเจรจาเสียงสเตอริโอ 44.1kHz ที่ 328kbps แต่ถ้าบังคับใช้ Dual Channel จะเพิ่มขึ้นได้ถึงราว 617kbps ที่ bitpool 53 เท่ากัน
  • แพตช์สำหรับ Android 8.1 และ 9 เพิ่ม SBC Dual Channel เข้าไปในการตั้งค่าอุปกรณ์ Bluetooth ในลักษณะเดียวกับตัวเลือก HD Audio และใช้ 551kbps สำหรับอุปกรณ์ EDR 3Mb/s และ 452kbps สำหรับอุปกรณ์ EDR 2Mb/s
  • ค่า 551kbps และ 452kbps เป็นค่าที่เลือกโดยคำนึงถึงประสิทธิภาพการส่งแบบ 5-slot ของ Bluetooth หากเพิ่ม bitpool มากกว่านี้ จำนวนเฟรมที่รวมส่งได้จะลดลง ทำให้มีโอกาสเสียงสะดุดมากขึ้นในสภาพสัญญาณไร้สายไม่ดี
  • ผู้ใช้ LineageOS, Resurrection Remix, crDroid สามารถเปิด SBC บิตเรตสูงได้จาก checkbox ในการตั้งค่า ส่วนผู้ใช้ Linux สามารถใช้แพตช์ PulseAudio เพื่อได้บิตเรต SBC ที่สูงขึ้นและการรองรับตระกูล aptX

ทำไมคุณภาพเสียง SBC จึงฟังดูต่ำ

  • ผู้ใช้หูฟังไร้สายบางส่วนพบว่าคุณภาพเสียงลดลงและย่านเสียงสูงขาดหายเมื่อใช้ SBC codec ซึ่งอุปกรณ์เสียง Bluetooth ทุกเครื่องรองรับ
  • อีกทางหนึ่งคือซื้ออุปกรณ์และหูฟังที่รองรับ aptX หรือ LDAC แต่ codec เหล่านี้มีค่าลิขสิทธิ์ ซึ่งอาจทำให้ราคาอุปกรณ์สูงขึ้น
  • สาเหตุหลักของคุณภาพ SBC ที่ต่ำคือ ข้อจำกัดที่ตั้งขึ้นโดย人为 ใน Bluetooth stack และการตั้งค่าหูฟังปัจจุบัน และอุปกรณ์เดิมก็สามารถเลี่ยงได้ด้วยการแก้ซอฟต์แวร์

พารามิเตอร์และบิตเรตของ SBC

  • SBC จะเจรจาพารามิเตอร์หลายอย่างในขั้นตอนตั้งค่าการเชื่อมต่อ
    • ประเภทและจำนวนช่องสัญญาณเสียง: Joint Stereo, Stereo, Dual Channel, Mono
    • จำนวนแถบความถี่: 4 หรือ 8
    • จำนวนบล็อกเสียงในแพ็กเก็ต: 4, 8, 12, 16
    • วิธีจัดสรรบิตสำหรับ quantization: Loudness, SNR
    • bitpool ต่ำสุดและสูงสุดที่ใช้สำหรับ quantization: โดยทั่วไป 2..53
  • ตัวถอดรหัสต้องรองรับการผสมพารามิเตอร์เหล่านี้ทั้งหมด แต่ตัวเข้ารหัสอาจนำไปใช้เพียงบางส่วน
  • Bluetooth stack เดิมมักเจรจาชุด Joint Stereo, 8 bands, 16 blocks, Loudness, bitpool 2..53 และในกรณีนี้เสียงสเตอริโอ 44.1kHz จะถูกเข้ารหัสที่ 328kbps
  • bitpool เป็นค่าที่เปลี่ยนบิตเรตของการเข้ารหัส ยิ่งค่าสูง บิตเรตและคุณภาพยิ่งสูงขึ้น
    • ความสัมพันธ์ที่ถูกต้องระหว่างค่า bitpool กับบิตเรตจะใช้ได้เฉพาะภายในโปรไฟล์หนึ่งๆ เท่านั้น
    • ประเภทช่องสัญญาณ จำนวนแถบความถี่ และจำนวนบล็อกเสียงก็มีผลอย่างมากต่อบิตเรตเช่นกัน
  • Dual Channel ต่างจาก Stereo หรือ Joint Stereo ตรงที่เข้ารหัสแต่ละช่องแยกกันและใช้ bitpool แยกต่อช่อง
    • หากบังคับใช้ Dual Channel แทน Joint Stereo แม้จะใช้ bitpool 53 เท่ากัน บิตเรตก็จะเพิ่มเป็นราว 617kbps ซึ่งเกือบสองเท่า

ข้อกำหนด A2DP และข้อจำกัดของ stack ปัจจุบัน

  • A2DP specification v1.2 ซึ่งมีผลตั้งแต่ปี 2007 ถึง 2015 กำหนดให้ตัวถอดรหัสต้องรองรับค่า bitpool ทุกค่าที่ไม่เกินบิตเรตสูงสุด
    • โปรไฟล์นี้จำกัดบิตเรตสูงสุดไว้ที่ 320kb/s ในโหมด mono และ 512kb/s ในโหมด 2-channel
  • ข้อกำหนดใหม่ไม่ได้ระบุข้อจำกัดด้านบิตเรตไว้
  • สันนิษฐานได้ว่าหูฟังรุ่นใหม่ที่รองรับ EDR และวางจำหน่ายหลังปี 2015 อาจรองรับได้สูงสุดถึง 730kbps
  • Bluetooth stack ที่ทดสอบ ได้แก่ Linux PulseAudio, Android, Blackberry, macOS ล้วนมีข้อจำกัดที่ตั้งขึ้นโดย人为ต่อพารามิเตอร์ bitpool สูงสุด
  • หูฟังแทบทั้งหมดก็จำกัดค่า bitpool สูงสุดไว้ที่ 53
  • ใน Bluetooth stack ที่แก้ไขแล้ว อุปกรณ์ส่วนใหญ่ทำงานที่ 551kbps ได้โดยไม่สะดุดหรือมีเสียงรบกวน แต่ Bluetooth stack พื้นฐานจะไม่เจรจาบิตเรตนี้ในสภาพทั่วไป

แพตช์ Bluetooth stack ของ Android

  • Bluetooth stack ที่เข้ากันได้กับ A2DP ทุกตัวต้องรองรับโหมด Dual Channel แต่ผู้ใช้ทั่วไปไม่มีวิธีบังคับใช้โหมดนี้
  • แพตช์สำหรับ Android 8.1 และ Android 9 เพิ่ม Dual Channel เข้าไปใน stack และเมนูนักพัฒนา และปฏิบัติกับมันเป็นตัวเลือก codec HD Audio ในการตั้งค่าอุปกรณ์ Bluetooth เช่นเดียวกับ aptX, AAC, LDAC
  • ลิงก์แพตช์
  • checkbox นี้ใช้สลับโหมด Dual Channel และใช้อัตราบิตต่อไปนี้ตามอุปกรณ์
    • อุปกรณ์ EDR 3Mb/s: 551kbps
    • อุปกรณ์ EDR 2Mb/s: 452kbps
  • ชุดแพตช์ถูกรวมเข้าในเฟิร์มแวร์ทางเลือกต่อไปนี้
    • LineageOS 15.1: ตั้งแต่ 31 มีนาคม 2019
    • LineageOS 16.0: ตั้งแต่ 13 พฤษภาคม 2019
    • Resurrection Remix: ตั้งแต่ 14 พฤษภาคม 2019
    • crDroid: ตั้งแต่ 13 พฤษภาคม 2019

เหตุผลที่เลือก 551kbps และ 452kbps

  • การส่งข้อมูลแบบแบ่งเวลาใน Bluetooth ถูกออกแบบมาให้ส่งแพ็กเก็ตขนาดคงที่ขนาดใหญ่ได้อย่างมีประสิทธิภาพ
  • จำนวน slot สูงสุดที่ส่งได้ในการส่งหนึ่งครั้งคือ 5 slot และแม้จะมีโหมดส่งแบบ 1-slot และ 3-slot แต่ไม่มีโหมด 2-slot หรือ 4-slot
  • ปริมาณข้อมูลที่ส่งได้ในการส่งแบบ 5-slot มีดังนี้
    • การเชื่อมต่อ 2Mbps: สูงสุด 679 bytes
    • การเชื่อมต่อ 3Mbps: สูงสุด 1021 bytes
  • ปริมาณข้อมูลสูงสุดของการส่งแบบ 3-slot มีดังนี้
    • การเชื่อมต่อ 2Mbps: 367 bytes
    • การเชื่อมต่อ 3Mbps: 552 bytes
  • หากส่งข้อมูลที่มากกว่า 367 หรือ 552 bytes แต่น้อยกว่า 679 หรือ 1021 bytes ก็ยังต้องใช้ 5-slot ทำให้ประสิทธิภาพการส่งลดลง
  • เมื่อเข้ารหัสเสียง 44.1kHz ด้วย SBC Dual Channel, bitpool 38, 16 blocks, 8 frequency bands จะได้เฟรมเสียงขนาด 164-byte และบิตเรต 452kbps
  • payload เสียงต้องถูกห่อด้วยโปรโตคอลส่งข้อมูล L2CAP และ AVDTP ซึ่งในกระบวนการนี้จะมี overhead 16 bytes หักออกจาก payload เสียง
  • ใน EDR 2Mb/s DH5 การส่งเสียงแบบ 5-slot หนึ่งครั้งสามารถบรรจุเฟรมเสียงได้ 4 เฟรม
    • 679 - 4(L2CAP) - 12(AVDTP/RTP) - 1(SBC header) - (164*4) = 6
    • ในแพ็กเก็ตจะเหลือพื้นที่ 6 bytes
    • แพ็กเก็ตเดียวบรรจุข้อมูลเสียงได้สูงสุด 11.7ms และส่งภายใน 3.75ms
  • หากเพิ่ม bitpool เพียงเล็กน้อย ก็จะไม่สามารถบรรจุเฟรมเสียง 4 เฟรมในการส่งครั้งเดียวได้ ต้องส่งครั้งละ 3 เฟรม
    • ประสิทธิภาพการส่งลดลง
    • ปริมาณเสียงที่บรรจุในหนึ่งแพ็กเก็ตลดลง
    • โอกาสเสียงสะดุดในสภาพสัญญาณไร้สายไม่ดียิ่งเพิ่มขึ้น
  • 551kbps สำหรับ EDR 3Mb/s ก็ถูกเลือกด้วยหลักการเดียวกัน
    • ที่ bitpool 47, 16 blocks per frame, 8 frequency bands ขนาดเฟรมคือ 200 bytes
    • สามารถรวมส่งได้สูงสุด 5 เฟรมในการส่งหนึ่งครั้ง หรือเท่ากับเพลง 14.6ms
  • การคำนวณพารามิเตอร์ SBC ซับซ้อนและเกิดข้อผิดพลาดได้ง่ายหากคำนวณด้วยมือ จึงมีเครื่องมือเว็บสำหรับคำนวณให้ใช้

ความต่างด้านคุณภาพเสียงระหว่าง aptX และ SBC

  • ตรงข้ามกับความเชื่อทั่วไปว่า aptX ดีกว่า SBC เสมอ ในบางกรณี aptX อาจให้คุณภาพเสียงต่ำกว่า SBC 328kbps มาตรฐาน
  • SBC จัดสรรบิต quantization ให้กับแถบความถี่แบบไดนามิก โดยกระจายบิตจากย่านล่างไปย่านบน
    • หากใช้บิตเรตทั้งหมดกับความถี่ต่ำและกลาง ความถี่สูงจะถูกตัดหรือทำให้เงียบ
  • aptX เป็น codec บิตเรตคงที่ที่ quantize แถบความถี่ด้วยจำนวนบิตเท่ากันเสมอ
    • 352kbps ที่ 44.1kHz
    • 384kbps ที่ 48kHz
  • aptX ไม่สามารถย้ายบิตไปยังความถี่ที่ต้องการได้ และแม้จะไม่ตัดความถี่ แต่จะเพิ่ม quantization noise ทำให้ dynamic range ของเสียงลดลง และบางครั้งอาจเกิดเสียงรบกวน
  • ในทางกลับกัน SBC จะทิ้งส่วนที่เงียบ และเมื่อเทียบกับ SBC 328kbps แล้ว aptX โดยเฉลี่ยมีความผิดเพี้ยนน้อยกว่าในเพลงที่มีช่วงความถี่กว้าง
  • สำหรับเพลงที่มีช่วงความถี่แคบและ dynamic range กว้าง SBC 328kbps อาจดีกว่า aptX ได้ในบางครั้ง
  • ในตัวอย่างการบันทึกเสียงเปียโน พลังงานส่วนใหญ่อยู่ที่ 0–4kHz และต่อเนื่องไปถึง 10kHz
    • SBC 328kbps ตัดช่วงตั้งแต่ 16kHz ขึ้นไปทั้งหมดเป็นระยะ
    • aptX ใส่ความผิดเพี้ยนมากกว่าในสเปกตรัมความถี่ที่มนุษย์ได้ยิน
    • SBC 328kbps ให้ความผิดเพี้ยนน้อยกว่าในช่วง 0–10kHz และตัดความถี่ที่เหลือ
    • SBC 485kbps เพียงพอที่จะรักษาช่วงความถี่ทั้งหมดไว้โดยไม่ตัด
  • มีไฟล์เสียงต้นฉบับและไฟล์ที่เข้ารหัสด้วย SBC/aptX ให้ใช้งาน
  • หากใช้ SBC บิตเรตสูง ในกรณีส่วนใหญ่จะได้เสียงที่ดีกว่า aptX และ 551kbps SBC บนหูฟังที่รองรับ EDR 3Mb/s ให้เสียงใกล้เคียง aptX HD มาก

ตัวเลือกบิตเรตที่สูงขึ้น

  • ชุดแพตช์ Android มีตัวเลือกเพิ่มเติมสำหรับเพิ่มบิตเรตของอุปกรณ์ EDR 2Mb/s
  • หากตั้งค่า persist.bluetooth.sbc_hd_higher_bitrate เป็น 1 จะเพิ่มบิตเรตจาก 452kbps เป็น 595kbps ได้
  • ตัวเลือกนี้อาจลดความเสถียรของการส่งข้อมูลในสภาพแวดล้อมไร้สายที่หนาแน่น
# setprop persist.bluetooth.sbc_hd_higher_bitrate 1
  • แพตช์บิตเรตสุดขั้วปัจจุบันถูกรวมเข้าเฉพาะใน LineageOS 15.1 เท่านั้น และยังไม่ถูกรวมใน LineageOS 16.0

อุปกรณ์ที่เข้ากันได้และเครื่องมือเปรียบเทียบ

  • SBC Dual Channel รองรับในหูฟัง ลำโพง และเฮดยูนิตรถยนต์เกือบทั้งหมด
  • เนื่องจากมาตรฐานกำหนดให้อุปกรณ์ถอดรหัสทุกตัวต้องรองรับโหมดนี้ จึงทำงานได้กับอุปกรณ์ส่วนใหญ่
  • มีอุปกรณ์ส่วนน้อยที่มีปัญหาในโหมดนี้ แต่เป็นกรณีที่พบได้ยากมาก
  • สามารถตรวจสอบข้อมูลอุปกรณ์ที่เข้ากันได้จากชุมชนต่อไปนี้
  • ยังมีเว็บเซอร์วิสที่เข้ารหัสเสียงแบบเรียลไทม์ในเบราว์เซอร์เป็น SBC, aptX, aptX HD
    • btcodecs.valdikss.org.ru/sbc-encoder
    • สามารถเปรียบเทียบเสียงของโปรไฟล์ SBC ต่างๆ และ codec อื่นๆ ผ่านหูฟังหรือลำโพงแบบมีสายได้โดยไม่ต้องส่งผ่าน Bluetooth จริง
    • สามารถเปลี่ยนพารามิเตอร์การเข้ารหัสได้โดยตรงแม้ระหว่างเล่นเสียง

ความพยายามนำเข้า AOSP และวิธีใช้งาน

  • มีการติดต่อผู้พัฒนา Bluetooth stack ของ Google เพื่อขอให้นำแพตช์เข้า AOSP ซึ่งเป็น branch หลักของ Android แต่ไม่ได้รับคำตอบ
  • แพตช์ที่ขึ้นบน Gerrit code review system for Android ก็ไม่ได้รับคอมเมนต์จากผู้เกี่ยวข้องกับการพัฒนา Android
  • Gerrit patchset เป็นหนึ่งใน revision แรกๆ ที่เก่าแล้ว และสามารถอัปเดตได้หากมีนักพัฒนาสนใจ
  • ผู้ใช้ LineageOS, Resurrection Remix, crDroid สามารถเพิ่มคุณภาพเสียง Bluetooth ได้โดยเปิด checkbox ในการตั้งค่าอุปกรณ์ Bluetooth
  • ผู้ใช้ Linux สามารถติดตั้ง แพตช์ PulseAudio ของ Pali Rohár เพื่อใช้บิตเรต SBC ที่สูงขึ้นได้
    • แพตช์นี้ยังเพิ่มการรองรับ codec aptX, aptX HD, FastStream ด้วย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-11-25
ความคิดเห็นจาก Hacker News

  • อันนี้ยอดเยี่ยมมาก: SBC รองรับกันอย่างกว้างขวาง และดูเหมือนเป็นการขยายมาตรฐานเดิมอย่างเป็นธรรมชาติ
    สำหรับผม ปัญหาไม่ใช่ว่าเป็น SBC หรือ LDAC/AAC แต่เป็น HFP ที่แย่มากต่างหาก ทันทีที่เปิดไมค์ก็รู้สึกเหมือนย้อนกลับไปยุค 90 และถ้าทำให้เสียง Bluetooth แบบสองทางออกมาดีได้จริง ก็คงน่ายินดีมาก

    • สุดท้ายคงเป็นเพราะต้องการ latency ต่ำ นั่นแหละมั้ง “สื่อ” อย่างเพลง/วิดีโอมีคุณภาพเสียงดีแต่ latency สูง และวิดีโอสามารถชดเชยได้ด้วยการหน่วงภาพให้เท่ากัน แต่สำหรับการโทรศัพท์ latency ระดับนั้นมากเกินไป
    • ผมไม่เข้าใจว่าทำไม HFP ยังเป็นมาตรฐานอุตสาหกรรมอยู่ อุปกรณ์ใน ecosystem เดียวกันอย่าง MacBook / iPhone / AirPods ดูจากคุณภาพเสียงแล้วก็น่าจะใช้ HFP
      หรืออาจเป็น AVRCP ก็ได้ แต่ไม่ว่าจะอย่างไหน เสียงก็แย่มาก
    • ฟีเจอร์นี้กำลังค่อย ๆ เข้าสู่ตลาดผ่าน LE Audio / Auracast อยู่ เพียงแต่น่าจะต้องใช้เวลาอีกสักพักกว่าจะมีการรองรับจากระบบปฏิบัติการที่ดี

  • บทความนี้ไม่ได้พูดถึง Bluetooth โดยรวม แต่เป็นการเจาะลึกบั๊กที่ฝังอยู่ใน Android Bluetooth stack
    สิ่งที่ผู้เขียนไม่ยอมรับเลยคือฮาร์ดแวร์พื้นฐานมีความหลากหลายมาก Android ทำงานอยู่บนชิปเซ็ต Bluetooth จำนวนมาก ดังนั้นการที่แพตช์ดูเหมือนใช้ได้กับฮาร์ดแวร์ของตัวเอง ไม่ได้รับประกันว่าจะใช้ได้กับโทรศัพท์ Android เครื่องอื่น
    อีกทั้งสิ่งที่อุปกรณ์กำลังทำอยู่ในขณะนั้นก็มีผลด้วย ถ้าสตรีมวิดีโอผ่าน Wi‑Fi บนชิปเซ็ตที่แชร์ BT+Wi‑Fi แล้วส่งเสียงไปยังหูฟัง อุปกรณ์ต้องแบ่งทรัพยากรระหว่างการใช้งาน Wi‑Fi กับ Bluetooth ดังนั้นเสียงที่เก็บในเครื่องกับเสียงที่สตรีมจึงไม่จำเป็นต้องได้ พารามิเตอร์โค้ดек แบบเดียวกัน
    หัวข้อนี้มีรายละเอียดปลีกย่อยมากมายที่ผู้เขียนไม่ได้พิจารณา จึงควรอ่านด้วยความระมัดระวัง

    • ในฐานะคนที่เคยพัฒนา custom ROM และเคยตรวจสอบ/รวมการแก้ไขของ valdikSS มาก่อน สิ่งที่ patchset นี้ทำไม่ใช่การแก้บั๊ก แต่เป็นการทำให้การเชื่อมต่อ source กับ sink สามารถเจรจา dual channel SBC ได้
      วิธีนี้ทำให้ใช้ bitrate สูงขึ้นได้โดยไม่เกิน bitpool สูงสุดที่ Android และตัวรับ Bluetooth บังคับไว้
      การเจรจาระหว่าง source กับ sink ยังคงเกิดขึ้นอยู่ และถ้าฝ่ายใดฝ่ายหนึ่งไม่รองรับ dual channel SBC ก็จะ fallback ไปใช้วิธีที่รองรับได้ อุปกรณ์ทั้งหมดที่ผมดูแลรองรับสิ่งนี้ และลำโพงราคาถูกบางตัวที่ทดสอบในตอนนั้นไม่รองรับ จึงเจรจาเป็นเซสชัน joint stereo
    • บทความเกี่ยวกับ Bluetooth โดยรวมอยู่ที่นี่: https://habr.com/en/articles/456182/

  • บน Windows มี Alternative A2DP Driver ที่ให้ฟีเจอร์นี้ ปรับพารามิเตอร์ SBC ได้ และยังทำให้ใช้ AAC หรือ aptX ได้ด้วย
    จากประสบการณ์ของผม มันทำงานได้ดี และยังช่วยให้ใช้ LDAC กับ Sony XM4 ได้ด้วย เป็นรูปแบบ trial แต่ราคาถูก
    ผมเคยเห็นระยะ Bluetooth ลดลงในโหมดคุณภาพสูง ซึ่งดูเหมือนเป็นสัญญาณว่า codec หรืออย่างน้อยบางอย่างกำลังเปลี่ยนจริง ๆ ไม่ใช่ placebo
    ไม่มีส่วนเกี่ยวข้องใด ๆ กับ https://www.bluetoothgoodies.com/a2dp/

    • ไม่รู้ว่า “Quality Loss” ที่พูดถึงตอน downsample จาก 48KHz เป็น 44.1KHz คืออะไร ถ้า resampling อย่างถูกต้อง จะเสียแค่ความถี่สูงมาก ๆ คือ 22050Hz ขึ้นไปเท่านั้น
      ช่วงการได้ยินของมนุษย์โดยทั่วไปถูกระบุไว้ถึง 20KHz แต่คนอายุน้อยบางคนอาจได้ยินความถี่สูงกว่านั้นเล็กน้อย

  • เผื่อเป็นข้อมูล บน Linux ก็สามารถเปิดใช้เสียง SBC bitrate สูงขึ้นได้ด้วยวิธีที่เรียกว่า SBC XQ เช่นกัน และยังใช้ mSBC เพื่อเสียง headset ที่ดีขึ้นได้ด้วย
    แน่นอนว่ายังเทียบกับระดับของ SBC หรือ aptX ไม่ได้เลย
    อยากให้ฝั่ง Google merge สิ่งเหล่านี้เข้ามาแล้วเสียที codec เสียงที่ดีกว่านี้มีหูฟังจำนวนมากรองรับ แต่ยังไม่แพร่หลาย และการปรับปรุงเสียงสองทางก็ยังขาดอยู่เป็นพิเศษ

    • บทความนี้เป็นบทความเมื่อ 4 ปีก่อน จึงยังไม่สะท้อนการเปลี่ยนแปลงภายหลัง เช่น การรองรับ LE Audio ที่ถูก merge เข้า Android
    • อยากรู้ว่าบน Linux เปิดใช้อันนั้นอย่างไร
      และอยากรู้วิธีตรวจสอบด้วยว่า headset ตอนนี้กำลังใช้อะไรอยู่
      จำได้ว่าเมื่อก่อนเคยใช้ PulseAudio ที่แพตช์แล้วซึ่ง expose การตั้งค่าที่เหมาะสม แต่ภายหลังได้ยินว่า “merge เข้าสายหลักแล้ว” ทว่าเอาเข้าจริงกลับหาการตั้งค่าหรือข้อมูลการใช้งานจริงไม่เจอ
    • แค่พยายามให้ Linux รองรับ AirPods แบบพอถูไถได้ก็เหนื่อยมากแล้ว

  • อยากให้ใครสักคนสร้าง Bluetooth audio profile ที่สามารถ buffer ล่วงหน้าได้นาน ๆ
    เช่น ถ้าเล่นเพลงยาว 1 นาที ก็ควรโหลดทั้งเพลงขึ้น buffer แน่นอนว่าถ้ากด pause หรือเปลี่ยน volume ก็ต้องทิ้ง buffer
    ถ้ามี buffer ยาว ๆ โทรศัพท์จะหลับได้บ่อยขึ้น ประหยัดพลังงาน และยังทนต่อการเชื่อมต่อไร้สายที่แย่ได้

    • เรื่องแบบนั้นดูมีโอกาสน้อยมาก ผมสงสัยอย่างยิ่งว่าหูฟังส่วนใหญ่จะมีหน่วยความจำสำหรับ buffer แบบนั้นหรือไม่
      ต่อให้เป็น RAM แค่ประมาณ 1~2MB หูฟังก็ต้องใช้แบตเตอรี่ที่มีค่าเพื่อคง RAM นั้นให้อยู่ในสถานะ active
      จากที่เคยแตะงานแอปเสียงมานิดหน่อย การรองรับฝั่งแอปพลิเคชันก็น่าจะยุ่งยากด้วย
    • คุณคงชอบมันแค่จนถึงวินาทีที่มีสายโทรเข้า แล้วแทนที่จะต้องฟัง Led Zeppelin อีก 1 นาทีถัดไปให้จบก่อน คุณจะอยากข้ามเนื้อหาที่ buffer ไว้นั้นและรับ สายเข้า ทันที
    • ถ้ามีหน่วยความจำ embedded เพียงพอก็ทำได้อยู่ แต่จะเป็นปัญหาเมื่อพยายาม sync เสียงกับวิดีโอ
      ดังนั้นสิ่งนี้น่าจะเป็นฟีเจอร์ที่แต่ละผลิตภัณฑ์ออกแบบใส่มาเอง และให้ผู้ใช้เปิด/ปิดในแอป มากกว่าจะเป็นปัญหาของ protocol
    • น่าเสียดาย แต่นั่นแทบจะตรงข้ามกับสิ่งที่ผู้ใช้ส่วนใหญ่ต้องการจากเสียงเลย

  • ผมเคยลองใช้ฟีเจอร์นี้บน LineageOS และพูดตรง ๆ ว่าดีมาก สามารถส่งเสียงคุณภาพสูงขึ้นไปยังอุปกรณ์อย่าง เครื่องเสียงรถยนต์ ที่ไม่รองรับ codec ของ third-party ได้ และกับหูฟังก็ช่วยได้พอสมควร
    user experience ยังต้องขัดเกลา แต่ตัวฟีเจอร์เองยอดเยี่ยม

    • น่าเสียดายที่ใน Lineage เวอร์ชันใหม่ ๆ มันหายไปแล้ว ตอนนี้แทบถูกลืมไปแล้ว

  • ควรใส่ 2019 ไว้ในชื่อเรื่องด้วย มีคำอย่าง “Bluetooth stack ทั้งหมดในปัจจุบัน” แต่สิ่งเหล่านี้ถูก implement ใน PulseAudio และ PipeWire มาพักหนึ่งแล้ว

  • ผมค่อนข้างสงสัยว่า 551kbps Dual Channel จะให้คุณภาพที่ดีกว่า 328kbps Joint Stereo อย่างเห็นได้ชัดจริงหรือเปล่า อาจเป็นแค่การใช้บิตมากขึ้นเพื่อ encode ข้อมูลที่ซ้ำซ้อนก็ได้
    อย่างน้อยก็กับเพลงส่วนใหญ่ และอาจมีข้อยกเว้นอย่างเพลงที่จงใจวาง track บันทึกเสียงคนละแบบไว้ซ้ายขวา

  • คำถามที่เกี่ยวข้องคือ อยากรู้ว่ามีวิธีปรับปรุง Bluetooth HFP บน macOS ไหม
    headset ตัวเดียวกันนี้บน Linux ผมใช้ mSBC ได้คุณภาพค่อนข้างดี แต่บน macOS แย่สุด ๆ และกลายเป็นคุณภาพระดับสายโทรศัพท์/โมโน อยากรู้ว่ามี hack ที่ทำให้มันทำงานได้ถูกต้องบน Darwin อยู่แล้วหรือยัง

  • ก่อนอ่านบทความนี้ ผมไม่รู้ด้วยซ้ำว่าตัวเองกำลังใช้ SBC อยู่ Lineage 18.1 ไม่แสดง checkbox นั้นใน UI แม้จะเชื่อมต่ออุปกรณ์ที่รองรับ SBC มหัศจรรย์จริง ๆ -