เสียงดิจิทัลแบบ USB

บทความนี้จะกล่าวถึงการรองรับเสียงดิจิทัลผ่าน USB ของ Android และโปรโตคอลที่เกี่ยวข้องกับ USB

ผู้ชม

กลุ่มเป้าหมายของบทความนี้คือ OEM ของอุปกรณ์ Android, ผู้ให้บริการ SoC, ผู้ให้บริการอุปกรณ์ต่อพ่วงเสียง USB, นักพัฒนาแอปพลิเคชันเสียงขั้นสูง และคนอื่นๆ ที่ต้องการทำความเข้าใจรายละเอียดเกี่ยวกับส่วนภายในของเสียงดิจิทัล USB ใน Android

ผู้ใช้ปลายทางของอุปกรณ์ Nexus ควรดูบทความบันทึกและเล่นเสียงโดยใช้โหมดโฮสต์ USB ที่ศูนย์ช่วยเหลือของ Nexus แทน แม้ว่าบทความนี้จะไม่มุ่งเน้นที่ผู้ใช้ปลายทาง แต่ผู้บริโภคที่ชื่นชอบเสียงอาจสนใจข้อมูลบางส่วน

ภาพรวมของ USB

Universal Serial Bus (USB) ได้รับการอธิบายอย่างไม่เป็นทางการในบทความ USB ของ Wikipedia และได้รับการกำหนดอย่างเป็นทางการโดยมาตรฐานที่เผยแพร่โดย USB Implementers Forum, Inc เราสรุปแนวคิดหลักของ USB ไว้ที่นี่เพื่อความสะดวก แต่มาตรฐานคือข้อมูลอ้างอิงที่เชื่อถือได้

แนวคิดและคำศัพท์พื้นฐาน

USB เป็นบัสที่มีผู้เริ่มดำเนินการโอนข้อมูลเพียงรายเดียว ซึ่งเรียกว่าโฮสต์ โฮสต์สื่อสารกับอุปกรณ์ต่อพ่วงผ่านบัส

หมายเหตุ: คําว่าอุปกรณ์และอุปกรณ์เสริมเป็นคําที่มีความหมายเหมือนกันสําหรับอุปกรณ์ต่อพ่วง เราจึงหลีกเลี่ยงการใช้คำดังกล่าว เนื่องจากอาจทำให้สับสนกับอุปกรณ์ Android หรือแนวคิดเฉพาะของ Android ที่เรียกกันว่าโหมดอุปกรณ์เสริม

บทบาทที่สำคัญของโฮสต์คือการแจกแจง ซึ่งเป็นกระบวนการตรวจหาอุปกรณ์ต่อพ่วงที่เชื่อมต่อกับบัส และการค้นหาพร็อพเพอร์ตี้ที่แสดงผ่านตัวระบุ

อุปกรณ์ต่อพ่วงอาจเป็นวัตถุจริง 1 รายการ แต่ใช้ฟังก์ชันเชิงตรรกะหลายรายการ เช่น อุปกรณ์ต่อพ่วงเว็บแคมอาจมีทั้งฟังก์ชันกล้องและฟังก์ชันเสียงของไมโครโฟน

ฟังก์ชันต่อพ่วงแต่ละรายการมีอินเทอร์เฟซที่กําหนดโปรโตคอลเพื่อสื่อสารกับฟังก์ชันนั้น

โฮสต์สื่อสารกับอุปกรณ์ต่อพ่วงผ่านไปป์ไปยังปลายทาง ซึ่งเป็นแหล่งข้อมูลหรือที่เก็บข้อมูลที่ได้จากฟังก์ชันของอุปกรณ์ต่อพ่วง

ซึ่งไพป์มี 2 ประเภท ได้แก่ message และ stream ไปป์ข้อความใช้สำหรับการควบคุมและสถานะแบบ 2 ทิศทาง ท่อสตรีมใช้สำหรับการโอนข้อมูลแบบทิศทางเดียว

โฮสต์จะเป็นผู้เริ่มการโอนข้อมูลทั้งหมด ดังนั้นคําว่าอินพุตและเอาต์พุตจึงแสดงตามโฮสต์ การดำเนินการอินพุตจะโอนข้อมูลจากอุปกรณ์ต่อพ่วงไปยังโฮสต์ ส่วนการดำเนินการเอาต์พุตจะโอนข้อมูลจากโฮสต์ไปยังอุปกรณ์ต่อพ่วง

โหมดการโอนข้อมูลหลักๆ มี 3 โหมด ได้แก่ การหยุดชะงัก การโอนจำนวนมาก และแบบไอโซโครนัส เราจะพูดถึงโหมด Isochronous เพิ่มเติมในบริบทของเสียง

อุปกรณ์ต่อพ่วงอาจมีขั้วต่อที่เชื่อมต่อกับโลกภายนอกนอกเหนือจากตัวอุปกรณ์ต่อพ่วงเอง วิธีนี้ช่วยให้อุปกรณ์ต่อพ่วงทำหน้าที่เป็นตัวแปลระหว่างโปรโตคอล USB กับสัญญาณ "ในชีวิตจริง" ขั้วต่อคือออบเจ็กต์ตรรกะของฟังก์ชัน

โหมด USB ของ Android

โหมดนักพัฒนาซอฟต์แวร์

โหมดการพัฒนามีมาตั้งแต่รุ่นแรกของ Android อุปกรณ์ Android จะปรากฏเป็นอุปกรณ์ต่อพ่วง USB ต่อ PC โฮสต์ที่ใช้ระบบปฏิบัติการเดสก์ท็อป เช่น Linux, Mac OS X หรือ Windows ฟังก์ชันต่อพ่วงที่มองเห็นได้เพียงอย่างเดียวคือ Android Fastboot หรือ Android Debug Bridge (adb) โปรโตคอล fastboot และ adb จะวางซ้อนกันเหนือโหมดการโอนข้อมูลจำนวนมากผ่าน USB

โหมดโฮสต์

โหมดโฮสต์มีให้ใช้งานใน Android 3.1 (API ระดับ 12)

เนื่องจากอุปกรณ์ Android ต้องทำหน้าที่เป็นโฮสต์ และอุปกรณ์ Android ส่วนใหญ่มีหัวต่อ micro-USB ที่ไม่อนุญาตให้ดำเนินการกับโฮสต์โดยตรง คุณจึงต้องใช้อะแดปเตอร์สำหรับเดินทาง (OTG) ดังตัวอย่างต่อไปนี้

รูปที่ 1 อะแดปเตอร์เดินทาง (OTG)

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

รูปที่ 2 ฮับที่มีไฟเข้า

โหมดอุปกรณ์เสริม

โหมดอุปกรณ์เสริมเปิดตัวใน Android 3.1 (API ระดับ 12) และพอร์ตไปยังเวอร์ชันเก่าใน Android 2.3.4 ในโหมดนี้ อุปกรณ์ Android จะทํางานเป็นอุปกรณ์ต่อพ่วง USB ภายใต้การควบคุมของอุปกรณ์อื่น เช่น แท่นชาร์จที่ทำหน้าที่เป็นโฮสต์ ความแตกต่างระหว่างโหมดการพัฒนากับโหมดอุปกรณ์เสริมคือโฮสต์จะเห็นฟังก์ชัน USB เพิ่มเติมนอกเหนือจาก adb อุปกรณ์ Android จะเริ่มในโหมดการพัฒนา จากนั้นจะเปลี่ยนไปใช้โหมดอุปกรณ์เสริมผ่านกระบวนการเจรจาต่อรองอีกครั้ง

โหมดอุปกรณ์เสริมได้รับการขยายการให้บริการด้วยฟีเจอร์เพิ่มเติมใน Android 4.1 โดยเฉพาะเสียงตามที่อธิบายไว้ด้านล่าง

เสียง USB

คลาส USB

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

คําว่าไม่ต้องใช้ไดรฟ์เป็นคําที่ตรงกันกับคําว่าเป็นไปตามข้อกําหนดของคลาส ซึ่งบ่งบอกว่าสามารถใช้ฟีเจอร์มาตรฐานของอุปกรณ์ต่อพ่วงดังกล่าวได้โดยไม่ต้องติดตั้งไดรฟ์เฉพาะระบบปฏิบัติการ เราสามารถสันนิษฐานได้ว่าอุปกรณ์ต่อพ่วงที่โฆษณาว่า "ไม่ต้องใช้ไดรเวอร์" สำหรับระบบปฏิบัติการเดสก์ท็อปหลักๆ จะเป็นไปตามข้อกำหนดของคลาส แม้ว่าอาจมีข้อยกเว้นก็ตาม

คลาสเสียง USB

ในส่วนนี้ เราจะพิจารณาเฉพาะอุปกรณ์ต่อพ่วงที่ใช้ฟังก์ชันเสียง และเป็นไปตามคลาสอุปกรณ์เสียง ข้อกำหนดคลาสเสียง USB มี 2 รุ่น ได้แก่ คลาส 1 (UAC1) และ 2 (UAC2)

การเปรียบเทียบกับคลาสอื่นๆ

USB ประกอบด้วยคลาสอุปกรณ์อื่นๆ อีกมากมาย ซึ่งบางคลาสอาจทำให้สับสนกับคลาสเสียง คลาสพื้นที่เก็บข้อมูลขนาดใหญ่ (MSC) ใช้สำหรับการเข้าถึงสื่อตามภาคส่วน ส่วนMedia Transfer Protocol (MTP) ใช้สำหรับการเข้าถึงไฟล์สื่ออย่างเต็มรูปแบบ คุณใช้ทั้ง MSC และ MTP เพื่อโอนไฟล์เสียงได้ แต่เฉพาะคลาสเสียง USB เท่านั้นที่เหมาะสำหรับสตรีมมิงแบบเรียลไทม์

ขั้วต่อเสียง

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

ช่อง

อุปกรณ์ต่อพ่วงที่มีฟังก์ชันเสียงอาจมีขั้วต่อแหล่งที่มา ขั้วต่อสัญญาณขาออก หรือทั้ง 2 อย่าง โดยแต่ละทิศทางอาจมี 1 ช่อง (โมโน), 2 ช่อง (สเตอริโอ) หรือมากกว่านั้น อุปกรณ์ต่อพ่วงที่มีมากกว่า 2 ช่องเรียกว่าหลายช่อง โดยทั่วไปแล้ว ผู้คนจะตีความสตรีมสเตอริโอว่าประกอบด้วยช่องซ้ายและขวา และขยายความว่าสตรีมหลายช่องมีตำแหน่งเชิงพื้นที่ที่สอดคล้องกับแต่ละช่อง อย่างไรก็ตาม การกำหนดความหมายเชิงพื้นที่มาตรฐานที่เฉพาะเจาะจงให้กับแต่ละช่องก็ค่อนข้างเหมาะสมเช่นกัน (โดยเฉพาะสำหรับเสียงผ่าน USB มากกว่าHDMI) ในกรณีนี้ แอปพลิเคชันและผู้ใช้จะเป็นผู้กำหนดวิธีใช้แต่ละแชแนล ตัวอย่างเช่น สตรีมอินพุต USB 4 แชนแนลอาจมีแชแนลแรก 3 ช่องที่เชื่อมต่อกับไมโครโฟนต่างๆ ภายในห้อง และแชแนลสุดท้ายที่รับอินพุตจากวิทยุ AM

โหมดการโอนแบบ Isochronous

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

การส่งแบบไอโซโครนัสจะเกิดขึ้นในแต่ละระยะเวลาเริ่มต้นของเฟรม (SOF) ระยะเวลา SOF คือ 1 มิลลิวินาทีสำหรับความเร็วเต็มรูปแบบ และ 125 ไมโครวินาทีสำหรับความเร็วสูง เฟรมความเร็วเต็มแต่ละเฟรมจะรับข้อมูลได้สูงสุด 1023 ไบต์ และเฟรมความเร็วสูงจะรับข้อมูลได้สูงสุด 1024 ไบต์ เมื่อนำข้อมูลเหล่านี้มารวมกัน เราจะคำนวณอัตราการโอนสูงสุดเป็น 1,023,000 หรือ 8,192,000 ไบต์ต่อวินาที ซึ่งจะเป็นการกำหนดขีดจำกัดบนตามทฤษฎีสำหรับอัตราการสุ่มตัวอย่าง ช่อง และบิตเชิงลึกของเสียงที่รวมกัน ขีดจํากัดที่ใช้งานได้จริงจะต่ำกว่า

โหมด Isochronous มีโหมดย่อย 3 โหมด ได้แก่

• ปรับอัตโนมัติ
• อะซิงโครนัส
• แบบซิงโครนัส

ในโหมดย่อยแบบปรับได้ ตัวรับหรือแหล่งที่มาของอุปกรณ์ต่อพ่วงจะปรับตามอัตราการสุ่มตัวอย่างของโฮสต์ที่อาจแตกต่างกัน

ในโหมดย่อยแบบไม่พร้อมกัน (หรือที่เรียกว่าการตอบกลับโดยนัย) ข้อมูลขาออกหรือแหล่งที่มาจะกําหนดอัตราการสุ่มตัวอย่าง และโฮสต์จะรองรับ ข้อดีหลักในทางทฤษฎีของโหมดย่อยแบบไม่พร้อมกันคือนาฬิกา USB ของแหล่งที่มาหรือตัวรับสัญญาณอยู่ใกล้กับนาฬิกาที่ขับเคลื่อน DAC หรือ ADC มากกว่าทั้งทางกายภาพและทางไฟฟ้า (และอาจเหมือนกันหรือมาจากนาฬิกาดังกล่าว) ความใกล้เคียงนี้หมายความว่าโหมดย่อยแบบไม่ประสานเวลาควรมีแนวโน้มที่จะได้รับผลกระทบจากความผันผวนของนาฬิกาน้อยลง นอกจากนี้ นาฬิกาที่ DAC หรือ ADC ใช้อาจออกแบบมาให้มีความแม่นยำสูงกว่าและมีความคลาดเคลื่อนต่ำกว่านาฬิกาของโฮสต์

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

ตารางด้านล่างแสดงสรุปโหมดย่อยแบบไอโซโครนาส

โหมดย่อย	จํานวนไบต์ ต่อแพ็กเกต	อัตราการสุ่มตัวอย่าง กำหนดโดย	ใช้สำหรับเสียง
ปรับ	เปลี่ยนแปลงได้	โฮสต์	ใช่
แบบอะซิงโครนัส	เปลี่ยนแปลงได้	อุปกรณ์ต่อพ่วง	ใช่
แบบซิงโครนัส	แก้ไขแล้ว	นาฬิกา USB	ไม่

ในทางปฏิบัติแล้ว โหมดย่อยก็มีความสำคัญ แต่คุณควรพิจารณาปัจจัยอื่นๆ ด้วย

การรองรับคลาสเสียง USB ของ Android

โหมดนักพัฒนาซอฟต์แวร์

โหมดการพัฒนาไม่รองรับเสียงผ่าน USB

โหมดโฮสต์

Android 5.0 (API ระดับ 21) ขึ้นไปรองรับฟีเจอร์ชุดย่อยของเสียง USB คลาส 1 (UAC1) ดังนี้

• อุปกรณ์ Android ต้องทำหน้าที่เป็นโฮสต์
• รูปแบบเสียงต้องเป็น PCM (อินเทอร์เฟซประเภท I)
• ความลึกของบิตต้องเป็น 16 บิต, 24 บิต หรือ 32 บิต โดยที่ข้อมูลเสียงที่มีประโยชน์ 24 บิตจะได้รับการกําหนดค่าให้อยู่ทางด้านซ้ายภายในบิตสําคัญที่สุดของคำ 32 บิต
• อัตราการสุ่มตัวอย่างต้องเป็น 48, 44.1, 32, 24, 22.05, 16, 12, 11.025 หรือ 8 kHz
• จำนวนช่องต้องเป็น 1 (โมโน) หรือ 2 (สเตอริโอ)

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

โหมดอุปกรณ์เสริม

Android 4.1 (API ระดับ 16) เพิ่มการรองรับการเล่นเสียงแบบจำกัดให้กับโฮสต์ ขณะที่อยู่ในโหมดอุปกรณ์เสริม Android จะกำหนดเส้นทางเอาต์พุตเสียงไปยัง USB โดยอัตโนมัติ กล่าวคือ อุปกรณ์ Android ทำหน้าที่เป็นแหล่งข้อมูลของโฮสต์ เช่น แท่นชาร์จ

เสียงในโหมดอุปกรณ์เสริมมีฟีเจอร์ต่อไปนี้

• อุปกรณ์ Android ต้องควบคุมโดยโฮสต์ที่มีความรู้ซึ่งสามารถเปลี่ยนอุปกรณ์ Android จากโหมดการพัฒนาเป็นโหมดอุปกรณ์เสริมได้ จากนั้นโฮสต์ต้องโอนข้อมูลเสียงจากอุปกรณ์ปลายทางที่เหมาะสม ดังนั้นอุปกรณ์ Android จึงไม่ได้ปรากฏเป็น "ไม่มีไดรเวอร์" แก่โฮสต์
• ทิศทางต้องเป็นอินพุตที่แสดงตามสัมพันธ์กับโฮสต์
• รูปแบบเสียงต้องเป็น PCM 16 บิต
• อัตราการสุ่มตัวอย่างต้องเป็น 44.1 kHz
• จำนวนช่องต้องเป็น 2 (สเตอริโอ)

เสียงในโหมดอุปกรณ์เสริมยังไม่ได้รับความนิยมอย่างแพร่หลาย และปัจจุบันเราไม่แนะนำให้ใช้กับการออกแบบใหม่

การใช้งานเสียงดิจิทัลผ่าน USB

ตามชื่อที่ระบุไว้ สัญญาณเสียงดิจิทัลของ USB จะแสดงด้วยสตรีมข้อมูลดิจิทัล ไม่ใช่สัญญาณอนาล็อกที่ใช้โดยขั้วต่อหูฟัง mini TRS ทั่วไป ท้ายที่สุดแล้ว สัญญาณดิจิทัลจะต้องแปลงเป็นสัญญาณอนาล็อกก่อนจึงจะได้ยินเสียง การเลือกตําแหน่งที่จะวาง Conversion นั้นมีข้อดีข้อเสีย

เปรียบเทียบ DAC 2 ตัว

ในแผนภาพตัวอย่างด้านล่าง เราจะเปรียบเทียบการออกแบบ 2 แบบ ก่อนอื่นเรามีอุปกรณ์เคลื่อนที่ที่มี Application Processor (AP), DAC ในตัว, เครื่องขยายเสียง และขั้วต่อ TRS แบบอนาล็อกที่ต่ออยู่กับหูฟัง นอกจากนี้ เรายังพิจารณาอุปกรณ์เคลื่อนที่ที่มี USB เชื่อมต่อกับ DAC และเครื่องขยายเสียง USB ภายนอก รวมถึงหูฟังด้วย

รูปที่ 3 การเปรียบเทียบ DAC 2 ตัว

การออกแบบใดดีกว่ากัน คำตอบนั้นขึ้นอยู่กับความต้องการของคุณ โดยแต่ละวิธีก็มีทั้งข้อดีและข้อเสีย

หมายเหตุ: การเปรียบเทียบนี้เป็นการเปรียบเทียบสมมติ เนื่องจากอุปกรณ์ Android จริงอาจมีทั้ง 2 ตัวเลือกนี้

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

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

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

ในทางกลับกัน การออกแบบที่ 2 มีความซับซ้อนกว่า และเมื่อมีความซับซ้อนมากขึ้น ก็มีโอกาสที่จะเกิดความผิดพลาดมากขึ้นด้วย นอกจากนี้ ยังมีเวลาในการตอบสนองเพิ่มเติมจากตัวควบคุม USB ด้วย

แอปพลิเคชันโหมดโฮสต์

แอปพลิเคชันเสียงโหมดโฮสต์ USB ทั่วไป ได้แก่

• การฟังเพลง
• โทรศัพท์
• การรับส่งข้อความโต้ตอบแบบทันทีและแชทด้วยเสียง
• กำลังบันทึก

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

ไม่มี API สำหรับเสียงดิจิทัลผ่าน USB โดยเฉพาะ สำหรับการใช้งานขั้นสูง การกำหนดเส้นทางอัตโนมัติอาจรบกวนแอปพลิเคชันที่รองรับ USB สําหรับแอปพลิเคชันดังกล่าว ให้ปิดใช้การกำหนดเส้นทางอัตโนมัติผ่านการควบคุมที่เกี่ยวข้องในส่วนสื่อของการตั้งค่า / ตัวเลือกสําหรับนักพัฒนาซอฟต์แวร์

แก้ไขข้อบกพร่องขณะอยู่ในโหมดโฮสต์

ขณะอยู่ในโหมดโฮสต์ USB การแก้ไขข้อบกพร่อง adb ผ่าน USB จะใช้งานไม่ได้ ดูวิธีอื่นได้ที่ส่วนการใช้งานแบบไร้สายของ Android Debug Bridge

ใช้เสียงผ่าน USB

คําแนะนําสําหรับผู้ให้บริการอุปกรณ์ต่อพ่วงเสียง

ผู้ให้บริการอุปกรณ์ต่อพ่วงด้านเสียงควรดำเนินการต่อไปนี้เพื่อให้อุปกรณ์ทำงานร่วมกันกับอุปกรณ์ Android ได้

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

คําแนะนําสําหรับ OEM ของอุปกรณ์ Android และผู้ขาย SoC

OEM ของอุปกรณ์และผู้ให้บริการ SoC ควรดำเนินการต่อไปนี้เพื่อรองรับเสียงดิจิทัลผ่าน USB

• ออกแบบฮาร์ดแวร์ให้รองรับโหมดโฮสต์ USB
• เปิดใช้การรองรับโฮสต์ USB ทั่วไปที่ระดับเฟรมเวิร์กผ่านฟีเจอร์ Flag android.hardware.usb.host.xml
• เปิดใช้ฟีเจอร์เคอร์เนลทั้งหมดที่จำเป็น ได้แก่ โหมดโฮสต์ USB, เสียง USB, โหมดการโอนแบบไอโซโครนาส
• อัปเดตเคอร์เนลและแพตช์ล่าสุดอยู่เสมอ แม้ว่าเป้าหมายอันสูงส่งของการปฏิบัติตามข้อกำหนดของคลาสจะมีอุปกรณ์ต่อพ่วงเสียงที่มีอยู่ซึ่งทำงานผิดปกติ แต่เคอร์เนลล่าสุดก็มีวิธีแก้ปัญหาการทำงานผิดปกติดังกล่าว
• เปิดใช้นโยบายเสียงผ่าน USB ตามที่อธิบายไว้ด้านล่าง
• เพิ่ม audio.usb.default ไปยัง PRODUCT_PACKAGES ใน device.mk
• ทดสอบความสามารถในการทำงานร่วมกันกับอุปกรณ์ต่อพ่วงเสียง USB ทั่วไป

เปิดใช้นโยบายเสียงผ่าน USB

หากต้องการเปิดใช้เสียงผ่าน USB ให้เพิ่มรายการลงในไฟล์การกำหนดค่านโยบายเสียง โดยปกติแล้วจะอยู่ที่นี่

device/oem/codename/audio_policy.conf

คุณควรแทนที่คอมโพเนนต์เส้นทาง "oem" ด้วยชื่อ OEM ที่ผลิตอุปกรณ์ Android และแทนที่ "codename" ด้วยชื่อรหัสของอุปกรณ์

ตัวอย่างรายการแสดงอยู่ที่นี่

audio_hw_modules {
  ...
  usb {
    outputs {
      usb_accessory {
        sampling_rates 44100
        channel_masks AUDIO_CHANNEL_OUT_STEREO
        formats AUDIO_FORMAT_PCM_16_BIT
        devices AUDIO_DEVICE_OUT_USB_ACCESSORY
      }
      usb_device {
        sampling_rates dynamic
        channel_masks dynamic
        formats dynamic
        devices AUDIO_DEVICE_OUT_USB_DEVICE
      }
    }
    inputs {
      usb_device {
        sampling_rates dynamic
        channel_masks AUDIO_CHANNEL_IN_STEREO
        formats AUDIO_FORMAT_PCM_16_BIT
        devices AUDIO_DEVICE_IN_USB_DEVICE
      }
    }
  }
  ...
}

ซอร์สโค้ด

การใช้งานระดับชั้นการจัดการฮาร์ดแวร์โดยตรง (HAL) ของเสียงสำหรับ USB อยู่ที่นี่

hardware/libhardware/modules/usbaudio/

HAL เสียง USB อาศัย tinyalsa เป็นอย่างมาก ซึ่งอธิบายไว้ในคำศัพท์เกี่ยวกับเสียง แม้ว่าเสียง USB จะอาศัยการโอนแบบไอโซโครน แต่การใช้งาน ALSA จะแยกการดำเนินการนี้ออก ดังนั้น HAL เสียง USB และ tinyalsa จึงไม่ต้องกังวลเกี่ยวกับโปรโตคอล USB ในส่วนนี้

ทดสอบเสียงผ่าน USB

ดูข้อมูลเกี่ยวกับการทดสอบ CTS สำหรับเสียงผ่าน USB ได้ที่การทดสอบโปรแกรมตรวจสอบ CTS ของเสียงผ่าน USB