オーディオサブシステムの理解方法
私はすでに多くのUbuntuバージョンを使用しており、5.10から始めました。しかし、オーディオサブシステムに問題があったためです。ハードウェアに関係なく、現在2台のコンピューターがあり、両方に問題があります。ラップトップでは、スピーカーチャネルをトリガーしてサウンドを取得する必要があります。デスクトップでは、Ubuntu 10.04/32ビットでもサウンドを機能させるのに手間がかかりました。実際、それは偶然にうまくいきました。入力音質はまだ本当に悪いですが。
今、別のパーティションUbuntu 10.04/64bitにインストールしましたが、高レベルのソフトウェアスタックは問題ないようですが、サウンドは動作しません。 Pavucontrolはサウンドを登録し、正しいハードウェアを表示しますが、音が聞こえません。 （他の出力ジャック、フロントパネル、および他のチャンネルを除いて、奇妙な音が聞こえます。）
私の質問は、どうすればUbuntuのサウンドシステムを理解し、そのような問題を自分でデバッグできるようになりますか？
そして別の質問：なぜUbuntuのオーディオはそれほど複雑なのですか？これらの問題については、オンラインフォーラムに何万ものスレッドが存在する必要があります。また、成功した解決策がないことを示す数十のスレッドを既に見ています。一方、何百もの問題解決ガイドがなければなりませんが、これらのどれもそれをすべてカバーすることはできません...
ありがとう、フィリップ
UbuntuでPCオーディオスタックを維持している間、デスクトップアスペクトのデバッグに関する プレゼンテーションをいくつか行いました 。 thisone 最も穏やかまたは有益です。問題の要点は、エゴ（別名「技術的プライド」）、政治、所有権の衝突（別名「メンテナーなし」）の組み合わせにより、過去10年（および数年）にAPIの泥沼が発生したことです。あちこちで多くの誤った仮定がなされています。 私たちは多くの矛盾と貧弱な仮定を排除し続けています。特にUbuntuには、 開発者Launchpad group があります。彼らはすべてCanonicalの従業員であり、追加の制限がある可能性があるため、他のメンバーの代わりに話すことはできませんが、Launchpadから私に連絡してください。スケジュールが一致するので、個別にデバッグプロセスをご案内させていただきます。
PulseAudioには、従来のアプリケーションとは根本的に異なる方法で、オーディオハードウェアのより厳しい要件があることに注意することが絶対に重要です。これらの要件は、カーネル、サウンドドライバー、および基礎となるライブラリでの不十分な前提を引き続き明らかにします。長い間、「壊れたサウンドを修正する」ための人々の「解決策」は、PulseAudioを削除することで構成されていました。PulseAudioは、カーネル、サウンドドライバー、基礎となるライブラリ自体の壊れた側面を効果的にスキップします。したがって、「サウンドを戻す」間、問題は残ります。最終的には、問題を完全に修正することをお勧めします。
まとめると、系統的なオーディオデバッグには2つの一般的なアプローチがあります。 Bansheeなどのアプリケーションレベルで開始するか、ハードウェアレベルで開始します。一貫性を保つために、前者を「高レベル」、つまりスタックの上位、後者を「低レベル」、またはハードウェアに最も近いスタックの下位と呼びます。過去10年間のオーディオへの関与（デバイスドライバーの作成と保守からアプリケーション統合まで）により、OEMがLinux（カーネル）が回避しなければならないミスを繰り返してきたため、トラブルシューティングが最も楽です。 （または私たちの開発者が時々それを呼ぶとき、「ハックアラウンド」）。しかし、ハードウェアの人はソフトウェアの人よりも罪がありません。これらの問題には多くの根拠があります：BIOS、電源、マザーボードブリッジ、サウンドコントローラーとコーデック、カーネル、またはユーザースペース部分（ライブラリ、API、PulseAudio、アプリケーションなど）にあるかどうかは関係ありません）。最後に、問題は非常に簡単です：私たちはすべて、下位レベルおよび下位レベルからの範囲外の条件を十分に処理しません。
PCハードウェアレベルでは、 使用するコンポーネントを正確に特定することでデバッグを開始します 。最新のデスクトップオーディオハードウェアには、PCIサブシステム識別子とオーディオコーデックサブシステム識別子という2つの重要な情報があります。前者はlspci -nvで見つけることができます;オーディオサブシステムコード0401（ AC'97 ）または0403（ High Definition Audio ）を探します。ハードウェアにもよりますが、後者は [〜＃〜] alsa [〜＃〜] ドライバー自体が/proc/asound（開発者のデバッグスクリプトリンクするだけで、その情報収集の多くが自動化されます）。 同様の、同一の症状であっても、多くの場合、ハードウェアとソフトウェアの原因が異なることを認識し、覚えておくことが不可欠です。そのため、バグを修正する人にとっては、明確なバグレポートを作成するのが最も簡単です。そのため、Ubuntuには、ドライバーの問題にはubuntu-bug alsa-base、アプリケーションの問題にはubuntu-bug pulseaudioがあります。何が問題なのかわからない場合は、1つを選択するか、ubuntu-bugの音声症状を使用してください。とにかく、必要に応じて追加情報をリクエストします。
PCI SSIDは重要です。なぜなら、それはどのコンピューター製造元がどのコンポーネントをマザーボードに統合するかの記録であるためです。たとえば、IDT/Sigmatel、Realtek、Cirrus、Analog、Conexantオーディオコンポーネントのさまざまな組み合わせを使用するDell、HP/Compaq、Acer、Samsung、Lenovoなどがよくあります。 Realtek 269を搭載したDellは、Realtek 269を搭載したHPと同じ動作をする必要はありません。
コーデックSSIDは、オーディオ機器メーカーの観点からは、PCI SSIDのアナログと見なすことができます。コーデックSSIDに関連付けられた情報を使用して、シリコンに統合されているリビジョンを見つけることができます。
残念ながら、ここから問題が始まります。 BIOSが正常であると仮定すると（Linuxオーディオに大混乱をもたらす壊れたBIOSが多数あるため、これはかなり盲目的な仮定です）、PCI SSIDが誤って再利用されることがあります。そのような状況では、コーデックSSIDに基づいてドライバーに特定の癖を適用することが私たちの頼みの綱です。残念ながら、コーデックSSIDが誤って再利用される場合があります。このような状況では、ドライバーを再初期化するために、盲目的に総当たり攻撃を試みることに加えて、コーデックの特定のリビジョンを調べる必要があります。
最新の機器のほとんどでは、従来の「このハードコードされた定義を使用する」アプローチを使用する代わりに、BIOSを信頼する傾向があります。状況によっては、コーデックをエミュレートするツールを使用して、どのピン定義がどの機能を実行するかを見つける必要があります。ジャックセンスを処理するためのドライバーにない機能、つまり、ヘッドフォンを（取り外し）挿入したときに内部スピーカーを（非）ミュートする、 は、この方法で簡単に修正 できます。
基盤となるハードウェアが壊れておらず、サウンドドライバーにパッチを適用する必要がないと判断したら、ユーザー空間レイヤー、つまりalsa-lib、alsa-plugins、およびpulseaudio。問題の大部分は、ドライバーまたはPulseAudio（へのインターフェイス）にあります。
alsa-libは、すべてのネイティブALSA操作を処理します（したがって、PulseAudioもそれを使用します）。ここでの問題は、PulseAudioが使用されているかどうかに関係なく現れます。一方、「デフォルト」のALSA仮想デバイスが使用されている場合にのみ発生する問題は、PulseAudio alsa-libプラグイン（alsa-plugins内）またはPulseAudio自体を指している可能性があります。標準のUbuntu 8.10およびKubuntu 10.10インストールでは、「デフォルト」はPulseAudioを経由するため、「デフォルト」とネイティブのPulseAudio出力（またはユースケースとしての入力）を切り替えると、さらに調査するレイヤーを絞り込むことができます。
PulseAudiobuntu's wiki のエントリから読み始めることができます。