Symphonic MPD讃(3)

本題に入る前にXenomaiについて、何も書いていないなと思い出したので、ちょっとコメントします。
僕がXenomaiを試したのは2年位前です。Xenomaiのインストールに関してはいろいろ情報あります。日本語の情報も結構あります。まず、英語のサイトから。

ここで基本的な情報はgetできます。また、詳細情報のリンクがありますから、ここから始めればOKでしょう。
インストールについても英文でよければ、上記サイトにリンク情報があります。
次に日本語の情報でお勧めなものは以下の通りです。

Raspberry Pi 3とリアルタイムカーネル(2)Xenomai導入編
僕はここの情報を使って、インストールしてみました。
Ubuntu 16.04 (linux-4.9.90)にXenomaiを入れるまで
intelアーキテクチュアであれば、こちらの情報ですかね。
Xenomai導入まとめ(備忘録)
ちょっと古いですが、こちらの情報も使えるかもしれません。

というところです。

音楽用のLinuxパッケージでも、デジファイさんのLightMPDとか、kicktickさんのArchlinux版でXenomaiカーネルに入れ換える版が公開されたことがあったと思います。これらの版に対して熱烈に支持する書き込みがありましたが、僕にはピンとこなかったです。通常のRT Preemptカーネルの方がスッキリした音で、Xenomaiカーネルの何がいいのかサッパリ分かりませんでした。
前々回ご紹介したパパリウスさんの書き込みを読んで、初めてその理由が分かりました。もう一度引用します。『Xenomaiカーネルは、良好なリアルタイム性能を得るためにXenomai APIに対応したアプリケーションとデバイスに応じたRTDMドライバーが必要になります』ということなのですね。
このため、その後、デジファイさんもkicktickさんも RT Preempt を完全に Xenomai に切り換えるということになっていません。デジファイさんの最新のlightMPD apu用1.02では RT Preempt と Xenomai の両方を入れておいて、使い手に選択してもらうという方法をとっています。MPDの Xenomai 対応をしていないので、カーネルの選択は使い手にまかせるということになるだと思います。
MPDを直接 Xenomai 対応させることは至難の技のようです。そのためにパパリウスさんとった対応策については後述します。

リアルタイムのカーネルとして、Linuxで普通に使えるものとしては、RT PreemptとXenomaiがあります。
音楽用のソフトウェアがリアルタイムカーネルを使う理由はレイテンシーを低く抑えるためです。レイテンシーとは処理の遅延のことで、音楽の再生ではレイテンシーは音切れやジッターの発生など諸悪の頑強です。リアルタイムカーネルの最大の目的はこのレイテンシーの改善です。通常、カーネルのレイテンシーは正しく設計されたシステムでは

Xenomai > RT Preempt > 通常のカーネル

となるといわれています。
このため、LightMPDやArchlinux版パッケージで、Xenomaiカーネルを使ってみるという実験が行われたわけですが、必ずしも音はよくならなかったというわけです。
この件に関して、実際にレイテンシーがどうなるのか実験した記事があります。上記のXenomai日本語サイトの一番最初に上げたリンク先のコイデマサヒロさんの書かれた別の記事「Raspberry Pi 3とリアルタイムカーネル(4)評価編」です。
この記事に三つのカーネル(normal、rt-preempt、Xenomai)のレイテンシーを比較したグラフがあります。この最終結果のグラフが大変興味深いので、引用します。

このグラフはcyclictestというレイテンシーを測定するツールを使って、normal(青)、rt-preempt(赤)、Xenomai(黄)カーネルの性能を測定したものです。縦軸が測定件数、横軸がレイテンシーとなります。
ご覧のように、normal、rt-preempt は統計学の教科書に出てきそうな綺麗なグラフを描いているのですが、Xenomai は統計学を無視した、横長の変なグラフとなっています。結果として、「対策していないXenomaiカーネルはバラツキが大きく不安定である。平均値は半分位で良い値だが、バラツクので、安定度で劣る。安定度ではRT Preemptが優れる」ということになります。
この安定度の差が音に影響するということですかね。

Xenomaiカーネルのバラツキを無くすには、「Xenomai APIに対応したアプリケーションとデバイスに応じたRTDMドライバー」となるわけですが、これを普通に行っている分野があります。ロボット開発です。ロボコンなんかだと、RPI+Xenomaiカーネルという組み合わせだらけなのではないでしょうか。センサーからの入力(i2c割り込み)を高速に処理しないといけないという意味で、ロボットの動作は音楽再生と極めてよく似た分野です。ロボットの場合アプリケーションは出来合いのものを使うということはありませんから、自作することになる。従って、簡単にXenomai対応出来るということになります。
一方、音楽再生の場合はアプリ部分はMPDなど出来合いのものを使うということになるので、このアプローチが使えなかったわけですね。Symphonic MPDの凄いのは、i2s専用という割り切りをして、Xenomai対応させたという点です。これは他の音楽パッケージでは無かったユニークなアプローチで、今までにない高音質化を図れることになりました。SMPDの場合、名前で誤解されやすいですが、MPDを再生に使っているわけではありません。以下、パパリウスさんの書き込みから引用します。

symphonic-mpdでは、Xenomai APIで新規開発したプレーヤーソフト(aplay-rt)を使ってPCMを再生しております。
mpdはpipeアウトプットプラグイン、
shairport-syncはpipeバックエンド、
spotify-connectはalsa-libのfileアウトプットプラグインをそれぞれ利用してfifo(名前付きパイプ)にPCMデータを送り、aplay-rtから読み込み、RTDMドライバーというXenomai向けに新規開発したデバイスドライバを使ってALSAバッファに書き込む方式としております。

結果、SMPDのレイテンシーのグラフは上掲の測定グラフとは随分形が変わっています。前々回に貼り付けた SMPD + rpi-3b のダッシュボードからレイテンシーグラフの部分を再掲します。

いかがですか。先程の「Raspberry Pi 3とリアルタイムカーネル(4)評価編」の Xenomai のグラフとまるで形が違います。こちらのグラフなら統計学の先生も「バラツキは少なく、安定度はまあいいよ」といってくれそうな内容です。これは上記のパパリスウさんが書き込んだ対策の有効性を証明するものだといえると思います。音楽ソフトの世界でこういう具合にあるソフトが優れていることをデータで例証できることは稀だと思います。これはその稀少な例ですね。

大分、脱線が長くなりましたが、ここからが本論「SMPDを使って、どうやってSoulNote D-2を鳴らすか」です。

このi2sしかサポートしないソフト(SMPD)をどうやってSoulNote D-2を繋ぐか。答えは簡単。SPDIFで繋ぐです。i2sをSPDIFに変えるrpi用ボードを使います。但し、D-2に繋ぐのだから、それなりに高性能、高音質であってほしい。捜したら、候補はありました。インド産のDigiOne Signatureというハードです。

以下、マニュアルの冒頭のボードを紹介している部分からの引用です。

DigiOne Signature は二つの基板で構成されていて、NDK社製のオシレータを中心としたクロック部分のメインボード(ここにDigiOne用のクリーン電源とRPI用の普通の電源用のUSB type C入力あり)とi2s-SPDIF変換チップWM8805用のサブボードからなります。特長は以下の通り。

ジッターだらけのRPIのクロックとは別に独自のクロックを有する “re-clocker”であること。
RPIのノイズだらけの回路からアースと信号が完全に分離したクリーンな基板による galvanically isolated であること。
メイン/サブボードに対するクリーンな電源(5V to 6V 100mA)とRPI用の5V/2A-3A電源の二電源方式。
お好みのプレーヤを選択できるメーカ製専用ドライバが用意されている。
ジッター値は400fs以下。
1ns以下の立ち上がり時間のcoaxial/BNC出力。

なかなかのスペックですね。
調べたら、コミュニティメンバで使っている方がかなりの人数(書き込みで確認出来るだけで6～7人)いて、十分使えそうです。インド製というのがチャレンジャブルなところですが(インドからオーディオ機器(?)をgetするのは初めてです)、トライしてみることにしました。日本では当然発売していませんので、ご本家のインドのサイトに注文することになります。PAYPALで決済出来るので、オーダは簡単でした。トラッキングも出来ますので、不安な要素はありません。注文して一週間位で到着しました。

AlloのサイトにはDIGIONE SIGNATURE PLAYERというrpiやソフトも含めて全てをセットにしたものもあるのですが、rpiが3B+との組み合わせであり、これではSMPDが動かないので、パスしました。
DIGIONE SIGNATURE はケース及び電源アダプターのフルセットと一緒に購入しました。ケースについては、アクリルというのが気に入らないのですが、最悪は銅テープを貼るという手はあるかなと考え、妥協しました。電源アダプターのフルセットに関しては、必要性は良く分かりませんでしたが、変換アダプタ/プラグなど付いているようなので、入手することにしました。
使ってみてですが、ケースはご覧の通りでLANケーブルなどの端子が出る側面の加工が駄目(雑)ですね。アクリルをセットした状態ではケーブルを差す事が出来ませんでした。結局、使えないので、この部分は裸のままにしました。全体的にも出来はいま一つ。どうしたものか思案中です。
電源アダプターセットは電源アダプターにこういう乾電池をセットするためのボックスがついてくるものです。

2.5mm のプラグ出力が付けられているので、これに変換プラグを組み合わせると簡単にバッテリーで動かすことが出来ます。これがクリーンな電源として使うことが出来るということになります。バッテリーを使わないという人には不要ですね。僕はFidelixのローノイズ電源を使っています。まあ、そのうちバッテリーとローノイズ電源の音質比較に使ってみるかなと思っています。

DIGIONE SIGNATURE への SMPD のインストールはケースの組み立て以外はお猿でも出来るレベルです。

Windows or Linuxで/boot/config.txtの冒頭の行を以下の通り変更
dtoverlay=allo-digione
※Allo DigiOne用ドライバーを指定

音ですが、文句無しです。
以下の通りWindowsの最高峰とLinuxのベストワンを聴き比べをしました。

<ネットワークトランスポート(USB)>
Intel i9-9900T + GUSTARD U16 
┣OS：Windows + JPLAYfemto(7d)
┗電源：エルサウンド

<ネットワークトランスポート (I2S)>
Raspberry Pi 3b / DIGIONE SIGNATURE
┣OS：Linux + Xenomai + Symphonic MPD(0.8.7)
┗電源：Fedelix

GUSTARD U16 についてはリンク先を見てもらえば分かりますが、欧米のオーディオマニアが熱烈支持する中国製DDCです。ESSの最新チップを使った高音質化がうりものです。リンク先はHead-Fiのスレッドですが、昨年の秋に発表された直後に書き込まれ、その後、半年で62ページ926ポスト(毎日数件の書き込みがあったことになります)となっています。凄いでしょ。というわけで、このDDC、JPLAYでもご推奨のハードの一つで、僕もD-2に繋いで、使っていました。
この二つ両方を同時にD-2に繋いで、D-2のUSB切替機能を使い、瞬時に切り換えるという形で聴き比べをすることができます。いろいろな曲をかけ、比べてみました。幸い、音量差はありません。
勝負の結果ですが、互角です。音に大きい差はないです。どちらも最新鋭デジタル処理の入り口の切れ味のよい音がします。ヴァイオリンの雑音成分とか、ピアノの余韻とか、人の声の微細な表情とか、様々の打楽器の響く素材の違いとか見事に描いて余すところがないです。グールドの鼻唄が実に音楽的に聴こえます(^^;;;。

以下、全くの独断と偏見です。この勝負、ハードの物量では

RaspberrPi 3b << Intel i9-9900T　　　　	価格と性能
DIGIONE SIGNATURE < GUSTARD U16　	価格と性能

となり、ソフトは

Symphonic MPD group = JPLAYfemto group　	開発者、コミュニティの力量
Linux+Xenomai+SMPD >>> Windows+JPLAY　　	自由度、可能性

というところです。ハード側は Intel i9-9900T + GUSTARD U16 が断然に優位ですが、ソフト側はLinux+Xenomai+SMPD が圧勝という感じです。個別にみて行きます。

RaspberrPi 3b << Intel i9-9900T　　　　	価格と性能

本体ハードですが、価格=性能の世界ですから、まあこんなものでしょう。もっと差があるという見方もあるかとは思います。

DIGIONE SIGNATURE < GUSTARD U16　	価格と性能

DDCハード部分です。電源を入れた価格ではいい勝負なのですが、GUSTARD U16はD-2と同じクロックに繋ぎ、同期をとっています。この分、GUSTARD側が性能面では優位かなと判断しました。

開発者、コミュニティの力量については評価をするのは無謀というものですが、互角としました。パパリウスさん、Marcinさんのどちらともメールのやりとりをしたことがあります。また、書き込みは多数拝見していますが、高度な再生を実現することにかける意欲と技に関して差は無いと思います。コミュニティについてはJPLAY側には参加していないので、評価できませんが、SMPDのコミュニティについては議論している内容は誰でも読めるようになっていますので、そのレベルの高さはご理解いただけるかと思います。

というわけで、ここまでは圧倒的にWindows+JPLAY側が有利。ところが最後のOS込みのソフトの自由度、可能性を活かしたSMPDが大逆転。勝負を互角に持ち込んだと言えそうです。
これって、1960年代のベトナム戦争を想起します。経済力と物量で圧倒的に優れるアメリカ軍に対抗して地の利と団結力で勝利したベトナム軍というわけです。ちょっと飛躍のしすぎですかね(^^;;;。

この瞬時の切替テストはなかなか面白いです。apu用の最新版のlightMPDとJPLAYで同じようなことができるから試してみますかね。さて、次回は最新版の0.8を中心にして、コミュニティについて書くつもりです。

(PC_Audio) 2019/05/18

コメントする

Symphonic MPD讃(2)

前回最後の部分で『Symphonic MPDは、グローバルなレベルで、音の良さを追求する音楽再生ソフトの最先端に位置するソフトだとと思います』と書きました。
グローバルと書いたのはJPLAYを意識したからです。JPLAYはSMPDと同じようなスタイルで開発されてきたソフトではないかなと思います。「同じようなスタイル」とは強力な開発者とそれを支えるコミュニティにより開発されてきたということです。JPLAY7.0の開発ではこのコミュニティでの議論は非公開だったようですが、SMPDの場合、公開されているというのは大きな違いですね。前回ご紹介したように、この議論が面白いです。SMPDの開発状況がリアルに現在進行形で分かります。WindowsのようなNDAによる縛りがないので、情報は全て公開できるというのは強みですね。

SMPDのもう一つの強みはOSの中に手をいれることが出来ることです。
これはWindowsでは絶対に不可能な技ですから、Windowsユーザからみれば、夢のような話です。処理時間を短縮させようとした場合、ネックになるのはOSの処理時間です。OSは様々の用途を想定して作成されているので、ある特定目的からみると必ずしも最適の処理とはなっていません。
例えば、スループットとレスポンスは二律背反です。よく知られた話で、MPDのバッファ値の設定を小さくすると、音は良くなるが、音切れが発生しやすくなるという事実は、この二律背反を示しています。バッファ値を小さくなるとOSはレスポンスを維持しようとギリギリ状態で動くので、結果として音は良くなる。ただ、システム全体の負荷は上がるので、スループット値は下がり、結果として音切れが発生しやすくなる。という訳です。
この時、音楽再生に関連する特定の処理のみスループットを改善させるという改良の可能性はあります。
ただ、Windowsのような汎用目的のOSではそのような改良は認められません。OSの処理の公平性を無視する改良になるからです。
Linux+Xenomaiというのはこのような個別の目的に合わせたシステムを自由に作成するためのプラットフォームです。
SMPDはこのプラットフォームを活かして、i2s専用のXenomai対応のドライバを作成する、OSの中に手を入れ音楽再生に不要な処理をとことん排除するといったような改良を行い、最高の音で再生可能としてということです。こんなソフトは他にありません。

SMPDですが、とりあえず次の二つの構成で音を確認しました。

一号機 rpi-3b / SB32+PRO DoP
二号機 rpi-2b / Terra-BerryDAC

SB32+PRO DoPはSMPDが上記のようなアプローチを行っていることを知り、今回、新たに入手したものです。Terra-BerryDACは2年以上前に入手した旧型なので、新しいボードが必要かなと考え、Raspberry PI の音楽再生の普及に力を注いでいらっしゃる、たかじんさんに敬意を表し、最新版のボードをgetしました。
rpi-2b/3bは二年位前Linuxに嵌まっていたころ入手したもの。今でも、十分最新機として使えるのにはビックリ。このあたり、Windowsの方がハードのレベルアップ速度は速いですね。まあ、商売の都合でどんどん新型を出して、旧製品を陳腐化させようということなのでしょう。

SMPDのインストールですが環境さえ整っていれば案外簡単です。環境とは、

rpi-3b(+は動かないので、ご注意)を使うこと、
dacはリストに登録されているものを使うこと、
そして、NASが家庭内LANで問題なく動いていること

です。この三つの条件がクリア出来れば、後は

ダウンロードしたイメージ(.img)をSDカードに書き込む。
書き込んだSDカードのブートパーティションにあるconfig.txtにi2sドライバを設定する。やり方はSMPDサイトに解説されています。リンク先にあるようにブートパーティションはFATですので、この処理はWindowsで出来ます(もちろんSSHを使って、LinuxでやってもOK)。
ブラウザを使ってympdを立ち上げNASを設定し、音楽ライブラリを更新する。smpd.local(dhcpアドレス)が使えますので、簡単です(Windows8以前の場合はBonjourが必要ですね)。

これでインストールは完了しますので、普通は「サルでも出来る」レベルです。

ただし、上記の僕の環境は両方ともこの三条件をクリア出来てないので、トラブルはありました。

まず、一号機。これは今年の2月位に発売開始された最新のカードなので、i2s DACリストに登録はありません。しかし、そのあたりはコミュニティがしっかりサポートしていて、情報はあります。以下、takoyakiさんの書き込みを引用します。

/boot/cofnig.txt
# I2S DAC
dtoverlay=hifiberry-dacplus
※hifiberrydac pro用ドライバーを指定

/etc/mpd.conf
# volume setting
mixer_type "external" #hardware, software, external, none
※noneをexternalに変更

# external volume control script
external_volume_control "/home/pi/plugins/sb32/volume.sh"
※コメントアウト

二号機はrpi-2bを使っていたので、トラブルは覚悟していたのですが、以前、cofnig.txtの修正で対応出来た記憶があるので、トライしました(前回の書き込みのリンク先にあります)。しかし、今回は上手くいきません。こちらはコミュニティで質問して、パパリウスさんより回答を頂き、解決しました。config.txtの変更は白文鳥さんの書き込みを参考にしました。以下、コンソールのログです。

ソースをダウンロード(ダウンロードページをご覧ください)
dtsからbinをビルド
dtc -q -I dts -O dtb -o dt-blob.bin.v08x.master.RPi2 dt-blob.dts.v08x.master.RPi2
バックアップをとる
sudo cp /boot/dt-blob.bin /boot/dt-blob.bin.bac
binに名前を変えてコピー
sudo cp dt-blob.bin.v08x.master.RPi2 /boot/dt-blob.bin
sudo reboot

config.txtをrpi2向けに修正
sudo nano /boot/config.txt
# over clock
force_turbo=1
# arm_freq=1152
# core_freq=576
# sdram_freq=576
# sdram_freq_min=576
arm_freq=864
core_freq=432
sdram_freq=432
sdram_freq_min=432

これでメデタシメデタシのはずだったのですが、もう一つ大きなトラブルが待っていました。僕の環境固有の問題なのですが。
NASの大きさです。3TBあります。tag_catcheが100MBを越えていて、パーティションを拡張しないと正しく登録できません。これもコミュニティで質問し、解決しました。容量不足と分かったので、partedのresizepartを実行。その後、パーティション拡張したシステムで起動し、resize2fsを使い、ファイルシステムの拡張をするという方法で行いました。

sdカード読み込み可能なLinux環境で実行。
sudo parted /dev/sdc2
resizepart 1 1700M
rpi-2b/3b環境で実行。
SMPD
sudo resize2fs /dev/mmcblk0p2

Limuxのコマンドを直接使って、実行しましたが、raspberry PI にはパーティション拡張専用のコマンドが用意されているのですね。Q&Aのページに解説があります。こちらの方が簡単そうです。こんなコマンドです。

sudo raspi-config noint --expand-rootfs

rpi-2b での再生ですが、ダッシュボードでみると、rpi-3bと比較して処理能力にはかなりの差があるようです。
これは rpi-2b / Terra-BerryDAC で音楽再生中のダッシュボードです。前回の rpi-3b / SB32+PRO DoP と比較してご覧いただくと、一目瞭然ですが、レイテンシーで2μ秒以上の差がありますね。

音の感想ですが、カードの音質性能を究極まで出し尽くしているという感じです。特に音場感が素晴らしいです。かなり高級なDACでないと出せない空間の広がりが楽々と表現されるところには驚きました。僕は普段はSACDをマルチチャルネルで聴いているのですが、SMPDの世界はこのSACDのマルチチャルネル表現に近いなと思いました。もちろん後ろから音は聴こえませんが、ホールの空間の広がりがとてもよく分かります。
またチップの差による音の違いがとても見事に表されます。SB32 ESSの分解能の高い、クリアで分析的な音とTerraBerry AKの暖かいが力強い音が鮮やかに描き分けられるのにはビックリしました。特にSB32+PRO DoPの超高解像度でありながら、刺激的にならない、クールな音は素晴らしいと思いました。これなら、高いDACは不要ですね。

さて、「これなら、高いDACは不要ですね。」と書いておいて、卓袱台返し。やっぱりSMPDを使って、SoulNote D-2を鳴らしたくなります。しかし、i2s接続は使えない。USB接続は駄目。となると、どうすればいいか。
コミュニティを覗いて、解を捜し出しました。答えは只今、インドから空を飛んでいるところです。次回にご紹介出来ると思います。

SMPD R and Dクラブ入会方法

P.S. 僕の書き込みでたかじんさんにお手数をかけては申し訳ないので、SMPDを使いたいと考える方は僕宛に
①お名前とメールアドレス
②オーディオ歴
③SMPDに興味をもった理由、どう使うつもりか
④Linux歴(無いと推薦しないという訳ではありません)、GPLを知っているか(知らなければ推薦しないというわけではありません)
⑤その他なんでも自己紹介(まったく初対面の方は自己PRして下さい)
をご連絡下さい。問題がなければ、パパリウスさんに入会を推薦します。

(PC_Audio) 2019/05/11

コメントする

Symphonic MPD 讃

「さらばJPLAY、さらばWindows」(^^;;;というわけではないのですが、Symphonic MPD(以降SMPDと表記します)というLinux/Raspberry_Pi専用の音楽ソフト(ディストリビューション)について書きます。実は、1年半位前にこのソフトを紹介したことがあります。そのころはまだ登場して半年もたっていなかったと思います。「これはRaspberry PI用の音楽ソフトとしては最有力のソフト」だなと思いました。ただ、デビューしたてだったために未完成の部分が一杯あって、i2s接続専用というユニークなアプローチがまだ完全には徹底されていないなという印象でした。i2s接続用に使っていたAITのDAC(ES9018)では使えなかったこともあり、僕の常用ソフトとなることは有りませんでした。結局、AITのDACはBBBとapuを組み合わせたを使った手作りシステムで接続して使うことにしました。

最近、new_western_elecのたかじんさんの記事で、Symphonic MPDが会員限定公開方式に制度を変えたという内容を読みました。「何が起きたのだろう」と驚き、早速、たかじんさんの記事のリンク先の、SMPD開発者、パパリウスさんのブログのコメント欄を覗きに行きました。
ビックリしましたね。このソフト、前代未聞のとんでもない地点まで行って、開発を続けているようです。「これは放ってはおけない」と考え、あわてて会員登録し、たかじんさんの最新i2sカードをgetして、試してみました。

で、結果が冒頭のセリフ。「さらばJPLAY、さらばWindows」、そして「こんにちはSMPD、こんにちはLinux」というわけです。凄いですね。このソフト。JPLAYfemtoも真っ青というレベル。ソフトでここまで出来るとは驚きました。

何が凄いのかというと、高音質化に対する徹底したアプローチにより、シンプルなi2s接続の基板レベルのハードを使って、信じられないほど素晴らしい音を出していること。
Raspberry PI 3b、i2s接続専用。リアルタイム性能の高いXenomai(ゼノマイと読むようです)カーネルを使い、ALSA、MPDなどを最適化する。Xenomai APIに対応したアプリケーションとRTDMドライバーを開発し、Linux本体側も音楽再生に最適化して、使う。RTDMドライバーが存在しないUSB接続はシャットアウトする。このようにして、徹底的にジッター低減を図っているようです。
このあたりをSMPDの作者、パパリウスさんが的確にコメントしているコミュニティでの書き込みがあります。「何故、SMPDでUSB接続に対応しないのか ?」というクラブメンバーの問に対する答えです。

symphonic-mpdの基盤として使用しているXenomaiカーネルは、良好なリアルタイム性能を得るためにXenomai APIに対応したアプリケーションとデバイスに応じたRTDMドライバーが必要になります。

上記に対応していない部分は、Linuxカーネルの機能を呼び出したり、通常のLinuxアプリケーションを使用することになります。
Linuxカーネルのタスク切り替え方式は「Preemptible Kernel (Low-Latency Desktop)」に設定しておりますので、Xenomai非対応の部分では、OSジッタの平均が15,000ナノ秒、最大が500,000ナノ秒程度の水準で、そこにXenomaiカーネル分のオーバーヘッドが加わります。

さて、EthernetについてはXenomaiが「RTNet」というRTDMドライバーを標準で提供していますので、アプリケーションをXenomai APIで開発すれば低レイテンシーなネットワークアプリケーションの開発は可能だろうと思います。 USBについてはXenomai標準のRTDMドライバーは存在しません。
自力でRTDMドライバーを開発できればよいのですが、USBの仕様は複雑で巨大すぎるため、わたしには不可能です。（Linuxコミッタに近い技術力を持ったUSBドライバーの開発経験者に外注しても、10人月〜20人月程度は必要ではないかと思います。）

1000ナノ秒以下の低レイテンシーが必須な分野ではFPGAが現実的なソリューションですので、今後も実用レベルのRTDMドライバーが開発される可能性は低そうです。

音質面で言えば、USBトランスポート側より、USBレシーバ側をクローズアップされると良いかもしれませんね。

I2Sというプロトコルは誤り訂正や再送制御といったデジタルの利点を何も備えておりません。
レシーバのI2S出力性能を疑問視する論調はあまり見かけませんが、影響は決して小さくないのではないでしょうか。

いかがですか。実に切れ味のいいコメントでしょ。明快そのもの。数字を適切に使って、説得力も凄い。これだけ見事に書いて頂けると、サルでもXenomaiの重要性と使い方が分かります。

実はXenomaiについては、僕も試してみたことがあるのですが、いま一つ良さがよく分からなかったのですよね。LightMPDの作者のデジファイさんの同じような主旨(Xenomaiのメリットが不明)の書き込みをされているのを読んだ記憶があります。その理由が専用アプリとRTDMドライバーへの対応が無かったということだったのですね。専用アプリがなく、RTDMドライバーへの対応されていない場合、Xenomaiを使っても何の意味も無いということのようです。永年の謎が具体的な回答例と共に、クリアに解き明かされました。

SMPDのXenomai対応は昨年7月のバージョン0.6.0のリリースからです。その時のリリースノートから引用します。

xenomaiカーネルでレイテンシーグラフを撮ってみました。
xenomai APIを適用したアプリケーションに限り、レイテンシーを2マイクロ秒以内に抑えることができます。
今のところ、aplayへのxenomai API適用が完了しています。音質は極上と言って差し支えないかと思います。

リンク先のリリースノートにはこのレイテンシーのグラフ表示があります。演奏中のものかどうかは分かりませんが、見事に1μ秒程度に収まっていますね。
ここから、オーディオ的に見ると別次元のアプローチが開始されたのかなと思います。この頃のコメントは半年ぶりの新版だったので、再開をよろこぶというものが多く、この新しいアプローチを評価するものはほとんどありません。まあ、Xenomaiの使い方なんて知っている人は普通にはいませんから、当たり前でしょうね。
JPLAYfemtoが登場した昨年の11月頃に、0.6.xの最終版に近い版がリリースされていますが、このあたりから大幅に音質改善され、メンバーから「音質は最高。もうこれで十分。」という評価されるようになっています。
作者のコメントです。

v0.6.8あたりから続くアップデートの流れは、v0.6.24でひとまず完了いたしました。
aplayの高速化に始まり、alsa-lib、alsa-driverと作業範囲を拡大し、ちょっと無謀とも思えたLinuxカーネルの高速化に取り組みました。
smpdで使用されている1000ファイル以上のソースからホットスポットとなっている箇所をピックアップし、数百ファイルを修正しています。

カーネルの高速化を施したv0.6.23とその改善版であるv0.6.24は空間表現に優れ、今まで重なって聴こえていた音像を前後に分離する力があります。
聴き慣れたCDクオリティの音源から、バージョンアップの度に新しい音・演奏表現を発見できるので、いくら聞いても飽きることがありません。時間がいくらあっても足りませんね（笑

これは僕の環境で実際に演奏中に状況表示するダッシュボードを表示させたところです。縦軸は対数目盛りですから、ご覧のようにほとんどのサンプルが2μ秒以内のレイテンシーに収まっていて、平均値は1μ以下であることが分かると思います。作者のリリースノート通りですが、これは驚異的な数字だと思います。

メンバーの声です。

以前より、シングルPCで聴くJplayの音は「Jplay独特のふくよかな音質」で、他のディストリビューションとは土俵が異なると感じておりました。
しかし、最初にJplay FemtoをdualPC構成として聴いた時に、皆さんが言われる通り素晴らしい音なのですが、Jplay独特な音質が薄くなって鋭い音となり、一方で、SMPD-0.6.23の音に近くなり、同じ土俵になったと感じました。
PC(ASIO)、Linux(ALSA)と環境が異なっても、音質を突き詰めて行くと同じ音質になるのでしょうか？

個人的な興味ですが、一度「Jplay使い」の方々に「SMPD-0.6.23の音」の感想を聞いてみたいものです。

僕も「Jplay使い」に分類されるかと思いますので、感想を書いておくと、「同じ土俵になった」というのに完全に同意します。というか、土俵はWindowsよりLinux-Xenomaiの方が広いでしょう。戦うには疲れそうですが、可能性はこちらの方がはるかに高いと思います。
メンバーを声をもう一つ。

私の環境では、RPi3用パラメーターをv0.6.24に適用してから、一線を画した臨場感が出てきています。
ここまで音像がはっきり再生出来るなんて、驚き！そして感動です。
そもそも、サラウンドという音響加工なんて、不要だと思うくらい凄いです。
アナログリマスタリングのCDを聞くのが楽しくて、時間がいくらあっても足りません！

この後、0.7.0を経て、0.8.0が登場。これが、また大幅なレベルアップした版となります。2019-03-03のお雛さまの日の作者のコメント。

さて、64bit版と並行して、Xenomai対応の本丸とも言える「RTDMドライバ」の開発を進めておりました。
ALSAドライバの機能のうち、aplay-rtで使用している部分だけを抜き出してRTDM(Real-Time Driver Model)で実装したものです。
1週間程度を目処に、RTDMドライバ搭載版をv0.8.0として公開したいと思います。
ただし、このv0.8.0は必ずしも多くの環境で動作するとは考えておりません。音が出たらラッキーだと思ってお試しいただければと思います。

この直後に会員限定公開方式に制度を変えることになったGPL違反騒動が発生し、非公開となりました。この時の作者パパリウスさんとメンバの間でのやりとりがそのまま残されていますが、冷静で、落ち着いた素晴らしい対応ですね。
さて、0.8.0が公開され、最初多少不安定な面があったようですが、現在では十分安定し、音も最高という絶賛の嵐が続いています。0.8.6での作者のコメントです。

v0.8.6では、aplay-rtからRTDMドライバーを呼び出す部分を改良し、データのコピーを最小限に抑える工夫をおこないました。

通常、アプリケーションからドライバの機能を呼び出すとき、メモリ上でデータのコピーが発生してしまいます。例えば1バイトのデータを引数としてドライバを呼ぶだけも、ユーザ空間からカーネル空間へのデータコピーのために100ナノ秒前後の処理時間がかかり、最大では1000ナノ秒程度の処理時間のブレが生じます。
結果として、CPUキャッシュの汚染、キャッシュヒット率の悪化という形でより重要な処理（ALSAバッファへのPCMデータ書き込みや、ALSAバッファからシリアライザ用送信FIFOへのDMA）に悪影響を及ぼしてしまいます。
v0.8.6では、このような重要性の低いデータコピーを前バージョンに比べて数分の一に削減しております。

Symphonic MPDは、グローバルなレベルで、音の良さを追求する音楽再生ソフトの最先端に位置するソフトだとと思います。WindowsにはないXenomaiという環境を使って、アプリとドライバをとことん音楽再生専用にチューニングしてしまおうというコンセプトが凄いです。ライセンス問題の結果として、作者のこの考えに共感して集まったコミュニティが形成されたのも、結果として音質を向上させるのに有利に働くと思います。このコミュニティでは非常に率直な意見交換が行われていて、作者のパパリウスさんもそれに素直に応じて、次々と新しい試みがされるという形で活発なやりとりがされてています。素晴らしい。

メンバにならないと使えないとか。i2s接続専用なので、使えるDACは制限されるとか。使いこなすにはLinuxのある程度の知識が必須とか。ハードルは高いのですが、一度この音を経験したら、後には戻れません。
天国への門は狭い。この素晴らしい音を味わうには、狭い門が待っているのは当たり前なのかもしれません。「狭き門より入れ。こんにちはSMPD、こんにちはLinux、こんにちはxenomai。新しい世界にようこそ」ですね。

(PC_Audio) 2019/05/04

コメントする

バッハレイチェル・ポジャーチェロ組曲ヴァイオリン

タイトルはご覧の通りで、要するにレイチェル・ポジャーがバッハの無伴奏チェロ組曲をヴァイオリンで弾いたSACDです。
この組曲は、スパッラで(ちょっと古楽器風にということですかね)、ビオラで(スパッラの親戚のようなものだから、もっとも)、コントラバスで(やりたい気分はよく分かるが、高音域は相当厳しそう)、サクソフォーンで(管楽器の超絶技巧となり、とても面白いです)、リコーダで(ブリュッヘンの録音があります。音域の問題は低音用の楽器を使えば、何とかなります)、ギターで(無理なく演奏できそうですね。ただ聴いたことがありますが、あまりピンとこなかったです。撥弦楽器と擦弦楽器の差ということですかね)など、いろいろな楽器で演奏されているのはご存じの通りです。ただ、同じ弦楽器ですが、ヴァイオリンでというのは今まで無かったと思います。
まったくの邪推(^^;;;ですが、理由はヴァイオリニストにとって、この曲を弾くと、チェリストからいちゃもんを付けられのが怖いからでしょうね。チェリストから見れば、「ビオラだとか、コントラバスなら、独奏用の曲が無いのだから分かる。ヴァイオリンには、れっきとした無伴奏のソナタとパルティータという大傑作があるじゃないか。その上、チェロ組曲まで弾いちゃうとは。掟破りのとんでもない輩だ。」と言われるのが怖かったのでしょう。でも、女は強い。ポジャーさん、そんなことは頓着せず、アルバムを出しちゃったということらしいです。

もっとも、ポジャーさんもそのあたりの事情を気にしていたようで、ライナーノートに言い訳の文章が載っています。そのタイトルが

「CELLO SUITES ON THE VIOLIN : LEGITIMATE OR LOONY」。

LEGITIMATEというのは法を守ること。LOONYというのは狂気の人という意味らしいです。

「ヴァイオリンで無伴奏チェロ組曲を演奏する。正しい振る舞いか、狂気の沙汰か」

というところですかね。相当に気にしているようです。

この言い訳が「確信犯の自白調書」という感じで、なかなか面白いので、供述調書風(^^;;;に紹介します。

私にとってバッハの音楽は身近にあるのが当たり前の音楽で、チェロ組曲もヴァイオリンで弾くことはできませんでしたが、子供の頃から日常的に愛聴する曲でした。ただ、多くのチェリストの演奏を聴いて(その中には巨匠と呼ばれる人もいました)、違和感があったのは、この組曲の舞曲(テンポやスタイル)としての性格が薄められた演奏ばかりということでした。かなり以前から、密かに、そう思っていて、もっと舞曲らしい演奏が登場しないかと切望していました。
その後、音楽大学に入り、この組曲がバロックチェロで演奏されるのを聴き、バロック弓でガット弦を擦る演奏から生ずる軽快な動きや躍動感を知り、初めて曲の意味が分かりました。本当にそれはまさに曲に生命が吹き込まれた瞬間で、天からの啓示と呼ぶべき体験でした。

その後、モダンチェロ、バロックチェロを問わずさまざまなチェリストにこの曲をアドバイスする機会にめぐまれ、自分のヴァイオリンで演奏して、このような観点(この曲は舞曲としての軽やかさを持つ曲だということ)を示し、教えてきました。こういう過程を経て、次第にこの組曲は、私にとって無伴奏ヴァイオリンパルティータやソナタに加えて、「必須食品」となっていきました。
そして、ウォーミングアップに特に好きないくつかの曲を演奏会で取り上げることから犯行を始め、ヴァイオリンで弾いてもまったく問題のないことを確認しました。この経験の中で、ヴァイオリンでこれらの曲を弾くと、特に高い音域でまったく新しい表現力の語彙を獲得出来ることも分かりました。
カザロス、フルニエ、トゥルトリエ、シュタルケルといったキラ星ように崇められ、尊ばれられるチェロの巨匠たちがカタログを飾ってきたこの曲のレコード演奏録音史において、ヴァイオリンによる新しい録音を行うという大胆な犯行に及ぶ場合、どうやってその行為を正当化するか、難問です。
しかし、私が行おうとしたことは、バッハ自身が行った自分の作品を別の楽器用に再構成し、再利用した行為と大した違いはないように思えます。バッハは際限なくこのような悪さを行っていて、ちょっと思い出すだけで、コンチェルトをカンタータのシンフォニアに転用したとか、ヴァイオリン協奏曲をハープシコード協奏曲に使ったとか、枚挙に暇の無いレベルです。振り返れば、振り返るほど、バッハはもっと悪いことをしているのだから、私は何も恥じるところは無いと思えるようになりました。だって、ホ長調のヴァイオリン・パルティータのプレリュードを思い出してください。バッハはこれをトランペットと太鼓が活躍するフルオーケストラのカンタータに変えてしまったのですから(^^;;;。

六つの組曲をヴァイオリンで弾くことは、(無伴奏のヴァイオンリン用に作曲された曲を弾くときとは)ちょっと違った立ち位置に立つことを意味します。ヴァイオリンはチェロと比較して楽器の響板は小さいので、もっと小回りが効きます。そしてその直截な音はフレクシブルで、飛び回り、跳ね回ることが出来る。慎重(circumspect)で、重々しい(gravitational)チェロとは違います。従って、舞曲ではチェロで慣れているテンポより、多少、速めに弾いた方がヴァイオリンでは効果的です。このように演奏すると、最初、例えばサラバンドのような遅いテンポの曲の場合、ちょっと響きが足りない感じでしたが、ガット弦をなだめすかして(cajore)、重音を弾くことにより、甘い響きを得るという方法で解決しました。

ヴァイオリンでプレリュードをどう演奏するか。簡単ではありません。ヴァイオリン向けに再構成するということになりますが、解決するのが楽しい、高級で、贅沢なパズルのようなものでした。
第一番のプレリュードは平均律第一巻第一番のプレリュードと同様に抗い難い流れに身を投げるという感じ。
第二番は半音階語法によりもっと神秘的に見える。
第三番は輝かしくさわやかにはじまりるが、拡張されたアルペジオ部分で複雑でゴツゴツした感じに変わり、レトリカルな終結部分に至り、予定調和的に終わる。
第四番は緒絶技巧の体力勝負。
特殊調弦の第五番は暗く、ヒリヒリした陰鬱な気分。
最後に、第六番は確固たる信念の下の終結部分であり、晴れやかに人生を肯定する。

最初の5曲はオリジナルのピッチに対して1オクターブ半(5度)を上げて演奏しています。
第六番は多少事情が異なります。オリジナルはもともとE弦が最高音の五弦のチェロのために書かれた曲なので、最初は五弦のビオラやヴァイオリンで試してみたのですが、最終的には普段弾いている自分のヴァイオリンを使うという選択に戻りました。但し、曲の音域の低い音のフレーズはビオラのC弦の助けを借りて、演奏しました。そして、後は、我が賢明なプロデューサとエンジニアの手に委ねました。

いかがでしょうか。冷静、分析的に「狂気の沙汰」におよんだことが良く分かる供述調書だと思います。全文をほぼそのまま逐語訳しています。但し、直訳すると僕の英語力(&日本語力)では意味不明になるので(^^;;;、調書風に意訳しました。

演奏はまさに上記コメント通りで、従来のチェロの演奏になれている耳には、まったく異なる新しい無伴奏ヴァイオリン用の曲集が登場したように聴こえます。「2018年大英博物館の地下倉庫でバッハの無伴奏ヴァイオリン組曲全6巻が発見され、10月にレイチェル・ポジャーがロンドン・ロイヤル・アカデミーの小ホールで初演、録音を行った。」という感じですね。

もっとも、世の中には頭の固いオッサン(ですかね?)はいるようで、Classics TodayでのJens F. Laursoさんのレビューです。

But something is missing. I have a feeling it is the effort, actually. The bit of strenuousness, the bit of exertion that the cello demands of its performer is missing, and the result becomes—sneakily—glib. The violin flits about neatly, but the sense that someone is digging in and, if not fighting for their life, at least grappling to achieve a greater glory, is missing.

ポジャーさんの犯行を取り締まる保守頑迷の検察官という感じですね。「何かが不足している」というのだけど、まあ不足しているのは批評家ご本人の想像力でしょう。

(music) 2019/04/28

コメントする

JPLAYでCPU Affinityとプロセス優先度を設定する(7)

まず、JPLAYのディフォルトの設定がどうなるのかを調べます。スレッド(コア)が9以上16以下となった場合。JPLAYを使っての再生中で、DedicatedCoreはディフォルト(1)の設定です。プロセス監視スクリプトの出力ログを編集しました。

i7 8700Tマシン(6コア/12スレッド)

1528 	 1.328125 	 0.015625 	 JPLAYfemto 4095 RealTime
4972 	 0.03125 	 0.03125 	 ffmpeg	added 4 Idle
1520 	 0.484375 	 0.03125 	 jplay 2 RealTime

1564 	 2.515625 	 0.015625 	 dwm 4095 Idle
5540 	 5.140625 	 0.03125 	 powershell 4095 Idle
4 	 13.09375 	 0.015625 	 System

i9 9900Tマシン(8コア/16スレッド)

7512 	 0.0625 	 0.0625 	 ffmpeg	added 4 Idle
1488 	 0.3125 	 0.015625 	 jplay 2 RealTime
1480 	 0.640625 	 0.015625 	 JPLAYfemto 65535 RealTime
1184 	 1.828125 	 0.015625 	 dwm 65533 Idle
7680 	 10.515625 	 0.078125 	 powershell 65533 Idle
4 	 17.125 	 0.015625 	 System

10進の4095は16進のxFFF、10進の65533は16進のxFFFFです。

表に纏めるとこうなります。

	Core0	Core1	Core2	Core3
JPLAYfemto	○	○	○	○
jplay	×	○	×	×
ffmepg	×	×	○	×
一般プロセス	○	○	○	○

この内容は4コア4スレッド以下の場合と微妙に異なります。
これが4コア4スレッド以下の表に纏めたものです。

	Core0	Core1	Core2	Core3
JPLAYfemto	○	○	○	○
jplay	×	○	×	×
ffmepg	×	×	○	×
一般プロセス	○	×	○	○

ご覧の通り、一般プロセスがCore1を使用するかどうかが差です。「コア数が5以上なら余裕があるから、一般プロセスがjplay/JPLAYfemtoとぶつかってもかまわない」ということなのですかね。

ディフォルトの状態で聴ける音ですが、素晴らしいです。4コア4スレッドのマシンと比較して、かなりの差を感じます。特に8コア16スレッドの音は次元が変わるという感じで、お勧めです。

という訳で、このままでもいいかなという感想ですが、ここで終わっては「みみず工房」の名が廃ります。
jplayとJPLAYfemtoを専用のコア/スレッドに貼り付けてみます。
6コア12スレッドシステム用の設定スクリプトです。
コア0番(0/1)、1番(2/3)、2番(4/5)を一般用に、コア2番(4/5)をffmpeg用に、コア3番(6/7)をjplay用に、コア4番(8/9)と5番(10/11)をJPLAYfemto用に設定します。

$instances = Get-Process
foreach ($i in $instances) { 
	$i.ProcessorAffinity=63
	$i.PriorityClass='idle'
}
(Get-Process -name ffmpeg).ProcessorAffinity =60
(Get-Process -name ffmpeg).PriorityClass = 'idle'
(Get-Process -name jplay).ProcessorAffinity =192
(Get-Process -name jplay).PriorityClass = 'Realtime'
(Get-Process -name JPLAYfemto).ProcessorAffinity =3840
(Get-Process -name JPLAYfemto).PriorityClass = 'Realtime'

次に8コア16スレッドシステム用の設定スクリプトです。
こちらはコア数に十分余裕がありますので、コア0番(0/1)、1番(2/3)、2番(4/5)を一般用に、コア2番(4/5)をffmpeg用に、コア3番(6/7)、4番(8/9)をjplay用に、コア5番(10/11)、6番(12/13)、7番(14/15)をJPLAYfemto用に設定します。

$instances = Get-Process
foreach ($i in $instances) { 
	$i.ProcessorAffinity = 0x003F
	$i.PriorityClass='idle'
}
(Get-Process -name ffmpeg).ProcessorAffinity = 0x0030
(Get-Process -name ffmpeg).PriorityClass = 'idle'
(Get-Process -name jplay).ProcessorAffinity = 0x03C0
(Get-Process -name jplay).PriorityClass = 'Realtime'
(Get-Process -name JPLAYfemto).ProcessorAffinity = 0xFC00
(Get-Process -name JPLAYfemto).PriorityClass = 'Realtime'

このように16進で表現することもできます。これなら16進計算機はいらないですね。

これでメデタシ、メデタシ。チューニングは完了。である筈だったのですが、Windows、マイクロソフトの世界はそう甘くはない。
プロセス監視スクリプトでのモニター結果が変なんですよね。
プロセス監視スクリプトについては前々回にソースコードを紹介していますので、そちらも参考にして下さい。順番に説明していきます。

尚、今回ご紹介するログはチューニング前にとったものなので、最後のチューニング完了後のものを除き旧バージョンのフォーマットとなっています。ご了解下さい。

i9-9900T、8コア/16スレッド構成、起動直後の状態。システムインストール直後。チューニングはまったく行っていない環境です。

Total_CPU_Time 	 37.734375 	 proc 	 72
 1.956705  1.704792  2.924071  1.612605  0.955062  1.580358  1.489024  1.738683  1.111036  1.236914  
1.143503  1.046017  1.112246  1.206007  1.205713  1.237157  1.397541 -avg

10秒間隔、50回のモニター結果を最後に集約して表示する部分です。
最初の行は監視中に動作したプロセスのトータルの実行時間と動いたプロセス数。時間は秒単位ですので、37.7秒、72プロスとなります。2行目と3行目はコア(CPU)毎のCPU負荷(パーセント)。ご覧のようにスレッド分16個のCPU負荷と平均の負荷値が並びます。
単純に考えれば、プロセスのトータル実行時間を測定時間とCPU数で割れば、CPU負荷ということになります。

(37.7(実行時間)÷600(測定時間))÷8(CPU数=コア数) = 0.78%

監視された平均CPU負荷(1.4% -avg)と比較すると低めの値ですが、マルチタスクのOS走行時間が差を発生させているのかなと思います。

これは、その後JPLAYで再生中の数値。Total_CPU_Timeが183.3秒と跳ね上がっていて、問題ありですね。何故かプロセス数は51に減っています。いずれにしても、チューニング無しでは使えそうもないです。

Total_CPU_Time 	 183.359375 	 proc 	 51
 3.300717  0.056929  0.182825  1.706493  24.010324  0.675682  2.337279  2.207862  1.011511  
0.980248  0.949044  1.042732  0.980262  1.011543  1.075015  1.011511  2.566222 -avg

というわけでチューニングしてみました。チューニングした内容は3回前の「JPLAY 7 で OSチューニング(1)」の中の手作業の部分のみです。
結果です。

Total_CPU_Time 	 23.03125 	 proc 	 74
  1.922745  0.516359  0.268084  0.891010  1.361659  0.891844  1.798521  1.579061  2.330120  
 0.484501  1.109145  1.077041  1.892608  2.330233  2.515706  1.611532  1.286335-avg

①～③のチューニング後の8コア/16スレッドの起動後何も動かしていない時の数値です。

Total_CPU_Time 	 10.328125 	 proc 	 51
 3.762380  0.042538  0.293424  1.388394  1.478600  0.91546  1.170271  1.385922  1.356510  
1.606397  1.607403  1.854584  2.387460  1.604606  1.825965  1.481430  1.483458 -avg

その後、同じく環境でJPLAYの再生中の数値です。
大分良くなりましが、もう一息という感じですね。1.483458 -avgは以前紹介した i5-3470の 0.979010-avgと比較すると大分高めですね。どうも、コア/スレッド数が大きいマシンの場合は別の観点からのチューニングが必要なようです。不思議なのはCPU実行合計時間、プロセス数共にJPLAY再生中の方がいい値になっていること。謎です。

以下はi9-9900Tの音楽再生専用システムに対して、「コア数が4を越えるマシンのチューニング」を行った後のログです。詳しい説明は次回以降にまわして、とりあえず結果だけです。

手作業で以下をチューニング。

設定、プライバシーを通知を除き徹底無効化
IAStorDataMgrSvcを退治
Search IndexerとSecurityHeathServiceを退治

以上のチューニング後、起動直後の何も動いていない状態です。

T_CPU_Time 1.15625 	 T_CPU_AVG 0.012 	 E_Time 600.9 	 CPU 16
T_proc 14    TR_proc 55    Loop 50
idle 1599.81748724976    real 0.182512750244314    real_avg 0.0114070468902696
 0.578604  1.296137  1.172319  2.016795  1.390697  1.516050  0.891575  1.548092  1.297688  
 1.234925  1.014490  0.079315  1.045477  1.453900  1.202464  1.704046  1.126283 -avg
p_total 19.4425721309126    p_avg 1.21516075818204

次に8コア/8スレッド構成に変更

T_CPU_Time 1.578125 	 T_CPU_AVG 0.033 	 E_Time 600.6 	 CPU 8
T_proc 18    P_Proc 47    Loop 50
idle 799.985961269435    real 0.014038730565062    real_avg 0.00175484132063275
 0.574150  0.012963  1.480586  1.322756  1.198969  0.822566  1.386760  1.230705  0.883107 -avg
p_total 8.02945391726816    p_avg 1.00368173965852

JPLAYを再生中に。

T_CPU_Time 1.25 	 T_CPU_AVG 0.026 	 E_Time 600.4 	 CPU 8
T_proc 21    P_Proc 57    Loop 50
idle 799.568543285007    real 0.431456714993146    real_avg 0.0539320893741433
 0.075359  0.043678  0.012149  0.167692  1.762870  1.231393  1.168980  1.262196  0.637806 -avg
p_total 5.72431731348044    p_avg 0.715539664185056

affinityを設定

T_CPU_Time 1.53125 	 T_CPU_AVG 0.032 	 E_Time 600.5 	 CPU 8
T_proc 24    P_Proc 73    Loop 50
idle 800.013987847462    real -0.0139878474618627    real_avg -0.00174848093273283
 0.110141  1.266414  0.138747  0.106933  0.018399  0.047626  0.140350  0.077092  0.191725 -avg
p_total 1.9057009997751    p_avg 0.238212624971888

個々のチューニング内容については次回以降説明します。
このチューニングため、出力のフォーマットを変更しています。ここでは、その内容について解説しておきます。

一行目。T_CPU_AVG(CPU実行時間から求められるCPU負荷)、その計算のベースになる経過時間(E_Time)とCPU数を追加。
二行目。プロセス数関連の情報を集めた行です。T_proc(一覧で表示される監視中に動いたプロセスの合計数です。本当のプロセスカットはこの数の削減が目的になるはずです)、P_Proc(毎回監視時のプロセス数を累計した実行総プロセス数)、Loop(ループ回数)。
三行目。get-counterで求められるidle(アイドルのCPU時間)とその逆数となるreal(実際に動いていた時間)とcpuあたりの平均値(real_avg)。
四行目。コア(CPU)毎のCPU負荷(パーセント)と平均(avg)。
五行目。三行目のコア(CPU)毎のCPU負荷の合計(p_total)とCPU数で割った平均値(p_avg)。p_avgは三行目のavgと同じになるはずなのですが、何故か一致しません。謎です(^^;;;。

チューニングのポイントとなる項を上記の引用した部分から取り出し、表にしてみましょう。

	実行プロセス数	平均プロセス数	累計プロセス実行時間	CPU負荷
インストール直後	72	5.34	37.73	1.397
jplay再生中	51	5.44	183.35	2.566
手作業でのOSチューニング	74	3.16	23.03	1.286
jplay再生中	51	5.6	10.32	1.483
自動+マルチ化チューニング	14	1.1	1.16	1.126
+8コア/8スレッド	16	0.96	1.11	0.948
jplay再生中	21	1.14	1.25	0.638
+affinty & jplay再生中	24	1.46	1.53	0.192

ご覧の通り、プロセス実行時間、プロセス数、CPU負荷など全ての面で数値が大幅に改善されています。大きい流れの部分で、細部は無視します。これを見ると、「JPLAYは 7になって、完成度は上がった。インストールするだけで、後は余計なことをする必要はない」という意見がありますが、チューニングは必要という感想ですね。詳細は次回以降解説します。

(PC_Audio) 2019/04/21

コメントする

JPLAYでCPU Affinityとプロセス優先度を設定する(6)

コア(CPU)数が6以上のシステムを導入し、試してみて分かったことを紹介します。「CPU Affinityとプロセス優先度」を延長戦です。

CPUはi7-8700Tとi9-9900Tです。i7-8700Tが6コア-12スレッド、i9-9900Tが8コア-16スレッド。どちらもTDPが35W。従って、比較的容量の小さい電源を使うことが出来ますので、電源の安定化がしやすいです。まあ、この低電源容量のTモデルだったから、レベルアップする気になったわけですが。「i9-9900Tなんてまだないだろう」という方はこちらをご参照ください。このESモデルを某所で get したのですよね。

写真はi9-9900Tを使っているパソコンの蓋を開けて写したものです。電源はご覧の通り、コンピュータケースの上においたローノイズ電源を使っています。エルサウンド社のDC12V10A (ピーク12A)のもの。最大160Wまでなので、i9-9900Tがギリギリ使えます。もちろん内蔵のディプレイチッブを使う、ディスクやPCIEボードは必要最小限に絞りこむなどの対策は必要です。160W対応のpicoPSU-160-XTというアダプター基板を使ってマザーボードやIOを繋ぐことになります。ディスクやPCIEボードは別電源という手法もとれますが、僕はそこまではやっていません。
この電源、大きさもありますが、重さもパソコン本体より思いです。
箱の中は電源なし、ボードなし、筐体のファンは全て外し、CPUファンは小型のもの、ということなので、ご覧の通りの伽藍堂。ディスクは6T音源用HD以外は全てSSD、Win10、WS2019デスクトップ、WS2019コアモードのマルチブートにする予定。ちょっと写真では分かりにくいですが、WS2019コアはマザーボード基板直付けのSATA DOM(SLC)に置くつもりです。PCIEポートはUSBカードとLANカード差してみるかなと思案中です。音楽専用にすると、箱の中は一般のパソコンとはかなり様相が変わりますね。
ワットチェッカーで稼働中の電力量を測りました。こんな感じですね。

モデル	無負荷時	音楽再生中	最大負荷
i9-9900T	30W	40W	145W
i7-8700T	20W	30W	65W

最大負荷とあるのはCINEBENCHでCPU性能測定中の値です。さすがにi9-9900Tだとかなりの値まであがります。逆に、i7-8700Tは65Wと意外に低い値です。こちらの方が、ローノイズ対策は簡単なのので、使いやすいかもしれませんね。僕がgetしたのはi7、i9共にベース動作周波数が1,70 GHzのESモデルなので、正式製品ではこの値は変わると思います。

本題のテーマに入ります。
コアが6以上、スレッドが12以上になった時に問題となるのは、コアとスレッドがどう対応しているかです。つまり

コア	C0-C5
対応するスレッド	S0-S11

として

C0	C1	C2	C3	C4	C5
S0	S1	S2	S3	S4	S5
S6	S7	S8	S9	S10	S11

なのか、それとも

C0	C1	C2	C3	C4	C5
S0	S2	S4	S6	S8	S10
S1	S3	S5	S7	S9	S11

ということなのかです。 8コアの場合は

コア	C0-C7
対応するスレッド	S0-S15

として

C0	C1	C2	C3	C4	C5	C6	C7
S0	S1	S2	S3	S4	S5	S6	S7
S8	S9	S10	S11	S12	S13	S14	S15

なのか、それとも

C0	C1	C2	C3	C4	C5	C6	C7
S0	S2	S4	S6	S8	S10	S12	S14
S1	S3	S5	S7	S9	S11	S13	S15

ということなのか。

実はこの件、コア数が2、スレッド数が4の時でも話題になっていて、以前に紹介したJPLAY欧州の掲示板のスレッドでやり取りがされています。
ただ、このスレッドは、読んで頂ければ、お分かりのように、Bernieさんの質問は2コア4スレッドの関係についてなのに、Marcinさんの答えはJPLAYのコア/スレッドへの割り当てについてとなっていて、問いと答えがズレています。NDAに縛られていて、ちゃんとは答えられないということなのですかね。
コア/スレッドの関係について、何故、ネットに情報がないのか、理由は不明です。コアとスレッドの対応を知ることはaffinityを効果的に設定するには必須の情報だと思いますが、答えはネットワークにありません。マイクロソフトによる解説が必要な問いなのに、答えのない理由は謎です。困ったものですね。

という訳で、マイクロソフトからの情報には期待できないので、以下の内容はまったく別のアプローチによる謎解きです。

別のアプローチとは仮想通貨のマイニングです。仮想通貨は、最近、暗号資産と呼ぶことになったらしい。ますます怪しげですね(^^;;;。未来を開く技術かもしれないのに、こんな呼び名でいいのだろうか。

実は、コアとスレッドの対応関係がどうやっても分からないものだから、「8コア16スレッドアフィニティ設定」というキーワードで検索したら、こんなサイト「BitZenyマイニングをCPUMinerのCPUアフィニティオプションで効率が上がる理屈が分からなかったので実践してみた」を発見。アフィニティの設定と仮想通貨のマイニングが関連しているとは夢にも思いませんでしたが、リンク先のページに答えが書いてありました。先程の表の下が正解なのですね。

調べて分かったことを紹介します。

仮想通貨のマイニング(採掘)とは通貨流通の整合性を確保するための検証作業のことで、膨大なコンピュータ計算量を必要とする処理です。仮想通貨はこの検証作業(計算)を第三者に行ってもらうことにより、その流通の安全性を確保しています。検証を行ってもらう第三者(ボランティア)には報酬として新規の仮想通貨を支払われる仕組みになっていて、世界各地で手をあげたボランティアが日夜膨大な計算量のコンピュータ処理を行っています。このあたり、「もうちょっと、ちゃんとした解説をしろ」という方にはこちらのページ「ビットコイン（Bitcoin）とは？」をお勧めします。
そういえば、この間、横浜地裁で判決の出たウィルス裁判もこの仮想通貨の計算に関するものですね。「ボーとネットを使っている」ユーザのパソコンを有効利用(悪用?)するプログラムを自分のウェブサイトに埋め込んだ作者が有罪か無罪か問われるというものでした。判決は「ボーと生きているヤツが悪い」と判断し、無罪ということでしたが、まあ当たり前でしょうね。

という訳で、この膨大なCPU計算処理を必要とする仮想通貨の世界がマルチコアマルチスレッドの謎を解いてくれました。
上記の「理屈が分からなかったので実践してみた」のページに書かかれているのは「8コア16スレッドのRyzen 7 1700システムで、16スレッド全部を使ってマイニング処理を行うと効率が悪くなる。理屈は分からないが、8コア8スレッドだけ使った方が効率が良い。不思議だなぁ」ということです。実は、これ、理屈は簡単で、「膨大なCPU計算がメインのマイニング処理の場合、8コア16スレッドにすると、CPUネックによるプロセス待ちが発生して効率が悪くなる。8コア8スレッドで動かせば、余計な待ちは発生せず、かえって効率がよくなる」というマルチCPU処理の基本原理をきれいに証明しているだけのことです。

具体的にはアフィニティの設定を

16進 FFFF
2進 1111111111111111 
10進 65535

より

16進 AAAA
2進 1010101010101010
10進 43690

とした場合の方が1割ほどハッシュ値(マイニング処理値)が上がるということです。 16進-2進-10進の変換はここのサイトを使いました。
同じような記述がこちら(論理コア制限でbitzenyマイニングの効率をあげる)やこちらにありました。
また、こちら(CPUがマルチコア・マルチスレッド過ぎてゲームが起動しない場合の対応方法)も参考になりました。

この書き込みの第一回目に書いたように16進(2進)のビットの配列がスレッドとコアに対応します。スレッド(コア)が9以上16以下となった場合、アフィニティの設定は16進の2バイトでスレッド(コア)の使用を表現することになります。この時、スレッド数=コア数であれば何の問題もなくて、16進ビット列の右側から0番のコア/スレッド、1番のコア/スレッド・・・と並ぶことになります。「理屈でなく実践」ページで分かったことは「スレッド数=コア数×2の場合、この並びが0番コア/0番スレッド、0番コア/1番スレッド、1番のコア/2番スレッド、1番のコア/3番スレッド、2番のコア/4番スレッド・・・という具合に並んでいく」ということです。
さて、ここまで分かれば、後は簡単です。省略してもいいのですが、次回に回します。

(PC_Audio) 2019/04/13

コメントする

JPLAY 7 で OSチューニング(2)(プロセス監視スクリプト)

ダウンロードする方法も考えましたが、内容を理解せずに使うことは考えられないスクリプトなので、コードをそのまま貼り付けることにします。

# process_snipper v0.3 © 2019/03/23 written by yo
Try {
# start
	Start-Transcript
	$loop = 50
	$mon_intval = 10
	$lsw = 0
	$elasped_time = 0
	$total = @{}
	$dif = @{}
	$dif_t = @{}
	$name = @{}
	$array = @()
	$idle_total = 0.0
	$s1 = 0.0
	$s2 = 0.0
	$s3 = 0.0
	$p_ctr = 0
	$core = (Get-WmiObject -Class Win32_Processor).NumberOfLogicalProcessors
# https://4sysops.com/archives/powershell-get-process-managing-processes/#viewing-cpu-and-memory-percentages
	$instances = Get-Process | Sort-Object CPU
	foreach ($i in $instances) {
		$total.Add($i.ID, $i.CPU)
		$dif_t.Add($i.ID, 0)
		$dif.Add($i.ID, 0)
		$name.Add($i.ID, $i.ProcessName)
		Write-Host ( $i.ID,"`t",$i.CPU,"`t",$i.ProcessName,$i.processoraffinity,$i.PriorityClass )
	}
# clear counter
	(Get-Counter -ListSet Process).Paths
	$d1 = (get-date)
	$d3 = (get-date)
	$d1

# loop
	while($lsw -ne $loop) {
#	while(1) {
		$cpu_t = 0
		$ctr = 0
		write-host `n
		Start-Sleep -Seconds $mon_intval
		$d2 = (get-date)
		$d2
		$d2 = $d2 - $d3
		$d3 = (get-date)
		$d2 = $d2.totalseconds
		$Num = $d2.ToString("0.0")
		$instances = Get-Process
		foreach ($i in $instances) {
			$key = $i.ID
			if ( $total.ContainsKey($key) ) {
				$dif.$key = $i.CPU - $total.$key - $dif_t.$key
				$dif_t.$key = $i.CPU - $total.$key
			} else {
				$total.Add($i.ID, 0)
				$dif.Add($i.ID, $i.CPU)
				$dif_t.Add($i.ID, $i.CPU)
				$name.Add($i.ID, $i.ProcessName + "`tadded")
			}
			if ($dif.$key -gt 0) { 
				$cpu_t += $dif.$key
				Write-Host $key,"`t",$i.CPU,"`t",$dif.$key,"`t",$name.$key,$i.processoraffinity,$i.PriorityClass
				$ctr += 1
			}
		}
		$p_t = (($cpu_t / $core) / $d2) * 100
		$p = $p_t.ToString("0.000")
		Write-Host "T_CPU_Time","$cpu_t","`t","A_CPU","$p","`t","N_Proc","$ctr","`t","intv","$d2"
		$p_ctr += $ctr
		$lsw += 1
<#
	Get-Counter '\Processor(*)\% Processor Time'
	Get-Counter '\Processor(*)\Interrupts/sec'
	Get-Counter '\Processor(*)\% Privileged Time'
	Get-Counter '\Processor(*)\% User Time'
	Get-Counter '\Processor(*)\% Interrupt Time'
参考 https://richardspowershellblog.wordpress.com/2011/02/22/performance-monitoring-with-get-counter/
https://devblogs.microsoft.com/scripting/use-powershell-to-check-your-servers-performance/
		$PrivilegedTime = (Get-Counter -counter "\Processor(*)\% Privileged Time”).CounterSamples.CookedValue
		$array += ,@($PrivilegedTime)
		$line = "Priv"
		foreach ($i in $PrivilegedTime) {

		$UserTime = (Get-Counter -counter "\Processor(*)\% User Time”).CounterSamples.CookedValue
		$array += ,@($UserTime)
		$line = "User"
		foreach ($i in $UserTime) {

		$InterruptTime = (Get-Counter -counter "\Processor(*)\% Interrupt Time”).CounterSamples.CookedValue
		$array += ,@($InterruptTime)
		$line = "Intr"
		foreach ($i in $InterruptTime) {
#>

		$s1 = 0.0
		$s2 = 0.0
		$CPUTime = (Get-Counter -counter "\Processor(*)\% Processor Time”).CounterSamples.CookedValue
		$array += ,@($CPUTime)
		$line = "Proc"
		foreach ($i in $CPUTime) {
			$Num = $i.ToString("0.000000")
			$line +="  $Num"
			$s1 += $s2
			$s2 = $i
		}
		$line += "-avg"
# add idle
		$CPUTime = (Get-Counter -counter "\Process(idle)\% Processor Time”).CounterSamples.CookedValue
		$s0 = 100.0 * $core - $CPUTime
		$s00 = $s0.ToString("0.000")
		$s10 = $CPUTime.ToString("0.000")
		$s40 = ($s0 / $core).ToString("0.000")
		$line1 = "idle $s10    real $s00    real_avg $s40"
		Write $line1
		Write $line
		$idle_total += $CPUTime
		$s3 = $s1 / $core
		$line1 ="p_total $s1    p_avg $s3 "
		Write $line1
<#
カウンターののクリア方法
Get-Counter -ListSet processor | Select-Object
(Get-Counter -ListSet Processor).Paths
(Get-Counter -ListSet Process).Paths
Get-Counter -ListSet process | Select-Object -ExpandProperty Paths
Clear-Host
参考https://forsenergy.com/ja-jp/windowspowershellhelp/html/20f5f2c0-d51b-4b5b-b423-384ac3abe544.htm
PowerShellのHelp　　Get-Counter

(Get-WmiObject -Class Win32_Processor).NumberOfLogicalProcessors
(Get-WmiObject -Class Win32_Processor).NumberOfCores
(Get-WmiObject -Class Win32_Processor).MaxClockSpeed

カンウターの意味については
https://superuser.com/questions/1303719/perfmon-cpu-usage-counters?rq=1
Perfmon CPU usage counters

使い方

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-counter?view=powershell-5.1
Get-Counter　　　Gets performance counter data from local and remote computers.

https://ss64.com/ps/get-counter.html
Get performance counter data from local and remote computers.

https://www.atmarkit.co.jp/ait/articles/1609/16/news035.html
Windows PowerShell基本Tips（8）：【 Get-Counter 】コマンドレット――システムのパフォーマンスを計測する

http://ujun.hatenablog.com/entry/2018/07/11/201832
PowerShell で基本的なコンピュータリソースのメトリクスをとる(プロセスごと)
#>
	}
} Finally {
	write-host `n
	$cpu_t = 0
	$name_l = @{}
	$instances = Get-Process
	foreach ($i in $instances) {
		$key = $i.ID
		if ( $total.ContainsKey($key) ) {
			$dif.$key = $i.CPU - $total.$key - $dif_t.$key
			$dif_t.$key = $i.CPU - $total.$key
		} else {
			$total.Add($i.ID, 0)
			$dif.Add($i.ID, $i.CPU)
			$dif_t.Add($i.ID, $i.CPU)
			$name.Add($i.ID, $i.ProcessName + "`tadded")
		}
		$name_l.Add($i.ID, $i.ProcessName)
	}
	$dif_t = $dif_t.GetEnumerator() | sort -Property value -descending
	$ctr = 0
	foreach($entry in $dif_t){
		$key = $entry.Key
		$value = $entry.Value
		$cpu_t += $value
		if (-not ($name_l.ContainsKey($key))) { $name.$key += "`tremoved" }
		if ($entry.Value -gt 0) {
			 Write-Host $key,"`t",$value,"`t",$name.$key,$i.processoraffinity,$i.PriorityClass
			$ctr +=1
		 }
	}
	$d2 = (get-date)
	$d2 -= $d1
	$d2 = $d2.totalseconds
	$Num = $d2.ToString("0.0")
	$p_t = (($cpu_t / $core) / $d2) * 100
	$p = $p_t.ToString("0.000")
	Write-Host "T_CPU_Time","$cpu_t","`t","T_CPU_AVG","$p","`t","E_Time","$Num","`t","CPU","$core"
	$p = $p_ctr / $loop
	$line0 = "T_proc $ctr    ATR_proc $p    TR_proc $p_ctr    Loop $loop"
	for ( $j = 0; $j -lt $array.Length; $j++ ) {
		if ($j -eq 0) {
			$avg = $array[$j]
		} else {
			$ctr = 0
			foreach($entry in $array[$j]){
				$avg[$ctr] += $entry
				$ctr += 1
			}
		}
	}
	$line = ""
	$s1 = 0.0
	foreach($entry in $avg){
		$avg_l = $entry/$lsw
		$s1 += $avg_l
		$Num = $avg_l.ToString("0.000000")
		$line +=" $Num "
	}
	$idle_total = $idle_total/$lsw

	$s0 = 100.0 * $core - $idle_total
	$s1 -= $avg_l
	$s3 = $s1 / $core
	$s4 = ($s0 / $core)
	$line1 = "idle $idle_total    real $s0    real_avg $s4"
	Write $line1

# 数字の整形 $Num.ToString("0.00")
# http://www.vwnet.jp/Windows/PowerShell/Format.htm
	$line += "-avg"
	Write $line
# add idle
	$line1 = "p_total $s1    p_avg $s3 "
	Write $line1
	Write $line0
	Stop-Transcript
}

著作権は主張しますので、そのまま転載される場合はメールでご連絡ください。
内容については次回以降に解説します。

(PC_Audio) 2019/04/06

コメントする

JPLAY 7 で OSチューニング(1)

このシリーズは、長くなります。そして、どうチューニングすればいいのかは最後の方に解説されることになります。レジメはこんな感じです。

パワーシェルによるプロセス監視スクリプトの処理内容
プロセス監視スクリプトの使い方
プロセス監視スクリプトのアウトプットの読み方
プロセス監視スクリプトを使って、チューニングする方法
チューニングするためのツール
CADスクリプトの紹介
CADスクリプトの使い方
手動でのチューニング
自動でのチューニング
まとめ

従来のプロセスカットはOSの動きを無視し、プロセス数の少なさだけを誇るという信仰によるものであり、あまり意味はないと思います。従って、前半でプロセス監視スクリプトについて詳述します。実際にOSがどのうように動いているか知った上で、対策をたてる方法について説明します。
後半はその分析を前提とした上で、BernieさんのレポートとCAD社のスクリプトをどのように使うかを解説します。
従って、具体的なチューニングの話は最後の二つの項に入ってからです。気の短い読者は「いったい何時になったらチューニングの話になるのだ」と怒りはじめるかもしれません。

というわけで、最初に簡単に何をチューニングしたのかと内容について書いてから本論に入り、本論の中でも行ったチューニングを例として取り上げながら解説するという方法をとろうと思います。

それでは、まずどういうチューニングをしているかという内容を解説無しに紹介します。
この内容はあくまで現時点で行っているものです。かなり長い連載になるので、途中で変化が発生するかもしれませんが、ご了解よろしくです。

手動でやったのは

①設定メニュー・・画面真っ黒け、色-トランスピアレントオフ、ウィンドウス音なし、システム-通知とアクション、時刻の自動修正オフ、システム-マルチタスク-タイムライン、プライバシィ全般-無効、バックグラウンド実行-なし、アカウント情報-アプリアクセス有効以外は全てオフ
②コントロールパネル・・電源パフォーマンス最大、自動再生なし、OneDriveの削除、Windows機能の無効化(.net、samba、powershell、remote接続、media機能以外)
システムのプロパティ・・視覚効果無し、システムの保護無効、ページング無し
③cのプロパティ・・デフラグスケジュールオフ
ファイルインデックスの無効化、

自動(スクリプト)でやったのは
④ストアアプリを可能な限り退治(自作ps1スクリプト)
⑤Cortanaの無効化
⑥Windows Defenderの無効化、Automatic Maintenaceの無効化(Bernieさんのレポートにあるもの)
⑦MS-Storeそのものの無効化(自作cmdでレジストリ操作、このスクリプトは⑥の無効化もいっしょに出来ます)
⑧CADスクリプト(プロセスカット部分とWindows機能カット部分はカット)を実行

というところです。

手動の内容については、説明は省略します。

自動のスクリプトですが、ストアアプリの退治スクリプトは以下の通りです。

Get-AppxPackage king.com.CandyCrushSodaSaga | Remove-AppxPackage
Get-AppxPackage Microsoft.BingWeather | Remove-AppxPackage
Get-AppxPackage Microsoft.Wallet | Remove-AppxPackage
Get-AppxPackage Microsoft.WindowsSoundRecorder | Remove-AppxPackage
Get-AppxPackage Microsoft.Office.Sway | Remove-AppxPackage
Get-AppxPackage Microsoft.WindowsStore| Remove-AppxPackage
Get-AppxPackage Microsoft.MicrosoftStickyNotes | Remove-AppxPackage
Get-AppxPackage Microsoft.MicrosoftSolitaireCollection | Remove-AppxPackage
Get-AppxPackage Microsoft.Print3D | Remove-AppxPackage
Get-AppxPackage Microsoft.Office.OneNote | Remove-AppxPackage
Get-AppxPackage Microsoft.Windows.Photos | Remove-AppxPackage
Get-AppxPackage Microsoft.People | Remove-AppxPackage
Get-AppxPackage Microsoft.MSPaint | Remove-AppxPackage
Get-AppxPackage Microsoft.BingNews | Remove-AppxPackage
Get-AppxPackage Microsoft.ZuneVideo | Remove-AppxPackage
Get-AppxPackage Microsoft.Microsoft3DViewer | Remove-AppxPackage
Get-AppxPackage Microsoft.Messaging | Remove-AppxPackage
Get-AppxPackage Microsoft.WindowsMaps | Remove-AppxPackage
Get-AppxPackage microsoft.windowscommunicationsapps | Remove-AppxPackage
Get-AppxPackage Microsoft.ZuneMusic | Remove-AppxPackage
Get-AppxPackage Microsoft.Getstarted | Remove-AppxPackage
Get-AppxPackage Microsoft.SkypeApp | Remove-AppxPackage
Get-AppxPackage Microsoft.Microsoft OfficeHub | Remove-AppxPackage
Get-AppxPackage Microsoft.GetHelp | Remove-AppxPackage
Get-AppxPackage Microsoft.WindowsFeedbackHub | Remove-AppxPackage
Get-AppxPackage Microsoft.WindowsCamera | Remove-AppxPackage
Get-AppxPackage Microsoft.WindowsCalculator | Remove-AppxPackage
Get-AppxPackage Microsoft.DesktopAppInstaller | Remove-AppxPackage
Get-AppxPackage Microsoft.WindowsAlarms | Remove-AppxPackage
Get-AppxPackage Microsoft.3DBuilder | Remove-AppxPackage
Get-AppxPackage king.com.CandyCrushSodaSaga | Remove-AppxPackage
Get-AppxPackage Microsoft.XboxApp | Remove-AppxPackage
Get-AppxPackage Microsoft.OneConnect | Remove-AppxPackage
Get-AppxPackage Microsoft.StorePurchaseApp | Remove-AppxPackage
Get-AppxPackage Microsoft.TCUI | Remove-AppxPackage
Get-AppxPackage Microsoft.XboxGameOverlay | Remove-AppxPackage
Get-AppxPackage Microsoft.XboxIdentityProvider | Remove-AppxPackage
Get-AppxPackage Microsoft.XboxSpeechToTextOverlay | Remove-AppxPackage

Get-AppxPackage *3d* | Remove-AppxPackage
Get-AppxPackage *bing* | Remove-AppxPackage
get-appxpackage *Microsoft.ZuneMusic* | remove-appxpackage
Get-AppxPackage *phone* | Remove-AppxPackage
Get-AppxPackage *solit* | Remove-AppxPackage
Get-AppxPackage *messaging* | Remove-AppxPackage
Get-AppxPackage *BingHealthAndFitness* | Remove-AppxPackage
Get-AppxPackage *BingFoodAndDrink* | Remove-AppxPackage
Get-AppxPackage *BingTravel* | Remove-AppxPackage
Get-AppxPackage *twitter* | Remove-AppxPackage
Get-AppxPackage *photo* | Remove-AppxPackage
Get-AppXPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

remove-appxpackage Microsoft.Wallet_2.2.18179.0_x64__8wekyb3d8bbwe

ネットで見つけた、いくつかのスクリプトのパッチワークです。

Cortanaの無効化の無効化はリンク先を参照して下さい。
Bernieさんのレポートはここからダウンロードできます。⑥と⑦のスクリプトは以下の通りです。

rem
rem additional registry edit for Win10 store app
rem added Sept.2019
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AppXSvc" /v Start  /t REG_DWORD /d 4 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PimIndexMaintenanceSvc" /v Start  /t REG_DWORD /d 4 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PimIndexMaintenanceSvc_374fb" /v Start  /t REG_DWORD /d 4 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TimeBrokerSvc" /v Start  /t REG_DWORD /d 4 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\UnistoreSvc" /v Start  /t REG_DWORD /d 4 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\UnistoreSvc_374fb" /v Start  /t REG_DWORD /d 4 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\UserDataSvc" /v Start  /t REG_DWORD /d 4 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\UserDataSvc_374fb" /v Start  /t REG_DWORD /d 4 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\UsoSvc" /v Start  /t REG_DWORD /d 4 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinHttpAutoProxySvc" /v Start  /t REG_DWORD /d 4 /f
reg import c:\Turn_Off_Windows_Defender_Antivirus.reg
reg import c:\Disable_Automatic_Maintenance.reg
rem
rem additional restory edit if you want ultimate
rem
rem reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\cbdhsvc" /v Start  /t REG_DWORD /d 4 /f
rem reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CDPUserSvc" /v Start  /t REG_DWORD /d 4 /f
rem reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WpnUserService" /v Start  /t REG_DWORD /d 4 /f
pause

⑧に関連する情報はここにあります。

echo   Disabling OVER 180 drivers and services...

から

echo	All Features tuned OFF

までの行をカットします。

プロセス監視スクリプトは次回に紹介します。

p.s. JPLAY 7 は認証機能の都合でOSのチューニングに制限が付くようになりました。この制限に引っかかると、LicenseExpiredゴジラが登場、インストールし直さないと使えないというハメになります。上記の項目の中でも(特に①と⑧)、この制限に対する理解なしに対策すると、悲惨な運命が待ち受けています。この記事を読んで、試してみようという無謀な方は、全て自己責任で、ご覚悟の上、試練の道を歩んで下さいませ。

(PC_Audio) 2019/03/30

コメントする

GPSDOクロックジェネレータ(2)

前回に続き、GPSDOクロックジェネレータのモニター機能の使い方を紹介します。
まず、パソコンとクロックの繋ぎ方から。

今どきのパソコンはシリアル接続はUSBだけというのが当たり前でRS232C端子をもったものはほとんど存在しません。昔はスキャナーやプリンターなどシリアル接続するものはRS232C端子で繋いでいたのですが、現在は全てUSBで置き換わっていますね。
しかし、ネットワークの世界ではこの接続規格はしぶとく生き残っています。理由はLinuxを使ったSOCでこの規格がパソコンとの接続のディフォルトだからです。Linuxで動くルータなどにRS232C接続でバソコンと繋げることが出来るものがあります。GPSDOクロックジェネレータがRS232C端子でパソコンと接続できるようになっているのも、同じ理由だと思います。

さて、RS232C端子を持たないパソコンとクロックの接続方法ですが、答えは簡単でUSB-シリアル(RS232C)の変換ケーブルを使うです。この件、以前に書き込んだことがあります。ここを参照して下さい。
リンク先はパソコンとパソコンの接続なのでクロスケーブルを使っていますが、クロックとの接続では、クロック側でINとOUTの反転は考慮されているようなので、クロスケーブルは不要です。

繋いだら、とりあえずデータのやりとりが出来るかどうか確認します。
TeraTermやPuttyを使うのがお勧めです。ここではTeraTermを使う方法を紹介します。
TeraTermを立ち上げ

設定 > シリアルポート

シリアルポート設定画面を表示させます。COMポートとボーレート=9600を指定します。僕の環境ではそれ以外のパラメータははディフォルトのままでOKでした。

上記の設定画面はTeraTermを立ち上げ時に「新しい接続」画面をキャンセルさせることで選択できます。GPSDOクロックジェネレータの接続を確認する場合はこの「新しい接続」画面でシリシル接続を選択します。

という具合です。正しく接続されていれば

こういう具合に衛星から送られてくるデータが連続されてログ表示され続けます。
このログデータはNMEAと呼ばれる標準化された規格のフォーマットで出力されます。規格の説明はこちら(WikiPedia)、フォーマットを解説しているサイトはこちら(GPSのNMEAフォーマット)がお勧め。

しかし、このログだけでは何のことやらですから、これを解析するプログラムが必要です。僕が使っているのはVisualGPSViewというプログラムです。
このプログラムはPayPalで支払い可能な5ドルのdonationwareです。
なかなか高機能で、面倒なので、サイトの情報をそのまま貼り付けます。

VisualGPSView (Freeware) incorporates many advanced features that show the status of the GPS receiver via the NMEA 0183 protocol. Its sole purpose is to display graphically specific NMEA 0183 sentences for GPS and position analysis. Features: - NMEA/GLONASS - Supports GPS NMEA and GLONASS NMEA - Azimuth and Elevation Plot - View all satellites that are in view. Each satellite identifies its pseudo random number (PRN) and its azimuth and elevation. - Scatter Plot - The scatter plot shows individual position samples referenced to several type of reference types, next sample, average or user defined. - Signal Quality/SNR Window - Monitor satellite signal to noise ratios and see them graphically on the screen. The signal quality window will grow or shrink to accommodate number of satellites in view - Position Plot - Monitor latitude, longitude and altitude averages. - NMEA Command Monitor - View NMEA sentences as they are received - NMEA Recording and Playback - Record NMEA directly to a file or read NMEA from a file. NMEA files consists of standard NMEA sentences in text ASCII characters. Requirements: GPS Receiver connected to a RS-232 port or USB with NMEA 0183 output Windows 7 to Window 10 VisualGPS decodes the following NMEA 0183 sentences: GPGGA and GLGGA GPGSA and GLGSA GPGSV and GLGSV

画面を紹介します。
Azimuth and Elevation Plot 画面です。View all satellites that are in view. Each satellite identifies its pseudo random number (PRN) and its azimuth and elevation. ということです。

Scatter Plot 画面です。The scatter plot shows individual position samples referenced to several type of reference types, next sample, average or user defined.ということです。

次にPosition Plot画面ですが、これはGPSDOクロックジェネレータの性能を示す興味深い画面となりますので、最後にお見せします。

GPSDO規格は標準化されているわけですから、他にも様々なプログラムがあります。いくつか紹介します。

Lady Heather’s Disciplined Oscillator Control Program: This program monitors and controls the operation of various GPS-disciplined frequency standards.
u-center - GNSS evaluation software for Windows: Highly interactive and easy to use
Full support of all u‑blox GNSS receivers
Extensive configuration an d control features
Real‑time display from a GNSS receiver via RS232 and USB interface

試してみましたが、どちらもお勧めですね。GPSDOの使い方の目的によって使い分けるということになるかと思います。

前回も書きましたが、オーディオ専用のGPSDOにはこのRS232C端子への出力が省略されています。従って、このモニタ機能が使えません。「オーディオ用にこんな機能は不要だ」ということなのでしょうが、残念ですね。オーディオ用にも使えると思います。

という訳で、最後にオーディオ用にこの機能を使って、電源の重要性を示すグラフをお目にかけます。
先程のPosition Plot画面を二つの電源で表示させたものです。経度、緯度の情報表示部分は3cm誤差で分かってしまうので、隠してあります。

まず最初はディフォルトの電源で動かしたもの。
このGPSDOは12V1ADCの電源で動きます。入手したものには安価なスイッチング方式のDCアダプターが付いています。一応、これを使っても動きますが、その時のグラフです。

次に電源部分を強化させた状態で動かしたもの。
安定化電源を使うかなと思っているのですが、空いているものがないので、とりあえずIFI社のDCフィルターを使ってみました。このフィルターは聴感では結構効果があって、使いやすいので、予備用にいくつか持っています。余っていたものが一つあったので、DCアダプターと本体の間に入れてみました。その時のグラフです。

違いは一目瞭然かと思います。後者の方が精度が出ていることが、こんなに明快に分かるとは思いませんでした。

(PC_Audio) 2019/03/23

コメントする

GPSDOクロックジェネレータ(1)

SoulNote D-2にGPSDOクロックジェネレータを繋いでみました。

本題に入る前に、例によってちょっとだけ、脱線です。D-2チューニング講座。

D-2だけではなく、SoulNote製品は置き場所と置き方にシビアに反応するようです。写真には全部は写っていませんが、僕はここ(言の葉の穴、SOULNOTE)にある教えに従い、次の三つの対策を実施しています。

オーディオラックに入れない
写真でご覧の通りで、アナログプレーヤ用に使っていた台の上に設置し、手元に置いて、簡単にボタン操作できるようにしています。DSD再生時に簡単にNOSスイッチの切替が手元で出来るので、重宝しています。
樺の板の受け台をに置く
これも写真の通りですが、台の上に厚さ30mmの樺の板を置いています。樺の板はネットで簡単に入手できますね。僕はここ【木材加工.com】で注文しました。塗装などの加工もやってくれるので、お勧めです。
マグネシウムスパイイク受けを使う
写真では写っていませんが、スバイク受けはマグネシウム製のものを使っています。ここ(SOULNOTE A-2 × サンシャインの純マグネシウムスパイク受け「S1」)を参照してください。

置き方で音が変わるなんてオカルトだろうと言われそうですが、これだけは本当に効果があるので、やむおえません。CSR本社でD-2を試聴しましたが、同じような置き方をしていてました。設計者ご推奨の置き方らしいです。
GPSDOクロックジェネレータは画面左上に見えます。ケーブル長を考慮するとそばに置きたいのですが、クロックジェネターとDACの距離は音の良さに比例するということなので、多少距離をとって置いています。

本題に戻ります。
外部クロックを繋ぐことで、DACの音調がガラリと変身することは、以前、フェーズメーションのDACを使っていた時の経験していたので(ここにその時書いた記事があります)、「試してみよう」と以前から考えていたのですが、クロックジェネレータって、それなりの価格なので、ほっておいたのですよね。

ある人から「通信機器用のGPSDOタイプの安いやつがあるよ」と教えてもらい、興味を持ちました。
通信機器用ですから、値段がオーディオ用より一桁低い。20K円以下で入手できそうです。これは試してみる一手だなと思いました。

GPSDOとはGlobal Positioning System disciplined oscillatorの略称です。要するにGPSを基準に使った周波数発生器(oscillator)ということ。そんなもん何に使うのかと言うと、通信の世界では、スペクトラム・アナライザなどの測定器や無線機の校正(計器類の狂いや精度を標準器と比べて正すこと)に使うということらしいです。

この通信用のGPSDOは10MHzの基準となる正弦波をクロックとして出力します。従って、オーディオ用のDACに外部から10MHzの基準クロックを受ける機能があれば、通信用のGPSDOであっても、オーディオ用として使うことが出来ます。オーディオ用のクロックジェネレータに求められるのは精度ですから、通信の世界で必要とされるクロック性能(10の11乗以上)であれば、オーディオ機器の内部クロックの精度を二桁以上上回るので、十分使えるということらしいです。
GPSの仕組みについての解説は、とても僕の手に負えるものではないので、WikiPediaからそのまま引用します。

GPS衛星からの信号には、衛星に搭載された原子時計からの時刻のデータ、衛星の天体暦（軌道）の情報などが含まれている。GPS衛星からの電波を受信し、その発信時刻を測定し、発信と受信との時刻差に、電波の伝播速度（光速）を掛けることによって、その衛星からの距離がわかる。もしもGPS受信機に搭載されている時計の誤差が100万分の1秒あったとしたら、距離の誤差は300mにも及んでしまう。そこで、多くの受信機は4つ以上のGPS衛星からの電波を受信することで現在時刻を頻繁に校正し、正確な受信時刻と受信機座標（3次元空間上の点）とを測位計算により同時に求める。

なるほど、ということは10の11乗の精度とは3cmということになりますね。金正恩暗殺計画、これなら十分ピンポイントに狙えるわけです。じゃあなくって、オーディオの話でしたね。

以上このあたりはこちらの記事(GPS10MHzクロックのマジック)で丁寧に解説されていますので、ご参照ください。オーディオ用のサイトですが、分かりやすく解説されています。偶然ですが、リンク先のサイトで紹介しているGPSDOは僕がgetしたのと同じメーカー(中国製)のハードです。

GPSはいまや何にでも入っているわけで、これを使って道案内とか自動運転をしようという時代に入っています。従って、当然それなりの精度が求められる。そのための技術開発は日進月歩です。また大量にチップが出回るわけで、コストダウンが進み、安くなる。
これを精度が求められる世界に転用しようというのは、当然の発想ですね。それで、通信の校正の世界に転用されたのが GPSDO です。それをそのままオーディオ用に使っちゃおうということです。「他人の褌で相撲をとる」ことになる。「音が良くて、安ければ、人の褌だろうと誰の褌だろうとかまわない」(^^;;;という人には大歓迎となります。

以上がGPSの説明です。次にD(O)ですね。disciplinedって何だろう。

これも面倒なので、Wikiからそのまま引用。ただし英語しかありませんでした。

A GPS clock, or GPS disciplined oscillator (GPSDO), is a combination of a GPS receiver and a high-quality, stable oscillator such as a quartz or rubidium oscillator whose output is controlled to agree with the signals broadcast by GPS or other GNSS satellites. GPSDOs work well as a source of timing because the satellite time signals must be accurate in order to provide positional accuracy for GPS in navigation. These signals are accurate to nanoseconds and provide a good reference for timing applications.

「なんだfemtoじゃないのか」なんて文句をいわないこと。校正すればfemtoに出来るということです。
念の為、このfemtoはJPLAYfemtoのことではありません。字義通りのfemtoです。英文をちゃんと読んで下さいね。
ほんとに数センチレベルの誤差で場所を特定できるのかについては、この記事が面白いです。「GPS 精度」でググると、関連する記事が出てきますが、このトピックの最前線を興味深く知ることが出来ます。

クロックジェネレータというのは使い方も何も無くて、ただ繋ぐだけ。あとは、電源を入れて、じっと待つということになります。なんで、「じっと待つ」かというと、動作が安定するまでに、多少時間がかかるからです。僕が入手したハードでは10分位かかります。高い精度で安定動作となると、もう少し時間が必要なようで、後でグラフをお見せしますが、1時間以上たつと、真価が発揮されるようになります。というわけで、環境にはやさしくないが、電源を入れっぱなしという使い方がお勧めかもしれません。
しかし、車の自動運転なんかで、安定するまでにこんなに時間がかかるとすると、安定するまでの間は事故が多くなるなんてことはないのだろうか不安ですね。当然対策はとられているのでしょうが。

繋ぎ方で要注意なのはBNCケーブルのインピーダンスのマッチングです。D-2の場合は50Ωだったので、問題はありませんでした。

以上ここまでが、テクニカルバックグラウンドのご紹介でした。

ハードはYahoo!オークションで入手しました。getしたハードの情報はここ(bg7tbl gpsdo master reference)にあります。このフォーラムもオーディオ用ではなく通信機器用ですね。このスレッド、bg7tblというこの機種の情報を集めるために作成されたようですが、よくこれだけ書き込まれているなぁと感嘆するレベルで情報があります。中国製のハードなので、情報が不足するから、それをこのフォーラムで補っているということだと思います。

GPSDOのの性能はGPSとOCXOに何が使われているかによって決まります。フォーラムの情報によれば、僕の持っている2016-05-31型の場合、OCXOはBLILEYのNVG47A1282が、GPSはu-bloxのNEO-7が使われているようですね。リンク先の情報を調べると、まあまあの性能のハードが使われているようです。

このハード特徴は何かというとシリアルポートを持っていることです。
「あれれ、これ何だろう」と思い、調べたら、ダウンロードしている校正用のデータのログをここからモニター出来るらしいと分かり、俄然興味が出て来ました。もちろんパソコンを使う必要がありますが、モニター用のソフトはフリーのものが存在するようです。
普通のオーディオ用のGPSDOでシリアルポートを持っているものはありません。さすが、通信機器用ですね。これなら、こちらを選ぶ意味があります。

オーディオ用のGPSDOクロックジェネレータがルビジウムなどを使った単体のクロックジェネレータに対して優位である言われている点は二つあります。

ルビジウムのような不安定な物質を使っていないので、校正なしで長期間安定して使える。
衛星のデータを使い精度を確保しているので、ウォームアップ時間を短く出来る。

実は、僕にはこの二つのメリットがあまりピンときませんでした。一番目のメリットは実際にルビジウム製のクロックジェネレータを使っていて、そのようなことは無し、二番目のメリットは電源を入れっぱなしにすれば、問題は無し、だったので。
しかし、このモニター機能は魅力的ですね。これならGPSDOタイプのクロックジェネレータを選ぶ意味がありそうです。オーディオ用にこの機能が無いのなら、通信用を選ぶ一手です。

という訳で、それまでは、GPSを使わない単品のOCXOやDOCXOを使ったクロックジェネレータを捜していたのですが、この情報を知って、通信機器用のシリアルポートを持つハードを捜すことにしました。当然、AliExpressとかE-Bayにはゴロゴロしています。国内だと雑誌社が無線雑誌とセットで発売しているものとか、海外からの輸入品とか、いろいろありますが、Yahoo!のオークションで安価に提供されているものがあり、最終的にオークションでgetしました。

D-2に繋いでの音ですが、最初に書いたフェーズメーションでルビジウムタイプのジェネレータを使った時と同じような感想です。繋ぐと、分解能があがり、鮮度が高くなります。また、空間が広がったという感じ。
オーディオにGPSDOを使った場合のメリットとして、精度、長期間の使用での安定性と並んで、ウォームアップに要する時間が短時間であることが言われますが、それ程でも無いですね。ある程度まとも音になるのに1時間位はかかりますし、十分に安定したといえる状態は2時間位ですかね。

便利なのは、先程書いたRS232Cによるモニター機能を使うと、このウォームアップ状態をモニター出来ることです。また例えば、電源環境を変えた時の変化なども、モニター機能により目でみることが出来ます。
このあたり面白いので、紹介しようと思いますが、長くなったので、次回に。

(PC_Audio) 2019/03/16

コメントする

JPLAYでCPU Affinityとプロセス優先度を設定する(5)

前回の表をもう少し情報を足して、書き直します。

JPLAYfemtoです。

threads	1244	1252 1436 5368 6052	4556 4536 2468	6056		6068		5372	8632
	User	6044 6048 6060 6064	2464 8276	User	Privileged	User	Privileged	Privileged	-
一回目	0.0468750	0	0	0.078125	0.09375	0.031250	0	0	-
最終回	0.0468750	0	-	0.296875	0.25000	0.171875	0.015625	0.015625	0
差分	0	0	0	0.218750	0.15625	0.140625	0.015625	0.015625	0
合計	0	0	0	0.375000	-	0.156250	-	0.015625	0

JPLAYです。

threads	1244	1468		5192		3516	9740
	User	User	Privileged	User	Privileged	-	-
一回目	0.015625	0.5000	5.062500	0.062500	0.109375	0	-
最終回	0.015625	0.5000	5.234375	0.078125	0.109375	-	0
差分	0	0	0.171875	0.015625	0	0	0
合計	0	-	0.171875	0.015625	-	0	0

ffmprgは再生中の起動毎にスレッドが一新するので、スレッドが消滅する直前のログをそのまま編集せずに引用します。

  Id TotalProcessorTime UserProcessorTime PrivilegedProcessorTime ThreadState     WaitReason
  -- ------------------ ----------------- ----------------------- -----------     ----------
8324 00:00:00.0156250   00:00:00.0156250  00:00:00                       Wait ExecutionDelay
 352 00:00:00           00:00:00          00:00:00                       Wait        Unknown
8916 00:00:00           00:00:00          00:00:00                       Wait        Unknown
9144 00:00:00           00:00:00          00:00:00                       Wait   EventPairLow

  Id TotalProcessorTime UserProcessorTime PrivilegedProcessorTime ThreadState     WaitReason
  -- ------------------ ----------------- ----------------------- -----------     ----------
1188 00:00:00.0781250   00:00:00.0781250  00:00:00                       Wait ExecutionDelay
3596 00:00:00           00:00:00          00:00:00                       Wait        Unknown
4872 00:00:00           00:00:00          00:00:00                       Wait        Unknown

  Id TotalProcessorTime UserProcessorTime PrivilegedProcessorTime ThreadState     WaitReason
  -- ------------------ ----------------- ----------------------- -----------     ----------
6952 00:00:00.0312500   00:00:00.0312500  00:00:00                       Wait ExecutionDelay
2792 00:00:00.0312500   00:00:00.0312500  00:00:00                       Wait        Unknown
2760 00:00:00           00:00:00          00:00:00                       Wait        Unknown

CPUはさすがにi5ですね。jplayfemto-6056 375ms、jplayfemto-6068 156.25ms、jplayfemto-5372 (pのみ) 15.625ms、jplay-1468(pのみ) 171.875ms、jplay- 5192 15.625ms、ffmpeg(uのみ) 125ms と全て0.1%以下の値です(0.1%が500ms)。全部足しても、859.325msです。CPU負荷1.7%位です。この窓口負荷の状態で、待ち行列理論の窓口(サーバ)数=4、客(プロセス)数=6+α(一般プロセス)ですから、ほとんど待ちが発生しないことになります(計算はしていませんが、待ちが発生する確率は1%以下のはずです)。
従って、待ち行列理論からいうと、この数値であれば、特別なCPUアフィニティを設定する必要はないです。

ただし、一般プロセスによる不確定な要素を排除するために、一般プロセスとffmpegを2番のCPUに限定させ、0番、1番、3番をJPLAYfemtoとJPLAYのスレッドに専用化させれば、より安定した状態が期待できるかもしれないです。
いい加減な計算ですが^^;;;、0.75×0.031×0.34×0.25=0.002%ですね。5万回に一回ですから、一秒間に500回、プロセス走るとして(まったくの根拠のない推定です、こんなに多くはないと思います)、100秒で1回待ちが発生するかどうかということになります。この組み合わせは試してみる値打ちはありそうです。スクリプトはこんな具合になります。

$instances = Get-Process
foreach ($i in $instances) { 
	$i.ProcessorAffinity=4
	$i.PriorityClass='idle'
}
(Get-Process -name jplay).ProcessorAffinity = 11
(Get-Process -name jplay).PriorityClass = 'Realtime'
(Get-Process -name JPLAYfemto).ProcessorAffinity = 11
(Get-Process -name JPLAYfemto).PriorityClass = 'Realtime'

もう一つ面白そうな設定はJPLAYfemtoとJPLAYのスレッドの使えるCPUをさらに限定する方法です。具体的にはJPLAYはディフォルトで1番になっていますので、これをそのまま使い、JPLAYfemtoを0番と3番に専用化させます。スクリプトはこんな具合になります。

$instances = Get-Process
foreach ($i in $instances) { 
	$i.ProcessorAffinity=4
	$i.PriorityClass='idle'
}
(Get-Process -name jplay).ProcessorAffinity = 2
(Get-Process -name jplay).PriorityClass = 'Realtime'
(Get-Process -name JPLAYfemto).ProcessorAffinity = 9
(Get-Process -name JPLAYfemto).PriorityClass = 'Realtime'

もちろん、これら設定は僕の環境の状態を考慮して決めたものですから、僕の環境でのみ有効です。他の環境では同じようにスクリプトを動作させ、状態を見ながら決めるということになります。結局、CPU Affinityとプロセス優先度については、これで決まりという単一の解はないので、自分の環境に合わせて決めることになります。

CPU Affinityについては「何故、こんなものをユーザが自由に設定できるようにしているのか」という疑問があります。OSのアフィニティの設定に関する必要情報が公開されていないのに、ユーザーがアフィニティを勝手に決めても、思ったような動きになるとは限らないからです。

僕の環境での例をあげて、説明したいと思います。
パワーシェルによるプロセス監視スクリプトのアウトプットを使って解説します。このスクリプトはOSのチューニング用に作成したものですが、最後に監視中に動いた全てのプロセスの実行時間と実行中のCPU別の平均負荷を表示するようにしています。この最後の部分をOSのチューニング後とチューニング前を比較してお見せします。最終行がコア(CPU)別のCPU負荷で、左から 0、1、2、3、システム全体の平均と並んでいます。使っているパソコンはWindows10 201809版をインストールしただけの音楽専用PCです。

チューニング後です。

2019年1月23日 19:19:07
1452 	 2.109375 	 powershell 4 Idle
3312 	 1.140625 	 svchost 4 Idle
1300 	 0.8125 	 jplay 4 Idle
1256 	 0.390625 	 conhost 4 Idle
1308 	 0.375 	 JPLAYfemto 4 Idle
4 	 0.328125 	 System 4 Idle
2060 	 0.171875 	 svchost 4 Idle
584 	 0.15625 	 csrss 4 Idle
500 	 0.140625 	 dwm 4 Idle
2412 	 0.109375 	 dasHost 4 Idle
1852 	 0.109375 	 atieclxx 4 Idle
5128 	 0.078125 	 explorer 4 Idle
688 	 0.078125 	 services 4 Idle
884 	 0.0625 	 svchost 4 Idle
2636 	 0.046875 	 svchost 4 Idle
1000 	 0.03125 	 svchost 4 Idle
4916 	 0.03125 	 svchost 4 Idle
2376 	 0.03125 	 svchost 4 Idle
1392 	 0.03125 	 svchost 4 Idle
1684 	 0.03125 	 svchost 4 Idle
3548 	 0.03125 	 ffmpeg	added	removed 4 Idle
6400 	 0.015625 	 ffmpeg	added 4 Idle
2032 	 0.015625 	 SearchProtocolHost	added	removed 4 Idle
7740 	 0.015625 	 RtkNGUI64 4 Idle
4108 	 0.015625 	 igfxTray 4 Idle
3144 	 0.015625 	 ffmpeg	removed 4 Idle
1524 	 0.015625 	 svchost 4 Idle
4752 	 0.015625 	 conhost	added	removed 4 Idle
5112 	 0.015625 	 igfxHK 4 Idle
4964 	 0.015625 	 svchost 4 Idle
Total_CPU_Time 	 6.4375 Elasped Time 	 500
  0.249384578106035  0.233744758081929  0.968622464446288  0.155634390052014  0.401721310490043-avg

チューニング前です。

2019年1月22日 19:10:57
5592 	 1.828125 	 powershell 4 Idle
7824 	 1.140625 	 WinStore.App	added 4 Idle
8164 	 0.921875 	 dwm 4 Idle
4 	 0.703125 	 System 4 Idle
2492 	 0.484375 	 svchost	added 4 Idle
620 	 0.40625 	 SettingSyncHost 4 Idle
6816 	 0.390625 	 SystemSettings	added 4 Idle
6136 	 0.3125 	 conhost 4 Idle
1332 	 0.296875 	 JPLAYfemto 4 Idle
868 	 0.21875 	 svchost 4 Idle
7584 	 0.21875 	 backgroundTaskHost	added	removed 4 Idle
1832 	 0.203125 	 svchost 4 Idle
7408 	 0.203125 	 svchost	added	removed 4 Idle
2404 	 0.171875 	 csrss 4 Idle
992 	 0.171875 	 svchost 4 Idle
2696 	 0.15625 	 Memory Compression 4 Idle
372 	 0.140625 	 explorer 4 Idle
96 	 0.140625 	 Registry 4 Idle
2288 	 0.140625 	 svchost 4 Idle
632 	 0.109375 	 services 4 Idle
5152 	 0.109375 	 svchost 4 Idle
2768 	 0.109375 	 svchost 4 Idle
7960 	 0.09375 	 SpeechRuntime	added	removed 4 Idle
3688 	 0.09375 	 RuntimeBroker	added 4 Idle
3296 	 0.09375 	 svchost 4 Idle
716 	 0.078125 	 lsass 4 Idle
1368 	 0.078125 	 svchost 4 Idle
5268 	 0.078125 	 svchost	added 4 Idle
728 	 0.0625 	 sihost 4 Idle
2804 	 0.0625 	 dasHost 4 Idle
7312 	 0.0625 	 ffmpeg	added	removed 4 Idle
6784 	 0.0625 	 WmiPrvSE	added	removed 4 Idle
1988 	 0.046875 	 svchost	added 4 Idle
6780 	 0.046875 	 ApplicationFrameHost 4 Idle
6948 	 0.046875 	 RuntimeBroker	added	removed 4 Idle
2788 	 0.046875 	 svchost	added 4 Idle
1452 	 0.03125 	 svchost 4 Idle
5668 	 0.03125 	 ffmpeg	added 4 Idle
4856 	 0.03125 	 audiodg	added 4 Idle
5684 	 0.03125 	 igfxTray 4 Idle
2764 	 0.03125 	 svchost 4 Idle
6308 	 0.03125 	 atieclxx 4 Idle
3548 	 0.03125 	 conhost	added 4 Idle
1968 	 0.015625 	 svchost 4 Idle
4100 	 0.015625 	 svchost 4 Idle
6104 	 0.015625 	 SearchIndexer 4 Idle
2200 	 0.015625 	 svchost 4 Idle
4604 	 0.015625 	 svchost 4 Idle
2588 	 0.015625 	 svchost 4 Idle
7480 	 0.015625 	 svchost 4 Idle
6832 	 0.015625 	 fontdrvhost 4 Idle
2348 	 0.015625 	 svchost 4 Idle
7984 	 0.015625 	 svchost	added	removed 4 Idle
1788 	 0.015625 	 svchost 4 Idle
4932 	 0.015625 	 RuntimeBroker 4 Idle
Total_CPU_Time 	 9.9375 Elasped Time 	 500
  2.75878614708974  0.321222949508881  0.697885317126409  0.228523002457096  0.979010528582172-avg

ご覧の通り、差は歴然という感じですね。表に纏めてみます。

	CPU0負荷	CPU1負荷	CPU2負荷	CPU3負荷	CPU負荷平均	動作プロセス数
チューニング後	0.25%	0.23%	0.97%	0.16%	0.40%	30
チューニング前	2.76%	0.32%	0.70%	0.23%	0.98%	55

チューニング後の数値は見事に設定通りになっていることがお分かりかと思います。
チューニング後のCPU2の負荷がチューニング前より高くなっていますが、これはプロセス監視スクリプトの監視周期をチューニング前の倍(10秒から5秒)の値にしたため発生したもので、補正すると、0.6%位になります。従って、おかしな所はなく、むしろWindowsの数値の精度を裏付けるものだと思います。

チューニング前と後の数値の違いにビックリされる方が多いかと思います。

一番の問題点はCPU0の負荷です。他のCPU1-3に対して圧倒的に多い。プロセス数も多すぎる。明らかに何らかの対応(チューニング)が必要な値です。
JPLAYfemtoになって、Lisence Expiredゴジラが乱舞するようになったので、プロセスカットなどのチューニングがやりづらくなっています。「JPLAY側の対応力が上がって、プロセスカットは不要になった」という神話があるようですが、この数値を見れば、やらない訳にいかないですよね。

という訳で、ここから話はOSチューニングに移るのですが、長くなったので、タイトルを変えて、継続させます。

(PC_Audio) 2019/02/24

コメントする

Symphonic MPD讃(3)

(PC_Audio) 2019/05/18

Symphonic MPD讃(2)

(PC_Audio) 2019/05/11

Symphonic MPD 讃

(PC_Audio) 2019/05/04

バッハ レイチェル・ポジャー チェロ組曲 ヴァイオリン

(music) 2019/04/28

JPLAYでCPU Affinityとプロセス優先度を設定する(7)

(PC_Audio) 2019/04/21

JPLAYでCPU Affinityとプロセス優先度を設定する(6)

(PC_Audio) 2019/04/13

JPLAY 7 で OSチューニング(2)(プロセス監視スクリプト)

(PC_Audio) 2019/04/06

JPLAY 7 で OSチューニング(1)

(PC_Audio) 2019/03/30

GPSDOクロックジェネレータ(2)

(PC_Audio) 2019/03/23

GPSDOクロックジェネレータ(1)

(PC_Audio) 2019/03/16

JPLAYでCPU Affinityとプロセス優先度を設定する(5)

(PC_Audio) 2019/02/24

top page previous page next page

バッハレイチェル・ポジャーチェロ組曲ヴァイオリン