

Advanced Linux Sound Architecture ( ALSA ) は、サウンドカードデバイスドライバ用のアプリケーションプログラミングインターフェイス(API)を提供する、 Linux カーネルの一部であるソフトウェアフレームワークです。
ALSAプロジェクトの初期目標には、サウンドカードハードウェアの自動構成と、システム内の複数のサウンドデバイスの適切な処理が含まれていました。ALSAはGPL-2.0以降およびLGPL-2.1以降でリリースされています。[ 5 ]
Linuxでは、sndio、PulseAudio、JACK(低遅延のプロ仕様オーディオ編集およびミキシング)、PipeWireなどのサウンドサーバーや、OpenAL、SDLオーディオなどの高レベルAPIは、ALSAとそのサウンドカードデバイスドライバ上で動作します。ALSAは、以前のLinux版Open Sound System(OSS)の後継です。
ALSA の開発プロジェクトは Jaroslav Kysela が主導し、Gravis Ultrasoundサウンドカード用の Linux デバイスドライバをベースにしていました。1998 年に開始され、2002 年に 2.5 開発シリーズ (2.5.4–2.5.5) に導入されるまで、Linux カーネルとは別に開発されていました。[ 6 ]
バージョン2.6では、以前のシステムであるOpen Sound System(OSS)がデフォルトで置き換えられました(ただし、下位互換性レイヤーは存在します)。[ 7 ]
ALSAはOSSよりもAPIが大きく複雑なため、ALSAをサウンド技術として使用するアプリケーションの開発はより困難になる場合があります。ALSAはOSSエミュレーションレイヤーを提供するように構成できますが、そのような機能は現在利用できないか、多くのLinuxディストリビューションではデフォルトでインストールされていません。
ALSAは、その構想当時、オープンソースソフトウェア(OSS)ではサポートされていなかったいくつかの機能を備えて設計されました。
ALSAは、サウンドデバイスドライバに加えて、カーネルドライバとの直接的なやり取りのために提供されるインターフェースよりも高レベルのインターフェースを介してドライバ機能を利用したいアプリケーション開発者向けに、ユーザー空間ライブラリを同梱しています。ハードウェアの機能を直接反映しようとするカーネルAPIとは異なり、ALSAのユーザー空間ライブラリは、異なる基盤となるハードウェア要素間で可能な限り標準化された抽象化を提供します。この目標は、ソフトウェアプラグインを使用することによって部分的に達成されます。たとえば、多くの最新のサウンドカードや内蔵サウンドチップには「マスターボリューム」コントロールがありません。代わりに、これらのデバイスに対して、ユーザー空間ライブラリは「softvol」プラグインを使用したソフトウェアボリュームコントロールを提供し、通常のアプリケーションソフトウェアは、そのようなコントロールが基盤となるハードウェアによって実装されているか、あるいは基盤となるハードウェアのソフトウェアエミュレーションによって実装されているかを気にする必要はありません。
Linuxカーネル内部のソフトウェアフレームワークに加えて、ALSAプロジェクトはコマンドラインツール[ 8 ] [ 9 ] [ 10 ]とユーティリティ[ 11 ]alsactl [ 12 ] [ 13 ]amixer、およびncursesベースのTUIも提供しています。arecord/aplayalsamixer
また、サードパーティの開発者によってプログラムされた GUI もあり、例えば GNOME-ALSAmixer [ 14 ] ( GTKを使用)、Kmix [ 14 ] XFCE4-mixer、LXpanel、QasHctl、QasMixer、Pavucontrol、AconnectGUI [ 15 ] tapiir [ 15 ] polarbear [ 15 ] ALSAmixerGUI [ 16 ] ( FLTKを使用)、ZynAddSubFX、Yoshimi などがあります。
通常、ALSAは0から7までの番号が振られた最大8枚のカードをサポートします。各カードは、入出力が可能な物理的または論理的なカーネルデバイスです。さらに、各カードは「 Headset」や「ICH 9 」などの説明文字列であるIDによってアドレス指定することもできます。
カードには、0から始まる番号のデバイスがあります。デバイスは、コンピュータからサウンドを出力する再生タイプ、またはキャプチャ、コントロール、タイマー、シーケンサーなどの他のタイプのいずれかです。[ 20 ]特定のデバイスが指定されていない場合は、デバイス番号0がデフォルトで使用されます。
デバイスには、0から始まる番号のサブデバイスが存在する場合があります。サブデバイスは、スピーカーペアなど、デバイスに関連する何らかの音響エンドポイントを表します。サブデバイスが指定されていない場合、またはサブデバイス番号-1が指定されている場合は、利用可能な任意のサブデバイスが使用されます。
カードのインターフェースは、カードにアクセスするためのALSAプロトコルの説明です。使用可能なインターフェースには、hw、plughw、default、plug:dmixなどがあります。hwインターフェースはカーネルデバイスへの直接アクセスを提供しますが、ソフトウェアミキシングやストリーム適応はサポートしていません。plughwとdefaultは、hwインターフェースではエラーが発生する場合でも音声出力を有効にします。
アプリケーションは通常、前述のすべての仕様をデバイス文字列に組み合わせることでサウンド出力を記述します。デバイス文字列は、以下のいずれかの形式をとります(大文字と小文字は区別されます)。
ALSAストリームは音声を表すデータフローであり、最も一般的なストリーム形式はPCMです。PCMは、ハードウェアの特性やパラメータに一致するように生成する必要があります。これには以下が含まれます。
ALSAシステムオンチップ(ASoC)レイヤーは、システムオンチップ(SoC)設計を使用する組み込みシステム上でALSAをより良くサポートすることを目的としています。[ 21 ]
Open Sound Systemバージョン 4 は ALSA をエミュレートできます。[ 22 ]
QNX はALSA から派生したサウンド システムを使用していますが、ALSA と直接互換性はありません。ヘッダー ファイルとライブラリ名は ALSA 名と同じ「asound」です。[ 23 ] ALSA API は、QNX カーネルでは許可されていない方法でioctl()呼び出しを使用します。 [ 24 ]
このページには私のプロジェクトのリストが含まれますが、まずいくつかのことを整理する必要があります。今のところ、次のリンクを使用するか、ftp を参照してください: tapiir、alsamixergui、aconnectgui、polarbear
alsamixerguiは、alsamixer用のFLTKベースのフロントエンドです。alsamixerのソースコードの上に直接記述されており、元のソースコードはそのまま残し、ifdefをいくつか追加し、GUI部分への呼び出しをいくつか追加しただけなので、まったく同じ機能を提供しますが、グラフィカルユーザーインターフェースを備えています。(研究者、1999-2010)
このサイトが存続している理由のいくつかとしては、公式ALSAサイトの誰もこのサイトに何も貢献したことがないこと(公式サイトが存在する前に、このサイトは公式wikiよりかなり前から存在している)、誰も公式にまたは正式に統合を提案していないこと、他の誰も統合を支援することに真剣な関心を示していないこと、そして最も重要なのは、このサイトが長い間存在しているため、外部サイトからの参照元やGoogleヒットが相当数直接このサイトに流入していることなどが挙げられます。