เสียงบลูทูธพลังงานต่ำ

เสียงบลูทูธพลังงานต่ำ (LEA) ช่วยให้ผู้ใช้ได้รับเสียงคุณภาพสูงโดยไม่เสียอายุการใช้งานแบตเตอรี่ และช่วยให้ผู้ใช้สลับระหว่างกรณีการใช้งานต่างๆ ได้อย่างราบรื่น Android 13 (API ระดับ 33) รองรับ LEA ในตัว

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

กรณีการใช้งาน

คุณอาจต้องผสานรวม LEA สำหรับกรณีการใช้งานต่อไปนี้

  • การแชร์เสียง: ผู้ใช้สามารถแชร์สตรีมเสียงหลายรายการไปยังอุปกรณ์ส่งออกเสียงอย่างน้อย 1 เครื่องพร้อมกัน ระบบจะซิงค์เสียงระหว่างอุปกรณ์ต้นทางกับอุปกรณ์ที่เชื่อมต่อ

  • ออกอากาศเสียง: ผู้ใช้สามารถออกอากาศเสียงให้เพื่อนๆ และครอบครัวฟังได้ พร้อมทั้งเชื่อมต่อกับการออกอากาศสาธารณะเพื่อรับข้อมูล ความบันเทิง หรือเพื่อเข้าถึงได้

  • การรองรับตัวแปลงสัญญาณเสียง LC3: นี่คือตัวแปลงสัญญาณเสียงเริ่มต้นและแทนที่ตัวแปลงรหัส SBC ที่ใช้สำหรับ A2DP (สื่อ) และ mSBC ใน HFP (เสียง) LC3 มีประสิทธิภาพมากกว่า กำหนดค่าใหม่ได้ และคุณภาพสูงกว่า

  • การปรับปรุงการสุ่มตัวอย่างเสียง: ชุดหูฟังจะคงคุณภาพเสียงเอาต์พุตให้สูงได้เมื่อใช้ไมโครโฟน บลูทูธคลาสสิกจะลดคุณภาพเสียงเมื่อใช้ไมโครโฟนบลูทูธ เมื่อใช้ BLE Audio การสุ่มตัวอย่างอินพุตและเอาต์พุตจะสูงถึง 32 kHz

  • ไมโครโฟนสเตอริโอ: ผู้ที่ได้ยินสามารถบันทึกเสียงด้วยไมโครโฟนสเตอริโอเพื่อเพิ่มประสิทธิภาพเสียงรอบทิศทาง

  • การรองรับ Hearing Aid Profile (HAP): HAP ช่วยให้ผู้ใช้เข้าถึงและใช้งานได้มากกว่าโปรโตคอล ASHA เวอร์ชันเก่า ผู้ใช้สามารถใช้เครื่องช่วยฟังสำหรับการโทรและแอปพลิเคชัน VoIP

  • การรองรับ Enhanced Attribute Protocol (EATT): EATT ช่วยให้นักพัฒนาแอปส่งคำสั่งหลายรายการพร้อมกันไปยังอุปกรณ์หูฟังที่จับคู่ไว้ได้

สถานการณ์สําคัญ

Use Case หลักๆ มี 4 หมวดหมู่ ได้แก่

  1. แบบสนทนา: แอปพลิเคชันแป้นโทรศัพท์และ VoIP ที่ต้องกำหนดเส้นทางการสื่อสารที่มีเวลาในการตอบสนองต่ำจะให้เสียงคุณภาพสูงและใช้แบตเตอรี่น้อยลง

  2. การเล่นเกม: การใช้ไมโครโฟนพร้อมกันและการเล่นที่มีความแม่นยำสูงช่วยให้เกมสตรีมเสียงคุณภาพสูงเพื่อให้ได้ยิน แอปเล่นเกมจะเข้าถึงอินพุตเสียง BLE ได้เมื่อเกมเตรียมไมโครโฟนบลูทูธให้พร้อมใช้งาน จากนั้นเมื่อผู้เล่นเริ่มการสนทนาสดกับผู้เล่นคนอื่นๆ แอปเกมจะใช้ข้อมูลไมโครโฟนได้โดยไม่ล่าช้า

  3. สื่อ: แอปพลิเคชันสื่อได้รับอนุญาตให้ตั้งค่าอุปกรณ์ที่ต้องการของเครื่องมือจัดการเสียง ผู้ใช้สามารถลบล้างการตั้งค่านี้ได้โดยเปลี่ยนอุปกรณ์ที่ต้องการจากภายในการตั้งค่าของระบบ

  4. การช่วยเหลือพิเศษ: ตอนนี้เครื่องช่วยฟังที่รองรับเสียง BLE สามารถใช้ไมโครโฟนได้แล้ว ซึ่งช่วยให้ผู้ใช้ใช้เครื่องช่วยฟังในการโทรได้อย่างต่อเนื่อง

เมธอดและ API ของ BLE Audio

ต้องมี API และวิธีการต่อไปนี้เพื่อรองรับการฟัง BLE Audio

AudioManager

  • setCommunicationDevice() เลือกอุปกรณ์เสียงที่ควรใช้สำหรับกรณีการใช้งานด้านการสื่อสารสำหรับ การโทรด้วยเสียงหรือวิดีโอคอล วิธีการนี้สามารถใช้โดยแอปพลิเคชันการแชทด้วยเสียงหรือวิดีโอแชทเพื่อเลือกอุปกรณ์เสียงอื่นที่ไม่ใช่อุปกรณ์ที่แพลตฟอร์มเลือกไว้โดยค่าเริ่มต้น API นี้จะแทนที่ API ที่เลิกใช้งานแล้วต่อไปนี้ startBluetoothSco(), stopBluetoothSco() และ setSpeakerphoneOn()
  • clearCommunicationDevice() จะเรียกใช้หลังจากที่แอปของคุณทำการโทรหรือเซสชันเสร็จสิ้นแล้ว เพื่อช่วยดูแลให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ยอดเยี่ยมเมื่อย้ายไปมาระหว่างแอปพลิเคชันต่างๆ

BluetoothProfile

  • BluetoothLeAudio ควบคุมบริการบลูทูธผ่านออบเจ็กต์พร็อกซี

Telecom InCallService

  • InCallService#requestCallEndpointChange() จะใช้แทน API InCallService.setAudioRoute() และ InCallService.requestBluetoothAudio() ที่เลิกใช้งานแล้ว เพื่ออนุญาตให้แอปส่งคําขอการกำหนดเส้นทางเสียงไปยัง CallEndpoint ที่เฉพาะเจาะจง ลูกค้าไม่ควรกำหนด CallEndpoint ของตนเองเมื่อส่งคำขอเปลี่ยนแปลง แต่ควรเป็นปลายทางใหม่ที่เป็นหนึ่งในปลายทางที่ถูกต้องซึ่ง InCallService.onAvailableCallEndpointsChanged(java.util.List) ระบุ
  • CallEndpoint.TYPE_BLUETOOTH ส่งสตรีมเสียงผ่านบลูทูธ
  • InCallService API ที่กล่าวถึงข้างต้นได้รับการออกแบบมาเพื่อให้แอปโทรศัพท์เริ่มต้นในโทรศัพท์ Android หรือแพลตฟอร์มการโทรอื่นๆ เช่น อุปกรณ์ที่สวมใส่ได้ รถยนต์ หรืออุปกรณ์บลูทูธอื่นๆ ใช้ ซึ่งอาจต้องการกำหนดเส้นทางเสียง

Telecom CallControl

  • คลาส CallControl ใหม่จะเปิดตัวใน API ระดับ 34 เพื่อแทนที่ Connection และ ConnectionService สำหรับแอปพลิเคชัน VoIP เท่านั้น
  • CallControl.requestCallEndpointChange() ขอเปลี่ยนแปลง CallEndpoint ด้วย API นี้จะมาแทนที่ API Connection.requestBluetoothAudio() และ Connection.setAudioRoute() ที่เลิกใช้งานแล้ว
  • นอกจาก Telecom Platform API ที่อัปเดตแล้ว เราขอแนะนำอย่างยิ่งให้ใช้ไลบรารี Telecom Jetpack เมื่อสร้างแอปพลิเคชันการโทรด้วยเสียงและ/หรือวิดีโอคอล ไลบรารีนี้ช่วยลดความซับซ้อนของกระบวนการผสานรวมและปรับปรุงการโทรผ่าน VoIP ในทุกแพลตฟอร์มของ Android ได้อย่างมีประสิทธิภาพ

ข้อมูลอุปกรณ์เสียง

  • AudioDeviceInfo.TYPE_BLE_HEADSET อธิบายประเภทอุปกรณ์เสียงว่าเป็นอุปกรณ์ LEA ใช้สำหรับระบุว่าอุปกรณ์แบบได้ยินเสียงเป็นอุปกรณ์ LEA หรือไม่

เครื่องบันทึกเสียง

  • setPreferredDevice() ตั้งค่าอุปกรณ์ที่ต้องการใช้กำหนดเส้นทางเสียง ผู้ใช้สามารถลบล้างการตั้งค่านี้ได้ในการตั้งค่าระบบ

อะแดปเตอร์บลูทูธ

  • isLeAudioSupported() จะแสดงผลหากฮาร์ดแวร์ของแพลตฟอร์มรองรับ LEA
  • isLeAudioBroadcastSourceSupported() จะแสดงผลหากฮาร์ดแวร์ของแพลตฟอร์มรองรับ LEA

คำแนะนำตามกรณีการใช้งาน

ด้านล่างนี้คือหลักเกณฑ์ในการใช้งาน LEA ตามกรณีการใช้งานที่เฉพาะเจาะจง

แอปพลิเคชันการสื่อสารด้วยเสียง

แอปพลิเคชันการสื่อสารด้วยเสียงจะมีตัวเลือกในการจัดการการกำหนดเส้นทางเสียงและสถานะของอุปกรณ์โดยการจัดการสถานะของแอปด้วยตนเอง หรือใช้ Telecom API ซึ่งจะจัดการการกำหนดเส้นทางเสียงและตรรกะสถานะให้คุณ

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

แอปพลิเคชันการบันทึกเสียง

  • โปรแกรมบันทึกสื่อ: เมื่อบันทึกเสียงโดยใช้โปรแกรมบันทึกสื่อ ตอนนี้คุณจะอัดเสียงได้ในสเตอริโอหากบลูทูธที่ได้ยินรองรับ LEA ดูคำแนะนำในการบันทึกเสียง

คำแนะนำเกี่ยวกับชุดหูฟัง LE Audio (LEA)

เมื่อมีการเปิดตัวชุดหูฟัง LEA มากขึ้น เราพบปัญหาในการทดสอบการใช้งานจริงที่ส่งผลเสียต่อประสบการณ์ของผู้ใช้ ข้อกำหนดเฉพาะนี้ไม่ได้ครอบคลุมปัญหาเหล่านี้ทั้งหมด ตารางต่อไปนี้แสดงรายการคำแนะนำที่ผู้ผลิตหูฟัง LEA ควรปฏิบัติตามเพื่อปรับปรุงประสบการณ์การใช้งานแบบครบวงจรสำหรับผู้ใช้ Android

คำอธิบาย บริบท
รองรับการสร้างคีย์ข้ามการขนส่ง (CTKD) สำหรับหูฟังแบบ 2 โหมด ดังนี้
  • รองรับการสร้างคีย์สําหรับทั้งการจับคู่แบบคลาสสิกกับ LE และการจับคู่แบบ LE กับคลาสสิก
 หูฟัง LEA ใหม่ส่วนใหญ่จะเป็นแบบ 2 โหมดจนกว่าอุปกรณ์แหล่งที่มาของ LEA จะมีส่วนแบ่งการตลาดเพิ่มขึ้น สิ่งสำคัญคือผู้ใช้ต้องจับคู่ชุดหูฟัง 2 โหมดได้อย่างราบรื่นและตั้งค่าการส่งทั้ง 2 แบบ ซึ่งก็สำคัญกับการจับคู่ด่วนของ Google ด้วย

รองรับประกาศที่กำหนดเป้าหมาย (TA) หากต้องการให้ชุดหูฟัง LEA เชื่อมต่อกับอุปกรณ์ต้นทางอีกครั้งได้อย่างน่าเชื่อถือ

หูฟังเอียร์บัด LE Audio ควรใช้ TA เพื่อขอการเชื่อมต่อขาเข้าจากอุปกรณ์ส่วนกลาง

จะเพิ่มลงใน BT SIG ที่กำลังจะมาถึง

 ซึ่งแตกต่างจากรูปแบบการเรียกของ BR/EDR ที่โทรศัพท์หรือหูฟังสามารถเริ่มการเชื่อมต่อได้ แต่การเชื่อมต่อใน LEA จะต้องเริ่มโดยอุปกรณ์ส่วนกลาง ปัจจุบันหูฟังหลายรุ่นไม่ได้ใช้ TA ซึ่งหมายความว่าอุปกรณ์ส่วนกลางอาจเชื่อมต่อกับอุปกรณ์ต่อพ่วงอีกครั้งไม่ได้หากไม่เพิ่มอุปกรณ์ต่อพ่วงนั้นลงในรายการที่อนุญาต อย่างไรก็ตาม วิธีแก้ปัญหาเฉพาะหน้าของรายการที่อนุญาตอาจทำให้ชุดหูฟังเชื่อมต่อกับอุปกรณ์กลางเครื่องอื่นไม่ได้ ดังนั้นชุดหูฟัง LEA จึงควรรองรับ TA อย่างเหมาะสมเพื่อให้อุปกรณ์ส่วนกลางเชื่อมต่ออีกครั้งได้อย่างเสถียรโดยไม่มีวิธีแก้ปัญหาเฉพาะหน้าซึ่งอาจทำให้การเชื่อมต่อหลายจุดขัดข้อง
เพิ่มการค้นพบหูฟังเอียร์บัดแบบ 2 โหมด
  • หูฟังเอียร์บัดหลัก - คอมโพเนนต์ BR/EDR ควรโฆษณาโดยใช้ที่อยู่สาธารณะ รวมถึงเปิดใช้การสอบถามและการสแกนหน้าด้วยชื่อที่พร้อมใช้งานผ่าน EIR และตั้งค่า LE Audio บิต 14 เป็น 1 ใน Major Service Class of Class of Device (CoD)
  • หูฟังเอียร์บัดหลัก - คอมโพเนนต์ LE: หูฟังเอียร์บัดหลัก ควรใช้โฆษณาที่เชื่อมต่อได้และค้นพบได้ (แบบจำกัดหรือทั่วไป) โดยใช้ที่อยู่สาธารณะเดียวกันกับคอมโพเนนต์ BR/EDR และใช้ชื่อท้องถิ่นแบบเต็มเดียวกันกับคอมโพเนนต์ BR/EDR โดยมีการกำหนดหมวดหมู่ลักษณะที่ปรากฏเป็นหมวดหมู่ลักษณะที่ปรากฏที่เหมาะสม ซึ่งตรงกับประเภทอุปกรณ์ระยะไกลที่มีการคาดการณ์ว่านโยบาย UI และเสียงของอุปกรณ์หลักจะใช้ข้อมูลนี้ในการปรับ
  • หูฟังเอียร์บัดรอง - LE เท่านั้น: หูฟังเอียร์บัดรองควรทำการโฆษณาแบบเชื่อมต่อได้และไม่สามารถค้นพบได้ โดยตั้งค่าหมวดหมู่ลักษณะที่ปรากฏเป็นหมวดหมู่ลักษณะที่ปรากฏที่เหมาะสมซึ่งตรงกับประเภทอุปกรณ์ระยะไกล โดยคาดหวังว่าอุปกรณ์ส่วนกลางจะใช้ข้อมูลนี้เพื่อปรับ UI และนโยบายการกำหนดเส้นทางเสียง

    หูฟังเอียร์บัดควรเลือกผู้นำจากกลุ่ม CSIP เป็นอุปกรณ์หลักแบบไดนามิก หากหูฟังเอียร์บัดเป็นแบบ 2 โหมด อุปกรณ์หลักต้องเป็นแบบ 2 โหมดเพื่อให้ฟังก์ชันการทำงานทั้ง LE และ Classic ทำงานได้อย่างถูกต้องหลังจากการจับคู่

 ซึ่งจะช่วยป้องกันไม่ให้หูฟังเอียร์บัด LEA แบบ 2 โหมดปรากฏเป็นรายการที่ซ้ำกันในการตั้งค่าบลูทูธ ซึ่งอาจทำให้ผู้ใช้สับสนและส่งผลเสียต่อประสบการณ์การจับคู่ LEA

การเลือกผู้นำแบบไดนามิกมีความสำคัญอย่างยิ่งสำหรับอุปกรณ์แบบ 2 โหมดที่จับคู่เพิ่ม เช่น หากมีเพียงหูฟังเอียร์บัดเดียวที่พร้อมใช้งานในการจับคู่ครั้งแรก หูฟังเอียร์บัดควรแสดงเป็นอุปกรณ์แบบ 2 โหมด เมื่อผู้ใช้จับคู่กับหูฟังเอียร์บัดตัวที่ 2 ในภายหลัง ผู้ใช้จะต้องจับคู่กับคอมโพเนนต์ LE เท่านั้น และ CSIP จะตรวจสอบว่าหูฟังเอียร์บัดทั้งสองอยู่ในกลุ่มเดียวกันบน Android

เราขอแนะนำให้ใช้ที่อยู่ระบุตัวตนในระหว่างการจับคู่ เนื่องจากคอมโพเนนต์ BR/EDR จะแสดงที่อยู่สาธารณะของอุปกรณ์ต่ออุปกรณ์ที่อยู่ใกล้เคียงอยู่แล้ว
รองรับ Enhanced Attribute Protocol (EATT) ลดการจับคู่และเวลาในการตอบสนองของการเชื่อมต่อ
รองรับการแคช GATT ที่มีประสิทธิภาพ ลดเวลาในการตอบสนองของการเชื่อมต่อ โดยเฉพาะสำหรับหูฟัง TWS
รองรับการจัดประเภทย่อยการเชื่อมต่อ ช่วยให้กำหนดเวลาแพ็กเก็ตมีความยืดหยุ่นมากขึ้นและช่วยประหยัดแบตเตอรี่ที่เป็นไปได้
ตรวจสอบว่าในระหว่างการประมวลผลก่อนและหลังทั้งการเล่นและการบันทึก ไปป์ไลน์การประมวลผลสัญญาณสามารถทำงานที่ 16, 24, 32 และ 48 kHz รวมถึงรองรับความถี่ที่สูงขึ้น ใช้ประโยชน์จากอัตราการสุ่มตัวอย่างที่สูงขึ้นซึ่งรองรับเส้นทางการบันทึกการโทรหรือ VoIP ของ LEA และการเล่นสื่อ
รองรับการควบคุมพลังงาน LE การจัดการพลังงานที่ดีขึ้น

การรองรับประเภทบริบท

คำอธิบาย บริบท
ใช้บริบททุกประเภทที่ระบุไว้ในหมายเลขที่กำหนด 6.12.3 เว้นแต่หูฟังจะไม่รองรับบริบทประเภทหนึ่งๆ อย่างชัดแจ้ง เช่น หากระบบไม่รองรับบริบทประเภท "เกม" แล้ว Android จะส่งเสียงเกม โดยเฉพาะอย่างยิ่ง โปรดทราบว่าประเภทบริบท "ไม่ระบุ" ไม่ได้หมายถึง "ประเภทบริบทใดๆ" และไม่ครอบคลุมประเภทบริบทที่ไม่รองรับ

เมื่ออุปกรณ์ส่วนกลางโต้ตอบกับ ASCS ของอุปกรณ์ต่อพ่วง อุปกรณ์ต่อพ่วงต้องเชื่อมต่อกับ MCS และ TBS ของอุปกรณ์ส่วนกลาง

อุปกรณ์กลางอาจไม่ได้ใช้เสียง LE เป็นเส้นทางสตรีมมิงเสมอไป เนื่องจากอาจเปลี่ยนไปใช้ A2DP หรือ HFP อุปกรณ์ต่อพ่วงสามารถใช้การโต้ตอบ ASCS เพื่อบ่งชี้ว่าอุปกรณ์ส่วนกลางจะใช้เสียง LE สำหรับการสตรีมหรือไม่

ตัวอย่างการโต้ตอบ ASCS ได้แก่ การอ่าน การเขียน และการลงทะเบียนเพื่อรับการแจ้งเตือน