USB เสียงดิจิตอล

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

ผู้ชม

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

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

ภาพรวมของยูเอสบี

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

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

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

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

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

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

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

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

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

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

มีสามโหมดการถ่ายโอนข้อมูลหลัก: การขัดจังหวะ จำนวนมาก และ isochronous โหมด Isochronous จะกล่าวถึงต่อไปในบริบทของเสียง

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

โหมด Android USB

โหมดการพัฒนา

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

โหมดโฮสต์

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

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

รูปที่ 1. อะแดปเตอร์ On-the-go (OTG)

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

รูปที่ 2. ฮับจ่ายไฟ

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

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

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

เสียง USB

คลาส USB

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

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

คลาสเสียง USB

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

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

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

ขั้วเสียง

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

ช่องทาง

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

โหมดการถ่ายโอนข้อมูลแบบ Isochronous

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

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

ภายในโหมด isochronous มีสามโหมดย่อย:

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

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

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

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

ตารางด้านล่างสรุปโหมดย่อยแบบ isochronous:

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

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

โหมดการพัฒนา

ไม่รองรับเสียง 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 จึงไม่ปรากฏเป็น "driverless" ต่อโฮสต์
• ทิศทางจะต้อง ป้อน แสดงความสัมพันธ์กับโฮสต์
• รูปแบบเสียงต้องเป็น PCM 16 บิต
• อัตราตัวอย่างต้องเป็น 44.1 kHz
• จำนวนช่องต้องเป็น 2 (สเตอริโอ)

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

แอพพลิเคชั่นเสียงดิจิตอล USB

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

เรื่องราวของ DAC สองตัว

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

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

การออกแบบไหนดีกว่ากัน? คำตอบขึ้นอยู่กับความต้องการของคุณ แต่ละคนมีข้อดีและข้อเสีย

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

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

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

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

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

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

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

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

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

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

การดีบักขณะอยู่ในโหมดโฮสต์

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

การใช้เสียง USB

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

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

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

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

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

• ออกแบบฮาร์ดแวร์ให้รองรับโหมดโฮสต์ USB
• เปิดใช้งานการสนับสนุนโฮสต์ USB ทั่วไปที่ระดับเฟรมเวิร์กผ่านแฟล็กคุณลักษณะ android.hardware.usb.host.xml
• เปิดใช้งานคุณสมบัติเคอร์เนลทั้งหมดที่จำเป็น: โหมดโฮสต์ USB, เสียง USB, โหมดการถ่ายโอนแบบ isochronous; ดู การกำหนดค่าเคอร์เนลของ 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
      }
    }
  }
  ...
}

รหัสแหล่งที่มา

การใช้งาน Audio Hardware Abstraction Layer (HAL) สำหรับเสียง USB อยู่ที่นี่:

hardware/libhardware/modules/usbaudio/

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

ทดสอบเสียง USB

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