abk1's scratched blog 3::AUDIO DIARY

mpd.confの記載内容に関して。
過去のエントリーで以下のように書いていた。

# MPD Internal Buffering ####

audio_buffer_size		"384"
buffer_before_play		"5%"
#

ここの設定について追記。新規エントリーにする。
参考にリンク。
http://linux.die.net/man/5/mpd.conf

「audio_buffer_size」と「buffer_before_play」のデフォルトは2048と10%らしい。これらを変更することで音質が変わるという。
「audio_buffer_size」の数値はkbである。
「buffer_before_play」はaudio_buffer_sizeのうち何％使うかを０～１００％の範囲で設定できる。

5%は少なめの設定だが、384kbの5%ということなら20kb弱だ。
この数値にどういう意味があるのか分からない。
ひどく少ない。
256kbの５％だと12.8kbになってしまう。
これは44.1/16の音楽データだと0.1秒に満たない。384kbの5%だと0.1秒を超える。
384kbの5%は、44.1/16の音楽データだと0.1秒を超えるぐらい。
しかしうちでは88.2/24にアップサンプリングしてるので、0.1秒よりもっと短いはずだ。

上記の設定で、CD１枚単位をflac+cue sheetにリッピングしたものを通して再生する分には、全く問題ない。
しかしiTSから買ったアルバムを通して聴く場合だと、ライブ盤を再生すると音が途切れるのが分かる。m4aをギャップレス再生できないのだ。
384kb/5%では足りないのだろうか。

bufferに関連してリンク。
http://mpd.wikia.com/wiki/Music_Player_Daemon_Crossfading_Troubleshooting
リンク先から引用してみる。

MPD does crossfading by using the buffer.
The amount of buffer used for crossfading is the size of the buffer minus the amount of space reserved for buffer_before_play.
By default (2MB buffer and 25% buffer_before_play) this is approximately 9 seconds of crossfading for 44.1 khz, 16-bit, stereo audio.
If you have the buffer_before_play set to 100%, there will be no crossfading.

crossfadingという操作がmpdクライアントから設定できる。
曲再生が終わって次の曲に移る際に数秒間かぶるように出来る（秒数も設定できる）。

ここで書かれていることから推測するに、buffer_before_playで使われる以外のbufferに、crossfadingのためのデータを読み込むということらしい。
こうした特別な使途がないなら、ほとんどなくてもいいbufferなのかもしれない。
逆に、before playとcrossfading以外で使うことがあれば不具合があるかもしれない。
ギャップレス再生の不具合とは関係があるのだろうか。
http://linux.die.net/man/5/mpd.confには「Try increasing this if you hear skipping when manually changing songs.」とあるが、skippingというのがどういう状態かよく分からない。

みみず工房掲示板からも引用する。

audio_buffer_size
decoderスレッドからoutputスレッドへデータを受け渡すfifoバッファーのサイズです。
buffer_before_play
audio_buffer_sizeのデータがこれより少なくなるとdecoderが動いてバッファーにデータを追加します。
再生開始時はバッファーにデータがこの値になるまで開始されません。
この値を100%にすると常に空きが出ないようにdecoderが動きます。

ここも参考にリンク。
http://d.hatena.ne.jp/propella/20061202/p2 ALSA PCM プログラミングのサウンドバッファ - 言語ゲーム

「audio_buffer_size "384" buffer_before_play "5%"」だと、20kb弱のbufferを切らさないようにdecoderが動いてるってことになる？
audio_buffer_size "1024" buffer_before_play "100%"といった設定だと、1MBのbufferを常に抱えることになる。
全く状況が違ってくるだろう。
常にdecoderが動いてるというのは望ましい状態なのかどうか。
buffer_before_playが100%だと常にdecoderが動くということだけど、buffer_before_playが小さい場合もdecoderが動く頻度が多くなると思う。
再生音にどんな変化があるのだろう。

どんな設定がいいのか、試行錯誤してみる。

こういう試行錯誤がやりやすくなった背景にはibook G4をtelnetサーバーにしたということがある。
当初はsshを考えていたんだけど「鍵」の扱いが面倒でやめた。もしかしたら鍵を使わない設定も出来るのかもしれないが分からなかった。家庭内LANなのでと割り切ってsshdも止めてしまった。

telnetサーバーはVine Linux ppc 5.2には最初からは入ってないので、Synapticパッケージマネージャを使ってインストールした。
当然だけどtelnetを使うと何かと楽だ。いちいちオーディオラックの下からibookを引っ張り出す必要がないし、ncmpcppを操作しながら、同じ画面でmpdサーバーの状況も操作できるというのは面白い。

クラシックの歌劇のCDを曲ごとにリッピングし、flacで保存したものを再生する。
「audio_output_format」は44.1kHz、16bitに固定した。

まず「audio_buffer_size "256"」にしてみる。
「buffer_before_play」の値は、0、10、50、100と換えてみた。
結果、これでは数秒間しか音が出ないことが分かった。
256では駄目みたいだ。

次に「audio_buffer_size "264"」にしてみる。
再生自体に問題はない。
しかし「buffer_before_play "100%"」にするとncmpcppでFキーを押して早送りすると、そのあと音が出なくなるなど再生の不具合が出る。
「buffer_before_play "10%"」にすると問題なくなった。
buffer_before_play以外のbufferは使用状況によっては不可欠かもしれない。
ギャップレス再生は問題なし。

いろいろ試していく。
こまごま書いていっても分かりにくいので、結果を表にする。
縦軸が「buffer_before_play」。
横軸が「audio_buffer_size」だ。

• b : 再生しても数秒間しか音が出ない状態。
• f : Ｆキーで早送りしたときに不具合が生じる。
• np : no problem

npとfの両方が付いているのは、不具合が出る頻度が少ないと感じた所である。
あまり厳密に回数を数えたりまではしなかったので、印象での評価だ。

ざっと見た感じ、早送りにはbuffer_before_play以外のbufferが必要だと分かる。
必要な数値を計算してみる。
1024*(1-0.8)≒200、320*(1-0.5)=160、264*(1-0.3)≒185

どうやら、200kb程の余裕があれば、問題なく早送り出来るようだ。
余分のbufferが足りないと早送りの後で音が出なくなったりする。それでも何回かＦキーなどを連打したら音が出る。
しかし、buffer_before_playが100%だとそれも上手くいかない。早送り自体が出来ないこともあり、止まったときに音を出すにはトラックの初めから再生するしかないようだ。

ギャップレス再生はaudio_buffer_sizeが256kbのとき以外の条件だと問題なく出来た。
256kbでは再生自体がままならなかったので仕方ない。
ということは、ギャップレス再生の可否はbufferの大きさには依存しないということだ。

m4aだとどうか。実は、audio_buffer_sizeが1024でも音が途切れる感じがあった。では、audio_buffer_sizeの数値によって途切れる感じが違ってくるかというと、以外にそうでもない。
mpdの設定よりも、ファイル形式による影響のほうが大きいのかもしれない。

現在の設定は以下の通り。きりがいい数値にした。

audio_buffer_size		"320"
buffer_before_play		"10%"

設定によって確かに音色の感触は違う。
しかし、どの設定が優れているかの判断は難しいと思った。
audio_buffer_sizeが大きいとゆったりした感触になるというのは世評のとおりだと感じた。

buffer_before_playの数値による違いは、どうもはっきりしなかった。
100%だとやや窮屈に聞こえるような印象で、音飛びさえなければ0%のほうがいいような気がする。しかし、そんな印象は気のせいじゃないか？という気もする。
素人考えだが、「0%」というけど実際に再生直前の音楽データのbufferを「0kb」で回してるなんてことは考えにくくて、実はmpdが勝手に判断してデータを切り回してると考えたほうが実際に近いのではないかと思う。

ちなみに、選曲時に「skipping」と思われる不具合も生じなかった。
そういうわけでbuffer_before_playは少なめだ。

アップサンプリングについての音質評価はまだしていない。しかし、少なくともbuffer_before_playの数値よりは影響が大きい印象だ。

ファイル形式によるギャップレス再生の不具合の違いは、そのうちまた確かめてみようと思う。
僕が使ったm4aファイルが、もともと良くないものだった可能性だってあるからだ。
iTunesで同じCDをリップして確認する必要があると思う。