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

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

ผู้ชม

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

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

ภาพรวมของ USB

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

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

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

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

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

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

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

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

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

โฮสต์เริ่มการโอนข้อมูลทั้งหมด ดังนั้นคำว่า input และ output จะแสดงสัมพันธ์กับโฮสต์ การดำเนินการอินพุตจะโอนข้อมูลจากอุปกรณ์ต่อพ่วงไปยังโฮสต์ ขณะที่การดำเนินการเอาต์พุตจะโอนข้อมูลจากโฮสต์ไปยังอุปกรณ์ต่อพ่วง

โหมดการโอนข้อมูลมี 3 โหมดหลักๆ ดังนี้ ขัดจังหวะ เป็นกลุ่ม และแบ่งเป็นช่วงๆ เราจะอธิบายเพิ่มเติมเกี่ยวกับโหมดแยกเดี่ยวในบริบทของเสียง

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

โหมด USB ของ Android

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

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

โหมดโฮสต์

โหมดโฮสต์เปิดตัวใน Android 3.1 (API ระดับ 12)

เนื่องจากอุปกรณ์ Android ต้องทำหน้าที่เป็นโฮสต์ และอุปกรณ์ Android ส่วนใหญ่ประกอบด้วย ขั้วต่อไมโคร 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

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

การเปรียบเทียบกับชั้นเรียนอื่นๆ

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

ขั้วปลายสายไฟ

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

ช่อง

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

โหมดการโอน Isochronous

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

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

ในโหมดนี้จะมีโหมดย่อยอยู่ 3 โหมด ได้แก่

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

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

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

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

ตารางด้านล่างจะสรุปโหมดย่อยที่เป็นทรงกลม

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

ในทางปฏิบัติ โหมดย่อยมีผลอย่างมาก แต่ปัจจัยอื่นๆ ที่ควรคำนึงถึงเช่นกัน

Android รองรับ USB Audio Class

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

โหมดนักพัฒนาซอฟต์แวร์ไม่รองรับเสียง USB

โหมดโฮสต์

Android 5.0 (API ระดับ 21) ขึ้นไปรองรับชุดย่อยของฟีเจอร์ USB Audio Class 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 จะไม่แสดงสถานะ "ไม่มีไดรเวอร์" ให้กับโฮสต์
• ทิศทางต้องเป็น input ซึ่งแสดงสัมพันธ์กับโฮสต์
• รูปแบบเสียงต้องเป็น PCM แบบ 16 บิต
• อัตราการสุ่มตัวอย่างต้องเป็น 44.1 kHz
• จำนวนช่องต้องเป็น 2 (สเตอริโอ)

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

แอปพลิเคชันสำหรับเสียงดิจิทัลแบบ USB

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

เรื่องเล่าของ DAC 2 คน

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ใช้ USB Audio

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

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

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

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

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

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

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

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

device/oem/codename/audio_policy.conf

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

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

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
      }
    }
  }
  ...
}

ซอร์สโค้ด

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

hardware/libhardware/modules/usbaudio/

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

ทดสอบเสียง USB

ดูข้อมูลเกี่ยวกับการทดสอบ CTS สำหรับเสียง USB ได้ที่ USB Audio CTS Verifier Tests