نسخه Android 10 شامل تغییر شکل قابل توجهی از مدیر سیاست صوتی برای ارائه انعطاف پذیری بیشتر برای پشتیبانی از موارد پیچیده استفاده از اتومبیل است:
استراتژی های مسیریابی OEM خاص
گروههای حجم قابل تنظیم برای گروههایی از انواع جریان قدیمی با استفاده از منحنیهای حجم یکسان.
استراتژیهای مسیریابی که توسط موتور خطمشی صوتی بهجای کدگذاری سخت اعلام شده است.
منحنیهای حجم و گروههای مدیریت شده توسط موتور خطمشی صوتی.
بازسازی داخلی آماده سازی برای تقسیم آتی بین کد رایج و کد قابل تنظیم و ارائه مدیریت غنی تر دستگاه صوتی. به عنوان مثال، استفاده از تمام ویژگی های دستگاه نه فقط نوع آن در قوانین خط مشی.
Android 7.0 فرمت فایل پیکربندی خط مشی صوتی (XML) را برای توصیف توپولوژی صوتی شما معرفی کرد.
نسخههای قبلی Android با استفاده از device/<company>/<device>/audio/audio_policy.conf مورد نیاز است تا دستگاههای صوتی موجود در محصول خود را اعلام کنید (نمونهای از این فایل را برای سختافزار صوتی Galaxy Nexus در device/samsung/tuna/audio/audio_policy.conf مشاهده میکنید. device/samsung/tuna/audio/audio_policy.conf ). با این حال، CONF یک قالب ساده و اختصاصی است که برای توصیف توپولوژی های پیچیده برای عمودی مانند تلویزیون و اتومبیل بسیار محدود است.
Android 7.0 audio_policy.conf را منسوخ کرد و برای تعریف توپولوژی صوتی با استفاده از قالب فایل XML که برای انسان قابل خواندن تر است، دارای طیف وسیعی از ابزارهای ویرایش و تجزیه است و به اندازه کافی برای توصیف توپولوژی های صوتی پیچیده انعطاف پذیر است، پشتیبانی اضافه کرد. Android 7.0 از پرچم ساخت USE_XML_AUDIO_POLICY_CONF برای انتخاب قالب XML فایل های پیکربندی استفاده می کند.
مزایای فرمت XML
مانند فایل CONF، فایل XML امکان تعریف تعداد و انواع نمایههای جریان خروجی و ورودی، دستگاههای قابل استفاده برای پخش و ضبط، و ویژگیهای صوتی را میدهد. علاوه بر این، فرمت XML پیشرفت های زیر را ارائه می دهد:
در اندروید 10، بیش از یک برنامه ضبط فعال به طور همزمان مجاز است.
شروع ضبط هرگز به دلیل وضعیت همزمان رد نمی شود.
پاسخ تماس registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb) مشتریان را از تغییرات مسیر ضبط مطلع می کند.
در شرایط زیر، مشتری نمونه های صوتی بی صدا دریافت می کند:
یک مورد استفاده حساس به حریم خصوصی (به عنوان مثال، VOICE_COMMUNICATION ) فعال است.
مشتری سرویس پیش زمینه یا رابط کاربری پیش زمینه ندارد.
نقش های ویژه توسط خط مشی به رسمیت شناخته می شوند:
سرویس دسترسپذیری: میتواند ضبط کند حتی اگر یک مورد استفاده حساس به حریم خصوصی فعال باشد.
دستیار: اگر رابط کاربری در بالا باشد، به حریم خصوصی حساس است.
نمایههای صوتی ساختاری شبیه به توصیفگرهای صوتی ساده HDMI دارند که مجموعه متفاوتی از نرخهای نمونهبرداری/ماسک کانال را برای هر فرمت صوتی امکانپذیر میسازد.
تعاریف صریحی برای همه اتصالات ممکن بین دستگاه ها و جریان ها وجود دارد. پیش از این، یک قانون ضمنی اتصال همه دستگاههای متصل به یک ماژول HAL را امکانپذیر میکرد و از کنترل کردن اتصالات درخواست شده با API وصله صوتی توسط خط مشی صوتی جلوگیری میکرد. در قالب XML، توضیحات توپولوژی محدودیت های اتصال را تعریف می کند.
پشتیبانی شامل جلوگیری از تکرار تعاریف استاندارد A2DP، USB یا ارسال مجدد مسیر است.
منحنی های حجم قابل تنظیم هستند. قبلا، جداول حجم هاردکد شده بودند. در قالب XML، جداول حجم شرح داده شده است و می توان آن را سفارشی کرد.
الگوی frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml بسیاری از این ویژگیها را در حال استفاده نشان میدهد.
فرمت فایل و مکان
فایل پیکربندی خط مشی صوتی جدید audio_policy_configuration.xml است و در /system/etc قرار دارد. مثالهای زیر یک پیکربندی خطمشی صوتی ساده را در قالب فایل XML برای Android 12 و برای نسخههای زیر Android 12 نشان میدهند.
ساختار سطح بالا شامل ماژولهایی است که با هر ماژول سختافزار صوتی HAL مطابقت دارند، جایی که هر ماژول فهرستی از پورتهای ترکیبی، پورتهای دستگاه و مسیرها را دارد:
پورتهای ترکیبی، نمایههای پیکربندی ممکن برای جریانها را توصیف میکنند که میتوانند در HAL صوتی برای پخش و ضبط باز شوند.
درگاههای دستگاه، دستگاههایی را توصیف میکنند که میتوان با نوع آنها (و به صورت اختیاری آدرس و ویژگیهای صوتی، در صورت لزوم) متصل شوند.
Routes از توصیفگر پورت ترکیبی جدا شده است و شرح مسیرها را از دستگاهی به دستگاه دیگر یا جریانی به دستگاه دیگر را امکان پذیر می کند.
جداول حجم لیست ساده ای از نقاط هستند که منحنی مورد استفاده را برای ترجمه از شاخص UI به حجم در دسی بل تعریف می کنند. یک فایل شامل جداگانه منحنی های پیش فرض را ارائه می دهد، اما هر منحنی برای یک مورد خاص و دسته دستگاه می تواند بازنویسی شود.
روش XML Inclusions (XInclude) می تواند برای گنجاندن اطلاعات پیکربندی خط مشی صوتی واقع در سایر فایل های XML استفاده شود. همه فایل های ارائه شده باید از ساختار توضیح داده شده در بالا با محدودیت های زیر پیروی کنند:
فایل ها فقط می توانند حاوی عناصر سطح بالا باشند.
فایل ها نمی توانند حاوی عناصر XInclude باشند.
استفاده شامل جلوگیری از کپی کردن اطلاعات پیکربندی ماژول صوتی HAL استاندارد پروژه منبع باز Android (AOSP) در همه فایلهای پیکربندی خط مشی صوتی (که مستعد خطا است). یک فایل XML پیکربندی خط مشی صوتی استاندارد برای HAL های صوتی زیر ارائه شده است:
A2DP:a2dp_audio_policy_configuration.xml
تغییر مسیر زیر میکس:rsubmix_audio_policy_configuration.xml
USB:usb_audio_policy_configuration.xml
سازمان کد خط مشی صوتی
AudioPolicyManager.cpp به چندین ماژول تقسیم شده است تا نگهداری و پیکربندی آن آسان باشد. سازمان frameworks/av/services/audiopolicy شامل ماژول های زیر است.
ماژول
توضیحات
/managerdefault
شامل رابط های عمومی و اجرای رفتار مشترک برای همه برنامه ها است. مشابه AudioPolicyManager.cpp با عملکرد موتور و مفاهیم رایج انتزاع شده است.
/common
کلاس های پایه را تعریف می کند (به عنوان مثال، ساختارهای داده برای نمایه های جریان صوتی ورودی خروجی، توصیفگرهای دستگاه صوتی، وصله های صوتی، و پورت های صوتی). این قبلاً در AudioPolicyManager.cpp تعریف شده بود.
/engine
قوانینی را اجرا میکند که تعیین میکند کدام دستگاه و حجمها باید برای یک مورد خاص استفاده شوند. این یک رابط استاندارد را با بخش عمومی پیادهسازی میکند، مانند دریافت دستگاه مناسب برای یک مورد خاص پخش یا ضبط، یا تنظیم دستگاههای متصل یا حالت خارجی (یعنی حالت تماس استفاده اجباری) که میتواند مسیریابی را تغییر دهد. تصمیم گیری
پیاده سازی موتور خط مشی که بر چارچوب پارامتر متکی است (به زیر مراجعه کنید). پیکربندی بر اساس چارچوب پارامتر و جایی است که خط مشی توسط فایل های XML تعریف می شود.
/enginedefault
پیاده سازی موتور خط مشی بر اساس پیاده سازی های قبلی Android Audio Policy Manager. این پیشفرض است و شامل قوانین سختکد شدهای است که با اجرای Nexus و AOSP مطابقت دارند.
/service
شامل رابط های کلاسور، threading و اجرای قفل با رابط به بقیه چارچوب است.
پیکربندی با استفاده از چارچوب پارامتر
کد خط مشی صوتی به گونه ای سازماندهی شده است که درک و نگهداری آن آسان باشد و در عین حال از یک خط مشی صوتی که به طور کامل توسط فایل های پیکربندی تعریف شده است نیز پشتیبانی می کند. سازماندهی و طراحی خط مشی صوتی بر اساس چارچوب پارامتر اینتل، چارچوبی مبتنی بر پلاگین و قانون برای کنترل پارامترها است.
استفاده از خط مشی صوتی قابل تنظیم، OEM های فروشندگان را قادر می سازد:
ساختار یک سیستم و پارامترهای آن را در XML توضیح دهید.
نوشتن (در C++) یا استفاده مجدد از یک باطن (پلاگین) برای دسترسی به پارامترهای توصیف شده.
شرایط/قواعدی را (در XML یا در یک زبان خاص دامنه) تعریف کنید که بر اساس آن یک پارامتر معین باید مقدار معینی را بگیرد.
AOSP شامل نمونه ای از فایل پیکربندی خط مشی صوتی است که از Framework Framework در Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml استفاده می کند. برای جزئیات، به مستندات اینتل در چارچوب پارامتر مراجعه کنید.
در Android 10 یا پایینتر، خطمشی صوتی قابل تنظیم با استفاده از گزینه ساخت USE_CONFIGURABLE_AUDIO_POLICY انتخاب میشود. در اندروید 11 یا بالاتر، نسخه موتور خطمشی صوتی در فایل audio_policy_configuration.xml انتخاب میشود. برای انتخاب موتور خط مشی صوتی قابل تنظیم، مقدار ویژگی engine_library عنصر globalConfiguration را روی configurable مانند مثال زیر تنظیم کنید:
Android 6.0 یک API عمومی Enumeration and Selection را معرفی کرد که در بالای زیرساخت وصله صوتی/پورت صوتی قرار میگیرد و به توسعهدهندگان برنامه اجازه میدهد تا ترجیحی برای خروجی یا ورودی دستگاه خاص برای ضبطها یا آهنگهای صوتی متصل نشان دهند.
در Android نسخه 7.0، Enumeration and Selection API توسط تستهای CTS تأیید میشود و برای شامل مسیریابی برای جریانهای صوتی C/C++ (OpenSL ES) داخلی گسترش مییابد. مسیریابی جریانهای بومی در جاوا با افزودن یک رابط AudioRouting که روشهای مسیریابی صریح را که مختص کلاسهای AudioTrack و AudioRecord بودند جایگزین، ترکیب و منسوخ میکند، ادامه مییابد.
برای جزئیات بیشتر در مورد Enumeration and Selection API، به رابطهای پیکربندی Android و OpenSLES_AndroidConfiguration.h مراجعه کنید. برای جزئیات بیشتر در مورد مسیریابی صدا، به AudioRouting مراجعه کنید.
پشتیبانی چند کاناله
اگر سختافزار و درایور شما از صدای چند کاناله از طریق HDMI پشتیبانی میکند، میتوانید جریان صدا را مستقیماً به سختافزار صوتی ارسال کنید (این کار میکسر AudioFlinger را دور میزند تا به دو کانال پایین نمیآید.) HAL صدا باید نمایه جریان خروجی را نشان دهد. از قابلیت های صوتی چند کاناله پشتیبانی می کند. اگر HAL قابلیت های خود را نشان دهد، مدیر خط مشی پیش فرض امکان پخش چند کاناله را از طریق HDMI می دهد. برای جزئیات پیاده سازی، device/samsung/tuna/audio/audio_hw.c ببینید.
برای اینکه مشخص کنید محصول شما دارای خروجی صوتی چند کاناله است، فایل پیکربندی خط مشی صدا را ویرایش کنید تا خروجی چند کاناله محصول شما را توصیف کند. مثال زیر از frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml یک ماسک کانال پویا را نشان می دهد، به این معنی که مدیر خط مشی صوتی، ماسک های کانال پشتیبانی شده توسط سینک HDMI را پس از اتصال جستجو می کند.
همچنین می توانید یک ماسک کانال ثابت مانند AUDIO_CHANNEL_OUT_5POINT1 را مشخص کنید. میکسر AudioFlinger وقتی به دستگاه صوتی که از صدای چند کاناله پشتیبانی نمیکند ارسال میشود، محتوا را بهطور خودکار به استریو میکس میکند.
کدک های رسانه ای
مطمئن شوید که کدکهای صوتی که سختافزار و درایورهای شما پشتیبانی میکنند به درستی برای محصول شما اعلام شدهاند. برای جزئیات، به افشای کدک ها در چارچوب مراجعه کنید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2024-11-18 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2024-11-18 بهوقت ساعت هماهنگ جهانی."],[],[]]