目次: ALSA - まとめリンク
ALSA のライブラリ alsa-lib(Git リポジトリ)のミキシングプラグイン dmix のバグらしきものを見つけたのでメモ書きを残しておきます。
簡単に言えば dmix プラグインのミキシング音声に激しいノイズが載ります。発生条件はわかっている限りで、下記の通りです。
現象は条件を満たせば必ず発生するようです。
バージョンは 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条こそが抑止力だと思います(1)を読んで。
私は、病気になるかも知れないから保険に入ろう、そのためのコストは払おうと思うけど、
このサイトの筆者さんのように、病気にならないように過ごせば保険は不要、自分のやりたいことに使おう、という考えもあるんだなあ。
でも病気になったら諦める以外ないから、ギャンブラーですよね。いずれにせよハイリスクハイリターン志向ですね。
メモ: 技術系の話は Facebook から転記しておくことにした。
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 から転記しておくことにした。
管理者: Katsuhiro Suzuki(katsuhiro( a t )katsuster.net)
This is Simple Diary 1.0
Copyright(C) Katsuhiro Suzuki 2006-2021.
Powered by PHP 5.2.17.
using GD bundled (2.0.34 compatible)(png support.)