USB Digital Audio

บทความนี้กล่าวถึงการสนับสนุน 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 ที่เรียกว่า โหมดอุปกรณ์เสริม

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

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

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

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

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

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

มีโหมดการถ่ายโอนข้อมูลหลักสามโหมด: ขัดจังหวะ กลุ่ม และ 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 ) เช่นนี้มักจะจำเป็น:

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

โหมดการถ่ายโอนแบบไอโซโครนัส

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

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

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

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

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

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

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

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

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

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

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

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

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

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

เรื่องราวของสอง DACs

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

การเปรียบเทียบ 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 และ "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
      }
    }
  }
  ...
}

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

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

hardware/libhardware/modules/usbaudio/

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

กำลังทดสอบเสียง USB

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