صدای دیجیتال USB

این مقاله به بررسی پشتیبانی اندروید از صدای دیجیتال USB و پروتکل‌های مبتنی بر USB مربوطه می‌پردازد.

مخاطب

مخاطبین این مقاله OEM های دستگاه های اندرویدی، فروشندگان SoC، تامین کنندگان لوازم جانبی صوتی USB، توسعه دهندگان برنامه های صوتی پیشرفته و دیگرانی هستند که به دنبال درک دقیق داخلی های صوتی دیجیتال USB در اندروید هستند.

کاربران نهایی دستگاه‌های Nexus باید مقاله ضبط و پخش صدا را با استفاده از حالت میزبان USB در مرکز راهنمایی Nexus ببینند. اگرچه این مقاله برای کاربران نهایی طراحی نشده است، اما برخی از مصرف کنندگان موسیقی دوست ممکن است بخش های مورد علاقه خود را پیدا کنند.

نمای کلی USB

گذرگاه سریال جهانی (USB) به طور غیررسمی در مقاله ویکی‌پدیا USB توضیح داده شده است و به طور رسمی با استانداردهای منتشر شده توسط USB Implementers Forum, Inc تعریف شده است. برای راحتی، مفاهیم کلیدی USB را در اینجا خلاصه می کنیم، اما استانداردها مرجع معتبر هستند.

مفاهیم و اصطلاحات اساسی

USB یک گذرگاه با یک آغازگر عملیات انتقال داده است که میزبان نامیده می شود. میزبان از طریق اتوبوس با تجهیزات جانبی ارتباط برقرار می کند.

توجه: اصطلاحات دستگاه و لوازم جانبی مترادف رایج برای لوازم جانبی هستند. ما در اینجا از این اصطلاحات اجتناب می کنیم، زیرا ممکن است با دستگاه Android یا مفهوم خاص اندروید به نام حالت لوازم جانبی اشتباه گرفته شود.

یک نقش میزبان حیاتی، شمارش است: فرآیند تشخیص اینکه کدام دستگاه‌های جانبی به گذرگاه متصل هستند، و پرس‌وجو ویژگی‌های آن‌ها که از طریق توصیفگرها بیان می‌شود.

یک ابزار جانبی ممکن است یک شی فیزیکی باشد اما در واقع چندین تابع منطقی را پیاده سازی کند. به عنوان مثال، یک ابزار جانبی وب کم می تواند هم عملکرد دوربین و هم عملکرد صدای میکروفون را داشته باشد.

هر تابع جانبی دارای یک رابط است که پروتکل ارتباط با آن تابع را تعریف می کند.

میزبان با یک دستگاه جانبی از طریق یک لوله به یک نقطه پایانی ، منبع داده یا سینک ارائه شده توسط یکی از عملکردهای دستگاه جانبی ارتباط برقرار می کند.

دو نوع لوله وجود دارد: پیام و جریان . یک لوله پیام برای کنترل و وضعیت دو جهته استفاده می شود. یک لوله جریان برای انتقال داده های یک طرفه استفاده می شود.

میزبان تمام انتقال داده ها را آغاز می کند، از این رو اصطلاحات ورودی و خروجی نسبت به میزبان بیان می شوند. عملیات ورودی داده ها را از دستگاه جانبی به میزبان منتقل می کند، در حالی که عملیات خروجی داده ها را از میزبان به دستگاه جانبی منتقل می کند.

سه حالت عمده انتقال داده وجود دارد: وقفه ، حجیم و هم زمان . حالت Isochronous بیشتر در زمینه صدا مورد بحث قرار خواهد گرفت.

دستگاه جانبی ممکن است ترمینال هایی داشته باشد که به دنیای خارج، فراتر از خود دستگاه، متصل می شوند. به این ترتیب، دستگاه جانبی برای ترجمه بین پروتکل USB و سیگنال های "دنیای واقعی" عمل می کند. پایانه ها اشیاء منطقی تابع هستند.

حالت های USB اندروید

حالت توسعه

حالت توسعه از زمان عرضه اولیه اندروید وجود داشته است. دستگاه Android به‌عنوان یک USB جانبی برای رایانه میزبانی که دارای سیستم‌عامل رومیزی مانند Linux، Mac OS X یا Windows است ظاهر می‌شود. تنها عملکرد جانبی قابل مشاهده Android fastboot یا Android Debug Bridge (adb) است. پروتکل های fastboot و adb روی حالت انتقال داده انبوه USB لایه بندی شده اند.

حالت میزبان

حالت میزبان در اندروید 3.1 (سطح API 12) معرفی شده است.

از آنجایی که دستگاه Android باید به عنوان میزبان عمل کند، و اکثر دستگاه‌های Android دارای یک کانکتور میکرو USB هستند که مستقیماً اجازه عملکرد میزبان را نمی‌دهد، معمولاً یک آداپتور در حال حرکت ( OTG ) مانند این مورد نیاز است:

شکل 1. آداپتور در حال حرکت (OTG).

بسته به میزان برق مورد نیاز دستگاه جانبی و میزان توانایی دستگاه Android، ممکن است یک دستگاه Android برای کار با یک دستگاه جانبی خاص، توان کافی را ارائه نکند. حتی اگر برق کافی در دسترس باشد، ممکن است شارژ باتری دستگاه Android به میزان قابل توجهی کاهش یابد. برای این مواقع، از یک هاب برقی مانند زیر استفاده کنید:

شکل 2. هاب برق دار

حالت لوازم جانبی

حالت لوازم جانبی در اندروید 3.1 (سطح API 12) معرفی شد و به اندروید 2.3.4 منتقل شد. در این حالت، دستگاه اندروید به عنوان یک USB جانبی، تحت کنترل دستگاه دیگری مانند یک داک که به عنوان میزبان عمل می کند، عمل می کند. تفاوت بین حالت توسعه و حالت لوازم جانبی در این است که عملکردهای USB اضافی، فراتر از adb، برای میزبان قابل مشاهده است. دستگاه Android در حالت توسعه شروع می شود و سپس از طریق یک فرآیند مذاکره مجدد به حالت جانبی منتقل می شود.

حالت لوازم جانبی با ویژگی‌های اضافی در Android 4.1، به ویژه صدایی که در زیر توضیح داده شده است، گسترش یافت.

صدای USB

کلاس های USB

هر تابع جانبی یک سند کلاس دستگاه مرتبط دارد که پروتکل استاندارد آن تابع را مشخص می کند. این امر میزبان‌های سازگار با کلاس و توابع جانبی را قادر می‌سازد تا بدون اطلاع دقیق از عملکرد یکدیگر، با یکدیگر کار کنند. انطباق کلاس در صورتی حیاتی است که میزبان و دستگاه جانبی توسط نهادهای مختلف ارائه شده باشد.

اصطلاح بدون راننده مترادف رایجی برای کلاس سازگار است، که نشان می‌دهد می‌توان از ویژگی‌های استاندارد چنین ابزار جانبی بدون نیاز به نصب درایور خاص سیستم عامل استفاده کرد. می توان فرض کرد که یک ابزار جانبی که به عنوان "بدون نیاز به درایور" برای سیستم عامل های اصلی دسکتاپ تبلیغ می شود، مطابق با کلاس باشد، هرچند ممکن است استثناهایی وجود داشته باشد.

کلاس صوتی USB

در اینجا ما فقط به وسایل جانبی که عملکردهای صوتی را اجرا می کنند و بنابراین به کلاس دستگاه های صوتی پایبند هستند، توجه می کنیم. دو نسخه از مشخصات کلاس صوتی USB وجود دارد: کلاس 1 (UAC1) و 2 (UAC2).

مقایسه با کلاس های دیگر

USB شامل بسیاری از کلاس‌های دستگاه دیگر است که ممکن است برخی از آنها با کلاس صوتی اشتباه گرفته شوند. کلاس ذخیره سازی انبوه (MSC) برای دسترسی بخش محور به رسانه استفاده می شود، در حالی که پروتکل انتقال رسانه (MTP) برای دسترسی کامل فایل به رسانه استفاده می شود. هر دو MSC و MTP ممکن است برای انتقال فایل های صوتی استفاده شوند، اما فقط کلاس صوتی USB برای پخش بلادرنگ مناسب است.

پایانه های صوتی

پایانه های یک دستگاه جانبی صوتی معمولا آنالوگ هستند. سیگنال آنالوگ ارائه شده در ترمینال ورودی دستگاه جانبی توسط یک مبدل آنالوگ به دیجیتال (ADC) به دیجیتال تبدیل می شود و روی پروتکل USB حمل می شود تا توسط میزبان مصرف شود. ADC یک منبع داده برای میزبان است. به طور مشابه، میزبان یک سیگنال صوتی دیجیتال را از طریق پروتکل USB به دستگاه جانبی ارسال می کند، جایی که یک مبدل دیجیتال به آنالوگ (DAC) تبدیل می شود و به یک ترمینال خروجی آنالوگ ارائه می شود. DAC یک سینک برای میزبان است.

کانال ها

یک دستگاه جانبی با عملکرد صوتی می تواند شامل یک ترمینال منبع، ترمینال سینک یا هر دو باشد. هر جهت ممکن است یک کانال ( مونو )، دو کانال ( استریو ) یا بیشتر داشته باشد. تجهیزات جانبی با بیش از دو کانال چند کاناله نامیده می شوند. معمول است که یک جریان استریو را به عنوان متشکل از کانال های چپ و راست تفسیر کنیم، و در نتیجه یک جریان چند کانالی را به عنوان دارای مکان های فضایی مربوط به هر کانال تفسیر کنیم. با این حال، کاملاً مناسب است (مخصوصاً برای صدای USB بیشتر از HDMI ) که هیچ معنای مکانی استاندارد خاصی را به هر کانال اختصاص ندهید. در این صورت این به اپلیکیشن و کاربر است که نحوه استفاده از هر کانال را تعریف کنند. به عنوان مثال، یک جریان ورودی USB چهار کاناله ممکن است سه کانال اول را به میکروفون‌های مختلف در یک اتاق متصل کرده و کانال نهایی ورودی را از یک رادیو AM دریافت کند.

حالت انتقال هم زمان

صدای USB از حالت انتقال هم‌زمان برای ویژگی‌های بلادرنگ خود استفاده می‌کند که هزینه آن بازیابی خطا است. در حالت هم زمان، پهنای باند تضمین می شود و خطاهای انتقال داده با استفاده از بررسی افزونگی چرخه ای (CRC) شناسایی می شوند. اما در صورت بروز خطا، هیچ تایید بسته یا ارسال مجدد وجود ندارد.

انتقال هم زمان در هر دوره شروع فریم (SOF) رخ می دهد. دوره SOF برای سرعت کامل یک میلی ثانیه و برای سرعت بالا 125 میکروثانیه است. هر فریم با سرعت کامل تا 1023 بایت و یک فریم با سرعت بالا تا 1024 بایت را حمل می کند. با کنار هم گذاشتن اینها، حداکثر نرخ انتقال را 1023000 یا 8192000 بایت در ثانیه محاسبه می کنیم. این یک حد بالای تئوری را در نرخ نمونه صوتی ترکیبی، تعداد کانال و عمق بیت تعیین می کند. حد عملی کمتر است.

در حالت هم زمان، سه حالت فرعی وجود دارد:

• تطبیقی
• ناهمزمان
• همزمان

در حالت فرعی تطبیقی، سینک یا منبع محیطی با نرخ نمونه بالقوه متغیر میزبان سازگار می شود.

در حالت فرعی ناهمزمان (که بازخورد ضمنی نیز نامیده می‌شود)، سینک یا منبع میزان نمونه‌گیری را تعیین می‌کند و میزبان آن را تطبیق می‌دهد. مزیت نظری اولیه حالت فرعی ناهمزمان این است که ساعت USB منبع یا سینک از نظر فیزیکی و الکتریکی به ساعتی که DAC یا ADC را هدایت می‌کند (و در واقع ممکن است مشابه یا مشتق از آن باشد) نزدیک‌تر است. این نزدیکی به این معنی است که حالت فرعی ناهمزمان باید کمتر در معرض لرزش ساعت باشد. علاوه بر این، ساعت استفاده شده توسط DAC یا ADC ممکن است برای دقت بالاتر و رانش کمتر نسبت به ساعت میزبان طراحی شده باشد.

در حالت فرعی همزمان، تعداد ثابتی از بایت ها در هر دوره SOF منتقل می شود. نرخ نمونه صدا به طور موثر از ساعت USB مشتق شده است. حالت فرعی همزمان معمولاً با صدا استفاده نمی شود زیرا هم میزبان و هم دستگاه جانبی در اختیار ساعت USB هستند.

جدول زیر حالت های فرعی هم زمان را خلاصه می کند:

در عمل، حالت فرعی البته مهم است، اما عوامل دیگری نیز باید در نظر گرفته شوند.

پشتیبانی اندروید از کلاس صوتی USB

حالت توسعه

صدای USB در حالت توسعه پشتیبانی نمی شود.

حالت میزبان

اندروید 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 کیلوهرتز باشد.
• تعداد کانال باید 1 (مونو) یا 2 (استریو) باشد

مطالعه کد منبع چارچوب Android ممکن است کد اضافی فراتر از حداقل مورد نیاز برای پشتیبانی از این ویژگی ها را نشان دهد. اما این کد تایید نشده است، بنابراین ویژگی های پیشرفته تری هنوز ادعا نشده است.

حالت لوازم جانبی

Android 4.1 (سطح API 16) پشتیبانی محدودی را برای پخش صدا به میزبان اضافه کرد. در حالی که در حالت لوازم جانبی است، اندروید به طور خودکار خروجی صوتی خود را به USB هدایت می کند. یعنی دستگاه اندروید به عنوان منبع داده برای میزبان عمل می کند، به عنوان مثال یک داک.

صدای حالت لوازم جانبی این ویژگی ها را دارد:

• دستگاه Android باید توسط یک میزبان آگاه کنترل شود که بتواند ابتدا دستگاه Android را از حالت توسعه به حالت جانبی انتقال دهد و سپس میزبان باید داده های صوتی را از نقطه پایانی مناسب منتقل کند. بنابراین دستگاه Android برای میزبان "بدون راننده" به نظر نمی رسد.
• جهت باید ورودی باشد و نسبت به میزبان بیان شود
• فرمت صدا باید PCM 16 بیتی باشد
• نرخ نمونه باید 44.1 کیلوهرتز باشد
• تعداد کانال باید 2 باشد (استریو)

صدای حالت لوازم جانبی به طور گسترده مورد استفاده قرار نگرفته است و در حال حاضر برای طرح های جدید توصیه نمی شود.

کاربردهای صوتی دیجیتال USB

همانطور که از نام آن مشخص است، سیگنال صوتی دیجیتال USB به جای سیگنال آنالوگ که توسط کانکتور معمولی هدست TRS استفاده می شود، توسط یک جریان داده دیجیتال نشان داده می شود. در نهایت هر سیگنال دیجیتال قبل از شنیدن باید به آنالوگ تبدیل شود. در انتخاب محل قرار دادن آن تبدیل، معاوضه هایی وجود دارد.

داستان دو DAC

در نمودار مثال زیر، دو طرح را با هم مقایسه می کنیم. ابتدا یک دستگاه تلفن همراه با Application Processor (AP)، DAC داخلی، آمپلی فایر و کانکتور TRS آنالوگ متصل به هدفون داریم. ما همچنین یک دستگاه تلفن همراه با USB متصل به USB خارجی DAC و تقویت کننده، همچنین با هدفون در نظر می گیریم.

شکل 3. مقایسه دو DAC

کدام طرح بهتر است؟ پاسخ به نیاز شما بستگی دارد. هر کدام مزایا و معایبی دارند.

توجه: این یک مقایسه مصنوعی است، زیرا یک دستگاه اندروید واقعی احتمالاً هر دو گزینه را در دسترس خواهد داشت.

اولین طرح A ساده‌تر، ارزان‌تر است، از توان کمتری استفاده می‌کند و با فرض اینکه اجزای یکسانی قابل اعتماد باشند، طراحی قابل اعتمادتری خواهد بود. با این حال، معمولاً کیفیت صدا در مقابل سایر الزامات معاوضه وجود دارد. به عنوان مثال، اگر این یک دستگاه بازار انبوه است، ممکن است متناسب با نیازهای مصرف کننده عمومی طراحی شده باشد، نه برای علاقه مندان به صدا.

در طراحی دوم، دستگاه جانبی صوتی خارجی C را می توان برای کیفیت صدای بالاتر و توان خروجی بیشتر طراحی کرد بدون اینکه هزینه دستگاه اندروید B را تحت تاثیر قرار دهد. بله، طراحی گران تری است، اما هزینه آن فقط توسط کسانی که آن را می خواهند

دستگاه‌های تلفن همراه به داشتن بردهای مدار با چگالی بالا معروف هستند، که می‌تواند فرصت‌های بیشتری برای تداخل ایجاد کند که سیگنال‌های آنالوگ مجاور را تخریب می‌کند. ارتباطات دیجیتال کمتر در معرض نویز قرار دارد، بنابراین انتقال DAC از دستگاه Android A به یک برد مدار خارجی C به مراحل نهایی آنالوگ اجازه می‌دهد تا از نظر فیزیکی و الکتریکی از برد مدار متراکم و پر سر و صدا جدا شوند و در نتیجه صدای وفاداری بالاتری ایجاد شود.

از سوی دیگر، طراحی دوم پیچیده‌تر است و با پیچیدگی بیشتر، فرصت‌های بیشتری برای شکست چیزها به وجود می‌آید. همچنین تاخیر اضافی از کنترلرهای USB وجود دارد.

برنامه های حالت میزبان

برنامه‌های صوتی حالت میزبان USB معمولی عبارتند از:

• گوش دادن به موسیقی
• تلفن
• پیام فوری و چت صوتی
• ضبط کردن

برای همه این برنامه‌ها، Android یک دستگاه جانبی صوتی دیجیتال USB سازگار را شناسایی می‌کند و به طور خودکار بر اساس قوانین خط‌مشی صدا، پخش و ضبط صدا را به طور مناسب هدایت می‌کند. محتوای استریو در دو کانال اول دستگاه جانبی پخش می شود.

هیچ API خاصی برای صدای دیجیتال USB وجود ندارد. برای استفاده پیشرفته، مسیریابی خودکار ممکن است با برنامه هایی که از USB آگاه هستند تداخل ایجاد کند. برای چنین برنامه‌هایی، مسیریابی خودکار را از طریق کنترل مربوطه در بخش رسانه تنظیمات / گزینه‌های برنامه‌نویس غیرفعال کنید.

اشکال زدایی در حالت میزبان

در حالت میزبان USB، اشکال زدایی adb از طریق USB در دسترس نیست. برای یک جایگزین، بخش استفاده بی‌سیم از Android Debug Bridge را ببینید.

اجرای صدای USB

توصیه هایی برای فروشندگان لوازم جانبی صوتی

به منظور همکاری با دستگاه های اندرویدی، فروشندگان لوازم جانبی صوتی باید:

• طراحی برای مطابقت با کلاس صوتی؛ در حال حاضر اندروید کلاس 1 را هدف قرار می دهد، اما عاقلانه است که برای کلاس 2 برنامه ریزی کنید
• اجتناب از عجیب و غریب
• تست قابلیت همکاری با دستگاه های مرجع و محبوب اندروید
• ویژگی های پشتیبانی شده، انطباق با کلاس صوتی، نیازهای برق و غیره را به وضوح مستند کنید تا مصرف کنندگان بتوانند تصمیمات آگاهانه بگیرند.

توصیه هایی برای سازندگان دستگاه های اندرویدی و فروشندگان SoC

به منظور پشتیبانی از صدای دیجیتال USB، سازندگان OEM دستگاه و فروشندگان SoC باید:

• طراحی سخت افزار برای پشتیبانی از حالت میزبان USB
• پشتیبانی از میزبان USB عمومی را در سطح چارچوب از طریق پرچم ویژگی 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 مراجعه کنید.