Oh Forgot the thing…(was VNC on Pi setting)

あ。
そいやわすれてましたよ。

VNCを使う場合、もしPiをディスプレイにつないでないと解像度が320×240かな?さがっちゃうので、以下セッティングをしましょう。

/boot/config.txtに追記。

hdmi_force_hotplug=1
hdmi_force_mode=1
hdmi_group=2
hdmi_mode=82

.profileにも念のため追記

xrandr –newmode “1920x1080_60.00” 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync
xrandr –addmode HDMI-1 1920x1080_60.00
xrandr –output HDMI-1 –mode 1920x1080_60.00

こんなかな、結構こうすると便利だったりします。

VNC might be useful to remote access via Internet

やばいすっかりわすれてました!ごめんなさい….
でですね、Raspberry PI Advent Calendar 6日目ですぅ。

今年はなんかSecondlife技術系はないですね、、、
今回はRaspberry Pi付属のRealVNCのお話。
これ無償でRealVNCサーバがバンドルされてくるのですが、これがうまく使うと便利なのです。。。これがうちMixxxサーバをVNCでみたとこ。ま、設定は言わずもがな設定項目からVNCの設定をONするだけ。またはsudo raspi-config→3 Interface Options→VNCでONにするだけ。

で、これができると自宅VPNアクセスでIP Reachableにするか、VNCのサブスクを買うと外部リモートアクセスが可能になります。つまり宿泊先にラップトップをもっていけば宿泊先でもいろいろ選曲可能なわけで。、、

小ネタですが、ご利用くださいませませ。

Raspberry Pi Streaming System feature and the next for Secondlife

ねみぃ

いやぁすいません、お仕事で昨日徹夜で眠いので、アレです。また、アドベントカレンダーブログは後から編集で書きます。今日はRaspberry Pi Advent Calendar 23日目、明日はクリスマスですね。あっきぃさん頑張ってるなぁ。

今のレンダラーシステムは2システム

今のシステムはdarkiceでiPhoneからのAirplayのデータをjackdで受け取り配信するというシステムと、Mixxxでmpd経由で配信するシステムと2つ持っています。なお、Mixxxベースはかなり楽勝で組めたのですが、darkiceで配信する側はjackd特有で出てしまう『音飛び』といかに格闘するかが問題となっています。低レートである128kpbsでも起きてしまうのとたびたびひどい音とびからいきなり音がフラッタリングしたうえ、工事音のような音になってしまい、音がひたすら再送し続ける?ようなことが起きてしまうようなことが起きています。ドハマりなところにさらに320kbpsという高レートでの配信をデフォルトとし変更したため、さらに大変なことになるという…
ま、その原因とひたすら格闘し続けてましたが、それがキャッシュ問題でCephと同様定期的にcrontabでデータを削除してあげなきゃいけない問題になるとは思いませんでした。ただ、これは定期的削除はさや当てみたいなもので、これをしても音ズレは完全に解消しないし、わからないくらいにまでにはしましたが、まだまだ格闘の余地がありそげです。
どうもさらにicecast側のapt listの更新のストップ、tempの定期的な削除も止めないとだめなようです。両方ともRaspberry Piだからでしょうね、SDカード遅いし、aptはチェック持にネットワークもってくし。今両方ともmaskをかけて、動けなくしてどうか?見ています。

配信サーバはicecast2

これも今回128kbpsでSL再開前は走らせていましたが、320kbps変更に伴い、icecast.xmlのqueue-sizeとburst-sizeの設定をいろいろ試行錯誤をしています。基本、5秒分をqueue-size、1秒分をburst-sizeでとるようで、burst-sizeはqueue-sizeより小さくしないと反映してくれないとかでいろいろググった末にこの辺りを見つけました。これはこの設定の度合いわからず結構格闘をここ数日していました。

音飛びと途中いきなり切れる要因は複雑..

Mixxxのレンダラーシステムもいきなり切られて無音になっていたり、darkiceのレンダラーシステムでは音飛びしたまま、工事音のような音がして落ちてしまったり、音が前後で配信しておかしくなったりする要因やら、Mixxxのシステム同様、途中で音切れが起きるわけですが、この要因はレンダラーでなくて、icecast側でも見直しが必要なことをいまさら実感しました。何が言いたいかというと音飛びやいきなり切れる要因は、icecastが重いことによって配信がうまくいかず結果として配信不具合が起きるのだなといまさら気づきました。そこでicecast側はdbus-daemonやら、aptのdaily updateにmaskをかけて起動できなくして、サーバ負担を落としてicecast以外のデーモンが常時にいないよう努めしました。aptはそれでもどうも23分程度も居座ってくれたらしく、なるほどこれが起きる前後はネットワークポートはプロセスアップでレンダラーからの受信ができず音飛びするわーと思った次第です。で、dbusなりapt dailyなどとめて、今連続稼働をテストしてみてるちうです。

でな、まだまだテストちう。

今日も朝から調整しつつ半日流していますが、いまのところ何とかなっています。えらいぞRaspberry Pi。ま、jackdのドキュメントにも書いてありますが、音飛びはどうも発生してしまうっぽなので、とにかく数を減らす、目立たなくするというのがワークアラウンドで今は調整>テストのトライアルエラーといったところです。

今後の方針

今はSecondlife内で配信するシステムとして、Secondlife内であたしが経営しているカフェとSaiさんという酔っ払いなおじさま?が経営されているBar Beastでの利用を想定しておりまして、メインはdarkiceベースのシステムで考えています。ただ、darkice自体がもうすたれたOSSで今の段階開発がストップ?している状況にあるため、メンテナーが今いるうちはどうにかなりそうでしょうけど、今後どのようにハードのアップデートなどやるかは検討課題なのかなと思っています。ま、darkiceベースシステムの方は、今後Raspberry Pi4の最新版に移行すると思いますが、ぼちぼちやろうかと思っています。ほんと時間がない、困ったもんです。
またもちろんのことながらですが、OSSベースのシステムなのでいつかどこかでいじった部分なりまとめてソースコードとOS+アプリを入れた形で丸ごと出そうと思っております。未開発ままのものなので皆さんで発展させてくれてあたしに戻してくれたらイシシシで本人喜びますので、よろしくお願いいたします。多分ノウハウをGit、OSイメージはどう配るかなぁ。

カフェはどこに(メモ)

あとから貼り付けます。

尻切れトンボですんません。

ほんとはもっと技術的な解説、どう動かしてるかコツを出したりしたいのですが、こちらに暇なく、、今後このブログで発表していきますから、どうかご容赦ください。

であであ、24日はあっきぃさんかな、メリクリーですー明日はケンタッキーだ!

尻切れでおしまい、すまん!

MP3 internal and limitation w/Raspberry Pi

くしゃみひどっ!

なんか噂されているのかなぁ、くしゃみがひどいwww、まったくぅよっぱさいどのか?
あ、Raspberry Pi Advent Calendar主宰のあっきぃさんだった、きっと。すみません、ゆるして💦
で、今日から技術的な話ですが、本当はね、構図を出すつもりでいましたが、まだまだ、実は高レート音楽を流すチューニングをicecastでしてまして、ごめんなさい。あっきぃさん。書き直した後は、こっち。

Icecastの現実と高レートMP3/AAC

実はIcecastもShoutcastももうかなり廃れたソフトです。バージョンアップももうメジャーはなくマイナーリリースが出ているくらいです。で、このオープンソースが程よくメンテされていた当初はこのころは低レートで、ここに音質をもとめることはなかったので、そんなに気にすることはなかったと思います。
ただ、今は320kbps高ビットレートmp3は当たり前だし、ハイレゾ音源でFLACとかALACとかもうわんさかなわけです。わんこ!ぐらいな。
正直、IcecastやShoutcastベースの配信サーバをSLでDJの方々に貸しているサービスのほとんどは128kbpsをリミットとしての利用なっています。この理由は何?ってわかる人はネットワークをわかっている人です。ハイ、帯域を食うからです。高ビットレート配信であればあるほど帯域を食い、結果大抵のご自宅はルータ経由で1IPアドレスで外にでますから、特にSLを高設定にしてしまっている人は音が原因でSLから落ちたりしちゃう恐れもあるわけです。正直IcecastもShoutcastも128kbps配信を想定しているといっても過言ではないと思います。

可聴音域と非可聴音域

よくCD音域とかでサンプリングレートが44100Hzとか48000Hzとか聞くと思いますが、人間の耳に聞こえる音域はせいぜい20000Hz前後まで、あと人間が差し障らない音域のビットレートは128kbps前後といわれます。ある意味Appleが昔iPod Shuffleで128kpbs音源にするという設定がありましたがあれはそういう意味で、音質とファイル容量の妥協点はこの辺りがポイントになります。じゃぁ非可聴音域や、128kbps以上の音域ってなぜいるのか?というと単に、奥行き感が広がるといったところです。ペラい音質になることがある意味オーディオマニア相当なDJから辟易され最近ではmp3の最大域である320kbpsで配信する人もいます。ただ、そんなレートで配信すれば結果、さきほどいったとおりネットワークへの負荷は大きいですから、きちんとネットワーク設計やサーバ設計をしないと音がとまってしまったり、途切れ途切れやら、音データが順不同でクライアント側に配信されたり、音データが配信遅れと認識して再送をしてしまったりなど…よく言われる『音飛び』の原因になったります。ある意味、ビットレートやサンプリングレートのリミットを128kpbs/44100Hzとする理由は配信においては妥協点であるのです。

CBR/ABR/VBRとか

これがちょっとめんどくさい。MP3ファイルには実装があって、ビットレートを可変するか、固定するかです。可変をすれば、配信するデータ総容量は落ちるため、ネットワークにはありがたいですが、固定であるほうが、エンコードに時間はかかりませんが、データ総容量はでかくなるので結果ネットワーク負荷が大きくなるのでそれはそれで不便です。
端的に紹介するとこんな感じです。いろいろ実はどれが音質がいいか議論があって、参照をだしにくいので、ここはググってみてください。
CBR(固定ビットレート)
VBR(可変ビットレート)
ABR(平均ビットレート)
一般的に皆さんが使っているMP3元ファイルはVBR可変レートになります。これポイント。可変レートなので、クライアント側に左右されつつ、配信をしようとしてくれますが、常に高音質をたもらないため、不便な扱いになります。ある意味クライアント側によってはビットレートを調整してくれますが、その分音質がおちたような感じがしてしまいます。激しい音の落差がある音楽だとバレバレになりますね、VBRは。
うちの配信システムはCBRを使っています。ただ、その通り容量が大きく、ネットワーク設計やらRaspberry Piだと配信自体の負荷は大きいですからね、CBRはVBRと違って音ズレしにくいといいますが、負荷の結果やらいろいろファクターはあるのでしょうが、高ビットレート、高サンプルレートで配信した場合、一定の時間後音飛びはしてしまいます。よくググるとバッファ値をあげるといいよとありますが、実際上げてみてもどこかでRaspberry Piのような非力だからかもしれませんが、音飛びはしてしまうようです。ただ、音飛び出現率は減るので、もちろんバッファ値をあげるのはアリです。ただ、上げすぎると今度はこれ自体が断片化する=音飛びするようなので、微妙な調整がいるようです。まじしんどい…これはバッファ自体書き込むデータ番地がアドレッシングされているわけでないので、書き込みタイミングによってはおかしくなるのかなぁ、と邪推してます。ただ、バッファ値はある値からは、初期値は一定化し、累積で伸びていくだけで、どうもCeph同様メモリを最後は食いつぶしてしまうようです、ワークアラウンドは同じ。
echo 3 > /proc/sys/vm/drop_caches
ですが、実行タイミングを考えないと音飛びしてしまうので、いまのところ15分にしています。ま、もともとRaspberry Pi手持ちのはメモリ小さいですからね、いらないキャッシュは定期的にクリーンしにないとってところなんでしょうかねぇ。

MP3Lameエンコーダ

これがさらに音質のわかる人なら、こまったちゃんなのですが、よくあるMP3配信クライアントソフト側ではこのLameエンコーダが使われ、デフォルトでは可聴音域以降である20000Hz以降は音データをカットしてしまいます。いくらいいビットレートをつかってもMP3Lameで非可聴音域を切るという所作をやるのでまいったもんです。これはエンコードをするデバイスの負荷を減らすための措置で、ま、Lameも廃れてアップデートしていないので、当初のデバイスからは仕方ないのかな、と思っています。

ALACなどの対ネットワークの仕掛け

じゃぁなんでAppleやらALACとかで高ネットワーク配信できるの?という疑問にぶちあたります。これは簡単で、Appleはきちんと言及していますが、対応デバイス側でデコードする際に高音域データに対応するためで、そりは当たり前だぁなと思うのです。素で384kbpsとかやられたらそれでも重くなる。そこでデコードデバイスは対応済みのものとする。ちなみにAppleはHomePod miniではロスレスオーディオは再生できないと設定から見られます。これは、推測ですが、ネットワーク受信型のHomePod miniではデコード対応していないのでは?と思っています。

ジャンボフレーム対応

音が高ビットレート、高サンプルレートになればなるほどジャンボフレーム対応させないと配信時にネットワーク側がCPUに余力があっても受けきれず、配信自体をicecastの場合だと配信を切ってしまうケースもあります。うちは今試験的にレンダラー、Icecastサーバ間をジャンボフレーム対応にしましたが果て大丈夫やら…ま、試験中です。

デバイスの2秒ルール(メモ)

ちょっと最近クライアントデバイスがどれくらいバッファするのか調べていたのですが約2秒だそうで…ただ、個体差はあるのだそうです。何が言いたいかというとSLで個別で聞こえなくなったとか音がおかしくなったとかは、個別問題もあるということはDJさんも念頭におきましょう。

MP3の最大ビットレートは320kbps(メモ)

これ、あたしも最近までよく知らなかった。多分これがmp3というフォーマットの限界なのでしょうけど。今うちはこれで配信テストしてます。

SLの土地音楽のMaxビットレートは192kbps(メモ)

もちろん知ってますよ。ただこれ以上で流すことに意味がないわけではない。オーバービットレート分は音の深さを作ってくれるので、間違いでないです。

結論:ストリーム配信の高音質化はかなり難しい。

これにつきます。ネットワーク負荷が大きいのとその結果、音飛びしやすくなります。正直音を追求しないで、音楽を追求するSL DJさんは、128kbps以上での配信は望まないほうがいいと思います。コンテンツ勝負で!という方は音質を追求しないほうがいいです。

で、Raspberry Piと関係あんの?

ま、こんなで、今も音楽調整中なのです、ほんと高音域再生はキッツなのです、、
まじきっつ。長時間再生での高音質はかなり無茶ですねぇ。

Blog should be resumed

It is for ‘Raspberry Pi Advent Calendar on 14th Dec’

で、なんかすごくしばらくブログ書いてなかったらWordpressがめんどくさくなってた((+_+))


はい、Raspberry PI Advent Calendar 14日目っす。Secondlife技術系 Advent Calendarがなくなっちゃったので、今回初めてちゃんとIT系に書きますが、初日はすません、ポエム日です。まじめに技術的なことを書くのはのち2回になります。ブログ再開で技術ポエムを書くとはなんとも。

Secondlifeに復帰してもう一年と半年。日本へ逃げるように帰国してステイホームじゃアレだわとおもって復帰しました。ま、Secondlifeはなに?というラズパイな方にいうと最近Facebookがメタって名前かえましたよね、はい、あのメタバースなゲームで2007年いに一度バブリーになったゲームでございます。で、知らないかと思うのですが、実はコロナ下で盛り返しまして…レジデンス数(ユーザ数)過去最高、売り上げ高も過去最高で、ファンドにちょうど良く買収もされたわけ、なんですが、技術的にいうとインハウスからAWSへ、VMからコンテナと実は最新技術においついてきたところで、いやぁまだ、過去の遺産的な実装もありーのゲームになっています。

で、そんなゲームとラズパイと何が関係あるか?っていうと、よくある話で第二の生活なものですから、自分のお家にいるときぐらい好きな音楽を流したいわけで、よくあるインターネットラジオのURLを自分の土地に設定すると、まるで家で音楽をながしているような気分になるわけです。

こんな感じっすね。

で、まぁそれでも好きな音楽をながしたりとかしたいわけで、じゃぁどうするか、と考えた結果、あー家に余ってるラズパイだわー、と思って余ってるラズパイを使ってmpdのジュークボックスをつかって、mpd.confを編集してicecastベースのサーバを貸しているところにつないで、ってことをするわけなのです。ま、最近ではmpdをベースとしたmixxxがラズパイ4でもつかえるようで、4GBタイプであれば、Raspberry Pi OSからmixxxがレポジトリにあるので、sudo apt install mixxx で普通にインストール可能です。Linuxちょっとできるな方ならPC二台よりラズパイでRealVNCサーバは標準でインストールされているんで、PCからRealVNCクライアントソフトをいれてやるだけでリモートアクセスできますから、5,000円程度とちょっとしたLinuxへのウンたらで楽勝でSecondlifeご自宅音楽の完成!といったところです。

で、うちはレンサバ探すのがめんどくさくなってicecastのサーバもラズパイにしてあります。このicecast構築、まじめにやったことのある人はわかるのですが、いろいろチューニングが必要になり、今に至ります。とくに昨今ベースとなる音楽ファイル(mp3等)の品質大幅向上もありまして、かなり今もチューニングの最適解には頭を痛めているところであります。もーどーしてこんなコーデックなんだよw試行錯誤で理解した部分もあります。

で、そんなうちが戻ってきて思ったのがSecondlife DJ増えたなぁって。なんかダンス系HUDを動かすDance Master(DM)ってのもあって楽しみが増えたこともあるのでしょうね。で、一部のDJさんがあいつの音楽は悪いとか、こいつの音楽すごいとか話を聞きますが、なんかそんなことに技術的にはいやいやいや(あんたも人のことは言えない)と思う節があり、それでSecondlife技術系を探したらありゃしない..orz

で、今回はそういうDJ/DM殿やいままでやったことまとめることも含めて、ちょっと今回あと2回も含めてAdvent Calendarで書ければ、と思ってます。

ラズパイ系のネタ期待した方すません。結構Secondlife側の設定とかも書くので、ネタとしてどうかってありますが、ご容赦くださりませ。Secondlifeの音楽実装は実にめんどく、推奨128kbps、最大192kbpsとなっているようで、ま、これは実は一般的なストリームの推奨値でもあるかと思うのですが、これゆえのめんどくささがあったりもします。
Secondlife系のネタを期待した人すいません、LSLネタは一切ありません。Blenderネタもないです。土地音楽/mpd/streaming/codec on Raspberry Piネタです。DJ/DM系で理系あるいはLinuxをいじってない方、何を言っているのか全く理解できない可能性もあります。Linuxでも中レベルの課題を扱いますのですいません。

でぁ、ゆるだらでならなくなった。今日はポエムで。ご容赦くださいませ。


Sorry…Gomen

まゆです。

最近カフェもあけず、Airplay SL Streamの件も怠っててすいません….

ちょっと親が地元で怪我しちゃいまして、看護もあって田舎と東京を往復してます。。。親は実はぴんぴんなんですが、こまったことは地元の対応やら保険金の手続きやらで困ってて、、、もう日常の仕事なんてできない><泣けてくる状態になってます。。。

来月からはなんとかなりそうなので、PCのことストリーミング等のことでご相談等ございましたら、SLのIMかお店の前のポストに投函いただければとおもってます。

ただ、暇をみつけてはカフェをあけるかもですが、よろしくです。なお、ごめんなさい、実家からはWiMax接続なため、音楽は自宅にあるJazzストリーミングのみとなります。

 

Tsun-dere

まゆです。

すっかりわすれてました。ひさぎさんによる改造手術でもう19世代目まできたんだよね。

最近は、こんなん。ちょっとつんでれ。
かわいいのはそもそも苦手なのでいいのかなぁ。

Snapshot_004

なわけで。来月で5歳、ついに年寄り(うそ)

Nirans Viewer is much buggy but it will be useful if the bugs were fixed.

最近いろいろSLでやてるまゆっす。

Nirans Viewerというのをあきさんからおせーてもらいますたのでいろいろやってみますた。すんげーバギーですが使えます。どうもこれKirstenの後継のようですね、、、いろんな人が既に紹介済みなので、ダウンロード先以外は割愛しますが、SLで問題になっている影の調整が細かくできるし、ハードウェア項目も細かく設定できるのはおいしい!timeout問題は根本は影とパフォーマンス不足の問題ですのでこの調整が できるのもうれしいところです。スナップショットはFirestorm系統と同様くずれるっぽいです(ちーと線がはいってます。。。)、とにかくノートの人は、影の設定を極端に落としてあげれば動作します。ためしにFirestormをみてみたのですが、ここまで細かい設定はできませんね。さすがキルステン系統!

Viewer_point_2

このとおり線が、、改善早くのぞみたいものっす。よーくみるとみえますよ、目立たないけど。

Snapshot_002

こまったことは、とにかく、途中でよくかたまります・多分読み込み方式をいじっているのでしょう、、まだここらへんはまだウオッチの段階です。

またグラボドライバは最新でないとまずそうです。古いドライバだとTimeoutの際、プロセスがゾンビのままでシステム側からプロセスを殺す必要がでてきます。280台での使用でおねがいします。

最新版のメッシュ対応だし、画面きれいだし。今後の期待ができるバギービューアでした。

BSOD – Blue Screen Of Death

いろいろ依頼されててやてないまゆです。

BSODについての説明です。BSODとはそのなのとおりブルースクリーンになり機器が死にいたるという意味です。ですが機器の故障という意味でなく、正確にいうと機器がプスッと(とまるで漫画みたいに)ぶっ壊れる前に機器を止めましょうという行為です。なのでどこかの機器がおかしくなり止めているという状態なのです。ブルースクリーンという動作自体は正常な行為、だという前提でお話をすすめます。

大抵のゲーム利用の場合、どこかが過負荷になることで、この行動を『意図的』に起こします。この過負荷に関しては要注意です。では、でたところでどう特定すれば?ってのがあります。やり方で順当なのはBlueScreenViewを使うことです。で、ダウンロードはここで、インストールはそんなにむずかしくありません。で、インストールして立ち上げると過去にブルースクリーンがあるとこのよーなスナップショットがでてきます。

bluescreenview

で、たとえば、エラー一覧にクリックしてあげるとエラー内容がでてくるす。エラーの内容はIT系でないと理解しにくいのですが、エラーを起こした原因がたいていわかります。で、エラーをクリックでセレクトしたあと、Fileタブからsave selected Itemsを選んでファイル保存すると詳細原因をファイルで確認できますですよ。

==================================================
Dump File : Mini010810-01.dmp
Crash Time : 2010/01/08 12:05:14
Bug Check String : KERNEL_MODE_EXCEPTION_NOT_HANDLED
Bug Check Code : 0x1000008e
Parameter 1 : 0xc0000005
Parameter 2 : 0xbd2a6b71
Parameter 3 : 0xb0ece93c
Parameter 4 : 0x00000000
Caused By Driver : nv4_disp.dll
Caused By Address : nv4_disp.dll+294b71
File Description : NVIDIA Windows XP Display driver, Version 280.26
Product Name : NVIDIA Windows XP Display driver, Version 280.26
Company : NVIDIA Corporation
File Version : 6.14.12.8026
Processor : 32-bit
Crash Address : nv4_disp.dll+294b71
Stack Address 1 :
Stack Address 2 :
Stack Address 3 :
Computer Name :
Full Path : C:\WINDOWS\Minidump\Mini010810-01.dmp
Processors Count : 2
Major Version : 15
Minor Version : 2600
Dump File Size : 90,112
==================================================

これを見るとグラボドライバがハンドルできてないようなので、次のような対処をします。

①最新版・安定板ドライバインストール

②ドライバの掃除

③PCIスロットの掃除

④空気の流れの確保(排熱のため)

⑤電源容量が推奨以上にある程度余裕があるか

なんてところです。これに関してはかなりマニアックですから、カフェでご相談にのります。IMか、カフェにおこしください。

Just only workarounds…Dolphin Viewer is old though but useful for highest settings.

まゆです。

これも書いておきますね、最近はやりのTDRの件、ここでもおっかけてきました。NvidiaでおきてしまうグラボのTimeoutの件です。どうも最新版3.2.5では、OpenGL等の仕様もかえたので大丈夫とのことがありますが、実際はNvidia 540MやGTS240やあたしのAlienware m11xR1ではやはりまだTDRで落ちます。たぶん理由は多々あると思います。どうも電源回りがあやしい。。。

で、workaroundなのですがいろいろ試してみたのですが、同様にFirestormでも起きるため、Viewer2系をどうしても、というのであれば、Dolphin Viewerをお勧めします。起動時にViewer古いぞでますけど、問題なく動きます。TDR対策はこのビューアでは、クラッシュして防止しているみたいですねぇ。。。(ただしょっちゅう落ちるわけでないですよ、もちろん。)よくプログラムで都合が悪くなったら意図的クラッシュ!ってきいたことありますが、本当にやるとは!という感じがいつもします。

Dolphin Warnings

ダウンロードはここから、インスコ等は変わりありませんから、1系のPhenixとか検討せずに、メッシュもきちんと使えるDolphinのほうがいいかもです。

ではでは。