簡単な方法でAndroidオーディオオーディオシステム

1.オーディオオーディオアーキテクチャの概要

2、Androidオーディオシステムフレームワーク

3.各レイヤーのオーディオアーキテクチャとコード配布図

第四に、オーディオフレームワークはAndroidシステムでさらに洗練されています

5、サウンドカードを作成し、サウンドカードを登録します

6、Androidオーディオシステムの構造

セブン、オーディオオーディオ原理の紹介

8つのオーディオオーディオ戦略の策定と戦略実行の呼び出しプロセス

9つのAndroidAudioPolicyServiceサービスの起動プロセス

10. Androidシステムのすべてのオーディオインターフェイスデバイスは、AudioFlingerのメンバー変数mAudioHwDevsに保存されます

11. Audio_policy.confは、同時に複数のオーディオインターフェイスを定義します

12. AudioFlingerのloadHwModuleを介して、各オーディオインターフェイスに対応するライブラリファイルをロードし、PlaybackThread再生スレッドまたはRecordThread録音スレッドを呼び出します。

13、AudioFlingerのopenInput（）メソッド呼び出しプロセス分析

14. AudioFlingerのopenOutput（）メソッドの呼び出しフローの分析

15.オーディオデータを正常に再生するには、オーディオシステムが抽象的なオーディオ出力インターフェイスオブジェクトを作成し、オーディオ出力プロセスを開く必要があります。

16.オーディオ入力を開くプロセス

17.オーディオ出力をオンにした後、AudioFlingerおよびAudioPolicyServiceのマニフェスト

18.オーディオ入力がオンになった後、AudioFlingerおよびAudioPolicyServiceの式の形式

19. AudioPolicyServiceは、システムによって定義されたすべてのオーディオインターフェイスをロードし、対応するデータオブジェクトを生成します

20、AudioPolicyServiceとAudioTrackおよびAudioFlingerの関係

21.サービスとして登録されたAudioPolicyServiceのプロセス

22、AudioTrack構築プロセス

23、AudioTrackとAudioFlingerの関係

24、audio_policyとAudioPolicyService、AudioPolicyCompatClientの関係

1.オーディオオーディオアーキテクチャの概要

APP

オーディオシステム全体の最上層

フレームワーク

MediaPlayerとMediaRecorder、AudioTrackとAudioRecorder、Androidシステムは、オーディオシステムを制御するためのAudioManager、AudioService、AudioSystemクラスを提供します。これらはすべて、上位レベルのアプリケーションの開発を容易にするためにフレームワークによって設計されています。

ライブラリ

システムサービスAudioFlingerおよびAudioPolicyService（ServiceManager、LocationManagerService、ActivityManagerServiceなど）。オーディオシステムのもう1つの重要なシステムサービスはMediaPlayerServiceです。

モノ

ハードウェアアブストラクションレイヤーは、AudioFlingerから直接アクセスされるオブジェクトです。これは、2つの問題を示しています。一方、AudioFlingerは、基になるドライバーを直接呼び出さない一方で、AudioFlingerの上位レイヤー（同じレイヤーのMediaPlayerServiceを含む）対話するだけでオーディオ関連の機能を実現できます。したがって、AudioFlingerはAndroidオーディオシステムの真の「分離ボード」と見なすことができます。次の変更がどのように行われたとしても、上位レベルの実装は互換性を維持できます。オーディオのハードウェアアブストラクションレイヤーは、主にAudioFlingerとAudioPolicyServiceの2つの部分に分かれています。実際、後者は実際のデバイスではありませんが、仮想デバイスを使用して、メーカーが独自の戦略を簡単にカスタマイズできるようにします。抽象化レイヤーのタスクは、AudioFlinger / AudioPolicyServiceをハードウェアデバイスに実際に関連付けることです。

以前は、AndroidシステムのオーディオシステムはALSA-libに依存していましたが、後にtinyalsaになりました。このような変更によって、上位層が損傷することはありません。したがって、Audio HALは、AudioFlinger / AudioPolicyServiceとの間の通信方法を定義するための統一されたインターフェイスを提供します。これがaudio_hw_device、audio_stream_in、audio_stream_outなどの目的です。これらのStructデータタイプのほとんどは、いくつかの「シェル」である関数ポインターの定義です。 "。"。AudioFlinger / AudioPolicyServiceが初期化されると、システム内で最も一致する実装を探し（これらの実装はaudio.primary。*、audio.a2dp。*という名前のさまざまなライブラリにあります）、これらの「シェル」を埋めます。

Androidオーディオシステムを理解する際の2つの手がかりがあります

たとえば、ライブラリを手がかりとして考えてみましょう。AudioPolicyServiceとAudioFlingerはどちらもlibaudioflingerライブラリにあり、AudioTrackやAudioRecorderなどの一連の実装はlibmediaライブラリにあります。

プロセスを手がかりとして、ライブラリはプロセスを表さず、プロセスは実行するライブラリに依存します。一部のクラスは同じライブラリに実装されていますが、同じプロセスで呼び出されるわけではありません。たとえば、AudioFlingerとAudioPolicyServiceはどちらもmediaserverという名前のシステムプロセスに存在しますが、AudioTrack / AudioRecorderとMediaPlayer / MediaRecorderは実際にはアプリケーションプロセスの一部にすぎず、バインダーサービスを介して他のシステムプロセスと通信します。

2、Androidオーディオシステムフレームワーク

3.各レイヤーのオーディオアーキテクチャとコード配布図

第四に、オーディオフレームワークはAndroidシステムでさらに洗練されています

5、サウンドカードを作成し、サウンドカードを登録します

6、Androidオーディオシステムの構造

セブン、オーディオオーディオ原理の紹介

AudioFlinger、AudioPolicyService、AudioTrack / AudioRecorderは、アプリケーション開発に直接関係するMediaPlayer、MediaRecorderを脇に置いており、オーディオシステム全体のコアはこれら3つで構成されています。それらの最初の2つはシステムサービスであり、メディアサーバープロセスに常駐し、AudioTrack / AudioRecorder要求を継続的に処理します。オーディオの再生と録音はプロセス全体の点で類似しているため、AudioTrackの分析に焦点を当てます

すべてのメディア関連のネイティブレイヤーサービス（AudioFlinger、MediaPlayerService、CameraService、AudioPolicyServiceを含む）を開始すると、コンパイルされたメディアサーバーがデバイスの/ system / bin / mediaserverパスに書き込まれ、システムの起動時にinitプロセスによって開始されます

オーディオシステムの構造

libmedia.soは、オーディオインターフェイスを提供します。これらのオーディオインターフェイスは、ネイティブコードだけでなく上位層にも開かれています。

libaudiofilnger.soは、オーディオインターフェイスの実装を提供します

オーディオハードウェア抽象化レイヤーは、AudioFlingerが呼び出すハードウェアへのインターフェイスを提供します

オーディオはJNIとJAVAを使用して、上位層へのインターフェースを提供します

メディアライブラリのオーディオフレーム部分

Androidのオーディオのコアフレームワークは、主にAudioSystem、AudioTrack、AudioRecorderの3つのクラスを実装するメディアライブラリで提供されます。IAudioFlingerクラスインターフェイスを提供します。このクラスでは、IAudioTrackとIAudioRecorderの2つのインターフェイスを取得できます。これらは、それぞれサウンドの再生と録音に使用されます。AudioTrackとAudioRecorderは、それぞれIAudioTrackとIAudioRecorderを呼び出すことで実装されます。

オーディオシステムヘッダーファイル

パスは次のとおりです：frameworks / base / include / media /

AudioSystem.h

IAudioFlinger.h

AudioTrack.h

IAudioTrack.h

AudioRecorder.h

IAudioRecorder.h

IxxxインターフェースはAudioFlingerを介して実装され、他のインターフェースはJNIを介して上位層へのインターフェースを提供します。

オーディオシステムのヘッダーファイルはframeworks / base / include / media /ディレクトリにあり、メインのヘッダーファイルは次のとおりです。

AudioSystem.h：メディアライブラリのオーディオ部分の上位層マネージャーへのインターフェイス

IAudioFlinger.h：下位層で実装する必要のあるマスターインターフェイス

AudioTrack.h：再生部分の上部インターフェース

IAudioTrack.h：再生部分の下位レイヤーで実装する必要のあるインターフェイス

AudioRecorder.h：録音部分の上部インターフェース

IAudioRecorder.h：録音部分の下位層によって実装される必要があるインターフェース

IAudioFlinger.h、IAudioTrack.h、およびIAudioRecorder.hの3つのインターフェイスは、下位層（つまり、AudioFlinger）の継承を通じて実装されます。

AudioFlinger.h、AudioTrack.h、AudioRecorder.hは、上位層に提供されるインターフェイスです。これらは、ローカルプログラム（サウンドプレーヤー、レコーダーなど）が呼び出すために使用するだけでなく、 JNIを介したJavaレイヤー

AudioTrackとAudioRecorderの両方に、開始、停止、一時停止などのインターフェイスがあります。前者は音声再生用の書き込みインターフェースを備え、後者は録音用の読み取りインターフェースを備えています。

AudioSystemは、オーディオシステムを制御するために使用されます。これには、主に、上位層のクラスであるいくつかのsetおよびgetインターフェイスが含まれています。

AudioFlingerはオーディオシステムのコアです。AudioTrackからのデータは最終的にここで処理され、AudioHALレイヤーに書き込まれます。

MediaPlayerは引き続きフレームワークレイヤーでAudioTrackを作成し、デコードされたPCMストリームをAudioTrackに渡し、次にそれをAudioFlingerに渡してミキシングし、次にハードウェアに渡して再生するため、MediaPlayerにはAudioTrackが含まれます。AudioTrackを使用して音楽を再生する

MediaPlayerは、より完全なパッケージと状態制御を提供します。MediaPlayerと比較して、AudioTrackはより洗練され、効率的です。実際、MediaPlayerServiceの内部実装は、AudioTrackを使用して、すべてのメディア関連のネイティブレイヤーサービス（AudioFlinger、MediaPlayerService、CameraService、AudioPolicyServiceを含む）を統合します。起動すると、コンパイルされたメディアサーバーはデバイスの/ system / bin / mediaserverパスに書き込まれ、システムの起動時にinitプロセスによって開始されます

2つのオーディオハードウェアHALインターフェイスの定義

レガシー：hardware / libhardware_legacy / include / hardware_legacy / AudioHardwareInterface.h

非レガシー：hardware / libhardware / include / hardware / audio.h

前者は2.3以前のオーディオデバイスインターフェイス定義であり、後者は4.0のインターフェイス定義です。前の設計と互換性を持たせるために、4.0は中間層を実装します：hardware / libhardware_legacy / audio /audio_hw_hal.cpp。構造は他のaudio_hw.cと似ています。違いは、openメソッドを実際には非レガシーaudio.hにカプセル化する必要があることです。正確には、レガシーインターフェイスではなくレガシーインターフェイスを接続する中間層が必要です。Audio_hw_hal.cppはこちらそのような役割として機能します。

ハードウェア/ libhardware /モジュール/オーディオ/

createAudioHardware（）関数

外部/ tinyalsa /

Mixer.cは、オーディオコンポーネントスイッチ、音量調整などとして機能するクラスalsa-libのコントロールです。

pcm.cクラスalsa-libpcm、オーディオpcmデータの再生と録音に使用

上記のhardware / libhardware_legacy / audio /、hardware / libhardware / modules / audio /、device / samsung / tuna / audio /は同じレイヤーにあります。1つは2.2時代のalsa_soundと互換性のあるレガシーオーディオです。2つ目はスタブオーディオインターフェイスです。3つ目はSamsungTunaのオーディオ抽象化レイヤーの実装です。通話レベル：AudioFlinger-> audio_hw-> tinyalsa

オーディオハードウェアアブストラクションレイヤーの実装はシステムごとに異なる場合があります。対応するクラスを継承して実装するには、コードを使用する必要があります。Androidシステムのローカルフレームワークレイヤーとドライバーインターフェイスとして、AudioFlingerはlibmedia.so（オーディオローカルフレームワーククラス）を継承します。上位層はlibmedia.so部分のインターフェースのみを呼び出しますが、実際に呼び出されるコンテンツはlibaudioflinger.soであり、JNIとJavaを使用して上位層へのインターフェースを提供し、JNI部分はによって提供されるインターフェースを呼び出すことによって実装されます。 libmedia.soライブラリ

オーディオハードウェアアブストラクションレイヤーは、AudioFlingerが呼び出すハードウェアへのインターフェイスを提供します。オーディオハードウェアアブストラクションレイヤーは、Androidのオーディオシステムがそうではないため、実際には、各プラットフォームの開発プロセスで主に関係し、独立して完了する必要がある部分です。コーディングとデコードのリンクを含み、責任があるのは上位システムと基盤となるオーディオハードウェア間の相互作用であるため、通常はPCMが入力/出力形式として使用されます。

IAudioFlingerクラスインターフェイスは、このクラスを介して、サウンドの再生と録音にそれぞれ使用される2つのインターフェイスIAudioTrackとIAudioRecorderを取得できます。AudioTrackとAudioRecorderは、それぞれIAudioTrackとIAudioRecorderを呼び出すことによって実装されます。

ハードウェアアブストラクションレイヤーは、主にAudioStreamInALSAとAudioStreamOutALSAの2つのクラスを実装します。これらのクラスは、ファイルの下にあるALSAStreamOpsクラスのメソッドを呼び出します。AudioStreamInALSAは、録音部分によって呼び出されるパスです。AudioStreamInALSAのコンストラクターでは、いくつかの初期化パラメーター設定がalsaで実行されます。

AudioStreamInALSAのreadメソッドは最も重要なメソッドであり、audioflingerレイヤーのread呼び出しはAudioStreamInALSAのreadの呼び出しです。のため

録音部分でのモノチャンネルとデュアルチャンネルのデータ転送に問題があります。通常の録音機能を実現し、エンコード中にデータを変更しても他のエンコードが機能しないという欠点を回避するために、読み取り方法を次のように変更します。

8つのオーディオオーディオ戦略の策定と戦略実行の呼び出しプロセス

AudioPolicyServiceはポリシーの作成者であり、AudioFlingerはポリシーの実行者です。

AudioTrackはAudioFlingerのクライアントであり、AudioFlingerはAndroidシステムのオーディオ管理の中心です。

Androidでは、AudioFlingerが実際にハードウェアデバイスを作成および管理するため、AudioPolicyServiceは最終的にAudioFlingerに呼び出されます。

AudioFlingerクラスは、AudioFlingerサービス全体を表すクラスであり、他のすべての作業クラスは、内部クラスを介して定義されます。

9つのAndroidAudioPolicyServiceサービスの起動プロセス

AudioPolicyServiceによって行われた作業

audio_policy.default.soライブラリをロードして、audio_policy_moduleモジュールを取得します

audio_policy_moduleモジュールを介してaudio_policy_deviceデバイスを開きます

audio_policy_deviceデバイスを介してaudio_policyを作成します

hw_get_module関数は、ハードウェアアブストラクションレイヤーモジュールのプロセスをロードします

Audio_policyはaudio_policy_hal.cppに実装され、audio_policy_service_opsはAudioPolicyService.cppに実装されています。create_audio_policy（）関数は、legacy_audio_policyオブジェクトを作成および初期化するためのものです。AudioPolicyCompatClientは、audio_policy_service_opsのカプセル化クラスであり、audio_policy_service_opsデータ構造で定義されたインターフェイスを提供します。

AndroidAudioPolicyServiceサービスの起動プロセス

AudioPolicyCompatClientオブジェクトを参照して、オーディオマネージャーAudioPolicyManagerがaudio_policy_service_opsのインターフェイスを使用できるようにします。

最初に/vendor/etc/audio_policy.conf構成ファイルをロードします。構成ファイルが存在しない場合は、/ system / etc / audio_policy.conf構成ファイルをロードします。ファイルがまだ存在しない場合は、関数defaultAudioPolicyConfig（）を使用してデフォルトのオーディオインターフェースを設定する

さまざまなオーディオストリームに対応する音量調整ポイントを設定します

対応するオーディオインターフェイスハードウェアアブストラクションライブラリを名前で開きます

mAttachedOutputDevicesに対応する出力を開きます

出力IOProfileをAudioOutputDescriptorオブジェクトとしてカプセル化します

現在のオーディオインターフェイスのデフォルトの出力デバイスを設定します

出力をオンにし、AudioFlingerでPlaybackThreadスレッドを作成して、スレッドのIDを返します。

mAttachedOutputDevicesとして使用できる出力デバイスを設定します

出力記述子オブジェクトAudioOutputDescriptorと作成されたPlaybackThreadスレッドIDをキーと値のペアの形式で保存します

デフォルトの出力デバイスを設定します

次の手順は、主にAudioPolicyManagerBaseオブジェクトの構築中に完了します。

loadAudioPolicyConfig（AUDIO_POLICY_CONFIG_FILE）audio_policy.conf構成ファイルをロードします

initializeVolumeCurves（）は、さまざまなオーディオストリームに対応する音量調整ポイントを初期化します

オーディオポリシーハードウェア抽象化ライブラリをロードします：mpClientInterface-> loadHwModule（mHwModules [i]-> mName）

attach_output_devices出力を開くmpClientInterface-> openOutput（）;

出力デバイス記述子オブジェクトを保存しますaddOutput（output、outputDesc）;

10. Androidシステムのすべてのオーディオインターフェイスデバイスは、AudioFlingerのメンバー変数mAudioHwDevsに保存されます

audio_policy.confファイル

audio_policy.confファイルから、システムには、システム内のaudio。<primary / a2dp/usb>。<device>.soに対応するprimary、a2dp、usbなどのオーディオインターフェイスが含まれていることがわかります。各オーディオインターフェイスには複数の出力と入力が含まれ、各出力または入力には、サンプリング周波数、チャネル数、その他の情報だけでなく、複数のデバイスが含まれます。これらのデバイス情報、サンプリング周波数情報、チャネル情報などは、それぞれのモジュールのIOProfileに格納されます。上記のaudio_policy.conf構成ファイルで説明されているように、システムは最終的に6つのモジュール（たとえば、primary、a2dp、hdmi、r_submix、hs_usb、usb）と7つの出力を生成します。

11. Audio_policy.confは、同時に複数のオーディオインターフェイスを定義します

通常、Android製品ごとにオーディオデザインに違いがあり、これらの違いはAudioの構成ファイルaudio_policy.confから取得できます。Androidシステムにはオーディオ構成ファイル用の2つのストレージパスがあり、ストレージアドレスはAudioPolicyManagerBase.cppファイルから取得できます。

AudioPolicyManager.cppファイルでは、システムが最初にconfigureファイルをvendor / etcディレクトリにロードし、次にconfigureファイルをsystem / etcディレクトリにロードすることがわかります。両方のロードでエラーが発生した場合、システムはデフォルトの構成ファイルをロードし、それをプライマリモジュールと名付けます

グローバル構成情報はloadGlobalConfig（root）関数を介して読み取られ、システム構成のすべてのオーディオインターフェイス（オーディオインターフェイスのロード）はloadHwModules（）関数を介してロードされます。audio_policy.confは複数のオーディオインターフェイスを定義できるため、この関数はloadHwModuleを呼び出します。周期的に（）して、各オーディオインターフェイスのパラメータ情報を解析します。Androidは、各オーディオインターフェイスパラメーターを記述するためにHwModuleクラスを定義し、入力および出力モード構成を記述するためにIOProfileクラスを定義します。

/system/etc/audio_policy.conf

/vendor/etc/audio_policy.conf

audio_moduleモジュールをロードします

audio_policy.conf構成ファイルを読み取ることにより、AudioPolicyManagerは、システムで現在サポートされているオーディオインターフェイス、接続されている入力デバイスと出力デバイス、およびデフォルトの出力デバイスを知ることができます。次に、これらのオーディオインターフェイスのハードウェアアブストラクションライブラリをロードする必要があります

AudioPolicyClientInterfaceは、オーディオインターフェイスハードウェアアブストラクションライブラリをロードするためのインターフェイス関数を提供します。AudioPolicyCompatClientは、プロキシaudio_policy_service_opsを介してAudioPolicyClientInterfaceインターフェイスを実装します。

AudioPolicyCompatClientはオーディオモジュールのロードをaudio_policy_service_opsに転送し、AudioPolicyServiceはそれをAudioFlingerに転送します

AudioPolicyManagerBaseが構築されると、ユーザーが提供したaudio_policy.confに従って、システム内のオーディオインターフェイス（primary、a2dp、usb）が分析され、AudioFlinger :: loadHwModuleを介して各オーディオインターフェイスに対応するライブラリファイルが読み込まれます。そしてそれらを順番に開きます出力（openOutput）と入力（openInput）

オーディオ出力を開くときは、audio_stream_outチャネルを作成し、AudioStreamOutオブジェクトを作成して、新しいPlaybackThread再生スレッドを作成します。

オーディオ入力を開くときは、audio_stream_inチャネルを作成し、AudioStreamInオブジェクトを作成して、RecordThread録音スレッドを作成します。

audio_policy.confファイルは、2つのオーディオ構成情報を定義します

現在のシステムでサポートされているオーディオ入力および出力デバイスとデフォルトの入力および出力デバイスは、global_configuration構成アイテムを介して設定されます。3種類のオーディオデバイス情報がglobal_configurationで定義されています。

attach_output_devices：接続された出力デバイス

default_output_device：デフォルトの出力デバイス

attach_input_devices：接続された入力デバイス

システムでサポートされているオーディオインターフェイス情報

audio_policy.confは、primary、a2dp、usbなど、システムでサポートされているすべてのオーディオインターフェイスパラメータ情報を定義します。

各オーディオインターフェイスには入力と出力が含まれ、各入力と出力には複数の入力と出力の構成が含まれ、各入力と出力の構成は複数のオーディオデバイスをサポートします。AudioPolicyManagerBaseは最初に/vendor/etc/audio_policy.confをロードし、ファイルが存在しない場合は/system/etc/audio_policy.confをロードします

audio_policy.confは、同時に複数のオーディオインターフェイスを定義し、各オーディオインターフェイスには複数の出力と入力が含まれ、各出力と入力は同時に複数の入力モードと出力モードをサポートし、各入力と出力モードは複数のデバイスをサポートします