パパリウス
パパリウス

マイルーム

オーディオルーム
オーディオルーム
借家(マンション) / 書斎兼用 / オーディオルーム / ~6畳 / 防音なし / スクリーンなし / ~2ch
<ネットワークトランスポート (I2S)> Raspberry Pi 3 ┣OS:symphonic-mpd (RT-Kernel) ┗電源:iFi-Audio iPower (5V…
所有製品

レビュー/コメント

レビュー/コメントはありません

カレンダー

      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

最新のレス

日記
製品レビュー/コメント

製品レビュー/コメントへのレスはありません

お気に入り製品

お気に入り製品はありません

日記

symphonic-mpd v0.6.0 正式版公開

このエントリーをはてなブックマークに追加
2018年08月17日

symphonic-mpd v0.6.0正式版のSDイメージを公開いたしました。

http://mpd.sytes.net/ja


βリリースの動作テストにご協力いただいた皆様には心からの感謝を申し上げます。


正式版とは言うものの、正常に再生できないファイル形式・サンプリングレートなど、多数の不具合が残っているものと思いますので、ご面倒をおかけしますが、こちらのスレッドにご連絡くださいませ。


前スレッドで「音質はβ5で完成。バグ対応のみ行って正式版をリリースする。」と発言しましたが、音質に影響する変更をいくつか行っております。
もしかすると、β5のほうが好ましいと感じる方もいらっしゃるかもしれません。
β5のSDイメージはリンク先に残していますので、音質の差異が気になる方は前スレッドからリンクを探してダウンロードしていただければと思います。

<8/18追記>
当方の環境では、v0.6.0は音飛びが発生しやすいようです。
β5以降に加えた変更が原因と思われますが、対策が完了次第、オンラインアップデートを配信させていただきます。

次回の日記→

←前回の日記

レス一覧

  1. パパリウス様

    v0.6.0正式版のリリースありがとうございます。
    私の環境でも正常に動作しております。
    β5では不具合の対処にお礼申し上げます。

    私の第一印象ですが、β5より音の鮮度が向上したように感じております。
    レファレンスとしておりますのは、Bill Evans Waltz for Debbyなのですが、臨場感が増しており、有名な地下鉄の音もくっきり聞こえてきます。

    まずは、簡略ではありますが、動作報告をさせていただきます。

    もし余裕がございましたら、音質に影響する変更をお教えいただければ幸いです。

    byhiroget9 at2018-08-17 21:42

  2. hiroget9さん

    さっそくのご報告、誠にありがとうございます。

    β5と正式版では、カーネルのビルド方法に違いがあります。

    この変更で、Xenomai上でのレイテンシの平均値が、ユーザスレッドで200ナノ秒改善、カーネルスレッドで50ナノ秒改善、割り込みが50ナノ秒悪化、、、という性能差が生じており、音にも明確な違いが現れています。
    (※平均だけではなく、最小値、最大値、分散を総合的にみて良し悪しを判断しています。平均値の方はgravityで調整できてしまうため、最も重要なのは分散と最大値が小さいこと、つまり処理タイミングの揺れが少ないことです。)

    v0.6.0正式版のSDイメージに含めるカーネルをどちらにするか、最後まで迷ったのですが、新方式のカーネルを同梱しました。
    β5よりも良くなった面もあれば、失った面もあるなというのが正直な感想です。
    解析的に聴くと正式版でなければ分離できてない音も多く、質という意味では正式版のカーネルの方が上回っていると判断したのですが、β5の方がノリが良く、どっしりと安定感があり、音源を選ばず気持ちよく聴けますので、β5と正式版のいいとこ取りをできるよう、調整してみたいと思っています。

    ※カーネルの差し替えは簡単ですので、β5のカーネルとインストールスクリプトを纏めたものをアップしようと思います。

    byパパリウス at2018-08-18 09:19

  3. パパリウス様
    #0.6.0正式版を入れさせていただきました。特に問題はございません。Dashboardのレイテンシーグラフは大きく広がって見えます。
    β版との差は私(駄耳には)よく分かりません。
    Raspberry3B+、hifiberry-digi、DiskStation212j(NAS)、ES3098PROで聴いています。

    byeric3 at2018-08-18 10:37

  4. パパリウス様

    Rpi3b+sabreberry32でv0.6.0正式版を拝聴しております。
    山頂で見る青空のように、清々しい音が出ており満足しております。

    pipe.shの中でsabreberry32の場合は、自動でaplayを32bit設定されていますので、mpd.conf側で強制的に32bitでaplayに送り出すよう設定してみました。
    smpdの基本方針としてsoxrは使わない方針かもしれませんが、私の耳にはこちらのほうが心地よい感じがします。

    # Upsampling Setting
    samplerate_converter "soxr very high" #very high, high, medium, low, quick
    audio_output_format "*:32:*"

    byalpaca at2018-08-18 11:22

  5. > ericさん

    RPi 3B+ での動作報告をありがとうございます。
    正常に起動しているようでよかったです。
    安定動作するよう改良を続けて参りますので、お気付きの点があればご連絡くださいませ。


    > alpacaさん

    ご指摘ありがとうございます。

    mpdとshairport-syncは設定ファイルの変更だけでsoxrで32bitに変換できますが、spotify-connectだけ変換の手段を持っておりませんでしたので、苦肉の策としてalsaプラグインの機能で32bitに変換しています。

    spotify-connectが不要であればalpacaさんのように前段でbit深度の変換を行うのが理想的なアプローチだと思います。

    aplayを改造すれば、mpdやshairport-syncの場合とspotify-connectでdeviceの指定を切り替えることも可能だと思いますので、いつか実装してみようと思います。

    byパパリウス at2018-08-18 15:29

  6. パパリウス様

    お世話になります。
    msberry dacで動作確認しました。
    airplayが使用できないようです(リストにあがらない)。
    取り急ぎ、ご報告です。

    byW.Peach at2018-08-18 16:22

  7. まだ聴き込んでいないのですが、第一印象は、symphonic modeとaccurate modeがあった頃の、symphonic modeを洗練させたような印象を持ちました。
    とても気持ちよく響きますね。

    byW.Peach at2018-08-18 16:31

  8. W.Peachさん、こんにちは。

    msberry dacでの動作報告をありがとうございます。

    airplayの件ですが、ympdにはホスト名でアクセスされてますか?それともIPアドレスでアクセスされてますでしょうか?
    こちらで再現する条件がわからない場合は、ログの送付をお願いするかもしれませんが、その際はよろしくお願いします。

    byパパリウス at2018-08-18 17:29

  9. パパリウス様

    早速のご返信ありがとうございます。
    ympdへは、IPアドレスでアクセスしています。
    よろしくお願い申し上げます。

    byW.Peach at2018-08-18 17:44

  10. それにしても、、、まさかsymphonicモード(のalsa-lib)との類似を聴感で指摘できる人間が存在するとは、夢にも思いませんでした。

    ご指摘の通り、Xenomai対応後(v0.6.0β2以降)のsmpdは、symphonicモードと同じ状態のalsa-libを使っています。

    acculateモードとの実装の違いについて説明したことありましたっけ、、、?

    例え違いを知っていたとしても、配布しているSDイメージから実装の違いを特定することはほぼ不可能ですので、W.Peachさんの聴感・試聴環境は微細な特徴や違いを捉え、記憶にある音と比較照合する力が並外れているのでしょう。

    いやー、以前から只者ではないと思っていましたが、、、すごい耳をお持ちです。

    byパパリウス at2018-08-18 17:46

  11. パパリウス様

    モード切り替えが実装された時に、ご説明いただいたような気がしますが、文系人間にはわかるはずもなく…(笑)

    音の滲ませ方が、「あー懐かしいな」と思った次第です。

    byW.Peach at2018-08-18 17:57

  12. パパリウスさん   flyingaceです。

    v606正式版有難うございます。

    Rpi3B + sabreberry32
    β5のグイグイ来る力強い音から一転、隅々までピントがシャープに合ったそれでいて硬さを感じさせない素晴らしい音です。
    β5のカーネルと切替えて両方楽しめるなら大変嬉しいです、是非お願いします。

    不具合報告です。
    airplayを常用しているのですが、mpdに戻ったときに”No such file or directory”が表示され操作できなくなります。
    この時、airplayに戻っての操作は出来ます、またSSHでの接続は問題ないです。
    この状態になるとリブート・シャットダウンしても回復しません、再インストールです。(再現性は高くないです)

    RPi3B+での動作報告が上がっていますが、私の所ではβ5同様Rpi3Bplusでは起動しないいです。(archphile,Z-MPD,Moode4.2等は起動しています)
    試しに、Rpi3Bplusで起動しないSDカードをRpi3Bに挿すと正常に起動するので焼きミスは無いと思いますが。。。

    byflyingace at2018-08-18 17:59

  13. パパリウス様

    airplayですが、リネームとリブートをしたところ、無事に表示されました!
    恐らく、こちらのちょっとした事が絡んでいたのだと思われます。

    byW.Peach at2018-08-18 18:31

  14. >W.Peachさん

    「滲ませ方が懐かしい」という感想が出てくる時点で、私に言わせれば超人です。。。
    モード切り替えはv0.2系でしたね。遠い昔のように感じます。

    v0.6.0正式版ではhiroget9さんに動作確認いただいたdt-blob.binをデフォルトに採用しました。
    これで起動の問題は回避できるだろう、、、と思っていたのですが、正式版でdt-blob.binの無効化(リネーム)が必要だったということは、dt-blob.binによるPLLの周波数変更は安定性の問題を抱えたチューニングということになりそうですね。
    正式版のカーネルはβ5に比べてかなり「攻めた」調整をしているため、これも一因になっているかと思います。


    >flyingaceさん

    不具合のご報告をいただきありがとうございます。
    airplayの再生開始時/停止時にshairport_event.shというスクリプトを実行し、不要プロセスの起動停止を制御しています。
    この処理と、mpdの起動処理が重なることで問題が起こるのかもしれません。処理が重ならないよう、改善してみます。

    RPi3B+についてもご報告ありがとうございます。
    うーむ、なかなかうまくいきませんね。
    他のディストリビューションからブート関連のバイナリを拝借するか、自分でplusを購入して動作確認するしかなさそうです。
    64bit版の開発環境としてもう一台あると便利だな、、、なんて思っていたところなので、、、これは買ってしまえというお告げかもしれません(笑

    byパパリウス at2018-08-18 21:36

  15. >flyingaceさん

    β5のカーネルとの切り替えについては、日曜日中にアップしたいと思いますのでしばしお待ちください。

    正式版のシャープさは、マイクロ秒以下のレイテンシの改善によるものと推測しています。
    一方、β5の力強さはミリ秒程度の長周期のレイテンシの安定性からくるものではないかと推測しています。

    これらの長所を両どりする方法(長周期の揺らぎも小さく、レイテンシの絶対値も小さい状態)がきっとあると思いますので、カーネルの試作・調整を続けてみようと思います。

    byパパリウス at2018-08-18 22:08

  16. パパリウス様

    airplayの件は、こちらの単純なミスでした。
    NASの音源を流している最中に、操作してしまっていました。

    よって、システム上の問題は、全くない筈です。
    混乱させてしまい、大変申し訳ございません。

    byW.Peach at2018-08-18 22:14

  17. W.Peachさん

    ご連絡ありがとうございます。
    dt-blobは問題なさそうで助かりました。

    v0.6系はベータリリースを重ねたものの、実験的要素の塊でまだまだ安定とは言い難い状態です。
    引き続きご支援をよろしくお願いします!

    byパパリウス at2018-08-18 22:23

  18. ババリウスさん
    Symphonic MPD 6.0
    Allo digiOne で動作確認しました。デフォールトのセッティング でNAS のQNAP119 にマウントDAC が異なるので 厳密な比較ではありませんが、Hifiberry igi+pro 、 volumio とつなぎ変えますと、澄んだ切れ味の良い、高分解能の美しい音楽が奏でます。 とうぶんこれをIFi Retro50 で 使いたいと思います。
    ありがとうございます。

    byKE2 at2018-08-19 11:31

  19. > KE2さん

    Allo digioneでの動作報告をいただきありがとうございます。
    お気付きの点がございましたらご連絡くださいませ。


    >flyingaceさん

    カーネルの詰め合わせをアップいたしました。

    1.ダウンロード
    wget "https://drive.google.com/uc?export=download&id=13YTtQY6Ay4Lc0SFPnIe9CbOfWRMvhJAQ" -O smpd_v6_kernel.tar.gz

    2.解凍
    tar xzf smpd_v6_kernel.tar.gz


    <β5のカーネルをインストールする場合>
    cd /home/pi/smpd_v6_kernel/v060b5
    ./kernel_install.sh
    ※再起動後に反映されます

    <v0.6.0正式版のカーネルに戻す場合>
    cd /home/pi/smpd_v6_kernel/v060ga
    ./kernel_install.sh
    ※再起動後に反映されます

    シェルの中で相対パスを使っていますので、必ず上記のように格納先にcdしたあと、./kernel_install.shを実行してください。

    byパパリウス at2018-08-19 14:07

  20. パパリウス様

    お世話になります。
    ダウンロードしまして、解凍後にβ5のカーネルをインストールしようとしますと

    depmod: ERROR: failed to load symbols from /lib/modules/4.14.52-smpd/kernel/net/mpls/mpls_gso.ko: Invalid argument

    と帰ってきます。

    以下は1行ですね。
    export=download&id=13YTtQY6Ay4Lc0SFPnIe9CbOfWRMvhJAQ" -O smpd_v6_kernel.tar.gz

    手順を間違えていないと思うのですが。
    v0.6.0正式版のカーネルに戻すと正常に動作いたします。

    byhiroget9 at2018-08-19 14:58

  21. hiroget9さん、こんにちは、

    ダウンロードのコマンドは、

    wget "https://drive.google.com/uc?export=download&id=13YTtQY6Ay4Lc0SFPnIe9CbOfWRMvhJAQ" -O smpd_v6_kernel.tar.gz

    までが一行です。
    見た目は改行が入っているかもしれませんが、wgetからtar.gzまで全部をコピペしてください。

    depmodのエラーは気になりますね。
    いま外出しておりましたので、帰宅後に再確認してみます。

    byパパリウス at2018-08-19 15:21

  22. パパリウス様

    中身を覗いてみたのですが、以下のようになっております。

    pi@smpd:~ $ ls
    configs misc mpd plugins smpd_v6_kernel smpd_v6_kernel.tar.gz util-dashboard.sh util-freq.sh util-plot.sh util-stat.sh xeno_clock_tune.sh

    pi@smpd:~ $ cd /home/pi/smpd_v6_kernel/v060b5
    pi@smpd:~/smpd_v6_kernel/v060b5 $ ls
    boot kernel_install.sh lib timer_calibration.sh

    pi@smpd:~/smpd_v6_kernel/v060b5 $ cd boot
    pi@smpd:~/smpd_v6_kernel/v060b5/boot $ ls
    bcm2708-rpi-0-w.dtb bcm2708-rpi-cm.dtb bcm2710-rpi-3-b-plus.dtb bcm2835-rpi-a-plus.dtb bcm2835-rpi-b-rev2.dtb bcm2836-rpi-2-b.dtb overlays
    bcm2708-rpi-b.dtb bcm2709-rpi-2-b.dtb bcm2710-rpi-cm3.dtb bcm2835-rpi-b.dtb bcm2835-rpi-zero.dtb bcm2837-rpi-3-b.dtb
    bcm2708-rpi-b-plus.dtb bcm2710-rpi-3-b.dtb bcm2835-rpi-a.dtb bcm2835-rpi-b-plus.dtb bcm2835-rpi-zero-w.dtb kernel7.img

    byhiroget9 at2018-08-19 15:22

  23. パパリウスさん   flyingaceです。

    >カーネルの詰め合わせをアップいたしました。

    誠にありがとうございます、早速試してみました。
    1枚のSDカードで両方使えるので大変ありがたいです、お忙しい中お手間を取らさせまして、有難うございました。

    両方のカーネルのいいとこ取りにも期待が膨らんでしまいます。

    byflyingace at2018-08-19 15:24

  24. パパリウス様

    どうやら、ディスクスペースが足りないため、解凍に失敗していたようです。大きめのパーテーションを作っておかないといけないです。
    もう一度トライしてみます。

    byhiroget9 at2018-08-19 15:58

  25. ”カーネルの詰め合わせ”バージョンでカーネルの切換が少し手間に感じたので、以下のことを試してみました。

    archphileの作者さんが、リブート、シャットダウン等が実装されてないarchphileの為にRaspi SSHというアプリを推奨されています。(ただし、現在はアンドロイド端末のみのようです)

    リモートコントロールアプリ Raspi SSH のDL,設定は以下です。
    https://archphile.org/tips-n-tricks/android-ssh-remote-control-archphile/

    私は日頃archphileのコントロールに利用させていただいています。
    SMPDのカーネルをワンタッチで切替えられるようこのアプリを流用させていただきました。
    以下は、私個人のやり方です、他の方法もあるかと思います。

    <β5のカーネルをインストールする場合>

    "Name"フィールドに"SMPD >>> β5"(適当な名前に)
    "command"フィールドに以下を記述
    cd /home/pi/smpd_v6_kernel/v060b5 && ./kernel_install.sh && sudo reboot

    <v0.6.0正式版のカーネルに戻す場合>

    "Name"フィールドに"SMPD >>> 060ga正式版"(適当な名前に)
    "command"フィールドに以下を記述
    cd /home/pi/smpd_v6_kernel/v060ga && ./kernel_install.sh && sudo reboot

    IPアドレスを固定にしておくと便利です。
    これで、都度々SSH接続してコマンド入力の必用が無くなりました、快適です。

    >パパリウスさん

    今どのカーネルにいるか確認方法が判りません、ご教示お願い出来ますでしょうか。

    長文、乱文失礼しました。

    byflyingace at2018-08-19 17:59

  26. パパリウス様

    毎度、驚きと感動をありがとうございます。

    私の環境(Terraberry DAC2)での動作報告をさせていただきます。

    1.音飛びは、発生しておりません。

    2.AAC、mp3も、正常再生されています。

    3.DSDは、β2と同様、スローでのPCM変換再生となります。

    3につきましては、未定とおっしゃっておられましたね。
    DSD対応のために、いろいろ検証して頂き、ありがとうございます。

    私が愚考するに、DSD対応(DOPやPCM変換再生)は、バッサリ断捨離でもいいのかなと思います。

    現段階で、DSDを凌ぐ程のPCM再生を実現されているように思います。

    手持ちのDSDファイルを、24/176.4か32/352.8のPCMに変換しておいて、それらを、現バージョンのsmpdで再生するのが最善かなと、個人的に思っております。

    byeiyer-music at2018-08-19 18:11

  27. > hiroget9さん

    原因が判明したようでなによりです。
    ディスクフルは私もうっかりやってしまうことがあります。

    > flyingaceさん

    ssh接続・コマンド実行を自動化できるアプリは便利ですよね。
    (iOSの場合は、Appleが提供している「Workflow」というアプリがオススメです。)

    カーネルのバージョン確認ですが、

    uname -a
    コマンドでビルド番号を確認してみてください。

    β5は
    Linux smpd 4.14.52-smpd #26

    v0.6.0正式版は
    Linux smpd 4.14.52-smpd #41

    という番号が確認できると思います。

    ※4.14系列のカーネルを初採用したβ2から数えてv0.6.0正式版の公開までに41個のカーネルが作られ、β5(#26)と正式版(#41)の2つを残し、他は全て電子の海に消えて行きました。


    > eiyer-musicさん

    Terraberry DAC2での動作報告をありがとうございます。

    DSDの件は未対応のままとなっておりますが、細々と情報収集(勉強とも言う)を続けています。

    お手数をかけますが、お気に入りのDSDファイルは、いったんPCM化しておいていただくとよいと思います。

    実装時期のお約束はできませんが、、、
    集めた情報がある時パズルのピースのように組み合わさり、一気に実装が進む、、、というのがこれまでのパターンですので、どうか期待せずにお待ちください。
    (私がDSDに音質面の優位性を確信したら一気に優先度は上がると思いますが、現時点ではPCM信者です。)

    byパパリウス at2018-08-19 18:50

  28. パパリウス様

    私のやらかしてしまったことで、お気遣いさせてしまい申し訳ありませんでしたm(_ _)m

    今日は良い天気なのに、一日家に引き籠ってずっと音楽鑑賞していました。とても気持ちの良い一日を過ごせました。
    来週、出勤したくない病が発症しそうです・・・

    感謝申し上げます。

    byhiroget9 at2018-08-19 19:14

  29. パパリウス様


    お世話になります。
    カーネルの詰め合わせですが、ダウンロードは問題なく行えましたが、解凍で躓きました(大量のエラーメッセージが返ってきます)。

    この手の作業は未だに要領を得ません(笑)

    byW.Peach at2018-08-19 20:00

  30. W.Peachさま


    私もディスクスペースが足らなくて、解答できなかった口です。

    私は“sudo raspi-config”を実行して...


    “7 Advanced Options”を選択

    “A1 Expand Filesystem”を選択

    処理が終わると、“sudo raspi-config”を実行した時のトップ画面に戻りますので、“Finish”を選択

    “Reboot”を求めてくるので、“OK”を選択


    この方法でパーテーションを拡張しました。
    以上、参考になりましたら何よりです。

    byジャイアン at2018-08-19 20:36

  31. ジャイアン様


    コメントありがとうございます。
    手順に沿って行ったところ、
    Command (m for help): The partition table has been altered.
    Calling ioctl() to re-read partition table.
    Re-reading the partition table failed.: Device or resource busy

    The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).
    となり、再起動後cd /home/pi/smpd_v6_kernel/v060b5
./kernel_install.sh
    を叩くと、-bash: cd: /home/pi/smpd_v6_kernel/v060b5
./kernel_install.sh: No such file or directory
    が返ってきます。うまくいっていないですね。

    とりあえず、カードの挿し直しで対応していきます。

    byW.Peach at2018-08-19 21:40

  32. W.Peach様 こんばんは。

    推測なのですが、Device or resource busyということなので、もしかしてSD上に音源を置いていらっしゃないでしょうか?
    間違っていましたらご容赦ください。

    byhiroget9 at2018-08-19 22:22

  33. W.Peach様 はじめまして。

    私も同じ症状でしたが、2行にわけて実行したら成功しました。
    ①pi@smpd:~ $ cd /home/pi/smpd_v6_kernel/v060b5
    ②pi@smpd:~/smpd_v6_kernel/v060b5 $ ./kernel_install.sh

    smpd_v6_kernel/v060b5フォルダへ移動→インストール、の順に行っているみたいです。
    ご参考になれば幸いです。

    byiwa3 at2018-08-19 22:58

  34. hiroget9様


    ご返信ありがとうございます。
    当方、SDカードには音源を置いて無い環境です。

    以前から、新しい事には必ず躓くのがお決まりのパターンなもので^^;
    お気遣いいただき、ありがとうございました。

    byW.Peach at2018-08-19 23:08

  35. iwa3様

    ご返信ありがとうございます。
    レスに倣ってコマンドしてみましたが、やはり/smpd_v6_kernel/v060b5: No such file or directory
    となります。
    当面はカードの挿し直しで対応ですね^^;

    byW.Peach at2018-08-19 23:19

  36. ダウンロードは完了している前提で、sshでログイン後に下記を実行してください。
    1行です。

    cd /run/;sudo tar xzf /home/pi/smpd_v6_kernel.tar.gz;cd smpd_v6_kernel/v060b5;./kernel_install.sh;sudo reboot

    byパパリウス at2018-08-19 23:34

  37. パパリウスさん
    正式版リリースお疲れ様でした。有難く聴かせていただいております。
    音質に関しては雰囲気的にオペアンプに例えればβ5はOPA2604,正式版はOPA2134でしょうか。(違うかな?)
    クオリティーに関してはOPA627と思います。Allo-DigioneにはBCLKの精度向上が非常に効果的ですね。
    私はパパリウスさんが自信をもってリリースされた正式版を聴きます。
    有難う御座いました。

    by出不精 at2018-08-20 01:53

  38. パパリウスさん  

    >カーネルのバージョン確認ですが、

    カーネルの確認が取れました、有難うございます。

    それにしても、β5の#26から正式版の#41まで、15個のカーネルをビルド試行錯誤されたことになりますね、パパリウスさんの努力に改めて感謝いたします。
    詰合せバージョンや両方のカーネルの良いとこ取りバージョンを気軽にお願いしている自分に冷汗が出ます、スミマセン!

    byflyingace at2018-08-20 08:02

  39. >出不精さん

    労いいただきありがとうございます。

    オペアンプの例えの通り、β5と正式版がこれほど際立ったキャラクターを持っていることに興奮しています。

    このキャラクターの違いは何がもたらしているのか、、、?
    この点を探求していけば、おもしろい展開が待っているような気がします。

    β5のカーネルで再生しながらコメントを書いていますが、、、いやー、図太い音が体に沁みて、快感中枢が刺激されっぱなしです(笑
    疲れ・ストレスを溶かして洗い流すにはβ5です!(笑


    > flyingaceさん

    詰め合わせも、いいとこ取りも、私が自分のためにやりたいと思ったことですので、全く負担にはなっておりません。ご心配なく!

    ご指摘を参考にairplayの再生開始・停止時の処理を見直しておりますが、まもなくアップデートを配信できると思います。しばしお待ちくださいませ。

    byパパリウス at2018-08-20 20:36

  40. パパリウス様 

    カーネルの切り替えができるようになりました。いつもありがとうございます。

    某所でも呟いたのですが、β5の「活きの良さ」、素晴らしいですよね。音源や、その日の気分で切り替えるつもりでいます。

    byW.Peach at2018-08-20 21:34

  41. W.Peachさん、こんばんは。

    切り替えできましたか!

    正式版に戻すときは

    cd /run/;sudo tar xzf /home/pi/smpd_v6_kernel.tar.gz;cd smpd_v6_kernel/v060ga;./kernel_install.sh;sudo reboot

    でいけると思います。
    (格納先フォルダが v060b5⇄v060ga と違うだけです)


    β5の活きの良さをそのままに、質を上げていければ最高ですよね。

    今後取り組む主要なテーマ3本をご紹介します。

    (1)Xenomai API適用率アップ

    aplay(およびalsa-libとドライバ)内でLinuxシステムコールを使うとaplayがLinux配下に遷移し、大きなオーバーヘッドが生じてしまいます。
    Xenomaiの性能を発揮するには、Xenomai APIへの置き換えを進め、モード遷移を極力減らしていく必要があります。

    (2)64bit版の開発とllvm-BOLT(バイナリ最適化ツール)の適用

    ちょっと前に「だれかビルドを手伝って!」と呼びかけしたツールがllvm-BOLTです。これがarmの64bitアーキテクチャにしか対応していないことがわかりまして、、、64bit版開発の優先度が一気にトッププライオリティになりました。
    メモリアクセスはCPUキャッシュアクセスに比べて桁違いに遅い処理のため、極力メモリアクセスを避ける必要があります。
    llvm-BOLTを使うことで、CPUキャッシュヒット率が格段に上がり、RPiの最高性能(最小遅延)が発揮できると思っています。

    ベースに使うディストリビューションはArch Linuxを想定していますが、他のディストリビューションを使うかもしれません。

    (3)FIQ(Fast Interrupt Requests)実装

    armのCPUはFIQという高速割り込みの機能を持っており、これを使うとRPiの最高性能(最小遅延)の割り込みが実装できます。
    ただし、arm独自の機能のため、XenomaiでFIQを扱えるかどうかは今のところよく分かっていません。
    (もっとも実現性が低いテーマです。)


    これらと並行して、新テーマ「β5と正式版のカーネルのいいとこ取り」も進めたいと思います。

    byパパリウス at2018-08-20 22:14

  42. パパリウスさん

    352.8kHz/24bit のFLACもDSD64(DSF)同様スロー再生になります。
    ご報告まで

    #猫にケーブルを齧られてI2S-DACが使えなかったのでUSB-DACを使うためしばらくVolumioに浮気していました。

    bybun at2018-08-21 00:00

  43. パパリウス様

    お陰様で、随分楽になりました。

    今後のビジョンについて、まだこんなにも着手する事があるとは、驚きです。
    いつも楽しませて頂くばかりで恐縮ですが、今後の展開も楽しみにしております。疲れの溜まりやすい時季ですので、くれぐれもご自愛くださいませ。

    byW.Peach at2018-08-21 01:10

  44. パパリウスさん

    v0.6.1の公開有難うございます。

    まだ数時間ですが、v060b5とv060gaの各カーネルでairplayv⇄mpd交互に切替えてチェックしていますが問題なく動作しています。(元々発生頻度は低いです)
    一度発生するとLINUX初心者の私にはお手上げで、SDカードの焼き直しで対応するしかありませんでしたが、これで安心して楽しめると思います。
    airplayメインで利用させて頂いていますが、時々mpdに切替えて今後もチェックを続けてみます。

    ところで、的外れかもしれませんが、v060b5とv060gaはピアノに例えればBosendorferとSteinwayのような違いがあるように下記のアルバムを聞いていて感じました。

    SIDE by SIDE Vol.3 PLAYS Bosendorfer&Steinway 1976
    八城一夫(P) 原田政長(B) 潮先郁男(G) 石松元(DS)
    録音エンジニア:菅野沖彦
    レーベル:AUDIOLABO

    このアルバムはジャズの曲をそれぞれに合った二種類のピアノで演奏するというものです。(40年前の録音とは思えない高音質)

    β5はベーゼンドルファー、正式版はスタインウェイがそれぞれの特徴を引き出しているように思います、楽しくて仕方がないです!!!

    byflyingace at2018-08-21 11:05

  45. パパリウス様

    今後のテーマをお教えいただき、ありがとうございます。
    まだまだ改善の余地があるというのは驚きです!
    もし、何かお手伝いできることがありましたら、ご協力いたします。

    byhiroget9 at2018-08-21 20:59

  46. パパリウスさん

    DSDと352.8kHz FLACがスロー再生になる問題が回避できました
    aplayがサンプルレート192.8kHzまでしか対応していないようで(man aplayより)DSDを内部でPCM変換する時に352.8kHzにしているためaplayが実時間で再生できないようです。

    とりあえず/etc/mpd.confの設定変更で半分に下げてます
     # Upsampling Setting
     samplerate_converter "soxr very high"
     audio_output_format "176400:24:*"

    aplayが384KHzまで動けば良いのですが...

    bybun at2018-08-21 22:28

  47. > bunさん

    ご報告ありがとうございます。
    FLACでも同じ現象が出るのですね。

    今までDSD(DoP)の処理に注目して調べていたのですが、高サンプリングレートに共通の現象となれば、調査すべき箇所に心当たりがあります。調査が進展するかもしれません。大変参考になりました。


    > W.Peachさん

    労いのお言葉をありがとうございます。
    W.Peachさんも遠地への引っ越しでお疲れかと思いますが、
    落ち着かれましたら楽園の空気と音楽を堪能なさってください!


    > flyingaceさん

    充実した中低域の再現を得意とするβ5と、燦めくような中高域の描写を得意とする正式版、どちらも音楽が楽しくて一日中でも浸っていられます。

    airplayはネットワーク経由で音声データを受け取ることを前提とした設計になっており、とてもコンパクトでモダンな実装です。
    複雑・高機能なmpdよりも負荷が低く、素晴らしい音質だと思います。
    私もairplayを使っている時間のほうが長いぐらいです。

    Xenomaiに同梱されているツールの一つに「latency」というコマンドがあります。

    ユーザスレッドの測定・・・latency
    カーネルスレッドの測定・・・latency -t 1
    割り込みの測定・・・latency -t 2
    ※Ctrl-Cで停止

    mpd再生中とairplay再生中でlatencyコマンドの測定結果を比べれば、負荷の違い(レイテンシーの大小)が数値として可視化できますので、一度眺めてみてください。


    > hiroget9さん

    応援いただきありがとうございます。
    5回に渡るベータリリースにお付き合いいただきありがとうございました。
    SDの焼き直しは大変なお手間だったでしょう。。。
    しばらくはオンラインアップデートでの配信になりますので、ご安心くださいませ(笑
    今後ともご協力のほどよろしくお願いいたします。

    byパパリウス at2018-08-21 22:43

  48. > bunさん

    スロー再生の件、有益な情報をありがとうございます!
    これを手掛かりに対策を進めることができると思いますので、対策完了まで今しばらくお待ちくださいませ。

    byパパリウス at2018-08-21 22:46

  49. パパリウス様
    #0.6.1にオンラインアップデートして聴いています。ハイレゾの報告ですがPCM96kHz,192kHzは正常になるように改善されています。しかしDSDはスロー再生になってしましまいます。
    使用機材はラズパイ3B+にHifiBerryーdigiの同軸をES9038PROにつないで再生しています。一応ハイレゾが聴けるようになって大変嬉しいです。DSDも改良させるのを心待しています。よろしく
    お願いいたします。

    byeric3 at2018-08-21 23:26

  50. パパリウスさん

    いつもお世話になっております。

    mpdとairplayでレイテンシーの差を眺めているのですが、明らかに両者には数値的にも差が出ていますね。
    下記サイト等を参考にしました。

    https://www.blaess.fr/christophe/2012/07/23/les-latences-de-xenomai/

    ですが今ひとつ理解が出来ません、SMPDと絡めて着目すべきポイントなどをご教示いただけると有り難いです。
    dashboardのグラフはこの数値データから生成されているのでしょうか。

    byflyingace at2018-08-23 08:18

  51. RaspberryPi 3B+にてv0.6.0を起動させようとしましたが、赤LEDが消灯するところまで辿り着けず起動が失敗します。
    Etherのランプも点灯しません。
    ここの書き込みを見るに正常に動作している方もいらっしゃるようですが、何か設定等必要でしょうか。

    当方の環境は以下のとおりです。
    RPi3B+/HiFiBerry DIGI+ PRO/Hugo2
    DLしたv0.6.0ファイルをmicroSDに焼きconfig.txtのDACを修正したものを使用

    よろしくお願いいたします。

    byhawami at2018-08-26 03:46

  52. 上記ですが、HDMIでTVに接続して起動を確認してみたところ、
    「A start job is running for dhcpcd on all interfaces」
    がOKにならないようです。
    これが起動NGの要因なのかは分かりませんが、正常起動するラズパイ3Bを同様にTVにて確認してみたところ、ここで引っかかることはありませんでした。
    なお、ラズパイ側のIPアドレスをDHCPではなく決め打ちにしても挙動は変わりませんでした。

    byhawami at2018-08-28 01:27

  53. すみません、上記を再度確認してみたところ、時間はかかっていますが「Started dhcpcd on all interfaces」でOKになっておりました。
    申し訳ございません。

    byhawami at2018-08-28 02:38

  54. ご無沙汰しております。
    本日、v0.6.2を配信しました。

    <主な更新内容>
    (1)aplayと共有ライブラリ(libarmmem)を更新しました。
    ※僅かながら音質向上に寄与するかと思います。

    (2)レイテンシ計測用のスクリプトを追加しました。(/home/pi/util-latency.sh)
    ※現在、私がgravityチューニングに使用しているツールとなります。


    β5のカーネルの音質がなぜ良いのかずっと追っていましたが、ようやくポイントが見えてきました。
    v0.6系の新カーネルをアップいたしましたのでお試しください。

    ビルド番号は「#65」となります。
    (ビルド番号は uname -a で確認できます)

    1.ダウンロード (wgetからtar.gzまでが1行です)
    wget "https://drive.google.com/uc?export=download&id=1zIgMqmYfwII6trqVABx9WMgHoWUKBdUM" -O smpd_v6_kernel_build65.tar.gz

    2.解凍
    tar xzf smpd_v6_kernel_build65.tar.gz

    3.インストールディレクトリに移動
    cd /home/pi/smpd_v6_kernel/v060#65

    4.インストール
    ./kernel_install.sh
    ※再起動後に反映されます


    <補足>
    gravityチューニングのツールとして/home/pi/xeno_clock_tune.shとautotuneモジュールを提供しておりましたが、カーネル#65で廃止しております。(autotuneの判定精度が低いため)


    RPi3以外でsmpdを利用する場合はgravityのチューニングが必須ですが、/home/pi/util-latency.shを活用することでレイテンシを計測しながらチューニングしていくことは可能です。

    (RPi3でノウハウがたまってきましたので、gravityチューニングの自動化もできそうです。RPi3b+でsmpdが動くようになったら、自動化スクリプトを書いてgravityのデフォルト値を探索してみようと思います。)

    byパパリウス at2018-09-09 14:26

  55. パパリウスさん

    アップデートを首を長くしてお待ちしておりました。開発の労をとっていただいていることには、感謝の言葉しかありません。大変にありがとうございます。
    同時に「新カーネル」のアップ、ありがとうございます。
    さっそく「新カーネル」と従来のカーネル(v060gaに収められているビルド #41という理解で正しいでしょうか?)を入れ替えながら、数曲、鳴らしました。

    従来のカーネルでも十分に高音質で、その出音感にストレスを感じません。
    しかし、#65の新カーネルでは、そのストレス感がさらに低くなっているように感じます。その違いを表現するいい言葉が思い浮かばないのですが(「透明感と躍動感が同居しているような」とか、そんな抽象的な言葉しか思い浮かばないのです)、まだ出音にストレスを感じさせる要素が残っていたことに、素直に驚いています。

    byジャイアン at2018-09-09 17:03

  56. パパリウスさん

    v0.6.2のリリース誠に有難うございます。
    #41→#65ご苦労様です、感謝申し上げます。

    β5(#26)の躍動感が好ましく感じていましたのでβ5+airplayで楽しませて頂いていました、#65はまだ一聴程度ですがジャイアンさんに同感です。

    v0.6.2に、β5(#26)のカーネルをインストールして計3つのカーネルで聴き比べしてその変化を楽しませていただいています。
    カーネルの切換には以前オススメ頂いたiosのアプリWorkflowを利用しています
    Workflow内の Run script over SSH というactionを利用することで、IPアドレスとコマンド記入するだけでカーネルの切換が可能となりました、アドバイス有難うございました。

    byflyingace at2018-09-09 17:55

  57. > ジャイアンさん

    ご報告ありがとうございます。
    ご認識の通りv060gaディレクトリのビルド番号#41のカーネルがv0.6.0正式版のものになります。

    正式版公開後、β5(#26)を越えるためにカーネルの試作とgravityチューニングを繰り返し、性能測定を続けてきました。
    時間がかかりましたが、この作業を通していくつか新しい発見があり、非常に有意義でした。


    今回アップした#65ですが、もうしばらく試聴を続けて音質に確信を持ちましたら、オンラインアップデートで配信したいと思っています。


    > flyingaceさん

    #41(正式版のカーネル)は、
    timer_calibration="1303i/3178k/4740u"
    に設定するとβ5のクオリティにいくらか近付きます。
    お時間があればお試しください。

    8/23にも書き込みしていただいていたのに、ご返信できておらずすみません。
    ダッシュボードのグラフはlatencyコマンドの-gオプションでデータをとってグラフ化しています。

    v0.6.2で/home/piにutil-latency.shというシェルを追加しています。
    ./util-latency.sh
    と叩いてもらうと、CPU1のレイテンシを3分間計測し、lat#xx.log というファイルに測定結果を出力します。

    音質との相関が最も強いのは、
    HSS| avg で始まる行にある
    レイテンシの平均値の分散(stddev)です。

    <#65 ユーザスレッド計測例>
    HSH|--param|--samples-|--average--|---stddev--
    HSS| avg| 59999| 0.167| 0.439

    この例だと、レイテンシの平均値は0.167マイクロ秒、
    分散が0.439マイクロ秒ということを表しています。
    この分散が小さいほど、再生品質は良くなると感じています。


    <#26(β5) ユーザスレッド計測例>
    HSH|--param|--samples-|--average--|---stddev--
    HSS| avg| 59999| 0.178| 0.489


    <#41(v0.6.0正式版 改) ユーザスレッド計測例>
    ※timer_calibration="1303i/3178k/4740u"に変更して計測
    HSH|--param|--samples-|--average--|---stddev--
    HSS| avg| 59999| 0.163| 0.454

    byパパリウス at2018-09-09 19:43

  58. パパリウス様

    v0.6系の新カーネルで早速聴きはじめました。
    一聴して、音にメリハリがあるように感じております。
    特にアコースティックギターやウッドベース、パーカッションの生々しさが向上したように思います。倍音成分がきれいに再生されているのではないでしょうか。
    またまた音楽を聴く時間が長くなりそうです!

    感謝申し上げます。

    byhiroget9 at2018-09-09 19:48

  59. パパリウス様

    久しぶりにsymphonic-mpdに戻ってまいりました。
    #41と#65のkernelはかなり音が違いますね。両者を比較すると前者は少し派手めですが音が少しぶれてハレーションが発生してる部分があるのに対し、#65はきちんとフォーカスがあっていて正しく再生している印象があります。

    bytakoyaki at2018-09-09 21:14

  60. パパリウス様

    お世話になります。
    0.6.2へのアップデートおよびカーネル#65のインストールを行いました(今回はスンナリいきました)。

    ここのところ、ずっと#26で聴いていたので、そことの比較になりますが、#26よりも重心が低くなり、ほんの少しデッド気味に振られ(SNが上がった、という表現が正しいのでしょうか)、当方の現在の環境へのマッチングが素晴らしく、ありがたい限りです。
    以前は、パパリウスさんデフォルトの設定から、少しだけ結び目を緩めるようなチューニングをさせて頂いていたのですが、最近使い始めたシステムでは、デフォルトのままが最良のようです。

    なかなかgravityを触るところまで辿り着けません(笑)

    byW.Peach at2018-09-09 22:16

  61. パパリウス様

    試しにクロック設定を0.5の時のcore_401のパターンにし、ユーザスレッドを計測したところ、
    HSH|--param|--samples-|--average--|---stddev--
    HSS| avg| 59999| 0.002| 0.049
    となりました。
    ここからgravityを変えてみて数値、音がどのように変わっていくか、楽しみです。

    byW.Peach at2018-09-09 23:56

  62. periodic user-mode taskの方を見るのですかね。
    だとしたら、
    HSH|--param|--samples-|--average--|---stddev--
    HSS| avg| 59999| 0.339| 0.647
    で、追い込みをかけないといけませんね。

    byW.Peach at2018-09-10 00:15

  63. hiroget9 さん、takoyakiさん、W.Peachさん

    皆さんから肯定的なファーストインプレッションを聞くことができ、自信が深まりました。
    #41は時間軸の揺らぎが大きかったからか、低域の表現が今ひとつで、相対的に高域が強調された派手な再生となっていました。
    #65では基音と倍音の時間軸がピッタリあっているのか、低域の沈み込みも深く、高域も伸びやかです。音源の材質が見えるような、階調豊かな表現になり、S/Nが向上したかのようです。


    >W.Peachさん

    オーバークロック設定を変えた場合は、割り込み・カーネルスレッド・ユーザスレッドの全てを調整していく必要があると思います。
    gravity設定を変えてレイテンシの平均値がある値に近付くと、あるところでスッと分散が収束します。
    帰宅しましたら詳しく書かせていただきます。

    byパパリウス at2018-09-10 08:20

  64. W.Peachさん

    gravityチューニングについて補足させていただきます。

    まず、Xenomaiのgravity設定は、
    レイテンシーグラフの山を、そっくりそのままの形で左に移動させるものだと思ってください。

    タイマーをセットしてスリープしたスレッドや、タイマーによって定間隔で処理を行うスレッドは、予定していた起床時間が来るとOSに起こされ、処理を開始します。
    ですが、実際にスレッドが処理を開始できるのは、起床予定時間から数マイクロ秒から数ミリ秒程度、遅延が生じてしまいます。

    これがOSジッタに起因する遅延です。

    割り込み待ちでスリープしているスレッドも同様の遅延が生じます。PCMデータの書き込みが可能になるのを待っているスレッドは、ハードウェア側の準備が整うとOSから通知を受け取り、スレッドはPCMの送信を開始しようとするのですが、ハードウェア側の準備が出来てからPCMの書き込みを開始するまでにも、数マイクロ秒から数ミリ秒の遅延が生じます。

    Xenomaiでは、起床予定時間よりすこし早めにスレッドを起こすことで、予定時間ぴったりに処理を開始できるように調整することができます。
    1マイクロ秒遅れるのが分かっているなら、1マイクロ秒早く起こしてやればいいという理屈です。

    これがgravity tripletというパラメータの役割になります。

    (※正確性を欠く説明ではありますが、ご容赦ください。私もぼんやりとしか理解しておりませんので、、、)

    to be continued...

    byパパリウス at2018-09-10 22:49

  65. チューニングの手順をあれこれ書いてしまうと、先入観を植え付けてしまい、新たな発見を阻害してしまうかもしれないのですが、、、
    あえて私のチューニング手順をお伝えしておきます。

    (実際、β5のgravity設定はセオリーから外れた設定になっています。経験を積んでしまうと先入観が邪魔して再現できなかったでしょう。β5は経験の浅さが生んだ偶然の産物でした。)

    gravityは、レイテンシーグラフをナノ秒単位で左にずらすというイメージです。

    gravityを大きくしていけば、いくらでもレイテンシーは小さくなっていき、ついにはゼロを通り越してマイナスになります。

    レイテンシーがマイナスというのは、「予定時間よりも早く起きてしまう」状態です。

    セオリーでは、レイテンシーがマイナスになるようなgravityは避けるべきとの記述がコミュニティのメーリングリスト(だったかな?)にありました。

    早すぎる場合にカーネルやドライバがどのような処理を行うのか調べないと結論はだせませんが、β5の教訓から言えることは、「マイナスになるgravity設定を恐れる必要はない」と思っています。

    当初、gravityを変化させてレイテンシーをゼロに近づけていったとき、ゼロに近くにつれて徐々に音質が良くなっているのかと思っていたのですが、必ずしもそうではありませんでした。
    また、レイテンシーがゼロの近辺になったときに音質が最高に達するのでは、と想像していたのですが、確かにゼロ近辺がベターではあるものの、ベストではありませんでした。

    レイテンシーがゼロに近いから、とか、マイナスだから、とかはあまり気にしても仕方がなく、設定の絞り込みの目安程度に考えて色々と試す必要がありました。
    3つのgravity設定をあれこれいじっていると、あるときスッとβ5の活きの良さが再現されます。
    これはβ5のカーネルに限らず、試作した複数のカーネルで見られた現象でした。
    β5の活きの良さは、カーネルコンフィグに起因するものではなく、gravity設定が噛み合った時に現れるものでした。

    to be continued...

    byパパリウス at2018-09-10 23:18

  66. さて、本題のチューニング手順です。

    まず、
    echo "0i/0k/0u" |sudo tee /proc/xenomai/clock/coreclk
    でgravity設定をクリアし、
    ./util-latency.sh
    で素のレイテンシーを計測します。

    計測時は、airplayかmpdで音楽を再生しておいてください。
    負荷をかけていないと、レイテンシーが小さすぎて有益な情報が取れません。

    計測結果のファイル(lat#xx.log)には3つのデータが記録されます。
    上から、
    ユーザスレッド、
    カーネルスレッド、
    割り込み
    のデータとなっています。

    真ん中のカーネルスレッドのデータ(Test mode: in-kernel periodic taskで始まるブロック)から、
    RTSで始まる行の一番左のデータに注目します。
    これは、計測期間中で最も小さい遅延時間です。
    例えば、それが2500(ナノ秒)だったとしますと、カーネルスレッドのgravityを2500近辺に設定します。
    これはレイテンシーグラフをぎりぎり左まで寄せた状態と言えます。
    この状態で再測定すれば、カーネルスレッドのレイテンシーの最小値はゼロ近辺になると思います。

    割り込みのgravityも同様に、
    Test mode: in-kernel timer handlerで始まる3つめのブロックから
    RTSで始まる行の一番左の値を見て、gravityを設定します。

    カーネルスレッドと割り込みのgravityは、レイテンシの最小値がゼロ近辺になるところがベストの値があるように思っています。

    最後にユーザスレッドのgravityですが、

    「無負荷状態で計測して、RTSで始まる行の左から2番目の値が、ユーザスレッドとカーネルスレッドで概ね一致するように」ユーザスレッドのgravityを設定します。
    RTSの行の左から2番目の値は、計測期間中のレイテンシの平均値です。

    このようにユーザスレッドのgravityを設定すると、ユーザスレッドのレイテンシの最小値は、おそらくマイナスに突入しているかと思います。
    (β5は思いっきりマイナスに突っ込んでいます。#65のカーネルだと、ぎりぎり0近辺で留まります。)

    ここまでで、gravity tripletの大まかな目安がきまります。

    to be continued... (文字数制限が厳しいです。。。)

    byパパリウス at2018-09-10 23:53

  67. ここからさらに細かな調整を行います。

    ダッシュボードのレイテンシーグラフを見ると、一番左の山(サンプル数1万前後の山)に続いて、2つほど小さな山があるかと思います。
    あの小さな山ができるだけ小さくなるようなgravityの組み合わせを見つけます。
    これは、負荷の大きなmpdを再生中に計測して
    lat#xx.logのヒストグラム部分の値を見て判断することができます。

    gravityの組み合わせが噛み合うと、β5の活きの良さが再現されますので、ここでチューニング完了です。

    このような流れでgravityを決定したあと、各カーネルの測定結果を横並びで眺めると、「レイテンシーの分散」が音質と強く相関しているということが見えてきました。


    以上です。

    wikiか配布サイトに書けばよかったですね。
    文字数制限に何度もひっかかりながら、なんとか完結です。。。


    > W.Peachさん

    いろいろgravityをいじってみて、なにかヒントが欲しいと感じたら、私の書き込みを読んでみてください。

    この手順はβ5の再現を省力化するものではありますが、もっとよいgravity値が存在するはずです。

    byパパリウス at2018-09-11 00:01

  68. パパリウス様

    お世話になります。
    とても詳しいご説明、誠にありがとうございます。
    まずは、いつものように、双方向に大振りに振って傾向を探って、少しずつ詰めていけたらと考えています。
    イメージとしては、車のチューニングに近い印象です。
    既成概念に囚われないよう色々試してみたいと思います。

    byW.Peach at2018-09-11 02:22

  69. パパリウス様

    echo "0i/0k/0u" |sudo tee /proc/xenomai/clock/coreclk
    の0の箇所を任意の数字に変えてコマンドを叩くと、その値で試聴できる、という理解でよろしいでしょうか。なお、任意の数値を入れた後に、
    cat /proc/xenomai/clock/coreclkを打つと、デフォルトの数値が返ってきます。

    また、/home/pi/configs/timer_calibration.shを打ってもPermission deniedが返ってきて、詰んでいます。

    byW.Peach at2018-09-12 00:43

  70. cat /proc/xenomai/clock/coreclkの方は、入力した値が返ってきていました。

    byW.Peach at2018-09-12 00:47

  71. パパリウス様

    お世話になります。
    gravityの調整方法を参考にさせていただき、トライしてみましたが、なかなか良い結果が得られず、デフォルトに戻しました。
    gravityの調整の手順なのですが、
    負荷をかけてカーネルスレッド、割り込みを測定した結果を反映させずに、無負荷でユーザスレッドの測定、反映という手順であっていますでしょうか?
    カーネルスレッド、割り込みを測定した結果を反映させてから、ユーザスレッドの測定する方法も試したのですが、いずれもダッシュボードのレイテンシーグラフが右へ動いて行ってしまいます。
    見ている数値が違うのかもしれせん。

    いずれにしても、gravityのデフォルトで良い音を聴かせていただいています。

    byhiroget9 at2018-09-12 12:43

  72. > W.Peachさん、hiroget9さん

    駆け足で説明してしまったため、細かい部分がケアできていませんでしたね。すみません。

    帰宅しましたらチューニング時の操作をもう少し丁寧に補足したいと思います。
    また、チューニング時に何度も行う操作(gravityの設定や確認)についてはシェルを用意するなどして簡略化を検討してみます。


    > W.Peachさん

    Permission deniedが出るのは権限不足の時です。
    コマンドの冒頭に sudo をつけていただけば大体OKです。

    gravityを反映するには、
    timer_calibration.shを編集してから
    sudo /home/pi/configs/timer_calibration.sh
    で実行していただくと即時に反映されます。

    echo "??i/??k/??u" |sudo tee /proc/xenomai/clock/coreclk
    で??部分の数値を変えてcoreclkに直接書き込んでも即時に反映されますが、こちらの方法には注意点があります。

    mpdで再生/停止したときや曲の変わり目でtimer_calibration.shが実行されるので、timer_calibration.shに記載しているgravityで設定が上書きされてしまいます。
    つまり、echoで直接書き込む場合は曲間に差し掛からないよう気をつけないといけないということになります。。。

    airplayも、再生/停止したときにtimer_calibration.shが実行されるのでgravityが上書きされますが、曲の変わり目ではtimer_calibration.shは呼ばれません。

    util-latency.shに
    sec=60
    と計測時間を定義している箇所があります。
    (上記設定は、60秒でユーザスレッド・カーネルスレッド・割り込みの測定をするので合計で180秒かかります)

    設定を変えながらちょっと傾向を見たいという場合は、
    このsecを10〜20にしてもらえば、さくさく計測できると思います。

    byパパリウス at2018-09-12 13:13

  73. 取り急ぎgravity確認・再設定のコマンドを書いてみました。
    wikiをご参照ください。

    https://github.com/papalius/symphonic-mpd/wiki/Xenomaiチューニング

    byパパリウス at2018-09-12 22:20

  74. > hiroget9さん

    ダッシュボードのグラフは、ユーザスレッドの測定結果のみをグラフ化したものです。
    util-latency.shの計測結果にはユーザスレッド・カーネルスレッド・割り込みの測定結果をサマリしたものとなっており、ダッシュボードよりも遥かに多くの情報を含んでいます。

    カーネルスレッド・割り込みのgravityを変更した場合、ユーザスレッドのレイテンシーに与える影響が小さいため、ダッシュボードのグラフの変化もごく僅かとなります。


    私が紹介した手順は、下記方針に基づいて設定する場合の手順となります。

    ・割り込みのgravityは、割り込みのレイテンシーの最小値が0近辺となるように設定(0i/0k/0uの状態で測定)

    ・カーネルスレッドのgravityも、カーネルスレッドのレイテンシーの最小値が0近辺となるように設定(割り込みのgravityは設定済みの状態で測定。??i/0k/0uの状態。)

    ・ユーザスレッドのgravityは、「ユーザスレッドのレイテンシーの平均値がカーネルスレッドのレイテンシーの平均値に近い値になる」ように設定(割り込みとカーネルスレッドのgravityは設定済みの状態で測定。??i/??k/0uの状態。ユーザスレッドの測定は、無負荷状態での測定結果を比べるか、airplay再生中の測定結果を比べるのがよいと思います。負荷が大きくなるにつれてユーザスレッドのレイテンシーの平均値はどんどん大きくなり、カーネルスレッドのレイテンシーの平均値から乖離していくため。)

    byパパリウス at2018-09-12 22:36

  75. パパリウス様

    詳しい解説をありがとうございます。
    また、gravityチューニング用の関数のwikiもお手数をおかけしました。
    今夜は遅いので、明日にでも試してみます。

    byhiroget9 at2018-09-12 23:03

  76. パパリウス様

    おはようございます。
    お陰様で、上手く設定することができました。
    ありがとうございました。

    1 wikiでご説明いただいた内容を準備
    2 i k u 全部クリア → g 0 0 0
    3 負荷ありで計測 → kのみ設定 → g 0 2500 0
    4 負荷ありで計測 → iの値追加 → g 1050 2500 0
    5 負荷なしで計測 → uの値追加 → g 1050 2500 3912

    というような手順ということで合っていますでしょうか?
    結果として次の値を設定することができました。
    irq=1041 kernel=2499 user=3906

    デフォルトに近い値ですね。
    レイテンシーグラフの山も一番左に寄り、次の山も小さくなっています。
    音質については帰宅後にゆっくり聴いてみます。

    byhiroget9 at2018-09-13 07:27

  77. > hiroget9さん

    手順については問題ありません。

    割り込み、カーネルスレッド、ユーザスレッドの順にブレが少ないので、私はi->k->uの順で作業していますが、kから始めても問題ないと思います。

    この設定を起点にしてパラメータ探索する場合、
    割り込みを3パターン、カーネルスレッドを5パターン、ユーザスレッドを7パターンの組み合わせ(3x5x7=105パターン)が探索範囲の中心になると思います。

    割り込みとカーネルスレッドのgravityは固定して、ユーザスレッドのgravityのみを探索し、よさそうなパラメータが見つかったら改めて割り込みとカーネルスレッドのgravityを微調整して確認する、、、という手順も、探索パターンを減らせるので良いかと思います。

    オーバークロック設定を変更した状態でもこの手順が通用するかどうかは、正直わかりません。

    特に、方針の3つ目として挙げた「ユーザスレッドのレイテンシーの平均値がカーネルスレッドのレイテンシーの平均値に近い値になる」ように、、、という部分は経験的に見出したもので、理論的な根拠はありません。なにか理論的な背景が隠れているのかもしれませんが、今はなんともいえません。

    byパパリウス at2018-09-13 18:42

  78. v0.6.3を配信しました。

    <主な更新内容>

    (1)sshログイン時のメッセージ(/etc/motd)を更新しました。

    (2)新カーネル(ビルド番号#65)を正式採用しました。

    カーネル一式の容量が約17MBあるため、アップデートに時間がかかります。

    既に#65を適用している場合はカーネルの更新はスキップされます。

    byパパリウス at2018-09-13 18:43

  79. パパリウス様

    お世話になります。
    パラメータの探索の指針をご教示いただき、ありがとうございます。
    カーネルスレッドと割り込みはデフォルトで良いのではないかと感じていますが、先入観にとらわれず、パラメータを変えて試してみようと思います。

    byhiroget9 at2018-09-14 07:47

  80. パパリウス様
    何時も使わせて頂いているSymphonicMPDですがV0.6.3に上げさせて頂きました。昨日オーディオ友達にも聴いて戴きましたが音の良さを評価して頂きました。全体に見て何処にも違和感が無く音の広がりも素晴らしいです。PCMであればハイレゾも問題がありません。DSDファイルが正常に再生できる日を待っています。宜しくお願いいたします。

    byeric3 at2018-09-15 08:50

  81. はじめまして

    symphonic-mpd、ありがたく使わせていただいてます。
    V0.6.3にアップデートし、以前のkernel切り替え用
    smpd_v6_kernel.tar.gz等を残したままにしてると、/が100%になり、プレイリストが保存されず
    再起動するとクリアされます。/ の空きを確保すれば保存されます。


    ところで、64bit版への移行は進んでますか?
    archの64bit版にraspberry piのgithubにあるkernelとfirmwareを組み込んで
    mpd,ympdが動いてNASをマウントし、ES9023なDACで音が出ています。
    私のスキルでは、音出しまで・・・

    byCresson at2018-09-16 11:17

  82. > hiroget9さん

    gravityチューニングは探索範囲が広いうえ、音質が連続的に変化してくれないのでなかなか手強いですよね。
    W.Peachさんがオーバークロックした状態でのgravityチューニングに取り組まれており、完成度の高いパラメータを絞り込めてきているようです。朗報を待ちましょう(笑

    > ericさん

    ご報告ありがとうございます。
    DSDについては気長にお待ちください。

    > Cressonさん

    はじめまして。
    v0.6.3でのカーネル更新はRAMディスク上でダウンロード・解凍を行なっているため、空き容量に関わらずアップデートできるものと思っていますが、空き容量が本当にギリギリ(1〜2MBとか。。。)だとディスクフルになってしまうかもしれませんね。
    次にSDイメージを作る際は、ディスク空き容量にもう少し余裕を持たせた方がいいかもしれませんね。

    64bit版の開発は、arm64向けのXenomaiパッチの公開待ちです。
    https://xenomai.org/downloads/ipipe/v4.x/arm64/

    上記URLに4.14系列のカーネル用のパッチがアップされたら64bit版の開発にシフトします。
    (Xenomaiのgithubにはarm64向けのファイルがアップされていますが、正常に動くレベルになっているんでしょうか。。。)


    v0.6.4を配信しました。

    <主な更新内容>
    (1)aplay/alsa-libに独自のパッチ当て、Xenomai APIの適用率を改善しました。

    現在取り組んでいるテーマの一つである「Xenomai API適用率向上」の中間成果物となります。

    byパパリウス at2018-09-22 21:33

  83. パパリウス様

    お世話になります。
    早速0.6.4にアップデートしました。変更内容についてサラッと書かれていますが、かなり大きな変化があるように感じました。
    現在、オーバークロック[arm_1203]で追い込み中なのですが、0.6.3と比べて、高域の空間表現がかなり変わっていて驚きました。

    gravityについて、ユーザースレッドの方は、ある程度結論がでていますあが、割り込みとカーネル、特にカーネルの方はもう少し追い込めそうなので、もう少し粘ってみたいと思います。

    byW.Peach at2018-09-23 00:20

  84. こんにちは

    あくまでも、私の主観なんですが、Arch64bit版はノーマルでArchphileより良い音が出てる気がします。
    64bit版楽しみに待ってます。

    一応、RT Kernelも試したのですが、RTだとIRQ割り込みのために
    CPU負荷が常に10%ちょっとかかってます。なので諦めました。
    ちなみに、RTでTimer Frequency 1000Hzにすると、音楽を再生中にMPDが落ちて
    使い物になりません。

    byCresson at2018-09-23 15:52

  85. パパリウス様

    お世話になります。
    gravityチューニングは、おしゃるとおり、なかなか難しいですね。
    いろいろ数値を変えてみましたが、結局デフォルトの設定に戻して聴いています。
    オーバークロックまでは、試していませんでしたので、W.Peachさんのご報告が待ち遠しいですね。
    ところで、アップデートありがとうございます。
    またまた新たな領域に入っていかれるようですね。
    聴き始めたところですので、第一印象でしかありませんが、S/N比がさらに向上し、繊細な音まではっきりと聴こえてくるように感じています。

    byhiroget9 at2018-09-23 17:01

  86. パパリウスさん
    W.Peachさん

    0.6.4の音、良いですね!以前に増して音の響きがさらに充実したように感じます。

    また、私はW.Peachさん試しに提示してくださったパラメーターで鳴らしているんですが、これがまたイイ!W.Peachさん、本当にありがとうございます。
    特にデフォルトと比べて違いを大きく感じるのはAirPlay再生音です。AirPlay再生音には、どこかいがらっぽい響きを感じてたのですが、W.Peachさんの設定にすると、そのいがらっぽさが軽減し、よりナチュラルな響きになります。気持ちよく響いてくれるので、音楽再生だと音量を上げられますし、よく通る音になるので、ネット配信の音声(NHKの語学講座アプリ)だと音量を2dB程度絞っても十分に聞き取れます。

    私自身は、パラメーターをいじりながら音を探るような地道な作業を最も苦手としていますので、この辺の開拓はパパリウスさん、W.Peachさんをはじめとする他の方にお任せです。どうぞよろしくお願いいたします。

    byジャイアン at2018-09-23 17:23

  87. パパリウス様

    お世話になります。
    クロックアップ状態で調整してきましたが、設定値がほぼ固まったのでご報告します。
    symphonic-mpd0.6.4 #65
    msberryDAC
    arm=1203 core=401 sdram=401 gpu=67
    over_voltage=8 p=7 i=1 c=1
    irq=885 kernel=2083 user=2760
    で、#65の元のキャラクターを残しつつ、余裕のある鳴らし方が加わったように思います。 ※kernelの調整が手強かったです。
    ちなみに、この状態からキャラクターを変えるには、over_voltageを調整するのが早いと思います。例えば、音場を広げるには、p=5,i=2,c=4とする等、以前のノウハウも活かせることを確認しています。
    個々の環境(DACや機材等)により印象や結果は変わるでしょうが、恐らく傾向としては同じような結果が得られるのではないかと思います。

    ジャイアン様
    いつも、検証いただきありがとうございます。複数の異なる条件で検証いただけるので、いつも助かっています。ナチュラルな響きになるのは、0.5系のPLLチューニング?の時の傾向がそのまま活かされているのだと思います。

    byW.Peach at2018-09-23 19:07

  88. > Cressonさん

    64bit版のArchは良さそうですね!
    今までのノウハウの集大成として一から作り直しますので、お時間はかかると思いますが納得のいくものができると思います。
    ご期待くださいませ。
    Timer Frequencyはカーネルタスクの切り替え周期ですので、高すぎるとタスクスイッチ自体が音楽再生の阻害原因となってしまうので注意が必要です。
    不要なカーネルスレッドは止めてユーザプロセス(スレッド)も最小限に絞り込んだ上でスケジューリングポリシーをFIFO(またはRR)にし、そもそもタスクスイッチが不要な状態を作った上で、Timer Frequencyは低く抑える(100Hz〜250Hz)のがベストだと思います。

    > hiroget9さん、ジャイアンさん

    ご感想をいただきありがとうございます。
    v0.6.4は、Xenomai API適用作業の完成度で言うと60%というところです。
    API適用前は
    「 システムコールの処理時間」+「モードスイッチのオーバーヘッド 」
    が遅延の要因となりますが、Xenomai APIを使った実装に置き換えることで
    「システムコールの処理時間」+「Xenomaiスレッド⇆Linuxスレッド間のXDDP通信オーバーヘッド」
    が遅延の要因になります。
    このXDDP通信(Cross-domain datagram protocol)部分の実装が悪いと余計に遅延が増えることになってしまうため、思ったように音質が改善されません。
    残り40%部分の実装はなかなか時間がかかりそうです。


    > W.Peachさん

    おお、ついに来ましたね!!
    早速、私の環境で試聴してみましたが、高域の鮮烈さが際立つチューニングと感じました。
    クロック設定とgravity設定でここまでキャラクターが様変わりするとは驚きです。
    msberryをお使いの方にはぜひとも試していただきたいですね!
    ベストマッチングしたmsberryはさぞかし鮮烈な音を奏でるのでしょうね。

    相対的には「デフォルトチューニングは中低域寄り」、「W.Peachチューニングは中高域寄り」という解釈ができるのでしょうか?
    この点を踏まえて環境ごとにマッチングをとってもらうことができそうですね。

    チューニングマイスターがいるお陰で、私がカバーできない部分をきっちり固めていただけるのでとても助かります。
    毎度ありがとうございます。

    byパパリウス at2018-09-23 20:55

  89. W.Peach様

    クロックアップでの設定値の情報、ご提供ありがとうございます。
    さっそく試してみました。
    低域に深みが増したように感じます。素晴らしい耳をお持ちですね!
    私のDACは廉価なhifiberry-dacですが、良い音で鳴っております。

    byhiroget9 at2018-09-23 21:04

  90. パパリウス様
    お試しいただきありがとうございます。当方、チューニングの際はJAZZ系の音源を使うのと、打楽器が好きなので、ご指摘のような傾向になりやすいのだと思います。0.5系以降は、デフォルトの中低域を活かしたまま、中高域の空間表現を触らせて頂いているイメージです。
    上記の設定で、高域が出過ぎと感じられる場合はirqとkernelの数値を増やすと、緩和の傾向にもっていけそうです。
    これからも、色々試してみたいと思います。

    hiroget9様
    お試しいただきありがとうございます。同じhifiberry系ですので、音の傾向は似ているのかなと思います。クロックアップした時の余裕のある感じも良いですよね。
    次は、core_freq432でのクロックアップで色々試してみたいと思っていますので、またお試しいただけたら幸いです。

    byW.Peach at2018-09-23 22:07

  91. > W.Peachさん

    私の環境では高域が鮮烈で空間表現・描写に優れて凄まじい存在感を放っています。
    相対的に、中低域は高域の陰に隠れてしまい、低域の弾力・コクが聞き取りづらくなっています。

    これはシステム構成やルームチューニングなど、環境の差異によるところが大きいのではないかと思います。

    私のシステムは高域寄りになりやすい要因がいくつかあります。

    一つは、ルームチューニングに使用している調音パネルが4〜8KHzを拡散反射すること。
    もう一つはアンバランスケーブルにモガミ2803、スピーカーケーブルにモガミ2804を使っており、表皮効果を抑制する結果として一般的なケーブルに比べて高域寄りのバランスになることです。

    このようなちょっとクセのある環境でデフォルトのパラメータを決定していますので、必ずしも多くの環境にマッチングする設定ではないと思っています。

    W.Peachさんが自分の耳で確かめながら決定されたパラメータは、デフォルトチューニングよりも広い環境にマッチングする可能性が高いと思っています。

    あらゆる環境にマッチする万能なパラメータは存在しないと思いますので、複数のセッティングが提示される意味は非常に大きいと思います。

    byパパリウス at2018-09-23 23:07

  92. > W.Peachさん

    core_freq 432でのチューニングに取り組まれるということですので、少し補足させていただきます。

    <core_freq=432の狙い>

    ラズパイは、19.2MHzの水晶発振器に5つのPLLがぶら下がっています。
    core_freqは「PLLC」(Video Core Clockとも呼ばれる)の周波数の決定に関係しており、PLLCはVideo関連機能とメモリの動作周波数に影響します。
    PLLの制御はクロックマネージャと呼ばれるドライバが取り仕切っているのですが、、、
    このクロックマネージャの動作について、2つの仮説を立てています。

    (1)クロックマネージャの処理が少なくなるような設定のほうが音質に良い(負荷が減り、メモリ動作に関わるPLLCやI2SのMCLKになるPLLDが安定する?)

    (2)PLL周波数は低いほうが音質に良い(ノイズが減る?)


    (1)については、
    ・arm_freqとcore_freqを整数比にする(整数比ならなんでもいいわけではない)
    ・PLL周波数を19.2MHzの整数倍にする
    といった工夫をすることで音質が良化するという経験則から推測したもの。

    (2)については、core_freq=401(PLLCは1604MHz)の評判がよいことから推測したものです。


    さて、これを踏まえて、SMPDのデフォルト設定の
    arm_freq=864 (PLLBは864MHz)
    core_freq=432 (PLLCは1728MHz)
    が何を狙っているかというと、

    ・PLLBが19.2MHzの整数倍
    ・PLLCが19.2MHzの整数倍、かつ、PLLCが極力小さい(1600MHzに近い)
    ・PLLBとPLLCが整数比

    という3つの条件を満たす組み合わせの一つとなっています。

    この条件に近いものとして、
    arm_freq=960 (PLLBは960MHz)
    core_freq=480 (PLLCは1920MHz)
    がありますが、PLLCがやや高めですね。

    PLLCを抑えることにこだわらなければ、かなり沢山の組み合わせが存在します。

    byパパリウス at2018-09-23 23:11

  93. W.Peachさん

    さっそく試させていただきました。時間が時間なので、久々にヘッドホンを引っ張り出してみました。我が家のあり合わせSPシステムでは変化を聴き取りづらいって事情もあるのですが。視聴環境は以下の三種です。

    1. Terra-Berry DAC2 → Balanced Ultra Desktop Amp

    2. HiFiBerry Digi+ Pro → Fostex HP-A8改

    3. SabreBerry32 → 真空管ヘッドホンアンプ WooAudio WA2

    Headphone : Ultrasone edition9

    これだけ環境が違うと、同じヘッドホンと言えどもまるで別もののように音はかなり違うんですが(edition9なので低域に独特のコクがありますw)、それでもそれぞれで、W.Peachさんが仰っているような傾向の変化、中高域の情報量が増して、全体的なバランスが良くなっているような変化を聴き取れました。
    一例を挙げると、真空管HPAではkernel=2135ではうるさく感じられたのが、kernel=2083では角が取れたような聴きやすい音に。コイツ、やりますね!

    今、SPでロック(MUSE)を鳴らしてますが、イヤァ〜コレハ楽しい!しばらくはコレをデフォルト設定にして楽しみたいと思います。

    core_freq=432バージョン、楽しみにしています!

    byジャイアン at2018-09-23 23:20

  94. パパリウス様
    なるほど、パパリウスさんの環境だと、私のパラメータだとシャープ過ぎな印象になってしまいますね。
    現在arm=1296にしていますが、この場合のPLLBはどうなりますでしょうか。
    ちなみに、core=432で詰めた方が、より現在のsymphonic-mpdの路線に近い鳴らし方をしてくれます。
    しかし、PLL周波数まで含めた調整となると、いよいよ追いつかなくなってきそうです(笑)

    ジャイアン様
    kernelの数値が案外効果が大きいですよね。
    core=432のパターン(暫定値)もツイートしたのですが、パパリウスさんのレスを見ないままやったものなので、大幅に変わるかもしれません。

    byW.Peach at2018-09-24 00:50

  95. W.Peachさん

    そのcore=432のパターンもさっそく試してみました。
    ガッツリ感のある低域ですね。私には音が重すぎて、元に戻しましたが。
    今後の展開、期待して拝見させていただきます!

    byジャイアン at2018-09-24 01:15

  96. > W.Peachさん

    お返事が遅くなりました。
    arm=1296の場合、PLLBは1296MHzとなります。
    PLLBはCPUの周波数制御のために専用で割り当てられているPLLとなります。

    PLLCはcore_freq≠PLLCなので、ちょっと特殊と言えるかもしれません。
    19.2MHzの水晶を逓倍してPLLの周波数を得たあと、PLLを分周することでPLLにぶら下がっている各クロックを生成します。
    このとき、PLLの周波数が低いと分周で得られるクロックが限られるため、狙った周波数と乖離がでてしまいます。
    このため、複数のクロックがぶら下がっているPLLCは、core_frocの設定をベースにして1600MHz〜2400MHzの範囲でPLL周波数を決定しています。こうすることで分周で得られる周波数を多くし、Video関連機能の各クロックを設定値に近い値で得られるように工夫されています。

    ※I2S用のクロックのように精度が求められるクロック向けにFractional-N(分数分周)が選択できるようになっておりますが、これはまた別の話になるので割愛します。


    さて、arm_freqとcore_freqの組み合わせについてですが、

    (1)PLLBとPLLCが整数比(組み合わせがごく少数に限られる)

    (2)arm_freqとcore_freqが整数比(組み合わせのパターンが多く、arm_freqを上げやすい)

    という指針は、本当に効果があるかどうかは、ファームウェアとカーネル(クロックマネージャ)の実装を確認しなくては、なんともいえません。

    選択肢を狭める原因を作っているのはPLLCの決定ロジックの部分ですので、ここを上書きして任意の値に設定できればいいのですが、
    PLLBとPLLCは電圧低下(Under Voltage)や温度上昇(Over Temparature)をトリガーにして強制的にCPUやメモリのクロックを引き下げる制御が入っており、その際にPLLBとPLLCも自動的に上書きされるような仕組みになっています。

    このようなPLLCの特殊性から、PLLCの初期設定についてはこれまで二の足を踏んでおりましたが、PLLBとPLLCを整数比にすることで音質改善するという確信が持てたら取り組む価値が出てくるかなと思っています。

    byパパリウス at2018-09-24 21:40

  97. パパリウス様

    詳細なご説明ありがとうございます。
    これまで様々なパラメータで聴いてきた印象だと、
    ・PLLBが19.2MHzの整数倍
    ・PLLCが19.2MHzの整数倍、かつ、PLLCが極力小さい(1600MHzに近い)
    の影響が大きいように思います(感覚的に、ですけど)。
    試しに、arm=1152,core=432の組み合わせで試してみようかと思います。

    byW.Peach at2018-09-25 00:59

  98. パパリウス様

    お世話になります。
    またまたアップデートされたようで、パパリウス様のご労苦には頭が下がります。
    どような改善をされたかは、またお教え頂けると思いますが、私が一聴した限りでは、さらに透明感が増したように感じました。
    もっとも、今週は多忙であまり音楽を聴く時間がなく、久し振りに聴いたので、そのように感じているだけかもしれませんが・・・いずれにしても心地良い音だと思います。

    byhiroget9 at2018-10-05 18:38

  99. パパリウス様

    お世話になります。
    0.6.5にアップデートしました。
    比較の為、0.6.4の設定値を全てデフォルトに戻してから行いました。
    高域の存在感が増したのもそうですが、全体的にかなり鋭い音になっている印象を受けました。
    パラメータは触っていないのですが、かなりデリケートな印象を受けます(笑)

    byW.Peach at2018-10-06 16:58

  100. > hiroget9さん

    v0.6.5は、取り組みテーマの一つである「Xenomai API適用率向上」の成果となります。

    まだベストな実装とはいえないものですが、何パターンも実装を試し続けてだんだん煮詰まってきてしまいましたので、、、現時点で最善と感じたものを配信しました。

    気分転換も兼ねて、他のテーマに着手しようかなと思っています。


    > W.Peachさん

    先月の後半に拙宅にお客様がいらっしゃったのですが、その時にたくさんの刺激をいただきまして、、、重い腰をあげてスピーカーのセッティングを見直しました。

    以前は動線を妨げないよう壁際に寄った配置だったのですが、フリースタンディングに近い配置に見直したことで試聴環境が大きく変わりました。
    smpdのチューニングにも影響しているものと思います。

    暫くはチューニングの方向性が定まらないかもしれませんが、、、ご容赦くださいませ。

    byパパリウス at2018-10-06 18:50

  101. パパリウスさん

    私も遅ればせながら0.6.5にアップデート。
    レイテンシーグラフでさらにチューニングが追い込まれていることを確認しました。
    カラクリの解説が楽しみです。(ついていけるかどうかは別問題)

    byジャイアン at2018-10-06 18:51

  102. パパリウス様
    Dashboardのグラフや、ユーザースレッドのレイテンシが安定して短縮しているので、適用率の向上が音質の鋭さにも反映されているのですかね。
    かなり大胆にスピーカーセッティングを変えられたようで、出音の違いに合点がいきました。

    byW.Peach at2018-10-06 19:06

  103. 高域の表現が、これまでと全く違うので、位相系のチューニングをこれから詰めていく、といったところでしょうか。
    リスニングポイントとスピーカーとの往復が大変そうですね(笑)

    byW.Peach at2018-10-06 19:09

  104. パパリウス様

    いつもながら解説ありがとうございます。
    アップデートさせていただいてから、聴きこんでいますが、素晴らしい音質で音楽を楽しめています。
    聴きなれた曲でも、まだまだ新たな発見があるとは驚きです!

    パパリウス様の取り組みを楽しみにしております。

    byhiroget9 at2018-10-06 20:01

  105. > ジャイアンさん

    aplay/alsa-lib/alsa-driverの主な仕事は以下の3つです。
    (1)名前付きパイプからPCMデータの読み込み
    (2)SOCの制御
    (3)SOCへのPCMデータ転送

    ソフトウェアが責任を担う範囲で最も音質に関わるのは、ハードウェアとの橋渡しとなる(3)の処理であると仮定して、この処理をいかに低ジッタで実装するか、、、ということに取り組んできました。

    Xenomaiのパフォーマンスを発揮するには、Linuxカーネルが提供する機能(システムコール)を使わず、Xenomaiカーネルが提供する機能だけを使い、RTDM(Real-Time Driver Model)というインターフェースを実装したデバイスドライバを使ってハードウェアにアクセスする必要があります。

    次善の策として用いられる方式が、システムコールを使う処理を別スレッドに切り出して処理を代行させるという方法です。
    こうしておけば、(3)の処理を行うXenomaiスレッドはモードスイッチを回避でき、低ジッタの条件をひとまずクリアすることができるというわけです。
    ただし、XenomaiスレッドとLinuxスレッド間の連携をうまく実装しなければかえって遅延が大きくなり、ジッタの原因となってしまいます。


    (2)についてはv0.6.4で対策が完了しており、「xddp」というスレッドが処理を代行しています。

    (1)はv0.6.5で対策した部分で「pipe」というスレッドが増えています。

    (3)はv0.6.0時点でMemory Mapped I/Oを使うことでモードスイッチを回避しています。

    ここまでの対策でモードスイッチを回避できるようになり、Xenomaiアプリケーションとしての最低ラインをクリアしたことになります。

    byパパリウス at2018-10-06 20:58

  106. > ジャイアンさん、W.Peachさん

    v0.6.5のもう一つ重要な変更が、period_size(period_time)のパラメータ変更です。

    period_sizeはSOCに送るPCMデータの塊である「チャンク」のサイズを指定するものです。

    period_sizeを小さくすると、PCMデータを小さく分けてSOCに送信するので、

    ・他の処理をブロックする時間が短い(前段の処理が長く待たされることがない)
    ・1回の遅延が影響を及ぼす範囲が小さい
    ・送信回数が増えるため、オーバーヘッドが増加する(CPU使用率が高くなる。結果として、重要な処理を待たせる可能性が高くなる)

    という傾向になります。

    mpdなど、他のアプリケーションのデフォルト値に比べると、v0.6.4までは極端と言えるほど小さな値に設定していましたが、v0.6.5で少し大きめにしました。

    これは、v0.6.4〜v0.6.5でXenomaiスレッドとLinuxスレッド間の通信というオーバーヘッド(さらに、スレッド増加によるコンテキストスイッチのオーバーヘッド)が新たに生じたため、なんらかの方法でCPU使用率を下げてバランスを取り直したいという狙いからです。

    現状ではperiod_timeを/home/pi/configs/pipe.shに指定してaplay内でperiod_size(=チャンクサイズ)を動的に算出していますが、このロジックは改善の余地がありそうです。

    > W.Peachさん

    位相、変ですか?!
    まだまだセッティングを詰めることができてないようですね(汗
    64bit版の開発は待ち状態なので、連休中にスピーカーセッティングを追い込んでみます!!!!

    > hiroget9さん

    v0.6.5から音質傾向が大きく変わってしまったようですが、そちらでは大丈夫そうでしょうか?(汗

    本日、v0.6.6を配信していますので、そちらもお試しくださいませ。

    byパパリウス at2018-10-06 21:22

  107. パパリウス様

    大丈夫ですよ。W.Peachさんがおっしゃる位相については、私の環境では感じていません。同軸スピーカーを使っているためかもしれませんが、そのあたりに関しては影響はないようです。

    byhiroget9 at2018-10-06 21:36

  108. パパリウス様

    高域の出方が明らかに違っていたので、以前のセッティングとはかなり異なる位相(恐らく高域がかなり減衰している)になっているのかなと想像しています。ただ、どちらの状況が正しいのか判らないのですがね(^^;;
    調音パネルも使用されているので、やる事が沢山ありそうですね。

    byW.Peach at2018-10-06 21:56

  109. パパリウスさん

    矢継ぎ早のアップデート、ご苦労さまです。

    v0.6.6にアップデート(v0.6.0から)すると、sabreberry32で音出し出来ないです。
    再度v0.6.0をインストールしてsabreberry32で音出しを確認後、v0.6.6にアップデートしましたがやはり音が出ません。

    v0.6.5の印象ですが、硬質な音を好む傾向の私にはピアノやアコースティックギターが大変心地よく響きます。
    全体的には"#26"のような少しヤンチャ坊主的な所があった方が音楽的によいかなと勝手に思っています。

    byflyingace at2018-10-07 07:41

  110. > hiroget9さん、W.Peachさん

    しばらくは帯域バランスがころころ変わってしまうかもしれませんね。
    試聴環境が落ち着くまでご辛抱ください。

    > flyingaceさん

    ご報告ありがとうございます。
    カーネルを4.14.71に変更した際に、手順が漏れておりました。。。
    対策版(v0.6.7)を配信しましたのでご確認ください。


    スレッドが伸びてきましたので、新規スレッドを建てたいと思います。
    たくさんのコメントをありがとうございました。

    byパパリウス at2018-10-07 12:41

レスを書く

レスを書くにはログインする必要があります
ログインする