まゆのだららんライフメインコンテンツへ移動サブコンテンツへ移動まゆのだららんライフだららんと書いていくブログなのです。mayukayoshikawa返信あ。そいやわすれてましたよ。VNCを使う場合、もしPiをディスプレイにつないでないと解像度が320×240かな?さがっちゃうので、以下セッティングをしましょう。/boot/config.txtに追記。1920x1080_60.00こんなかな、結構こうすると便利だったりします。Pi付属のRealVNCのお話。これ無償でRealVNCサーバがバンドルされてくるのですが、これがうまく使うと便利なのです。これがうちMixxxサーバをVNCでみたとこ。ま、設定は言わずもがな設定項目からVNCの設定をONするだけ。Options→VNCでONにするだけ。Reachableにするか、VNCのサブスクを買うと外部リモートアクセスが可能になります。宿泊先にラップトップをもっていけば宿泊先でもいろいろ選曲可能なわけで。小ネタですが、ご利用くださいませませ。mayukayoshikawa返信ねみぃいやぁすいません、お仕事で昨日徹夜で眠いので、アレです。アドベントカレンダーブログは後から編集で書きます。23日目、明日はクリスマスですね。あっきぃさん頑張ってるなぁ。今のレンダラーシステムは2システム今のシステムはdarkiceでiPhoneからのAirplayのデータをjackdで受け取り配信するというシステムと、Mixxxでmpd経由で配信するシステムと2つ持っています。Mixxxベースはかなり楽勝で組めたのですが、darkiceで配信する側はjackd特有で出てしまう『音飛び』といかに格闘するかが問題となっています。低レートである128kpbsでも起きてしまうのとたびたびひどい音とびからいきなり音がフラッタリングしたうえ、工事音のような音になってしまい、音がひたすら再送し続ける?ようなことが起きてしまうようなことが起きています。ドハマりなところにさらに320kbpsという高レートでの配信をデフォルトとし変更したため、さらに大変なことになるという...ま、その原因とひたすら格闘し続けてましたが、それがキャッシュ問題でCephと同様定期的にcrontabでデータを削除してあげなきゃいけない問題になるとは思いませんでした。これは定期的削除はさや当てみたいなもので、これをしても音ズレは完全に解消しないし、わからないくらいにまでにはしましたが、まだまだ格闘の余地がありそげです。listの更新のストップ、tempの定期的な削除も止めないとだめなようです。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が重いことによって配信がうまくいかず結果として配信不具合が起きるのだなといまさら気づきました。updateにmaskをかけて起動できなくして、サーバ負担を落としてicecast以外のデーモンが常時にいないよう努めしました。aptはそれでもどうも23分程度も居座ってくれたらしく、なるほどこれが起きる前後はネットワークポートはプロセスアップでレンダラーからの受信ができず音飛びするわーと思った次第です。dailyなどとめて、今連続稼働をテストしてみてるちうです。今日も朝から調整しつつ半日流していますが、いまのところ何とかなっています。ま、jackdのドキュメントにも書いてありますが、音飛びはどうも発生してしまうっぽなので、とにかく数を減らす、目立たなくするというのがワークアラウンドで今は調整>テストのトライアルエラーといったところです。Beastでの利用を想定しておりまして、メインはdarkiceベースのシステムで考えています。darkice自体がもうすたれたOSSで今の段階開発がストップ?している状況にあるため、メンテナーが今いるうちはどうにかなりそうでしょうけど、今後どのようにハードのアップデートなどやるかは検討課題なのかなと思っています。Pi4の最新版に移行すると思いますが、ぼちぼちやろうかと思っています。ほんと時間がない、困ったもんです。ことながらですが、OSSベースのシステムなのでいつかどこかでいじった部分なりまとめてソースコードとOS+アプリを入れた形で丸ごと出そうと思っております。未開発ままのものなので皆さんで発展させてくれてあたしに戻してくれたらイシシシで本人喜びますので、よろしくお願いいたします。ノウハウをGit、OSイメージはどう配るかなぁ。カフェはどこに(メモ)あとから貼り付けます。尻切れトンボですんません。ほんとはもっと技術的な解説、どう動かしてるかコツを出したりしたいのですが、こちらに暇なく、、今後このブログで発表していきますから、どうかご容赦ください。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前後といわれます。Shuffleで128kpbs音源にするという設定がありましたがあれはそういう意味で、音質とファイル容量の妥協点はこの辺りがポイントになります。非可聴音域や、128kbps以上の音域ってなぜいるのか?というと単に、奥行き感が広がるといったところです。ペラい音質になることがある意味オーディオマニア相当なDJから辟易され最近ではmp3の最大域である320kbpsで配信する人もいます。そんなレートで配信すれば結果、さきほどいったとおりネットワークへの負荷は大きいですから、きちんとネットワーク設計やサーバ設計をしないと音がとまってしまったり、途切れ途切れやら、音データが順不同でクライアント側に配信されたり、音データが配信遅れと認識して再送をしてしまったりなど...よく言われる『音飛び』の原因になったります。ある意味、ビットレートやサンプリングレートのリミットを128kpbs/44100Hzとする理由は配信においては妥協点であるのです。CBR/ABR/VBRとかこれがちょっとめんどくさい。MP3ファイルには実装があって、ビットレートを可変するか、固定するかです。可変をすれば、配信するデータ総容量は落ちるため、ネットワークにはありがたいですが、固定であるほうが、エンコードに時間はかかりませんが、データ総容量はでかくなるので結果ネットワーク負荷が大きくなるのでそれはそれで不便です。端的に紹介するとこんな感じです。実はどれが音質がいいか議論があって、参照をだしにくいので、ここはググってみてください。CBR(固定ビットレート)VBR(可変ビットレート)ABR(平均ビットレート)一般的に皆さんが使っているMP3元ファイルはVBR可変レートになります。可変レートなので、クライアント側に左右されつつ、配信をしようとしてくれますが、常に高音質をたもらないため、不便な扱いになります。ある意味クライアント側によってはビットレートを調整してくれますが、その分音質がおちたような感じがしてしまいます。激しい音の落差がある音楽だとバレバレになりますね、VBRは。うちの配信システムはCBRを使っています。Piだと配信自体の負荷は大きいですからね、CBRはVBRと違って音ズレしにくいといいますが、負荷の結果やらいろいろファクターはあるのでしょうが、高ビットレート、高サンプルレートで配信した場合、一定の時間後音飛びはしてしまいます。Piのような非力だからかもしれませんが、音飛びはしてしまうようです。音飛び出現率は減るので、もちろんバッファ値をあげるのはアリです。上げすぎると今度はこれ自体が断片化する=音飛びするようなので、微妙な調整がいるようです。まじしんどい...これはバッファ自体書き込むデータ番地がアドレッシングされているわけでないので、書き込みタイミングによってはおかしくなるのかなぁ、と邪推してます。バッファ値はある値からは、初期値は一定化し、累積で伸びていくだけで、どうもCeph同様メモリを最後は食いつぶしてしまうようです、ワークアラウンドは同じ。/proc/sys/vm/drop_cachesですが、実行タイミングを考えないと音飛びしてしまうので、いまのところ15分にしています。Pi手持ちのはメモリ小さいですからね、いらないキャッシュは定期的にクリーンしにないとってところなんでしょうかねぇ。MP3Lameエンコーダこれがさらに音質のわかる人なら、こまったちゃんなのですが、よくあるMP3配信クライアントソフト側ではこのLameエンコーダが使われ、デフォルトでは可聴音域以降である20000Hz以降は音データをカットしてしまいます。いいビットレートをつかってもMP3Lameで非可聴音域を切るという所作をやるのでまいったもんです。これはエンコードをするデバイスの負荷を減らすための措置で、ま、Lameも廃れてアップデートしていないので、当初のデバイスからは仕方ないのかな、と思っています。ALACなどの対ネットワークの仕掛けじゃぁなんでAppleやらALACとかで高ネットワーク配信できるの?という疑問にぶちあたります。これは簡単で、Appleはきちんと言及していますが、対応デバイス側でデコードする際に高音域データに対応するためで、そりは当たり前だぁなと思うのです。素で384kbpsとかやられたらそれでも重くなる。そこでデコードデバイスは対応済みのものとする。miniではロスレスオーディオは再生できないと設定から見られます。miniではデコード対応していないのでは?と思っています。音が高ビットレート、高サンプルレートになればなるほどジャンボフレーム対応させないと配信時にネットワーク側がCPUに余力があっても受けきれず、配信自体をicecastの場合だと配信を切ってしまうケースもあります。うちは今試験的にレンダラー、Icecastサーバ間をジャンボフレーム対応にしましたが果て大丈夫やら...ま、試験中です。デバイスの2秒ルール(メモ)ちょっと最近クライアントデバイスがどれくらいバッファするのか調べていたのですが約2秒だそうで...ただ、個体差はあるのだそうです。何が言いたいかというとSLで個別で聞こえなくなったとか音がおかしくなったとかは、個別問題もあるということはDJさんも念頭におきましょう。MP3の最大ビットレートは320kbps(メモ)これ、あたしも最近までよく知らなかった。これがmp3というフォーマットの限界なのでしょうけど。今うちはこれで配信テストしてます。SLの土地音楽のMaxビットレートは192kbps(メモ)もちろん知ってますよ。これ以上で流すことに意味がないわけではない。オーバービットレート分は音の深さを作ってくれるので、間違いでないです。結論:ストリーム配信の高音質化はかなり難しい。ネットワーク負荷が大きいのとその結果、音飛びしやすくなります。DJさんは、128kbps以上での配信は望まないほうがいいと思います。コンテンツ勝負で!という方は音質を追求しないほうがいいです。Piと関係あんの?ま、こんなで、今も音楽調整中なのです、ほんと高音域再生はキッツなのです、、まじきっつ。長時間再生での高音質はかなり無茶ですねぇ。Calendarがなくなっちゃったので、今回初めてちゃんとIT系に書きますが、初日はすません、ポエム日です。まじめに技術的なことを書くのはのち2回になります。ブログ再開で技術ポエムを書くとはなんとも。Secondlifeに復帰してもう一年と半年。日本へ逃げるように帰国してステイホームじゃアレだわとおもって復帰しました。ま、Secondlifeはなに?というラズパイな方にいうと最近Facebookがメタって名前かえましたよね、はい、あのメタバースなゲームで2007年いに一度バブリーになったゲームでございます。知らないかと思うのですが、実はコロナ下で盛り返しまして...レジデンス数(ユーザ数)過去最高、売り上げ高も過去最高で、ファンドにちょうど良く買収もされたわけ、なんですが、技術的にいうとインハウスからAWSへ、VMからコンテナと実は最新技術においついてきたところで、いやぁまだ、過去の遺産的な実装もありーのゲームになっています。そんなゲームとラズパイと何が関係あるか?っていうと、よくある話で第二の生活なものですから、自分のお家にいるときぐらい好きな音楽を流したいわけで、よくあるインターネットラジオのURLを自分の土地に設定すると、まるで家で音楽をながしているような気分になるわけです。それでも好きな音楽をながしたりとかしたいわけで、じゃぁどうするか、と考えた結果、あー家に余ってるラズパイだわー、と思って余ってるラズパイを使ってmpdのジュークボックスをつかって、mpd.confを編集してicecastベースのサーバを貸しているところにつないで、ってことをするわけなのです。普通にインストール可能です。Linuxちょっとできるな方ならPC二台よりラズパイでRealVNCサーバは標準でインストールされているんで、PCからRealVNCクライアントソフトをいれてやるだけでリモートアクセスできますから、5,000円程度とちょっとしたLinuxへのウンたらで楽勝でSecondlifeご自宅音楽の完成!といったところです。うちはレンサバ探すのがめんどくさくなってicecastのサーバもラズパイにしてあります。このicecast構築、まじめにやったことのある人はわかるのですが、いろいろチューニングが必要になり、今に至ります。昨今ベースとなる音楽ファイル(mp3等)の品質大幅向上もありまして、かなり今もチューニングの最適解には頭を痛めているところであります。もーどーしてこんなコーデックなんだよw試行錯誤で理解した部分もあります。Master(DM)ってのもあって楽しみが増えたこともあるのでしょうね。Calendarで書ければ、と思ってます。ラズパイ系のネタ期待した方すません。Secondlife側の設定とかも書くので、ネタとしてどうかってありますが、ご容赦くださりませ。Secondlifeの音楽実装は実にめんどく、推奨128kbps、最大192kbpsとなっているようで、ま、これは実は一般的なストリームの推奨値でもあるかと思うのですが、これゆえのめんどくささがあったりもします。Secondlife系のネタを期待した人すいません、LSLネタは一切ありません。Blenderネタもないです。DJ/DM系で理系あるいはLinuxをいじってない方、何を言っているのか全く理解できない可能性もあります。Linuxでも中レベルの課題を扱いますのですいません。ぁ、ゆるだらでならなくなった。