コグノスケ

alsa-lib dmixのバグ

目次: ALSA

ALSAのライブラリalsa-lib（Gitリポジトリ）のミキシングプラグインdmixのバグらしきものを見つけたのでメモ書きを残しておきます。

現象

簡単に言えばdmixプラグインのミキシング音声に激しいノイズが載ります。発生条件はわかっている限りで、下記の通りです。

• dmixプラグインを用いてミキシングを行う、つまり2つ以上の音声を出力する。
• PC以外（つまりx86やx64以外）のCPU向けにビルドされたalsa-lib を用いる、例えばDebian armel向けパッケージなど。
• CPUのエンディアンと異なる（CPUがリトルなら、サウンドカードはビッグ）エンディアンのLPCMを受け取るサウンドカードに対し音声を出力する、例えばS32_BEなど。

現象は条件を満たせば必ず発生するようです。

バージョンは1.0.27.2（2013年7月8日リリース）で発生しますが、おそらくその前、後のバージョンでも発生します。

詳細は後述しますが、原因となる箇所を見る限りGitリポジトリのHEADでも特に解決されている様子はありません。調べたリビジョンへのリンク。

原因

おそらくですが、CPUのエンディアンと異なるエンディアンのLPCMをミキシングするための汎用関数generic_mix_areas_32_swap() が、符号の扱いを間違っているためです。

問題の箇所は下記の通りです。ソースファイル名はalsa-lib/src/pcm/pcm_dmix_generic.cです。

snd_pcm_mmap_writei()
    snd_pcm_write_areas()
        func = snd_pcm_mmap_write_areas()
            snd_pcm_mmap_commit()
                pcm->fast_ops->mmap_commit() = snd_pcm_dmix_mmap_commit()
                    snd_pcm_dmix_mmap_commit()
                        snd_pcm_dmix_sync_area()
                            mix_areas()
                                generic_mix_areas_32_swap() //★★これ★★

(関数ポインタの設定箇所など)

generic_mix_select_callbacks()
    dmix->u.dmix.mix_areas_32 = generic_mix_areas_32_swap()

このgeneric_mix_areas_32_swap() 関数の4行目にある、
sample = bswap_32(*src) >> 8;
が、おそらく意図と異なる結果を招いています。

意図する処理は1/256のスケーリングだと思いますので、
sample = (signed int)bswap_32(*src) >> 8;
が正しいと思われます。

解説

何がまずいかというとbswap_32() の返り値の型がunsigned intのため、右シフト（>> 8）が符号を無視してシフトしてしまうことです。

何故まずいか？というとbswap_32() が（符号付きの値としてみたとき）負の値を返したときに、意図せず結果が正の値になってしまい、音が変わってしまう、という問題を招くからです。

例を出した方がわかりやすいと思います。

例えば、bswap_32() が0xffffec78を返したとします。これは符号付きの値としてみると負の値 -5000です。

本来の右8ビットシフトの期待値は上位ビットを1で埋めた -20（0xffffffec）を得ることだと思われます。しかし、現在のalsa-libのコードだと上位ビットを0で埋めてしまうため、結果が16777196（0x00ffffec）と全く違う値になり、ノイズの発生源となってしまいます。

国家を一か八かの勝負に使わないで欲しい

「軍事的な抑止力」なんて時代遅れ、憲法9条こそが抑止力だと思います（１）を読んで。

私は、病気になるかも知れないから保険に入ろう、そのためのコストは払おうと思うけど、

このサイトの筆者さんのように、病気にならないように過ごせば保険は不要、自分のやりたいことに使おう、という考えもあるんだなあ。

でも病気になったら諦める以外ないから、ギャンブラーですよね。いずれにせよハイリスクハイリターン志向ですね。

メモ: 技術系の話はFacebookから転記しておくことにした。

Javaのabstractはどこに書く？

Javaの修飾子（Modifiers）は、どの順で書くのが正解あるいは推奨なのでしょうか？Javaの修飾子は適当な順に書いてもエラーにならないため、私は今まで何も気にせずに書いていたのですが、不思議なことに一度気にし始めたら気になって仕方ありません。

ググって見るとabstract publicと書く人が多い（デー - public、abstract、static、finalなど修飾子の順番 (3)より）そうです。自身の今まで書いたコードを見直しても、abstract publicと書くことが多かったため、特に意識せず書くとこんな順になるんだろうか、と思ったりしていたのですが…。

Java言語仕様3版を見るとpublic abstractが例として出ているではありませんか。どうやら仕様策定した人としてはpublic abstractと書いて欲しいようです。

なお、コード例は8.4.3.1 abstract Methodsにあります。

いつものパターン

すげえ数売れて超儲かるお花畑計画が承認され、多額の予算と人材が投入され、不発に終わり超絶赤字を叩き出す、までがテンプレになっている。

でも一度も「今回は失敗だった、何故か考えよう」という会議を見たことがありません。

実はやっていたとしても、こう何度も同じ失敗ばかりでは、何も学べていないも同然なので根底を変えるべきでしょうし、失敗は恥ずかしいからと、誤魔化したり、自然消滅させているならさらに悪いでしょう。学習能力ゼロです。

組織も生き物も、学習能力のないやつは早々に死にます。ヤバいわこれ…。

メモ: 技術系の話はFacebookから転記しておくことにした。