syuさん

> dsdリピート再生、昼間の6時間越え、達成しました ^.^

rtoptありのmpd-dsdでも中断なしに再生できたということですね。「syが18-20%程度まで増えていましたが」ということなので、僕の環境では確実に再生中断になる状況なので、不思議ですね。

> 代わりに、再生継続のまま無音が続きます。曲の途中で音が消えるわけではないので、実害は減りました。

この意味ですが、曲の終わりまで再生できて、そのあと音が出ていないのに再生が継続しているように表示されるという意味ですか。また「音消え」というのは再生が一時的に中断されるという意味ですか。

> おそらくmpd-dsdで、このパッチと同等の修正が加わったのだろうと思います。

その通りだと思います。jurgenさんはdsd再生がメインのはずだから、同じようなトラブルにあい、対応されたということでしょう。


こちらでの実験結果ですが、残念ながら、BBBだとどうやっても再生中断は解消されないですね。
raspberrypiサーバ(3.10.10カーネル)がcuboxで好成績だったので(rtopt有りのmpd-dsdでも長時間の連続再生可能でした)、BBBでも試してみましたが、rtopt無しmpd-dsdでも再生中断は発生しますね。BBBに関してはサーバは関係なさそうです。
おっしゃるように再生中断は20分位で発生しました。またtop画面でcpu負荷を確認しましたが、20%近い値で、cuboxの倍以上です。このあたりが影響しているのだと思います。
原因がBBBにあるのか3.8.13rtカーネルかは不明です。タグを使って、3.8の問題が発生する以前のバージョンに戻し、試してみたのですが、起動でエラーになってしまうのですよね。

rtsetのserviceファイルの書式は問題ないと思います。topの表示も正しく設定されてように見えます。

いろいろ試して分かったことはあるのですが、もう少し整理してから書きます。

tinkerさん

> Archってdebianでunstableを使ってるみたいなドキドキ感がありますね^^;

ほんとじゃじゃ馬ですね(^^;;;。昨日出来ていたことが今日は駄目になる世界ですね。

> ２については、yoさん，syuさんの対応の他に、PKGBUILDでは以下のようにしているようです。

これってどこの情報ですか。

yoさん
>これってどこの情報ですか。
ABS（Arch Build System）を入れてます。使ってないですけど^^;
mpdのPKGBUILDを見ると以下のようになってます。

pkgname=mpd
pkgver=0.17.5
pkgrel=1
pkgdesc='Flexible, powerful, server-side application for playing music'
url='http://www.musicpd.org/" target="_blank">http://www.musicpd.org/'
license=('GPL')
arch=('i686' 'x86_64')
depends=('libao' 'ffmpeg' 'libmodplug' 'audiofile' 'libshout' 'libmad' 'curl' 'faad2'
'sqlite' 'jack' 'libmms' 'wavpack' 'avahi' 'libid3tag' 'yajl')
makedepends=('doxygen')
source=("http://www.musicpd.org/download/" target="_blank">http://www.musicpd.org/download/${pkgname}/${pkgver%.*}/${pkgname}-${pkgver}.tar.xz"
'tmpfiles.d')
sha1sums=('a12b78452de5ff876c36827572c6bb4af26e0f7d'
'f4d5922abb69abb739542d8e93f4dfd748acdad7')

backup=('etc/mpd.conf')
install=install

prepare() {
cd "${srcdir}/${pkgname}-${pkgver}"
sed 's:cdio/paranoia.h:cdio/paranoia/paranoia.h:g' -i src/input/cdio_paranoia_input_plugin.c
sed 's:AVCODEC_MAX_AUDIO_FRAME_SIZE:192000:g' -i src/decoder/ffmpeg_decoder_plugin.c
}

本日休日なので、昼過ぎから少し試してみました。

yoさん

>「syが18-20%程度まで増えていましたが」ということなので、僕の環境では確実に再生中断になる状況なので、不思議です ね。

ここの挙動は不安定で不思議ですね。わたしのbbb/arch/Fe では、電源断から起動した直後には、 dsdでcpu%-syが10%以下です。以前は数時間で徐々に18-20%程度まで上がり、 音が消え初め、次いで、tty、sshどちらも接続できなくなっていました。

今回新しくインストールし直したarch linuxだと、cpu%-syの値が長時間安定しています。No.3507で例示したtopは 6時間以上経過した後 ですが、cpu%-syは12%程度までの増加で済んでいます。徐々 にはcpu%-syが増加しますが、増加速度が遅 いので、bbbが落ちるまでの時間が長くなる印象です。

もう一つ不思議なのは、リセットボタンで強制再起動した ときだ けでなく、 rebootコマンドで正しく再起動した場合でも、cpu%-sy が下がらず、再起動前 の状態が（むしろやや悪 化して）引き継がれたよ うに見えることです。

　※　 shutdownして 10秒以上置いてから電源を入れると、dsd再生で のcpu%-syも10%程度に下 がります。
　※　reboot コマンドやリセットボタンで の再起動ではcpu%-sy 増加の原因が消さ れずに残っていることになります。不思議で す。

7月24日にダウンロー ドしたArchLinuxARM- am33x- latest.tar.gzは 177,564,166 bytesでしたが、 9月１日取得版は 163,610,621 bytesで、新しくなっています。これが cpu%-syの増加速度に影 響している可能性はあるかもし れません。

>曲の終わりまで再生できて、そのあ と音が出ていないのに再生が継続しているよ うに表示される

そ の通りです。 0.17.4のとき曲終端でノイズ が出ていた音源に限定した現象です。 gmpcのプログレスバーは次の曲に切り替わって進 行し、 topの状態も変わりなく cpu%-syも低いままで急変しません。 dacの表示は176kHzに変わ り、無音(軽 いホワイトノイズ)になります。 gmpcから [停止] ≫ [再生] で音が復帰します。

>BBBに関してはサーバは 関係なさそうです。

わたしの環境で は、qnap-st212と cubox/arch-linux-3.10.10-no forced preemption だ けが再生中断を生じません。 cubox/archでも他の preemption modelだ と数時間が限界のようです。つまり、bbb とcifsサーバの両方が相 互に関与し合っているように見 え るんですよね　^.^;;

サーバを替えて、topの状態を比較してみました。

○　alix3d2サーバでは cpu%-syが20%程度の高い値

top - 14:49:24 up 3 min, 1 user, load average: 2.23, 0.70, 0.26
Tasks: 70 total, 1 running, 69 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.1 us, 20.9 sy, 0.0 ni, 76.3 id, 0.0 wa, 0.0 hi, 0.7 si, 0.0 st
KiB Mem: 513420 total, 237052 used, 276368 free, 6404 buffers
KiB Swap: 0 total, 0 used, 0 free, 169824 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 14.6 0.0 0:27.28 irq/35-musb+
226 root -54 0 61152 58288 13928 S 3.0 11.4 0:06.03 mpd
76 root -54 0 0 0 0 S 2.3 0.0 0:04.27 irq/57-4a10+
254 root -54 0 0 0 0 S 2.3 0.0 0:03.91 cifsd
403 root 20 0 4612 1276 1008 R 0.7 0.2 0:01.01 top
3 root 20 0 0 0 0 S 0.3 0.0 0:00.27 ksoftirqd/0
77 root -51 0 0 0 0 S 0.3 0.0 0:00.57 irq/58-4a10+

○　umount /root/musicした後、qnapに接続先を変更してmount -a　
(paworoffなしだと cpu%-syは高いまま)

top - 14:53:44 up 8 min, 1 user, load average: 0.15, 0.52, 0.31
Tasks: 68 total, 1 running, 67 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.5 us, 19.6 sy, 0.0 ni, 76.9 id, 0.0 wa, 0.0 hi, 1.1 si, 0.0 st
KiB Mem: 513420 total, 100512 used, 412908 free, 6428 buffers
KiB Swap: 0 total, 0 used, 0 free, 33480 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 14.2 0.0 0:53.12 irq/35-musb+
226 root -54 0 61152 58288 13928 S 3.3 11.4 0:11.50 mpd
76 root -54 0 0 0 0 S 2.0 0.0 0:08.29 irq/57-4a10+
414 root 20 0 0 0 0 S 2.0 0.0 0:00.50 cifsd
77 root -51 0 0 0 0 S 0.7 0.0 0:01.20 irq/58-4a10+
17 root 20 0 0 0 0 S 0.3 0.0 0:00.45 kworker/0:1
416 root 20 0 4612 1276 1008 R 0.3 0.2 0:00.17 top

○　qnap に接続したまま poweroff > 10sec. > power onした場合は cpu%-syが低くなるが、cuboxの方が優秀。

top - 14:58:06 up 1 min, 1 user, load average: 0.42, 0.19, 0.07
Tasks: 70 total, 1 running, 69 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.2 us, 13.3 sy, 0.0 ni, 83.9 id, 0.0 wa, 0.0 hi, 1.6 si, 0.0 st
KiB Mem: 513420 total, 100776 used, 412644 free, 6404 buffers
KiB Swap: 0 total, 0 used, 0 free, 33412 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 14.2 0.0 0:04.79 irq/35-musb+
226 root -54 0 61152 58288 13928 S 3.3 11.4 0:01.72 mpd
254 root -54 0 0 0 0 S 2.6 0.0 0:00.96 cifsd
76 root -54 0 0 0 0 S 2.0 0.0 0:00.92 irq/57-4a10+
77 root -51 0 0 0 0 S 0.3 0.0 0:00.15 irq/58-4a10+
190 root 20 0 4772 3532 472 S 0.3 0.7 0:02.03 haveged

○　no.3507から転載。cuboxの場合。cpu%-syが最も低い。

top - 19:03:31 up 6:07, 1 user, load average: 0.03, 0.07, 0.21
Tasks: 68 total, 1 running, 67 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.3 us, 11.7 sy, 0.0 ni, 84.8 id, 0.0 wa, 0.0 hi, 1.2 si, 0.0 st
KiB Mem: 513420 total, 373560 used, 139860 free, 1628 buffers
KiB Swap: 0 total, 0 used, 0 free, 310980 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 14.2 0.0 51:58.06 irq/35-musb+
226 root -54 0 61292 58428 13928 S 3.0 11.4 12:09.01 mpd
76 root -54 0 0 0 0 S 2.3 0.0 7:46.92 irq/57-4a10+
254 root -54 0 0 0 0 S 2.3 0.0 7:25.61 cifsd
427 root 20 0 4612 1276 1008 R 0.7 0.2 0:00.16 top
77 root -51 0 0 0 0 S 0.3 0.0 1:00.42 irq/58-4a10+
423 root 20 0 0 0 0 S 0.3 0.0 0:02.89 kworker/0:2

いずれも、bbb側は、/etc/fstabの変更だけです。
相互作用の原因がわからないのが問題なんですよね。

bbbのcifsdに問題があるのかなあ。
他の機種のmpdでサーバを替えてどうなるかですかね。

tinkerさ ん

>mpdの PKGBUILD

見てもわからな い私には、ABSは まだ早過ぎるよ うです ;-p

tinkerさん

お答えありがとうございました。

ABSですか。mpdのビルドが簡単になるのなら、試してみますかね。しかし、
sed 's:AVCODEC_MAX_AUDIO_FRAME_SIZE:192000:g' -i src/decoder/ffmpeg_decoder_plugin.c
というのは随分乱暴な修正のしかただと思いますが(ハードコーディング)、どうなのですかね。まあ人のことはいえなけど(^^;;;。

syuさん

とりあえず、こちらで分かっていることを書いておきます。
BBBはまだ試していないのですが、cuboxの方では、rtoptパッチと3.10.9-rtカーネルを共存させる方法は分かりました。
ハードウェア割り込みの優先レベルは梅雨入りバージョンのままにしておいて(lan=56、usb=55、その他=51)、mpdプロセスの優先レベルを40番台に下げます(player=47、decoder=46、audio_output=47)。あとは以下のスクリプトをブート時に起動します。
#!/bin/sh

while true
do
chrt -f -p 49 `pgrep kworker/0:0`
chrt -f -p 49 `pgrep kworker/0:1`
chrt -f -p 49 `pgrep kworker/0:2`
sleep 300s
done

要するにrt優先度の指定の問題です。kworkerというのはカーネルの割り込み処理に関連するプロセスのようですが、これがmpdプロセスに妨害されて動けなくなると再生中断が発生するということのようです。
これで、sacd3枚分の連続再生はできることは確認しました。nasは僕の環境で一番再生中断を起きやすい玄柴nfsモードです。

yoさん

>あとは以下のスクリプトをブート時に起動

rtカーネルでのdsd中断対策が無限ループみたい、って言う冗談なのかと思ってしまいました　^^;;

斬新なアイディアに脱帽です。kworkerと言うプロセス、調べても私には理解できませんでしたが、優先度を5分おきに再指定する必要があるような挙動をするプロセスなんですね。

bbbだとどうなのか、3.8.13-rt9ですが適用してみました。

> mpdプロセスの優先レベルを40番台に下げます(player=47、decoder=46、audio_output=47)。

この通りにmpdconfでの指定を変更。

no.3507で使ったrtset.serviceで呼び出すrtsetスクリプトを変更。

[root@arch-mpd ~]# nano /usr/local/sbin/rtset

#!/bin/sh
chrt -f -p 55 `pgrep irq/35-musb-hdr`
chrt -f -p 53 `pgrep irq/57-4a100000`
sleep 10
chrt -f -p 53 `pgrep cifsd`


新しく、kwsetと名付けたスクリプトを作成

[root@arch-mpd ~]# nano /usr/local/sbin/kwset

#!/bin/sh
top
while true
do
chrt -f -p 49 `pgrep kworker/0:0`
chrt -f -p 49 `pgrep kworker/0:1`
chrt -f -p 49 `pgrep kworker/0:2`
sleep 300s
done

ログイン後に適当なタイミングでkwsetを実行しました。
これで、無限ループしている最中の top を見ることができましたが、bbbでtopを眺める程度では、taskがひとつ増えた以外の違いはわかりませんでした。（ターミナルをsshでもう一つ開いても操作は可能でしたね。）

>　これがmpdプロセスに妨害されて動けなくなると再生中断が発生

この現象は、何かで観察されたのですか。

>nasは僕の環境で一番再生中断を起きやすい玄柴nfs

やはりこうやるのが王道ですね。

yoさん
>随分乱暴な修正のしかただと思いますが
Archは以前のVer（0.17.3だったかな）でも同じように修正しているみたいです。
まっ、動けばいいかと^^;

>chrt -f -p 49 `pgrep kworker/0:0`
wandboardで故あって同じこと試してるところでした。こちらでは、ksoftirqdを上げてみました。
debian，ubuntuはうまくいってるんですが、Archが・・・
今度、kworkerで試してみます。

syuさん

> rtカーネルでのdsd中断対策が無限ループみたい、って言う冗談なのかと思ってしまいました　^^;;

(大笑い)。
ご明察の通りで、kworkerというプロセスがゾンビのごとく生まれ変わり、cpu負荷を使って動き回って、mpdのdsd再生を中断させているように見えたのので、とった対策です。
BBBでの対応はお書きになっている内容でOKだと思います。

> この現象は、何かで観察されたのですか。

rtoptパッチをかけていないmpd-dsdを使っていても、chrtでプロセスの優先度を指定すると、同じようにdsd再生中断になるので、これは優先度の指定の問題だなと気が付きました。
ps -eLo pid,lwp,rtprio,priority,cmd | sed -f /root/rtopt.scr > /root/rtopt.sh
sedのスクリプトは以下の通りです。
/\/usr\/local\/bin\/mpd/{
N
N
N
N
s/[^\n]*\n[^\n]*\n *[0-9][0-9]* *\([0-9][0-9]*\)[^\n]*\n *[0-9][0-9]* *\([0-9][0-9]*\)[^\n]*\n *[0-9][0-9]* *\([0-9][0-9]*\)[^\n]*/chrt -f -p 52 \1\nchrt -f -p 49 \2\nchrt -f -p 53 \3\n/p
}
d
この後、rtopt.shを実行します(sh ./rtopt.sh)。
topで調べて、kworkerというやつがしつこく動いていることので、コイツが諸悪の頑強かなと考え、やってみました。

> やはりこうやるのが王道ですね。

ということなので、確実に再生中断が発生する環境で実験してみて下さい。
もっとも、これで再現するとますます謎は深まるのですが(^^;;;。

なかなか時間がとれなくて停滞しています。

>確実に再生中断が発生する環境で実験

私の試せる範囲では、alix3d2/voyage-mpd/nfs3が、dsdではブチブチと断続状態になっていました。（クライアントはbbb/debian/nfs3)

私はarch linuxに拘る係なので(^^;;; alix3d2にmpdなしのvoyage-linuxを入れ、bbb/arch向けにnfs4の指定をしてみました。

すると、ubuntu-pcからはnfs4で接続できるのに、bbb/archからは接続できません。showmount -eではデータサーバが表示されるのに、マウントしようとすると跳ねられるんですよね。

仕方ないのでalix側をnfs3にしたらbbb/archからも接続できました。このとき、bbb/archでは、rpcbindの設定が必要でした。

# nano /etc/hosts.allow

rpcbind: 192.168.11.0/24　＃環境によります

# systemctl enable rpcbind
# systemctl start rpcbind

不思議ですが、kworkerをいじらなくても、bbb/arch/nfs3で中断なくdsdが再生できます。でも・・音は・・相当・・悪い(^^">

cubox/arch-NFP-serverにnfs3の設定もしてみましたが、これはbbb/arch/nfs3から接続できません。ファイアウォール関連なのか不詳。

今のところ、わたしの環境では、cubox/arch-NFP-server/cifsが安定度でも音でも、最強です。

dsd再生中のtop(cubox/arch-smb <-> bbb/arch-mpd)

top - 15:27:32 up 44 min, 1 user, load average: 0.01, 0.12, 0.17
Tasks: 69 total, 1 running, 68 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.0 us, 8.8 sy, 0.0 ni, 88.0 id, 0.0 wa, 0.0 hi, 1.2 si, 0.0 st
KiB Mem: 513420 total, 370980 used, 142440 free, 1276 buffers
KiB Swap: 0 total, 0 used, 0 free, 308476 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 14.2 0.0 6:13.09 irq/35-musb+
232 root 20 0 61292 58408 13928 S 3.0 11.4 1:17.91 mpd
76 root -54 0 0 0 0 S 1.7 0.0 0:46.57 irq/57-4a10+
270 root 20 0 0 0 0 S 1.7 0.0 0:42.90 cifsd
417 root 20 0 4612 1280 1008 R 0.7 0.2 0:13.21 top
77 root -51 0 0 0 0 S 0.3 0.0 0:11.73 irq/58-4a10+
411 root -51 0 0 0 0 S 0.3 0.0 0:02.29 irq/88-OMAP+
1 root 20 0 4796 2668 1796 S 0.0 0.5 0:02.00 systemd

では、また。

syuさん

BBB(3.8rt + arch latest)での確認はこちらでもとってまして、NGでした。優先度をチューニングした環境で再生中断、mpdハングどちらも発生しますね。
まあ予想通りの結果だったのですが、syuさんの環境だと発生しないというのは不思議です。何かnas環境の違いでそういうことになるのでしょう。音が悪いというのは同感です。cpu負荷の問題だと思うのですが、僕の環境だと20%前後となりsyuさんの環境とは大分違うのがよく分かりませんね。

BBB&archという環境はかなりの「じゃじゃ馬」で僕のところでもいろいろ摩訶不思議なことが次々と発生、対応におおわらわという状況です。メゲまして(^^;;;、BBBでのDSD再生は断念し、HD7A-192改専用にして、CDリップした44.1KHzFlacファイル専用に使うことにしました。これは本当に良い音だと思います。現状ではDSD再生はCuboxに任せることにしました。BBB 3.10rt版の登場待ちですね。

みなさま　お久しぶりです。

コンパイル作業は私にはちょっと敷居が高くて、その後ずっとロムさせていただいておりました。
もしよければ現状でのイメージを公開していただけないでしょうか？

当方ＣＤリップした44.1KHz Flacがほとんどで、現状でも問題は発生しておらず、かなり良い音を楽しませていただいているのですが、みなさまのご苦労のたまものを、ぜひとも聞かせていただければと思っております。

どうぞよろしくお願い致します m(_ _)m

まさまささん。

確かに、bbb/arch/rtoptとcubox/NFPserverを、imgかtar.gzで公開した方が話が進みますね。上手くいってない場合も皆で検討すれば突破口が見つかるかもしれません。しばし、お時間をいただきます。

syuさん

> 確かに、bbb/arch/rtoptとcubox/NFPserverを、imgかtar.gzで公開した方が話が進みますね。

気長にお待ちします。イメージ化するのが面倒なら、rootfs丸ごとtar.gzで十分だと思います。同じハード構成なのに、nasの違いで現れている現象はかなり差あるので、興味があります。

あと、Cubox+3.10.9+rt5+mpd-dsdの方は梅雨入り版に追加変更した部分だけtar化して公開するのは簡単ですが、興味のある方いますかね。

私も BBB 試してみました。
みなさん仰るとおり、良い音ですね！CuBox の力強い音もとても魅力的でしたが、BBB は繊細でより情報量が多いように感じます（ジャンルによって使い分けても良さそうですね）。
ただ、私の環境でも DSD は数分で再生中断します（CuBox は全く問題なし）。
それといろいろと挙動に再現性がなく？怪しい感じが（笑）。妖怪かな？

syuさん
yoさん同様、興味あります。イメージ公開を気長にお待ちします。

yoさん
> あと、Cubox+3.10.9+rt5+mpd-dsdの方は梅雨入り版に追加変更した部分だけtar化して公開するのは簡単ですが、興味のある方いますかね。

興味あります！
CuBox の音はこれはこれで魅力的ですし、DSD は現状 CuBox がないとまともに聴けませんので、
気長にお待ちします。


＃ みなさん tsunamp ってご存知でしょうか？
CuBox や BBB もサポートということで面白そうです。
http://www.tsunamp.com/comingsoon/" target="_blank">http://www.tsunamp.com/comingsoon/

yoさん、皆様

BBB/arch/mpd-dsd-rtoptのtarを作ろうとしていますが、多少の混乱を生じています。

nasの問題を切り分けてみるためと音質のリファレンスにするため、新たにsd-musicディレクトリを作り、ここにdffファイルをサーバ(cubox)からコピーしようとしたのですが、すぐにメモリが足りなくなってしまいました。

sdカードの容量がそれほど少ないはずはないので、sdカードを取り出してリーダにマウントし、中を見たのですが、rootfsは９月初めにインストールしたままのarch linux。あれこれ改変した痕跡がありません。

慌ててemmcを覗いてみたら、No.3507で話題にしたrootfsは、実はこっちでした。

しかし、カードなしでemmcから起動してみると、今度は途中で止まってしまう(^^;;

改変なしのarch linuxでsdカードから起動し、emmcのrootfsに入り、
＃ tar czvf ../arch-bbb-rootfs.tar.gz .
とやって、emmcのrootfsを取り出しましたが、これが動いてくれるかどうか・・・今から動作確認等やってみます。

連休中には何とかしたいですが、気長にお待ちくださいませ。

一連の作業をしているときに気づいたのですが、arch linuxのmpdはmpd-0.17.5-1からmpd-dsd-0.17.5に変わってますね。

syuさん & 皆様

こちらも混乱の極みです。

> あと、Cubox+3.10.9+rt5+mpd-dsdの方は梅雨入り版に追加変更した部分だけtar化して公開するのは簡単ですが、興味のある方いますかね。

実は試してみたのですが、同じように奇怪な妖怪に遭遇しています。

tarボールを作り、梅雨入り版にに書き込んでみたのですが、駄目ですね。異常にcpu負荷が高くなり(ほとんど100%)、まともなdsd再生が出来なくなります。tarボールは3.10化した現用のcuboxシステムから作っていますので駄目になる理由がよくわからないのですよね。やっぱりarchには魔物が潜んでいるとしか思えません。ウームです。

syu さん

気長にお待ちしております♪

私の BBB はその後、何もいじっていないせいか、極めて好調に動いております。

ちなみに、今までずっと 0731pe の方で聞いています。
理由としては、44.1K flac でパチノイズが出ないからです。
0731rt だと、44.1K flac で、かなりパチノイズが出るのと、NHK-FMだとちょっと聞いてられないくらいに出たのです。
ただ、0731pe でも 192K Flac にすると、パチノイズが出始めますので、やっぱりCPU負荷が高くなると出るのかなぁと思っていまして、皆様が実施されている kworker の処理を入れられれば、rt でもパチノイズなく再生できるのではと思った次第です。

それから NAS 側の CuBox ですが、実をいうと今まで使っていたしょぼいNASと比べ、私の耳では違いが判らなかったです。
なぜ CuBox を NAS に使っているかというと、ESATA, USB を使って２台の外付けHDが付けられて、GigaEthernet があるためなのです。

yo様、皆様

この度皆様のお陰で何とか運用にこぎ着けました。
改めてお礼を申し上げます。

電源をトランスを使用し、レギュレーターにはローノイズ型の
TPS7A47を使用したところかなりの音質アップとなりました。

スチッチング型のアダプターでは上記と同じ電源対策したvoyage starterkit(シンさんバージョン)の方が良い位でしたが、電源対策する事でBBBが化ます。

S/Nが上がり音の消えゆく様がよく分かり、アーティストの気配を感じる様です。
高音質化に電源対策は必須だと改めて感じた次第です。

以上、そんな事既に知っていると言われそうですが報告させて頂きました。

> 皆様が実施されている kworker の処理を入れられれば、rt でもパチノイズなく再生できるのでは

今日は思い立って、0731rt で yo さんの No. 3514 の書き込み通りの方法でパチノイズが止まるかどうか、ちょっと敷居が高かったのですが頑張ってやってみました。

スクリプトを起動時に立ち上げるっていう技がわからず、ssh terminalで接続している root アカウントから起動して、プロンプトが返ってこない状態で確認しました。

結果ですが、192K, 96K FLAC ではまったく変化無しでした。
それで JAVS X-DDC の後の DAC が悪いのかと思い、96K まで対応している AV アンプに接続し、96K FLAC を再生してみたのですが、残念ながらまったく同じ状況でした。
ということで、rt のソフトに何か問題がありそうです。
しばし待つしかないみたいですね。


コウさん
電源対策いいですよねー。
私もそろそろ自作しようかと思っています。他の電流を食う機器でも使えるようにLM723のキットを使おうかなと計画しています。

まさまさ様

今回手持ちのトランスで組んだ為、一時側電圧が高すぎなので暫定バージョンとしてます。

LM317で一旦電圧落としていますが、2つのレギュレーター共に熱々で常時電源on出来ません。

このままでは怖くてケースに蓋出来ないのでトランス調達し組み直すつもりです。

皆様

emmcから抜き出したarch linuxのrootfsは結局古いものでしたので、最新版で作り直してみました。後ほどアップロードできると思います。

dsdのテストも、より厳しい負荷条件が好ましいと思いますが、FIDELIXさんのサイトに5.6MHz-dffのサンプルが置いてあるのに気付きました。
http://www.fidelix.jp/technology/balance.html" target="_blank">http://www.fidelix.jp/technology/balance.html

下から４行目にリンクのある”5.6MHzオリジナルDFFファイル”(Torna Srrento.dff)はログインなしでもダウンロードできますので、お試しください。
https://skydrive.live.com/?cid=e957a3ce59c390dd&id=E957A3CE59C390DD" target="_blank">https://skydrive.live.com/?cid=e957a3ce59c390dd&id=E957A3CE59C390DD!181&authkey=!ALyQKyBzpXXYQwo

[root@arch-mpd-dsd-sd ~]# uname -a
Linux arch-mpd-dsd-sd 3.8.13-rt9_Fe-00899-g46930b7 #1 SMP PREEMPT Wed Aug 7 01:47:34 JST 2013 armv7l GNU/Linux

[root@arch-mpd-dsd-sd ~]# mpd --version
mpd (MPD: Music Player Daemon) 0.17.5-DSD

以下は、5.6MHz-dff再生中のtopです。

2時間半まで中断なく連続再生できています。引き続きテスト中です。

5.6MHz-dffでは、mpd優先度の設定なしでは頻回にノイズが出ましたが、mpd優先度の設定でノイズは大幅に減り、実用範囲に入りました。

dsd再生は環境による影響が大きく、アップロードするファイルがお役に立つ可能性は低いと思いますが、乗りかかった船ですね(^^;

top - 13:18:29 up 2:31, 1 user, load average: 0.95, 0.83, 0.84
Tasks: 70 total, 1 running, 69 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4.2 us, 19.3 sy, 0.0 ni, 74.5 id, 0.0 wa, 0.0 hi, 1.9 si, 0.0 st
KiB Mem: 513420 total, 165288 used, 348132 free, 7748 buffers
KiB Swap: 0 total, 0 used, 0 free, 95608 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 16.2 0.0 23:33.56 irq/35-musb+
224 root -54 0 61144 58288 13920 S 5.6 11.4 8:00.71 mpd
262 root -54 0 0 0 0 S 4.3 0.0 5:57.13 cifsd
76 root -54 0 0 0 0 S 4.0 0.0 6:02.09 irq/57-4a10+
17 root 20 0 0 0 0 S 0.3 0.0 0:12.18 kworker/0:1
77 root -51 0 0 0 0 S 0.3 0.0 0:49.92 irq/58-4a10+
414 root 20 0 4612 1280 1008 R 0.3 0.2 0:44.87 top
1 root 20 0 4824 2800 1900 S 0.0 0.5 0:01.91 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:05.35 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
7 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/u:0H


[root@arch-mpd-dsd-sd ~]# nano /usr/local/sbin/rtset

#!/bin/sh
chrt -f -p 55 `pgrep irq/35-musb-hdr`
chrt -f -p 53 `pgrep irq/57-4a100000`
sleep 10
chrt -f -p 53 `pgrep cifsd`
chrt -f -p 53 `pgrep mpd`

追記　

5.6MHz-dffでの連続再生、6時間を越えましたので、試験終了してtar.gzファイルの作成(証拠隠滅)に取りかかります。

時間経過とともに負荷が少しずつ低下しているようです。

5.6MHz-dff再生中のtop

top - 17:05:11 up 6:18, 1 user, load average: 0.92, 0.91, 0.91
Tasks: 70 total, 1 running, 69 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4.6 us, 17.8 sy, 0.0 ni, 75.3 id, 0.0 wa, 0.0 hi, 2.3 si, 0.0 st
KiB Mem: 513420 total, 198644 used, 314776 free, 9240 buffers
KiB Swap: 0 total, 0 used, 0 free, 127296 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 16.2 0.0 60:12.14 irq/35-musb+
224 root -54 0 61144 58288 13920 S 5.0 11.4 20:31.36 mpd
76 root -54 0 0 0 0 S 4.0 0.0 15:26.57 irq/57-4a10+
262 root -54 0 0 0 0 S 3.6 0.0 15:14.18 cifsd
77 root -51 0 0 0 0 S 0.7 0.0 2:08.00 irq/58-4a10+
424 root 20 0 4612 1276 1008 R 0.7 0.2 0:06.66 top
422 root 20 0 0 0 0 S 0.3 0.0 0:06.50 kworker/0:0
1 root 20 0 4824 2832 1916 S 0.0 0.6 0:01.92 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:12.57 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
7 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/u:0H

皆様

私の環境限定ですが、5.6MHz-dsdまで連続再生可能なarch linuxのrootfsを公開します。

rtoptパッチをあてたmpd-dsdも最新版を取得し作成しました。

https://docs.google.com/file/d/0B1n2sZGxAleMSTdfNkh4ajkxcEU/edit?usp=sharing" target="_blank">https://docs.google.com/file/d/0B1n2sZGxAleMSTdfNkh4ajkxcEU/edit?usp=sharing

以下、rootで作業します。

# sudo su

# mkdir arch-mpd-dsd

適当にディレクトリを作成し、そこにダウンロードしてください。

# cd arch-mpd-dsd

ディレクトリに移動したら、下のページのinstallタブに書いてある手順で6番目まで、書いてある通りに進めます。

http://archlinuxarm.org/platforms/armv7/ti/beaglebone-black" target="_blank">http://archlinuxarm.org/platforms/armv7/ti/beaglebone-black

７番目は以下のように進めてください。

# mkdir root
# mount /dev/sdX2 root
# tar -xvf arch-mpd-dsd.tar.gz -C root


マウントポイントに入ります。

# cd root

fstabの編集

# nano etc/fstab

パスワードなど、環境に合わせてください。

固定IPの変更（eth0の場合)

# nano etc/conf.d/network@eth0

address=192.168.11.7
netmask=24
broadcast=192.168.11.255
gateway=192.168.11.1

環境に合わせ書き換え。

# nano etc/systemd/system/network@eth0.service

編集が必要な場合があります。

# nano root/.mpdconf

必要なら編集してください。

umountします。

# umount root

sdカードを取り出して、bbbにマウント。
初回だけブートスイッチを３秒程、押し続けたまま起動します。

rootのパスワードはbbblackです。

パスワードを変更してください。

# passwd

１回リブートした方がいいでしょう。

# rebt

２回目からはそのまま電源ONでsdカードから起動できます。
起動後5分間ほど放置してから、演奏開始が良いと思います。

mpdはarch linuxの流儀に従っていますので、設定ファイルは/root/.mpdconfです。
その他は/root/.mpd/にありますが、残渣が残っているかもしれません。
ご笑覧くださってもかまいませんが、口外は禁止します（笑

musicフォルダは/root/musicです。

selbootは使えます。selmpdはありません。

systemctl rebootの代わりにrebtコマンドを使用すると迅速にrebootできると思います。

poffコマンドで迅速なsystemctl poweroffができます。


皆様、ご試用よろしく。

syu さん

どうもありがとうございました m(_ _)m

さっそくやってみました！

[root@arch-mpd-dsd-sd ~]# uname -a
Linux arch-mpd-dsd-sd 3.8.13-rt9_Fe-00899-g46930b7 #1 SMP PREEMPT Wed Aug 7 01:47:34 JST 2013 armv7l GNU/Linux

なんか音がしっとりと落ち着いたような感じがします。

ですが、残念ながらパチ音は直らないみたいです。
14.4K, 96K, 192K FLAC 全てで出てしまいました。
ただし、192K FLAC では頻度が少し少なくなった気がします。

私の場合には、0731pe版で当面過ごすのが良さそうです。

syuさん

BBB Archアップロードありがとうございました。以前公開されたものとは多少変更されているようなので、期待して試してみました。
残念ながら結果はNGです。僕の環境ではDSD再生で再生中断、ハング共に発生します。ただ発生頻度はかなり改善されています。旧イメージだと10分くらいで発生していたのですが、1時間(SACD一枚)聴いて起きることがあるかどうかというところですね。問題が発生しないこともあるので、確認に時間がかかりました。

topの結果です。
top - 17:25:15 up 4:54, 2 users, load average: 0.15, 0.20, 0.22
Threads: 78 total, 1 running, 77 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.9 us, 10.5 sy, 0.0 ni, 86.4 id, 0.0 wa, 0.0 hi, 1.2 si, 0.0 st
KiB Mem: 513408 total, 372648 used, 140760 free, 2168 buffers
KiB Swap: 0 total, 0 used, 0 free, 307016 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 14.4 0.0 33:03.52 irq/35-musb-hdr
76 root -54 0 0 0 0 S 1.6 0.0 4:01.24 irq/57-4a100000
282 root 20 0 0 0 0 S 1.6 0.0 3:34.13 cifsd
293 root -48 0 60760 57976 13920 S 1.3 11.3 3:05.22 mpd
469 root 20 0 4616 1336 1008 R 1.0 0.3 0:00.07 top
77 root -51 0 0 0 0 S 0.3 0.0 0:53.88 irq/58-4a100000
291 root -48 0 60760 57976 13920 S 0.3 11.3 1:02.96 mpd
292 root -47 0 60760 57976 13920 S 0.3 11.3 1:42.53 mpd
459 root 20 0 10444 3420 2748 S 0.3 0.7 0:07.62 sshd
1 root 20 0 4828 2800 1884 S 0.0 0.5 0:01.97 systemd

cpu負荷が10%から15%の間になっています。以前は20%位の値だったので、多少減っていますね。多分このあたりが発生頻度を低下させているのだと思います。
旧イメージと新イメージでネットワークの設定が変わっているようですが(固定アドレス)、これが原因ですかね。
また、topの結果はsyuさんの環境より僕の環境の方が良い(cpu負荷、ロードアベレージなど)のに、トラブルは僕のところでしか発生しないというのが不思議ですね。

音は今回のイメージの方が良いようです。

直前のメッセージを書き込むちょっと前に、リピートモードにして連続再生していますが、3時間位、止まりませんね。一体どうなっているのだろう。このイメージ、エージングされるのですかね。top画面の状況に変化はありません。もう訳がわからん状態ですね。

ちょっと気になることがあり、もう一度試してみました。
実は他の方の設定を参考にしていて、fstab の cifs 接続で rsize,wsizeに関しては何も設定していなかったので、rsize=130048,wsize=4096 を追加してみました。

これを設定したところ、0731rt では 44.1K ではパチ音無し、96K, 192K ではパチ音ありますが、発生間隔がかなり長くなりました。

次に syu さんのイメージで同様に試したところ、やはり改善されたのですが、44.1K では若干パチ音ありになりました。

発生間隔ですが、一定間隔ではありませんので、何かのタイミングでCPU負荷がたまたま高くなったときに発生するのかもしれません。

とりあえず、0731rt では使えることがわかりましたので、大収穫です！

でも、syu さんのイメージが一番音が良いので、なんとかしてみたいです。不必要なプロセスなどを止めれば良いのでしょうけど、何を削ってよいやら。。。

まさまささん

お試し、ありがとうございます。

パチノイズは、うちでも稀に出ます。

もっとも過酷な5.6MHz-dffの再生に限定してですが、mpd優先度の指定を.mpdconf だけでやったときは、かなり頻回にパチ・・・・・・パチ・・・パチ・・・・・・・・・って感じで、非周期的に頻発しました。

/usr/local/sbin/rtsetに　chrt -f -p 53 `pgrep mpd` を書き加えて
# rtset
とやると、ほとんど出なくなりました。

でも、起動する度に5.6MHz-dffでのパチノイズの出方は変化するんですよね。運が悪いと、mpdの優先度を指定しても、5.6MHz-dffに限ってですが、パチパチうるさいことがある。リブートすると多くはおさまります。

困ったことに、cpu負荷の大小とは相関ないみたいです。

sdカードに音楽ファイルをコピーして、そこから再生すると、どうなるでしょう。

# mkdir /root/sd-music
# cd /root/music
とやってから、適当な音楽ファイルを選び、それを/root/sd-musicにコ ピー
# cp <music.wav> /root/sd-music
mpdconfで　~/sd- music　に書き換えて
# systemctl daemon-reload
# systemctl restart mpd

これでネットワークは関係なくなるはずですが、それでもパチ ノイズは出るでしょうか。

実は、私の環境でこれをやってみましたが、5.6MHz-dffを再生させると、数分で演奏停止し、同時にPC側のGMPCが落ちます。ttyはこの段階では生 きていますが、エラーメッセージは出ません。コマンドを入れると１回だけ実行しますが、そのまま落ちます。

私の環境では、LANから読み込むよりsdカードからの方が不利なんです。何が起きてるのかな。

yoさん、お試しありがとうございます。

アップロードしたファイルは最新版をそのままインストールし、pacman -Syuした後、固定IPにし、rtsetを起動させ、mpd-dsd-rtoptを新しくコンパイルしただけのものです。特殊な魔法はかけていません。

>エージングされるのですかね。

書きませんでしたが、実はうちでも、インストールした最初だけ、dsdが数分～10分ぐらいで止まります。
”一時停止　>　再生”でやり過ごすと、その後は停止しなくなる。

理由は不明ですが、sdカードをミュージックディレクトリに指定するとすぐ落ちたりしますので、LANのどこかが学習しているのかなと、ボンヤリ考えてます。

cpu負荷は、起動する度に変動します。今のところランダムに運次第です。演奏開始した初期の値が高いと、ずっとそのままです。topで表示される負荷の大小と音は無相関な印象ですが、音の良し悪しも、cpu負荷とは無関係に、起動する度に変化しているような印象です。

iriverのサンプルdffでScarlattiは曲の終わりでクラッシュしてましたが、今度のrootfsではクラッシュしません。曲の終わりで音が消え、プログレスバーは次の曲に移動。”一時停止　>　再生”で音が復活します。e-onkyoの２Lレーベルの曲で発生するのと同じ現象です。

まあ、当分は、手に負えませんね(^^;

syu さん

色々と情報をありがとうございます。

SD-Card にコピーしてやってみましたが、syu さんと同じで、
SD-Card の方がパチノイズが良く出るようになってしまいました。

ちょっと調べてみたら、どうもバグっぽいです。
https://groups.google.com/forum/#" target="_blank">https://groups.google.com/forum/#!topic/beagleboard/fOGeXCub9OY

チップの設定を間違っているらしくスピードが出ないみたいです。どうやらパッチもあるみたいです（パッと見で、英語ちゃんと読んでませんが、なんとなくそんな感じみたいです）。。。


もしかして、このパッチで直りませんかね？例えば何かログをSDに書き込もうとして遅いので、処理が待たされ、結果としてパチノイズ発生やDSDが止まってしまうとか。。。
（当たってないだろうなぁ。。。笑）

ちなみに、今は rsize=512000 にして聞いていますが、昨晩と比較してそんなにパチノイズが発生せず、気にならないレベルになってきました。
当面これで様子見してみます♪

syuさん

BBB Archアップロードありがとうございました。私も試してみました。
私の環境でも再現性が今一つで報告遅くなりましたが、
DSDは最初数分でstopし、再起動後は数時間大丈夫な場合が多いので、syuさんyoさんと概ね一緒のようです。

>LANのどこかが学習しているのかなと、ボンヤリ考えてます。
Hubでしょうか？

音は落ち着いたやさしい感じですね。
私の環境と音源では 0731rt の方が好みですが、
上流でこれだけ変わるのも面白いですね。

まさまささん

情報ありがとうございます。

パッチ当てはよくわかりませんが、同じrootfsをemmcにも入れていますので、そちらで再生してみました。sdカードは入っていません。

しかし、emmc上のsd-musicディレクトリに置いた5.6MHz-dffを再生すると、数秒で落ちました。落ち方がsdカードの時より早い印象。

このときの状態

[root@emmc-arch-mpd-dsd ~]# fdisk -l

Disk /dev/mmcblk0: 1920 MB, 1920991232 bytes, 3751936 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x4616c03e

Device Boot Start End Blocks Id System
/dev/mmcblk0p1 * 2048 133119 65536 e W95 FAT16 (LBA)
/dev/mmcblk0p2 133120 3751935 1809408 83 Linux

Disk /dev/mmcblk0boot1: 1 MB, 1048576 bytes, 2048 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mmcblk0boot0: 1 MB, 1048576 bytes, 2048 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

[root@emmc-arch-mpd-dsd ~]# hdparm -tT /dev/mmcblk0

/dev/mmcblk0:
Timing cached reads: 530 MB in 2.01 seconds = 264.28 MB/sec
Timing buffered disk reads: 68 MB in 3.14 seconds = 21.64 MB/sec

emmcなら、速度は問題なさそうですが、不必要な割り込みを生じるバグなど、ありそうですね。誰かが解決してくれるまで待つしかなさそう。

当面、emmcにインストールしてLAN経由で音楽聴くのが、気分的にマシかもしれません。

sdカードからemmcにtarするときは、事前に
# selboot 3120ARCH
とやって通常カーネルに戻しておいた方が、問題が起きにくいと思います。

mさん、ありがとうございます。

>私の環境と音源では 0731rt の方が好み

実はまだ試していません(^^;;; あとで比較してみますね。

syu さん

やっぱり、当たってませんでしたね（苦笑）

一からコンパイルするのではなさそうだったので、パッチあてにチャレンジしてみました。

# cd /root
# pacman -S dtc
;省略
Packages (1): dtc-v1.4.0-1
;省略
# cp /boot/dtbs/am335x-boneblack.dtb /boot/dtbs/am335x-boneblack.dtb.org
（とりあえず怖いのでバックアップをとっておきました）
# dtc -I dtb -O dts -o test.dts /boot/dtbs/am335x-boneblack.dtb
# vi test.dts

mmc@48060000 をサーチ
mmc@48060000 {
compatible = "ti,omap3-hsmmc";
ti,hwmods = "mmc1";
; 少し省略
vmmc-supply = <0xb>;
bus-width = <0x4>; <-- この行を追加します
ti,vcc-aux-disable-is-sleep;
linux,phandle = <0x28>;
phandle = <0x28>;
};

save して終了します。

# dtc -I dts -O dtb -o /boot/dtbs/am335x-boneblack.dtb test.dts
# reboot

で、syu さんお察しの通り、直りません。。。
気持ち、パチノイズが少なくなったかな？くらいでした。

残念！

アップグレードで入るbbb/archの最新カーネルは、いきなり3.12.0-rc2-1-ARCHになっていますが、このカーネルでは　bus-width = <0x4>;　がちゃんと記述されていました。

3.12-rtが出ると良いですね。

syuさん

ご返事ありがとうございます。肝心な部分はいまだ闇の中ですが、大分いろいろなことが分かってきましたかね。

> cpu負荷は、起動する度に変動します。

僕のところは文字通りエージングされます。長い時間再生を続けていると良くなります。
ただし、cuboxと異なり今のところ10%以下になることはありません。再生中で試聴している時は、nexus7 ssh端末のtop画面とにらめっこしながら聴いていますが、再生中断はcpu負荷が大きくなった時に発生しています。
インスール直後のまったくエージングされていない時に負荷は極端(50%)に高くなるのですが、これはarch環境の初期化のプロセスがいろいろ動いているためのように見えます(例えばmandbなんかが動いています)。
その後、安定して10%台前半に収まるのですが、時々数十秒のレベルで50%位に跳ね上がるのですよね。この理由がよく分かりません。この状態で再生中断せず連続演奏できるとだんだんcpu負荷が跳ね上がる頻度が低くなり、1時間以上再生続行できている場合は10%台で安定して再生が続きます。

rtカーネルの割り込み処理関連のプロセス管理に起因する障害じゃないかと思います。何か問題があるのでしょうね。lanだと起きにくくなるというのが解せないのですが。

yoさん

topでの最も目立つ差は、Threadsの項目でしょうか。

yoさんのNo.3571では

top - 17:25:15 up 4:54, 2 users, load average: 0.15, 0.20, 0.22
Threads: 78 total, 1 running, 77 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.9 us, 10.5 sy, 0.0 ni, 86.4 id, 0.0 wa, 0.0 hi, 1.2 si, 0.0 st


私の場合（emmcから起動直後2.8MHz-dff)

top - 23:03:12 up 1 min, 1 user, load average: 0.19, 0.10, 0.04
Tasks: 71 total, 1 running, 70 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.7 us, 10.8 sy, 0.0 ni, 85.3 id, 0.0 wa, 0.0 hi, 1.2 si, 0.0 st

dff連続演奏5分経過後

top - 23:07:11 up 5 min, 1 user, load average: 0.17, 0.18, 0.09
Tasks: 69 total, 1 running, 68 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.8 us, 8.7 sy, 0.0 ni, 87.0 id, 0.0 wa, 0.0 hi, 1.6 si, 0.0 st

私の環境では5分過ぎぐらいで、総稼動プロセス数が71から69 に減りますが、yoさんのデータでは、5時間近くでも78です。

同じイメージのはずなのに、私の場合と総稼動プロセス数が９も違う。この原因は何ですかね？　何かプロセスを追加されたのでなければ、外来の原因でプロセスが増えてる可能性ですね。LANですかねえ。何らかの外来因子でプロセス数が増え、突発的なcpu負荷の増加を生じてdsd再生が中断するということなんでしょうね。

syuさん

Threads部分の差はsyuさんと僕の環境差だと思います。

> 私の環境では5分過ぎぐらいで、総稼動プロセス数が71から69 に減りますが、yoさんのデータでは、5時間近くでも78です。

僕の環境でも多少減ります。「cuboxでsamba」のスレッドでのNo.3563で稼働後2分位のtop画面をペーストしてありますが、82ですので。この時使ったイメージはsyuさんの古いarchでしたが、新しいものでも同じだと思います。ただ、9あるトータルの数のプロセス数の差はご指摘のようにネットワークなどの違いに起因するものだと思います(今回はsyuさんのイメージに手を加えていません)。
この違いがトラブルの発生頻度などの差を引き起こしているのでしょうね。

ちなみに、5時間経過後の今回のtopで 2 usersとなっていますが、これはssh接続をnexus7とパソコンの両方から行っているためで、片方を止めるとプロセスの数が減少します。

あと、このThreads部分で重要なのはload averageで、これは処理待ちプロセスの数を意味しますが(現時点から1分前、5分前、15分前)、この値が大きくなると(確実に待たされるという意味の1.00に近づくと)トラブルが発生します。この値はcpu負荷にある程度依存しますね(cpu負荷が高くなると大きくなりますが、そうでない場合もありますね)。

yoさん、みなさま

再起動直後からDSD再生を開始し、load average（1カラム目）を試しに15秒毎に記録してみました。
https://docs.google.com/file/d/0B5eFIaI2AU9INEVQS3Y4MFhfOHM/edit?usp=sharing" target="_blank">https://docs.google.com/file/d/0B5eFIaI2AU9INEVQS3Y4MFhfOHM/edit?usp=sharing
syuさんのBBBは"慣らし"済み（でも時々止まります）。
すべて cifs で NAS と繋いでいます。

"top" 画面をずっと眺めていたことは無かったので、結構激しく動いていてビックリです（何してるんだろ？）。
毎回違うのも謎です。
再生 stop と load average の関係ですが、あるような無いような？よく分かりませんが
0731rt の場合、どうも oad average が跳ね上がった数分後に落ちやすい様です。
load average のピークとか、stop 時の top を調べても
これと言った特徴は見つけられず、、といった状況です。

統計的にはまだまだサンプル数が足りないのと
サンプリング間隔はもっと細かくする必要あるかもですね。

（ちなみに、私の環境では5分過ぎぐらいで、総稼動プロセス数が73から71に減ります。）

状況報告でした。

mさん

データの公開ありがとうございます。興味深く拝見しました。なるほどなぁという感じです。

サーバのチューニングなどで、load averageは1.0を超えると確実に待たされることになるので、何らかの対応が必要と言われているのですが、やっぱりBBBの成績はあんまり芳しくないですね。debianの成績が悪いは意外でした。またarchで1.0を超えてもなにも起きてなくて、その後、問題のなさそうな0.5以下の状態で発生しているのも面白いですね。さすがにcubox archの3.8.10rt6は安定していますね。これがあるべき姿だと思います。

僕の推測ですが、再生中断や音切れの発生要因はrtカーネルのプロセス制御のバグだと思います。
rtカーネルの場合、割り込みハンドラや処理プロセスは独立してrt優先度に合わせて処理される筈ですが、このコントールに何らかの乱れが発生して、一種のデッドロック状態が起き、再生中断したり、音切れしたりするのではないかと思っています。
mさんのデータを見て思うのは、このデッドロック状態が単純にロードアベレージが起きるのではない。しかし、ロードアベレージが高くなると起きやすくなり、0.5以下で収まる環境であれば、発生しにくいというところですかね。

ところでload averageは次のようなスクリプトを用意しておくと簡単に観察ですますね。

#!/bin/sh

date > loadave.txt
while true
do
cat /proc/loadavg >> loadave.txt
sleep 3s
done

問題はpdfにグラフ化する方法なのですが、mさんはどういう具合にされたのでしょうか。

mさん

興味深いデータ、ありがとうございます。

loadの平均値ではなく、サンプリング値そのものを取得するコマンドは存在するのでしょうか。平均を計算するには、適当な間隔でloadの値をサンプリングしているはずなので、何らかの手段で瞬時の値も取得できそうに思うのですが、ググっても判然としません。

maximum load(peak)が観察できると、もっと何かがわかりそうな気がしますね。

# nano /usr/local/sbin/uptm

#!/bin/sh

while true
do
uptime
sleep 1
done
----

# uptm

これで約1秒おきにload average が表示されますが、およそ5秒おきに移動平均を表示するようですね。

syuさん

cプログラミングする覚悟があれば、このページの情報は参考になりませんか。
http://d.hatena.ne.jp/naoya/20070518/1179492085" target="_blank">http://d.hatena.ne.jp/naoya/20070518/1179492085

まあ、僕はパスです(^^;;;。

yoさん

ずっと使うものでもないので、特別なことはしていません（笑）。
今回は load average に影響するプロセスを知りたかったので、
まずは Top を記録
top -b -d 15 > top.log_`date +%y%m%d.%H%M`
less top.log_*** |grep load > load.log
で load average を抽出しました。

Excel から load.log を開いて（区切り文字は "," ":" ）グラフ化
PowerPoint に貼り付けコメント記入、pdf化という流れです。


syuさん、yoさん
調べ切れていませんが、DTrace はどうでしょう？
http://en.wikipedia.org/wiki/DTrace" target="_blank">http://en.wikipedia.org/wiki/DTrace
（出来たとしても音は悪くなりそうなので、僕もパスですが(^^;;;）

皆様

システムモニタ用のツールを調べてみました。
sysstat(sar)というツールが便利ですね。

pacman -Sy sysstat

でインストールする必要があり、使い方もちょっとややこしいですが、例えば

sar -uq -o data.file 1 600 > /dev/null &
sar -uq -f data.file > data.txt
nano data.txt

で1秒間隔、10分間のcpu負荷とロードアベレージをまとめてみることができます。
使い方はibmとoracleのサイトにありました。
ibm
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.cmds/doc/aixcmds5/sar.htm" target="_blank">http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.cmds/doc/aixcmds5/sar.htm
oracle
http://docs.oracle.com/cd/E19455-01/806-2718/6jbtrjv3b/" target="_blank">http://docs.oracle.com/cd/E19455-01/806-2718/6jbtrjv3b/

皆様

No.3463でtinkerさんに情報をいただいたpatchの件、やり方がわからなかったこともあって、適用しないままになっていました。

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=c72a0e036f9d80c609e608a723751343f1f5e9fc" target="_blank">https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=c72a0e036f9d80c609e608a723751343f1f5e9fc

このpatchを適用した3.8-rtをコンパイルしてみましたので、zipファイルで公開します。

環境によっては、もしかすると、ノイズや音切れが減る可能性です。増える可能性もなくはありません。module名が長たらしいですが、ご容赦。ご試用、ご批評、よろしく。

https://docs.google.com/file/d/0B1n2sZGxAleMVW14dlVEUFZzV0E/edit?usp=sharing" target="_blank">https://docs.google.com/file/d/0B1n2sZGxAleMVW14dlVEUFZzV0E/edit?usp=sharing

rootで作業してください。

# sudo su

適当なディレクトリで

# unzip 0807.zip

出来たものをsdカードにコピーします。
sdカードのマウントポイントを/archと仮定

# cd 0807
# cp -r 0807rt /arch/build_files/
# cp -r 3.8.13-rt9_Fe_ehci-sched_patched_-00899-gb3db21e-dirty /arch/lib/modules/

# umount /arch

bbbにsdカードを移して起動後selbootします。

# selboot 0807rt

私の環境では、一部のdsd曲の終末で発生していた音切れ現象の発生頻度が減ったような気がします。

追記

Google Driveの設定が変でした。左上隅のアイコンをクリックしてDriveを開くと、そこから0807.zipを落とせると思います。

追記2

zipファイルの作成でミスってましたので一旦削除しました。m(__)m
後ほど再アップロードします。

syu さん

いつもどうもありがとうございます！

残念ながら、私の flac (44.1K, 96K, 192K)ではほとんど変化はわかりませんでした。


しかし早く根本原因が判って修正されると良いですよね。

どこかに書き込んだら、コード書いた人が気づいてくれたりしないですかねぇ。。。

皆様

zipファイル、容量等が変な気がしたので一度削除しましたが、問題なかったようです。すみません。

新しく作り直したファイルをアップロードしました。
patchを当てた0731rtと0806rtの2種類です。

# tar Jxfv ./0807n.tar.xz
などと解凍したあと、該当ディレクトリにコピーしてください。

0731n.tar.xz
https://docs.google.com/file/d/0B1n2sZGxAleMcnRaV1RSS0M2Q28/edit?usp=sharing" target="_blank">https://docs.google.com/file/d/0B1n2sZGxAleMcnRaV1RSS0M2Q28/edit?usp=sharing

0807n.tar.xz
https://docs.google.com/file/d/0B1n2sZGxAleMbU01SkRlVWNDOU0/edit?usp=sharing" target="_blank">https://docs.google.com/file/d/0B1n2sZGxAleMbU01SkRlVWNDOU0/edit?usp=sharing

まさまささん

ご試用、ありがとうございます。やはりだめでしたか。残念でした。

>コード書いた人が気づいてくれたり

検索してみたら、ロボットやってる方が、BBBの3.8-rtは挙動がおかしいと、RT-Preemptカーネルの評価をしておられるのを発見しました。

http://blog.livedoor.jp/k_yon/archives/52499525.html" target="_blank">http://blog.livedoor.jp/k_yon/archives/52499525.html

騒ぎが伝わって、何とかなると良いですね。

このスレッド、長くなったので、新しいスレッドに移行します。新スレッドのタイトルは「BeagleBone Black(7)」です(最長不倒ですね)。