「lightMPD for apu.1c」がヴァージョンアップ

soxrをopenmpに対応

apu.1c用のlightMPDが「lightMPD-v0.09」にヴァージョンアップしたようです。
幾つか変わった部分があるようなのですが、主な変更点は「soxrをopenmpに対応」させたことのようです。

ただし、これを読んで、「おーっ、ついにsoxがをopenmpに対応するようになったのか！」と事を飲み込んで理解できる人はほとんどいないのではないでしょうか。
実は事情は私も全く同じで「soxrをopenmpに対応」と書かれても、いったいどういう事なのか全く理解できませんでした。（＾＾；

「soxr」はアップサンプリングするときのコンバーターです。これは分かります。
分からないのが「openmpに対応」のほうです。

そこで、早速にGoogle先生に」「openmp」なるものを教えてもらいました。
結論から言うと・・・よく分かりませんでした。（＾＾；；

ネット上を調べてみると

「OpenMPは、マルチスレッド並列プログラミングのための API（Application Programming Interface）です。」

と書かれています。

そして、

「OpenMPは C/C++ や Fortran* の言語規格に準拠しているため、OpenMP* を利用してもプログラムの移植性や互換性を損なうことなく、並列処理を容易に適用することができます。
プログラムの開発者は、コードの設計時から OpenMPを利用した並列処理を実装することも、すでに開発されたプログラムを、OpenMPを利用して段階的に並列化することも可能です。」

とも書かれています。
と言うことは、「soxrをopenmpに対応」とは、「soxr」を「openmp」を利用することで並列処理ができるようにした、と理解していいようです。

では、問題は「並列処理」とは何か？と言う問題です。
これもGoogle先生に聞いてみると「複数のマイクロプロセッサなどに処理を分散して割り当て、同時に計算・処理を行うことで、システム全体の処理性能を向上させる技術」と答えてくれます。

つまりは、「apu.1c」はデュアルコアですから、この二つのCPUにアップサンプリングという処理を分散して割り当てを行い処理性能を向上させたと理解していいようです。
ただ、こういう通り一遍の説明だけでは「ハイ、そうですか」とはなりません。身近な具体例でもう少し突っ込んで考えてみます。

一般的にプログラムを実行するときには「順番」というものが存在します。並列処理をするときに一番のネックになるのがこの「順番」の束縛です。

例えば、台所でチャーハンを作るとします。並列処理という作業は、このチャーハンを複数の人間で作ることを意味します。

まずは冷蔵庫から材料を探し出します。
これは、二人いれば分担できますから時間は間違いなく短縮できます。
タマネギ・ピーマン・人参・豚肉・卵・ご飯・塩・こしょう等という材料を探し出す作業や、それらの皮をむいたり切ったりという下ごしらえの作業は、それぞれがやるべき仕事を適切に割り振っておけば、お互いが同期を取ることもなく仕事が進められます。まさに、並列化の恩恵を十分に受けられます。

しかしながら、次の「炒める」作業にはいるためには、この並列処理が全て終わるのを待たざるを得ません。
おそらく、人参の皮をむいて細かく切るという作業が最も時間がかかると思われるので、この作業の終了を待たずして勝手にタマネギを炒め始めると「計算不正」が起こります。
ですから、片方の人は自分の仕事が終わっても、相手の人が人参の下ごしらえを終わらせるのを待たないといけません。

つまり、次の「炒める」という手順に入るためには一時的にシングルタスクに戻らざるを得ず、そのために「待ち時間」がどうしても発生するのです。
そして、次の「炒める」という作業は「野菜や豚肉を炒める作業」と「ご飯と卵を炒める作業」にマルチタスク化することが可能です。
しかしながら、ここでも炒めた野菜やお肉、そしてご飯と卵を混ぜ合わせて「チャーハン」に仕上げるためにはこの二つの並列作業が完全に終了するのを待つ必要があります。
ここでも、処理は再びシングルタスクに戻り、何らかの待ち時間が発生します。

そして、最後の混ぜ合わせる作業は完全にシングルタスクです。

つまり、「チャーハン」を作るというタスクは、二人いたからと言って作業時間が単純に半分になるわけではないのです。
そして、この事はパソコンのプログラムにもそっくりそのまま当てはまります。

特に、「順番」の束縛が強いプログラムだと待ち時間が頻繁に発生するので「並列処理」のメリットはあまり受けられないと言うことです。

と言うことで、問題は「soxr」というアップサンプリングのコンバーターが「並列処理」のメリットをどの程度受けられるかです。
そこで、あれこれ調べてみたのですが、どうやら「soxrをopenmpに対応」させることで、それぞれのCPUがステレオ録音されている片チャンネルを受け持つようになるようなのです。

なるほど、これは素晴らしい！！

これならば、途中で待ち時間が発生することはありませんから、ほぼ理論値通りの高速化が期待できそうです。

そこで、さらに調べてみると、「音響処理」は「並列処理」に非常に向いている分野であることが見えてきました。

「OpenMP入門―マルチコアCPU時代の並列プログラミング」という書籍で、「OpenMP」の有効性を示す具体例として音響処理の例が取り上げられています。

具体的には以下のような作業が例として取り上げられています。

1. 左右チャンネルを合成してモノラル化
2. エコーをかける
3. カラオケ化

これらの作業を「OpenMP」を使って並列処理をしたときの処理速度がどの程度向上するかをテストしています。
デュアルコアの場合の結果は以下の通りです。

「2CPU(0.52倍）」とはシングルタスクで実施したときと較べて2CPUによる並列処理では0．52倍の時間で処理が終わったことを意味しています。

1. 左右チャンネルを合成してモノラル化:2CPU(0.52倍）:4CPU(0.38倍)
2. エコーをかける:2CPU(0.46倍）:4CPU(0.23倍)
3. カラオケ化:2CPU(0.51倍）:4CPU(0.25倍)

2CPUなら処理時間は半分、4CPUならば4分の1という、ほぼ理論値通りの結果が出ています。
また、並列処理を行うと計算精度も上がるようなことを書いているページもあったのですが、これはイマイチよく分かりませんでした。

ただし、実際に「soxrをopenmpに対応」させることでどの程度処理速度が高速化されるのかという具体的な数値は見つけることはできませんでしたが、おそらく理論値に近い効果は出ているのではないかと想像はされます。
なお、並列処理については「インテルR コンパイラー OpenMP* 入門]というページが非常に詳しいです。興味のある方はご一読ください。

実際に音質面での変化はどうなのか？

とはいえ、オーディオの世界ですから、肝心なのは「音」です。
openmpに対応した「soxr」でアップサンプリングして音質的なメリットがなければ何の意味もありません。

処理速度が半分になったんだよね！でも、音は変わらないんだよ！！・・では意味がないのです。

ただし、この比較の前にぜひ「「mpd.conf」を弄る~アップサンプリング(1)」をお読みいただければ幸いです。
ただし、そんなものをいちいち読んでられないというのが普通でしょうから、掻い摘んでまとめておきます。

以前はアップサンプリングに関しては「懐疑的」と言うよりははっきりと「否定的」でした。理由は簡単で、「format “88200:24:2″」と変更してみても、音質的にはどう考えてもNGだったからです。理屈から考えて悪かろうはずはないのですが、この世界は理屈よりも現実ですから、音が悪ければどうしようもありません。
しかし、最近になって、きわめて重要なことを見落としていたことに気づきました。
何を見落としていたのかというと、アップサンプリングという動作はアルゴリズムが選べるという事実です。

アップサンプリングは「libsamplerate」と「soxr」という二つのコンバーターが使えるのですが、長らくデフォルトは「libsamplerate」で、おまけに最低品質の「internal」というアルゴリズムがデフォルト設定だったのです。
ただし、これには理由があって、かつてのような非力な「ALIX3D2」では負荷のかかる高品質のアルゴリズムは使えなかったのです。

しかし、使用される基盤が「ALIX3D2」からパワフルな「apu.1c」になることで、何と、最も負荷のかかる「libsamplerate」の最高品質のアルゴリズムを使っても余裕で動作するようになったのです。そして、この最高品質のアルゴリズムでアップサンプリングした音は今までのアップサンプリングした音とは別世界です。

この結果を持って、「ボードの高スペック化でアップサンプリングも実用化の範疇に入ってきたような気がします。」とまとめたものでした。
そして、もう一つのコンバータの「soxr」も「音質的にはlibsamplerateよりはソリッドな感じがするので好みは分かれそうです。」とまとめておきました。

ただし、これに続く「「mpd.conf」を弄る~アップサンプリング(2)」では、それでも拭いきれないマイナス点についても記しています。

「ボードの高スペック化（「APU.1D4」）でアップサンプリングも実用化の範疇に入ってきたような気がします。・・・と書きました。そしてこの2週間ほど設定をあれこれ変えて聞き比べてみた結果、結論から言えば、「16bit 44.1kHz」→「24bit 88.2kHz」へのアップサンプリングを基本とすることにしました。
もちろん、全てが「ブラボー！」ではありません。
たとえば、ピアノの音が少しヘタレ気味になります。これが一番の困ったちゃんです。ですから、ピアノ音楽をメインに聞く人や、それがどうしても我慢できないという人にとってはNGです。(ただし、私の環境)
さらに、ヴァイオリンの高音域がほんの少しシャリシャリする感じも否定できません。(個人的には許容範囲)

しかしながら、そういうマイナス面は指摘できますが、トータルで判断すればメリットがデメリットを上回ると判断しました。音のつややかさやふくよかさ、そして何よりも天井が少し高くなってすっと背筋が伸びたような雰囲気がとても好ましく思えます。そして、「APU.1D4+lightmpd」という組み合わのもとでのアップサンプリングならば、音楽が持つ力感や気迫がスポイルされるマイナス面は最小限にとどめられています。」

しかし、どうしても拭いきれないマイナス点があるので、時々は素の「44.1kHz」で聞いたり、また気が変わって「24bit 88.2kHz」へのアップサンプリングを実施したりと、腰が据わらない状態でした。
アップサンプリングした音を聞き続けていると「16bit 44.1kHz」の生成りのザラッとした感じの音が恋しくなり、逆に「16bit 44.1kHz」の音を聞き続けているとどこか窮屈な感じが我慢できなくなってくるのです。

そこで、いつも「soxr」と「libsamplerate」の美質が両方享受できないものかと思っていました。
正確さには欠ける表現ですが（＾＾；、「soxr」には「切れ」があり、「libsamplerate」には「こく」がありました。ビールのコマーシャルではないですが、この切れとこくが同居してくれれば言うことがないのです。

と言うことで、前振りがとっても長くなりました。
つまりは、「soxrをopenmpに対応」することで何が変わったのかと言えば、どうやら長く待ち望んでいた「soxr」の「切れ」に「こく」が加わったような雰囲気なのです。

今まではいささかソリッド気味だった「soxr」なのですが、OpenMpに対応させた「soxr」では明らかにふくよかさが出てきますのでヴァイオリンの高音域がほんの少しシャリシャリする感じはほとんどありません。さらに大きいのは、、ピアノの音が少しヘタレ気味になることは完全に影を潜めました。
いや、それどころか、ピアノの音が実に魅力的に響くではないですか！！

処理速度の高速化がメリットになっているのか、それとも一部で言われているような計算精度の向上が寄与しているのか、そのあたりのことははっきりしません。
ただし、音が変わることは間違いないようです。

と言うことで、今度こそは間違いなく「soxrがopenmpに対応」することで間違いなくも実用化の範疇に入ったようです。