Androidの基礎となる開発

Androidオーディオフレームワークノート-最初



Android Audio Framework Notes First



覚えておいてください、純粋な個人的なメモ、あなたはめまいを見るかもしれません

まず、オーディオデジタルの基本

この本を見て、次のように知識のポイントをリストしてください。



  • 音
    音波、音の周波数、ラウドネス、トーン、トーン。
    オーディオデバイスのチャネル
    中学校の教科書をめくらなければなりません。

  • 健全なデジタル化プロセス
    音源->マイク-> ADC（アナログ-デジタルコンバーター）、サンプリング、量子化-> [オプション]フィルタリング、効果音などの特殊処理->エンコーディング->
    サンプリングプロセスには、サンプリングレート、サンプリング深度、およびチャネルが含まれます。
    ナイキストのサンプリング法：本を参照してください。
    音量調整とウェーバーの法則：本を参照してください。
    これは大学の教科書に依存します：多数、アナログ回路、デジタル回路、マルチメディア技術。



  • オーディオコーデック形式
    元のPCMオーディオデータの圧縮およびエンコードとデコードの形式を指します。

  • オーディオファイル形式
    オーディオデータを保存するためのファイル保存形式を指します。

次に、アーキテクチャレベルマップ

オーディオフレームの全体像

2590816-b90abf504ed8f84c.pngPaste_Image.png
2590816-c3393679edf42890.pngPaste_Image.png
2590816-f26574b79c12168d.pngPaste_Image.png

第三に、コードと生成されたライブラリ

3-1、コードの場所

フレームワーク av メディア
フレームワーク av サービス audioflinger
フレームワーク/ベース/メディア/



オーディオシステムコード

  • 1、オーディオの Java セクション
    フレームワーク/ベース/メディア/ java / android / media
    フレームワーク/ベース/メディア/ jni
    内部の一部であるframework.jarを生成します。

Audioに関連付けられているJavaパッケージはandroid.mediaで、主にAudioManagerとAudioシステムのいくつかのクラスが含まれています。
次のような2セットのAPIを提供します。
AudioTrack.java/AudioRecord.javaは、より独創的で、柔軟性があり、利便性が低くなっています。
MediaPlayer / MediaRecordには、コーデック、ファイル形式のサポートが含まれており、より簡単です。

  • 2、AudioのJNI部分

フレームワーク/ベース/コア/ jni
AudioのJNIの一部であるライブラリlibandroid_runtime.soを生成します。この部分は、オーディオローカルフレームワークへの呼び出しの詳細を保護します。簡略化すると、JAVAインターフェイスのローカルトランジットに相当します。ローカルインターフェイス変換は、もともとJNI関数の1つです。

  • 3、オーディオのフレームワーク部分

全体の場所は、マルチメディア関連のframeworks av mediaです。

3.1
libmedia.so
一部、オーディオシステムのコアフレームワーク、オーディオまで
JNIセクションは、AudioのJava部分へのインターフェースを間接的に提供するインターフェースを提供します。
フレームワーク av media libmedia
フレームワーク av include media
古いバージョン：
フレームワーク/ベース/インクルード/メディア/
フレームワーク/ベース/メディア/ libmedia /

この部分は、オーディオシステムのコアフレームワークを実装し、IAudioFlingerクラスインターフェイスを提供するライブラリlibmedia.soにコンパイルされます。このクラスでは、サウンドの再生と録音のために、IAudioTrackとIAudioRecorderの2つのインターフェイスを取得できます。
AudioTrackとAudioRecorder
IAudioTrackとIAudioRecorderをそれぞれ呼び出すことによって呼び出されます。 IAudioFlinger.h、IAudioTrack.h、およびIAudioRecorder.hの3つのインターフェイスは、下位層を介して実装されます。 AudioSystem.h、AudioTrack.h、およびAudioRecorder.hは、上位層に提供されるインターフェースであり、Java層へのインターフェースを提供するためにローカルプログラムとJNIの両方に使用されます。機能的な観点から、
AudioSystem
はオーディオシステムの統合管理機能を担当し、AudioTrackとAudioRecorderはオーディオデータの出力と入力、つまり再生と録音を担当します。もう1つのインターフェイスはIAudioFlingerClientで、これはIAudioFlingerに登録されたリスナーとして機能します。これは、コールバック関数を使用してIAudioFlingerランタイム情報を取得するのと同じです。

MediaScanner
メディアファイルのスキャンを担当します。

3.2mediaplayerservice
フレームワーク av media libmediaplayerservice
libmediaplayerservice.soを生成します

上位層のAPIの1つのサーバー実装、つまりMediaPlayer / MediaRecordのサーバー実装。
実際、オーディオ部分はlibmedia.soのAudioTrack / AudioRecordによって実装されています。
さらに、内部には、エンコード、デコード、ファイル形式、ビデオの再生/記録などが含まれます。
ビデオ再生セクションには、StagefrightPlayer / Recorder、NuPlayer、openCoreの早期使用などのいくつかのプレーヤーがあります。

3.3メディアサーバー、メディアサービスプロセス
フレームワーク av media mediaserver
すべてのメディアサーバーコードスレッドは、このプロセスで開始されます
/ system / bin / mediaserverを生成します

3.4libeffectsサウンドパート
フレームワーク av media libeffects
生成された
/system/lib/libeffects.so//総入口
/ system / lib / soundfx ///特定の効果音

  • 4、ローカルサービス
    セクション、オーディオサービスプロセス

4.1オーディオフリンガー
フレームワーク av services audioflinger
古いバージョン
フレームワーク/ベース/ライブラリ/オーディオフリンガー
この部分は、オーディオシステムのローカルサービス部分であるライブラリlibaudioflinger.soにコンパイルされます。 （実際、libaudioresampler.soもあります）

4.2オーディオポリシーローカルフレームワークサービスパート
フレームワーク av services audiopolicy
libaudiopolicymanager.so、libaudiopolicyservice.so、libaudiopolicymanagerdefault.soを生成します

オーディオ戦略のためのローカルサービスフレームワーク、
インターフェースをアップし、AudioSystem.cpp / AudioService.cpp / AudioManager.cppなどへのインターフェースを提供します。//少なくともAudioSystem.cppはAudioPolicyService.cppをパッケージ化します。
オーディオポリシーを実装するために、HALレイヤーを介してライブラリに呼び出されます。デフォルトの実装はaudio_policy.default.soであり、最後に具象実装クラスAudioPolicyManagerBaseが呼び出されます。
audio_policy.default.soに転送した後に得られた結果を含む、戦略的処理のみを担当します。
特定のオーディオ処理トランザクションはAudioFlingerに送られ、最終的に実行されます。
重要な点は、AudioPolicyManagerBaseがaudio_policy.confとaudio_effects.confをロードして、オーディオデバイスとサウンドエフェクトに構成可能なポリシーを実装することです。したがって、通常は構成を変更するだけで、AudioManagerBaseを変更するメーカーはほとんどないはずです。

  • 5、オーディオのハードウェアアブストラクションレイヤーインターフェイス
    オーディオHALのAndroidフレームワーク定義とレガシー実装
    ハードウェア libhardware モジュール
    ハードウェア/ libhardware_legacy / include / hardware /

HALベンダー実装コード
デバイスサムスンマンタオーディオ
device asus grouper audio

1. Audioは、JNIとJavaを使用して、上位層へのインターフェースを提供します。 JNI部分は、libmediaライブラリによって提供されるインターフェースを呼び出すことによって実装されます。
2、オーディオローカルフレームワーククラスはlibmedia.soの一部です。これらのオーディオフレームワーククラスは、基盤となるローカルコードによって実装される上位層へのインターフェイスを提供します。
3. AudioFlingerはlibmeidaのインターフェースを継承し、実装ライブラリlibaudiofilnger.soを提供します。コンテンツのこの部分には、独自の外部ヘッダーファイルがありません。上位層はlibmediaのインターフェースのみを呼び出しますが、実際のコンテンツはlibaudioflinger.soです。
4. Audioのハードウェアアブストラクションレイヤーは、AudioFlingerが呼び出すハードウェアへのインターフェイスを提供します。オーディオのハードウェアアブストラクションレイヤーは、実際には、各プラットフォームの開発中に個別に焦点を合わせて完了する必要がある部分です。
Androidのオーディオシステムでは、上位層と下位層の両方が管理クラスと出力入力を使用して、オーディオシステム全体を表します。出力と入力はデータチャネルを担当します。さまざまなレベルの間に対応関係があります。

2590816-f1d8194e4083f244.pngPaste_Image.png
  • 6、関連する基礎となるオーディオアーキテクチャ**
    system core include system
    外部/ tinyalsa
    またはalsaバージョン
    external / alsa-lib
    external / alsa-utils

4.1以降、基本的にtinyalsaを使用します

  • 7、その他
    7.1オーディオ定数の定義
    system core include system audio.h
    AudioSystem.java
    多くの定数は一貫しています。1つはネイティブ参照用で、もう1つはJava参照用です。

7.2ネイティブレイヤーのパブリックヘッダーファイルの定義
system core include system audio.h
このヘッダーファイルは非常に重要です。その定数定義のいくつかは上から下まで一貫している必要があるため、JavaレイヤーのAudioSystem.javaはこれと一貫しています。
audio.hは、ネイティブレイヤーのすべてのモジュールへの参照です。
JNIレイヤーのcppファイル、libaudioflinger.so、audio.xxx.so、audio_policy.soなどが含まれます。
（もちろん、ナンセンスですが、alsalibライブラリはそうではありません。ヘッダーファイルは、alsaアーキテクチャに合わせて設計されたalsa標準ヘッダーファイルであることを示しています。
統合されたalsalibインターフェースを提供しますが、AndroidのHALレイヤーはalsalibヘッダーファイルを使用する必要があります。 ）。

オーディオライブラリとコードの場所

libmedia.so
フレームワーク av media libmedia
オーディオサービスフレームワークコード
libaudioflinger.so ****
フレームワーク av サービス audioflinger
HALフレームワークコード
ハードウェア libhardware モジュール
HALの公式の標準実装コード？
HALベンダー実装コード
デバイスサムスンマンタオーディオ

device asus grouper audio
基礎となるオーディオアーキテクチャ関連
system core include system
外部/ tinyalsa

オーディオライブラリと小さなファイルの場所

オーディオサービスフレームワークライブラリ：** libaudioflinger.so libmedia.so
通常、マシンの/ system / libディレクトリに配置されます。
オーディオデバイスHALライブラリ：audio_xxx.so
ハードウェアベンダーによって実装およびカスタマイズされています。 audio_policy.confの構成は、これらの実装に対応しています。
これらのライブラリは、オーディオHALレイヤーフレームワークの実装です。オーディオHALフレームワークは、hardware libhardware include hardware audio.hで定義されています。
特定の実装コードはベンダーから提供される必要があり、googleのデフォルトの実装は次のとおりです。 ？
によって生成されるライブラリには、通常、audio_primary.so、audio_a2dp.soなどがあります。
通常、マシンの/ system / lib / hwまたはvendor / lib / hwディレクトリに配置されます。

関連プロセス：

システムサーバー：AudioFlinger、AudioPolicyServiceなど、つまりオーディオサーバー
APPプロセス：AudioTrack、AudioRecoderなど、オーディオクライアント

Andorid.process.media：マルチメディア管理クラスのプロセス

3-2、ランタイムモデル、プロセススレッドの関係

第四に、Linuxのオーディオフレームワーク

  • Linuxネイティブの3種類：OSS、ALSA、TinyAlsa。
    現在、AndroidはTinyALSAオーディオライブラリを使用しています。 TinyAlsaは、実際にはLinuxアプリケーション層にあるオーディオライブラリです。これは、ALSAドライバーアーキテクチャに依存しています。基盤となるドライバーは、ALSAドライバーアーキテクチャを使用する必要があります。これは、AndroidがLinuxアプリケーション層のALSAアーキテクチャを置き換えるために使用する大規模で複雑なライブラリであり、より適切なものになっています。組み込みデバイス用。
    とにかく、それはLinuxアプリケーション層のための統一された便利なオーディオインターフェースを提供します。 pcm_read（）/ pcm_write（）など
    Linuxカーネルでは、ALSAオーディオアーキテクチャが使用されます。ドライバフレームワークは、ALSAフレームワークインターフェイスに従って記述されています。そのポートを駆動するのはSOCベンダーです。

参照：
ALSAの公式ドキュメント
http://blog.csdn.net/DroidPhone/article/category/1118446
さまざまなオーディオハードウェアアクセスマップ
http://blog.csdn.net/qianjin0703/article/details/6387662
完全な作品です（一部は上記の記事から）
http://www.360doc.com/content/14/0414/10/97538_368733041.shtml

  • サポートされているオーディオデバイスのリスト（出力）
    ハードウェアオーディオ出力デバイスのタイプ、本を参照

HALレイヤーでは、オーディオデバイスはaudio_hw_device_t構造で表され、サポートされる出力タイプは次のとおりです。 audio_policy.conf 指定。
上位層がOUTチャネルを開きたい場合、一致するタイプを探して開きます。

  • Androidがサポートするメディア形式
    本を見る
    録音可能なオーディオソース
    記録可能なビデオソース
    カメラまたはデフォルト

5、詳細なコード

5-1、クラスの使用

AudioRecord.cpp / AudioRecord.java（前者のJAVAパッケージのみ）

AudioRecord.javaを使用する手順

  1. データストリームを作成します。
  2. 必要な最小記録バッファーサイズをgetMinBufferSizeメソッドで取得できるAudioRecordオブジェクトを作成します。バッファ容量が小さすぎると、オブジェクトの構築が失敗します。
  3. AudioRecordオブジェクトがサウンドデータを書き込むために使用するバッファサイズ以上のバッファを初期化します。
  4. 録音を開始。
  5. AudioRecordから初期化バッファにサウンドデータを読み取り、バッファ内のデータをデータストリームにインポートします。
  6. 録音を停止します。
  7. データストリームをオフにします。

AudioRecord.cppに対応するコード：

AudioRecord pAudioRecord = new android::AudioRecord() pAudioRecord->set( inputSource, sampleRateInHz, audioFormat, channelConfig, minFrameCount, AudioRecordCallback, NULL, 0, true, 0, android::AudioRecord::TRANSFER_DEFAULT, AUDIO_INPUT_FLAG_NONE, //AUDIO_INPUT_FLAG_NONE //audio_input_flags_t flags) NULL )

または

AudioRecord recordInstance = new AudioRecord( MediaRecorder.AudioSource.REMOTE_SUBMIX, frequency, AudioFormat.CHANNEL_IN_MONO, audioEncoding, bufferSize) recordInstance.startRecording()

// AudioRecod.cppのset（）関数にはいくつかの制限があるようです：

AudioRecod.set(){ If (inputSource == AUDIO_SOURCE_DEFAULT) {** //The default recording source is the MIC inputSource = AUDIO_SOURCE_MIC } if (sampleRate == 0) { ALOGE('Invalid sample rate %u', sampleRate) return BAD_VALUE } // these below should probably come from the audioFlinger too... If (format == AUDIO_FORMAT_DEFAULT) {**//Default data format, ie **AUDIO_FORMAT_PCM_16_BIT format = AUDIO_FORMAT_PCM_16_BIT } // Temporary restriction: AudioFlinger currently supports 16-bit PCM only If (format != AUDIO_FORMAT_PCM_16_BIT) {**//data format, it can only be **AUDIO_FORMAT_PCM_16_BIT ALOGE('Format %#x is not supported', format) return BAD_VALUE } }

いくつかの問題：
オーディオソース、入力または出力は何ですか？シングルチャネルとデュアルチャネル？音源と後者の2つのパラメータはどのように一致しますか？

その中で：
オーディオソースの録音* CPPは、JAVAレイヤーの定義と一致しています。以下のような音源があります。
要約すると、それはMIC、コールインおよびコールアウト、REMOTE_SUBMIX、CAMCORDER（録音に使用されるマイクであり、通常は独立しておらず、最終的にはデフォルトのMICです）です。
そのため、メインデバイスがミキシングされた後のサウンド出力など、まだ録音されていないものがあります。これには、考えられるあらゆる種類の音楽、着信音、通知、その他のサウンドが含まれます。
つまり、Androidが上位アプリケーションに提供するインターフェースは、MICの録音、通話の録音、およびビデオの録画のみが可能であるということです。録音シーンの残りの部分は、与えないでください。
typedef列挙型{
AUDIO_SOURCE_DEFAULT = 0、
AUDIO_SOURCE_MIC = 1、
AUDIO_SOURCE_VOICE_UPLINK = 2、
AUDIO_SOURCE_VOICE_DOWNLINK = 3、
AUDIO_SOURCE_VOICE_CALL = 4、
AUDIO_SOURCE_CAMCORDER = 5、
AUDIO_SOURCE_VOICE_RECOGNITION = 6、
AUDIO_SOURCE_VOICE_COMMUNICATION = 7、
AUDIO_SOURCE_REMOTE_SUBMIX = 8、/ リモートで提示されるミックスのソース。 /
/ リモートプレゼンテーションの例はWifiディスプレイです /
/ テレビに取り付けられたドングルを使用できる場所 /
/ このオーディオソースによってキャプチャされたミックスを再生します。 /
AUDIO_SOURCE_CNT、
AUDIO_SOURCE_MAX = AUDIO_SOURCE_CNT-1、
AUDIO_SOURCE_HOTWORD = 1999、/ 優先度の低い、プリエンプティブなオーディオソース
バックグラウンドソフトウェアのホットワード検出用。
AUDIO_SOURCE_VOICE_RECOGNITIONと同じチューニング。
フレームワークの内部でのみ使用されます。露出していない
オーディオHALで。 * /
} audio_source_t

チャネル：
入力と出力を定義します。これらは、シングル、デュアル、フロントとバック、それぞれ5.1チャンネル、7.1チャンネルを定義し、次に、より使いやすいサウンドのさまざまな組み合わせを定義します。道路。
基礎となる実装がどのように実装されているかに関係なく、チャネルに対する人々の理解を定義することを意味します。
明らかに、一部のソースでは、5.1チャンネルを使用することは不可能です。そのため、効果的なマッチングの問題がまだあります。

オーディオトラック

本を見て、

  • 簡単に言えば、再生プロセスは次のとおりです。
    Java側が呼び出しを開始し、MediaPlayerがMediaPlayerServiceに移動し、対応するデコードツールが呼び出されてAudioTrackがデコードおよび作成されます。出力されるすべてのAudioTrackは、AudioFlinger :: AudioMixerで合成され、AudioHALを介して合成されます（AudioHardwareInterfaceの実際の実装は、再生のために実際のハードウェアに渡されます。

AudioTrack.java-> AudioTrack.cppを直接使用する場合、後続のプロセスはAudioFlingerに直接移動し、その後ダウンします。
AudioTrackの概要
この分析を通して、私は次の点を感じています。
l AudioTrackの動作原理、特にデータ転送は、共有メモリ、クロスプロセス同期などを含むより詳細な分析を行っており、多くの疑問を説明することもできます。
l最も重要な仕事はAudioFlingerで行われているようです。 AudioTrackの導入により、AudioFlingerのその後の詳細な分析のためのエントリポイントを提供します。
動作原理とプロセスさて、もう一度言いましょう。 JAVAレイヤーは、上部の例を示しています。言うことは本当に何もありません。
l AudioTrackは新しく、一連の情報を設定します。同時に、Binderメカニズムを介してAudioFlingerのもう一方の端を呼び出し、IAudioTrackオブジェクトを取得し、それを介してAudioFlingerと対話します。
l start関数を呼び出した後、コールバック処理を実行するスレッドが開始されます。コードにはデータコピーのコールバックがありますが、JNIレイヤーのコールバック関数は実際にはデータを内部に書き込みません。 、あなたはただ書き込みを読む必要があります。
lユーザーは何度も何度も書き込む必要があり、AudioTrackはデータmemcpyを共有バッファーに入れるだけです。
lご想像のとおり、AudioFlingerには、オーディオデバイスへのmemcpyデータにスレッドが必要です。お待ちしております。

5-2、関連するクラスの説明

  • マルチメディア管理
    MediaScannerService
    3つのブロードキャストのスキャンプロセス
    3つのブロードキャストのスキャンパス
    MediaProvider
    MediaReceiver
    MediaStore

  • 再生と記録、JAVAレイヤー
    MediaPlayer
    オーディオおよびビデオマルチメディアを再生するためのアプリ層にパッケージ化されています。
    状態遷移図
    フレーム
    MediaRecorder
    オーディオおよびビデオマルチメディアクラスを記録するために、Appレイヤーにパッケージ化されています。とてもフレンドリーなパッケージで、録音、エンコード、ストレージなどのすべての詳細がカプセル化されています。 ****
    状態遷移図
    フレーム

AudioRecord.java
APP層のオーディオ録音クラスをカプセル化し、非常に使いやすく簡素化されたインターフェイスとコールフローを提供します。
JNIを介してAudioRecord.cpp関数クラスの特定のトランザクション操作をカプセル化します。
JNIファイル：android_media_AudioRecord.cpp

AudioTrack.java
AudioTrack.cpp Javaレイヤーラッパークラス、オーディオの再生

AudioTrack.cpp
オーディオデータの再生に使用されます。
データ転送モードには次の2種類があります。
アクティブプッシュとプル
2種類のデータ操作モードに分けられます。
静的
着信音、通知、効果音などの少量のデータ、短時間。データは一度配信されてから再生されます。
ストリーム
音楽などの大量のデータ、長時間。データは共有メモリを介して送信され、再生のためにストリーミングされます。 ****

AudioRecord.cpp
録音機能クラス、クライアント側、サーバーが実際に録音作業を行っています。
AudioRecord：**** AudioRecordThread

  • フレームレイヤー
    MediaPlayerService
    APP層MediaPlayerとMediaRecorderのサービス層、再生と記録操作のサービスクラス、実際の再生と操作の実行クラスと関数クラスが呼び出されます。
    MediaRecoderClient
    クライアントと MediaRecorde **** r 対応するサーバーアシスタントクラス、マルチインスタンス、1対1の対応。
    StageFrightRecoder
    ダイレクトレコーダー、記録操作の実行クラス。
    クライアント
    クライアントと MediaPlaye **** r 対応するサーバーアシスタントクラス、マルチインスタンス、1対1の対応。 ****
    さまざまなプレイヤークラス
    タイプは、NU_PLAYER、PV_PLAYERなどです。

AudioSystem.cpp
ラッパークラス、AudioTrack / AudioRecordクラスAudioPolicyService、AudioFlingerを分離します。
したがって、後者のポリシークラスとオーディオサービスクラスの変更を分離するための統合インターフェイスを提供します。
トランジットコールであり、AudioPolicyServiceまたはAudioFlingerに渡されるその実装を参照してください。

AudioService

AudioFlinger
AudioFlinger（以下、AFと呼びます）は、オーディオシステム全体の中核であり難しさです。 Androidシステムのオーディオハブとして、HALによってアクティブ化されるシステムサービスでもあります（HALはオーディオデバイスの管理に使用されます）。 AudioFlingerはAudioHardwareにアクセスして、オーディオデータを出力し、オーディオパラメータを制御します。
AudioFlingerは、オーディオデバイスとの通信方法、既存のシステムでオーディオデバイスを維持する方法、複数のオーディオストリームのミキシングを処理する方法など、戦略の実行者です。これは、AudioFlingerによって実行されます。
AudioFlinger-> PlaybackThread
オーディオデータ作業の再生を担当するスレッドクラス
** AudioFlinger-> MixerThread
混合作業を担当するスレッドクラス
** AudioFlinger-> MixerThread-> AudioMixer
特定のトランザクションの混合を担当する関数クラス

@AudioFlingerの作成と初期化
本を作成し、
TODO：初期化

@オーディオ機器の管理
AudioPolicyManagerBaseコンストラクター、AudioPolicyManagerBase-> loadAudioPolicyConfig、audio_policy.confのロードと解析、使用可能なオーディオデバイスの検索-> AudioFlingerロードモジュール

AudioPolicyService
AudioPolicyServiceは、オーディオインターフェイスデバイスをいつ開くか、どの種類のストリームタイプのオーディオがどのデバイスに対応するかなどのポリシーメーカーです。 AudioFlingerは、オーディオデバイスとの通信方法、既存のシステムでオーディオ機器を維持する方法、複数のオーディオストリームのミキシングを処理する方法など、戦略の実行者です。 AudioPolicyServiceは、AudioFlingerがユーザー構成に基づいてデバイスインターフェイスをロードするようにガイドし、ルーティング機能として機能します。

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

#define AUDIO_POLICY_VENDOR_CONFIG_FILE '/vendor/etc/audio_policy.conf' #define AUDIO_POLICY_CONFIG_FILE '/system/etc/audio_policy.conf'

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

TODO：これらの構成、理由、コードで対応するaudio_hw_device_tをロード、処理、生成する方法、上位層でこの情報を使用する方法、なぜそれを使用するのか。
HALレイヤーでは、オーディオデバイスはaudio_hw_device_t構造で表され、サポートされる出力タイプは次のとおりです。 audio_policy.conf 指定。
上位層がOUTチャネルを開きたい場合、一致するタイプを探して開きます。

audio_effects.conf
サウンドプロファイル、最終的なマシン、通常は次の場所に保存されます。
/system/etc/audio_effects.conf
/vendor/etc/audio_effects.conf

struct default_audio_policy { struct audio_policy policy struct audio_policy_service_ops *aps_ops void *service }

AudioPolicyManagerBase
それは何のため？
初期化プロセス： AudioPolicyServiceコンストラクト： rc = mpAudioPolicyDev-> create_audio_policy（mpAudioPolicyDev、＆aps_ops、this、
＆mpAudioPolicy）-> ....-> AudioPolicyManagerBase

@ストラテジークラスルーティング関数？
ルーティング機能とは何ですか？ルーティングプロセスとは何ですか？
audio.hの出力デバイスタイプは何ですか？ audio_policy.confとの関係は何ですか？
ポリシークラスはこれらの定義と構成をどのように使用しますか？
最後に、適切な出力デバイスを選択する方法、つまりaudio_deivceクラスに対応する方法で、対応する出力チャネル、つまりaudio_deivce-> openOutputStreamを見つけます。どちらを開くのですか？
Androidの上位層で定義されているサウンドストリームタイプはどのように対応していますか？
**上記のlibaudiopolicy.soの後の、AudioPolicyManagerBase.getDevicesForStream（）-> ****。getDeviceForStrategy（）（AudioSystem.java/AudioSystemLegacy.h）への呼び出しは、オーディオデバイスで定義されたサウンドストリームタイプであると言われています。 audio.hで定義されている型変換プロセス。