ITの最近の流行は、現代のコンピューターの大部分のデバイスが「ソフトウェア」になったという事実につながっています。 プロセッサへの追加の負荷に加えて、これは代替システムのユーザーにとって多くの問題を引き起こします。
私の以前のコンピューターには、VIA VT8237ベースの統合サウンドカードが搭載されたマザーボードがありました。 VT8237は完全なハードウェアソリューションであり、Windows / FreeBSD / Linuxでのサウンドの再生に問題はありませんでした。
アップグレード後、ビルトインカードはRealtek ALC883に変更されましたが、ハードウェアミキシングはありませんでした。 これにより、複数のalsaアプリケーションを使用したり、alsaとossエミュレーションを同時に操作したりするときに、さまざまな問題が発生しました。
カットの下でこれらの問題を解決する方法
ALSAでの複数のストリームのミキシングはプログラムで実装され、デフォルトのデバイス（alsa：default）のみを使用する場合は問題ありません。 しかし、エミュレーションではOSSは悪いです。 LinuxにOSSを実装するには、いくつかのオプションがあります。
- ALSAエミュレーションを備えたネイティブOSS
- aoss-alsa-ossを介して/ dev / dspへの呼び出しをインターセプトする
- padp-pulseaudioを介した/ dev / dspへの呼び出しをインターセプトする
- カーネルのALSAを介したOSSエミュレーション
- ...
カーネルでALSAを使ってalsa-ossとOSSを試しました。 最初の解決策は、OSSインターフェースの実装が不完全なためにバグが多いことがあります（/ dev / dspへの呼び出しをインターセプトすることが常に可能とは限りません）。 また、少なくとも1つのalsaアプリケーションが実行されている場合（トレイ内のミキサーなど）、カーネル内のALSAを介したOSSはエラーを返します（サウンドカードは「ソフトウェア」であり、複数のストリームを混合できません）。 ALSAを使用するすべてをアンロードしてからアップロードすることは可能ですが、便利ではありません。
比較的最近、ニュースレターの1つで
OSSプロキシについて言及しました。 OSSプロキシ-CUSEを介したOSS実装。 CUSEは、charデバイスのLinux実装です。
OSSプロキシは、CUSEを介してキャラクターデバイス/ dev / dsp、/ dev / adspおよび/ dev / mixerを作成するサービスで構成されます。 次に、これらのデバイスへの呼び出しは、バックエンドが理解できる形式で送信されます（現在はpulseaudioとalsaを介した出力があります）。
Debian Squeeze用の
パッケージをコンパイルしました。 このパッケージが適さない人は、ソースコードを含むパッケージから再構築できます。
OSSプロキシを介してエミュレーションを使用した夜は、次の状況でのパフォーマンスを示しました。
- 複数のOSSアプリケーションの同時操作
- ALSAとOSSの同時操作
私の意見では、OSSプロキシは、ソフトウェアサウンドカードでOSSをエミュレートするための最適なソリューションです。
UPD ：lintianコメントが修正された新しいビルド1.3.2-2をコンパイルしました。 新しいバージョンをインストールする前に、古いバージョンを削除することをお勧めします。
sudo dpkg -P osspまたはsudo aptitude purge ossp