บทความนี้จะทบทวนการรองรับ 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 ที่เรียกว่า โหมดอุปกรณ์เสริม
บทบาทของโฮสต์ที่สำคัญคือ การแจงนับ : กระบวนการในการตรวจสอบว่าอุปกรณ์ต่อพ่วงใดเชื่อมต่อกับบัส และสอบถามคุณสมบัติที่แสดงผ่าน ตัวอธิบาย
อุปกรณ์ต่อพ่วงอาจเป็นวัตถุทางกายภาพชิ้นเดียว แต่จริงๆ แล้วใช้ฟังก์ชันลอจิคัลหลาย ฟังก์ชัน ตัวอย่างเช่น อุปกรณ์ต่อพ่วงเว็บแคมอาจมีทั้งฟังก์ชันกล้องและฟังก์ชันเสียงไมโครโฟน
ฟังก์ชันต่อพ่วงแต่ละฟังก์ชันมี อินเทอร์เฟซ ที่กำหนดโปรโตคอลเพื่อสื่อสารกับฟังก์ชันนั้น
โฮสต์สื่อสารกับอุปกรณ์ต่อพ่วงผ่าน ไปป์ ไปยัง จุดสิ้นสุด ซึ่งเป็นแหล่งข้อมูลหรือแหล่งรับที่มาจากฟังก์ชันใดฟังก์ชันหนึ่งของอุปกรณ์ต่อพ่วง
ไปป์มีสองประเภท: ข้อความ และ สตรีม ไปป์ข้อความใช้สำหรับการควบคุมและสถานะแบบสองทิศทาง สตรีมไปป์ใช้สำหรับการถ่ายโอนข้อมูลแบบทิศทางเดียว
โฮสต์เริ่มต้นการถ่ายโอนข้อมูลทั้งหมด ดังนั้นเงื่อนไข อินพุต และ เอาต์พุต จึงแสดงสัมพันธ์กับโฮสต์ การดำเนินการอินพุตจะถ่ายโอนข้อมูลจากอุปกรณ์ต่อพ่วงไปยังโฮสต์ ในขณะที่การดำเนินการเอาต์พุตจะถ่ายโอนข้อมูลจากโฮสต์ไปยังอุปกรณ์ต่อพ่วง
มีโหมดการถ่ายโอนข้อมูลหลักสามโหมด: Interrupt , Bulk และ Isochronous โหมด Isochronous จะมีการหารือเพิ่มเติมในบริบทของเสียง
อุปกรณ์ต่อพ่วงอาจมี ขั้วต่อ ที่เชื่อมต่อกับโลกภายนอก นอกเหนือจากอุปกรณ์ต่อพ่วงนั้นเอง ด้วยวิธีนี้ อุปกรณ์ต่อพ่วงจะทำหน้าที่แปลระหว่างโปรโตคอล USB และสัญญาณ "โลกแห่งความเป็นจริง" เทอร์มินัลเป็นอ็อบเจ็กต์ลอจิคัลของฟังก์ชัน
โหมด USB ของ Android
โหมดการพัฒนา
โหมดการพัฒนา มีมาตั้งแต่ 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 ที่ไม่อนุญาตให้โฮสต์ดำเนินการโดยตรง ดังนั้นโดยทั่วไปจำเป็นต้องใช้อะแดปเตอร์แบบพกพา ( OTG ) เช่นนี้:
![โอทีจี](https://source.android.google.cn/static/docs/core/audio/images/otg.jpg?authuser=2&hl=th)
รูปที่ 1 อะแดปเตอร์แบบพกพา (OTG)
อุปกรณ์ Android อาจจ่ายไฟไม่เพียงพอที่จะใช้งานอุปกรณ์ต่อพ่วงบางอย่าง ขึ้นอยู่กับปริมาณพลังงานที่อุปกรณ์ต่อพ่วงต้องการ และจำนวนอุปกรณ์ Android ที่สามารถจ่ายได้ แม้ว่าจะมีพลังงานเพียงพอ แต่การชาร์จแบตเตอรี่ของอุปกรณ์ Android อาจลดลงอย่างมาก สำหรับสถานการณ์เหล่านี้ ให้ใช้ ฮับ ที่จ่ายไฟดังนี้:
![ศูนย์กลางขับเคลื่อน](https://source.android.google.cn/static/docs/core/audio/images/hub.jpg?authuser=2&hl=th)
รูปภาพ 2 ดุมขับเคลื่อน
โหมดอุปกรณ์เสริม
โหมดอุปกรณ์เสริม เปิดตัวใน Android 3.1 (API ระดับ 12) และพอร์ตกลับเป็น Android 2.3.4 ในโหมดนี้ อุปกรณ์ Android จะทำงานเป็นอุปกรณ์ต่อพ่วง USB ภายใต้การควบคุมของอุปกรณ์อื่น เช่น แท่นที่ทำหน้าที่เป็นโฮสต์ ความแตกต่างระหว่างโหมดการพัฒนาและโหมดอุปกรณ์เสริมก็คือ โฮสต์จะมองเห็นฟังก์ชัน USB เพิ่มเติมได้ นอกเหนือจาก adb อุปกรณ์ Android เริ่มต้นในโหมดการพัฒนา จากนั้นจะเปลี่ยนเป็นโหมดอุปกรณ์เสริมผ่านกระบวนการเจรจาใหม่
โหมดอุปกรณ์เสริมได้รับการขยายด้วยคุณสมบัติเพิ่มเติมใน Android 4.1 โดยเฉพาะเสียงที่อธิบายไว้ด้านล่าง
เสียงยูเอสบี
คลาส USB
ฟังก์ชันต่อพ่วงแต่ละฟังก์ชันมีเอกสาร คลาสอุปกรณ์ ที่เกี่ยวข้องซึ่งระบุโปรโตคอลมาตรฐานสำหรับฟังก์ชันนั้น ซึ่งช่วยให้โฮสต์ ที่สอดคล้องกับคลาส และฟังก์ชันต่อพ่วงสามารถทำงานร่วมกันได้โดยไม่ต้องมีความรู้โดยละเอียดเกี่ยวกับการทำงานของกันและกัน การปฏิบัติตามข้อกำหนดของคลาสถือเป็นสิ่งสำคัญหากโฮสต์และอุปกรณ์ต่อพ่วงจัดทำโดยเอนทิตีที่แตกต่างกัน
คำว่า driverless เป็นคำพ้องความหมายทั่วไปสำหรับ class ตามมาตรฐาน ซึ่งบ่งชี้ว่าสามารถใช้คุณสมบัติมาตรฐานของอุปกรณ์ต่อพ่วงดังกล่าวได้โดยไม่ต้องติดตั้ง ไดรเวอร์ เฉพาะระบบปฏิบัติการ เราสามารถสรุปได้ว่าอุปกรณ์ต่อพ่วงที่โฆษณาว่า "ไม่จำเป็นต้องใช้ไดรเวอร์" สำหรับระบบปฏิบัติการเดสก์ท็อปหลักๆ จะเป็นไปตามมาตรฐานคลาส แม้ว่าอาจมีข้อยกเว้นก็ตาม
คลาสเสียง USB
ในที่นี้เราเกี่ยวข้องกับอุปกรณ์ต่อพ่วงที่ใช้ฟังก์ชันเสียงเท่านั้น และจึงยึดตามคลาสอุปกรณ์เสียง ข้อมูลจำเพาะคลาสเสียง USB มีสองรุ่น: คลาส 1 (UAC1) และ 2 (UAC2)
เปรียบเทียบกับคลาสอื่นๆ
USB มีคลาสอุปกรณ์อื่นๆ มากมาย ซึ่งบางคลาสอาจสับสนกับคลาสเสียง คลาสที่เก็บข้อมูลขนาดใหญ่ (MSC) ใช้สำหรับการเข้าถึงสื่อแบบเซกเตอร์ ในขณะที่ Media Transfer Protocol (MTP) ใช้สำหรับการเข้าถึงไฟล์แบบเต็มไปยังสื่อ อาจใช้ทั้ง MSC และ MTP ในการถ่ายโอนไฟล์เสียง แต่เฉพาะคลาสเสียง USB เท่านั้นที่เหมาะสำหรับการสตรีมแบบเรียลไทม์
ขั้วต่อสัญญาณเสียง
ขั้วต่อของอุปกรณ์ต่อพ่วงเสียงโดยทั่วไปจะเป็นแบบอะนาล็อก สัญญาณแอนะล็อกที่แสดงที่ช่องอินพุตของอุปกรณ์ต่อพ่วงจะถูกแปลงเป็นดิจิทัลโดย ตัวแปลงแอนะล็อกเป็นดิจิทัล (ADC) และถูกส่งผ่านโปรโตคอล USB ที่โฮสต์จะใช้งาน ADC เป็น แหล่ง ข้อมูลสำหรับโฮสต์ ในทำนองเดียวกัน โฮสต์จะส่งสัญญาณเสียงดิจิทัลผ่านโปรโตคอล USB ไปยังอุปกรณ์ต่อพ่วง โดยที่ ตัวแปลงดิจิทัลเป็นอนาล็อก (DAC) จะแปลงและนำเสนอไปยังเทอร์มินัลเอาต์พุตอะนาล็อก DAC เป็นเหมือน sink สำหรับโฮสต์
ช่อง
อุปกรณ์ต่อพ่วงที่มีฟังก์ชันเสียงอาจรวมถึงขั้วต่อต้นทาง ขั้วต่อ sink หรือทั้งสองอย่าง แต่ละทิศทางอาจมีหนึ่งช่องสัญญาณ ( โมโน ) สองช่อง ( สเตอริโอ ) หรือมากกว่า อุปกรณ์ต่อพ่วงที่มีมากกว่าสองช่องสัญญาณเรียกว่า หลายช่องสัญญาณ เป็นเรื่องปกติที่จะตีความสตรีมสเตอริโอว่าประกอบด้วยช่องสัญญาณ ซ้าย และ ขวา และโดยการขยายเพื่อตีความสตรีมแบบหลายช่องสัญญาณว่ามีตำแหน่งเชิงพื้นที่ที่สอดคล้องกับแต่ละช่องสัญญาณ อย่างไรก็ตาม มันก็ค่อนข้างเหมาะสม (โดยเฉพาะอย่างยิ่งสำหรับเสียง USB มากกว่า HDMI ) ที่จะไม่กำหนดความหมายเชิงพื้นที่มาตรฐานใด ๆ ให้กับแต่ละช่องสัญญาณ ในกรณีนี้ ขึ้นอยู่กับแอปพลิเคชันและผู้ใช้ในการกำหนดวิธีการใช้งานแต่ละช่อง ตัวอย่างเช่น สตรีมอินพุต USB สี่ช่องอาจมีสามช่องแรกต่ออยู่กับไมโครโฟนต่างๆ ภายในห้อง และช่องสุดท้ายรับอินพุตจากวิทยุ AM
โหมดการถ่ายโอนแบบไอโซโครนัส
เสียง USB ใช้โหมดการถ่ายโอนแบบไอโซโครนัสสำหรับคุณลักษณะแบบเรียลไทม์ โดยเสียค่าใช้จ่ายในการกู้คืนข้อผิดพลาด ในโหมดไอโซโครนัส รับประกันแบนด์วิดท์ และตรวจพบข้อผิดพลาดในการส่งข้อมูลโดยใช้การตรวจสอบซ้ำซ้อนแบบวน (CRC) แต่ไม่มีการรับทราบแพ็คเก็ตหรือการส่งซ้ำในกรณีที่เกิดข้อผิดพลาด
การส่งสัญญาณแบบ Isochronous เกิดขึ้นในแต่ละช่วง Start Of Frame (SOF) ช่วงเวลา SOF คือหนึ่งมิลลิวินาทีสำหรับความเร็วเต็ม และ 125 ไมโครวินาทีสำหรับความเร็วสูง เฟรมความเร็วเต็มแต่ละเฟรมรับน้ำหนักบรรทุกสูงสุด 1,023 ไบต์ และเฟรมความเร็วสูงแต่ละเฟรมรับน้ำหนักบรรทุกสูงสุด 1,024 ไบต์ เมื่อนำสิ่งเหล่านี้มารวมกัน เราจะคำนวณอัตราการถ่ายโอนสูงสุดเป็น 1,023,000 หรือ 8,192,000 ไบต์ต่อวินาที ซึ่งจะกำหนดขีดจำกัดบนตามทฤษฎีเกี่ยวกับอัตราตัวอย่างเสียง จำนวนช่อง และความลึกของบิตที่รวมกัน ขีดจำกัดในทางปฏิบัติต่ำกว่า
ภายในโหมด isochronous มีสามโหมดย่อย:
- ปรับตัว
- แบบอะซิงโครนัส
- ซิงโครนัส
ในโหมดย่อยแบบปรับเปลี่ยนได้ ซิงก์หรือแหล่งกำเนิดอุปกรณ์ต่อพ่วงจะปรับตามอัตราตัวอย่างของโฮสต์ที่อาจเปลี่ยนแปลงได้
ในโหมดย่อยแบบอะซิงโครนัส (หรือที่เรียกว่าผลตอบรับโดยนัย) ซิงก์หรือแหล่งที่มาจะกำหนดอัตราตัวอย่าง และโฮสต์รองรับ ข้อได้เปรียบทางทฤษฎีหลักของโหมดย่อยแบบอะซิงโครนัสคือนาฬิกา USB ต้นทางหรือซิงก์นั้นอยู่ใกล้ทั้งทางกายภาพและทางไฟฟ้า (และอาจเหมือนกันหรือได้มาจาก) นาฬิกาที่ขับเคลื่อน DAC หรือ ADC ความใกล้ชิดนี้หมายความว่าโหมดย่อยแบบอะซิงโครนัสควรไวต่อการกระวนกระวายใจของนาฬิกาน้อยลง นอกจากนี้ นาฬิกาที่ใช้โดย DAC หรือ ADC อาจได้รับการออกแบบให้มีความแม่นยำสูงกว่าและเบี่ยงเบนไปต่ำกว่านาฬิกาโฮสต์
ในโหมดย่อยแบบซิงโครนัส จำนวนไบต์คงที่จะถูกถ่ายโอนในแต่ละช่วง SOF อัตราตัวอย่างเสียงได้มาจากนาฬิกา 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 ทั่วไป ในที่สุดสัญญาณดิจิทัลใดๆ จะต้องถูกแปลงเป็นอนาล็อกก่อนจึงจะได้ยิน การเลือกตำแหน่งที่จะวาง Conversion นั้นมีข้อด้อย
เรื่องราวของ DAC สองตัว
ในแผนภาพตัวอย่างด้านล่าง เราจะเปรียบเทียบการออกแบบสองแบบ อันดับแรก เรามีอุปกรณ์เคลื่อนที่ที่มีตัวประมวลผลแอปพลิเคชัน (AP), DAC ออนบอร์ด, แอมพลิฟายเออร์ และตัวเชื่อมต่อ TRS แบบอะนาล็อกที่ต่ออยู่กับหูฟัง นอกจากนี้เรายังพิจารณาอุปกรณ์พกพาที่เชื่อมต่อ USB เข้ากับ USB DAC ภายนอกและแอมพลิฟายเออร์ รวมถึงหูฟังด้วย
![การเปรียบเทียบ DAC](https://source.android.google.cn/static/docs/core/audio/images/dac.png?authuser=2&hl=th)
รูปที่ 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, โหมดการถ่ายโอนแบบไอโซโครนัส; ดู การกำหนดค่าเคอร์เนล 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/
HAL เสียง USB อาศัย Tinyalsa อย่างมาก ดังอธิบายไว้ใน คำศัพท์เฉพาะทางเสียง แม้ว่าเสียง USB จะขึ้นอยู่กับการถ่ายโอนแบบ isochronous แต่การนำ ALSA ไปใช้ก็เป็นนามธรรม ดังนั้น HAL เสียง USB และ Tinyalsa จึงไม่จำเป็นต้องกังวลกับโปรโตคอล USB ส่วนนี้
ทดสอบเสียง USB
สำหรับข้อมูลเกี่ยวกับการทดสอบ CTS สำหรับเสียง USB โปรดดูที่ การทดสอบตัวตรวจสอบ CTS เสียง 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 ที่เรียกว่า โหมดอุปกรณ์เสริม
บทบาทของโฮสต์ที่สำคัญคือ การแจงนับ : กระบวนการในการตรวจสอบว่าอุปกรณ์ต่อพ่วงใดเชื่อมต่อกับบัส และสอบถามคุณสมบัติที่แสดงผ่าน ตัวอธิบาย
อุปกรณ์ต่อพ่วงอาจเป็นวัตถุทางกายภาพชิ้นเดียว แต่จริงๆ แล้วใช้ฟังก์ชันลอจิคัลหลาย ฟังก์ชัน ตัวอย่างเช่น อุปกรณ์ต่อพ่วงเว็บแคมอาจมีทั้งฟังก์ชันกล้องและฟังก์ชันเสียงไมโครโฟน
ฟังก์ชันต่อพ่วงแต่ละฟังก์ชันมี อินเทอร์เฟซ ที่กำหนดโปรโตคอลเพื่อสื่อสารกับฟังก์ชันนั้น
โฮสต์สื่อสารกับอุปกรณ์ต่อพ่วงผ่าน ไปป์ ไปยัง จุดสิ้นสุด ซึ่งเป็นแหล่งข้อมูลหรือแหล่งรับที่มาจากฟังก์ชันใดฟังก์ชันหนึ่งของอุปกรณ์ต่อพ่วง
ไปป์มีสองประเภท: ข้อความ และ สตรีม ไปป์ข้อความใช้สำหรับการควบคุมและสถานะแบบสองทิศทาง สตรีมไปป์ใช้สำหรับการถ่ายโอนข้อมูลแบบทิศทางเดียว
โฮสต์เริ่มต้นการถ่ายโอนข้อมูลทั้งหมด ดังนั้นเงื่อนไข อินพุต และ เอาต์พุต จึงแสดงสัมพันธ์กับโฮสต์ การดำเนินการอินพุตจะถ่ายโอนข้อมูลจากอุปกรณ์ต่อพ่วงไปยังโฮสต์ ในขณะที่การดำเนินการเอาต์พุตจะถ่ายโอนข้อมูลจากโฮสต์ไปยังอุปกรณ์ต่อพ่วง
มีโหมดการถ่ายโอนข้อมูลหลักสามโหมด: Interrupt , Bulk และ Isochronous โหมด Isochronous จะมีการหารือเพิ่มเติมในบริบทของเสียง
อุปกรณ์ต่อพ่วงอาจมี ขั้วต่อ ที่เชื่อมต่อกับโลกภายนอก นอกเหนือจากอุปกรณ์ต่อพ่วงนั้นเอง ด้วยวิธีนี้ อุปกรณ์ต่อพ่วงจะทำหน้าที่แปลระหว่างโปรโตคอล USB และสัญญาณ "โลกแห่งความเป็นจริง" เทอร์มินัลเป็นอ็อบเจ็กต์ลอจิคัลของฟังก์ชัน
โหมด USB ของ Android
โหมดการพัฒนา
โหมดการพัฒนา มีมาตั้งแต่ 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 ที่ไม่อนุญาตให้โฮสต์ดำเนินการโดยตรง ดังนั้นโดยทั่วไปจำเป็นต้องใช้อะแดปเตอร์แบบพกพา ( OTG ) เช่นนี้:
![โอทีจี](https://source.android.google.cn/static/docs/core/audio/images/otg.jpg?authuser=2&hl=th)
รูปที่ 1 อะแดปเตอร์แบบพกพา (OTG)
อุปกรณ์ Android อาจจ่ายไฟไม่เพียงพอที่จะใช้งานอุปกรณ์ต่อพ่วงบางอย่าง ขึ้นอยู่กับปริมาณพลังงานที่อุปกรณ์ต่อพ่วงต้องการ และจำนวนอุปกรณ์ Android ที่สามารถจ่ายได้ แม้ว่าจะมีพลังงานเพียงพอ แต่การชาร์จแบตเตอรี่ของอุปกรณ์ Android อาจลดลงอย่างมาก สำหรับสถานการณ์เหล่านี้ ให้ใช้ ฮับ ที่จ่ายไฟดังนี้:
![ศูนย์กลางขับเคลื่อน](https://source.android.google.cn/static/docs/core/audio/images/hub.jpg?authuser=2&hl=th)
รูปภาพ 2 ดุมขับเคลื่อน
โหมดอุปกรณ์เสริม
โหมดอุปกรณ์เสริม เปิดตัวใน Android 3.1 (API ระดับ 12) และพอร์ตกลับเป็น Android 2.3.4 ในโหมดนี้ อุปกรณ์ Android จะทำงานเป็นอุปกรณ์ต่อพ่วง USB ภายใต้การควบคุมของอุปกรณ์อื่น เช่น แท่นที่ทำหน้าที่เป็นโฮสต์ ความแตกต่างระหว่างโหมดการพัฒนาและโหมดอุปกรณ์เสริมก็คือ โฮสต์จะมองเห็นฟังก์ชัน USB เพิ่มเติมได้ นอกเหนือจาก adb อุปกรณ์ Android เริ่มต้นในโหมดการพัฒนา จากนั้นจะเปลี่ยนเป็นโหมดอุปกรณ์เสริมผ่านกระบวนการเจรจาใหม่
โหมดอุปกรณ์เสริมได้รับการขยายด้วยคุณสมบัติเพิ่มเติมใน Android 4.1 โดยเฉพาะเสียงที่อธิบายไว้ด้านล่าง
เสียงยูเอสบี
คลาส USB
ฟังก์ชันต่อพ่วงแต่ละฟังก์ชันมีเอกสาร คลาสอุปกรณ์ ที่เกี่ยวข้องซึ่งระบุโปรโตคอลมาตรฐานสำหรับฟังก์ชันนั้น ซึ่งช่วยให้โฮสต์ ที่สอดคล้องกับคลาส และฟังก์ชันต่อพ่วงสามารถทำงานร่วมกันได้โดยไม่ต้องมีความรู้โดยละเอียดเกี่ยวกับการทำงานของกันและกัน การปฏิบัติตามข้อกำหนดของคลาสถือเป็นสิ่งสำคัญหากโฮสต์และอุปกรณ์ต่อพ่วงจัดทำโดยเอนทิตีที่แตกต่างกัน
คำว่า driverless เป็นคำพ้องความหมายทั่วไปสำหรับ class ตามมาตรฐาน ซึ่งบ่งชี้ว่าสามารถใช้คุณสมบัติมาตรฐานของอุปกรณ์ต่อพ่วงดังกล่าวได้โดยไม่ต้องติดตั้ง ไดรเวอร์ เฉพาะระบบปฏิบัติการ เราสามารถสรุปได้ว่าอุปกรณ์ต่อพ่วงที่โฆษณาว่า "ไม่จำเป็นต้องใช้ไดรเวอร์" สำหรับระบบปฏิบัติการเดสก์ท็อปหลักๆ จะเป็นไปตามมาตรฐานคลาส แม้ว่าอาจมีข้อยกเว้นก็ตาม
คลาสเสียง USB
ในที่นี้เราเกี่ยวข้องกับอุปกรณ์ต่อพ่วงที่ใช้ฟังก์ชันเสียงเท่านั้น และจึงยึดตามคลาสอุปกรณ์เสียง ข้อมูลจำเพาะคลาสเสียง USB มีสองรุ่น: คลาส 1 (UAC1) และ 2 (UAC2)
เปรียบเทียบกับคลาสอื่นๆ
USB มีคลาสอุปกรณ์อื่นๆ มากมาย ซึ่งบางคลาสอาจสับสนกับคลาสเสียง คลาสที่เก็บข้อมูลขนาดใหญ่ (MSC) ใช้สำหรับการเข้าถึงสื่อแบบเซกเตอร์ ในขณะที่ Media Transfer Protocol (MTP) ใช้สำหรับการเข้าถึงไฟล์แบบเต็มไปยังสื่อ อาจใช้ทั้ง MSC และ MTP ในการถ่ายโอนไฟล์เสียง แต่เฉพาะคลาสเสียง USB เท่านั้นที่เหมาะสำหรับการสตรีมแบบเรียลไทม์
ขั้วต่อสัญญาณเสียง
ขั้วต่อของอุปกรณ์ต่อพ่วงเสียงโดยทั่วไปจะเป็นแบบอะนาล็อก สัญญาณแอนะล็อกที่แสดงที่ช่องอินพุตของอุปกรณ์ต่อพ่วงจะถูกแปลงเป็นดิจิทัลโดย ตัวแปลงแอนะล็อกเป็นดิจิทัล (ADC) และถูกส่งผ่านโปรโตคอล USB ที่โฮสต์จะใช้งาน ADC เป็น แหล่ง ข้อมูลสำหรับโฮสต์ ในทำนองเดียวกัน โฮสต์จะส่งสัญญาณเสียงดิจิทัลผ่านโปรโตคอล USB ไปยังอุปกรณ์ต่อพ่วง โดยที่ ตัวแปลงดิจิทัลเป็นอนาล็อก (DAC) จะแปลงและนำเสนอไปยังเทอร์มินัลเอาต์พุตอะนาล็อก DAC เป็นเหมือน sink สำหรับโฮสต์
ช่อง
อุปกรณ์ต่อพ่วงที่มีฟังก์ชันเสียงอาจรวมถึงขั้วต่อต้นทาง ขั้วต่อ sink หรือทั้งสองอย่าง แต่ละทิศทางอาจมีหนึ่งช่องสัญญาณ ( โมโน ) สองช่อง ( สเตอริโอ ) หรือมากกว่า อุปกรณ์ต่อพ่วงที่มีมากกว่าสองช่องสัญญาณเรียกว่า หลายช่องสัญญาณ เป็นเรื่องปกติที่จะตีความสตรีมสเตอริโอว่าประกอบด้วยช่องสัญญาณ ซ้าย และ ขวา และโดยการขยายเพื่อตีความสตรีมแบบหลายช่องสัญญาณว่ามีตำแหน่งเชิงพื้นที่ที่สอดคล้องกับแต่ละช่องสัญญาณ อย่างไรก็ตาม มันก็ค่อนข้างเหมาะสม (โดยเฉพาะอย่างยิ่งสำหรับเสียง USB มากกว่า HDMI ) ที่จะไม่กำหนดความหมายเชิงพื้นที่มาตรฐานใด ๆ ให้กับแต่ละช่องสัญญาณ ในกรณีนี้ ขึ้นอยู่กับแอปพลิเคชันและผู้ใช้ในการกำหนดวิธีการใช้งานแต่ละช่อง ตัวอย่างเช่น สตรีมอินพุต USB สี่ช่องอาจมีสามช่องแรกต่ออยู่กับไมโครโฟนต่างๆ ภายในห้อง และช่องสุดท้ายรับอินพุตจากวิทยุ AM
โหมดการถ่ายโอนแบบไอโซโครนัส
เสียง USB ใช้โหมดการถ่ายโอนแบบไอโซโครนัสสำหรับคุณลักษณะแบบเรียลไทม์ โดยเสียค่าใช้จ่ายในการกู้คืนข้อผิดพลาด ในโหมดไอโซโครนัส รับประกันแบนด์วิดท์ และตรวจพบข้อผิดพลาดในการส่งข้อมูลโดยใช้การตรวจสอบซ้ำซ้อนแบบวน (CRC) แต่ไม่มีการรับทราบแพ็คเก็ตหรือการส่งซ้ำในกรณีที่เกิดข้อผิดพลาด
การส่งสัญญาณแบบ Isochronous เกิดขึ้นในแต่ละช่วง Start Of Frame (SOF) ช่วงเวลา SOF คือหนึ่งมิลลิวินาทีสำหรับความเร็วเต็ม และ 125 ไมโครวินาทีสำหรับความเร็วสูง เฟรมความเร็วเต็มแต่ละเฟรมรับน้ำหนักบรรทุกสูงสุด 1,023 ไบต์ และเฟรมความเร็วสูงแต่ละเฟรมรับน้ำหนักบรรทุกสูงสุด 1,024 ไบต์ เมื่อนำสิ่งเหล่านี้มารวมกัน เราจะคำนวณอัตราการถ่ายโอนสูงสุดเป็น 1,023,000 หรือ 8,192,000 ไบต์ต่อวินาที ซึ่งจะกำหนดขีดจำกัดบนตามทฤษฎีเกี่ยวกับอัตราตัวอย่างเสียง จำนวนช่อง และความลึกของบิตที่รวมกัน ขีดจำกัดในทางปฏิบัติต่ำกว่า
ภายในโหมด isochronous มีสามโหมดย่อย:
- ปรับตัว
- แบบอะซิงโครนัส
- ซิงโครนัส
ในโหมดย่อยแบบปรับเปลี่ยนได้ ซิงก์หรือแหล่งกำเนิดอุปกรณ์ต่อพ่วงจะปรับตามอัตราตัวอย่างของโฮสต์ที่อาจเปลี่ยนแปลงได้
ในโหมดย่อยแบบอะซิงโครนัส (หรือที่เรียกว่าผลตอบรับโดยนัย) ซิงก์หรือแหล่งที่มาจะกำหนดอัตราตัวอย่าง และโฮสต์รองรับ ข้อได้เปรียบทางทฤษฎีหลักของโหมดย่อยแบบอะซิงโครนัสคือนาฬิกา USB ต้นทางหรือซิงก์นั้นอยู่ใกล้ทั้งทางกายภาพและทางไฟฟ้า (และอาจเหมือนกันหรือได้มาจาก) นาฬิกาที่ขับเคลื่อน DAC หรือ ADC ความใกล้ชิดนี้หมายความว่าโหมดย่อยแบบอะซิงโครนัสควรไวต่อการกระวนกระวายใจของนาฬิกาน้อยลง นอกจากนี้ นาฬิกาที่ใช้โดย DAC หรือ ADC อาจได้รับการออกแบบให้มีความแม่นยำสูงกว่าและเบี่ยงเบนไปต่ำกว่านาฬิกาโฮสต์
ในโหมดย่อยแบบซิงโครนัส จำนวนไบต์คงที่จะถูกถ่ายโอนในแต่ละช่วง SOF อัตราตัวอย่างเสียงได้มาจากนาฬิกา 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 ทั่วไป ในที่สุดสัญญาณดิจิทัลใดๆ จะต้องถูกแปลงเป็นอนาล็อกก่อนจึงจะได้ยิน การเลือกตำแหน่งที่จะวาง Conversion นั้นมีข้อด้อย
เรื่องราวของ DAC สองตัว
ในแผนภาพตัวอย่างด้านล่าง เราจะเปรียบเทียบการออกแบบสองแบบ อันดับแรก เรามีอุปกรณ์เคลื่อนที่ที่มีตัวประมวลผลแอปพลิเคชัน (AP), DAC ออนบอร์ด, แอมพลิฟายเออร์ และตัวเชื่อมต่อ TRS แบบอะนาล็อกที่ต่ออยู่กับหูฟัง นอกจากนี้เรายังพิจารณาอุปกรณ์พกพาที่เชื่อมต่อ USB เข้ากับ USB DAC ภายนอกและแอมพลิฟายเออร์ รวมถึงหูฟังด้วย
![การเปรียบเทียบ DAC](https://source.android.google.cn/static/docs/core/audio/images/dac.png?authuser=2&hl=th)
รูปที่ 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, โหมดการถ่ายโอนแบบไอโซโครนัส; ดู การกำหนดค่าเคอร์เนล 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 } } } ... }
รหัสแหล่งที่มา
การใช้งาน Layer Abstraction Abstraction (HAL) Audio Hardware สำหรับ USB Audio ตั้งอยู่ที่นี่:
hardware/libhardware/modules/usbaudio/
USB Audio Hal พึ่งพา Tinyalsa เป็นอย่างมากซึ่งอธิบายไว้ใน คำศัพท์ด้านเสียง แม้ว่า USB Audio อาศัยการถ่ายโอนแบบ isochronous แต่สิ่งนี้ถูกแยกออกจากการใช้งาน ALSA ดังนั้น USB Audio Hal และ Tinyalsa ไม่จำเป็นต้องกังวลกับตัวเองกับโปรโตคอล USB ในส่วนนี้
ทดสอบเสียง USB
สำหรับข้อมูลเกี่ยวกับการทดสอบ CTS สำหรับ USB Audio ให้ดู การทดสอบ Audio CTS Verifier ของ USB