การปรับโครงสร้าง SCO ที่มีการจัดการเสียง

หน้านี้อธิบายวิธีเปิดใช้เฟรมเวิร์กเสียงและ AHAL (Audio HAL) เพื่อจัดการการเชื่อมต่อแบบซิงโครนัสที่มุ่งเน้นการเชื่อมต่อ (SCO) ซึ่งเป็นกระบวนการที่ระบุว่าเป็น AMSCO (Audio Managed SCO)

ใน Android 17 ขึ้นไป เฟรมเวิร์กเสียงของ Android จะใช้ฟีเจอร์การจัดการ SCO เพื่อจัดการการกำหนดเส้นทาง SCO ซึ่งเดิมทีจัดการโดยเฟรมเวิร์กบลูทูธ (BT) การย้ายข้อมูลนี้จะย้ายสถานะการเชื่อมต่อ SCO จากสถานะที่เป็นของเฟรมเวิร์ก BT ไปเป็นผลลัพธ์ปลายทางของกิจกรรมการสตรีมเสียง

ฟีเจอร์นี้จะรวมการเป็นเจ้าของเส้นทางการกำหนดเส้นทางเสียงไว้ในเฟรมเวิร์กเสียง ซึ่งจะปรับการใช้งานระดับชั้นการจัดการฮาร์ดแวร์โดยตรง (HAL) สำหรับ SCO ให้สอดคล้องกับโปรไฟล์ BT อื่นๆ เช่น โปรไฟล์การกระจายเสียงขั้นสูง (A2DP) และ LE Audio การปรับโครงสร้างนี้จะทำให้การโต้ตอบระหว่างสแต็กโทรคมนาคมและ BT ง่ายขึ้น ซึ่งจะช่วยให้สถาปัตยกรรมการกำหนดเส้นทางเสียงมีความแข็งแกร่งและรวมศูนย์มากขึ้น

ภาพรวมสถาปัตยกรรม

สถาปัตยกรรม AMSCO จะรวมการจัดการการเชื่อมต่อ SCO ไว้ในเฟรมเวิร์กเสียงของ Android ซึ่งจะอิงตามกิจกรรมการสตรีมเสียงในการตัดสินใจกำหนดเส้นทาง สถาปัตยกรรมนี้แตกต่างจากโมเดลก่อนหน้าซึ่งสแต็ก BT เป็นผู้จัดการการเชื่อมต่อ บทบาทของคอมโพเนนต์แต่ละรายการในสถาปัตยกรรมนี้มีดังนี้

AHAL จะเริ่มและระงับเซสชัน SCO ก็ต่อเมื่อเป็นไปตามเงื่อนไขต่อไปนี้

• มีการแพตช์สตรีมที่ใช้งานอยู่ไปยังอุปกรณ์ SCO
• มีการตั้งค่าโหมดเสียงและมีการแพตช์ไปยังอุปกรณ์ SCO

เฟรมเวิร์กเสียงจะป้องกันไม่ให้อุปกรณ์ A2DP มีการแพตช์พร้อมกันเมื่อเป็นไปตามเกณฑ์ที่เฉพาะเจาะจงเหล่านี้ เฟรมเวิร์กเสียงจะไม่ส่งการเปลี่ยนแปลงสถานะ SCO หรือการระงับ A2DP ไปยัง AHAL อีกต่อไป

เฟรมเวิร์กเสียงจะจัดการ SCO ดังนั้นสแต็ก BT จึงไม่เรียกใช้การเชื่อมต่อหรือยกเลิกการเชื่อมต่อเสียงอีกต่อไป ในกรณีที่ยกเลิกการเชื่อมต่อ SCO หรือเกิดข้อผิดพลาดล่วงหน้า สแต็ก BT จะแจ้งให้เฟรมเวิร์กเสียงทราบด้วย AudioManager#onHfpAudioDisconnected

วางแผน

ใช้ข้อมูลในส่วนนี้เพื่อประเมินข้อกำหนดด้านความเข้ากันได้และสถาปัตยกรรมต่อไปนี้ก่อนที่จะใช้การปรับโครงสร้างการจัดการ SCO

ความเข้ากันได้แบบย้อนหลัง

หากต้องการให้เฟรมเวิร์กยังคงรองรับอุปกรณ์ที่อาจได้รับการอัปเดตระบบปฏิบัติการโดยไม่ต้องอัปเดต AHAL หรือ BT AHAL ให้ใช้พร็อพเพอร์ตี้ของระบบเพื่อระบุว่าต้องเปิดใช้การจัดการ SCO ใหม่ ระบบจะเก็บเส้นทางเดิมไว้เป็นเวลาสูงสุด 6 ปีในกรณีที่ปิดใช้พร็อพเพอร์ตี้ของระบบหรือ HAL เวอร์ชันล้าสมัย

ตั้งค่าเซสชัน HFP

AHAL ต้องใช้ประเภทเซสชันโปรไฟล์แฮนด์ฟรี (HFP) ใหม่เพื่อเริ่มหรือระงับการเล่น ซึ่งคล้ายกับประเภทเซสชัน BT อื่นๆ ระบบจะจัดการสถานะสตรีมโดยใช้ IBluetoothAudioProviders ที่แตกต่างกัน ซึ่งคลาส Factory จะแจงนับและสร้างขึ้นโดยขึ้นอยู่กับเส้นทางที่มี

สแต็ก BT จะใช้เส้นทางการออฟโหลดฮาร์ดแวร์ทุกครั้งที่ทำได้ การกำหนดค่าตัวแปลงสัญญาณระหว่างการเจรจาจะเป็นไปตามลำดับต่อไปนี้ ฮาร์ดแวร์ LC3 มีความสำคัญมากกว่าซอฟต์แวร์ LC3 ตามด้วยฮาร์ดแวร์ mSBC จากนั้นซอฟต์แวร์ mSBC และสุดท้ายฮาร์ดแวร์ CVSD มีความสำคัญมากกว่าซอฟต์แวร์ CVSD

แผนภาพลำดับต่อไปนี้แสดงรายละเอียดการโต้ตอบระหว่าง AHAL และสแต็ก BT ที่จำเป็นต่อการสร้างสถานะสตรีม

ขั้นตอนการออฟโหลดฮาร์ดแวร์

รูปที่ 1 แสดงวิธีที่ AHAL และสแต็ก BT ประสานงานกันเพื่อสร้างเส้นทางข้อมูลฮาร์ดแวร์โดยตรงสำหรับเสียง SCO

รูปที่ 1 ขั้นตอนการออฟโหลดฮาร์ดแวร์

ขั้นตอนเส้นทางข้อมูลซอฟต์แวร์

รูปที่ 2 แสดงกระบวนการจัดการข้อมูลเสียงที่ต้องมีการประมวลผลซอฟต์แวร์ระบบ

รูปที่ 2 ขั้นตอนเส้นทางข้อมูลซอฟต์แวร์

ขั้นตอนการเจรจาตัวแปลงสัญญาณใหม่

เมื่อเกตเวย์เสียง (AG) ได้รับคำสั่งตัวแปลงสัญญาณ BT ที่พร้อมใช้งานใหม่ (AT+BAC) เกตเวย์เสียงจะรีสตาร์ทขั้นตอนการเจรจาตัวแปลงสัญญาณใหม่ รูปที่ 3 แสดงขั้นตอนการเจรจาตัวแปลงสัญญาณใหม่

รูปที่ 3 ขั้นตอนการเจรจาตัวแปลงสัญญาณใหม่

ผลกระทบต่อ HeadsetStateMachine

เครื่องสถานะชุดหูฟังเลเยอร์ Java (แสดงโดยคลาส HeadsetStateMachine) จะยังคงไม่เปลี่ยนแปลงมากนัก ยกเว้นสถานะ AUDIO_CONNECTED ซึ่งขับเคลื่อนโดยเหตุการณ์สแต็กเนทีฟ ภายในเลเยอร์ Java ระบบจะไม่เริ่ม connectAudioNative หรือ disconnectAudioNative อีกต่อไป แต่ระบบจะตอบสนองต่อการเปลี่ยนแปลงสถานะการเชื่อมต่อเสียงจากสแต็กเนทีฟ การเปลี่ยนแปลงเหล่านี้จะทริกเกอร์โดยคำสั่งของ AHAL ใน IBluetoothAudioProvider หรือ IBluetoothAudioPort

การใช้งาน

หากต้องการผสานรวมการปรับโครงสร้างการจัดการ SCO ให้อัปเดตการสื่อสารระหว่างสแต็ก BT กับเฟรมเวิร์กเสียง

ทำตามขั้นตอนต่อไปนี้เพื่อใช้ฟีเจอร์

1. แจ้งให้เฟรมเวิร์กเสียงทราบเกี่ยวกับการเปลี่ยนแปลง BT ที่ใช้งานอยู่เพื่อช่วยในการจัดการการเริ่มต้นและการยกเลิก SCO อย่างเหมาะสมระหว่างการเชื่อมต่ออุปกรณ์ HFP และเพื่อจัดการการเปลี่ยนแปลงอุปกรณ์ที่ใช้งานอยู่ ใช้ AudioManager.handleBluetoothActiveDeviceChanged(HfpInfo) เพื่อให้ข้อมูลนี้แก่เฟรมเวิร์กเสียง

   

   รูปที่ 4 เชื่อมต่ออุปกรณ์ HFP

   เฟรมเวิร์กเสียงจะใช้การเรียกกลับ AudioManagerAudioDeviceCallback#onAudioDevicesAdded แทนการออกอากาศเดิมเพื่อระบุสถานะอุปกรณ์เสียง

2. ใช้การควบคุมสตรีม AHAL โดยใช้ setCommunicationDevice(AudioDeviceInfodevice) เป็นจุดควบคุมหลักเพื่อเริ่มการเชื่อมต่อ SCO

   หาก HfpTransport::StartRequest แสดงผล BluetoothAudioCtrlAck::PENDING AHAL ต้องลองคำขออีกครั้งเนื่องจากไม่ได้สร้างเครื่องสถานะ HFP

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

ส่วนต่อไปนี้แสดงเส้นทางของผู้ใช้ที่สำคัญ (CUJ) ทั่วไป

โฟลว์การโทรคมนาคม

การปรับโครงสร้างการจัดการ SCO จะเปลี่ยน phoneStateChanged เป็นฟังก์ชันการบล็อก การแก้ไขนี้ทำให้โทรคมนาคมรอให้การดำเนินการ phoneStateChanged ภายในเมธอด BluetoothInCallService.onCallAdded() เสร็จสมบูรณ์ก่อนที่จะเรียกใช้ API เฟรมเวิร์กเสียงเพื่อเริ่มการสร้าง SCO

รูปที่ 5 รับหรือเริ่มการโทรผ่านโทรคมนาคม

โฟลว์การโทร VOIP

เฟรมเวิร์กเสียงจะเริ่มกระบวนการโดยการเรียกใช้เมธอด BluetoothHeadset.startScoUsingVirtualVoiceCall หลังจากที่สแต็ก BT แสดงผลลัพธ์ไปยังเฟรมเวิร์กเสียงแล้ว เฟรมเวิร์กจะสั่งให้ AHAL ดำเนินการ startStream รูปต่อไปนี้แสดงโฟลว์นี้

รูปที่ 6 รับหรือเริ่มการโทรผ่าน VOIP

การจดจำเสียงพูด

สำหรับการจดจำเสียงพูดที่เริ่มโดย HF (แฮนด์ฟรี) และ AG ทั้งคู่ สแต็ก BT ต้องขอให้เฟรมเวิร์กเสียงเปิด SCO โดยใช้ AudioManager.setCommunicationDevice() ซึ่งแสดงไว้ในรูปต่อไปนี้

รูปที่ 7 การเริ่มต้น SCO การจดจำเสียงพูด

การเชื่อมต่อเสียง

สแต็ก BT จะเริ่มการเชื่อมต่อ SCO โดยขอเฟรมเวิร์กเสียงด้วย AudioManager.setCommunicationDevice(AudioDeviceInfo)ระหว่างการจดจำ เสียงพูด หากมีการโทรที่ใช้งานอยู่ สแต็ก BT จะขอ BluetoothInCallService#requestBluetoothAudio จากสแต็กโทรคมนาคมแทน

กระบวนการนี้แสดงไว้ในรูปต่อไปนี้

รูปที่ 8 การเชื่อมต่อเสียง

การตรวจสอบและการทดสอบ

หากต้องการตรวจสอบว่ามีการผสานรวมฟีเจอร์อย่างถูกต้องและเป็นไปตามมาตรฐานคุณภาพ ผู้ผลิตอุปกรณ์ต้องทำการทดสอบต่อไปนี้

• CTS Verifier: ใช้ CTS Verifier เพื่อทดสอบการกำหนดเส้นทางเสียงแบบอินเทอร์แอกทีฟระหว่างการโทร
• Vendor Test Suite (VTS): ตรวจสอบการโต้ตอบ AHAL และ BT AHAL โดยใช้ VTS

ข้อกำหนด

ฟีเจอร์นี้เป็นไปตามข้อกำหนดต่อไปนี้

• AHAL: การใช้งานต้องใช้ AHAL ที่เข้ากันได้ซึ่งรองรับเส้นทางการจัดการ SCO ที่ปรับโครงสร้างแล้ว