rockdisknextをマウントする
yoさま、みなさま
初心者質問です。
NASとしてrockdisknextを昨晩うごかしましたが、
マウントできません。
/etc/fstabには
//192.168.0.2/Music /mnt/RDN1 cifs username=admin,password=XXXX,sec=ntlm,uid=mpd,file_mode=0666,dir_mode=0766,iocharset=utf8,rsize=130048,wsize=4096 0 0
と追記。mount -aの返事は
mount error(16): Device or resource busy
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
mount error(16): Device or resource busy
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Retrying with upper case share name
mount error(6): No such device or address
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
でした。たぶん
//192.168.0.2/Music ここのdirectoryの指定が変なのだろうとは思いますが
そうしたら良いでしょう？
現在、梅雨入りver. archlinuxでうごいています。
よろしくおねがいします。
Re: rockdisknextをマウントする
yo 
2013/12/16(Mon) 21:06 
No.3750
bakanmo さん
何故複数のエラーメッセージが出るのか分かりませんが、
Device or resource busy
はnasが他のユーザに使われている
No such device or address
はnasが存在しない(共用ファイルとして認識されていない)という意味です。
多分、rockdisknextのnasとしての認識が上手くいっていないのだと思います。
Windows(or Mac)からは認識されていますか。
何故複数のエラーメッセージが出るのか分かりませんが、
Device or resource busy
はnasが他のユーザに使われている
No such device or address
はnasが存在しない(共用ファイルとして認識されていない)という意味です。
多分、rockdisknextのnasとしての認識が上手くいっていないのだと思います。
Windows(or Mac)からは認識されていますか。
yo 2013/12/16(Mon) 21:06 No.3750
Re: rockdisknextをマウントする
yoさん、みなさま
解決しました。
//IPアドレス/music
でなく
//IPアドレス/admin/Music
でした。
おさわがせしました。
解決しました。
//IPアドレス/music
でなく
//IPアドレス/admin/Music
でした。
おさわがせしました。
BeagleBone Black(8)
tinkerさん
新zImage試してみました。トレモロは出なくなりましたが、音は歪みが多く、悪いです(44.1KHz wav)。
依然cpu負荷は高く、変です。
top - 21:02:08 up 1:42, 1 user, load average: 1.12, 1.19, 1.16
Threads: 82 total, 1 running, 81 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 63.2 sy, 0.0 ni, 36.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 511188 total, 506348 used, 4840 free, 1492 buffers
KiB Swap: 0 total, 0 used, 0 free, 430912 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 27.1 0.0 27:19.02 irq/35-musb-hdr
447 root 20 0 4620 1256 928 R 1.6 0.2 0:02.32 top
3 root -2 0 0 0 0 S 0.6 0.0 0:25.20 ksoftirqd/0
86 root -54 0 0 0 0 S 0.6 0.0 0:36.88 irq/57-4a100000
419 root -48 0 70936 67904 13912 S 0.6 13.3 0:35.70 mpd
420 root -47 0 70936 67904 13912 S 0.6 13.3 0:48.90 mpd
278 root -54 0 0 0 0 S 0.6 0.0 0:35.55 cifsd
219 root 20 0 4776 3512 452 S 0.3 0.7 0:12.27 haveged
421 root -48 0 70936 67904 13912 S 0.3 13.3 0:28.00 mpd
「top -H」の結果です。44.1KHz wavです。
今度はirq/35-musb-hdrの%CPUだけがかなり変な値。それ以外はまあ普通の値です。havegedって見かけないのですが、何だろうか ?
%Cpu(s): 0.0 us, 63.2 sy, は前と大差なし。いずれにしても異常。
他の方とかなり違うのですが、syuさんがご指摘のようにusbドライバの負荷の差はtinkerさんのrootfsになにか秘密があるようですね。あとは、環境差ですかね。tinkerさんやsyuさんの環境ではそれなりに鳴っているようなので、僕の環境はbbbに呪われているのですかね(^^;;;。
syuさん、twlさん、僕のtopデータで共通しているのは rtカーネルのusbドライバ対応の問題ですね。3.10でも問題だったのですが、さらにレベルダウンしているという感じです。
あと、twlさんの
> tinkerさんおよび私の結果ではmpdのPRは20となっていますが、syuさん、yoさんでは-54となっています。
はsyuさんのarchで「chrt -f -p 53 `pgrep mpd`(mpd全体のrt優先度を54に設定している)」ためです。ただ、これは多分無効で、個別のプロセス毎に優先度を設定する必要があります。上記のtop画面は「top -H」で表示させていますので、/root/.mpdconfで設定されたプロセス毎の優先度(47、46、47)が表示されています。
Re: BeagleBone Black(8)
twl 2013/11/14(Thu) 23:42 No.3663
yoさん wrote:
> 個別のプロセス毎に優先度を設定する必要があります。
ああ、そういうことでしたか。ここがうまく理解できずに先日質問させていただいたのですが、確かにyoさんの示されたスクリプトを実行してみると、優先度を設定していないmpd(0.18.3)のプロセスが複数あることが分かりました。
root@arm:~# ./rtcurrent
70 70 55 -56 00:00:08 [irq/35-musb-hdr]
100 100 53 -54 00:00:01 [irq/57-4a100000]
101 101 53 -54 00:00:00 [irq/58-4a100000]
1567 1567 53 -54 00:00:02 [cifsd]
1904 1904 - 20 00:00:00 /usr/bin/mpd /etc/mpd.conf
1904 1905 - 20 00:00:00 /usr/bin/mpd /etc/mpd.conf
1904 1907 52 -53 00:00:00 /usr/bin/mpd /etc/mpd.conf
1904 1908 49 -50 00:00:00 /usr/bin/mpd /etc/mpd.conf
1904 1948 53 -54 00:00:01 /usr/bin/mpd /etc/mpd.conf
2200 2200 - 20 00:00:00 egrep irq/35|irq/57|irq/58|mpd|cifsd
この未設定のプロセスについて試しに
root@arm:~# chrt -f -p 47 1904
root@arm:~# chrt -f -p 48 1905
とやって
root@arm:~# ./rtcurrent
70 70 55 -56 00:00:19 [irq/35-musb-hdr]
100 100 53 -54 00:00:03 [irq/57-4a100000]
101 101 53 -54 00:00:01 [irq/58-4a100000]
1567 1567 53 -54 00:00:04 [cifsd]
1904 1904 47 -48 00:00:00 /usr/bin/mpd /etc/mpd.conf
1904 1905 48 -49 00:00:00 /usr/bin/mpd /etc/mpd.conf
1904 1907 52 -53 00:00:00 /usr/bin/mpd /etc/mpd.conf
1904 1908 49 -50 00:00:01 /usr/bin/mpd /etc/mpd.conf
1904 1948 53 -54 00:00:02 /usr/bin/mpd /etc/mpd.conf
2205 2205 - 20 00:00:00 egrep irq/35|irq/57|irq/58|mpd|cifsd
となり、優先度の設定が行われたことが分かりました。あくまでも暫定的な設定であり、適正なものかどうかは分かりませんが、tinkerさんのzImageでのDSD128の再生が幾分改善しました。といっても、まだかなりきびしいですが。
> 個別のプロセス毎に優先度を設定する必要があります。
ああ、そういうことでしたか。ここがうまく理解できずに先日質問させていただいたのですが、確かにyoさんの示されたスクリプトを実行してみると、優先度を設定していないmpd(0.18.3)のプロセスが複数あることが分かりました。
root@arm:~# ./rtcurrent
70 70 55 -56 00:00:08 [irq/35-musb-hdr]
100 100 53 -54 00:00:01 [irq/57-4a100000]
101 101 53 -54 00:00:00 [irq/58-4a100000]
1567 1567 53 -54 00:00:02 [cifsd]
1904 1904 - 20 00:00:00 /usr/bin/mpd /etc/mpd.conf
1904 1905 - 20 00:00:00 /usr/bin/mpd /etc/mpd.conf
1904 1907 52 -53 00:00:00 /usr/bin/mpd /etc/mpd.conf
1904 1908 49 -50 00:00:00 /usr/bin/mpd /etc/mpd.conf
1904 1948 53 -54 00:00:01 /usr/bin/mpd /etc/mpd.conf
2200 2200 - 20 00:00:00 egrep irq/35|irq/57|irq/58|mpd|cifsd
この未設定のプロセスについて試しに
root@arm:~# chrt -f -p 47 1904
root@arm:~# chrt -f -p 48 1905
とやって
root@arm:~# ./rtcurrent
70 70 55 -56 00:00:19 [irq/35-musb-hdr]
100 100 53 -54 00:00:03 [irq/57-4a100000]
101 101 53 -54 00:00:01 [irq/58-4a100000]
1567 1567 53 -54 00:00:04 [cifsd]
1904 1904 47 -48 00:00:00 /usr/bin/mpd /etc/mpd.conf
1904 1905 48 -49 00:00:00 /usr/bin/mpd /etc/mpd.conf
1904 1907 52 -53 00:00:00 /usr/bin/mpd /etc/mpd.conf
1904 1908 49 -50 00:00:01 /usr/bin/mpd /etc/mpd.conf
1904 1948 53 -54 00:00:02 /usr/bin/mpd /etc/mpd.conf
2205 2205 - 20 00:00:00 egrep irq/35|irq/57|irq/58|mpd|cifsd
となり、優先度の設定が行われたことが分かりました。あくまでも暫定的な設定であり、適正なものかどうかは分かりませんが、tinkerさんのzImageでのDSD128の再生が幾分改善しました。といっても、まだかなりきびしいですが。
twl 2013/11/14(Thu) 23:42 No.3663
Re: BeagleBone Black(8)
tinker 2013/11/15(Fri) 20:51 No.3665
yoさん
>新zImage試してみました。トレモロは出なくなりましたが、音は歪みが多く、悪いです(44.1KHz wav)。
依然cpu負荷は高く、変です。
今回も手強そうですね。ただ、あまり変更できる所がないんですよね。
変更できそうなところは、以下くらいです。
・BasicRT
・USBをDisable DMA (always use PIO)に
BBBの話ではないですが、3.12は3.10よりも高音の歪が少なく感じます。wandboardは3.10であまり良くなかったんですが、3.12になって、とても良くなりました。
ただしrtopを当てたmpdで、たまに音切れするのは、まだ治っていませんが・・・
twlさん
zimage試してみました。BBBはnonRTでも綺麗に鳴りますよね。
Preemptible Kernel (Low-Latency Desktop)にしてみると、音も少し変わるかもしれないですね。
ソースは同じだと思いますが、Nelsonさんのページのとおり./build_kernel.shでbuildするとgcc4.8が使われますよね。
twlさんのzImageは4.7でbuildされているようで、個人的には安心しました。
というのも、4.8のせいかどうか分からないのですが、4.8でbuildしたものを使うと、いろいろ不思議なことがおこります。
（apt-get upgradeが正常終了しないとか、mpdのautogen.shが失敗するとか）
>新zImage試してみました。トレモロは出なくなりましたが、音は歪みが多く、悪いです(44.1KHz wav)。
依然cpu負荷は高く、変です。
今回も手強そうですね。ただ、あまり変更できる所がないんですよね。
変更できそうなところは、以下くらいです。
・BasicRT
・USBをDisable DMA (always use PIO)に
BBBの話ではないですが、3.12は3.10よりも高音の歪が少なく感じます。wandboardは3.10であまり良くなかったんですが、3.12になって、とても良くなりました。
ただしrtopを当てたmpdで、たまに音切れするのは、まだ治っていませんが・・・
twlさん
zimage試してみました。BBBはnonRTでも綺麗に鳴りますよね。
Preemptible Kernel (Low-Latency Desktop)にしてみると、音も少し変わるかもしれないですね。
ソースは同じだと思いますが、Nelsonさんのページのとおり./build_kernel.shでbuildするとgcc4.8が使われますよね。
twlさんのzImageは4.7でbuildされているようで、個人的には安心しました。
というのも、4.8のせいかどうか分からないのですが、4.8でbuildしたものを使うと、いろいろ不思議なことがおこります。
（apt-get upgradeが正常終了しないとか、mpdのautogen.shが失敗するとか）
tinker 2013/11/15(Fri) 20:51 No.3665
Re: BeagleBone Black(8)
twl 2013/11/15(Fri) 22:53 No.3666
tinkerさん wrote:
> zimage試してみました。BBBはnonRTでも綺麗に鳴りますよね。
ありがとうございます。
> Preemptible Kernel (Low-Latency Desktop)にしてみると、音も少し変わるかもしれないです
> ね。
あれ、一応最低限のpreemptiveに設定したつもりですが (^^;、unameやconfig.gzでご確認下さい。
> ソースは同じだと思いますが、Nelsonさんのページのとおり./build_kernel.shでbuildすると
> gcc4.8が使われますよね。
> twlさんのzImageは4.7でbuildされているようで、個人的には安心しました。
ああ、このgcc4.8は苦手です。たしかgithub.com/RobertCNelson/linux-dev.gitで./build_kernel.shが勝手に引っ張って来るやつですね。
最初は黙認していたのですが、3.12ではビルドできても起動しないカーネルを作ってくれるので嫌になり、最近はgithub.com/beagleboard/kernelからの./patch.shでダウンロードしたソースに対し、私のMacBook (early2008) のParallels Desktopで動くUbuntu13.04上でお察しのごとくarm-linux-gnueabihf-gcc-4.7を使ってクロスコンパイルしています。
ReadMeに従い、make ARCH=arm LOADADDR=0x80008000 uImage dtbs で作ったものが私の3.12-nonRTのカーネルです。mpdのコンパイルなどはBBB上で直接行っていますが、このgccは4.6でした。
なお、このスレッドには関係ないことなので恐縮ですが、BBBには5V/3Aのリニア電源を用いています。流せる電流に余裕があるためUSBハブが使用可能、USB DDCやUSB化した複数のmicroSDを同時接続でき、MacBook/Ubuntuでクロスコンパイルしたファイルのやりとりなどで重宝しています。
> zimage試してみました。BBBはnonRTでも綺麗に鳴りますよね。
ありがとうございます。
> Preemptible Kernel (Low-Latency Desktop)にしてみると、音も少し変わるかもしれないです
> ね。
あれ、一応最低限のpreemptiveに設定したつもりですが (^^;、unameやconfig.gzでご確認下さい。
> ソースは同じだと思いますが、Nelsonさんのページのとおり./build_kernel.shでbuildすると
> gcc4.8が使われますよね。
> twlさんのzImageは4.7でbuildされているようで、個人的には安心しました。
ああ、このgcc4.8は苦手です。たしかgithub.com/RobertCNelson/linux-dev.gitで./build_kernel.shが勝手に引っ張って来るやつですね。
最初は黙認していたのですが、3.12ではビルドできても起動しないカーネルを作ってくれるので嫌になり、最近はgithub.com/beagleboard/kernelからの./patch.shでダウンロードしたソースに対し、私のMacBook (early2008) のParallels Desktopで動くUbuntu13.04上でお察しのごとくarm-linux-gnueabihf-gcc-4.7を使ってクロスコンパイルしています。
ReadMeに従い、make ARCH=arm LOADADDR=0x80008000 uImage dtbs で作ったものが私の3.12-nonRTのカーネルです。mpdのコンパイルなどはBBB上で直接行っていますが、このgccは4.6でした。
なお、このスレッドには関係ないことなので恐縮ですが、BBBには5V/3Aのリニア電源を用いています。流せる電流に余裕があるためUSBハブが使用可能、USB DDCやUSB化した複数のmicroSDを同時接続でき、MacBook/Ubuntuでクロスコンパイルしたファイルのやりとりなどで重宝しています。
twl 2013/11/15(Fri) 22:53 No.3666
Re: BeagleBone Black(8)
tinker 2013/11/16(Sat) 16:41 No.3667
やれることは、やっておこうということで。
syuさんの0731から作成したものをUPしておきます。
DSDはいつもどおり未検証です。
https://drive.google.com/file/d/0BxnbJHx0_xurZEIzaVl1VXI1VFU/edit?usp=sharing" target="_blank">https://drive.google.com/file/d/0BxnbJHx0_xurZEIzaVl1VXI1VFU/edit?usp=sharing
修正点
oldconfigで反映されないものの修正等
・CMA
・USB phy
・USB DMA
・CAPE削除
・M2Tech hiFace USB-SPDIF driver追加（モジュール）
syuさんの0731から作成したものをUPしておきます。
DSDはいつもどおり未検証です。
https://drive.google.com/file/d/0BxnbJHx0_xurZEIzaVl1VXI1VFU/edit?usp=sharing" target="_blank">https://drive.google.com/file/d/0BxnbJHx0_xurZEIzaVl1VXI1VFU/edit?usp=sharing
修正点
oldconfigで反映されないものの修正等
・CMA
・USB phy
・USB DMA
・CAPE削除
・M2Tech hiFace USB-SPDIF driver追加（モジュール）
tinker 2013/11/16(Sat) 16:41 No.3667
Re: BeagleBone Black(8)
syu 2013/11/17(Sun) 23:23 No.3669
tinkerさん
新版公開深謝。
3120rtのdtbsはそのままでmoduleとzImageを入れ替えて試してみました。rootfsはarch最新版です。
[root@sd-arch ~]# uname -a
Linux sd-arch 3.12.0-rt1_0722kai-patched-00067-g01aff5a-dirty #1 SMP PREEMPT RT Sat Nov 16 16:20:07 JST 2013 armv7l GNU/Linux
[root@sd-arch ~]# mpd -V
mpd (MPD: Music Player Daemon) 0.17.6-DSD
dsdの検証ですが、dsd64は、クセものの23407 Scarlatti - Sonata in C major, K. 420 - Allegroでもすんなり再生できます。dsd128も、この版では、２Lのtest benchのサンプルでですが、ノイズも中断もなく良好に再生できています。
pcmで24/176.4まで、もちろん問題無し。
実はait-labのDACを借用して試聴中ですが、素晴らしい再生能力に聴覚の判定基準が大幅にドリフトしてしまってます。記憶頼りではbbbの音質判定が困難に。しばし聴き比べてみます。
新版公開深謝。
3120rtのdtbsはそのままでmoduleとzImageを入れ替えて試してみました。rootfsはarch最新版です。
[root@sd-arch ~]# uname -a
Linux sd-arch 3.12.0-rt1_0722kai-patched-00067-g01aff5a-dirty #1 SMP PREEMPT RT Sat Nov 16 16:20:07 JST 2013 armv7l GNU/Linux
[root@sd-arch ~]# mpd -V
mpd (MPD: Music Player Daemon) 0.17.6-DSD
dsdの検証ですが、dsd64は、クセものの23407 Scarlatti - Sonata in C major, K. 420 - Allegroでもすんなり再生できます。dsd128も、この版では、２Lのtest benchのサンプルでですが、ノイズも中断もなく良好に再生できています。
pcmで24/176.4まで、もちろん問題無し。
実はait-labのDACを借用して試聴中ですが、素晴らしい再生能力に聴覚の判定基準が大幅にドリフトしてしまってます。記憶頼りではbbbの音質判定が困難に。しばし聴き比べてみます。
syu 2013/11/17(Sun) 23:23 No.3669
Re: BeagleBone Black(8)
tinker 2013/11/18(Mon) 19:27 No.3671
twlさん
>gcc4.8は苦手です
何故なのか説明しろって言われても出来ないですが、なんかおかしいですよね。
syuさん
>ノイズも中断もなく良好に再生できています
とりあえず、鳴るようで良かったです。
rt2が出ていたので、syuさんのconfigでbuildしました。以下のurlにUPしました。
次は、公式ソースでboot出来るようになった時に。
https://drive.google.com/file/d/0BxnbJHx0_xurMlJVczRNX2p4MDA/edit?usp=sharing" target="_blank">https://drive.google.com/file/d/0BxnbJHx0_xurMlJVczRNX2p4MDA/edit?usp=sharing
>gcc4.8は苦手です
何故なのか説明しろって言われても出来ないですが、なんかおかしいですよね。
syuさん
>ノイズも中断もなく良好に再生できています
とりあえず、鳴るようで良かったです。
rt2が出ていたので、syuさんのconfigでbuildしました。以下のurlにUPしました。
次は、公式ソースでboot出来るようになった時に。
https://drive.google.com/file/d/0BxnbJHx0_xurMlJVczRNX2p4MDA/edit?usp=sharing" target="_blank">https://drive.google.com/file/d/0BxnbJHx0_xurMlJVczRNX2p4MDA/edit?usp=sharing
tinker 2013/11/18(Mon) 19:27 No.3671
Re: BeagleBone Black(8)
syu 2013/11/19(Tue) 19:39 No.3673
tinkerさん、いつもありがとうございます。
まずお詫び。
前回、dsd128が問題なく再生できると書きましたが、実は再生できたのは新しいuda2の方で、uda3ではありませんでした。uda3でのdsd128は31200rt2-131118でも、ノイズだけになります。
bbb(arch) => uda2 =spdif=> ait-dacの条件で、0731rtnと31200rt2を比較してみましたが、31200rt2の方が0731rtnよりも高域の分解能が高く、不自然な艶や響きが少なくなります。
私は31200rt2+mpd0176dsd-rtoptが、現在のところ最も音がよいと思います。
0731rtnのdsd128は、この環境では数分に1回ほど音が消え（プログレスバーは進行)、やや不安定でした。
load averageやcpu負荷は、31200rt2で極めて高い値を示しますが、音とは無相関な印象です。
Linux sd-arch 3.12.0-rt2_131118 #2 SMP PREEMPT RT Mon Nov 18 19:06:59 JST 2013 armv7l GNU/Linux
dsd128演奏中
top - 10:52:34 up 8 min, 1 user, load average: 2.34, 1.45, 0.66
Tasks: 72 total, 1 running, 71 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 67.3 sy, 0.0 ni, 32.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 512940 total, 508496 used, 4444 free, 1716 buffers
KiB Swap: 0 total, 0 used, 0 free, 443120 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 32.4 0.0 2:16.27 irq/35-musb+
235 root -54 0 61672 58916 14424 S 12.8 11.5 0:53.10 mpd
81 root -54 0 0 0 0 S 5.8 0.0 0:19.90 irq/57-4a10+
256 root -54 0 0 0 0 S 5.5 0.0 0:24.79 cifsd
数時間継続後は、なぜか負荷が分散され、合計でも減ります。
dsd128演奏中
top - 01:56:12 up 2:25, 2 users, load average: 2.86, 1.75, 0.80
Tasks: 74 total, 1 running, 73 sleeping, 0 stopped, 0 zombie
%Cpu(s): 11.7 us, 30.3 sy, 0.0 ni, 47.6 id, 0.0 wa, 0.0 hi, 10.4 si, 0.0 st
KiB Mem: 512940 total, 508336 used, 4604 free, 2264 buffers
KiB Swap: 0 total, 0 used, 0 free, 440356 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 31.8 0.0 2:21.25 irq/35-musb+
235 root -54 0 61792 58936 14424 S 13.1 11.5 0:43.06 mpd
256 root -54 0 0 0 0 S 5.9 0.0 0:19.11 cifsd
81 root -54 0 0 0 0 S 5.6 0.0 0:17.03 irq/57-4a10+
>次は、公式ソースでboot出来るようになった時
現在の31200rt2でかなり満足ですが、次にも期待しています。
まずお詫び。
前回、dsd128が問題なく再生できると書きましたが、実は再生できたのは新しいuda2の方で、uda3ではありませんでした。uda3でのdsd128は31200rt2-131118でも、ノイズだけになります。
bbb(arch) => uda2 =spdif=> ait-dacの条件で、0731rtnと31200rt2を比較してみましたが、31200rt2の方が0731rtnよりも高域の分解能が高く、不自然な艶や響きが少なくなります。
私は31200rt2+mpd0176dsd-rtoptが、現在のところ最も音がよいと思います。
0731rtnのdsd128は、この環境では数分に1回ほど音が消え（プログレスバーは進行)、やや不安定でした。
load averageやcpu負荷は、31200rt2で極めて高い値を示しますが、音とは無相関な印象です。
Linux sd-arch 3.12.0-rt2_131118 #2 SMP PREEMPT RT Mon Nov 18 19:06:59 JST 2013 armv7l GNU/Linux
dsd128演奏中
top - 10:52:34 up 8 min, 1 user, load average: 2.34, 1.45, 0.66
Tasks: 72 total, 1 running, 71 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 67.3 sy, 0.0 ni, 32.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 512940 total, 508496 used, 4444 free, 1716 buffers
KiB Swap: 0 total, 0 used, 0 free, 443120 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 32.4 0.0 2:16.27 irq/35-musb+
235 root -54 0 61672 58916 14424 S 12.8 11.5 0:53.10 mpd
81 root -54 0 0 0 0 S 5.8 0.0 0:19.90 irq/57-4a10+
256 root -54 0 0 0 0 S 5.5 0.0 0:24.79 cifsd
数時間継続後は、なぜか負荷が分散され、合計でも減ります。
dsd128演奏中
top - 01:56:12 up 2:25, 2 users, load average: 2.86, 1.75, 0.80
Tasks: 74 total, 1 running, 73 sleeping, 0 stopped, 0 zombie
%Cpu(s): 11.7 us, 30.3 sy, 0.0 ni, 47.6 id, 0.0 wa, 0.0 hi, 10.4 si, 0.0 st
KiB Mem: 512940 total, 508336 used, 4604 free, 2264 buffers
KiB Swap: 0 total, 0 used, 0 free, 440356 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 31.8 0.0 2:21.25 irq/35-musb+
235 root -54 0 61792 58936 14424 S 13.1 11.5 0:43.06 mpd
256 root -54 0 0 0 0 S 5.9 0.0 0:19.11 cifsd
81 root -54 0 0 0 0 S 5.6 0.0 0:17.03 irq/57-4a10+
>次は、公式ソースでboot出来るようになった時
現在の31200rt2でかなり満足ですが、次にも期待しています。
syu 2013/11/19(Tue) 19:39 No.3673
Re: BeagleBone Black(8)
m 2013/11/19(Tue) 22:35 No.3674
syu さん
ご無沙汰しております。
>前回、dsd128が問題なく再生できると書きましたが、実は再生できたのは新しいuda2の方で、uda3ではありませんでした。uda3でのdsd128は31200rt2-131118でも、ノイズだけになります。
ここ、教えてください。
「新しいuda2」＝「⑥USB DUAL AUDIO基板 Version2 (通称UDA2再生専用基板)」
「uda3」＝「④USB DUAL AUDIO基板 (通称UDA(DoP版)」
という理解で良いですか？
syuさん環境 0731rt でDSD再生問題ない、というのはもしかして「新しいuda2」のみ、だったりしますか？
ご無沙汰しております。
>前回、dsd128が問題なく再生できると書きましたが、実は再生できたのは新しいuda2の方で、uda3ではありませんでした。uda3でのdsd128は31200rt2-131118でも、ノイズだけになります。
ここ、教えてください。
「新しいuda2」＝「⑥USB DUAL AUDIO基板 Version2 (通称UDA2再生専用基板)」
「uda3」＝「④USB DUAL AUDIO基板 (通称UDA(DoP版)」
という理解で良いですか？
syuさん環境 0731rt でDSD再生問題ない、というのはもしかして「新しいuda2」のみ、だったりしますか？
m 2013/11/19(Tue) 22:35 No.3674
Re: BeagleBone Black(8)
syu 2013/11/20(Wed) 13:39 No.3675
mさん
>syuさん環境 0731rt でDSD再生問題ない、というのはもしかして「新しいuda2」のみ、だったりしますか？
0731rtと0731rtn(usbパッチ適用)は、uda3(UDA(DoP版))でもuda2(UDA2再生専用基板)でも、dsd64の再生に問題はありませんでした。
uda2はdsd/pcm(88.2kHz)変換spdif=>dac、uda3はuda3=>sdif3基板dsd64=>dacとdsd/pcm(88.2kHz)変換spdif=>dacの両方で確認。
31200rtシリーズとuda2とdsd128の組み合わせで、例の音消え現象が発生しました。必発ではなく、偶発的です。
31200rtシリーズとuda3とdsd128の組み合わせでは、ノイズで音楽は聴けません。
どちらもI2S/dsd入力ではなく、dsd/pcm変換spdif経由です。
以下はその通りです。
>「新しいuda2」＝「⑥USB DUAL AUDIO基板 Version2 (通称UDA2再生専用基板)」
>「uda3」＝「④USB DUAL AUDIO基板 (通称UDA(DoP版)」
31200rt2は聴き込むほどに良いですよ。
何度も連発すると信頼度を損ねますが、過去最高です。
>syuさん環境 0731rt でDSD再生問題ない、というのはもしかして「新しいuda2」のみ、だったりしますか？
0731rtと0731rtn(usbパッチ適用)は、uda3(UDA(DoP版))でもuda2(UDA2再生専用基板)でも、dsd64の再生に問題はありませんでした。
uda2はdsd/pcm(88.2kHz)変換spdif=>dac、uda3はuda3=>sdif3基板dsd64=>dacとdsd/pcm(88.2kHz)変換spdif=>dacの両方で確認。
31200rtシリーズとuda2とdsd128の組み合わせで、例の音消え現象が発生しました。必発ではなく、偶発的です。
31200rtシリーズとuda3とdsd128の組み合わせでは、ノイズで音楽は聴けません。
どちらもI2S/dsd入力ではなく、dsd/pcm変換spdif経由です。
以下はその通りです。
>「新しいuda2」＝「⑥USB DUAL AUDIO基板 Version2 (通称UDA2再生専用基板)」
>「uda3」＝「④USB DUAL AUDIO基板 (通称UDA(DoP版)」
31200rt2は聴き込むほどに良いですよ。
何度も連発すると信頼度を損ねますが、過去最高です。
syu 2013/11/20(Wed) 13:39 No.3675
Re: BeagleBone Black(8)
syu 2013/11/20(Wed) 14:55 No.3676
rootfsをdebian(bone20)とarch最新版で差し替えて、31200rt2/mpd0176dsd-rtoptでの比較をしてみました。
どちらも良いですが、より精緻に感じるのはarchですね。高域の歪みがやや少なくなる印象です。あくまで私の環境での比較です。いよいよ返却するait-dacを使用しました。古いdCSは、やはり古かった(^^;;
combo384なんてのも話題のようですが、どなたかお試しの方、使用感をお聞かせ下さい。
どちらも良いですが、より精緻に感じるのはarchですね。高域の歪みがやや少なくなる印象です。あくまで私の環境での比較です。いよいよ返却するait-dacを使用しました。古いdCSは、やはり古かった(^^;;
combo384なんてのも話題のようですが、どなたかお試しの方、使用感をお聞かせ下さい。
syu 2013/11/20(Wed) 14:55 No.3676
Re: BeagleBone Black(8)
twl 2013/11/20(Wed) 21:54 No.3677
> combo384なんてのも話題のようですが、どなたかお試しの方、使用感を
> お聞かせ下さい。
AmaneroのI2S、DSDのの両者に対応可能なCombo384のことですね。昨年から都合３個購入、そのうち二つをCuBoxおよびBBBで個別に使用しています。
I2S、DSDの自動切り替え可能なTwisted PearのBuffalo III Dac (ES9018) に接続、CuBox側とBBB側のCombo384の切り替えには同じTwisted PearのOTTO-IIというディジタル入力のスイッチを使用、ビルドしたカーネルのCuBoxとBBB間での音質比較を簡易に行えるメリットがあります。
ところで、先日Tinkerさんが新たにアップロードされたbbb-12-00-syu0731.tar.gzを解凍してBBBで試させていただきました。Debian, ArchともにPCM再生については問題ありませんでしたが、私の環境ではDSD64, DSD128の再生には前回同様かなりのノイズが混じり、試聴が困難でした。
既述したとおり自前のnon-RTの3.12カーネルではDSD再生については私の環境ではまったく問題がないので、この違いについてはrootfsの違いとしかいいようがないようですね。勿論使用したmpdのバージョンあるいはチューニングの違いもあるかもしれませんが。
ただし経験的には、DSD、特にDSD128に関しては、BBBの環境でのrtカーネルによるnoiseless再生が本当に可能な状況なのかどうか、大変に疑問を持っています。
twl
> お聞かせ下さい。
AmaneroのI2S、DSDのの両者に対応可能なCombo384のことですね。昨年から都合３個購入、そのうち二つをCuBoxおよびBBBで個別に使用しています。
I2S、DSDの自動切り替え可能なTwisted PearのBuffalo III Dac (ES9018) に接続、CuBox側とBBB側のCombo384の切り替えには同じTwisted PearのOTTO-IIというディジタル入力のスイッチを使用、ビルドしたカーネルのCuBoxとBBB間での音質比較を簡易に行えるメリットがあります。
ところで、先日Tinkerさんが新たにアップロードされたbbb-12-00-syu0731.tar.gzを解凍してBBBで試させていただきました。Debian, ArchともにPCM再生については問題ありませんでしたが、私の環境ではDSD64, DSD128の再生には前回同様かなりのノイズが混じり、試聴が困難でした。
既述したとおり自前のnon-RTの3.12カーネルではDSD再生については私の環境ではまったく問題がないので、この違いについてはrootfsの違いとしかいいようがないようですね。勿論使用したmpdのバージョンあるいはチューニングの違いもあるかもしれませんが。
ただし経験的には、DSD、特にDSD128に関しては、BBBの環境でのrtカーネルによるnoiseless再生が本当に可能な状況なのかどうか、大変に疑問を持っています。
twl
twl 2013/11/20(Wed) 21:54 No.3677
Re: BeagleBone Black(8)
tinker 2013/11/20(Wed) 21:59 No.3678
syuさん
>より精緻に感じるのはarchですね
確かにarchのほうが良いですよね。分かっていても時々面倒くさいんで、Debianで聞いてます^^;
組み合わせを変えてimageを作ってみました。時間のある時で結構ですので、DSDが再生できるか検証をお願いできないでしょうか。
https://drive.google.com/file/d/0BxnbJHx0_xurczdKcXRmWW1DcHM/edit?usp=sharing" target="_blank">https://drive.google.com/file/d/0BxnbJHx0_xurczdKcXRmWW1DcHM/edit?usp=sharing
組み合わせは、以下のとおりです。
[Preemption Model][USB mode]
zImage-FP；[Full RT][PIO]
zImage-BD；[Basic RT][DMA]
zImage-BP；[Basic RT][PIO]
先日UPしたzImageはzImage-FD[Full RT][DMA]です。
少ししか聞いていないので、違いはよく分からないですが、BDが良いような気もします。
>より精緻に感じるのはarchですね
確かにarchのほうが良いですよね。分かっていても時々面倒くさいんで、Debianで聞いてます^^;
組み合わせを変えてimageを作ってみました。時間のある時で結構ですので、DSDが再生できるか検証をお願いできないでしょうか。
https://drive.google.com/file/d/0BxnbJHx0_xurczdKcXRmWW1DcHM/edit?usp=sharing" target="_blank">https://drive.google.com/file/d/0BxnbJHx0_xurczdKcXRmWW1DcHM/edit?usp=sharing
組み合わせは、以下のとおりです。
[Preemption Model][USB mode]
zImage-FP；[Full RT][PIO]
zImage-BD；[Basic RT][DMA]
zImage-BP；[Basic RT][PIO]
先日UPしたzImageはzImage-FD[Full RT][DMA]です。
少ししか聞いていないので、違いはよく分からないですが、BDが良いような気もします。
tinker 2013/11/20(Wed) 21:59 No.3678
Re: BeagleBone Black(8)
tinker 2013/11/20(Wed) 22:21 No.3679
twlさん
>BBBの環境でのrtカーネルによるnoiseless再生が本当に可能な状況なのかどうか
3.8-rtの時もnoneRTならDSDの再生も大丈夫と、yoさんも言われていましたね。
lightMPD（No.3634記）とういものが、DSDの再生も可能らしいですよ。
>BBBの環境でのrtカーネルによるnoiseless再生が本当に可能な状況なのかどうか
3.8-rtの時もnoneRTならDSDの再生も大丈夫と、yoさんも言われていましたね。
lightMPD（No.3634記）とういものが、DSDの再生も可能らしいですよ。
tinker 2013/11/20(Wed) 22:21 No.3679
Re: BeagleBone Black(8)
m 2013/11/20(Wed) 23:51 No.3680
syuさん
いろいろ情報ありがとうございます。UDA基板の違いではないのですね。
syuさんは何れも S/PDIF を使われているようで、私の環境（uda3=>dac I2S入力）との違いが気になります。
ait-dac 良いですよね、試聴記を楽しみにしています。
USB や内部配線やらで色々実験出来る（好みの音を作れる）のも楽しいところです。
いろいろ情報ありがとうございます。UDA基板の違いではないのですね。
syuさんは何れも S/PDIF を使われているようで、私の環境（uda3=>dac I2S入力）との違いが気になります。
ait-dac 良いですよね、試聴記を楽しみにしています。
USB や内部配線やらで色々実験出来る（好みの音を作れる）のも楽しいところです。
m 2013/11/20(Wed) 23:51 No.3680
Re: BeagleBone Black(8)
syu 2013/11/21(Thu) 20:08 No.3682
mさん
>何れも S/PDIF を使
uda3は特注で、ソフトが一部変更されています。以下のリンクと基本は同じですがudaはDoP版の改変です。
http://fpga.cool.coocan.jp/wordpress/?p=204" target="_blank">http://fpga.cool.coocan.jp/wordpress/?p=204
http://fpga.cool.coocan.jp/wordpress/?p=205" target="_blank">http://fpga.cool.coocan.jp/wordpress/?p=205
uda3からI2Sコネクタ経由でsdif3出力基板に接続し、ここからBNCケーブル3本でdCS-dacのsdif2入力にnative dsdで送っています。I2Sコネクタの信号はsdif用に変調されており、本来のI2S信号ではありません。sdif3からpcmは出力されず、dsd専用です。
>uda3=>dac I2S入力）との違い
uda3のコードの違いがどこまで影響しているか不明なのが問題ですね。基本は同じはずなんですが。
ait-dacキットはddcからI2S/DSDでdacに入力する仕様にしましたので、来週末辺りには、mさんに近い環境でテストできそうです。ddcはuda2とcombo384の2種類になります。
>何れも S/PDIF を使
uda3は特注で、ソフトが一部変更されています。以下のリンクと基本は同じですがudaはDoP版の改変です。
http://fpga.cool.coocan.jp/wordpress/?p=204" target="_blank">http://fpga.cool.coocan.jp/wordpress/?p=204
http://fpga.cool.coocan.jp/wordpress/?p=205" target="_blank">http://fpga.cool.coocan.jp/wordpress/?p=205
uda3からI2Sコネクタ経由でsdif3出力基板に接続し、ここからBNCケーブル3本でdCS-dacのsdif2入力にnative dsdで送っています。I2Sコネクタの信号はsdif用に変調されており、本来のI2S信号ではありません。sdif3からpcmは出力されず、dsd専用です。
>uda3=>dac I2S入力）との違い
uda3のコードの違いがどこまで影響しているか不明なのが問題ですね。基本は同じはずなんですが。
ait-dacキットはddcからI2S/DSDでdacに入力する仕様にしましたので、来週末辺りには、mさんに近い環境でテストできそうです。ddcはuda2とcombo384の2種類になります。
syu 2013/11/21(Thu) 20:08 No.3682
Re: BeagleBone Black(8)
syu 2013/11/21(Thu) 20:15 No.3683
tinkerさん
とりあえず、archでテストしてみました。
zImage-FP；[Full RT][PIO]
Linux sd-arch 3.12.0-rt2_131118 #3 SMP PREEMPT RT Wed Nov 20 20:51:49 JST 2013 armv7l GNU/Linux
dsd128まで、良い音で聴けます。(dsd128はuda2のみ）
zImage-BD；[Basic RT][DMA]
Linux sd-arch 3.12.0-rt2_131118 #5 SMP PREEMPT Wed Nov 20 21:04:57 JST 2013 armv7l GNU/Linux
zImage-BP；[Basic RT][PIO]
Linux sd-arch 3.12.0-rt2_131118 #4 SMP PREEMPT Wed Nov 20 20:58:11 JST 2013 armv7l GNU/Linux
この2種は、意外にもdsd64も音が出ません。プログレスバーは進行し、topを見ても再生している様子ですが、音は出ません。
今までは、この状態で一時停止＞再生とやれば音が出ていましたが、今回はそれも無反応でした。
full rtが通るのにbasic rtでdsdがダメなのは、全く意外ですね。
とりあえず、archでテストしてみました。
zImage-FP；[Full RT][PIO]
Linux sd-arch 3.12.0-rt2_131118 #3 SMP PREEMPT RT Wed Nov 20 20:51:49 JST 2013 armv7l GNU/Linux
dsd128まで、良い音で聴けます。(dsd128はuda2のみ）
zImage-BD；[Basic RT][DMA]
Linux sd-arch 3.12.0-rt2_131118 #5 SMP PREEMPT Wed Nov 20 21:04:57 JST 2013 armv7l GNU/Linux
zImage-BP；[Basic RT][PIO]
Linux sd-arch 3.12.0-rt2_131118 #4 SMP PREEMPT Wed Nov 20 20:58:11 JST 2013 armv7l GNU/Linux
この2種は、意外にもdsd64も音が出ません。プログレスバーは進行し、topを見ても再生している様子ですが、音は出ません。
今までは、この状態で一時停止＞再生とやれば音が出ていましたが、今回はそれも無反応でした。
full rtが通るのにbasic rtでdsdがダメなのは、全く意外ですね。
syu 2013/11/21(Thu) 20:15 No.3683
Re: BeagleBone Black(8)
syu 2013/11/21(Thu) 20:28 No.3684
twlさん
いろんな情報ありがとうございます。combo384を主にご使用なんですね。私の環境ではuda3(DoP版)とuda2(再生専用版)でdsd再生に大きな差が出ますので、combo384はまた違った反応を示す可能性もありそうです。数週以内にはcombo384もテストできそうです。
いろんな情報ありがとうございます。combo384を主にご使用なんですね。私の環境ではuda3(DoP版)とuda2(再生専用版)でdsd再生に大きな差が出ますので、combo384はまた違った反応を示す可能性もありそうです。数週以内にはcombo384もテストできそうです。
syu 2013/11/21(Thu) 20:28 No.3684
Re: BeagleBone Black(8)
twl 2013/11/21(Thu) 22:02 No.3685
twlです。
> 私の環境ではuda3(DoP版)とuda2(再生専用版)でdsd再生に大きな差が出ますので、
私も今はディスコンになった初期のDoP対応UDA基板を使用しています。といっても再生が目的ではなくADC経由でのDSD録音が目的なのですが。
それでもたまにはエレアトさん自作のWindows用ソフトでDSDファイルを再生、USB接続のUDA基板上のI2S/DSD経由でBuffalo DACに流して聞いたりしています。使い勝手は最悪なソフトですが、さすがに本家、基板経由の再生音は素晴らしいです。
> 数週以内にはcombo384もテストできそうです。
最近ではES9018のDACにCombo384とアイソレーターを組み込んだものを紹介しているガレージメーカーさんもあるので、このような環境だとBBBのRTカーネルの意義も変わるかもしれませんね。いずれにしても今後のsyuさんのご報告を楽しみにしております。
> 私の環境ではuda3(DoP版)とuda2(再生専用版)でdsd再生に大きな差が出ますので、
私も今はディスコンになった初期のDoP対応UDA基板を使用しています。といっても再生が目的ではなくADC経由でのDSD録音が目的なのですが。
それでもたまにはエレアトさん自作のWindows用ソフトでDSDファイルを再生、USB接続のUDA基板上のI2S/DSD経由でBuffalo DACに流して聞いたりしています。使い勝手は最悪なソフトですが、さすがに本家、基板経由の再生音は素晴らしいです。
> 数週以内にはcombo384もテストできそうです。
最近ではES9018のDACにCombo384とアイソレーターを組み込んだものを紹介しているガレージメーカーさんもあるので、このような環境だとBBBのRTカーネルの意義も変わるかもしれませんね。いずれにしても今後のsyuさんのご報告を楽しみにしております。
twl 2013/11/21(Thu) 22:02 No.3685
Re: BeagleBone Black(8)
m 2013/11/21(Thu) 23:55 No.3687
syuさん
詳細なご説明ありがとうございます。
DSD再生stopの状況（BBBは送ったけれど、DACには届いていない）からすると
どうも、両者の間にある DDC 周りが怪しいと思っています。
（CuBoxはOKなので、BBBの動作マージン？も足りないのでしょうか）
ait-dac お買い上げでほぼ環境も揃うということでご報告を楽しみにしております。
詳細なご説明ありがとうございます。
DSD再生stopの状況（BBBは送ったけれど、DACには届いていない）からすると
どうも、両者の間にある DDC 周りが怪しいと思っています。
（CuBoxはOKなので、BBBの動作マージン？も足りないのでしょうか）
ait-dac お買い上げでほぼ環境も揃うということでご報告を楽しみにしております。
m 2013/11/21(Thu) 23:55 No.3687
Re: BeagleBone Black(8)
syu 2013/11/22(Fri) 20:43 No.3690
tinkerさん
zImage-BD；[Basic RT][DMA]
Linux sd-arch 3.12.0-rt2_131118 #5 SMP PREEMPT Wed Nov 20 21:04:57 JST 2013 armv7l GNU/Linux
zImage-BP；[Basic RT][PIO]
Linux sd-arch 3.12.0-rt2_131118 #4 SMP PREEMPT Wed Nov 20 20:58:11 JST 2013 armv7l GNU/Linux
basic rtの2種は、dsdだけでなく、24/96と24/176.4でも問題が発生しました。
24/176.4で顕著ですが、フッフッフッ・・と言う感じで、音の瞬断が連続的に発生します。波高のあるノイズではなく瞬断なので無音部や音量レベルの低い部分では判別困難になります。
瞬断の発生間隔はfsに比例する印象で、24/96では24/176.4の倍くらいの発生間隔になり、そのつもりで聴いていると16/44.1でも聴き取れるような気がしますが、顕著ではありません。
yoさんがご報告の初期zImageでのトレモロ現象と同じかもしれません。
※違憲状態選で「イッポンをトレモロす」と連呼された国家秘密とは無関係です。保全法が適用される心配は多分ありません(^^;;;
twlさん
ご指摘のノイズは、これと同様でしょうか、それとも別の発生状態でしょうか。波高のあるノイズか、瞬断か、どちらに近いでしょう。
zImage-BD；[Basic RT][DMA]
Linux sd-arch 3.12.0-rt2_131118 #5 SMP PREEMPT Wed Nov 20 21:04:57 JST 2013 armv7l GNU/Linux
zImage-BP；[Basic RT][PIO]
Linux sd-arch 3.12.0-rt2_131118 #4 SMP PREEMPT Wed Nov 20 20:58:11 JST 2013 armv7l GNU/Linux
basic rtの2種は、dsdだけでなく、24/96と24/176.4でも問題が発生しました。
24/176.4で顕著ですが、フッフッフッ・・と言う感じで、音の瞬断が連続的に発生します。波高のあるノイズではなく瞬断なので無音部や音量レベルの低い部分では判別困難になります。
瞬断の発生間隔はfsに比例する印象で、24/96では24/176.4の倍くらいの発生間隔になり、そのつもりで聴いていると16/44.1でも聴き取れるような気がしますが、顕著ではありません。
yoさんがご報告の初期zImageでのトレモロ現象と同じかもしれません。
※違憲状態選で「イッポンをトレモロす」と連呼された国家秘密とは無関係です。保全法が適用される心配は多分ありません(^^;;;
twlさん
ご指摘のノイズは、これと同様でしょうか、それとも別の発生状態でしょうか。波高のあるノイズか、瞬断か、どちらに近いでしょう。
syu 2013/11/22(Fri) 20:43 No.3690
Re: BeagleBone Black(8)
twl 2013/11/22(Fri) 23:54 No.3691
syuさん wrote:
> ご指摘のノイズは、これと同様でしょうか、それとも別の発生状態でしょうか。
> 波高のあるノイズか、瞬断か、どちらに近いでしょう。
tinkerさんのBD, BP, FPの各zImageをdebianで試させていただきました。
BD: Linux arm 3.12.0-rt2_131118 #5 SMP PREEMPT Wed Nov 20 21:04:57 JST 2013 armv7l GNU/Linux
BP: Linux arm 3.12.0-rt2_131118 #4 SMP PREEMPT Wed Nov 20 20:58:11 JST 2013 armv7l GNU/Linux
FP: Linux arm 3.12.0-rt2_131118 #3 SMP PREEMPT RT Wed Nov 20 20:51:49 JST 2013 armv7l GNU/Linux
PCMに関してはBDがノイズもなく安定して再生できました。当然といえば当然なのでしょうが。しかしBPとFPではブツブツと時々ノイズが混じるようになり、FPで目立つ傾向となりました。
DSD64、DSD128については、いずれのzImageでもsyuさんが指摘されるような再生音の瞬断はないのですが、絶えずプツピチ、プツピチといったような高いピッチでのノイズが再生されている主音の背景につきまといます。また主音のピッチも不安定、レコードやテープの早回しや手動で停止をかけるような音程の変化が短い間隔で連続します。なんというのか、短波のラジオ放送をチューニングしているような感じですね。
それでもchrtでmpd(0.18.3)の優先度を適当に設定すると、BPではなんとかまともな再生音に近い状態が得られますが、FPに至ってはその効果もなく、検証をすぐにやめたくなるぐらい、不安定な音の連続となります。ただし瞬断現象のような変化はありませんでした。それと、同じ現象かどうかは判断しかねますが、再生音声が微妙にトレモロ状態になることもBPで経験しました。
以上、報告申し上げます。twl
> ご指摘のノイズは、これと同様でしょうか、それとも別の発生状態でしょうか。
> 波高のあるノイズか、瞬断か、どちらに近いでしょう。
tinkerさんのBD, BP, FPの各zImageをdebianで試させていただきました。
BD: Linux arm 3.12.0-rt2_131118 #5 SMP PREEMPT Wed Nov 20 21:04:57 JST 2013 armv7l GNU/Linux
BP: Linux arm 3.12.0-rt2_131118 #4 SMP PREEMPT Wed Nov 20 20:58:11 JST 2013 armv7l GNU/Linux
FP: Linux arm 3.12.0-rt2_131118 #3 SMP PREEMPT RT Wed Nov 20 20:51:49 JST 2013 armv7l GNU/Linux
PCMに関してはBDがノイズもなく安定して再生できました。当然といえば当然なのでしょうが。しかしBPとFPではブツブツと時々ノイズが混じるようになり、FPで目立つ傾向となりました。
DSD64、DSD128については、いずれのzImageでもsyuさんが指摘されるような再生音の瞬断はないのですが、絶えずプツピチ、プツピチといったような高いピッチでのノイズが再生されている主音の背景につきまといます。また主音のピッチも不安定、レコードやテープの早回しや手動で停止をかけるような音程の変化が短い間隔で連続します。なんというのか、短波のラジオ放送をチューニングしているような感じですね。
それでもchrtでmpd(0.18.3)の優先度を適当に設定すると、BPではなんとかまともな再生音に近い状態が得られますが、FPに至ってはその効果もなく、検証をすぐにやめたくなるぐらい、不安定な音の連続となります。ただし瞬断現象のような変化はありませんでした。それと、同じ現象かどうかは判断しかねますが、再生音声が微妙にトレモロ状態になることもBPで経験しました。
以上、報告申し上げます。twl
twl 2013/11/22(Fri) 23:54 No.3691
Re: BeagleBone Black(8)
tinker 2013/11/23(Sat) 17:37 No.3695
syuさん、twlさん
検証ありがとうございます。
どこかに解決のヒントがあるのかなと思いましたが、なかなか上手くいかないですね。
検証ありがとうございます。
どこかに解決のヒントがあるのかなと思いましたが、なかなか上手くいかないですね。
tinker 2013/11/23(Sat) 17:37 No.3695
Re: BeagleBone Black(8)
syu 2013/11/23(Sat) 18:55 No.3696
twlさん、ありがとうございます。
twlさんの場合、私の環境でのノイズとは違うノイズらしいのが、BBBの不思議ですね。
私の環境ではFPとFDは良い音が出ますが、BDとBPはダメなのも不思議。twlさんの場合、BDとBPよりもFD、FPの結果が悪いけど、こちらの方が合理的だと思うんですよね。
皆様
ご覧の皆さんで、うちではFDかFPで音が出てるよって方は居られるんでしょうか。詳細なコメントいただけると有難いですが、「音が出てます」ってだけで、詳細コメントなしでも良いですから、ご報告いただけると嬉しいです。もしかして、FPとFDでまともに音が出てるのは、tinkerさんと私の環境だけなんでしょうか。
tinkerさん
私の環境では、31200rt2シリーズ（FDとFP)は抜群に良い音ですので、普遍性を獲得すべく、何とかしましょう(他力本願)(^^;;;
私の環境でも夜間は昼間より改善するなど、環境・電源ノイズが影響している印象もあるので、電源まわりのノイズフィルターを全部外し、近くの工場が操業している時間帯に試してみようかと思っています。いつになるかは保証外ですが・・。
twlさんの場合、私の環境でのノイズとは違うノイズらしいのが、BBBの不思議ですね。
私の環境ではFPとFDは良い音が出ますが、BDとBPはダメなのも不思議。twlさんの場合、BDとBPよりもFD、FPの結果が悪いけど、こちらの方が合理的だと思うんですよね。
皆様
ご覧の皆さんで、うちではFDかFPで音が出てるよって方は居られるんでしょうか。詳細なコメントいただけると有難いですが、「音が出てます」ってだけで、詳細コメントなしでも良いですから、ご報告いただけると嬉しいです。もしかして、FPとFDでまともに音が出てるのは、tinkerさんと私の環境だけなんでしょうか。
tinkerさん
私の環境では、31200rt2シリーズ（FDとFP)は抜群に良い音ですので、普遍性を獲得すべく、何とかしましょう(他力本願)(^^;;;
私の環境でも夜間は昼間より改善するなど、環境・電源ノイズが影響している印象もあるので、電源まわりのノイズフィルターを全部外し、近くの工場が操業している時間帯に試してみようかと思っています。いつになるかは保証外ですが・・。
syu 2013/11/23(Sat) 18:55 No.3696
Re: BeagleBone Black(8)
yo 2013/11/24(Sun) 17:08 No.3697
皆様
僕の環境(debian、HD-7A 192改)でのFP、BP、BDの結果ですが、残念ながら全てNGです。ノイズまじりのトレモロ音となります。192KHz wavの再生のみ確認しています。どれも同じなので、一番悪いFPのみ、topを貼り付けます。
Linux beagle 3.12.0-rt2_131118 #3 SMP PREEMPT RT Wed Nov 20 20:51:49 JST 2013 armv7l GNU/Linux
top - 05:18:57 up 1 min, 1 user, load average: 0.81, 0.34, 0.13
Tasks: 78 total, 1 running, 77 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.5 us, 45.8 sy, 0.0 ni, 44.0 id, 0.0 wa, 0.0 hi, 8.7 si, 0.0 st
KiB Mem: 512936 total, 168236 used, 344700 free, 4260 buffers
KiB Swap: 0 total, 0 used, 0 free, 85012 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 27.0 0.0 0:05.88 irq/35-musb-hdr
2422 mpd 20 0 85368 81m 22m S 9.4 16.3 0:02.96 mpd
17 root 20 0 0 0 0 S 7.2 0.0 0:01.93 kworker/0:1
81 root -55 0 0 0 0 S 6.2 0.0 0:01.65 irq/57-4a100000
82 root -51 0 0 0 0 S 3.3 0.0 0:00.91 irq/58-4a100000
zImageを3.8.13に戻すと同じ環境、同じwavファイルが問題なく美しい音で再生できます。
Linux beagle 3.8.13-rt9_0722kai-00899-gbbecbc0 #6 SMP PREEMPT Wed Jul 31 07:53:11 JST 2013 armv7l GNU/Linux
top - 05:14:18 up 3 min, 1 user, load average: 0.18, 0.24, 0.12
Tasks: 78 total, 1 running, 77 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.2 us, 14.9 sy, 0.0 ni, 78.4 id, 0.0 wa, 0.0 hi, 4.5 si, 0.0 st
KiB Mem: 513280 total, 362456 used, 150824 free, 4296 buffers
KiB Swap: 0 total, 0 used, 0 free, 280040 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 13.9 0.0 0:27.49 irq/35-musb-hdr
76 root -55 0 0 0 0 S 4.6 0.0 0:08.65 irq/57-4a100000
2297 mpd 20 0 86384 81m 22m S 4.0 16.3 0:08.53 mpd
17 root 20 0 0 0 0 S 1.3 0.0 0:02.74 kworker/0:1
77 root -51 0 0 0 0 S 0.7 0.0 0:01.27 irq/58-4a100000
比較するとFPは全体に%CPUが高い。特にirq/35-musb-hdrが異常な数値というところが特徴ですね。
archでも試しましたが、同じ結果です。rootfsは関係なさそうですね。
僕の環境(debian、HD-7A 192改)でのFP、BP、BDの結果ですが、残念ながら全てNGです。ノイズまじりのトレモロ音となります。192KHz wavの再生のみ確認しています。どれも同じなので、一番悪いFPのみ、topを貼り付けます。
Linux beagle 3.12.0-rt2_131118 #3 SMP PREEMPT RT Wed Nov 20 20:51:49 JST 2013 armv7l GNU/Linux
top - 05:18:57 up 1 min, 1 user, load average: 0.81, 0.34, 0.13
Tasks: 78 total, 1 running, 77 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.5 us, 45.8 sy, 0.0 ni, 44.0 id, 0.0 wa, 0.0 hi, 8.7 si, 0.0 st
KiB Mem: 512936 total, 168236 used, 344700 free, 4260 buffers
KiB Swap: 0 total, 0 used, 0 free, 85012 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 27.0 0.0 0:05.88 irq/35-musb-hdr
2422 mpd 20 0 85368 81m 22m S 9.4 16.3 0:02.96 mpd
17 root 20 0 0 0 0 S 7.2 0.0 0:01.93 kworker/0:1
81 root -55 0 0 0 0 S 6.2 0.0 0:01.65 irq/57-4a100000
82 root -51 0 0 0 0 S 3.3 0.0 0:00.91 irq/58-4a100000
zImageを3.8.13に戻すと同じ環境、同じwavファイルが問題なく美しい音で再生できます。
Linux beagle 3.8.13-rt9_0722kai-00899-gbbecbc0 #6 SMP PREEMPT Wed Jul 31 07:53:11 JST 2013 armv7l GNU/Linux
top - 05:14:18 up 3 min, 1 user, load average: 0.18, 0.24, 0.12
Tasks: 78 total, 1 running, 77 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.2 us, 14.9 sy, 0.0 ni, 78.4 id, 0.0 wa, 0.0 hi, 4.5 si, 0.0 st
KiB Mem: 513280 total, 362456 used, 150824 free, 4296 buffers
KiB Swap: 0 total, 0 used, 0 free, 280040 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 13.9 0.0 0:27.49 irq/35-musb-hdr
76 root -55 0 0 0 0 S 4.6 0.0 0:08.65 irq/57-4a100000
2297 mpd 20 0 86384 81m 22m S 4.0 16.3 0:08.53 mpd
17 root 20 0 0 0 0 S 1.3 0.0 0:02.74 kworker/0:1
77 root -51 0 0 0 0 S 0.7 0.0 0:01.27 irq/58-4a100000
比較するとFPは全体に%CPUが高い。特にirq/35-musb-hdrが異常な数値というところが特徴ですね。
archでも試しましたが、同じ結果です。rootfsは関係なさそうですね。
yo 2013/11/24(Sun) 17:08 No.3697
Re: BeagleBone Black(8)
twl 2013/11/24(Sun) 19:29 No.3698
twlです。
tinkerさんのお世話になっているばかりでは申し訳ないので、私も3.12-rtのkernel(RT_FULL))をビルドしてみました。以下のURLに置きましたので、皆様、お時間のある時にご検証下さい。
http://lydia.concorde.gr.jp/luke/312rt2_BBB.tar.gz" target="_blank">http://lydia.concorde.gr.jp/luke/312rt2_BBB.tar.gz
最初にgithub.com/RobertCNelson/linux-dev.gitで3.12.1のカーネルを作成、これにrt2のパッチを当てたものです。
root@arm:~# uname -a
Linux arm 3.12.1-rt2_BBB_1123_RT+ #2 SMP PREEMPT RT Sat Nov 23 22:17:34 JST 2013 armv7l GNU/Linux
Debianの環境でしか試していませんが、私の使用しているnon-RTのmpd(0.18.3)ではPCM、DSD64まではノイズなしで再生できています。DSD128では高いピッチでプチプチとノイズが混じりますが、tinkerさんのRT_FULLのzImageと比べると、私の環境では現状ではまあまあかなといった再生状態です。syuさんと私の環境では逆の結果になるようなので、syuさんのコメントが楽しみです。yoさんの再生状況は私の環境に近いようですが、よろしくお願いいたします。
＃現在rt4のパッチを当てた3.12カーネルのビルド中ですが、BBB上で作っているのでいつ終了するか、予測できません。(^^;
tinkerさんのお世話になっているばかりでは申し訳ないので、私も3.12-rtのkernel(RT_FULL))をビルドしてみました。以下のURLに置きましたので、皆様、お時間のある時にご検証下さい。
http://lydia.concorde.gr.jp/luke/312rt2_BBB.tar.gz" target="_blank">http://lydia.concorde.gr.jp/luke/312rt2_BBB.tar.gz
最初にgithub.com/RobertCNelson/linux-dev.gitで3.12.1のカーネルを作成、これにrt2のパッチを当てたものです。
root@arm:~# uname -a
Linux arm 3.12.1-rt2_BBB_1123_RT+ #2 SMP PREEMPT RT Sat Nov 23 22:17:34 JST 2013 armv7l GNU/Linux
Debianの環境でしか試していませんが、私の使用しているnon-RTのmpd(0.18.3)ではPCM、DSD64まではノイズなしで再生できています。DSD128では高いピッチでプチプチとノイズが混じりますが、tinkerさんのRT_FULLのzImageと比べると、私の環境では現状ではまあまあかなといった再生状態です。syuさんと私の環境では逆の結果になるようなので、syuさんのコメントが楽しみです。yoさんの再生状況は私の環境に近いようですが、よろしくお願いいたします。
＃現在rt4のパッチを当てた3.12カーネルのビルド中ですが、BBB上で作っているのでいつ終了するか、予測できません。(^^;
twl 2013/11/24(Sun) 19:29 No.3698
Re: BeagleBone Black(8)
syu 2013/11/25(Mon) 00:17 No.3700
ait-laboのdac、先ほど組み上げ完了し、試運転中です。ddcは慣れているuda2からI2S/DSD接続。combo384もスタックして実装しましたが、コネクタ差し替え式です。明日にでも試す予定です。
早速、31200rt2-131118(fd)で慣らし中ですが、dsd128でノイズなく再生可能です。時折ストライキをやってくれますが、一時停止>再生の操作で復活します。ストライキの頻度が高いとダメですが、様子を見てみます。
dsd64は、全く問題なく、良い音です。今のところ、ストライキも起きません。
他のイメージやtwlさんのカーネルは明日以降、楽しませていただく予定です。twlさん、カーネル公開ありがとうございました。私の力量では、まだtinkerさんやtwlさんのようなことはできませんので、当面は後追いを楽しみたいと思います。
yoさん
またもやBBBの妖怪ですかね(^^;;;
私の環境でdsd128再生中のtop -Hです。やはり負荷は高いんですが、ノイズやトレモロはでません。
top - 00:12:06 up 16 min, 1 user, load average: 1.90, 2.26, 1.49
Threads: 78 total, 1 running, 77 sleeping, 0 stopped, 0 zombie
%Cpu(s): 7.5 us, 41.2 sy, 0.0 ni, 44.3 id, 0.0 wa, 0.0 hi, 7.1 si, 0.0 st
KiB Mem: 512940 total, 508040 used, 4900 free, 1820 buffers
KiB Swap: 0 total, 0 used, 0 free, 441388 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 32.1 0.0 4:30.37 irq/35-musb+
312 root -54 0 61892 59000 14424 S 5.7 11.5 0:45.53 mpd
80 root -54 0 0 0 0 S 5.0 0.0 0:38.47 irq/57-4a10+
309 root -54 0 0 0 0 S 5.0 0.0 0:46.33 cifsd
310 root -53 0 61892 59000 14424 S 2.8 11.5 0:23.43 mpd
311 root -50 0 61892 59000 14424 S 2.8 11.5 0:26.58 mpd
476 root 20 0 5092 1284 1008 R 1.6 0.3 0:08.55 top
41 root 20 0 0 0 0 S 0.3 0.0 0:01.63 kswapd0
240 root -54 0 61892 59000 14424 S 0.3 11.5 0:04.26 mpd
dsd64再生中のtop -H
top - 00:29:09 up 33 min, 1 user, load average: 3.22, 2.43, 2.00
Threads: 77 total, 1 running, 76 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.3 us, 26.3 sy, 0.0 ni, 65.8 id, 0.0 wa, 0.0 hi, 6.6 si, 0.0 st
KiB Mem: 512940 total, 489064 used, 23876 free, 1784 buffers
KiB Swap: 0 total, 0 used, 0 free, 422796 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 30.0 0.0 9:41.72 irq/35-musb+
309 root -54 0 0 0 0 S 3.3 0.0 1:27.98 cifsd
80 root -54 0 0 0 0 S 2.6 0.0 1:13.10 irq/57-4a10+
312 root -54 0 61892 59000 14424 S 2.6 11.5 1:24.06 mpd
311 root -50 0 61892 59000 14424 S 1.6 11.5 0:49.89 mpd
480 root 20 0 5092 1280 1004 R 1.6 0.2 0:03.11 top
310 root -53 0 61892 59000 14424 S 1.3 11.5 0:42.90 mpd
81 root -51 0 0 0 0 S 0.7 0.0 0:14.37 irq/58-4a10+
3 root -2 0 0 0 0 S 0.3 0.0 0:02.43 ksoftirqd/0
240 root -54 0 61892 59000 14424 S 0.3 11.5 0:08.08 mpd
早速、31200rt2-131118(fd)で慣らし中ですが、dsd128でノイズなく再生可能です。時折ストライキをやってくれますが、一時停止>再生の操作で復活します。ストライキの頻度が高いとダメですが、様子を見てみます。
dsd64は、全く問題なく、良い音です。今のところ、ストライキも起きません。
他のイメージやtwlさんのカーネルは明日以降、楽しませていただく予定です。twlさん、カーネル公開ありがとうございました。私の力量では、まだtinkerさんやtwlさんのようなことはできませんので、当面は後追いを楽しみたいと思います。
yoさん
またもやBBBの妖怪ですかね(^^;;;
私の環境でdsd128再生中のtop -Hです。やはり負荷は高いんですが、ノイズやトレモロはでません。
top - 00:12:06 up 16 min, 1 user, load average: 1.90, 2.26, 1.49
Threads: 78 total, 1 running, 77 sleeping, 0 stopped, 0 zombie
%Cpu(s): 7.5 us, 41.2 sy, 0.0 ni, 44.3 id, 0.0 wa, 0.0 hi, 7.1 si, 0.0 st
KiB Mem: 512940 total, 508040 used, 4900 free, 1820 buffers
KiB Swap: 0 total, 0 used, 0 free, 441388 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 32.1 0.0 4:30.37 irq/35-musb+
312 root -54 0 61892 59000 14424 S 5.7 11.5 0:45.53 mpd
80 root -54 0 0 0 0 S 5.0 0.0 0:38.47 irq/57-4a10+
309 root -54 0 0 0 0 S 5.0 0.0 0:46.33 cifsd
310 root -53 0 61892 59000 14424 S 2.8 11.5 0:23.43 mpd
311 root -50 0 61892 59000 14424 S 2.8 11.5 0:26.58 mpd
476 root 20 0 5092 1284 1008 R 1.6 0.3 0:08.55 top
41 root 20 0 0 0 0 S 0.3 0.0 0:01.63 kswapd0
240 root -54 0 61892 59000 14424 S 0.3 11.5 0:04.26 mpd
dsd64再生中のtop -H
top - 00:29:09 up 33 min, 1 user, load average: 3.22, 2.43, 2.00
Threads: 77 total, 1 running, 76 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.3 us, 26.3 sy, 0.0 ni, 65.8 id, 0.0 wa, 0.0 hi, 6.6 si, 0.0 st
KiB Mem: 512940 total, 489064 used, 23876 free, 1784 buffers
KiB Swap: 0 total, 0 used, 0 free, 422796 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 30.0 0.0 9:41.72 irq/35-musb+
309 root -54 0 0 0 0 S 3.3 0.0 1:27.98 cifsd
80 root -54 0 0 0 0 S 2.6 0.0 1:13.10 irq/57-4a10+
312 root -54 0 61892 59000 14424 S 2.6 11.5 1:24.06 mpd
311 root -50 0 61892 59000 14424 S 1.6 11.5 0:49.89 mpd
480 root 20 0 5092 1280 1004 R 1.6 0.2 0:03.11 top
310 root -53 0 61892 59000 14424 S 1.3 11.5 0:42.90 mpd
81 root -51 0 0 0 0 S 0.7 0.0 0:14.37 irq/58-4a10+
3 root -2 0 0 0 0 S 0.3 0.0 0:02.43 ksoftirqd/0
240 root -54 0 61892 59000 14424 S 0.3 11.5 0:08.08 mpd
syu 2013/11/25(Mon) 00:17 No.3700
Re: BeagleBone Black(8)
syu 2013/11/26(Tue) 21:14 No.3703
twlさん、ありがとうございます。
ご公開のdtbs、zImage、moduleをarch最新版で試してみました。uda2 = I2S/DSD => ait dacです。
dsd64は音は出ますが、数分おきにストライキが起きます。一時停止>再生で復活する例のやつです。たまにボツとノイズが出ます。
dsd64再生中のtop -Hです。musbの%cpuがtinkerさんのFD/FPよりも高くなります。
top - 20:53:53 up 6 min, 1 user, load average: 2.07, 1.90, 0.89
Threads: 87 total, 1 running, 86 sleeping, 0 stopped, 0 zombie
%Cpu(s): 6.1 us, 45.5 sy, 0.0 ni, 41.8 id, 0.0 wa, 0.0 hi, 6.6 si, 0.0 st
KiB Mem: 501796 total, 333328 used, 168468 free, 6776 buffers
KiB Swap: 0 total, 0 used, 0 free, 258156 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
76 root -56 0 0 0 0 S 41.0 0.0 2:03.27 irq/35-musb+
271 root -54 0 0 0 0 S 4.7 0.0 0:12.89 cifsd
318 root -54 0 61672 58916 14424 S 3.1 11.7 0:10.06 mpd
98 root -54 0 0 0 0 S 2.5 0.0 0:08.52 irq/57-4a10+
317 root -50 0 61672 58916 14424 S 2.5 11.7 0:07.21 mpd
444 root 20 0 5092 1292 1008 R 2.5 0.3 0:00.60 top
99 root -51 0 0 0 0 S 2.2 0.0 0:06.22 irq/58-4a10+
316 root -53 0 61672 58916 14424 S 1.9 11.7 0:05.35 mpd
254 root -54 0 61672 58916 14424 S 0.9 11.7 0:02.88 mpd
dsd128はait dacの表示がfs=NO SIGとなり、再生できませんでした。GMPCではプログレスバーは動いており、top -Hの表示もそれなりな値です。
top - 21:06:03 up 6 min, 1 user, load average: 4.60, 2.45, 1.11
Threads: 87 total, 1 running, 86 sleeping, 0 stopped, 0 zombie
%Cpu(s): 8.7 us, 59.2 sy, 0.0 ni, 19.1 id, 0.0 wa, 0.0 hi, 13.0 si, 0.0 st
KiB Mem: 501796 total, 317796 used, 184000 free, 7132 buffers
KiB Swap: 0 total, 0 used, 0 free, 242124 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
76 root -56 0 0 0 0 S 40.0 0.0 2:16.60 irq/35-musb+
268 root -54 0 0 0 0 S 8.9 0.0 0:21.22 cifsd
310 root -54 0 61672 58916 14424 S 7.1 11.7 0:16.34 mpd
99 root -51 0 0 0 0 S 6.0 0.0 0:10.10 irq/58-4a10+
309 root -50 0 61672 58916 14424 S 5.4 11.7 0:13.28 mpd
98 root -54 0 0 0 0 S 3.7 0.0 0:13.17 irq/57-4a10+
308 root -53 0 61672 58916 14424 S 3.7 11.7 0:08.89 mpd
441 root 20 0 5092 1292 1008 R 2.3 0.3 0:01.51 top
254 root -54 0 61672 58916 14424 S 0.6 11.7 0:03.13 mpd
やはり環境の違いが大きいようですね。差は何でしょうね。
もしかしてBBBの個体差？
yoさんの環境でtwlさんのカーネルがどうなるかですね。他の皆様は、どうでしょう。
ご公開のdtbs、zImage、moduleをarch最新版で試してみました。uda2 = I2S/DSD => ait dacです。
dsd64は音は出ますが、数分おきにストライキが起きます。一時停止>再生で復活する例のやつです。たまにボツとノイズが出ます。
dsd64再生中のtop -Hです。musbの%cpuがtinkerさんのFD/FPよりも高くなります。
top - 20:53:53 up 6 min, 1 user, load average: 2.07, 1.90, 0.89
Threads: 87 total, 1 running, 86 sleeping, 0 stopped, 0 zombie
%Cpu(s): 6.1 us, 45.5 sy, 0.0 ni, 41.8 id, 0.0 wa, 0.0 hi, 6.6 si, 0.0 st
KiB Mem: 501796 total, 333328 used, 168468 free, 6776 buffers
KiB Swap: 0 total, 0 used, 0 free, 258156 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
76 root -56 0 0 0 0 S 41.0 0.0 2:03.27 irq/35-musb+
271 root -54 0 0 0 0 S 4.7 0.0 0:12.89 cifsd
318 root -54 0 61672 58916 14424 S 3.1 11.7 0:10.06 mpd
98 root -54 0 0 0 0 S 2.5 0.0 0:08.52 irq/57-4a10+
317 root -50 0 61672 58916 14424 S 2.5 11.7 0:07.21 mpd
444 root 20 0 5092 1292 1008 R 2.5 0.3 0:00.60 top
99 root -51 0 0 0 0 S 2.2 0.0 0:06.22 irq/58-4a10+
316 root -53 0 61672 58916 14424 S 1.9 11.7 0:05.35 mpd
254 root -54 0 61672 58916 14424 S 0.9 11.7 0:02.88 mpd
dsd128はait dacの表示がfs=NO SIGとなり、再生できませんでした。GMPCではプログレスバーは動いており、top -Hの表示もそれなりな値です。
top - 21:06:03 up 6 min, 1 user, load average: 4.60, 2.45, 1.11
Threads: 87 total, 1 running, 86 sleeping, 0 stopped, 0 zombie
%Cpu(s): 8.7 us, 59.2 sy, 0.0 ni, 19.1 id, 0.0 wa, 0.0 hi, 13.0 si, 0.0 st
KiB Mem: 501796 total, 317796 used, 184000 free, 7132 buffers
KiB Swap: 0 total, 0 used, 0 free, 242124 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
76 root -56 0 0 0 0 S 40.0 0.0 2:16.60 irq/35-musb+
268 root -54 0 0 0 0 S 8.9 0.0 0:21.22 cifsd
310 root -54 0 61672 58916 14424 S 7.1 11.7 0:16.34 mpd
99 root -51 0 0 0 0 S 6.0 0.0 0:10.10 irq/58-4a10+
309 root -50 0 61672 58916 14424 S 5.4 11.7 0:13.28 mpd
98 root -54 0 0 0 0 S 3.7 0.0 0:13.17 irq/57-4a10+
308 root -53 0 61672 58916 14424 S 3.7 11.7 0:08.89 mpd
441 root 20 0 5092 1292 1008 R 2.3 0.3 0:01.51 top
254 root -54 0 61672 58916 14424 S 0.6 11.7 0:03.13 mpd
やはり環境の違いが大きいようですね。差は何でしょうね。
もしかしてBBBの個体差？
yoさんの環境でtwlさんのカーネルがどうなるかですね。他の皆様は、どうでしょう。
syu 2013/11/26(Tue) 21:14 No.3703
Re: BeagleBone Black(8)
yo 2013/11/26(Tue) 21:24 No.3704
どうにも解せないので、bbbをaitlabo(ddcはuda3、I2S/DSD接続)につなぎ変えて試してみました。部屋を移動する必要があるので、結構大変で、さぼっていたのですよね(^^;;;。
fd、fp、bd、bp全てOKでハイレソpcm、dsd64全て問題なく再生できます(手持ちのdsd128は上手く再生できませんでしたが、これはファイルの問題のようです)。しかし、長時間の連続再生ではdsdの再生中断が発生するので、後述する方法でmpd(rtopt有)のrt優先レベルを変更して対応しました。メインで確認したrootfsはarch(syuさんの最新版)ですが、debianでも同じ結果です(debianはノイズの出ないことの確認だけ)。結局、確認できた結果はcuboxと同じ結果となりますので、原因はddcハード(おそらくusbファーム)とrtカーネル(おそらくusbドライバ)にあるようです。
syuさん
上記の環境で僕のtopですが
Linux beagle 3.12.0-rt1_0722kai-patched-00067-g01aff5a-dirty #1 SMP PREEMPT RT Sat Nov 16 16:20:07 JST 2013 armv7l GNU/Linux
top - 20:21:34 up 29 min, 2 users, load average: 1.28, 0.82, 0.64
Threads: 86 total, 2 running, 84 sleeping, 0 stopped, 0 zombie
%Cpu(s): 12.0 us, 18.7 sy, 0.0 ni, 64.0 id, 0.0 wa, 0.0 hi, 5.3 si, 0.0 st
KiB Mem: 512928 total, 508572 used, 4356 free, 2752 buffers
KiB Swap: 0 total, 0 used, 0 free, 421748 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 28.8 0.0 8:27.86 irq/35-musb-hdr
406 root -36 0 96348 92820 31084 S 3.8 18.1 0:42.43 mpd
81 root -54 0 0 0 0 S 2.9 0.0 0:59.39 irq/57-4a100000
407 root -38 0 96348 92820 31084 S 2.2 18.1 0:46.01 mpd
375 root 20 0 0 0 0 R 1.9 0.0 0:36.87 cifsd
490 root 20 0 5096 1344 1008 R 1.9 0.3 0:00.40 top
405 root -37 0 96348 92820 31084 S 1.6 18.1 0:22.96 mpd
負荷のレベルはHD-7A 192改と変わりませんが(syuさんの結果ともほぼ同じ)、これでノイズはなくなります。ということは、ノイズはHD-7Aのファームと12.0rtカーネルのusbドライバに起因するようですね。
ただ、長時間再生を続けると、例の再生中断が発生しました。これはmpdのrt優先レベルを調整(38、37、38)し、対応できました。音はおっしゃるように素晴らしいと思います。特にfdが僕の好みですね。「さて、cuboxとbbbの使い分けどうするかなぁ」と悩みますね。
twlさん
3.12.1-rt2_BBB_1123_RT+を試してみました。テスト条件は上記の通りです(rootfsはdebianでなくarch)。結果はtinlerさんのfd、fp、bd、bpと同じくノイズの問題は解消されていますね。
ただ、連続再生ではdsdの再生中断はこちらでも発生します。問題はrt優先レベルを調整しても再生中断が解消しないこと。また、中断はtinkerさんのカーネルではかなり長時間(30分以上)連続再生させないと発生しないのですが、twlさんのカーネルでは数分(場合によると数十秒)で発生します。dsd64再生時のtopの結果もかなり違って
Linux beagle 3.12.1-rt2_BBB_1123_RT+ #2 SMP PREEMPT RT Sat Nov 23 22:17:34 JST 2013 armv7l GNU/Linux
top - 19:23:18 up 1:24, 1 user, load average: 0.92, 0.71, 0.40
Threads: 93 total, 1 running, 92 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.1 us, 62.4 sy, 0.0 ni, 32.0 id, 0.0 wa, 0.0 hi, 3.6 si, 0.0 st
KiB Mem: 501784 total, 401448 used, 100336 free, 2848 buffers
KiB Swap: 0 total, 0 used, 0 free, 312740 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
76 root -56 0 0 0 0 S 41.7 0.0 12:14.33 irq/35-musb-hdr
98 root -54 0 0 0 0 S 4.4 0.0 1:14.81 irq/57-4a100000
559 root 20 0 5096 1348 1008 R 3.4 0.3 0:00.57 top
397 root -38 0 96480 92812 31084 S 2.8 18.5 0:57.12 mpd
396 root -36 0 96480 92812 31084 S 1.9 18.5 0:52.72 mpd
364 root 20 0 0 0 0 S 1.9 0.0 0:35.82 cifsd
395 root -37 0 96480 92812 31084 S 1.6 18.5 0:30.02 mpd
3 root -2 0 0 0 0 S 0.6 0.0 0:09.78 ksoftirqd/0
というようなかなり異常な%CPUの状態が長く続くことです。
mpdをnone rtoptにすると発生しなくなるということですが、原因がよく分からないですね、。
fd、fp、bd、bp全てOKでハイレソpcm、dsd64全て問題なく再生できます(手持ちのdsd128は上手く再生できませんでしたが、これはファイルの問題のようです)。しかし、長時間の連続再生ではdsdの再生中断が発生するので、後述する方法でmpd(rtopt有)のrt優先レベルを変更して対応しました。メインで確認したrootfsはarch(syuさんの最新版)ですが、debianでも同じ結果です(debianはノイズの出ないことの確認だけ)。結局、確認できた結果はcuboxと同じ結果となりますので、原因はddcハード(おそらくusbファーム)とrtカーネル(おそらくusbドライバ)にあるようです。
syuさん
上記の環境で僕のtopですが
Linux beagle 3.12.0-rt1_0722kai-patched-00067-g01aff5a-dirty #1 SMP PREEMPT RT Sat Nov 16 16:20:07 JST 2013 armv7l GNU/Linux
top - 20:21:34 up 29 min, 2 users, load average: 1.28, 0.82, 0.64
Threads: 86 total, 2 running, 84 sleeping, 0 stopped, 0 zombie
%Cpu(s): 12.0 us, 18.7 sy, 0.0 ni, 64.0 id, 0.0 wa, 0.0 hi, 5.3 si, 0.0 st
KiB Mem: 512928 total, 508572 used, 4356 free, 2752 buffers
KiB Swap: 0 total, 0 used, 0 free, 421748 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 28.8 0.0 8:27.86 irq/35-musb-hdr
406 root -36 0 96348 92820 31084 S 3.8 18.1 0:42.43 mpd
81 root -54 0 0 0 0 S 2.9 0.0 0:59.39 irq/57-4a100000
407 root -38 0 96348 92820 31084 S 2.2 18.1 0:46.01 mpd
375 root 20 0 0 0 0 R 1.9 0.0 0:36.87 cifsd
490 root 20 0 5096 1344 1008 R 1.9 0.3 0:00.40 top
405 root -37 0 96348 92820 31084 S 1.6 18.1 0:22.96 mpd
負荷のレベルはHD-7A 192改と変わりませんが(syuさんの結果ともほぼ同じ)、これでノイズはなくなります。ということは、ノイズはHD-7Aのファームと12.0rtカーネルのusbドライバに起因するようですね。
ただ、長時間再生を続けると、例の再生中断が発生しました。これはmpdのrt優先レベルを調整(38、37、38)し、対応できました。音はおっしゃるように素晴らしいと思います。特にfdが僕の好みですね。「さて、cuboxとbbbの使い分けどうするかなぁ」と悩みますね。
twlさん
3.12.1-rt2_BBB_1123_RT+を試してみました。テスト条件は上記の通りです(rootfsはdebianでなくarch)。結果はtinlerさんのfd、fp、bd、bpと同じくノイズの問題は解消されていますね。
ただ、連続再生ではdsdの再生中断はこちらでも発生します。問題はrt優先レベルを調整しても再生中断が解消しないこと。また、中断はtinkerさんのカーネルではかなり長時間(30分以上)連続再生させないと発生しないのですが、twlさんのカーネルでは数分(場合によると数十秒)で発生します。dsd64再生時のtopの結果もかなり違って
Linux beagle 3.12.1-rt2_BBB_1123_RT+ #2 SMP PREEMPT RT Sat Nov 23 22:17:34 JST 2013 armv7l GNU/Linux
top - 19:23:18 up 1:24, 1 user, load average: 0.92, 0.71, 0.40
Threads: 93 total, 1 running, 92 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.1 us, 62.4 sy, 0.0 ni, 32.0 id, 0.0 wa, 0.0 hi, 3.6 si, 0.0 st
KiB Mem: 501784 total, 401448 used, 100336 free, 2848 buffers
KiB Swap: 0 total, 0 used, 0 free, 312740 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
76 root -56 0 0 0 0 S 41.7 0.0 12:14.33 irq/35-musb-hdr
98 root -54 0 0 0 0 S 4.4 0.0 1:14.81 irq/57-4a100000
559 root 20 0 5096 1348 1008 R 3.4 0.3 0:00.57 top
397 root -38 0 96480 92812 31084 S 2.8 18.5 0:57.12 mpd
396 root -36 0 96480 92812 31084 S 1.9 18.5 0:52.72 mpd
364 root 20 0 0 0 0 S 1.9 0.0 0:35.82 cifsd
395 root -37 0 96480 92812 31084 S 1.6 18.5 0:30.02 mpd
3 root -2 0 0 0 0 S 0.6 0.0 0:09.78 ksoftirqd/0
というようなかなり異常な%CPUの状態が長く続くことです。
mpdをnone rtoptにすると発生しなくなるということですが、原因がよく分からないですね、。
yo 2013/11/26(Tue) 21:24 No.3704
Re: BeagleBone Black(8)
twl 2013/11/26(Tue) 21:52 No.3705
twlです。syuさん、ご検証ありがとうございました。
> dsd64は音は出ますが、数分おきにストライキが起きます。一時停止>再生で復活する例のやつです。
> たまにボツとノイズが出ます。
> dsd64再生中のtop -Hです。musbの%cpuがtinkerさんのFD/FPよりも高くなります。
確かに高いですね。私の環境でも下のごとく結構な負荷になっています。
76 root -56 0 0 0 0 S 38.0 0.0 10:32.79 irq/35-musb-hdr
2109 mpd -54 0 75224 11m 2484 S 6.5 2.2 0:54.83 mpd
1697 root -54 0 0 0 0 S 5.0 0.0 0:39.57 cifsd
97 root -54 0 0 0 0 S 4.1 0.0 1:16.47 irq/57-4a100000
2068 mpd -50 0 75224 11m 2484 S 3.5 2.2 1:20.79 mpd
4165 root 20 0 2672 1128 784 R 2.4 0.2 0:00.54 top
98 root -54 0 0 0 0 S 2.1 0.0 0:16.57 irq/58-4a100000
44 root 20 0 0 0 0 S 1.5 0.0 0:15.38 kswapd0
2066 mpd -53 0 75224 11m 2484 S 0.9 2.2 0:04.18 mpd
> -snip-
> dsd128はait dacの表示がfs=NO SIGとなり、再生できませんでした。GMPCではプログレスバーは動いており、top -Hの表示もそれなりな値です。
うーん、NO SIGですか。これはUDA側が信号を受け付けていないとか？
> -snip-
> やはり環境の違いが大きいようですね。差は何でしょうね。
> もしかしてBBBの個体差？
私のDACもsyuさんのDACも基本的には同じES9018なので、DDCに用いたUDAとamaneroの違いか、あるいはBBBそのものの違いなのでしょうか。ちなみに私のBBBはA5Cとあります。今度、是非amaneroでのご検討をお願いいたします。
なお、新しいrt4のRT Kernelを下記のURLに置きましたので、お時間のある特に再度ご検証下さい。MytekとhiFace Evoのmoduleを追加してありますので、ここをお読みの他の皆様方もよろしくお願いいたします。
http://lydia.concorde.gr.jp/luke/3.12.1-rt4_BBB.tar.gz" target="_blank">http://lydia.concorde.gr.jp/luke/3.12.1-rt4_BBB.tar.gz
twl
> dsd64は音は出ますが、数分おきにストライキが起きます。一時停止>再生で復活する例のやつです。
> たまにボツとノイズが出ます。
> dsd64再生中のtop -Hです。musbの%cpuがtinkerさんのFD/FPよりも高くなります。
確かに高いですね。私の環境でも下のごとく結構な負荷になっています。
76 root -56 0 0 0 0 S 38.0 0.0 10:32.79 irq/35-musb-hdr
2109 mpd -54 0 75224 11m 2484 S 6.5 2.2 0:54.83 mpd
1697 root -54 0 0 0 0 S 5.0 0.0 0:39.57 cifsd
97 root -54 0 0 0 0 S 4.1 0.0 1:16.47 irq/57-4a100000
2068 mpd -50 0 75224 11m 2484 S 3.5 2.2 1:20.79 mpd
4165 root 20 0 2672 1128 784 R 2.4 0.2 0:00.54 top
98 root -54 0 0 0 0 S 2.1 0.0 0:16.57 irq/58-4a100000
44 root 20 0 0 0 0 S 1.5 0.0 0:15.38 kswapd0
2066 mpd -53 0 75224 11m 2484 S 0.9 2.2 0:04.18 mpd
> -snip-
> dsd128はait dacの表示がfs=NO SIGとなり、再生できませんでした。GMPCではプログレスバーは動いており、top -Hの表示もそれなりな値です。
うーん、NO SIGですか。これはUDA側が信号を受け付けていないとか？
> -snip-
> やはり環境の違いが大きいようですね。差は何でしょうね。
> もしかしてBBBの個体差？
私のDACもsyuさんのDACも基本的には同じES9018なので、DDCに用いたUDAとamaneroの違いか、あるいはBBBそのものの違いなのでしょうか。ちなみに私のBBBはA5Cとあります。今度、是非amaneroでのご検討をお願いいたします。
なお、新しいrt4のRT Kernelを下記のURLに置きましたので、お時間のある特に再度ご検証下さい。MytekとhiFace Evoのmoduleを追加してありますので、ここをお読みの他の皆様方もよろしくお願いいたします。
http://lydia.concorde.gr.jp/luke/3.12.1-rt4_BBB.tar.gz" target="_blank">http://lydia.concorde.gr.jp/luke/3.12.1-rt4_BBB.tar.gz
twl
twl 2013/11/26(Tue) 21:52 No.3705
Re: BeagleBone Black(8)
twl 2013/11/26(Tue) 22:07 No.3706
yoさん、ご検証ありがとうございました。
> 結果はtinlerさんのfd、fp、bd、bpと同じくノイズの問題は解消されていますね。
そうですか。debianの環境でのDSD128の再生ではmpdの優先度を変更しないと、顕著ではないものの、細かなスクラッチノイズがつきまといます。
それにしても、dsdの再生中断、rt優先レベルを調整しても再生中断が解消しないこと、数分(場合によると数十秒)で発生するなど、まだ問題がありそうですね。
> 76 root -56 0 0 0 0 S 41.7 0.0 12:14.33 irq/35-musb-hdr
> -snip-
> というようなかなり異常な%CPUの状態が長く続くことです。
確かにすごい値です。
> mpdをnone rtoptにすると発生しなくなるということですが、原因がよく分からないですね、。
というか、mpdそのものがnon-RT(0.18.3)で、これにchrtで優先度を設定するとノイズがかなり改善されるということです。PCMおよびDSD64ではまったく問題がないのですが。
ひき続き、先に投稿したrt4カーネルのご検証もよろしくお願いいたします。
twl
> 結果はtinlerさんのfd、fp、bd、bpと同じくノイズの問題は解消されていますね。
そうですか。debianの環境でのDSD128の再生ではmpdの優先度を変更しないと、顕著ではないものの、細かなスクラッチノイズがつきまといます。
それにしても、dsdの再生中断、rt優先レベルを調整しても再生中断が解消しないこと、数分(場合によると数十秒)で発生するなど、まだ問題がありそうですね。
> 76 root -56 0 0 0 0 S 41.7 0.0 12:14.33 irq/35-musb-hdr
> -snip-
> というようなかなり異常な%CPUの状態が長く続くことです。
確かにすごい値です。
> mpdをnone rtoptにすると発生しなくなるということですが、原因がよく分からないですね、。
というか、mpdそのものがnon-RT(0.18.3)で、これにchrtで優先度を設定するとノイズがかなり改善されるということです。PCMおよびDSD64ではまったく問題がないのですが。
ひき続き、先に投稿したrt4カーネルのご検証もよろしくお願いいたします。
twl
twl 2013/11/26(Tue) 22:07 No.3706
Re: BeagleBone Black(8)
tinker 2013/11/26(Tue) 22:46 No.3707
皆様
検証ありがとうございます。
鳴らすための条件は、とても厳しそうですね。
DDCに繋いで24/192を再生すると、こちらではこんな感じです。
ノイズ等は無いですが、topを見ながらだと、あまり気分は良くないですね。
top - 22:19:19 up 1:49, 1 user, load average: 0.60, 0.19, 0.15
Tasks: 80 total, 1 running, 79 sleeping, 0 stopped, 0 zombie
%Cpu(s): 31.3 us, 19.1 sy, 0.0 ni, 42.6 id, 0.0 wa, 0.0 hi, 7.0 si, 0.0 st
KiB Mem: 511512 total, 354736 used, 156776 free, 5248 buffers
KiB Swap: 0 total, 0 used, 0 free, 329820 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root rt 0 0 0 0 S 30.9 0.0 31:53.10 irq/35-musb-hdr
2099 mpd 20 0 67940 5164 1916 S 22.4 1.0 4:19.99 mpd
78 root -51 0 0 0 0 S 3.2 0.0 0:45.61 irq/57-4a100000
1632 root 20 0 0 0 0 S 2.5 0.0 0:26.76 cifsd
79 root -51 0 0 0 0 S 1.3 0.0 0:16.18 irq/58-4a100000
ログで以下の所が気になり調べてみました。
musb-hdrc musb-hdrc.1.auto: Falied to request rx1.
rx1というのがDMAを使う時のようですが、それが上記の様になっています。
USBの設定をCPPI4.1にしてもDMAになってないの？と思い調べてみると、以下のNo.140～142にパッチがあったので、patchを当ててbuildしてみました。
が、結果は更に負荷が80％位まで増えました(T_T)
増えた分はirq/33-47400000でdma-controllerらしいです。
http://marc.info/?l=linux-usb&w=2&r=5&s=musb&q=b" target="_blank">http://marc.info/?l=linux-usb&w=2&r=5&s=musb&q=b
またパッチを当てずに、usb及びusb-audioをモジュールにしてbuildした場合も、パッチを当てた場合と同じようにdma-controllerが動きます。
ということで、失敗報告でした。
twlさん
>BBB上で作っているのでいつ終了するか、予測できません
チャレンジャーですね～。時間はどの位でした？
検証ありがとうございます。
鳴らすための条件は、とても厳しそうですね。
DDCに繋いで24/192を再生すると、こちらではこんな感じです。
ノイズ等は無いですが、topを見ながらだと、あまり気分は良くないですね。
top - 22:19:19 up 1:49, 1 user, load average: 0.60, 0.19, 0.15
Tasks: 80 total, 1 running, 79 sleeping, 0 stopped, 0 zombie
%Cpu(s): 31.3 us, 19.1 sy, 0.0 ni, 42.6 id, 0.0 wa, 0.0 hi, 7.0 si, 0.0 st
KiB Mem: 511512 total, 354736 used, 156776 free, 5248 buffers
KiB Swap: 0 total, 0 used, 0 free, 329820 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root rt 0 0 0 0 S 30.9 0.0 31:53.10 irq/35-musb-hdr
2099 mpd 20 0 67940 5164 1916 S 22.4 1.0 4:19.99 mpd
78 root -51 0 0 0 0 S 3.2 0.0 0:45.61 irq/57-4a100000
1632 root 20 0 0 0 0 S 2.5 0.0 0:26.76 cifsd
79 root -51 0 0 0 0 S 1.3 0.0 0:16.18 irq/58-4a100000
ログで以下の所が気になり調べてみました。
musb-hdrc musb-hdrc.1.auto: Falied to request rx1.
rx1というのがDMAを使う時のようですが、それが上記の様になっています。
USBの設定をCPPI4.1にしてもDMAになってないの？と思い調べてみると、以下のNo.140～142にパッチがあったので、patchを当ててbuildしてみました。
が、結果は更に負荷が80％位まで増えました(T_T)
増えた分はirq/33-47400000でdma-controllerらしいです。
http://marc.info/?l=linux-usb&w=2&r=5&s=musb&q=b" target="_blank">http://marc.info/?l=linux-usb&w=2&r=5&s=musb&q=b
またパッチを当てずに、usb及びusb-audioをモジュールにしてbuildした場合も、パッチを当てた場合と同じようにdma-controllerが動きます。
ということで、失敗報告でした。
twlさん
>BBB上で作っているのでいつ終了するか、予測できません
チャレンジャーですね～。時間はどの位でした？
tinker 2013/11/26(Tue) 22:46 No.3707
Re: BeagleBone Black(8)
twl 2013/11/26(Tue) 23:10 No.3708
tinkerさん、お疲れ様です。
> >BBB上で作っているのでいつ終了するか、予測できません
> チャレンジャーですね～。時間はどの位でした？
チャレンジャーといえば聞こえはいいですが、単なる馬鹿ですね。(^^;
夜7時ぐらいにrtのパッチを当てたビルド作業をBBB上で開始、私は12時過ぎには就寝、unameで見ると翌日の午前３時ぐらいにはカーネルは出来上がっていたようです。朝の６時前後に起床してビルドを確認後、make modulesを開始。それを放置したまま仕事にでかけ、夜帰宅するとエラーなくmoduleが出来ているのでほっとする、といったようなペースです。昨夜はCuBox用の3.12rtカーネル、BBB用のrtカーネルおよびnon-RTカーネルのビルドを同時進行させていたので、クロスコンパイル用のMacを含め、都合３台のPCが私が寝ている間仕事していたようです。(^^;
> >BBB上で作っているのでいつ終了するか、予測できません
> チャレンジャーですね～。時間はどの位でした？
チャレンジャーといえば聞こえはいいですが、単なる馬鹿ですね。(^^;
夜7時ぐらいにrtのパッチを当てたビルド作業をBBB上で開始、私は12時過ぎには就寝、unameで見ると翌日の午前３時ぐらいにはカーネルは出来上がっていたようです。朝の６時前後に起床してビルドを確認後、make modulesを開始。それを放置したまま仕事にでかけ、夜帰宅するとエラーなくmoduleが出来ているのでほっとする、といったようなペースです。昨夜はCuBox用の3.12rtカーネル、BBB用のrtカーネルおよびnon-RTカーネルのビルドを同時進行させていたので、クロスコンパイル用のMacを含め、都合３台のPCが私が寝ている間仕事していたようです。(^^;
twl 2013/11/26(Tue) 23:10 No.3708
Re: BeagleBone Black(8)一部追記
syu 2013/11/27(Wed) 12:25 No.3709
皆様、本日休日のsyuです。
ait-dacのddcをamanero combo384に切り替えてみました。
結論から言えば、私の環境で、BBB-312rtとcombo384は相性悪そうです。combo384の故障でないか、今後あれこれ試してみたいと思います。
tinkerさんのもtwlさんのも、312-rtシリーズはpcmもdsdもノイズまみれでした。pcm44-176/dsd64-128まで、音は出ますがスクラッチノイズ様の混入が激しく、傷だらけのSP盤を蓄音機で再生している状態より悪い。しかし、ノイズに隠れて聴こえる音楽は、かなり良さそうで、可能性は十分ありそう。
312-rtシリーズをいったん諦め、0731rtnにしてみました。
0731rtnでもdsd128は音は出ますがノイズまみれ。
dsd64はノイズ少ないが、時々チリチリ、ジリジリ、時々音割れ。この現象を除外すれば、音は良い。
0731rtnでのpcmは、しかし一転、96kHzまでノイズ少なく再生。良い音。時々、プチッとノイズが出ますが、実用範囲です。
pcm176はプチプチノイズがやや頻発し、ピアノの音が割れたり。やや辛い。
0731rtnのpcm44-96に限れば、uda2とは違う傾向の良い音で、好みの範囲です。
切れ味よりもボディで迫る粘りと体温のある音で、欧米の一流製品の風味が十分ある。古いけど、スチュダcdpにチェロのアンプにスピーカーはATC300かなあ（＾＾；
癒されるのが嫌いな私でも、時にはこんなのに魅了されてメロメロするのも良いなあ(笑
上手にテンパリングされたチョコレートのような、本当にスムースで立派な音なので、これでdsdとpcm176がまともに出れば・・・・・・しかし、聴き込むほどに、雰囲気は良いなあ(笑
と言う状況で、bbb-312rtのラビリンスを楽しく彷徨うには、今のところcombo384は最適ではなさそうですが、ハードルが高いけど良さそうと言う点で、combo384で粘ってみるのは推奨です。私にcombo384で粘ってみるだけの力量がないのが残念。twlさんが頼り(^^;;;
今の私の環境ではuda2(再生専用版)がいち押しですが、combo384から戻してみると、正確性は高いけどキビしさがある。録音側の機材や技量が低いと、モロ見え。キビしさがありすぎるかもですねえ。
combo384と31200rt2-131120-fpで16/44.1再生中のtop -Hです。ノイズが多い状態。
top - 12:09:40 up 1 min, 1 user, load average: 0.42, 0.21, 0.08
Threads: 79 total, 1 running, 78 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.6 us, 20.7 sy, 0.0 ni, 76.8 id, 0.0 wa, 0.0 hi, 0.8 si, 0.0 st
KiB Mem: 512948 total, 117848 used, 395100 free, 6544 buffers
KiB Swap: 0 total, 0 used, 0 free, 48036 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 24.5 0.0 0:14.29 irq/35-musb+
448 root 20 0 5092 1284 1008 R 1.6 0.3 0:01.07 top
81 root -54 0 0 0 0 S 0.7 0.0 0:00.54 irq/57-4a10+
289 root -39 0 61672 58916 14424 S 0.7 11.5 0:00.19 mpd
292 root -54 0 0 0 0 S 0.7 0.0 0:00.54 cifsd
82 root -51 0 0 0 0 S 0.3 0.0 0:00.12 irq/58-4a10+
239 root 20 0 61672 58916 14424 S 0.3 11.5 0:01.06 mpd
290 root -38 0 61672 58916 14424 S 0.3 11.5 0:00.36 mpd
291 root -39 0 61672 58916 14424 S 0.3 11.5 0:00.25 mpd
ait-dacのddcをamanero combo384に切り替えてみました。
結論から言えば、私の環境で、BBB-312rtとcombo384は相性悪そうです。combo384の故障でないか、今後あれこれ試してみたいと思います。
tinkerさんのもtwlさんのも、312-rtシリーズはpcmもdsdもノイズまみれでした。pcm44-176/dsd64-128まで、音は出ますがスクラッチノイズ様の混入が激しく、傷だらけのSP盤を蓄音機で再生している状態より悪い。しかし、ノイズに隠れて聴こえる音楽は、かなり良さそうで、可能性は十分ありそう。
312-rtシリーズをいったん諦め、0731rtnにしてみました。
0731rtnでもdsd128は音は出ますがノイズまみれ。
dsd64はノイズ少ないが、時々チリチリ、ジリジリ、時々音割れ。この現象を除外すれば、音は良い。
0731rtnでのpcmは、しかし一転、96kHzまでノイズ少なく再生。良い音。時々、プチッとノイズが出ますが、実用範囲です。
pcm176はプチプチノイズがやや頻発し、ピアノの音が割れたり。やや辛い。
0731rtnのpcm44-96に限れば、uda2とは違う傾向の良い音で、好みの範囲です。
切れ味よりもボディで迫る粘りと体温のある音で、欧米の一流製品の風味が十分ある。古いけど、スチュダcdpにチェロのアンプにスピーカーはATC300かなあ（＾＾；
癒されるのが嫌いな私でも、時にはこんなのに魅了されてメロメロするのも良いなあ(笑
上手にテンパリングされたチョコレートのような、本当にスムースで立派な音なので、これでdsdとpcm176がまともに出れば・・・・・・しかし、聴き込むほどに、雰囲気は良いなあ(笑
と言う状況で、bbb-312rtのラビリンスを楽しく彷徨うには、今のところcombo384は最適ではなさそうですが、ハードルが高いけど良さそうと言う点で、combo384で粘ってみるのは推奨です。私にcombo384で粘ってみるだけの力量がないのが残念。twlさんが頼り(^^;;;
今の私の環境ではuda2(再生専用版)がいち押しですが、combo384から戻してみると、正確性は高いけどキビしさがある。録音側の機材や技量が低いと、モロ見え。キビしさがありすぎるかもですねえ。
combo384と31200rt2-131120-fpで16/44.1再生中のtop -Hです。ノイズが多い状態。
top - 12:09:40 up 1 min, 1 user, load average: 0.42, 0.21, 0.08
Threads: 79 total, 1 running, 78 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.6 us, 20.7 sy, 0.0 ni, 76.8 id, 0.0 wa, 0.0 hi, 0.8 si, 0.0 st
KiB Mem: 512948 total, 117848 used, 395100 free, 6544 buffers
KiB Swap: 0 total, 0 used, 0 free, 48036 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 24.5 0.0 0:14.29 irq/35-musb+
448 root 20 0 5092 1284 1008 R 1.6 0.3 0:01.07 top
81 root -54 0 0 0 0 S 0.7 0.0 0:00.54 irq/57-4a10+
289 root -39 0 61672 58916 14424 S 0.7 11.5 0:00.19 mpd
292 root -54 0 0 0 0 S 0.7 0.0 0:00.54 cifsd
82 root -51 0 0 0 0 S 0.3 0.0 0:00.12 irq/58-4a10+
239 root 20 0 61672 58916 14424 S 0.3 11.5 0:01.06 mpd
290 root -38 0 61672 58916 14424 S 0.3 11.5 0:00.36 mpd
291 root -39 0 61672 58916 14424 S 0.3 11.5 0:00.25 mpd
syu 2013/11/27(Wed) 12:25 No.3709
Re: BeagleBone Black(8)
tinker 2013/11/27(Wed) 19:35 No.3710
twlさん
結構時間かかるんですね。
UPされているイメージを試してみました。
yoさんが書かれている再生中断は、CMAを確保していない事が関係しているかもしれないですね。
私がUPしたものは、何も考えずに128M確保しています。
yoさんのところでは30分くらいで再生中断とのことなので、128Mでも足りないのかもしれませんが。
yoさん
再生中断は、FDとFPの両方で発生しますか？
結構時間かかるんですね。
UPされているイメージを試してみました。
yoさんが書かれている再生中断は、CMAを確保していない事が関係しているかもしれないですね。
私がUPしたものは、何も考えずに128M確保しています。
yoさんのところでは30分くらいで再生中断とのことなので、128Mでも足りないのかもしれませんが。
yoさん
再生中断は、FDとFPの両方で発生しますか？
tinker 2013/11/27(Wed) 19:35 No.3710
Re: BeagleBone Black(8)
yo 2013/11/27(Wed) 20:07 No.3711
twlさん
> そうですか。debianの環境でのDSD128の再生ではmpdの優先度を変更しないと、顕著ではないものの、細かなスクラッチノイズがつきまといます。
DSD128は僕の環境ではdsdファイルと認識されていません。結果、無音かノイズだけが発生します。昨日はファイルの問題かなと思いましたが、違うようですね。もう少し調べてみます。
> というか、mpdそのものがnon-RT(0.18.3)で、これにchrtで優先度を設定するとノイズがかなり改善されるということです。PCMおよびDSD64ではまったく問題がないのですが。
という意味では、再生中断の件が一番大きな違いですね。中断に関しては、syuさんのところは僕と同じような状況なので、arch/debianとRTopt-mpd/none-RTopt-mpdというのが環境の相違点となります。
あとrt4を試したのですが、音源を認識してくれません。3.12.1-rt4_BBB_1126_RT-00068-g34487ed-dirtyとdtbsの入れ換えは行っています。原因は不明です。
twlさんのコンフィグはまだ確認していないのですが、かなりのモジュールを組み込んでいますよね(ビルドで時間がかかる大きい理由もそのためだと思います)。このあたりに環境差による問題を引き起こす要因が潜んでいるという気がするのですが。
tinkerさん
最新版のrtカーネルのusbドライバの扱いに問題があることは確実だと思います。ハード環境によって問題の起き方が変わるようですが、3.10で発生した問題はまだクリア出来ていないようですね。今週末に3.12のpreemptを試してみるかな思っています。
> 再生中断は、FDとFPの両方で発生しますか？
両方で発生します。あとBP、BDでも発生します。ただし、mpdのRT優先度を前のメッセージ通り変更すれば発生しなくなります。あと、syuさんの「ストライキ」というのは同じ現象をいっていると思います。
syuさん
aitlaboでの確認は同じような結果ですね。ただ、僕の環境では128dsdはdsdファイルと認識されず、パネルにfs=44KHz I2S と表示されます。dsdファイルを通常のwavと誤認しているようですが、ddc部分(uda2/3)の差ですかね。以前のカーネル(3.8.11以前のcubox)では再生出来ていたので、不思議です。
combo384の再生結果(ノイズの状態)は僕の環境でのHD-7A 192改とよく似ているようです。このあたりはddc部分のファームウェアの動きとLinux RTカーネルの兼ね合いではないですかね。トレモロ音を引き起こすかどうかというのは大きな違いですが。
tinkerさんのメッセージに書きましたが、RTを捨ててPreemptで試してみるという手はありますかね。
> そうですか。debianの環境でのDSD128の再生ではmpdの優先度を変更しないと、顕著ではないものの、細かなスクラッチノイズがつきまといます。
DSD128は僕の環境ではdsdファイルと認識されていません。結果、無音かノイズだけが発生します。昨日はファイルの問題かなと思いましたが、違うようですね。もう少し調べてみます。
> というか、mpdそのものがnon-RT(0.18.3)で、これにchrtで優先度を設定するとノイズがかなり改善されるということです。PCMおよびDSD64ではまったく問題がないのですが。
という意味では、再生中断の件が一番大きな違いですね。中断に関しては、syuさんのところは僕と同じような状況なので、arch/debianとRTopt-mpd/none-RTopt-mpdというのが環境の相違点となります。
あとrt4を試したのですが、音源を認識してくれません。3.12.1-rt4_BBB_1126_RT-00068-g34487ed-dirtyとdtbsの入れ換えは行っています。原因は不明です。
twlさんのコンフィグはまだ確認していないのですが、かなりのモジュールを組み込んでいますよね(ビルドで時間がかかる大きい理由もそのためだと思います)。このあたりに環境差による問題を引き起こす要因が潜んでいるという気がするのですが。
tinkerさん
最新版のrtカーネルのusbドライバの扱いに問題があることは確実だと思います。ハード環境によって問題の起き方が変わるようですが、3.10で発生した問題はまだクリア出来ていないようですね。今週末に3.12のpreemptを試してみるかな思っています。
> 再生中断は、FDとFPの両方で発生しますか？
両方で発生します。あとBP、BDでも発生します。ただし、mpdのRT優先度を前のメッセージ通り変更すれば発生しなくなります。あと、syuさんの「ストライキ」というのは同じ現象をいっていると思います。
syuさん
aitlaboでの確認は同じような結果ですね。ただ、僕の環境では128dsdはdsdファイルと認識されず、パネルにfs=44KHz I2S と表示されます。dsdファイルを通常のwavと誤認しているようですが、ddc部分(uda2/3)の差ですかね。以前のカーネル(3.8.11以前のcubox)では再生出来ていたので、不思議です。
combo384の再生結果(ノイズの状態)は僕の環境でのHD-7A 192改とよく似ているようです。このあたりはddc部分のファームウェアの動きとLinux RTカーネルの兼ね合いではないですかね。トレモロ音を引き起こすかどうかというのは大きな違いですが。
tinkerさんのメッセージに書きましたが、RTを捨ててPreemptで試してみるという手はありますかね。
yo 2013/11/27(Wed) 20:07 No.3711
Re: BeagleBone Black(8)
syu 2013/11/27(Wed) 20:57 No.3712
twlさん
rt4、arch=>uda2=>ait-dacで試してみました。
dsd128は依然としてfs=NO SIGと表示されます。まれに6.4MHz表示が出ますが、その際も音は出ません。
dsd64はとても良い音です。再生中断は2ー3分程度で反復します。でも柔らかくて高解像な素敵な音です。
tinkerさんご提案の128M確保でどうなるかですね。
pcm44-176は問題なしの良い音でした。
tinkerさん。
fdもfpも、私の環境ではほぼ完璧です。
dsd64(fd)は先日22時間連続リピート再生できました。初期に中断が頻発していたdsd128も、なぜか中断発生が滅多にない状態になっています(fd)。バーンイン効果があるようです。
魅惑的な音のcombo384でうまくいかないのが課題といえなくもないですが・・・(^^;;
yoさん
uda3でのdsd128は私の環境でも(dsd/pcm変換)ダメでした。私のuda3はI2S端子の仕様がちがうので、I2S/DSDで接続できません。
>RTを捨ててPreemptで試してみる
後ほどやってみたいですが、課題が多すぎて捌けませんね(笑
私の環境でbdとbpが依然として上手くないのがyoさんとの大きな差です。不思議です。
rt4、arch=>uda2=>ait-dacで試してみました。
dsd128は依然としてfs=NO SIGと表示されます。まれに6.4MHz表示が出ますが、その際も音は出ません。
dsd64はとても良い音です。再生中断は2ー3分程度で反復します。でも柔らかくて高解像な素敵な音です。
tinkerさんご提案の128M確保でどうなるかですね。
pcm44-176は問題なしの良い音でした。
tinkerさん。
fdもfpも、私の環境ではほぼ完璧です。
dsd64(fd)は先日22時間連続リピート再生できました。初期に中断が頻発していたdsd128も、なぜか中断発生が滅多にない状態になっています(fd)。バーンイン効果があるようです。
魅惑的な音のcombo384でうまくいかないのが課題といえなくもないですが・・・(^^;;
yoさん
uda3でのdsd128は私の環境でも(dsd/pcm変換)ダメでした。私のuda3はI2S端子の仕様がちがうので、I2S/DSDで接続できません。
>RTを捨ててPreemptで試してみる
後ほどやってみたいですが、課題が多すぎて捌けませんね(笑
私の環境でbdとbpが依然として上手くないのがyoさんとの大きな差です。不思議です。
syu 2013/11/27(Wed) 20:57 No.3712
Re: BeagleBone Black(8)
twl 2013/11/27(Wed) 21:18 No.3713
yoさん
> かなりのモジュールを組み込んでいますよね(ビルドで時間がかかる大きい理由も
> そのためだと思います)。このあたりに環境差による問題を引き起こす要因が潜ん
> でいるという気がするのですが。
おっしゃる通り、defaultのままでmake moduleしています。これはまずkernelのbuild自体をとにかくエラーなく終了させることを目的にしたためです。それでもrt4のバージョンではすこしは不要なmoduleを削ったのですが。でも再生音の質に関わる可能性が大きいですよね。もう少し煮詰めてみます。
tinkerさん
> yoさんが書かれている再生中断は、CMAを確保していない事が関係しているかもしれないですね。
アドバイスありがとうございます。次回のビルド時の参考にさせていただきます。
syuさん
> 今のところcombo384は最適ではなさそうですが、ハードルが高いけど良さそうと言う点で、combo384で粘って
> みるのは推奨です。
ハードルは高くないと思いますが、combo384のファームウェアは最新の状態(確か1.68だったと思いますが)ですよね。以前yoさんの雛祭りバージョンをお試し中にファームウェアを更新したら、再生音が激変した記憶がありますので、ご参考まで。
ということで皆様のアドバイスのもとに3.12rt4のカーネルビルドを再検討してみます。ありがとうございました。
twl
> かなりのモジュールを組み込んでいますよね(ビルドで時間がかかる大きい理由も
> そのためだと思います)。このあたりに環境差による問題を引き起こす要因が潜ん
> でいるという気がするのですが。
おっしゃる通り、defaultのままでmake moduleしています。これはまずkernelのbuild自体をとにかくエラーなく終了させることを目的にしたためです。それでもrt4のバージョンではすこしは不要なmoduleを削ったのですが。でも再生音の質に関わる可能性が大きいですよね。もう少し煮詰めてみます。
tinkerさん
> yoさんが書かれている再生中断は、CMAを確保していない事が関係しているかもしれないですね。
アドバイスありがとうございます。次回のビルド時の参考にさせていただきます。
syuさん
> 今のところcombo384は最適ではなさそうですが、ハードルが高いけど良さそうと言う点で、combo384で粘って
> みるのは推奨です。
ハードルは高くないと思いますが、combo384のファームウェアは最新の状態(確か1.68だったと思いますが)ですよね。以前yoさんの雛祭りバージョンをお試し中にファームウェアを更新したら、再生音が激変した記憶がありますので、ご参考まで。
ということで皆様のアドバイスのもとに3.12rt4のカーネルビルドを再検討してみます。ありがとうございました。
twl
twl 2013/11/27(Wed) 21:18 No.3713
Re: BeagleBone Black(8)
twl 2013/11/27(Wed) 22:25 No.3714
twlです。再度カーネルビルドの作業と思ったのですが、その前にmoduleで組み込んだhiFace EvoでのPCM再生はどうかなと思い、EvoをI2SでDACに接続、小生の3.12rt4カーネルで音質をチェックしてみました。
結果: Evoを介したPCM再生は非常にクリア、amaneroでの再生品質よりも良好な印象を受けました。DSD信号に対応していないDDCなので日常使用の対象にはしていなかったのですが、ちょっと考えさせられました。
もうひとつ、私にとって驚きだったのはrtset.confをonにしているにもかかわらず、以下にお示しするように、優先度を指定したプロセスの負荷の軽さで、これはamanero使用時とは大きな違いでした。特にirq/35-musb-hdrの負荷の軽さが印象的です。
root@arm:~# uname -a
Linux arm 3.12.1-rt4_BBB_1126_RT-00068-g34487ed-dirty #4 SMP PREEMPT RT Tue Nov 26 03:05:17 JST 2013 armv7l GNU/Linuxrtset.conf start
top - 22:04:07 up 5 min, 1 user, load average: 0.19, 0.55, 0.31
Threads: 94 total, 1 running, 93 sleeping, 0 stopped, 0 zombie
%Cpu(s): 7.4 us, 6.1 sy, 0.0 ni, 85.2 id, 0.0 wa, 0.0 hi, 1.3 si, 0.0 st
KiB Mem: 502088 total, 70176 used, 431912 free, 5848 buffers
KiB Swap: 0 total, 0 used, 0 free, 37592 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2044 mpd 20 0 75024 10m 2612 S 6.5 2.2 0:14.58 mpd
76 root -56 0 0 0 0 S 3.6 0.0 0:09.20 irq/35-musb-hdr
2350 root 20 0 2672 1128 784 R 1.9 0.2 0:00.48 top
97 root -54 0 0 0 0 S 1.0 0.0 0:02.40 irq/57-4a100000
1673 root -54 0 0 0 0 S 1.0 0.0 0:01.83 cifsd
98 root -54 0 0 0 0 S 0.6 0.0 0:01.41 irq/58-4a100000
2085 mpd 20 0 75024 10m 2612 S 0.6 2.2 0:01.31 mpd
2323 root 20 0 8648 2848 2128 S 0.3 0.6 0:01.12 sshd
1 root 20 0 1688 644 540 S 0.0 0.1 0:01.95 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root -2 0 0 0 0 S 0.0 0.0 0:02.30 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
Evoご使用の方々には朗報かもしれませんが、この結果から考察すると、カーネル自体の抱えるUSB関連の問題とは別に、どうも使用するUSB DDCの違いによるプロセス負荷の大小が再生ノイズの発生に大きく影響しているようです。時間があればXMOSのDDCでPCMおよびDSD64再生時の負荷をチェックしてみます。
# 3.12rtカーネルにはDDCを選り好みする傾向があるかも。
結果: Evoを介したPCM再生は非常にクリア、amaneroでの再生品質よりも良好な印象を受けました。DSD信号に対応していないDDCなので日常使用の対象にはしていなかったのですが、ちょっと考えさせられました。
もうひとつ、私にとって驚きだったのはrtset.confをonにしているにもかかわらず、以下にお示しするように、優先度を指定したプロセスの負荷の軽さで、これはamanero使用時とは大きな違いでした。特にirq/35-musb-hdrの負荷の軽さが印象的です。
root@arm:~# uname -a
Linux arm 3.12.1-rt4_BBB_1126_RT-00068-g34487ed-dirty #4 SMP PREEMPT RT Tue Nov 26 03:05:17 JST 2013 armv7l GNU/Linuxrtset.conf start
top - 22:04:07 up 5 min, 1 user, load average: 0.19, 0.55, 0.31
Threads: 94 total, 1 running, 93 sleeping, 0 stopped, 0 zombie
%Cpu(s): 7.4 us, 6.1 sy, 0.0 ni, 85.2 id, 0.0 wa, 0.0 hi, 1.3 si, 0.0 st
KiB Mem: 502088 total, 70176 used, 431912 free, 5848 buffers
KiB Swap: 0 total, 0 used, 0 free, 37592 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2044 mpd 20 0 75024 10m 2612 S 6.5 2.2 0:14.58 mpd
76 root -56 0 0 0 0 S 3.6 0.0 0:09.20 irq/35-musb-hdr
2350 root 20 0 2672 1128 784 R 1.9 0.2 0:00.48 top
97 root -54 0 0 0 0 S 1.0 0.0 0:02.40 irq/57-4a100000
1673 root -54 0 0 0 0 S 1.0 0.0 0:01.83 cifsd
98 root -54 0 0 0 0 S 0.6 0.0 0:01.41 irq/58-4a100000
2085 mpd 20 0 75024 10m 2612 S 0.6 2.2 0:01.31 mpd
2323 root 20 0 8648 2848 2128 S 0.3 0.6 0:01.12 sshd
1 root 20 0 1688 644 540 S 0.0 0.1 0:01.95 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root -2 0 0 0 0 S 0.0 0.0 0:02.30 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
Evoご使用の方々には朗報かもしれませんが、この結果から考察すると、カーネル自体の抱えるUSB関連の問題とは別に、どうも使用するUSB DDCの違いによるプロセス負荷の大小が再生ノイズの発生に大きく影響しているようです。時間があればXMOSのDDCでPCMおよびDSD64再生時の負荷をチェックしてみます。
# 3.12rtカーネルにはDDCを選り好みする傾向があるかも。
twl 2013/11/27(Wed) 22:25 No.3714
Re: BeagleBone Black(8)
yo 2013/11/27(Wed) 22:40 No.3715
syuさん
> 私の環境でbdとbpが依然として上手くないのがyoさんとの大きな差です。不思議です。
これは見落としていました。
僕の環境でfd/fpとbd/bpの差はあまりないです。音もfdがベストと思いますが、僅差ですね。再生中断の発生の仕方も同じような感じです。
uda2/3位しか差はないのだけど、ネットワークとかnasが関連しているのですかね。ただ、archについてはcifsだから同じですね。
> 私の環境でbdとbpが依然として上手くないのがyoさんとの大きな差です。不思議です。
これは見落としていました。
僕の環境でfd/fpとbd/bpの差はあまりないです。音もfdがベストと思いますが、僅差ですね。再生中断の発生の仕方も同じような感じです。
uda2/3位しか差はないのだけど、ネットワークとかnasが関連しているのですかね。ただ、archについてはcifsだから同じですね。
yo 2013/11/27(Wed) 22:40 No.3715
Re: BeagleBone Black(8)
yo 2013/11/29(Fri) 19:53 No.3717
twlさん
興味深い情報ありがとうございます。
> Evoご使用の方々には朗報かもしれませんが、この結果から考察すると、カーネル自体の抱えるUSB関連の問題とは別に、どうも使用するUSB DDCの違いによるプロセス負荷の大小が再生ノイズの発生に大きく影響しているようです。
usbドライバ(ddc)の違いによりrtカーネルの問題点が引き起こされると考えた方が良いと思います。同じrtカーネルで、標準のドライバであれば負荷が高くなり、Evo対応のドライバだと通常の負荷に戻るということは、ドライバによってrtカーネルの振る舞い方が変わるということではないでしょうか。Preemptだと問題は発生しないのも同じことだと思います。
3.6%というのはrtカーネル3.8.11以前とだいたい同じですから、この状態なら問題は発生しないようですね。
という次第で正常に聞こえていても、irq/35-musb-hdrが20%以上というのは気持ちが悪いのですよね。
興味深い情報ありがとうございます。
> Evoご使用の方々には朗報かもしれませんが、この結果から考察すると、カーネル自体の抱えるUSB関連の問題とは別に、どうも使用するUSB DDCの違いによるプロセス負荷の大小が再生ノイズの発生に大きく影響しているようです。
usbドライバ(ddc)の違いによりrtカーネルの問題点が引き起こされると考えた方が良いと思います。同じrtカーネルで、標準のドライバであれば負荷が高くなり、Evo対応のドライバだと通常の負荷に戻るということは、ドライバによってrtカーネルの振る舞い方が変わるということではないでしょうか。Preemptだと問題は発生しないのも同じことだと思います。
3.6%というのはrtカーネル3.8.11以前とだいたい同じですから、この状態なら問題は発生しないようですね。
という次第で正常に聞こえていても、irq/35-musb-hdrが20%以上というのは気持ちが悪いのですよね。
yo 2013/11/29(Fri) 19:53 No.3717
Re: BeagleBone Black(8)
twl 2013/11/29(Fri) 22:29 No.3718
yoさん
>> -snip-
>> どうも使用するUSB DDCの違いによるプロセス負荷の大小が再生ノイズの発生に大きく影響しているようです。
> usbドライバ(ddc)の違いによりrtカーネルの問題点が引き起こされると考えた方が良いと思います。
正確にはそういうことでしょうね。現実にはその違いがddcという物理的な装置の違いとして認識されてしまうわけでが。
> という次第で正常に聞こえていても、irq/35-musb-hdrが20%以上というのは気持ちが悪いのですよね。
まったくですね。RT_FULLで音が悪くなるというのは、RT_FULLが原因ではなく、それによって引き起こされたmusb hdrcの負荷がmpdの動作を妨げ、ノイズの多い環境を作り出しているのだと認識しました。この部分が解決されればrt kernelでのmpdによる再生ノイズ等の問題はほぼ解決するのではないかと思いました。
ちなみにirq/35-musb-hdrの挙動について、hiFace/archlinuxでの状況およびXMOS(REference Design))のDDCをdebian上で使用してみた結果を下記に追加させていただきます。いずれも3.12rt4カーネルでの状況です。hiFaceは前回のdebian同様、archlinuxでも負荷なく動作、XMOSはこれまでの他のDDC同様、重い負荷でのirq/35-musb-hdrの動作となっています。
[root@alarm ~]# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: hiFace [hiFace], device 0: USB-SPDIF Audio [USB-SPDIF Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0
[root@alarm ~]# top
top - 17:18:17 up 4 min, 1 user, load average: 0.37, 0.38, 0.18
Tasks: 85 total, 1 running, 84 sleeping, 0 stopped, 0 zombie
%Cpu(s): 8.5 us, 4.1 sy, 0.0 ni, 87.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 502096 total, 111204 used, 390892 free, 14396 buffers
KiB Swap: 0 total, 0 used, 0 free, 64296 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
235 mpd 20 0 85556 16048 5420 S 8.2 3.2 0:20.90 mpd
76 root -56 0 0 0 0 S 3.9 0.0 0:06.08 irq/35-musb+
428 root 20 0 4616 1288 1008 R 1.3 0.3 0:00.50 top
98 root -54 0 0 0 0 S 0.7 0.0 0:01.64 irq/57-4a10+
root@arm:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: X20 [XMOS USB Audio 2.0], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0
root@arm:~# top
top - 17:51:33 up 28 min, 1 user, load average: 0.19, 0.27, 0.30
Tasks: 75 total, 1 running, 74 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.5 us, 9.7 sy, 0.0 ni, 88.9 id, 0.0 wa, 0.0 hi, 1.0 si, 0.0 st
KiB Mem: 512880 total, 76524 used, 436356 free, 5616 buffers
KiB Swap: 0 total, 0 used, 0 free, 43252 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -51 0 0 0 0 S 26.2 0.0 1:27.23 irq/35-musb-hdr
2379 mpd 20 0 75812 10m 2048 S 2.0 2.0 0:04.91 mpd
2387 root 20 0 2672 1108 784 R 1.3 0.2 0:00.91 top
80 root -51 0 0 0 0 S 1.0 0.0 0:25.94 irq/57-4a100000
twl
>> -snip-
>> どうも使用するUSB DDCの違いによるプロセス負荷の大小が再生ノイズの発生に大きく影響しているようです。
> usbドライバ(ddc)の違いによりrtカーネルの問題点が引き起こされると考えた方が良いと思います。
正確にはそういうことでしょうね。現実にはその違いがddcという物理的な装置の違いとして認識されてしまうわけでが。
> という次第で正常に聞こえていても、irq/35-musb-hdrが20%以上というのは気持ちが悪いのですよね。
まったくですね。RT_FULLで音が悪くなるというのは、RT_FULLが原因ではなく、それによって引き起こされたmusb hdrcの負荷がmpdの動作を妨げ、ノイズの多い環境を作り出しているのだと認識しました。この部分が解決されればrt kernelでのmpdによる再生ノイズ等の問題はほぼ解決するのではないかと思いました。
ちなみにirq/35-musb-hdrの挙動について、hiFace/archlinuxでの状況およびXMOS(REference Design))のDDCをdebian上で使用してみた結果を下記に追加させていただきます。いずれも3.12rt4カーネルでの状況です。hiFaceは前回のdebian同様、archlinuxでも負荷なく動作、XMOSはこれまでの他のDDC同様、重い負荷でのirq/35-musb-hdrの動作となっています。
[root@alarm ~]# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: hiFace [hiFace], device 0: USB-SPDIF Audio [USB-SPDIF Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0
[root@alarm ~]# top
top - 17:18:17 up 4 min, 1 user, load average: 0.37, 0.38, 0.18
Tasks: 85 total, 1 running, 84 sleeping, 0 stopped, 0 zombie
%Cpu(s): 8.5 us, 4.1 sy, 0.0 ni, 87.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 502096 total, 111204 used, 390892 free, 14396 buffers
KiB Swap: 0 total, 0 used, 0 free, 64296 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
235 mpd 20 0 85556 16048 5420 S 8.2 3.2 0:20.90 mpd
76 root -56 0 0 0 0 S 3.9 0.0 0:06.08 irq/35-musb+
428 root 20 0 4616 1288 1008 R 1.3 0.3 0:00.50 top
98 root -54 0 0 0 0 S 0.7 0.0 0:01.64 irq/57-4a10+
root@arm:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: X20 [XMOS USB Audio 2.0], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0
root@arm:~# top
top - 17:51:33 up 28 min, 1 user, load average: 0.19, 0.27, 0.30
Tasks: 75 total, 1 running, 74 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.5 us, 9.7 sy, 0.0 ni, 88.9 id, 0.0 wa, 0.0 hi, 1.0 si, 0.0 st
KiB Mem: 512880 total, 76524 used, 436356 free, 5616 buffers
KiB Swap: 0 total, 0 used, 0 free, 43252 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -51 0 0 0 0 S 26.2 0.0 1:27.23 irq/35-musb-hdr
2379 mpd 20 0 75812 10m 2048 S 2.0 2.0 0:04.91 mpd
2387 root 20 0 2672 1108 784 R 1.3 0.2 0:00.91 top
80 root -51 0 0 0 0 S 1.0 0.0 0:25.94 irq/57-4a100000
twl
twl 2013/11/29(Fri) 22:29 No.3718
Re: BeagleBone Black(8)
yo 2013/11/30(Sat) 17:57 No.3719
twlさん
汎用のusb-audio用ドライバは
/lib/modules/3.12.1-rt2_BBB_1123_RT+/kernel/sound/usb/snd-usb-audio.ko
hiface専用のusb-audio用ドライバは
/lib/modules/3.12.1-rt2_BBB_1123_RT+/kernel/sound/usb/hiface/snd-usb-hiface.ko
ですね。
irq/35-musb+というのはrtカーネルのみに存在するデバイスハンドラで、上記のドライバをrt動作させるための制御を行っているのではないかと思います。
root@beagle:~# cat /proc/interrupts
CPU0
28: 9768 INTC 12 edma
30: 0 INTC 14 edma_error
33: 0 INTC 17 47400000.dma-controller
34: 0 INTC 18 musb-hdrc.0.auto
35: 40 INTC 19 musb-hdrc.1.auto
44: 938 INTC 28 mmc1
46: 60 INTC 30 4819c000.i2c
52: 0 INTC 36 tilcdc
56: 0 INTC 40 4a100000.ethernet
57: 161236 INTC 41 4a100000.ethernet
58: 238867 INTC 42 4a100000.ethernet
59: 0 INTC 43 4a100000.ethernet
80: 29872 INTC 64 mmc0
84: 108473 INTC 68 gp_timer
86: 619 INTC 70 44e0b000.i2c
88: 434 INTC 72 OMAP UART0
91: 0 INTC 75 rtc0
92: 0 INTC 76 rtc0
150: 0 GPIO 6 mmc0
IPI0: 0 CPU wakeup interrupts
IPI1: 0 Timer broadcast interrupts
IPI2: 0 Rescheduling interrupts
IPI3: 0 Function call interrupts
IPI4: 0 Single function call interrupts
IPI5: 0 CPU stop interrupts
Err: 0
の割り込み番号35番に対応するrtカーネル専用のプロセスです。
twlさんのhifaceとxmosの結果を比較すると
76 root -56 0 0 0 0 S 3.9 0.0 0:06.08 irq/35-musb+
64 root -51 0 0 0 0 S 26.2 0.0 1:27.23 irq/35-musb-hdr
となっていてかなり大きくことなりますが、この差はirq/35-musbの相手が専用ドライバのsnd-usb-hiface.koか汎用ドライバのsnd-usb-audio.koかで引き起こされるのだと思います。
そして、udaの場合も汎用ドライバのsnd-usb-audio.koを使うことになりますので、負荷は大きい値になるのだと思います。
単純にはドライバの違いが負荷の差を引き起こすわけだから
> 現実にはその違いがddcという物理的な装置の違いとして認識されてしまうわけでが。
ということになりますね。
ちなみに、Preemptにはこの割り込み番号35番に対応するrtプロセスは存在しません(top画面で表示されません)。従ってノイズは発生しないということになります(カーネル3.12系列では未確認ですが)。
汎用のusb-audio用ドライバは
/lib/modules/3.12.1-rt2_BBB_1123_RT+/kernel/sound/usb/snd-usb-audio.ko
hiface専用のusb-audio用ドライバは
/lib/modules/3.12.1-rt2_BBB_1123_RT+/kernel/sound/usb/hiface/snd-usb-hiface.ko
ですね。
irq/35-musb+というのはrtカーネルのみに存在するデバイスハンドラで、上記のドライバをrt動作させるための制御を行っているのではないかと思います。
root@beagle:~# cat /proc/interrupts
CPU0
28: 9768 INTC 12 edma
30: 0 INTC 14 edma_error
33: 0 INTC 17 47400000.dma-controller
34: 0 INTC 18 musb-hdrc.0.auto
35: 40 INTC 19 musb-hdrc.1.auto
44: 938 INTC 28 mmc1
46: 60 INTC 30 4819c000.i2c
52: 0 INTC 36 tilcdc
56: 0 INTC 40 4a100000.ethernet
57: 161236 INTC 41 4a100000.ethernet
58: 238867 INTC 42 4a100000.ethernet
59: 0 INTC 43 4a100000.ethernet
80: 29872 INTC 64 mmc0
84: 108473 INTC 68 gp_timer
86: 619 INTC 70 44e0b000.i2c
88: 434 INTC 72 OMAP UART0
91: 0 INTC 75 rtc0
92: 0 INTC 76 rtc0
150: 0 GPIO 6 mmc0
IPI0: 0 CPU wakeup interrupts
IPI1: 0 Timer broadcast interrupts
IPI2: 0 Rescheduling interrupts
IPI3: 0 Function call interrupts
IPI4: 0 Single function call interrupts
IPI5: 0 CPU stop interrupts
Err: 0
の割り込み番号35番に対応するrtカーネル専用のプロセスです。
twlさんのhifaceとxmosの結果を比較すると
76 root -56 0 0 0 0 S 3.9 0.0 0:06.08 irq/35-musb+
64 root -51 0 0 0 0 S 26.2 0.0 1:27.23 irq/35-musb-hdr
となっていてかなり大きくことなりますが、この差はirq/35-musbの相手が専用ドライバのsnd-usb-hiface.koか汎用ドライバのsnd-usb-audio.koかで引き起こされるのだと思います。
そして、udaの場合も汎用ドライバのsnd-usb-audio.koを使うことになりますので、負荷は大きい値になるのだと思います。
単純にはドライバの違いが負荷の差を引き起こすわけだから
> 現実にはその違いがddcという物理的な装置の違いとして認識されてしまうわけでが。
ということになりますね。
ちなみに、Preemptにはこの割り込み番号35番に対応するrtプロセスは存在しません(top画面で表示されません)。従ってノイズは発生しないということになります(カーネル3.12系列では未確認ですが)。
yo 2013/11/30(Sat) 17:57 No.3719
Re: BeagleBone Black(8)
twl 2013/12/01(Sun) 17:30 No.3720
yoさん wrote:
> irq/35-musb+というのはrtカーネルのみに存在するデバイスハンドラで、上記のドライバをrt動作させるための制御を
> 行っているのではないかと思います。
確かにnon-RT kernelでのtopコマンドではmusb-hdrcの負荷は検知できませんが、yoさんのお示しになったcat /proc/interruptsで各IRQの割り込みを見ると、non-RTのカーネルでも同様の割り込みが行われているようです。
以下、3.12.1のnon-RTおよびRT kernelについてmusb-hdrcの割り込み回数について比較してみました。データ取得がリアルタイムで順に行われていますので後のデータほど各IRQの割り込み回数が増えていますが、non-RT、RTのいずれのカーネルでもmusb-hdrc.1の割り込み回数が他の割り込み回数に比べ異常に多いことが指摘できます。
まずarchlinux with non-RT (PREEMPT) kernelでの状況です。
[root@alarm ~]# uname -a
Linux alarm 3.12.1_BBB_1123-bone8.1 #1 SMP PREEMPT Sat Nov 23 01:36:31 JST 2013 armv7l GNU/Linux
以下はhiFace with PCMでのtop
[root@alarm ~]# top -H
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
175 mpd 20 0 92532 14952 5532 S 8.2 2.9 0:40.20 mpd
347 root 20 0 4616 1288 1008 R 1.0 0.3 0:00.52 top
178 mpd 20 0 92532 14952 5532 S 0.7 2.9 0:04.48 mpd
159 root 20 0 4776 3528 468 S 0.3 0.7 0:03.68 haveged
301 root 20 0 0 0 0 S 0.3 0.0 0:04.97 cifsd
1 root 20 0 4796 2668 1828 S 0.0 0.5 0:03.60 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:00.33 ksoftirqd/0
4 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kworker/0:0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:00.06 kworker/u2:0
上記のごとくmusb-hdrcの負荷は検知できませんが、その直後の
[root@alarm ~]# cat /proc/interrupts では
CPU0
28: 2995 INTC 12 edma
30: 0 INTC 14 edma_error
33: 0 INTC 17 47400000.dma-controller
34: 0 INTC 18 musb-hdrc.0.auto
35: 445387 INTC 19 musb-hdrc.1.auto
44: 942 INTC 28 mmc1
46: 60 INTC 30 4819c000.i2c
52: 0 INTC 36 tilcdc
56: 0 INTC 40 4a100000.ethernet
57: 61333 INTC 41 4a100000.ethernet
58: 34022 INTC 42 4a100000.ethernet
59: 0 INTC 43 4a100000.ethernet
80: 9457 INTC 64 mmc0
84: 37131 INTC 68 gp_timer
musb-hdrc.1による結構な回数の割り込みが行われています。そのままDDCをAmaneroに接続変更、
Amanero with PCM での割り込みは以下のごとく、
[root@alarm ~]# cat /proc/interrupts
CPU0
28: 3311 INTC 12 edma
30: 0 INTC 14 edma_error
33: 0 INTC 17 47400000.dma-controller
34: 0 INTC 18 musb-hdrc.0.auto
35: 1289562 INTC 19 musb-hdrc.1.auto
44: 942 INTC 28 mmc1
46: 60 INTC 30 4819c000.i2c
52: 0 INTC 36 tilcdc
56: 0 INTC 40 4a100000.ethernet
57: 107144 INTC 41 4a100000.ethernet
58: 50818 INTC 42 4a100000.ethernet
59: 0 INTC 43 4a100000.ethernet
80: 10977 INTC 64 mmc0
84: 59436 INTC 68 gp_timer
86: 670 INTC 70 44e0b000.i2c
他のIRQの割り込みに比べ、musb-hdrc.1の割り込み回数の増加が目立ちます。しかし割り込み回数についてのDDC間での違いはなさそうです。
Amanero with DSD128でもこの状況は同様です。
[root@alarm ~]# cat /proc/interrupts
CPU0
28: 3336 INTC 12 edma
30: 0 INTC 14 edma_error
33: 0 INTC 17 47400000.dma-controller
34: 0 INTC 18 musb-hdrc.0.auto
35: 1837044 INTC 19 musb-hdrc.1.auto
44: 942 INTC 28 mmc1
46: 60 INTC 30 4819c000.i2c
52: 0 INTC 36 tilcdc
56: 0 INTC 40 4a100000.ethernet
57: 139636 INTC 41 4a100000.ethernet
58: 63701 INTC 42 4a100000.ethernet
59: 0 INTC 43 4a100000.ethernet
80: 11102 INTC 64 mmc0
84: 62778 INTC 68 gp_timer
Rootfsをarchからdebianに変更しても以下のように同じような結果です。なおリアルタイムでの計測のために、後のデータほど各IRQの割り込み回数は増えています。
root@arm:~# uname -a
Linux arm 3.12.1_BBB_1123-bone8.1 #1 SMP PREEMPT Sat Nov 23 01:36:31 JST 2013 armv7l GNU/Linux
Amanero with DSD128
root@arm:~# cat /proc/interrupts
CPU0
28: 2128 INTC 12 edma
30: 0 INTC 14 edma_error
33: 0 INTC 17 47400000.dma-controller
34: 0 INTC 18 musb-hdrc.0.auto
35: 717906 INTC 19 musb-hdrc.1.auto
44: 6750 INTC 28 mmc1
46: 60 INTC 30 4819c000.i2c
52: 0 INTC 36 tilcdc
56: 0 INTC 40 4a100000.ethernet
57: 55080 INTC 41 4a100000.ethernet
58: 20420 INTC 42 4a100000.ethernet
59: 0 INTC 43 4a100000.ethernet
80: 0 INTC 64 mmc0
Amanero with PCM
root@arm:~# cat /proc/interrupts
CPU0
28: 2138 INTC 12 edma
30: 0 INTC 14 edma_error
33: 0 INTC 17 47400000.dma-controller
34: 0 INTC 18 musb-hdrc.0.auto
35: 1062413 INTC 19 musb-hdrc.1.auto
44: 6800 INTC 28 mmc1
46: 60 INTC 30 4819c000.i2c
52: 0 INTC 36 tilcdc
56: 0 INTC 40 4a100000.ethernet
57: 83120 INTC 41 4a100000.ethernet
58: 30372 INTC 42 4a100000.ethernet
59: 0 INTC 43 4a100000.ethernet
hiFace with PCM
root@arm:~# cat /proc/interrupts
CPU0
28: 2213 INTC 12 edma
30: 0 INTC 14 edma_error
33: 0 INTC 17 47400000.dma-controller
34: 0 INTC 18 musb-hdrc.0.auto
35: 1526106 INTC 19 musb-hdrc.1.auto
44: 7095 INTC 28 mmc1
46: 60 INTC 30 4819c000.i2c
52: 0 INTC 36 tilcdc
56: 0 INTC 40 4a100000.ethernet
57: 89034 INTC 41 4a100000.ethernet
58: 33733 INTC 42 4a100000.ethernet
59: 0 INTC 43 4a100000.ethernet
80: 0 INTC 64 mmc0
次にdebianでカーネルをnon-RTからRTカーネルに変更、
root@arm:~# uname -a
Linux arm 3.12.1-rt4_BBB_1123_RT+ #3 SMP PREEMPT RT Sun Nov 24 20:49:47 JST 2013 armv7l GNU/Linux
Amanero with PCM
root@arm:~# cat /proc/interrupts
CPU0
28: 2137 INTC 12 edma
30: 0 INTC 14 edma_error
33: 0 INTC 17 47400000.dma-controller
34: 0 INTC 18 musb-hdrc.0.auto
35: 408182 INTC 19 musb-hdrc.1.auto
44: 6761 INTC 28 mmc1
46: 60 INTC 30 4819c000.i2c
52: 0 INTC 36 tilcdc
56: 0 INTC 40 4a100000.ethernet
57: 3340 INTC 41 4a100000.ethernet
Amanero with DSD128
root@arm:~# cat /proc/interrupts
CPU0
28: 2153 INTC 12 edma
30: 0 INTC 14 edma_error
33: 0 INTC 17 47400000.dma-controller
34: 0 INTC 18 musb-hdrc.0.auto
35: 723953 INTC 19 musb-hdrc.1.auto
44: 6841 INTC 28 mmc1
46: 60 INTC 30 4819c000.i2c
52: 0 INTC 36 tilcdc
56: 0 INTC 40 4a100000.ethernet
57: 14351 INTC 41 4a100000.ethernet
DDCをhiFaceに変更 (hiFace with PCM)
root@arm:~# cat /proc/interrupts
CPU0
28: 2229 INTC 12 edma
30: 0 INTC 14 edma_error
33: 0 INTC 17 47400000.dma-controller
34: 0 INTC 18 musb-hdrc.0.auto
35: 1083650 INTC 19 musb-hdrc.1.auto
44: 7141 INTC 28 mmc1
46: 60 INTC 30 4819c000.i2c
52: 0 INTC 36 tilcdc
56: 0 INTC 40 4a100000.ethernet
57: 54158 INTC 41 4a100000.ethernet
58: 7151 INTC 42 4a100000.ethernet
59: 0 INTC 43 4a100000.ethernet
まとめ:
musb-hdrc.1の割り込みはnon-RT kerelでも観察され、その割り込み回数はRTかPREEMPTかというカーネルの違いには依存しないようです。また、topで見る限り、割り込み頻度とCPU負荷の間にはあきらかな相関はなく、DDCや再生ファイルの違いにも依存しないようです。ただし、いずれにしてもこの割り込みの回数や頻度自体は異常な気がします。musb自体についてもソフトおよびハードを含めたBBB製造元のTI側の関与が大きく影響していると思われますが、3.12カーネルの今後の開発がこのような問題を解決してくれるといいですね。
twl
> irq/35-musb+というのはrtカーネルのみに存在するデバイスハンドラで、上記のドライバをrt動作させるための制御を
> 行っているのではないかと思います。
確かにnon-RT kernelでのtopコマンドではmusb-hdrcの負荷は検知できませんが、yoさんのお示しになったcat /proc/interruptsで各IRQの割り込みを見ると、non-RTのカーネルでも同様の割り込みが行われているようです。
以下、3.12.1のnon-RTおよびRT kernelについてmusb-hdrcの割り込み回数について比較してみました。データ取得がリアルタイムで順に行われていますので後のデータほど各IRQの割り込み回数が増えていますが、non-RT、RTのいずれのカーネルでもmusb-hdrc.1の割り込み回数が他の割り込み回数に比べ異常に多いことが指摘できます。
まずarchlinux with non-RT (PREEMPT) kernelでの状況です。
[root@alarm ~]# uname -a
Linux alarm 3.12.1_BBB_1123-bone8.1 #1 SMP PREEMPT Sat Nov 23 01:36:31 JST 2013 armv7l GNU/Linux
以下はhiFace with PCMでのtop
[root@alarm ~]# top -H
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
175 mpd 20 0 92532 14952 5532 S 8.2 2.9 0:40.20 mpd
347 root 20 0 4616 1288 1008 R 1.0 0.3 0:00.52 top
178 mpd 20 0 92532 14952 5532 S 0.7 2.9 0:04.48 mpd
159 root 20 0 4776 3528 468 S 0.3 0.7 0:03.68 haveged
301 root 20 0 0 0 0 S 0.3 0.0 0:04.97 cifsd
1 root 20 0 4796 2668 1828 S 0.0 0.5 0:03.60 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:00.33 ksoftirqd/0
4 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kworker/0:0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:00.06 kworker/u2:0
上記のごとくmusb-hdrcの負荷は検知できませんが、その直後の
[root@alarm ~]# cat /proc/interrupts では
CPU0
28: 2995 INTC 12 edma
30: 0 INTC 14 edma_error
33: 0 INTC 17 47400000.dma-controller
34: 0 INTC 18 musb-hdrc.0.auto
35: 445387 INTC 19 musb-hdrc.1.auto
44: 942 INTC 28 mmc1
46: 60 INTC 30 4819c000.i2c
52: 0 INTC 36 tilcdc
56: 0 INTC 40 4a100000.ethernet
57: 61333 INTC 41 4a100000.ethernet
58: 34022 INTC 42 4a100000.ethernet
59: 0 INTC 43 4a100000.ethernet
80: 9457 INTC 64 mmc0
84: 37131 INTC 68 gp_timer
musb-hdrc.1による結構な回数の割り込みが行われています。そのままDDCをAmaneroに接続変更、
Amanero with PCM での割り込みは以下のごとく、
[root@alarm ~]# cat /proc/interrupts
CPU0
28: 3311 INTC 12 edma
30: 0 INTC 14 edma_error
33: 0 INTC 17 47400000.dma-controller
34: 0 INTC 18 musb-hdrc.0.auto
35: 1289562 INTC 19 musb-hdrc.1.auto
44: 942 INTC 28 mmc1
46: 60 INTC 30 4819c000.i2c
52: 0 INTC 36 tilcdc
56: 0 INTC 40 4a100000.ethernet
57: 107144 INTC 41 4a100000.ethernet
58: 50818 INTC 42 4a100000.ethernet
59: 0 INTC 43 4a100000.ethernet
80: 10977 INTC 64 mmc0
84: 59436 INTC 68 gp_timer
86: 670 INTC 70 44e0b000.i2c
他のIRQの割り込みに比べ、musb-hdrc.1の割り込み回数の増加が目立ちます。しかし割り込み回数についてのDDC間での違いはなさそうです。
Amanero with DSD128でもこの状況は同様です。
[root@alarm ~]# cat /proc/interrupts
CPU0
28: 3336 INTC 12 edma
30: 0 INTC 14 edma_error
33: 0 INTC 17 47400000.dma-controller
34: 0 INTC 18 musb-hdrc.0.auto
35: 1837044 INTC 19 musb-hdrc.1.auto
44: 942 INTC 28 mmc1
46: 60 INTC 30 4819c000.i2c
52: 0 INTC 36 tilcdc
56: 0 INTC 40 4a100000.ethernet
57: 139636 INTC 41 4a100000.ethernet
58: 63701 INTC 42 4a100000.ethernet
59: 0 INTC 43 4a100000.ethernet
80: 11102 INTC 64 mmc0
84: 62778 INTC 68 gp_timer
Rootfsをarchからdebianに変更しても以下のように同じような結果です。なおリアルタイムでの計測のために、後のデータほど各IRQの割り込み回数は増えています。
root@arm:~# uname -a
Linux arm 3.12.1_BBB_1123-bone8.1 #1 SMP PREEMPT Sat Nov 23 01:36:31 JST 2013 armv7l GNU/Linux
Amanero with DSD128
root@arm:~# cat /proc/interrupts
CPU0
28: 2128 INTC 12 edma
30: 0 INTC 14 edma_error
33: 0 INTC 17 47400000.dma-controller
34: 0 INTC 18 musb-hdrc.0.auto
35: 717906 INTC 19 musb-hdrc.1.auto
44: 6750 INTC 28 mmc1
46: 60 INTC 30 4819c000.i2c
52: 0 INTC 36 tilcdc
56: 0 INTC 40 4a100000.ethernet
57: 55080 INTC 41 4a100000.ethernet
58: 20420 INTC 42 4a100000.ethernet
59: 0 INTC 43 4a100000.ethernet
80: 0 INTC 64 mmc0
Amanero with PCM
root@arm:~# cat /proc/interrupts
CPU0
28: 2138 INTC 12 edma
30: 0 INTC 14 edma_error
33: 0 INTC 17 47400000.dma-controller
34: 0 INTC 18 musb-hdrc.0.auto
35: 1062413 INTC 19 musb-hdrc.1.auto
44: 6800 INTC 28 mmc1
46: 60 INTC 30 4819c000.i2c
52: 0 INTC 36 tilcdc
56: 0 INTC 40 4a100000.ethernet
57: 83120 INTC 41 4a100000.ethernet
58: 30372 INTC 42 4a100000.ethernet
59: 0 INTC 43 4a100000.ethernet
hiFace with PCM
root@arm:~# cat /proc/interrupts
CPU0
28: 2213 INTC 12 edma
30: 0 INTC 14 edma_error
33: 0 INTC 17 47400000.dma-controller
34: 0 INTC 18 musb-hdrc.0.auto
35: 1526106 INTC 19 musb-hdrc.1.auto
44: 7095 INTC 28 mmc1
46: 60 INTC 30 4819c000.i2c
52: 0 INTC 36 tilcdc
56: 0 INTC 40 4a100000.ethernet
57: 89034 INTC 41 4a100000.ethernet
58: 33733 INTC 42 4a100000.ethernet
59: 0 INTC 43 4a100000.ethernet
80: 0 INTC 64 mmc0
次にdebianでカーネルをnon-RTからRTカーネルに変更、
root@arm:~# uname -a
Linux arm 3.12.1-rt4_BBB_1123_RT+ #3 SMP PREEMPT RT Sun Nov 24 20:49:47 JST 2013 armv7l GNU/Linux
Amanero with PCM
root@arm:~# cat /proc/interrupts
CPU0
28: 2137 INTC 12 edma
30: 0 INTC 14 edma_error
33: 0 INTC 17 47400000.dma-controller
34: 0 INTC 18 musb-hdrc.0.auto
35: 408182 INTC 19 musb-hdrc.1.auto
44: 6761 INTC 28 mmc1
46: 60 INTC 30 4819c000.i2c
52: 0 INTC 36 tilcdc
56: 0 INTC 40 4a100000.ethernet
57: 3340 INTC 41 4a100000.ethernet
Amanero with DSD128
root@arm:~# cat /proc/interrupts
CPU0
28: 2153 INTC 12 edma
30: 0 INTC 14 edma_error
33: 0 INTC 17 47400000.dma-controller
34: 0 INTC 18 musb-hdrc.0.auto
35: 723953 INTC 19 musb-hdrc.1.auto
44: 6841 INTC 28 mmc1
46: 60 INTC 30 4819c000.i2c
52: 0 INTC 36 tilcdc
56: 0 INTC 40 4a100000.ethernet
57: 14351 INTC 41 4a100000.ethernet
DDCをhiFaceに変更 (hiFace with PCM)
root@arm:~# cat /proc/interrupts
CPU0
28: 2229 INTC 12 edma
30: 0 INTC 14 edma_error
33: 0 INTC 17 47400000.dma-controller
34: 0 INTC 18 musb-hdrc.0.auto
35: 1083650 INTC 19 musb-hdrc.1.auto
44: 7141 INTC 28 mmc1
46: 60 INTC 30 4819c000.i2c
52: 0 INTC 36 tilcdc
56: 0 INTC 40 4a100000.ethernet
57: 54158 INTC 41 4a100000.ethernet
58: 7151 INTC 42 4a100000.ethernet
59: 0 INTC 43 4a100000.ethernet
まとめ:
musb-hdrc.1の割り込みはnon-RT kerelでも観察され、その割り込み回数はRTかPREEMPTかというカーネルの違いには依存しないようです。また、topで見る限り、割り込み頻度とCPU負荷の間にはあきらかな相関はなく、DDCや再生ファイルの違いにも依存しないようです。ただし、いずれにしてもこの割り込みの回数や頻度自体は異常な気がします。musb自体についてもソフトおよびハードを含めたBBB製造元のTI側の関与が大きく影響していると思われますが、3.12カーネルの今後の開発がこのような問題を解決してくれるといいですね。
twl
twl 2013/12/01(Sun) 17:30 No.3720
Re: BeagleBone Black(8)
yo 2013/12/02(Mon) 20:28 No.3721
このスレッドは長くなったので新しくします。タイトルは「BeagleBone Black(9)」です。
yo 2013/12/02(Mon) 20:28 No.3721
VoyageMPD と KORG DS-DAC-100
KORGからDS-DAC-10の次の世代となるDS-DAC-100が11月下旬にも販売開始となるそうです。 この2機種のUSB DACはUSB2.1でDSDサポートがされているのですが、VoyageMPDでも使用可能なものなのか、KORGからはLinux関連情報が無くて不明です。
１．DS-DAC-10でVoyageMPDからDSD再生は可能なものでしょうか。
２．DSD対応不可としても、USB2,0として認識され、PCM再生ならできるものでしょうか。
もし、実践された方がいらっしゃいましたら情報をいただけませんでしょうか。
Re: VoyageMPD と KORG DS-DAC-100
丹波 2013/11/24(Sun) 19:33 No.3699
http://www.alsa-project.org/main/index.php/Matrix:Vendor-Korg" target="_blank">http://www.alsa-project.org/main/index.php/Matrix:Vendor-Korg
このあたりに対応についてのヒントがあるらしいのですが
詳しい内容はわかりません、
このあたりに対応についてのヒントがあるらしいのですが
詳しい内容はわかりません、
丹波 2013/11/24(Sun) 19:33 No.3699
Re: VoyageMPD と KORG DS-DAC-100
丹羽さん
情報ありがとうございました。
KORG DS-DAC-10結構売れたらしいのですが、Linuxでお使いになっている人はあまりいないのでしょうね。
情報ありがとうございました。
KORG DS-DAC-10結構売れたらしいのですが、Linuxでお使いになっている人はあまりいないのでしょうね。
Cuboxと M2tech hiface組み合わせ時でのDSD再生の御質問
始めましてccrと申します。
Cubox導入以来ずっと「梅雨入りVer」で高音質の再生を楽しませて頂いております。
重ねてこの様なimage fileを無料で配布して頂きましたyo様始め関係者の皆様に厚く御礼申し上げます。
さて今回始めて当該掲示板に御質問させて頂きましたのは現在私の再生システムでDDCに「M2tech hiface」を使いDSD再生(DSD64のみ)が出来るのですがどうもこの理屈(hifaceでのDSD再生)が理解出来ずにいます。
◎ 現在の当方の再生システム＆状況は下記のとうりです。
Cubox → M2tech hiface(初期版です) → Mytek DSD-DAC
(1) hifaceは御存知の様に24bit-192Khz迄の対応ですが何故かCuboxとの組み合わせではDSD64迄再生が出来ます。物は試しと
UDA基板(Dop版)で接続しますとDSD再生は出来ませんでした。
(2) 梅雨入りVerは全くの初期仕様にて再生しています。
(3) DSDはSACDからのfileになります。
(4) Mytek側のDSD再生時にはきちんと「DSD Lock」の表示がされます。
(5) 再生の操作はMpadから行っているのですが，Mpad上での再生時のサンプリングレートが「352.8Khz」表示になります。
但し再生が終了し停止した状態ではMytek側の表示が「176.4Khz」になっています。
(6) hifaceの上位機種であります「Hiface EVO」をお使いの方も私同様「DSD64」迄の再生が可能なのでしょうか？
それ共「DSD128」迄の再生が可能でしょうか？
(7) Cuboxと hifaceとの組み合わせのみがDSD再生が可能という事になるのでしょうか？
以上基本的な質問ばかりで恐縮ですがどなたか「Cubox + hiface」等の組み合わせで御教示頂ければ大変有り難いです。
Re: Cuboxと M2tech hiface組み合わせ時でのDSD再生の御質問
twl 2013/11/21(Thu) 22:48 No.3686
twlです。
ccrさん、今晩は。思わずCreedence Clearwater Revivalを思い出してしまいました。
ccrさん wrote:
(6) hifaceの上位機種であります「Hiface EVO」をお使いの方も私同様「DSD64」迄の再生が可能なのでしょうか？
それ共「DSD128」迄の再生が可能でしょうか？
(7) Cuboxと hifaceとの組み合わせのみがDSD再生が可能という事になるのでしょうか？
まず(7)からです。私もMacやWindowsでの音楽再生にはFirewireやUSB経由でMytekを使用しています。上記のようなS/PDIF経由でのDSD再生は行ったことがなく、あくまでも推論ですが:
DSD再生が可能だったのは御使用のMytekがDoP対応のためと思われます。CuboxのS/PDIFはToslinkのみなので96KHzが限度、 DoPでのDSD再生に必要な176.4KHzをカバーするには192KHzまでの対応が可能なhiFaceのようなUSB DDCが必要、このhiFaceによる同軸のS/PDIF経由でPCM形式に偽装されたDSDファイルをCuboxからMytekまで搬送、その信号を受け取ったMytekがPCMに偽装されたファイルをdecodeしてもともとのDSDファイルとして無事に再生しているためと思われます。なお、DSD128の再生は無理だと思います。なぜならMytekに搭載されているSabre ES9016が352.8KHzに対応していないので。
(6)についてですが、私もCuBoxやBeaglebone BlackでのPCM再生にhiFace Evoを用いることがありますが、接続は常にI2S経由となっており、この環境ではDSD再生はできません。M2TECHのブログページでは、hiFace EvoだってDSD再生は可能なんだ。だけどそれをするにはKernel Streamingの環境が必要なんだ、と意地を張っていますが*、言ってるだけでやる気はなさそう、今後もhiFace Evo単体ではDSD再生のチャンスはないものと思っております。
ccrさんのようにEvoの同軸S/PDIF経由でMytekにつなげればDSD64の再生は可能かもしれませんが、試していないのでこれについては残念ながらお答えできません。いずれにしてもMytekをお持ちであることがDSD再生可能な最大の理由ではないでしょうか。
* http://m2techsrl.blogspot.jp/2013/02/hiface-and-hiface-evo-transfer-dop-dsd.html" target="_blank">http://m2techsrl.blogspot.jp/2013/02/hiface-and-hiface-evo-transfer-dop-dsd.html
ccrさん、今晩は。思わずCreedence Clearwater Revivalを思い出してしまいました。
ccrさん wrote:
(6) hifaceの上位機種であります「Hiface EVO」をお使いの方も私同様「DSD64」迄の再生が可能なのでしょうか？
それ共「DSD128」迄の再生が可能でしょうか？
(7) Cuboxと hifaceとの組み合わせのみがDSD再生が可能という事になるのでしょうか？
まず(7)からです。私もMacやWindowsでの音楽再生にはFirewireやUSB経由でMytekを使用しています。上記のようなS/PDIF経由でのDSD再生は行ったことがなく、あくまでも推論ですが:
DSD再生が可能だったのは御使用のMytekがDoP対応のためと思われます。CuboxのS/PDIFはToslinkのみなので96KHzが限度、 DoPでのDSD再生に必要な176.4KHzをカバーするには192KHzまでの対応が可能なhiFaceのようなUSB DDCが必要、このhiFaceによる同軸のS/PDIF経由でPCM形式に偽装されたDSDファイルをCuboxからMytekまで搬送、その信号を受け取ったMytekがPCMに偽装されたファイルをdecodeしてもともとのDSDファイルとして無事に再生しているためと思われます。なお、DSD128の再生は無理だと思います。なぜならMytekに搭載されているSabre ES9016が352.8KHzに対応していないので。
(6)についてですが、私もCuBoxやBeaglebone BlackでのPCM再生にhiFace Evoを用いることがありますが、接続は常にI2S経由となっており、この環境ではDSD再生はできません。M2TECHのブログページでは、hiFace EvoだってDSD再生は可能なんだ。だけどそれをするにはKernel Streamingの環境が必要なんだ、と意地を張っていますが*、言ってるだけでやる気はなさそう、今後もhiFace Evo単体ではDSD再生のチャンスはないものと思っております。
ccrさんのようにEvoの同軸S/PDIF経由でMytekにつなげればDSD64の再生は可能かもしれませんが、試していないのでこれについては残念ながらお答えできません。いずれにしてもMytekをお持ちであることがDSD再生可能な最大の理由ではないでしょうか。
* http://m2techsrl.blogspot.jp/2013/02/hiface-and-hiface-evo-transfer-dop-dsd.html" target="_blank">http://m2techsrl.blogspot.jp/2013/02/hiface-and-hiface-evo-transfer-dop-dsd.html
twl 2013/11/21(Thu) 22:48 No.3686
Re: Cuboxと M2tech hiface組み合わせ時でのDSD再生の御質問
ccr 2013/11/22(Fri) 13:42 No.3688
twlさん始めまして。
早速の御教示頂きまして大変有り難う御座います。
>思わずCreedence Clearwater Revivalを思い出してしまいました。
はい昔からずっとCCR大好き人間です。(笑）
今回twlさんの御説明で何となく今迄のもやっとしていたものが少し氷解した様に思います。
実はこのCuboxにはずっとUDA基板をDDCとして使っていたのですが，昨今Hiface EvoをCuboxに使っておられる方のサイトを散見し物は試しとばかりに組み合わせてみた所何の問題もなく再生に至りました。
おまけにDSD再生迄至り現状私のシステムではUDA基板を上回る音質で今ではすっかり常用しています。
ただ現状では御指摘の様に同軸S/PDIF経由ではDSD64迄の再生しか出来ないのでこの辺は割り切りが必要ですね。
>いずれにしてもMytekをお持ちであることがDSD再生可能な最大の理由ではないでしょうか。
ある意味ドライバー無しでDopでDSD再生が可能というのは全く想像していませんでしたのtwlさんの御指摘の説明に納得しました。
そういう意味ではこのMytekのDSD-DACというのは希有な存在ではありますね。（Mytekのfirmware等でLinux対応の何等かのドライバーが既に組み込まれているのか私の浅い知識では知る由もありませんが・・・
）
余談になりますが本当はCuboxからusb2.0直結でMytekでのDSD128再生をしたいのですがいかんせんLinuxに関しては門外漢の為「snd-usb-mytek」のビルドは未だ躊躇している段階です。
最後に今回twlさんの御教示で又一段と理解を深める事が出来ました。
本当にお世話になりました。
早速の御教示頂きまして大変有り難う御座います。
>思わずCreedence Clearwater Revivalを思い出してしまいました。
はい昔からずっとCCR大好き人間です。(笑）
今回twlさんの御説明で何となく今迄のもやっとしていたものが少し氷解した様に思います。
実はこのCuboxにはずっとUDA基板をDDCとして使っていたのですが，昨今Hiface EvoをCuboxに使っておられる方のサイトを散見し物は試しとばかりに組み合わせてみた所何の問題もなく再生に至りました。
おまけにDSD再生迄至り現状私のシステムではUDA基板を上回る音質で今ではすっかり常用しています。
ただ現状では御指摘の様に同軸S/PDIF経由ではDSD64迄の再生しか出来ないのでこの辺は割り切りが必要ですね。
>いずれにしてもMytekをお持ちであることがDSD再生可能な最大の理由ではないでしょうか。
ある意味ドライバー無しでDopでDSD再生が可能というのは全く想像していませんでしたのtwlさんの御指摘の説明に納得しました。
そういう意味ではこのMytekのDSD-DACというのは希有な存在ではありますね。（Mytekのfirmware等でLinux対応の何等かのドライバーが既に組み込まれているのか私の浅い知識では知る由もありませんが・・・
）
余談になりますが本当はCuboxからusb2.0直結でMytekでのDSD128再生をしたいのですがいかんせんLinuxに関しては門外漢の為「snd-usb-mytek」のビルドは未だ躊躇している段階です。
最後に今回twlさんの御教示で又一段と理解を深める事が出来ました。
本当にお世話になりました。
ccr 2013/11/22(Fri) 13:42 No.3688
Re: Cuboxと M2tech hiface組み合わせ時でのDSD再生の御質問
yo 2013/11/22(Fri) 19:27 No.3689
ccrさん
> どうもこの理屈(hifaceでのDSD再生)が理解出来ずにいます。
dsdファイルがddc(hiface)とDoP対応のdac(Mytec)でネイティブ再生できる理屈については、ご存じかもしれませんが、ここ
http://dsd-guide.com/dop-open-standard" target="_blank">http://dsd-guide.com/dop-open-standard
に情報があります(twlさんが書いておられる通りです)。
従って、ddc側は別にhifaceだけではなく、usb2.0対応の172KHzが再生可能なものであれば、何でも使えるはずです。
UDA基板もddcとして使えますので、これとMytekをつないもdsdネイティブ再生はできます。僕はaitlaboユーザですが、ddc部分はuda3を使って、問題なくdsd再生できています(udaは354KHz再生に対応していますので、dsd128も再生可能です)。ディプスイッチの設定で出来たような記憶があります。
あと、snd-usb-mytekについては梅雨入り版に入っています。有効にするにはファームウェアを組み込む必要はありますが、使えると思います。ここに情報があります。
http://www.symphonic-net.com/kubotayo/articles/articles015.html#042" target="_blank">http://www.symphonic-net.com/kubotayo/articles/articles015.html#042
ただし、Mytekのddcは354KHz対応していないのではありませんか。あとMytekのddc機能を有効にするにはパネル操作が必要かもしれません。
> どうもこの理屈(hifaceでのDSD再生)が理解出来ずにいます。
dsdファイルがddc(hiface)とDoP対応のdac(Mytec)でネイティブ再生できる理屈については、ご存じかもしれませんが、ここ
http://dsd-guide.com/dop-open-standard" target="_blank">http://dsd-guide.com/dop-open-standard
に情報があります(twlさんが書いておられる通りです)。
従って、ddc側は別にhifaceだけではなく、usb2.0対応の172KHzが再生可能なものであれば、何でも使えるはずです。
UDA基板もddcとして使えますので、これとMytekをつないもdsdネイティブ再生はできます。僕はaitlaboユーザですが、ddc部分はuda3を使って、問題なくdsd再生できています(udaは354KHz再生に対応していますので、dsd128も再生可能です)。ディプスイッチの設定で出来たような記憶があります。
あと、snd-usb-mytekについては梅雨入り版に入っています。有効にするにはファームウェアを組み込む必要はありますが、使えると思います。ここに情報があります。
http://www.symphonic-net.com/kubotayo/articles/articles015.html#042" target="_blank">http://www.symphonic-net.com/kubotayo/articles/articles015.html#042
ただし、Mytekのddcは354KHz対応していないのではありませんか。あとMytekのddc機能を有効にするにはパネル操作が必要かもしれません。
yo 2013/11/22(Fri) 19:27 No.3689
Re: Cuboxと M2tech hiface組み合わせ時でのDSD再生の御質問
twl 2013/11/23(Sat) 10:45 No.3692
ccrさん wrote:
> 余談になりますが本当はCuboxからusb2.0直結でMytekでのDSD128再生をしたいのですが
> いかんせんLinuxに関しては門外漢の為「snd-usb-mytek」のビルドは未だ躊躇している
> 段階です。
以下のURLにsnd-usb-mytek.ko組み込み済みの3.8.13-rt4および3.10.18-rt14のkernelとmoduleを置きました。USB2.0の環境でCuboxを直接Mytekに接続してお試し下さい。いい結果が得られるといいですね。
http://lydia.concorde.gr.jp/luke/mytek.tar.gz" target="_blank">http://lydia.concorde.gr.jp/luke/mytek.tar.gz
なお、梅雨入りバージョンの項でyoさんが詳しく説明されていますが、/lib/firmware/mytekのディレクトリを作り、その中にMytekのサイトからダウンロードしたWindows用ドライバーファイル(mytek_v1.34.10_setup.zipなど)内にあるmytekap.ihx、mytekcf.bin、mytekl2.ihxをコピー格納しておく必要があります。
CuboxにMytekを認識させるにはちょっとコツがいるかもしれません。Plug-and-playというわけにはいかないようで、MytekからのUSBケーブルをCuboxに挿す前にいったんMytekの電源を落として再投入、その間にUSBケーブルをCuboxに挿してやると素直に認識されることを経験しています。
うまくいけばaplayで以下のようになると思われます。
[root@alarmcubox ~]# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: USB2 [Mytek Stereo192-DSD USB2], device 0: MytekUSB2 [Mytek USB2]
Subdevices: 0/1
Subdevice #0: subdevice #0
なお、yoさんも私も先述したようにMytek搭載のSabre ES9016は352.8/384kHzをサポートしないので、残念ながらCubox/linuxではDSD128の再生はできません。どうしてもMytekでDSD128の再生をしたいということであれば、現状ではWindowsでのASIO方式のみがこれに対応している状況です。私もFoobar2KでこのASIOによるDSD128再生は確認しております。
> 余談になりますが本当はCuboxからusb2.0直結でMytekでのDSD128再生をしたいのですが
> いかんせんLinuxに関しては門外漢の為「snd-usb-mytek」のビルドは未だ躊躇している
> 段階です。
以下のURLにsnd-usb-mytek.ko組み込み済みの3.8.13-rt4および3.10.18-rt14のkernelとmoduleを置きました。USB2.0の環境でCuboxを直接Mytekに接続してお試し下さい。いい結果が得られるといいですね。
http://lydia.concorde.gr.jp/luke/mytek.tar.gz" target="_blank">http://lydia.concorde.gr.jp/luke/mytek.tar.gz
なお、梅雨入りバージョンの項でyoさんが詳しく説明されていますが、/lib/firmware/mytekのディレクトリを作り、その中にMytekのサイトからダウンロードしたWindows用ドライバーファイル(mytek_v1.34.10_setup.zipなど)内にあるmytekap.ihx、mytekcf.bin、mytekl2.ihxをコピー格納しておく必要があります。
CuboxにMytekを認識させるにはちょっとコツがいるかもしれません。Plug-and-playというわけにはいかないようで、MytekからのUSBケーブルをCuboxに挿す前にいったんMytekの電源を落として再投入、その間にUSBケーブルをCuboxに挿してやると素直に認識されることを経験しています。
うまくいけばaplayで以下のようになると思われます。
[root@alarmcubox ~]# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: USB2 [Mytek Stereo192-DSD USB2], device 0: MytekUSB2 [Mytek USB2]
Subdevices: 0/1
Subdevice #0: subdevice #0
なお、yoさんも私も先述したようにMytek搭載のSabre ES9016は352.8/384kHzをサポートしないので、残念ながらCubox/linuxではDSD128の再生はできません。どうしてもMytekでDSD128の再生をしたいということであれば、現状ではWindowsでのASIO方式のみがこれに対応している状況です。私もFoobar2KでこのASIOによるDSD128再生は確認しております。
twl 2013/11/23(Sat) 10:45 No.3692
Re: Cuboxと M2tech hiface組み合わせ時でのDSD再生の御質問
twl 2013/11/23(Sat) 10:51 No.3693
twlです。
先の投稿の補足です。
Mytekのmoduleは/lib/modules/[kernel version]/extra内にありますので、それをinsmodして下さい。3.10カーネルはhifaceも追加してあります。
先の投稿の補足です。
Mytekのmoduleは/lib/modules/[kernel version]/extra内にありますので、それをinsmodして下さい。3.10カーネルはhifaceも追加してあります。
twl 2013/11/23(Sat) 10:51 No.3693
Re: Cuboxと M2tech hiface組み合わせ時でのDSD再生の御質問
ccr 2013/11/23(Sat) 11:29 No.3694
yoさん始めまして
種々のアドバイス頂きまして有り難う御座います。
>別にhifaceだけではなく、usb2.0対応の172KHzが再生可能なものであれば、何でも使えるはずです。
私もこの件に関しましてはそうではないかなと漠然と思っておりました。が先述のUDA基板で試したおり結果的にDSD再生が出来なく結局Mytek側の表示は88.2KhzになってのPCM再生となった次第です。
CuboxでのDDCとMytekの組み合わせはどうも一長一短ですね。
twlさん
snd-usb-mytek組み込みの御説明恐縮です。
>私もFoobar2KでこのASIOによるDSD128再生は確認しております。
私も全く同操作で確認は出来ていたのですが最近はCuboxでの再生時間が殆どになりました。
何れにしましてもsnd-usb-mytekの作業に今後は注力していこうかなと思います。
何卒今後共宜しくお願いします。
重ねて御両人様からの御説明感謝申し上げます。
種々のアドバイス頂きまして有り難う御座います。
>別にhifaceだけではなく、usb2.0対応の172KHzが再生可能なものであれば、何でも使えるはずです。
私もこの件に関しましてはそうではないかなと漠然と思っておりました。が先述のUDA基板で試したおり結果的にDSD再生が出来なく結局Mytek側の表示は88.2KhzになってのPCM再生となった次第です。
CuboxでのDDCとMytekの組み合わせはどうも一長一短ですね。
twlさん
snd-usb-mytek組み込みの御説明恐縮です。
>私もFoobar2KでこのASIOによるDSD128再生は確認しております。
私も全く同操作で確認は出来ていたのですが最近はCuboxでの再生時間が殆どになりました。
何れにしましてもsnd-usb-mytekの作業に今後は注力していこうかなと思います。
何卒今後共宜しくお願いします。
重ねて御両人様からの御説明感謝申し上げます。
ccr 2013/11/23(Sat) 11:29 No.3694
rtopt patch for MPD 0.18 Release
Hi Yan,
Thanks for the patch I have been using since mpd 0.16 and I enjoy very much.
Since the release of MPD 0.18, would you advice which rtopt patch to apply? I have tried all the patches in "skydrive" download but it returns with error when I patch.
buffer.c.diff
mpd-dsdbugfix-20130809.diff
mpd-rtopt-20130813.diff
mpd-dsdbugfix-20130203.diff
mpd-rtopt-20130203.diff
Kindly advise.
Jeff
Re: rtopt patch for MPD 0.18 Release
yo 2013/11/14(Thu) 21:03 No.3660
Hi Jeff,
I think yan is busy for his work, so I will reply on behalf of him.
Yan's patches mpd-rtopt-20130813.diff and mpd-dsdbugfix-20130809.diff are for MPD 0.18. But they are not effective for current version since the update of the MPD has progressed. Therefore you must wait a little for yan's patch corresponding to the new version of MPD.
You can set RT priority by using "chrt" command. Please refer to the following links.
http://www.symphonic-net.com/kubotayo/cgi-bin/read.cgi?mode=all&list=topic&no=3509#3521" target="_blank">http://www.symphonic-net.com/kubotayo/cgi-bin/read.cgi?mode=all&list=topic&no=3509#3521
http://www.symphonic-net.com/kubotayo/cgi-bin/read.cgi?mode=all&list=topic&no=3599#3631" target="_blank">http://www.symphonic-net.com/kubotayo/cgi-bin/read.cgi?mode=all&list=topic&no=3599#3631
They are in Japanese but you could use Google translation.
Regards
yo
I think yan is busy for his work, so I will reply on behalf of him.
Yan's patches mpd-rtopt-20130813.diff and mpd-dsdbugfix-20130809.diff are for MPD 0.18. But they are not effective for current version since the update of the MPD has progressed. Therefore you must wait a little for yan's patch corresponding to the new version of MPD.
You can set RT priority by using "chrt" command. Please refer to the following links.
http://www.symphonic-net.com/kubotayo/cgi-bin/read.cgi?mode=all&list=topic&no=3509#3521" target="_blank">http://www.symphonic-net.com/kubotayo/cgi-bin/read.cgi?mode=all&list=topic&no=3509#3521
http://www.symphonic-net.com/kubotayo/cgi-bin/read.cgi?mode=all&list=topic&no=3599#3631" target="_blank">http://www.symphonic-net.com/kubotayo/cgi-bin/read.cgi?mode=all&list=topic&no=3599#3631
They are in Japanese but you could use Google translation.
Regards
yo
yo 2013/11/14(Thu) 21:03 No.3660
Re: rtopt patch for MPD 0.18 Release
Thanks yo! Looking forward for the new patches
I am a fans of your blog too!
I am now a Voyage+Alix users. How would you compare the alix with the Cubox (with all the tweaks you have mentioned in the blog)?
I am a fans of your blog too!
I am now a Voyage+Alix users. How would you compare the alix with the Cubox (with all the tweaks you have mentioned in the blog)?
Re: rtopt patch for MPD 0.18 Release
yo 2013/11/16(Sat) 17:32 No.3668
Hi Jeff,
> How would you compare the alix with the Cubox (with all the tweaks you have mentioned in the blog)?
Difficult question to answer because I do not have alix and my English vocabulary is limited.
But I have heard Alix once in my audio room and I thought both Cubox and Alix are excellent sound but the sound quality of two are quite different. Alix is much soft and gentle. Cubox is more sharp and clear. It depends on your taste to choose which one.
> How would you compare the alix with the Cubox (with all the tweaks you have mentioned in the blog)?
Difficult question to answer because I do not have alix and my English vocabulary is limited.
But I have heard Alix once in my audio room and I thought both Cubox and Alix are excellent sound but the sound quality of two are quite different. Alix is much soft and gentle. Cubox is more sharp and clear. It depends on your taste to choose which one.
yo 2013/11/16(Sat) 17:32 No.3668
BeagleBone Black(7)
syuさん、毎度ながらアップロードありがとうございました。
0731rtnと0807rtnを試してみました(新しいページは問題なくダウンロードできました)。
BBBはHD-7A192改とつないでflac/wav再生専用にしたので、dsd再生は試していません。
僕の好みは0731rtnですね。かなりの差でこれが一番良いと思いました。
HD-7A192改ではハイレソデータでもノイズはのらないので、そのあたりは分かりません。
参考までに192KHz wavデータを再生中の負荷状況(0731rtnと0806rtのsarの結果)を貼り付けておきます。
どちらも同じような結果ですが、ロードアベレージが高い部分が気になります。cpu負荷は変動していないので、rt優先度のチューニングが必要なのかなと思います。
Linux 3.8.13-rt9_Fe-00899-g46930b7 (arch-mpd-dsd-sd) 10/08/2013 _armv7l_ (1 CPU)
08:20:03 PM CPU %user %nice %system %iowait %steal %idle
08:20:13 PM all 1.89 0.00 14.39 0.12 0.00 83.61
08:20:23 PM all 1.66 0.00 14.44 0.12 0.00 83.79
08:20:33 PM all 1.19 0.00 14.17 0.12 0.00 84.52
08:20:43 PM all 1.90 0.00 13.78 0.12 0.00 84.20
08:20:53 PM all 2.49 0.00 13.63 0.00 0.00 83.89
08:21:03 PM all 2.12 0.00 14.45 0.12 0.00 83.31
08:21:13 PM all 1.52 0.00 15.24 0.12 0.00 83.12
08:21:23 PM all 1.66 0.00 14.03 0.12 0.00 84.19
08:21:33 PM all 1.42 0.00 14.86 0.12 0.00 83.61
08:21:43 PM all 2.34 0.00 14.40 0.12 0.00 83.14
08:21:53 PM all 2.35 0.00 14.24 0.12 0.00 83.29
08:22:03 PM all 1.76 0.00 16.18 1.76 0.00 80.30
08:22:13 PM all 1.51 0.00 16.18 0.12 0.00 82.19
08:22:23 PM all 1.41 0.00 15.08 0.00 0.00 83.51
08:22:33 PM all 2.01 0.00 13.95 0.12 0.00 83.92
08:22:43 PM all 2.44 0.00 14.77 4.19 0.00 78.60
08:22:53 PM all 2.32 0.00 15.30 0.23 0.00 82.16
08:23:03 PM all 1.64 0.00 15.32 0.00 0.00 83.04
08:23:13 PM all 1.89 0.00 14.15 0.12 0.00 83.84
08:23:23 PM all 1.88 0.00 14.57 0.12 0.00 83.43
08:23:33 PM all 2.24 0.00 13.81 0.12 0.00 83.83
08:23:43 PM all 1.76 0.00 14.79 0.00 0.00 83.45
08:23:53 PM all 2.21 0.00 15.03 0.12 0.00 82.63
08:24:03 PM all 2.33 0.00 14.59 4.32 0.00 78.76
08:24:13 PM all 1.76 0.00 14.77 0.12 0.00 83.35
08:24:23 PM all 1.75 0.00 15.38 0.12 0.00 82.75
08:24:33 PM all 2.43 0.00 15.18 0.00 0.00 82.39
08:24:43 PM all 2.79 0.00 14.53 0.12 0.00 82.56
08:24:53 PM all 2.19 0.00 15.80 0.12 0.00 81.89
08:25:03 PM all 2.45 0.00 15.89 0.58 0.00 81.07
Average: all 1.98 0.00 14.77 0.45 0.00 82.80
08:20:03 PM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 blocked
08:20:13 PM 0 79 0.19 0.31 0.31 0
08:20:23 PM 0 79 0.62 0.40 0.34 0
08:20:33 PM 0 79 1.30 0.55 0.39 0
08:20:43 PM 0 79 1.63 0.65 0.42 0
08:20:53 PM 0 79 1.92 0.74 0.46 0
08:21:03 PM 0 79 1.93 0.78 0.47 0
08:21:13 PM 0 79 1.87 0.81 0.49 0
08:21:23 PM 0 79 1.81 0.83 0.50 0
08:21:33 PM 0 79 1.61 0.82 0.50 0
08:21:43 PM 0 79 1.36 0.79 0.49 0
08:21:53 PM 0 79 1.15 0.76 0.49 0
08:22:03 PM 1 79 0.98 0.74 0.48 1
08:22:13 PM 0 79 0.83 0.71 0.48 0
08:22:23 PM 0 79 0.70 0.69 0.47 0
08:22:33 PM 0 79 0.59 0.67 0.47 0
08:22:43 PM 0 79 0.50 0.65 0.46 0
08:22:53 PM 0 79 0.42 0.62 0.46 0
08:23:03 PM 0 79 0.36 0.60 0.45 0
08:23:13 PM 0 79 0.30 0.58 0.45 0
08:23:23 PM 0 79 0.26 0.56 0.44 0
08:23:33 PM 0 79 0.22 0.55 0.44 0
08:23:43 PM 0 79 0.18 0.53 0.43 0
08:23:53 PM 0 79 0.15 0.51 0.43 0
08:24:03 PM 0 79 0.13 0.49 0.42 0
08:24:13 PM 0 79 0.11 0.48 0.42 0
08:24:23 PM 0 79 0.09 0.46 0.41 0
08:24:33 PM 0 79 0.16 0.46 0.41 0
08:24:43 PM 0 79 0.14 0.45 0.41 0
08:24:53 PM 0 79 0.11 0.43 0.41 0
08:25:03 PM 0 79 0.10 0.42 0.40 0
Average: 0 79 0.72 0.60 0.44 0
Linux 3.8.13-rt9_0722kai-patched-00899-gc6c9946-dirty (arch-mpd-dsd-sd) 10/08/2013 _armv7l_ (1 CPU)
09:19:19 PM CPU %user %nice %system %iowait %steal %idle
09:19:29 PM all 2.10 0.00 15.54 1.87 0.00 80.49
09:19:39 PM all 1.30 0.00 15.52 0.12 0.00 83.06
09:19:49 PM all 1.66 0.00 15.17 0.00 0.00 83.18
09:19:59 PM all 2.58 0.00 14.91 0.12 0.00 82.39
09:20:09 PM all 2.58 0.00 15.22 0.12 0.00 82.08
09:20:19 PM all 2.57 0.00 15.32 0.00 0.00 82.11
09:20:29 PM all 1.77 0.00 15.67 2.59 0.00 79.98
09:20:39 PM all 1.78 0.00 15.27 1.66 0.00 81.30
09:20:49 PM all 1.89 0.00 15.37 5.67 0.00 77.07
09:20:59 PM all 2.94 0.00 14.57 0.12 0.00 82.37
09:21:09 PM all 2.46 0.00 15.67 0.12 0.00 81.75
09:21:19 PM all 2.45 0.00 15.64 0.00 0.00 81.91
09:21:29 PM all 2.12 0.00 15.09 0.12 0.00 82.67
09:21:39 PM all 2.00 0.00 15.55 0.12 0.00 82.33
09:21:49 PM all 2.46 0.00 15.36 0.12 0.00 82.06
09:21:59 PM all 2.57 0.00 15.65 0.00 0.00 81.78
09:22:09 PM all 1.89 0.00 14.91 1.54 0.00 81.66
09:22:19 PM all 2.12 0.00 15.45 0.00 0.00 82.43
09:22:29 PM all 2.93 0.00 14.87 0.12 0.00 82.08
09:22:39 PM all 2.79 0.00 15.83 1.51 0.00 79.86
09:22:49 PM all 2.46 0.00 15.14 0.12 0.00 82.28
09:22:59 PM all 1.78 0.00 14.96 0.12 0.00 83.14
09:23:09 PM all 2.35 0.00 16.71 0.12 0.00 80.82
09:23:19 PM all 2.95 0.00 14.17 0.00 0.00 82.88
09:23:29 PM all 3.16 0.00 14.52 0.12 0.00 82.20
09:23:39 PM all 2.45 0.00 15.77 2.45 0.00 79.32
09:23:49 PM all 2.47 0.00 14.81 0.12 0.00 82.61
09:23:59 PM all 1.78 0.00 14.63 0.12 0.00 83.47
09:24:09 PM all 2.36 0.00 15.08 0.00 0.00 82.57
09:24:19 PM all 2.95 0.00 14.15 0.12 0.00 82.78
Average: all 2.32 0.00 15.22 0.64 0.00 81.82
09:19:19 PM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 blocked
09:19:29 PM 0 79 0.81 0.77 0.49 0
09:19:39 PM 0 79 0.69 0.74 0.49 0
09:19:49 PM 0 79 0.58 0.72 0.48 0
09:19:59 PM 0 79 0.49 0.70 0.48 0
09:20:09 PM 0 79 0.42 0.67 0.47 0
09:20:19 PM 1 79 0.35 0.65 0.47 0
09:20:29 PM 0 79 0.30 0.63 0.46 0
09:20:39 PM 0 79 0.25 0.61 0.46 0
09:20:49 PM 0 79 0.21 0.59 0.45 0
09:20:59 PM 0 79 0.18 0.57 0.45 0
09:21:09 PM 0 79 0.15 0.55 0.44 0
09:21:19 PM 0 79 0.13 0.53 0.44 0
09:21:29 PM 0 79 0.11 0.52 0.43 0
09:21:39 PM 0 79 0.09 0.50 0.43 0
09:21:49 PM 0 79 0.08 0.48 0.42 0
09:21:59 PM 0 79 0.07 0.47 0.42 0
09:22:09 PM 0 79 0.06 0.45 0.41 0
09:22:19 PM 0 79 0.05 0.44 0.41 0
09:22:29 PM 0 79 0.20 0.45 0.42 0
09:22:39 PM 0 79 0.78 0.57 0.45 0
09:22:49 PM 0 79 0.66 0.55 0.45 0
09:22:59 PM 0 79 0.56 0.54 0.44 0
09:23:09 PM 0 79 0.88 0.60 0.47 0
09:23:19 PM 0 79 1.51 0.75 0.52 0
09:23:29 PM 0 79 1.97 0.87 0.56 0
09:23:39 PM 0 79 2.59 1.04 0.62 0
09:23:49 PM 0 79 2.80 1.14 0.65 0
09:23:59 PM 0 79 2.45 1.11 0.65 0
09:24:09 PM 0 79 2.07 1.08 0.64 0
09:24:19 PM 0 79 1.90 1.08 0.65 0
Average: 0 79 0.78 0.68 0.49 0
Re: BeagleBone Black(7)
syu 2013/10/10(Thu) 20:15 No.3601
yoさん
お試し感謝。私も0731rtnが好みです。
前に引用したロボット屋さんのブログでcyclictestが行われていましたので、preemptionの違いでどの程度差が出るか、試してみました。
tinkerさんの0731configを使用。パッチを当て、.configで、no forced preemption、voluntary preemption、low latency、basic_rtを指定したカーネルで比較しました。
channel classicsのVivaldi Concerto(2.8MHz-dff)を演奏中のデータです。 http://iriver.jp/products/product_94.php#6" target="_blank">http://iriver.jp/products/product_94.php#6
最大遅延時間は順に減っていて、期待した動作はしてくれているようです。
それぞれの末尾のリンクからzImage,dtb,moduleをダウンロードできます。
rt_fullはやはり起動できませんね。
また、smp指定を外して試みてもみましたが、これも起動できませんでした。
low latency kernelの音も悪くないと思うのですが、これなら、ノイズや音切れは減るでしょうか。
ーーー
◎ no forced preemption
[root@emmc-arch-mpd-dsd ~]# uname -a
Linux emmc-arch-mpd-dsd 3.8.13-rt9_0722kai-p-NFP-00899-gc6c9946-dirty #6 SMP Thu Oct 10 00:56:11 JST 2013 armv7l GNU/Linux
[root@emmc-arch-mpd-dsd ~]# cyclictest -t10 -p 99 -n -i 10000 -l 5000
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.04 0.11 0.08 1/67 360
T: 0 ( 351) P:99 I:10000 C: 5000 Min: 13 Act: 18 Avg: 21 Max: 440
T: 1 ( 352) P:99 I:10500 C: 4789 Min: 19 Act: 27 Avg: 30 Max: 477
T: 2 ( 353) P:99 I:11000 C: 4572 Min: 13 Act: 18 Avg: 23 Max: 585
T: 3 ( 354) P:99 I:11500 C: 4373 Min: 14 Act: 23 Avg: 21 Max: 499
T: 4 ( 355) P:99 I:12000 C: 4191 Min: 17 Act: 24 Avg: 30 Max: 479
T: 5 ( 356) P:99 I:12500 C: 4023 Min: 13 Act: 19 Avg: 21 Max: 151
T: 6 ( 357) P:99 I:13000 C: 3868 Min: 13 Act: 23 Avg: 22 Max: 435
T: 7 ( 358) P:99 I:13500 C: 3725 Min: 13 Act: 20 Avg: 22 Max: 312
T: 8 ( 359) P:99 I:14000 C: 3592 Min: 12 Act: 20 Avg: 22 Max: 238
T: 9 ( 360) P:99 I:14500 C: 3468 Min: 13 Act: 18 Avg: 22 Max: 538
https://docs.google.com/file/d/0B1n2sZGxAleMQmVYcGhxMHpzNFE/edit?usp=sharing" target="_blank">https://docs.google.com/file/d/0B1n2sZGxAleMQmVYcGhxMHpzNFE/edit?usp=sharing
ーーー
◎ voluntary kernel preemption
[root@emmc-arch-mpd-dsd ~]# uname -a
Linux emmc-arch-mpd-dsd 3.8.13-rt9_0722kai-p-VKP-00899-gc6c9946-dirty #5 SMP Wed Oct 9 22:59:02 JST 2013 armv7l GNU/Linux
[root@emmc-arch-mpd-dsd ~]# cyclictest -t10 -p 99 -n -i 10000 -l 5000
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.25 0.25 0.11 1/69 322
T: 0 ( 313) P:99 I:10000 C: 5000 Min: 12 Act: 17 Avg: 21 Max: 180
T: 1 ( 314) P:99 I:10500 C: 4789 Min: 18 Act: 44 Avg: 32 Max: 171
T: 2 ( 315) P:99 I:11000 C: 4571 Min: 14 Act: 21 Avg: 22 Max: 229
T: 3 ( 316) P:99 I:11500 C: 4372 Min: 13 Act: 30 Avg: 21 Max: 167
T: 4 ( 317) P:99 I:12000 C: 4190 Min: 19 Act: 29 Avg: 29 Max: 166
T: 5 ( 318) P:99 I:12500 C: 4023 Min: 14 Act: 20 Avg: 21 Max: 142
T: 6 ( 319) P:99 I:13000 C: 3868 Min: 12 Act: 20 Avg: 21 Max: 207
T: 7 ( 320) P:99 I:13500 C: 3725 Min: 14 Act: 48 Avg: 22 Max: 171
T: 8 ( 321) P:99 I:14000 C: 3592 Min: 12 Act: 21 Avg: 22 Max: 234
T: 9 ( 322) P:99 I:14500 C: 3468 Min: 14 Act: 21 Avg: 22 Max: 175
https://docs.google.com/file/d/0B1n2sZGxAleMNWdzWVpwaFZjOUk/edit?usp=sharing" target="_blank">https://docs.google.com/file/d/0B1n2sZGxAleMNWdzWVpwaFZjOUk/edit?usp=sharing
ーーー
◎ low latency
[root@emmc-arch-mpd-dsd ~]# uname -a
Linux emmc-arch-mpd-dsd 3.8.13-rt9_0722kai-p-lowlatency-00899-gc6c9946-dirty #4 SMP PREEMPT Wed Oct 9 22:14:20 JST 2013 armv7l GNU/Linux
[root@emmc-arch-mpd-dsd ~]# cyclictest -t10 -p 99 -n -i 10000 -l 5000
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.35 0.20 0.08 1/70 313
T: 0 ( 304) P:99 I:10000 C: 5000 Min: 13 Act: 20 Avg: 22 Max: 144
T: 1 ( 305) P:99 I:10500 C: 4784 Min: 13 Act: 19 Avg: 21 Max: 120
T: 2 ( 306) P:99 I:11000 C: 4566 Min: 20 Act: 34 Avg: 30 Max: 169
T: 3 ( 307) P:99 I:11500 C: 4368 Min: 14 Act: 20 Avg: 23 Max: 178
T: 4 ( 308) P:99 I:12000 C: 4186 Min: 13 Act: 19 Avg: 23 Max: 156
T: 5 ( 309) P:99 I:12500 C: 4018 Min: 14 Act: 20 Avg: 22 Max: 136
T: 6 ( 310) P:99 I:13000 C: 3864 Min: 13 Act: 20 Avg: 22 Max: 137
T: 7 ( 311) P:99 I:13500 C: 3721 Min: 18 Act: 33 Avg: 33 Max: 120
T: 8 ( 312) P:99 I:14000 C: 3588 Min: 14 Act: 16 Avg: 22 Max: 152
T: 9 ( 313) P:99 I:14500 C: 3464 Min: 15 Act: 23 Avg: 22 Max: 111
https://docs.google.com/file/d/0B1n2sZGxAleMMmlXR0lyVXdTRGs/edit?usp=sharing" target="_blank">https://docs.google.com/file/d/0B1n2sZGxAleMMmlXR0lyVXdTRGs/edit?usp=sharing
ーーー
◎ basic_rt
[root@emmc-arch-mpd-dsd ~]# uname -a
Linux emmc-arch-mpd-dsd 3.8.13-rt9_0722kai-patched-00899-gc6c9946-dirty #3 SMP PREEMPT Mon Oct 7 18:52:59 JST 2013 armv7l GNU/Linux
[root@emmc-arch-mpd-dsd ~]# cyclictest -t10 -p 99 -n -i 10000 -l 5000
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.59 0.34 0.13 1/84 425
T: 0 ( 416) P:99 I:10000 C: 5000 Min: 14 Act: 20 Avg: 22 Max: 102
T: 1 ( 417) P:99 I:10500 C: 4772 Min: 15 Act: 34 Avg: 33 Max: 102
T: 2 ( 418) P:99 I:11000 C: 4555 Min: 14 Act: 22 Avg: 23 Max: 97
T: 3 ( 419) P:99 I:11500 C: 4357 Min: 14 Act: 19 Avg: 22 Max: 154
T: 4 ( 420) P:99 I:12000 C: 4176 Min: 14 Act: 21 Avg: 22 Max: 99
T: 5 ( 421) P:99 I:12500 C: 4009 Min: 15 Act: 24 Avg: 23 Max: 103
T: 6 ( 422) P:99 I:13000 C: 3854 Min: 16 Act: 29 Avg: 33 Max: 124
T: 7 ( 423) P:99 I:13500 C: 3712 Min: 15 Act: 21 Avg: 22 Max: 125
T: 8 ( 424) P:99 I:14000 C: 3579 Min: 15 Act: 42 Avg: 34 Max: 130
T: 9 ( 425) P:99 I:14500 C: 3456 Min: 15 Act: 19 Avg: 22 Max: 126
これで試せることはあまり残っていないかなと思います。
お陰で、私の環境ではほぼ問題が無くなりましたので、次の動きを期待しつつ、待機します。
次は何でしょうねえ(^^;
お試し感謝。私も0731rtnが好みです。
前に引用したロボット屋さんのブログでcyclictestが行われていましたので、preemptionの違いでどの程度差が出るか、試してみました。
tinkerさんの0731configを使用。パッチを当て、.configで、no forced preemption、voluntary preemption、low latency、basic_rtを指定したカーネルで比較しました。
channel classicsのVivaldi Concerto(2.8MHz-dff)を演奏中のデータです。 http://iriver.jp/products/product_94.php#6" target="_blank">http://iriver.jp/products/product_94.php#6
最大遅延時間は順に減っていて、期待した動作はしてくれているようです。
それぞれの末尾のリンクからzImage,dtb,moduleをダウンロードできます。
rt_fullはやはり起動できませんね。
また、smp指定を外して試みてもみましたが、これも起動できませんでした。
low latency kernelの音も悪くないと思うのですが、これなら、ノイズや音切れは減るでしょうか。
ーーー
◎ no forced preemption
[root@emmc-arch-mpd-dsd ~]# uname -a
Linux emmc-arch-mpd-dsd 3.8.13-rt9_0722kai-p-NFP-00899-gc6c9946-dirty #6 SMP Thu Oct 10 00:56:11 JST 2013 armv7l GNU/Linux
[root@emmc-arch-mpd-dsd ~]# cyclictest -t10 -p 99 -n -i 10000 -l 5000
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.04 0.11 0.08 1/67 360
T: 0 ( 351) P:99 I:10000 C: 5000 Min: 13 Act: 18 Avg: 21 Max: 440
T: 1 ( 352) P:99 I:10500 C: 4789 Min: 19 Act: 27 Avg: 30 Max: 477
T: 2 ( 353) P:99 I:11000 C: 4572 Min: 13 Act: 18 Avg: 23 Max: 585
T: 3 ( 354) P:99 I:11500 C: 4373 Min: 14 Act: 23 Avg: 21 Max: 499
T: 4 ( 355) P:99 I:12000 C: 4191 Min: 17 Act: 24 Avg: 30 Max: 479
T: 5 ( 356) P:99 I:12500 C: 4023 Min: 13 Act: 19 Avg: 21 Max: 151
T: 6 ( 357) P:99 I:13000 C: 3868 Min: 13 Act: 23 Avg: 22 Max: 435
T: 7 ( 358) P:99 I:13500 C: 3725 Min: 13 Act: 20 Avg: 22 Max: 312
T: 8 ( 359) P:99 I:14000 C: 3592 Min: 12 Act: 20 Avg: 22 Max: 238
T: 9 ( 360) P:99 I:14500 C: 3468 Min: 13 Act: 18 Avg: 22 Max: 538
https://docs.google.com/file/d/0B1n2sZGxAleMQmVYcGhxMHpzNFE/edit?usp=sharing" target="_blank">https://docs.google.com/file/d/0B1n2sZGxAleMQmVYcGhxMHpzNFE/edit?usp=sharing
ーーー
◎ voluntary kernel preemption
[root@emmc-arch-mpd-dsd ~]# uname -a
Linux emmc-arch-mpd-dsd 3.8.13-rt9_0722kai-p-VKP-00899-gc6c9946-dirty #5 SMP Wed Oct 9 22:59:02 JST 2013 armv7l GNU/Linux
[root@emmc-arch-mpd-dsd ~]# cyclictest -t10 -p 99 -n -i 10000 -l 5000
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.25 0.25 0.11 1/69 322
T: 0 ( 313) P:99 I:10000 C: 5000 Min: 12 Act: 17 Avg: 21 Max: 180
T: 1 ( 314) P:99 I:10500 C: 4789 Min: 18 Act: 44 Avg: 32 Max: 171
T: 2 ( 315) P:99 I:11000 C: 4571 Min: 14 Act: 21 Avg: 22 Max: 229
T: 3 ( 316) P:99 I:11500 C: 4372 Min: 13 Act: 30 Avg: 21 Max: 167
T: 4 ( 317) P:99 I:12000 C: 4190 Min: 19 Act: 29 Avg: 29 Max: 166
T: 5 ( 318) P:99 I:12500 C: 4023 Min: 14 Act: 20 Avg: 21 Max: 142
T: 6 ( 319) P:99 I:13000 C: 3868 Min: 12 Act: 20 Avg: 21 Max: 207
T: 7 ( 320) P:99 I:13500 C: 3725 Min: 14 Act: 48 Avg: 22 Max: 171
T: 8 ( 321) P:99 I:14000 C: 3592 Min: 12 Act: 21 Avg: 22 Max: 234
T: 9 ( 322) P:99 I:14500 C: 3468 Min: 14 Act: 21 Avg: 22 Max: 175
https://docs.google.com/file/d/0B1n2sZGxAleMNWdzWVpwaFZjOUk/edit?usp=sharing" target="_blank">https://docs.google.com/file/d/0B1n2sZGxAleMNWdzWVpwaFZjOUk/edit?usp=sharing
ーーー
◎ low latency
[root@emmc-arch-mpd-dsd ~]# uname -a
Linux emmc-arch-mpd-dsd 3.8.13-rt9_0722kai-p-lowlatency-00899-gc6c9946-dirty #4 SMP PREEMPT Wed Oct 9 22:14:20 JST 2013 armv7l GNU/Linux
[root@emmc-arch-mpd-dsd ~]# cyclictest -t10 -p 99 -n -i 10000 -l 5000
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.35 0.20 0.08 1/70 313
T: 0 ( 304) P:99 I:10000 C: 5000 Min: 13 Act: 20 Avg: 22 Max: 144
T: 1 ( 305) P:99 I:10500 C: 4784 Min: 13 Act: 19 Avg: 21 Max: 120
T: 2 ( 306) P:99 I:11000 C: 4566 Min: 20 Act: 34 Avg: 30 Max: 169
T: 3 ( 307) P:99 I:11500 C: 4368 Min: 14 Act: 20 Avg: 23 Max: 178
T: 4 ( 308) P:99 I:12000 C: 4186 Min: 13 Act: 19 Avg: 23 Max: 156
T: 5 ( 309) P:99 I:12500 C: 4018 Min: 14 Act: 20 Avg: 22 Max: 136
T: 6 ( 310) P:99 I:13000 C: 3864 Min: 13 Act: 20 Avg: 22 Max: 137
T: 7 ( 311) P:99 I:13500 C: 3721 Min: 18 Act: 33 Avg: 33 Max: 120
T: 8 ( 312) P:99 I:14000 C: 3588 Min: 14 Act: 16 Avg: 22 Max: 152
T: 9 ( 313) P:99 I:14500 C: 3464 Min: 15 Act: 23 Avg: 22 Max: 111
https://docs.google.com/file/d/0B1n2sZGxAleMMmlXR0lyVXdTRGs/edit?usp=sharing" target="_blank">https://docs.google.com/file/d/0B1n2sZGxAleMMmlXR0lyVXdTRGs/edit?usp=sharing
ーーー
◎ basic_rt
[root@emmc-arch-mpd-dsd ~]# uname -a
Linux emmc-arch-mpd-dsd 3.8.13-rt9_0722kai-patched-00899-gc6c9946-dirty #3 SMP PREEMPT Mon Oct 7 18:52:59 JST 2013 armv7l GNU/Linux
[root@emmc-arch-mpd-dsd ~]# cyclictest -t10 -p 99 -n -i 10000 -l 5000
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.59 0.34 0.13 1/84 425
T: 0 ( 416) P:99 I:10000 C: 5000 Min: 14 Act: 20 Avg: 22 Max: 102
T: 1 ( 417) P:99 I:10500 C: 4772 Min: 15 Act: 34 Avg: 33 Max: 102
T: 2 ( 418) P:99 I:11000 C: 4555 Min: 14 Act: 22 Avg: 23 Max: 97
T: 3 ( 419) P:99 I:11500 C: 4357 Min: 14 Act: 19 Avg: 22 Max: 154
T: 4 ( 420) P:99 I:12000 C: 4176 Min: 14 Act: 21 Avg: 22 Max: 99
T: 5 ( 421) P:99 I:12500 C: 4009 Min: 15 Act: 24 Avg: 23 Max: 103
T: 6 ( 422) P:99 I:13000 C: 3854 Min: 16 Act: 29 Avg: 33 Max: 124
T: 7 ( 423) P:99 I:13500 C: 3712 Min: 15 Act: 21 Avg: 22 Max: 125
T: 8 ( 424) P:99 I:14000 C: 3579 Min: 15 Act: 42 Avg: 34 Max: 130
T: 9 ( 425) P:99 I:14500 C: 3456 Min: 15 Act: 19 Avg: 22 Max: 126
これで試せることはあまり残っていないかなと思います。
お陰で、私の環境ではほぼ問題が無くなりましたので、次の動きを期待しつつ、待機します。
次は何でしょうねえ(^^;
syu 2013/10/10(Thu) 20:15 No.3601
Re: BeagleBone Black(7)
tinker 2013/10/11(Fri) 19:22 No.3602
お久しぶりです。
覗いてはいたんですが、ネタもないので・・・
最近はraspberry piでルータの設定したり、VirtualBoxとVMware Playerのどっちがいいのかとか、openSUSEやMintとかインストールして遊んでました。
最近調べたことだと
・BBB
nextにam335x-boneblack.dtsが入ったようです。これで3.13からは公式ソースでkernelが作れそうです。ただ13だとRTパッチは出ないので、次の3.14を待つことになります。時期的には来年のGW頃でしょうか。
・Cubox-i
最初乗ってくるkernelは3.0.35なんですね。RTにできるまで少し時間がかかりそうです。
私はi.MX6のwandboardを持ってるので、Cubox-iを買うことはないと思います。
・3.10.14＋rt9
rtパッチを当てたmpdでも切れたりしません。皆さんのところはどうでしょうか？
>次は何でしょうねえ(^^;
きっとyoさんがODROIDを。。。(^^;
覗いてはいたんですが、ネタもないので・・・
最近はraspberry piでルータの設定したり、VirtualBoxとVMware Playerのどっちがいいのかとか、openSUSEやMintとかインストールして遊んでました。
最近調べたことだと
・BBB
nextにam335x-boneblack.dtsが入ったようです。これで3.13からは公式ソースでkernelが作れそうです。ただ13だとRTパッチは出ないので、次の3.14を待つことになります。時期的には来年のGW頃でしょうか。
・Cubox-i
最初乗ってくるkernelは3.0.35なんですね。RTにできるまで少し時間がかかりそうです。
私はi.MX6のwandboardを持ってるので、Cubox-iを買うことはないと思います。
・3.10.14＋rt9
rtパッチを当てたmpdでも切れたりしません。皆さんのところはどうでしょうか？
>次は何でしょうねえ(^^;
きっとyoさんがODROIDを。。。(^^;
tinker 2013/10/11(Fri) 19:22 No.3602
Re: BeagleBone Black(7)
tinker 2013/10/11(Fri) 19:51 No.3603
ちょっと訂正です。
>・BBB
>次の3.14を待つことになります。時期的には来年のGW頃でしょうか。
3.12.rc4に入ってるみたいです。
年末くらいには何とかなりそうですね。
>・BBB
>次の3.14を待つことになります。時期的には来年のGW頃でしょうか。
3.12.rc4に入ってるみたいです。
年末くらいには何とかなりそうですね。
tinker 2013/10/11(Fri) 19:51 No.3603
Re: BeagleBone Black(7)
yo 2013/10/11(Fri) 20:56 No.3604
syuさん
cyclictestの結果を興味深く拝見しました。ロボット屋さんの結果とは多少異なるようですが、-Pを99にしたからですかね。syuさんの結果の方が整合性はとれていると思います。僕のところでも試してみましたが(cyclictestってビルドする必要があるのですね)、syuさんのところと同じような結果でした。
> low latency kernelの音も悪くないと思うのですが、これなら、ノイズや音切れは減るでしょうか。
非rtカーネルであれば、ノイズ、音切れ、再生中断などは発生しません。僕が公開しているdebianのイメージではpreempt(syuさんのllのことです)のカーネルを選択できるようにしてあります(0731pe)。これはdsd再生でrtカーネル(0731rt)だと再生中断が発生するので、その対応の為に最初から入れておきました。
非rtカーネルの場合、cpu負荷、ロードアベレージなどの値は大幅に改善されていて、3.8.11以前のrtカーネルと同じような状況です。このあたりが非rtカーネルだと問題を起こさない理由だと思っています。
参考までに今回の0731llでの192KHz wavデータを再生中の負荷状況を貼り付けておきます。使ったwavファイル、接続したハードウェアなどは一番最初のメッセージと全く同じです。
sar -uq -o data.file 10 30 > /dev/null &
sar -uq -f data.file > data.txt
でdata.txtの内容です。
Linux 3.8.13-rt9_0722kai-p-lowlatency-00899-gc6c9946-dirty (arch-mpd-dsd-sd) 10/11/2013 _armv7$
08:44:07 PM CPU %user %nice %system %iowait %steal %idle
08:44:17 PM all 1.83 0.00 6.69 0.11 0.00 91.37
08:44:27 PM all 1.51 0.00 6.92 0.11 0.00 91.46
08:44:37 PM all 1.96 0.00 5.56 0.22 0.00 92.26
08:44:47 PM all 1.31 0.00 6.01 0.22 0.00 92.46
08:44:57 PM all 1.74 0.00 6.19 0.22 0.00 91.86
08:45:07 PM all 2.16 0.00 6.27 0.22 0.00 91.35
08:45:17 PM all 1.73 0.00 6.49 0.11 0.00 91.68
08:45:27 PM all 1.97 0.00 5.46 0.33 0.00 92.24
08:45:37 PM all 1.31 0.00 6.01 0.00 0.00 92.68
08:45:47 PM all 1.42 0.00 6.21 0.22 0.00 92.16
08:45:57 PM all 2.38 0.00 6.05 0.22 0.00 91.35
08:46:07 PM all 2.18 0.00 5.55 0.11 0.00 92.17
08:46:17 PM all 2.05 0.00 6.57 0.11 0.00 91.27
08:46:27 PM all 1.43 0.00 5.70 0.22 0.00 92.65
08:46:37 PM all 1.20 0.00 6.12 0.00 0.00 92.68
08:46:47 PM all 1.74 0.00 6.19 0.22 0.00 91.86
08:46:57 PM all 1.95 0.00 6.49 0.11 0.00 91.46
08:47:07 PM all 1.63 0.00 6.30 0.11 0.00 91.96
08:47:17 PM all 1.97 0.00 5.57 0.11 0.00 92.36
08:47:27 PM all 1.20 0.00 6.33 0.11 0.00 92.36
08:47:37 PM all 1.41 0.00 6.42 0.11 0.00 92.06
08:47:47 PM all 2.27 0.00 6.17 0.11 0.00 91.45
08:47:57 PM all 1.83 0.00 7.09 0.21 0.00 90.87
08:48:07 PM all 1.86 0.00 5.68 0.11 0.00 92.36
08:48:17 PM all 1.31 0.00 6.34 0.00 0.00 92.35
08:48:27 PM all 1.20 0.00 6.63 0.22 0.00 91.96
08:48:37 PM all 1.95 0.00 6.28 0.11 0.00 91.66
08:48:47 PM all 2.16 0.00 6.68 0.11 0.00 91.06
08:48:57 PM all 1.72 0.00 7.11 0.11 0.00 91.06
08:49:07 PM all 1.74 0.00 5.67 2.94 0.00 89.64
Average: all 1.74 0.00 6.23 0.24 0.00 91.80
08:44:07 PM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 blocked
08:44:17 PM 0 63 0.00 0.01 0.05 0
08:44:27 PM 0 63 0.00 0.01 0.05 0
08:44:37 PM 0 63 0.00 0.01 0.05 0
08:44:47 PM 0 63 0.00 0.01 0.05 0
08:44:57 PM 0 63 0.00 0.01 0.05 0
08:45:07 PM 0 63 0.00 0.01 0.05 0
08:45:17 PM 0 63 0.00 0.01 0.05 0
08:45:27 PM 0 63 0.00 0.01 0.05 0
08:45:37 PM 0 63 0.00 0.01 0.05 0
08:45:47 PM 0 63 0.00 0.01 0.05 0
08:45:57 PM 0 63 0.00 0.01 0.05 0
08:46:07 PM 0 63 0.00 0.01 0.05 0
08:46:17 PM 0 63 0.08 0.03 0.05 0
08:46:27 PM 0 63 0.07 0.03 0.05 0
08:46:37 PM 0 63 0.06 0.03 0.05 0
08:46:47 PM 0 63 0.05 0.03 0.05 0
08:46:57 PM 0 63 0.04 0.03 0.05 0
08:47:07 PM 0 63 0.04 0.03 0.05 0
08:47:17 PM 0 63 0.03 0.03 0.05 0
08:47:27 PM 0 63 0.03 0.02 0.05 0
08:47:37 PM 0 63 0.02 0.02 0.05 0
08:47:47 PM 0 63 0.02 0.02 0.05 0
08:47:57 PM 0 63 0.02 0.02 0.05 0
08:48:07 PM 0 63 0.01 0.02 0.05 0
08:48:17 PM 0 63 0.01 0.02 0.05 0
08:48:27 PM 0 63 0.01 0.02 0.05 0
08:48:37 PM 0 63 0.01 0.02 0.05 0
08:48:47 PM 0 63 0.01 0.02 0.05 0
08:48:57 PM 0 63 0.01 0.02 0.05 0
08:49:07 PM 0 63 0.00 0.01 0.05 0
Average: 0 63 0.02 0.02 0.05 0
ご覧の通り素晴らしい数値で、特にロードアベレージはほとんど待ちが発生していないことになりますから、凄いです。
cyclictestの結果を興味深く拝見しました。ロボット屋さんの結果とは多少異なるようですが、-Pを99にしたからですかね。syuさんの結果の方が整合性はとれていると思います。僕のところでも試してみましたが(cyclictestってビルドする必要があるのですね)、syuさんのところと同じような結果でした。
> low latency kernelの音も悪くないと思うのですが、これなら、ノイズや音切れは減るでしょうか。
非rtカーネルであれば、ノイズ、音切れ、再生中断などは発生しません。僕が公開しているdebianのイメージではpreempt(syuさんのllのことです)のカーネルを選択できるようにしてあります(0731pe)。これはdsd再生でrtカーネル(0731rt)だと再生中断が発生するので、その対応の為に最初から入れておきました。
非rtカーネルの場合、cpu負荷、ロードアベレージなどの値は大幅に改善されていて、3.8.11以前のrtカーネルと同じような状況です。このあたりが非rtカーネルだと問題を起こさない理由だと思っています。
参考までに今回の0731llでの192KHz wavデータを再生中の負荷状況を貼り付けておきます。使ったwavファイル、接続したハードウェアなどは一番最初のメッセージと全く同じです。
sar -uq -o data.file 10 30 > /dev/null &
sar -uq -f data.file > data.txt
でdata.txtの内容です。
Linux 3.8.13-rt9_0722kai-p-lowlatency-00899-gc6c9946-dirty (arch-mpd-dsd-sd) 10/11/2013 _armv7$
08:44:07 PM CPU %user %nice %system %iowait %steal %idle
08:44:17 PM all 1.83 0.00 6.69 0.11 0.00 91.37
08:44:27 PM all 1.51 0.00 6.92 0.11 0.00 91.46
08:44:37 PM all 1.96 0.00 5.56 0.22 0.00 92.26
08:44:47 PM all 1.31 0.00 6.01 0.22 0.00 92.46
08:44:57 PM all 1.74 0.00 6.19 0.22 0.00 91.86
08:45:07 PM all 2.16 0.00 6.27 0.22 0.00 91.35
08:45:17 PM all 1.73 0.00 6.49 0.11 0.00 91.68
08:45:27 PM all 1.97 0.00 5.46 0.33 0.00 92.24
08:45:37 PM all 1.31 0.00 6.01 0.00 0.00 92.68
08:45:47 PM all 1.42 0.00 6.21 0.22 0.00 92.16
08:45:57 PM all 2.38 0.00 6.05 0.22 0.00 91.35
08:46:07 PM all 2.18 0.00 5.55 0.11 0.00 92.17
08:46:17 PM all 2.05 0.00 6.57 0.11 0.00 91.27
08:46:27 PM all 1.43 0.00 5.70 0.22 0.00 92.65
08:46:37 PM all 1.20 0.00 6.12 0.00 0.00 92.68
08:46:47 PM all 1.74 0.00 6.19 0.22 0.00 91.86
08:46:57 PM all 1.95 0.00 6.49 0.11 0.00 91.46
08:47:07 PM all 1.63 0.00 6.30 0.11 0.00 91.96
08:47:17 PM all 1.97 0.00 5.57 0.11 0.00 92.36
08:47:27 PM all 1.20 0.00 6.33 0.11 0.00 92.36
08:47:37 PM all 1.41 0.00 6.42 0.11 0.00 92.06
08:47:47 PM all 2.27 0.00 6.17 0.11 0.00 91.45
08:47:57 PM all 1.83 0.00 7.09 0.21 0.00 90.87
08:48:07 PM all 1.86 0.00 5.68 0.11 0.00 92.36
08:48:17 PM all 1.31 0.00 6.34 0.00 0.00 92.35
08:48:27 PM all 1.20 0.00 6.63 0.22 0.00 91.96
08:48:37 PM all 1.95 0.00 6.28 0.11 0.00 91.66
08:48:47 PM all 2.16 0.00 6.68 0.11 0.00 91.06
08:48:57 PM all 1.72 0.00 7.11 0.11 0.00 91.06
08:49:07 PM all 1.74 0.00 5.67 2.94 0.00 89.64
Average: all 1.74 0.00 6.23 0.24 0.00 91.80
08:44:07 PM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 blocked
08:44:17 PM 0 63 0.00 0.01 0.05 0
08:44:27 PM 0 63 0.00 0.01 0.05 0
08:44:37 PM 0 63 0.00 0.01 0.05 0
08:44:47 PM 0 63 0.00 0.01 0.05 0
08:44:57 PM 0 63 0.00 0.01 0.05 0
08:45:07 PM 0 63 0.00 0.01 0.05 0
08:45:17 PM 0 63 0.00 0.01 0.05 0
08:45:27 PM 0 63 0.00 0.01 0.05 0
08:45:37 PM 0 63 0.00 0.01 0.05 0
08:45:47 PM 0 63 0.00 0.01 0.05 0
08:45:57 PM 0 63 0.00 0.01 0.05 0
08:46:07 PM 0 63 0.00 0.01 0.05 0
08:46:17 PM 0 63 0.08 0.03 0.05 0
08:46:27 PM 0 63 0.07 0.03 0.05 0
08:46:37 PM 0 63 0.06 0.03 0.05 0
08:46:47 PM 0 63 0.05 0.03 0.05 0
08:46:57 PM 0 63 0.04 0.03 0.05 0
08:47:07 PM 0 63 0.04 0.03 0.05 0
08:47:17 PM 0 63 0.03 0.03 0.05 0
08:47:27 PM 0 63 0.03 0.02 0.05 0
08:47:37 PM 0 63 0.02 0.02 0.05 0
08:47:47 PM 0 63 0.02 0.02 0.05 0
08:47:57 PM 0 63 0.02 0.02 0.05 0
08:48:07 PM 0 63 0.01 0.02 0.05 0
08:48:17 PM 0 63 0.01 0.02 0.05 0
08:48:27 PM 0 63 0.01 0.02 0.05 0
08:48:37 PM 0 63 0.01 0.02 0.05 0
08:48:47 PM 0 63 0.01 0.02 0.05 0
08:48:57 PM 0 63 0.01 0.02 0.05 0
08:49:07 PM 0 63 0.00 0.01 0.05 0
Average: 0 63 0.02 0.02 0.05 0
ご覧の通り素晴らしい数値で、特にロードアベレージはほとんど待ちが発生していないことになりますから、凄いです。
yo 2013/10/11(Fri) 20:56 No.3604
Re: BeagleBone Black(7)
yo 2013/10/11(Fri) 21:00 No.3605
皆様
> >次は何でしょうねえ(^^;
> きっとyoさんがODROIDを。。。(^^;
ODROIDか次期alixか悩んでいるのですよね。BBBでarmアーキテクチャの難しさは痛感したので(^^;;;。
> >次は何でしょうねえ(^^;
> きっとyoさんがODROIDを。。。(^^;
ODROIDか次期alixか悩んでいるのですよね。BBBでarmアーキテクチャの難しさは痛感したので(^^;;;。
yo 2013/10/11(Fri) 21:00 No.3605
Re: BeagleBone Black(7)
syu 2013/10/12(Sat) 17:26 No.3606
tinkerさん
>>次は何でしょうねえ(^^;
>きっとyoさんがODROIDを。。。(^^;
ふーむ。音はどうでしょうかねえ。
やってみないとわかりませんからねえ。
yoさん
>ODROIDか次期alixか悩んでいる
昨晩、こんなのを見つけました。
http://i.imgur.com/712EXOx.jpg" target="_blank">http://i.imgur.com/712EXOx.jpg
次期alixは、早くても2014年の春ぐらいみたいですね。
先にODROID片付けとくのも手ですね(^^;;
私は、bbbで構成したhi/low-passフィルターボードにbbb-mpdからデータ渡して、bbbトロイカによるデジフィル・マルチチャンネルを、可能なら、やってみたいです。
うちのは2wayだし、それぞれのユニットは比較フラットな特性なので、相互干渉の少ないブリックウォールフィルタで継いでみたいのですよね。
>>次は何でしょうねえ(^^;
>きっとyoさんがODROIDを。。。(^^;
ふーむ。音はどうでしょうかねえ。
やってみないとわかりませんからねえ。
yoさん
>ODROIDか次期alixか悩んでいる
昨晩、こんなのを見つけました。
http://i.imgur.com/712EXOx.jpg" target="_blank">http://i.imgur.com/712EXOx.jpg
次期alixは、早くても2014年の春ぐらいみたいですね。
先にODROID片付けとくのも手ですね(^^;;
私は、bbbで構成したhi/low-passフィルターボードにbbb-mpdからデータ渡して、bbbトロイカによるデジフィル・マルチチャンネルを、可能なら、やってみたいです。
うちのは2wayだし、それぞれのユニットは比較フラットな特性なので、相互干渉の少ないブリックウォールフィルタで継いでみたいのですよね。
syu 2013/10/12(Sat) 17:26 No.3606
Re: BeagleBone Black(7)
syu 2013/10/12(Sat) 18:33 No.3607
皆様
cyclictestのビルドは比較的簡単でした。
準備
# selboot 3120ARCH
# pacman -Syu
余分な物もあるかもしれませんが、mpd-dsdなどがビルドできるbbb環境にします。
# pacman -S git make autoconf automake libtool pkg-config patch
pythonが必要です。
# pacman -S python
以下の通りで使えるようになります。
https://rt.wiki.kernel.org/index.php/Cyclictest" target="_blank">https://rt.wiki.kernel.org/index.php/Cyclictest
# git clone git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git
# cd rt-tests
# make all
# cp ./cyclictest /usr/bin/
# cyclictest --help
これで稼働を確認できれば成功です。
当たり前でしょうが、最大遅延時間とload averageは逆相関傾向ですね。
cyclictestのビルドは比較的簡単でした。
準備
# selboot 3120ARCH
# pacman -Syu
余分な物もあるかもしれませんが、mpd-dsdなどがビルドできるbbb環境にします。
# pacman -S git make autoconf automake libtool pkg-config patch
pythonが必要です。
# pacman -S python
以下の通りで使えるようになります。
https://rt.wiki.kernel.org/index.php/Cyclictest" target="_blank">https://rt.wiki.kernel.org/index.php/Cyclictest
# git clone git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git
# cd rt-tests
# make all
# cp ./cyclictest /usr/bin/
# cyclictest --help
これで稼働を確認できれば成功です。
当たり前でしょうが、最大遅延時間とload averageは逆相関傾向ですね。
syu 2013/10/12(Sat) 18:33 No.3607
Re: BeagleBone Black(7)
tinker 2013/10/12(Sat) 21:06 No.3608
syuさん
やってみました。
debiabでkernelは3.10.15+rt9です。cpuの能力によって随分変わってくるんですね。
[wandboard（i.mx6 1G*2）]
T: 0 ( 8179) P:99 I:10000 C: 5000 Min: 25 Act: 44 Avg: 38 Max: 79
T: 1 ( 8180) P:98 I:10500 C: 4762 Min: 27 Act: 41 Avg: 39 Max: 85
T: 2 ( 8181) P:97 I:11000 C: 4546 Min: 24 Act: 32 Avg: 37 Max: 93
T: 3 ( 8182) P:96 I:11500 C: 4348 Min: 25 Act: 39 Avg: 41 Max: 109
T: 4 ( 8183) P:95 I:12000 C: 4167 Min: 26 Act: 35 Avg: 42 Max: 91
T: 5 ( 8184) P:94 I:12500 C: 4000 Min: 25 Act: 34 Avg: 38 Max: 88
T: 6 ( 8185) P:93 I:13000 C: 3846 Min: 25 Act: 33 Avg: 38 Max: 74
T: 7 ( 8186) P:92 I:13500 C: 3704 Min: 25 Act: 40 Avg: 38 Max: 86
T: 8 ( 8187) P:91 I:14000 C: 3572 Min: 26 Act: 33 Avg: 39 Max: 87
T: 9 ( 8188) P:90 I:14500 C: 3448 Min: 26 Act: 47 Avg: 41 Max: 85
[xh61v（celeron G1610 1.6G*2）]
T: 0 ( 3988) P:99 I:10000 C: 5000 Min: 5 Act: 8 Avg: 9 Max: 17
T: 1 ( 3989) P:98 I:10500 C: 4762 Min: 4 Act: 7 Avg: 9 Max: 16
T: 2 ( 3990) P:97 I:11000 C: 4545 Min: 5 Act: 10 Avg: 9 Max: 16
T: 3 ( 3991) P:96 I:11500 C: 4348 Min: 5 Act: 9 Avg: 9 Max: 18
T: 4 ( 3992) P:95 I:12000 C: 4166 Min: 5 Act: 9 Avg: 9 Max: 18
T: 5 ( 3993) P:94 I:12500 C: 4000 Min: 5 Act: 9 Avg: 9 Max: 17
T: 6 ( 3994) P:93 I:13000 C: 3846 Min: 5 Act: 10 Avg: 9 Max: 17
T: 7 ( 3995) P:92 I:13500 C: 3703 Min: 5 Act: 8 Avg: 9 Max: 17
T: 8 ( 3996) P:91 I:14000 C: 3571 Min: 6 Act: 11 Avg: 9 Max: 17
T: 9 ( 3997) P:90 I:14500 C: 3448 Min: 6 Act: 11 Avg: 9 Max: 17
やってみました。
debiabでkernelは3.10.15+rt9です。cpuの能力によって随分変わってくるんですね。
[wandboard（i.mx6 1G*2）]
T: 0 ( 8179) P:99 I:10000 C: 5000 Min: 25 Act: 44 Avg: 38 Max: 79
T: 1 ( 8180) P:98 I:10500 C: 4762 Min: 27 Act: 41 Avg: 39 Max: 85
T: 2 ( 8181) P:97 I:11000 C: 4546 Min: 24 Act: 32 Avg: 37 Max: 93
T: 3 ( 8182) P:96 I:11500 C: 4348 Min: 25 Act: 39 Avg: 41 Max: 109
T: 4 ( 8183) P:95 I:12000 C: 4167 Min: 26 Act: 35 Avg: 42 Max: 91
T: 5 ( 8184) P:94 I:12500 C: 4000 Min: 25 Act: 34 Avg: 38 Max: 88
T: 6 ( 8185) P:93 I:13000 C: 3846 Min: 25 Act: 33 Avg: 38 Max: 74
T: 7 ( 8186) P:92 I:13500 C: 3704 Min: 25 Act: 40 Avg: 38 Max: 86
T: 8 ( 8187) P:91 I:14000 C: 3572 Min: 26 Act: 33 Avg: 39 Max: 87
T: 9 ( 8188) P:90 I:14500 C: 3448 Min: 26 Act: 47 Avg: 41 Max: 85
[xh61v（celeron G1610 1.6G*2）]
T: 0 ( 3988) P:99 I:10000 C: 5000 Min: 5 Act: 8 Avg: 9 Max: 17
T: 1 ( 3989) P:98 I:10500 C: 4762 Min: 4 Act: 7 Avg: 9 Max: 16
T: 2 ( 3990) P:97 I:11000 C: 4545 Min: 5 Act: 10 Avg: 9 Max: 16
T: 3 ( 3991) P:96 I:11500 C: 4348 Min: 5 Act: 9 Avg: 9 Max: 18
T: 4 ( 3992) P:95 I:12000 C: 4166 Min: 5 Act: 9 Avg: 9 Max: 18
T: 5 ( 3993) P:94 I:12500 C: 4000 Min: 5 Act: 9 Avg: 9 Max: 17
T: 6 ( 3994) P:93 I:13000 C: 3846 Min: 5 Act: 10 Avg: 9 Max: 17
T: 7 ( 3995) P:92 I:13500 C: 3703 Min: 5 Act: 8 Avg: 9 Max: 17
T: 8 ( 3996) P:91 I:14000 C: 3571 Min: 6 Act: 11 Avg: 9 Max: 17
T: 9 ( 3997) P:90 I:14500 C: 3448 Min: 6 Act: 11 Avg: 9 Max: 17
tinker 2013/10/12(Sat) 21:06 No.3608
Re: BeagleBone Black(7)
yo 2013/10/12(Sat) 21:30 No.3609
syuさん
> http://i.imgur.com/712EXOx.jpg" target="_blank">http://i.imgur.com/712EXOx.jpg
興味深く拝見しました。よさそうですね。これで、すんなり linux rtカーネルが動けば、文句なしです。
> 先にODROID片付けとくのも手ですね(^^;;
背中を押されそうだなぁ。どうしましょう(^^;;。
最悪、nasサーバには転用できそうだから、チャレンジしますかね。
> http://i.imgur.com/712EXOx.jpg" target="_blank">http://i.imgur.com/712EXOx.jpg
興味深く拝見しました。よさそうですね。これで、すんなり linux rtカーネルが動けば、文句なしです。
> 先にODROID片付けとくのも手ですね(^^;;
背中を押されそうだなぁ。どうしましょう(^^;;。
最悪、nasサーバには転用できそうだから、チャレンジしますかね。
yo 2013/10/12(Sat) 21:30 No.3609
Re: BeagleBone Black(7)
まさまさ 2013/10/15(Tue) 01:47 No.3610
syu さん
遅くなりました。
出張やら家族奉仕やらで、ようやく時間がとれました。
さすがですね、ついにノイズ無しで鳴るようになりましたね！
実は5V電源を自作でなくオーダしてしまいまして、両方合わせて現在にんまり中です♪
それで一つ質問なのですが、音源がそれしかなくて泣く泣く持っている mp3 のファイルなのですが、どうも読み込めていないみたいなのです。.mpdconf などの修正で読み込めるようになりますでしょうか？あとInternet Radio系のmms: や http:xxx/stream なども読み込めるようになると嬉しいのですが。
よろしくお願い致します。
遅くなりました。
出張やら家族奉仕やらで、ようやく時間がとれました。
さすがですね、ついにノイズ無しで鳴るようになりましたね！
実は5V電源を自作でなくオーダしてしまいまして、両方合わせて現在にんまり中です♪
それで一つ質問なのですが、音源がそれしかなくて泣く泣く持っている mp3 のファイルなのですが、どうも読み込めていないみたいなのです。.mpdconf などの修正で読み込めるようになりますでしょうか？あとInternet Radio系のmms: や http:xxx/stream なども読み込めるようになると嬉しいのですが。
よろしくお願い致します。
まさまさ 2013/10/15(Tue) 01:47 No.3610
Re: BeagleBone Black(7)
まさまさ 2013/10/15(Tue) 01:57 No.3611
ちなみに、192Khz flac ファイルで、0731nfp, 0731vkp, 0731lln で試して、すべてでパチ音が無いことを確認しています。
まさまさ 2013/10/15(Tue) 01:57 No.3611
Re: BeagleBone Black(7)
syu 2013/10/16(Wed) 19:26 No.3612
yoさん
>背中を押されそうだなぁ。どうしましょう(^^;;。
yoさんの背中を押すなど、恐れ多くて、できまっせん。(^^;
数周回の遅れですが、今頃になってPS3をダウングレードして、DSDのデータベースを整備しようかなと計画しています。E3何とかを手配したところです。そっちで手一杯になりそうで、後追いでのお供も思うに任せない可能性が・・・
>背中を押されそうだなぁ。どうしましょう(^^;;。
yoさんの背中を押すなど、恐れ多くて、できまっせん。(^^;
数周回の遅れですが、今頃になってPS3をダウングレードして、DSDのデータベースを整備しようかなと計画しています。E3何とかを手配したところです。そっちで手一杯になりそうで、後追いでのお供も思うに任せない可能性が・・・
syu 2013/10/16(Wed) 19:26 No.3612
Re: BeagleBone Black(7)
syu 2013/10/16(Wed) 19:56 No.3613
まさまささん
>0731nfp, 0731vkp, 0731lln で試して、すべてでパチ音が無い
yoさんの記事にもありますが、0731llnはyoさんの0731peと基本的には同じ物で、差は/drivers/usb/host/ehci-sched.cにパッチが当たっていることだけです。非リアルタイムカーネルなので安定です。0731nfpまですべて、rtoptパッチの当たったmpdを使用しconfigでrt優先度指定があっても問題なく動きます。
0807rtn同様、0731rtnでもダメなんじゃないかと思います。
> mp3 のファイルなのですが、どうも読み込めていない
ffmpegをenable指定するとmpdのコンパイルでエラーが出ますので、disable指定しています。
mpd-0.17.6が公開されていましたので、rtoptを当ててコンパイルしてみましたが、ffmpegのエラーはまだ修正されていませんでした。ご本家での修正待ちですかね。
>Internet Radio系のmms: や http:xxx/stream など
これは、私はやったことがないです。対策法をyoさんが前にどこかでお書きになっていた記憶があります。
>5V電源を自作でなくオーダ
を！良いですねえ。bbbは電源に敏感なようですからね。
>現在にんまり中です♪
かなり変わるでしょ♪
私は電圧を安定化し大まかなノイズをとる機器を入れ、そこからDDCとbbbのローノイズ電源アダプタに供給しています。DACやプリの電源もここから取ると、もっと効果的ですよ。
http://www.soundhouse.co.jp/shop/ProductDetail.asp?Item=233" target="_blank">http://www.soundhouse.co.jp/shop/ProductDetail.asp?Item=233^PDMR^^
http://www.soundhouse.co.jp/shop/ProductDetail.asp?Item=350" target="_blank">http://www.soundhouse.co.jp/shop/ProductDetail.asp?Item=350^AR1215J^^
皆様
先日公開されたmpd-0.17.6にrtoptを当て、mpd-dsd-0.17.5と比較してみました。
私の環境では、弦の高域のIM歪み様の着色が0.17.6rtの方が少なく、ハモリが分厚くなる印象です。皆さんのご意見はいかがでしょうか。
>0731nfp, 0731vkp, 0731lln で試して、すべてでパチ音が無い
yoさんの記事にもありますが、0731llnはyoさんの0731peと基本的には同じ物で、差は/drivers/usb/host/ehci-sched.cにパッチが当たっていることだけです。非リアルタイムカーネルなので安定です。0731nfpまですべて、rtoptパッチの当たったmpdを使用しconfigでrt優先度指定があっても問題なく動きます。
0807rtn同様、0731rtnでもダメなんじゃないかと思います。
> mp3 のファイルなのですが、どうも読み込めていない
ffmpegをenable指定するとmpdのコンパイルでエラーが出ますので、disable指定しています。
mpd-0.17.6が公開されていましたので、rtoptを当ててコンパイルしてみましたが、ffmpegのエラーはまだ修正されていませんでした。ご本家での修正待ちですかね。
>Internet Radio系のmms: や http:xxx/stream など
これは、私はやったことがないです。対策法をyoさんが前にどこかでお書きになっていた記憶があります。
>5V電源を自作でなくオーダ
を！良いですねえ。bbbは電源に敏感なようですからね。
>現在にんまり中です♪
かなり変わるでしょ♪
私は電圧を安定化し大まかなノイズをとる機器を入れ、そこからDDCとbbbのローノイズ電源アダプタに供給しています。DACやプリの電源もここから取ると、もっと効果的ですよ。
http://www.soundhouse.co.jp/shop/ProductDetail.asp?Item=233" target="_blank">http://www.soundhouse.co.jp/shop/ProductDetail.asp?Item=233^PDMR^^
http://www.soundhouse.co.jp/shop/ProductDetail.asp?Item=350" target="_blank">http://www.soundhouse.co.jp/shop/ProductDetail.asp?Item=350^AR1215J^^
皆様
先日公開されたmpd-0.17.6にrtoptを当て、mpd-dsd-0.17.5と比較してみました。
私の環境では、弦の高域のIM歪み様の着色が0.17.6rtの方が少なく、ハモリが分厚くなる印象です。皆さんのご意見はいかがでしょうか。
syu 2013/10/16(Wed) 19:56 No.3613
Re: BeagleBone Black(7)
tinker 2013/10/16(Wed) 22:43 No.3614
皆様
kernel.orgの3.12rc4でzImageを作ったのですが、bootしないです。
Nelsonさんの3.12rc4はbootするので、私の作り方が悪いのか何か足りないのか。
config見ていて気づいたのですが、USBがTI CPPI 4.1 (AM335x)ってのがデフォになってるみたいです。
これはDMAみたいなので、うまくいけばUSBはもっと安定するかもしれません。音が良くなるかどうかは聞いてみないと分かりませんが。
>yoさん
ODROID U2はもう発注したんですか？
以前から調べていて、3.8のrtソースが有ることは分かっているんですが、3.12についての情報が見当たらないんですよね。
kernel.orgの3.12rc4でzImageを作ったのですが、bootしないです。
Nelsonさんの3.12rc4はbootするので、私の作り方が悪いのか何か足りないのか。
config見ていて気づいたのですが、USBがTI CPPI 4.1 (AM335x)ってのがデフォになってるみたいです。
これはDMAみたいなので、うまくいけばUSBはもっと安定するかもしれません。音が良くなるかどうかは聞いてみないと分かりませんが。
>yoさん
ODROID U2はもう発注したんですか？
以前から調べていて、3.8のrtソースが有ることは分かっているんですが、3.12についての情報が見当たらないんですよね。
tinker 2013/10/16(Wed) 22:43 No.3614
Re: BeagleBone Black(7)
yo 2013/10/17(Thu) 19:23 No.3616
syuさん
> 数周回の遅れですが、...
僕は最新の状況は知らないのですが、何か必要なことがあれば、メールして下さい。
> 数周回の遅れですが、...
僕は最新の状況は知らないのですが、何か必要なことがあれば、メールして下さい。
yo 2013/10/17(Thu) 19:23 No.3616
Re: BeagleBone Black(7)
yo 2013/10/17(Thu) 19:24 No.3617
tinkerさん
> ODROID U2はもう発注したんですか？
まだ、グズグズと逡巡しております。ちょっとバタバタしていて、時間がとれないということもありますが。
今、調べたら、ODROID U2 の3.8rtカーネルは3.8.4なのですね。これだとDSD再生中断の問題は発生しない筈だから、また悩むなぁ(^^;;;。
> ODROID U2はもう発注したんですか？
まだ、グズグズと逡巡しております。ちょっとバタバタしていて、時間がとれないということもありますが。
今、調べたら、ODROID U2 の3.8rtカーネルは3.8.4なのですね。これだとDSD再生中断の問題は発生しない筈だから、また悩むなぁ(^^;;;。
yo 2013/10/17(Thu) 19:24 No.3617
Re: BeagleBone Black(7)
yo 2013/10/17(Thu) 19:25 No.3618
まさまささん
> Internet Radio系のmms: や http:xxx/stream など
mmsは--enable-mmsを指定してビルドする必要があります。httpdはenableになっているようなので、mpd.confの設定で使えるのではないでしょうか。僕はやったことがないので、分からないのですが、このページの
http://mpd.wikia.com/wiki/Configuration" target="_blank">http://mpd.wikia.com/wiki/Configuration
情報が参考になりませんか。
> Internet Radio系のmms: や http:xxx/stream など
mmsは--enable-mmsを指定してビルドする必要があります。httpdはenableになっているようなので、mpd.confの設定で使えるのではないでしょうか。僕はやったことがないので、分からないのですが、このページの
http://mpd.wikia.com/wiki/Configuration" target="_blank">http://mpd.wikia.com/wiki/Configuration
情報が参考になりませんか。
yo 2013/10/17(Thu) 19:25 No.3618
Re: BeagleBone Black(7)
まさまさ 2013/10/19(Sat) 03:28 No.3620
syu さん
安定化電源いいですね！
お小遣いをためて（涙）、買おう～
mp3 の件は、ffmpeg が入ってなかったのですね。なるほどです。
それから Internet Radio の件ですが、yo さんにアドバイスいただいたページを見て、いろいろやってみたのですが、再生できませんでした。
CuBox の時には再生できていたので、mpd.conf を見比べてもほとんど変わらないし、なんでだろうと思って調べていたら、もしかして ffmpeg が m3u ファイルの処理をしているのかな？と思い始めています。m3u っていうのは mp3 playlistのことのようなので。
そうなるとffmpegが入らないとだめかもしれませんね。
安定化電源いいですね！
お小遣いをためて（涙）、買おう～
mp3 の件は、ffmpeg が入ってなかったのですね。なるほどです。
それから Internet Radio の件ですが、yo さんにアドバイスいただいたページを見て、いろいろやってみたのですが、再生できませんでした。
CuBox の時には再生できていたので、mpd.conf を見比べてもほとんど変わらないし、なんでだろうと思って調べていたら、もしかして ffmpeg が m3u ファイルの処理をしているのかな？と思い始めています。m3u っていうのは mp3 playlistのことのようなので。
そうなるとffmpegが入らないとだめかもしれませんね。
まさまさ 2013/10/19(Sat) 03:28 No.3620
Re: BeagleBone Black(7)
twl 2013/10/22(Tue) 22:40 No.3621
twlです。
最近のこのスレッドを拝見しておりますと、皆様rtカーネルのビルド疲れというか、大体やることはやったというか、なんとなく静かな雰囲気で話題が流れているようですね。
ところで、先日BBB関連の3.1xカーネルの最近の進捗はどうかなとwww.eewiki.netを覗いてみましたら、3.12.0-rc関連のカーネルがようやくUSBをサポートするようになったらしいので、早速ビルドしてみました。
URL: http://www.eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-LinuxKernel" target="_blank">http://www.eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-LinuxKernel
出来上がったカーネルのもとでDebianおよびArchlinux上のmpd(それぞれ0.17.6および0.17.5、いずれもnon-rt)をI2S接続で試しましたが、両者ともPCM音源の再生についてはまったく問題ありませんでした。
root@arm:~# uname -a
Linux arm 3.12.0-rc6_BBB_1021-bone7 #1 SMP PREEMPT Mon Oct 21 18:41:20 JST 2013
[root@alarm ~]# uname -a
Linux alarm 3.12.0-rc6_BBB_1021-bone7 #1 SMP PREEMPT Mon Oct 21 18:41:20 JST 2013
Debianでは従来の3.8カーネル(non-rt)同様DSD128、DSD64ともにノイズなしで問題なく再生できました。主観の域を出ませんが、音質についてはきわめて満足できる状況です。
Archlinuxでは3.8カーネルでの不快なノイズが消えることを期待しましたが、DSD128、DSD64のいずれにおいても従来通りのノイズが再生時に出現、解決には至りませんでした。
両者とも音源はNAS経由のcifsマウントですが、3.8カーネルでの書式と異なり、/etc/fstabで記述したiocharset=utf8が何故か認識してもらえず、この部分はiocharset=iso8859-1と変更することで解決させました。MpodやMpad上での日本語表示には問題ありません。
他力本願の情けない状況ですが、それでもしばらく我慢していると3.1xでのrtカーネルがビルド可能になる日がやってくるに違いないと考えております。皆様、今後ともよろしくお願いいたします。
ちなみにCubox上ではRT_FULLの3.10.15-rt11カーネルが安定稼働中です。
最近のこのスレッドを拝見しておりますと、皆様rtカーネルのビルド疲れというか、大体やることはやったというか、なんとなく静かな雰囲気で話題が流れているようですね。
ところで、先日BBB関連の3.1xカーネルの最近の進捗はどうかなとwww.eewiki.netを覗いてみましたら、3.12.0-rc関連のカーネルがようやくUSBをサポートするようになったらしいので、早速ビルドしてみました。
URL: http://www.eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-LinuxKernel" target="_blank">http://www.eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-LinuxKernel
出来上がったカーネルのもとでDebianおよびArchlinux上のmpd(それぞれ0.17.6および0.17.5、いずれもnon-rt)をI2S接続で試しましたが、両者ともPCM音源の再生についてはまったく問題ありませんでした。
root@arm:~# uname -a
Linux arm 3.12.0-rc6_BBB_1021-bone7 #1 SMP PREEMPT Mon Oct 21 18:41:20 JST 2013
[root@alarm ~]# uname -a
Linux alarm 3.12.0-rc6_BBB_1021-bone7 #1 SMP PREEMPT Mon Oct 21 18:41:20 JST 2013
Debianでは従来の3.8カーネル(non-rt)同様DSD128、DSD64ともにノイズなしで問題なく再生できました。主観の域を出ませんが、音質についてはきわめて満足できる状況です。
Archlinuxでは3.8カーネルでの不快なノイズが消えることを期待しましたが、DSD128、DSD64のいずれにおいても従来通りのノイズが再生時に出現、解決には至りませんでした。
両者とも音源はNAS経由のcifsマウントですが、3.8カーネルでの書式と異なり、/etc/fstabで記述したiocharset=utf8が何故か認識してもらえず、この部分はiocharset=iso8859-1と変更することで解決させました。MpodやMpad上での日本語表示には問題ありません。
他力本願の情けない状況ですが、それでもしばらく我慢していると3.1xでのrtカーネルがビルド可能になる日がやってくるに違いないと考えております。皆様、今後ともよろしくお願いいたします。
ちなみにCubox上ではRT_FULLの3.10.15-rt11カーネルが安定稼働中です。
twl 2013/10/22(Tue) 22:40 No.3621
Re: BeagleBone Black(7)
tinker 2013/10/23(Wed) 23:21 No.3622
twlさん
Nelsonさんとこの3.12rcxはちゃんと動きますね。
上の方は綺麗ですが、低域はまだ少し緩いって感じですね。
こちらだけかもしれないですが、ちょっと不具合があって、3.8.13では問題ないのですが、3.12.rc5，rc6ではapt-get upgradeが失敗します。
>iocharset=iso8859-1と変更することで解決させました
多分、Native language supportでUTF-8が組み込まれていないからだと思われます。
{*} NLS UTF-8としてkernelを作りなおしてみてください。
kernel.orgの3.12rcxでのbootは、まだ成功していません。
まだ2ヶ月くらい余裕があるので、それまでにboot出来ればいいのですが。
Nelsonさんとこの3.12rcxはちゃんと動きますね。
上の方は綺麗ですが、低域はまだ少し緩いって感じですね。
こちらだけかもしれないですが、ちょっと不具合があって、3.8.13では問題ないのですが、3.12.rc5，rc6ではapt-get upgradeが失敗します。
>iocharset=iso8859-1と変更することで解決させました
多分、Native language supportでUTF-8が組み込まれていないからだと思われます。
{*} NLS UTF-8としてkernelを作りなおしてみてください。
kernel.orgの3.12rcxでのbootは、まだ成功していません。
まだ2ヶ月くらい余裕があるので、それまでにboot出来ればいいのですが。
tinker 2013/10/23(Wed) 23:21 No.3622
Re: BeagleBone Black(7)
twl 2013/10/24(Thu) 00:58 No.3623
twlです。tinkerさん、アドバイスありがとうございました。
> 上の方は綺麗ですが、低域はまだ少し緩いって感じですね。
これはdebian、archlinuxのどちらでしょうか。Debianですと高域、低域とも比較的バランスがとれている印象を受けますが、確かにarchlinuxですとご指摘の様に低域の表現に甘さを感じますね。それに加え、archlinuxでは他のプロセスによる負荷が加わると、途端にチリチリと細かなノイズが乗ってくることに気付きました。
>> iocharset=iso8859-1と変更することで解決させました
> 多分、Native language supportでUTF-8が組み込まれていないからだと思われます。
> {*} NLS UTF-8としてkernelを作りなおしてみてください。
ご指摘ありがとうございました。.configを見直したら確かに# CONFIG_NLS_UTF8 is not setとなっていました。githubだと./build_kernel.shでほぼ半自動でカーネルをビルドしてくれるので、これはお気楽と思っていた自分に甘さがありました。再度ビルドしてみます。
> 上の方は綺麗ですが、低域はまだ少し緩いって感じですね。
これはdebian、archlinuxのどちらでしょうか。Debianですと高域、低域とも比較的バランスがとれている印象を受けますが、確かにarchlinuxですとご指摘の様に低域の表現に甘さを感じますね。それに加え、archlinuxでは他のプロセスによる負荷が加わると、途端にチリチリと細かなノイズが乗ってくることに気付きました。
>> iocharset=iso8859-1と変更することで解決させました
> 多分、Native language supportでUTF-8が組み込まれていないからだと思われます。
> {*} NLS UTF-8としてkernelを作りなおしてみてください。
ご指摘ありがとうございました。.configを見直したら確かに# CONFIG_NLS_UTF8 is not setとなっていました。githubだと./build_kernel.shでほぼ半自動でカーネルをビルドしてくれるので、これはお気楽と思っていた自分に甘さがありました。再度ビルドしてみます。
twl 2013/10/24(Thu) 00:58 No.3623
Re: BeagleBone Black(7)
tinker 2013/10/24(Thu) 23:05 No.3624
twlさん
>これはdebian、archlinuxのどちらでしょうか
debian＋（mpd-dsd＋rtop）です。
最近Archの保守がめんどくさくなって^^;
少し緩いと感じたのは、同条件で3.8-rtと比べた場合です。
好みの範囲だと思いますが、個人的にはもう少し締めたいです。
>これはdebian、archlinuxのどちらでしょうか
debian＋（mpd-dsd＋rtop）です。
最近Archの保守がめんどくさくなって^^;
少し緩いと感じたのは、同条件で3.8-rtと比べた場合です。
好みの範囲だと思いますが、個人的にはもう少し締めたいです。
tinker 2013/10/24(Thu) 23:05 No.3624
Re: BeagleBone Black(7)
nakanaka 2013/10/30(Wed) 14:03 No.3625
nakanakaです。
voyage muboxが、BeagleBone Balckをサポートしていました。２８日にアップされていたので、インストールに挑戦しましたが、起動できていません。
Cubieboard2版は、問題なくインストールできて、音がでています。
以上、報告です。
voyage muboxが、BeagleBone Balckをサポートしていました。２８日にアップされていたので、インストールに挑戦しましたが、起動できていません。
Cubieboard2版は、問題なくインストールできて、音がでています。
以上、報告です。
nakanaka 2013/10/30(Wed) 14:03 No.3625
Re: BeagleBone Black(7)
syu 2013/10/30(Wed) 21:43 No.3626
nakanakaさん、情報ありがとうございます。
ちょっとだけ見てみました。
一部変更して、とりあえず起動は出来ましたが、その後の設定はまだです。
○ install-mubox-beaglebone.shのパーミッション変更が必要でした。
○ install-mubox-beaglebone.shの中を見たら、syncとumountの順序が3ヶ所ほど変な気が(^^;;
順序を入れ替えたらスクリプトは終わりまで走りました。
umount ${mntpt}
sync
となっている所を入れ替えました
sync
umount ${mntpt}
これでとりあえず起動はできました。
root@voyage-mubox:~# uname -a
Linux voyage-mubox 3.12.0-rc2-1-ARCH #1 SMP Wed Sep 25 17:23:54 CDT 2013 armv7l GNU/Linux
まだあちこち修正が必要みたいですが、ボチボチやってみますかね。
https://plus.google.com/107906919028234849442/posts" target="_blank">https://plus.google.com/107906919028234849442/posts
こっちには公開されていないので、未完成な段階なんでしょうか。
追記
10-31にgoogle+にも記事が出ましたが、内容は同じでした。
iocharset=utf8が通らないし、サウンドカードも認識されませんね。
ちょっとだけ見てみました。
一部変更して、とりあえず起動は出来ましたが、その後の設定はまだです。
○ install-mubox-beaglebone.shのパーミッション変更が必要でした。
○ install-mubox-beaglebone.shの中を見たら、syncとumountの順序が3ヶ所ほど変な気が(^^;;
順序を入れ替えたらスクリプトは終わりまで走りました。
umount ${mntpt}
sync
となっている所を入れ替えました
sync
umount ${mntpt}
これでとりあえず起動はできました。
root@voyage-mubox:~# uname -a
Linux voyage-mubox 3.12.0-rc2-1-ARCH #1 SMP Wed Sep 25 17:23:54 CDT 2013 armv7l GNU/Linux
まだあちこち修正が必要みたいですが、ボチボチやってみますかね。
https://plus.google.com/107906919028234849442/posts" target="_blank">https://plus.google.com/107906919028234849442/posts
こっちには公開されていないので、未完成な段階なんでしょうか。
追記
10-31にgoogle+にも記事が出ましたが、内容は同じでした。
iocharset=utf8が通らないし、サウンドカードも認識されませんね。
syu 2013/10/30(Wed) 21:43 No.3626
Re: BeagleBone Black(7)
twl 2013/10/31(Thu) 21:38 No.3627
twlです。
> voyage muboxが、BeagleBone Balckをサポートしていました。２８日にアップされていたので、
> インストールに挑戦しましたが、起動できていません。
情報のご提供ありがとうございました。ダウンロード先からbootloaderとrootfsのファイルをmicroSDにコピー、/etc関係の設定をあらかじめ自分の環境に書き換えた後でSDカードをBBBに挿入するだけで問題なく起動しました。
起動はしましたがcifs経由でマウントされるはずのnasがcifsエラーとなりマウントされず、実際のvoyageサウンドを聞く事ができませんでした。
zcat /proc/config.gzでチェックするとcifsはmoduleとして設定されているので、このマウントエラーに納得がいかず、githubのlinux-dev経由で先日ビルドしていた、より新しい3.12.0-rc7のカーネルに入れ替えて再起動しましたら、nasは問題なくcifsマウントされvoyage mpd (0.18~git)が動きました。Voyage側でのカーネルビルドの設定に課題が残る印象です。
再生音質ですが、BBB上のarchlinuxおよびdebian同様、pcmの再生に関しては問題はありませんでした。ただしvoyage mpdの音質に特に優越性はないと思われました。あくまでも私見です。
DSD再生に関しては3.8.13-rtのカーネル同様、64fs、128fsの双方の音源ソースともノイズまみれ、使い物になりません。3.12.0-rc7のカーネルで走るdebian上のmpdの方が安定しています。もっともDSD再生に関しては、私の環境ではrtなしの3.8.13 (bone28)カーネルが一番安定している印象ですが。
以上、報告でした。
> voyage muboxが、BeagleBone Balckをサポートしていました。２８日にアップされていたので、
> インストールに挑戦しましたが、起動できていません。
情報のご提供ありがとうございました。ダウンロード先からbootloaderとrootfsのファイルをmicroSDにコピー、/etc関係の設定をあらかじめ自分の環境に書き換えた後でSDカードをBBBに挿入するだけで問題なく起動しました。
起動はしましたがcifs経由でマウントされるはずのnasがcifsエラーとなりマウントされず、実際のvoyageサウンドを聞く事ができませんでした。
zcat /proc/config.gzでチェックするとcifsはmoduleとして設定されているので、このマウントエラーに納得がいかず、githubのlinux-dev経由で先日ビルドしていた、より新しい3.12.0-rc7のカーネルに入れ替えて再起動しましたら、nasは問題なくcifsマウントされvoyage mpd (0.18~git)が動きました。Voyage側でのカーネルビルドの設定に課題が残る印象です。
再生音質ですが、BBB上のarchlinuxおよびdebian同様、pcmの再生に関しては問題はありませんでした。ただしvoyage mpdの音質に特に優越性はないと思われました。あくまでも私見です。
DSD再生に関しては3.8.13-rtのカーネル同様、64fs、128fsの双方の音源ソースともノイズまみれ、使い物になりません。3.12.0-rc7のカーネルで走るdebian上のmpdの方が安定しています。もっともDSD再生に関しては、私の環境ではrtなしの3.8.13 (bone28)カーネルが一番安定している印象ですが。
以上、報告でした。
twl 2013/10/31(Thu) 21:38 No.3627
Re: BeagleBone Black(7)
syu 2013/11/04(Mon) 01:11 No.3628
mpd-0.17.5-dsdが5日ほど前に更新されていましたので、rtoptパッチを当ててコンパイルしてみました。
ここ↓に置いてますので、ご検証よろしく。
https://drive.google.com/file/d/0B1n2sZGxAleMcndjdEtzUzhhcVU/edit?usp=sharing" target="_blank">https://drive.google.com/file/d/0B1n2sZGxAleMcndjdEtzUzhhcVU/edit?usp=sharing
私の環境では、従来は曲の終端でOSまで巻き込んでクラッシュしていた2Lのdsd128ファイルが、この版では難なく再生できました。
dsd128再生中のtopは凄いことになってますが、ノイズの無い良い音で聴けます。
(追記 dsd128を長時間継続再生していると、ブチ、ブチ、ってノイズが出始めました）
Linux emmc-arch-mpd-dsd 3.8.13-rt9_0722kai-patched-00899-gc6c9946-dirty #3 SMP PREEMPT Mon Oct 7 18:52:59 JST 2013 armv7l GNU/Linux
top - 01:09:42 up 34 min, 1 user, load average: 0.84, 0.77, 0.62
Tasks: 69 total, 1 running, 68 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.6 us, 24.0 sy, 0.0 ni, 70.3 id, 0.0 wa, 0.0 hi, 2.2 si, 0.0 st
KiB Mem: 513292 total, 370748 used, 142544 free, 2380 buffers
KiB Swap: 0 total, 0 used, 0 free, 305972 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 15.8 0.0 5:01.10 irq/35-musb+
225 root -54 0 61332 58420 13940 S 5.3 11.4 1:21.15 mpd
78 root -54 0 0 0 0 S 3.9 0.0 1:02.44 irq/57-4a10+
262 root -54 0 0 0 0 S 3.9 0.0 0:57.97 cifsd
421 root 20 0 4612 1276 1008 R 0.7 0.2 0:00.66 top
40 root 20 0 0 0 0 S 0.3 0.0 0:02.31 kswapd0
79 root -51 0 0 0 0 S 0.3 0.0 0:08.90 irq/58-4a10+
2Lのtest filesはこちら。
http://www.2l.no/hires/" target="_blank">http://www.2l.no/hires/
Stereo DXD 24BIT/352.8kHzに挑戦してみたいですね。
ここ↓に置いてますので、ご検証よろしく。
https://drive.google.com/file/d/0B1n2sZGxAleMcndjdEtzUzhhcVU/edit?usp=sharing" target="_blank">https://drive.google.com/file/d/0B1n2sZGxAleMcndjdEtzUzhhcVU/edit?usp=sharing
私の環境では、従来は曲の終端でOSまで巻き込んでクラッシュしていた2Lのdsd128ファイルが、この版では難なく再生できました。
dsd128再生中のtopは凄いことになってますが、ノイズの無い良い音で聴けます。
(追記 dsd128を長時間継続再生していると、ブチ、ブチ、ってノイズが出始めました）
Linux emmc-arch-mpd-dsd 3.8.13-rt9_0722kai-patched-00899-gc6c9946-dirty #3 SMP PREEMPT Mon Oct 7 18:52:59 JST 2013 armv7l GNU/Linux
top - 01:09:42 up 34 min, 1 user, load average: 0.84, 0.77, 0.62
Tasks: 69 total, 1 running, 68 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.6 us, 24.0 sy, 0.0 ni, 70.3 id, 0.0 wa, 0.0 hi, 2.2 si, 0.0 st
KiB Mem: 513292 total, 370748 used, 142544 free, 2380 buffers
KiB Swap: 0 total, 0 used, 0 free, 305972 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 15.8 0.0 5:01.10 irq/35-musb+
225 root -54 0 61332 58420 13940 S 5.3 11.4 1:21.15 mpd
78 root -54 0 0 0 0 S 3.9 0.0 1:02.44 irq/57-4a10+
262 root -54 0 0 0 0 S 3.9 0.0 0:57.97 cifsd
421 root 20 0 4612 1276 1008 R 0.7 0.2 0:00.66 top
40 root 20 0 0 0 0 S 0.3 0.0 0:02.31 kswapd0
79 root -51 0 0 0 0 S 0.3 0.0 0:08.90 irq/58-4a10+
2Lのtest filesはこちら。
http://www.2l.no/hires/" target="_blank">http://www.2l.no/hires/
Stereo DXD 24BIT/352.8kHzに挑戦してみたいですね。
syu 2013/11/04(Mon) 01:11 No.3628
Re: BeagleBone Black(7)
yo 2013/11/04(Mon) 22:05 No.3629
syuさん
情報ありがとうございます。cubox-archで試してみました。
Linux cubox 3.10.10-rt7_CuboxAudioRTunedDeadline #7 PREEMPT RT Tue Sep 24 23:42:53 PDT 2013 armv7l GNU/Linux
top - 18:12:50 up 6 min, 1 user, load average: 0.18, 0.46, 0.25
Tasks: 71 total, 1 running, 70 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.4 us, 8.0 sy, 0.0 ni, 86.7 id, 0.0 wa, 0.0 hi, 2.8 si, 0.0 st
KiB Mem: 1032676 total, 465492 used, 567184 free, 5328 buffers
KiB Swap: 0 total, 0 used, 0 free, 327096 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
68 root -55 0 0 0 0 S 8.212 0.000 0:27.24 irq/24-ehci_hcd
235 root -56 0 0 0 0 S 3.285 0.000 0:11.67 irq/29-eth0
392 mpd 20 0 81044 19100 2724 S 2.956 1.850 0:12.56 mpd
14 root -61 0 0 0 0 S 1.314 0.000 0:04.75 kworker/0:1
という状況ですが、mpdのcpu負荷の差は気になりますね。こちらでは音に問題は無しです。
情報ありがとうございます。cubox-archで試してみました。
Linux cubox 3.10.10-rt7_CuboxAudioRTunedDeadline #7 PREEMPT RT Tue Sep 24 23:42:53 PDT 2013 armv7l GNU/Linux
top - 18:12:50 up 6 min, 1 user, load average: 0.18, 0.46, 0.25
Tasks: 71 total, 1 running, 70 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.4 us, 8.0 sy, 0.0 ni, 86.7 id, 0.0 wa, 0.0 hi, 2.8 si, 0.0 st
KiB Mem: 1032676 total, 465492 used, 567184 free, 5328 buffers
KiB Swap: 0 total, 0 used, 0 free, 327096 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
68 root -55 0 0 0 0 S 8.212 0.000 0:27.24 irq/24-ehci_hcd
235 root -56 0 0 0 0 S 3.285 0.000 0:11.67 irq/29-eth0
392 mpd 20 0 81044 19100 2724 S 2.956 1.850 0:12.56 mpd
14 root -61 0 0 0 0 S 1.314 0.000 0:04.75 kworker/0:1
という状況ですが、mpdのcpu負荷の差は気になりますね。こちらでは音に問題は無しです。
yo 2013/11/04(Mon) 22:05 No.3629
Re: BeagleBone Black(7)
syu 2013/11/06(Wed) 19:35 No.3630
mpd-dsd、早くも0.17.6になってます。次は1か月ほどで0.18.xでしょうか。
0.17.6まではrtoptパッチの有無でかなり差がつきますが、mpd-0.18.x-dsdだと18git用パッチでは無理。ご本家の0.18.1stableにも、当然ですが、yanさんの18git用パッチは適用できませんでした。どうしますかね。自力でやるべきなんでしょうが (^^;
0.17.6まではrtoptパッチの有無でかなり差がつきますが、mpd-0.18.x-dsdだと18git用パッチでは無理。ご本家の0.18.1stableにも、当然ですが、yanさんの18git用パッチは適用できませんでした。どうしますかね。自力でやるべきなんでしょうが (^^;
syu 2013/11/06(Wed) 19:35 No.3630
Re: BeagleBone Black(7)
yo 2013/11/07(Thu) 21:29 No.3631
syuさん
> どうしますかね。自力でやるべきなんでしょうが (^^;
以前
http://www.symphonic-net.com/kubotayo/cgi-bin/read.cgi?mode=all&list=topic&no=3509#3521" target="_blank">http://www.symphonic-net.com/kubotayo/cgi-bin/read.cgi?mode=all&list=topic&no=3509#3521
に書いた方法で、mpdのプロセス毎の優先度はシェルスクリプトを使い、立ち上げ時に自動的に指定できます。
sedのスクリプトの内容を解説すると、最初の
/\/usr\/local\/bin\/mpd/
は/usr/local/bin/mpdという行を捜し、一致したら
Nというコマンドでその後の4行をバッファに読み込み
s/...../..../
という行でプロセス番号をつかみ、「chrt -f -p rt優先度 プロセス番号」に変換しています。
/usr/local/bin/mpdの並びは (main) player decoder output だと思います。
優先度を変えたければ、52、49、53 という部分を変更すればいいです。
> どうしますかね。自力でやるべきなんでしょうが (^^;
以前
http://www.symphonic-net.com/kubotayo/cgi-bin/read.cgi?mode=all&list=topic&no=3509#3521" target="_blank">http://www.symphonic-net.com/kubotayo/cgi-bin/read.cgi?mode=all&list=topic&no=3509#3521
に書いた方法で、mpdのプロセス毎の優先度はシェルスクリプトを使い、立ち上げ時に自動的に指定できます。
sedのスクリプトの内容を解説すると、最初の
/\/usr\/local\/bin\/mpd/
は/usr/local/bin/mpdという行を捜し、一致したら
Nというコマンドでその後の4行をバッファに読み込み
s/...../..../
という行でプロセス番号をつかみ、「chrt -f -p rt優先度 プロセス番号」に変換しています。
/usr/local/bin/mpdの並びは (main) player decoder output だと思います。
優先度を変えたければ、52、49、53 という部分を変更すればいいです。
yo 2013/11/07(Thu) 21:29 No.3631
Re: BeagleBone Black(7)
tinker 2013/11/08(Fri) 19:22 No.3632
>syuさん
もう0.18.1が出ているんですね。確かにrtopのパッチが当たりませんね。
>yoさん
3.10.xでmpdにrtopパッチを当てた場合の問題は、もうすぐ解決するかもしれません。
http://marc.info/?l=linux-rt-users&m=138322846828845&w=2" target="_blank">http://marc.info/?l=linux-rt-users&m=138322846828845&w=2
上記パッチのみ当てて試したところ、完璧ではないですが随分ましになりました。
上記スレッドでは、他ファイルに対してのパッチも上げられてるようです。
公式kernelの3.12は、BBBでは未だにboot出来ずです。
ここでもboot出来ていないようなので、kernelソースの問題みたいです。
http://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Testing/Fedora_21" target="_blank">http://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Testing/Fedora_21
もう0.18.1が出ているんですね。確かにrtopのパッチが当たりませんね。
>yoさん
3.10.xでmpdにrtopパッチを当てた場合の問題は、もうすぐ解決するかもしれません。
http://marc.info/?l=linux-rt-users&m=138322846828845&w=2" target="_blank">http://marc.info/?l=linux-rt-users&m=138322846828845&w=2
上記パッチのみ当てて試したところ、完璧ではないですが随分ましになりました。
上記スレッドでは、他ファイルに対してのパッチも上げられてるようです。
公式kernelの3.12は、BBBでは未だにboot出来ずです。
ここでもboot出来ていないようなので、kernelソースの問題みたいです。
http://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Testing/Fedora_21" target="_blank">http://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Testing/Fedora_21
tinker 2013/11/08(Fri) 19:22 No.3632
Re: BeagleBone Black(7)
tinker 2013/11/10(Sun) 10:24 No.3634
昨日、某掲示板を読んでいたら”lightMPD”というものを見つけました。
https://sites.google.com/site/digififan/" target="_blank">https://sites.google.com/site/digififan/
BeagleBone及びBeagleBone Black対応だそうです。
特徴は、以下のようです。
・romfsで軽い（らしい。未確認）
・3.8-rt
・mpd-dsd 0.17.5 ＋ yanさんのrtパッチ
・dsdの再生も問題なく出来る（らしい。確認できません^^;）
少し使ってみた感想です。
・bootボタン押さなくてもbootします。
・音は良いと思います。ただ私の環境だとDSDの再生環境も無いので、自分で整えたものとの差は感じません（CFQなのかな）
・mpd.confではmixer_type "disabled"となっているので、このままであれば特に不具合はありません。ただしsoftwareに変更する場合は、音量がMAXにならない、またはミュートで音が出ないということもあるかもしれません。また、mixer_typeの行が2行あるので注意が必要（片方はコメントにするか削除で問題なし）
・ネットラジオは、今のところhttp，mmsは使えませんでした。
・sshが使えない（シリアルコンソールは使えるらしいです。ケース分解が面倒なので試してません）ので、実行時の負荷はどうなっているのか分かりません。
uInitrdをバラしてみました。
libcが2.15なのでDebianなのかな？
中を確認したところ、chrt -f -p 99 `pgrep irq/35-musb-hdr`のみ設定されており、eth0部の指定はないようです。
自分でbuildしたmpdと差し替えてみましたが、mpdの起動は出来ませんでした。環境が違うので、何かライブラリが足りないのかもしれません。
シリアル繋げば確認できると思いますが、面倒なのでやってません。
https://sites.google.com/site/digififan/" target="_blank">https://sites.google.com/site/digififan/
BeagleBone及びBeagleBone Black対応だそうです。
特徴は、以下のようです。
・romfsで軽い（らしい。未確認）
・3.8-rt
・mpd-dsd 0.17.5 ＋ yanさんのrtパッチ
・dsdの再生も問題なく出来る（らしい。確認できません^^;）
少し使ってみた感想です。
・bootボタン押さなくてもbootします。
・音は良いと思います。ただ私の環境だとDSDの再生環境も無いので、自分で整えたものとの差は感じません（CFQなのかな）
・mpd.confではmixer_type "disabled"となっているので、このままであれば特に不具合はありません。ただしsoftwareに変更する場合は、音量がMAXにならない、またはミュートで音が出ないということもあるかもしれません。また、mixer_typeの行が2行あるので注意が必要（片方はコメントにするか削除で問題なし）
・ネットラジオは、今のところhttp，mmsは使えませんでした。
・sshが使えない（シリアルコンソールは使えるらしいです。ケース分解が面倒なので試してません）ので、実行時の負荷はどうなっているのか分かりません。
uInitrdをバラしてみました。
libcが2.15なのでDebianなのかな？
中を確認したところ、chrt -f -p 99 `pgrep irq/35-musb-hdr`のみ設定されており、eth0部の指定はないようです。
自分でbuildしたmpdと差し替えてみましたが、mpdの起動は出来ませんでした。環境が違うので、何かライブラリが足りないのかもしれません。
シリアル繋げば確認できると思いますが、面倒なのでやってません。
tinker 2013/11/10(Sun) 10:24 No.3634
Re: BeagleBone Black(7)
yoさん、みなさん はじめまして
今までずっとROMしていました。８月ごろからBBBを使っています。それ以前は古いPC（Pen3）にVoyageMPDでした。
dsdの再生環境がないので、wav・flacをyoさんやsyuさんのimgで楽しませていただいています。
voyage muboxをインストールしてみました。（No.3626 のsyuさんの方法でです。）
カーネルを以前syuさんが公開されたArchのimgの0731tinkerに入れ替え、rtset,confの内容をrc.localにコピーして再起動しました。
音の出方が明らかに違って聴こえます。非常に好ましい変化に私は聴こえます。
ぜひ皆さんに聴いていただきたいと思います。
今までずっとROMしていました。８月ごろからBBBを使っています。それ以前は古いPC（Pen3）にVoyageMPDでした。
dsdの再生環境がないので、wav・flacをyoさんやsyuさんのimgで楽しませていただいています。
voyage muboxをインストールしてみました。（No.3626 のsyuさんの方法でです。）
カーネルを以前syuさんが公開されたArchのimgの0731tinkerに入れ替え、rtset,confの内容をrc.localにコピーして再起動しました。
音の出方が明らかに違って聴こえます。非常に好ましい変化に私は聴こえます。
ぜひ皆さんに聴いていただきたいと思います。
Re: BeagleBone Black(7)
twl 2013/11/11(Mon) 01:12 No.3636
twlです。tinkerさん wrote:
> もう0.18.1が出ているんですね。確かにrtopのパッチが当たりませんね。
現在は0.18.3ですか。pacman -S mpdでインストールされることをどなたかが書かれていた記憶があるのですが、出自を失念しました。でもこのversionではDSD128のファイルが再生できず、変だなと思っていましたら、128fsのdsdiffをdecodeできないバグがあることをJurgenさんが指摘、ほどなくそれに対するパッチが御本人から提供されており*、これを0.18.3のソースにあててコンパイルしてみたら問題なくDSD128のファイルが再生できました。Archlinuxでのffmpegの問題も解決されており、新しい安定板として使えそうです。ただしdebianと異なり、ArchlinuxでのDSD128の再生では相変わらずノイズが乗ります。
* http://blog.gmane.org/gmane.comp.audio.musicpd.devel" target="_blank">http://blog.gmane.org/gmane.comp.audio.musicpd.devel
> 公式kernelの3.12は、BBBでは未だにboot出来ずです。
お、もう公式kernelなのかと、私もビルドしてみましたが(3.12.0-armv7-devel-r5)、RT_FULL指定の3.8.13-rtカーネル同様、ビルド自体はできるものの、BBBではLEDの点滅が途中で固まり、それ以上に進まないですね。他力本願で気長に待つことにします。
ところで皆様に教えていただきたいことがあります。BBBでのarchlinux用のrtset.confの書式の詳細を知りたいのですが、よろしくご指導下さい。cifsマウントの環境です。
> もう0.18.1が出ているんですね。確かにrtopのパッチが当たりませんね。
現在は0.18.3ですか。pacman -S mpdでインストールされることをどなたかが書かれていた記憶があるのですが、出自を失念しました。でもこのversionではDSD128のファイルが再生できず、変だなと思っていましたら、128fsのdsdiffをdecodeできないバグがあることをJurgenさんが指摘、ほどなくそれに対するパッチが御本人から提供されており*、これを0.18.3のソースにあててコンパイルしてみたら問題なくDSD128のファイルが再生できました。Archlinuxでのffmpegの問題も解決されており、新しい安定板として使えそうです。ただしdebianと異なり、ArchlinuxでのDSD128の再生では相変わらずノイズが乗ります。
* http://blog.gmane.org/gmane.comp.audio.musicpd.devel" target="_blank">http://blog.gmane.org/gmane.comp.audio.musicpd.devel
> 公式kernelの3.12は、BBBでは未だにboot出来ずです。
お、もう公式kernelなのかと、私もビルドしてみましたが(3.12.0-armv7-devel-r5)、RT_FULL指定の3.8.13-rtカーネル同様、ビルド自体はできるものの、BBBではLEDの点滅が途中で固まり、それ以上に進まないですね。他力本願で気長に待つことにします。
ところで皆様に教えていただきたいことがあります。BBBでのarchlinux用のrtset.confの書式の詳細を知りたいのですが、よろしくご指導下さい。cifsマウントの環境です。
twl 2013/11/11(Mon) 01:12 No.3636
Re: BeagleBone Black(7)
tinker 2013/11/11(Mon) 20:58 No.3638
皆様
3.12.0＋rt1を作成しました。今回はFull RTです。
UPしましたので、よろしければ検証お願いします。
CDripのFlacのみ確認しました。音はVer.1ということで^^;
相変わらず、USBは弱そうです。
なお3.12では、M2Tech hiFace USB-SPDIF driverの項目がありましたので、モジュールにしてbuildしています。
configはいつもの通り/procの中です。
https://drive.google.com/file/d/0BxnbJHx0_xurRlg5VlNEbVlTbWs/edit?usp=sharing" target="_blank">https://drive.google.com/file/d/0BxnbJHx0_xurRlg5VlNEbVlTbWs/edit?usp=sharing
作成方法
１．Nelsonさんのところの3.12を持ってくる
git clone git://github.com/RobertCNelson/linux-dev.git
cd linux-dev/
git checkout origin/am33x-v3.12 -b tmp
./build_kernel.sh
２．パッチ
上記操作でlinux-dev/KERNELにkernelソースができます。そのソースに対してrt1パッチを当てました。
linux-dev/KERNEL/drivers/misc/Makefileはパッチが正常に当たらないので、手で修正。
３．build（※LOADADDR=0x80008000は必要ないかもしれません。公式ソースの時は必要）
make -j3 LOADADDR=0x80008000 uImage dtbs
make -j3 modules
3.12.0＋rt1を作成しました。今回はFull RTです。
UPしましたので、よろしければ検証お願いします。
CDripのFlacのみ確認しました。音はVer.1ということで^^;
相変わらず、USBは弱そうです。
なお3.12では、M2Tech hiFace USB-SPDIF driverの項目がありましたので、モジュールにしてbuildしています。
configはいつもの通り/procの中です。
https://drive.google.com/file/d/0BxnbJHx0_xurRlg5VlNEbVlTbWs/edit?usp=sharing" target="_blank">https://drive.google.com/file/d/0BxnbJHx0_xurRlg5VlNEbVlTbWs/edit?usp=sharing
作成方法
１．Nelsonさんのところの3.12を持ってくる
git clone git://github.com/RobertCNelson/linux-dev.git
cd linux-dev/
git checkout origin/am33x-v3.12 -b tmp
./build_kernel.sh
２．パッチ
上記操作でlinux-dev/KERNELにkernelソースができます。そのソースに対してrt1パッチを当てました。
linux-dev/KERNEL/drivers/misc/Makefileはパッチが正常に当たらないので、手で修正。
３．build（※LOADADDR=0x80008000は必要ないかもしれません。公式ソースの時は必要）
make -j3 LOADADDR=0x80008000 uImage dtbs
make -j3 modules
tinker 2013/11/11(Mon) 20:58 No.3638
Re: BeagleBone Black(7)
yo 2013/11/11(Mon) 21:07 No.3639
tinkerさん、いろいろ情報ありがとうございます。
> http://marc.info/?l=linux-rt-users&m=138322846828845&w=2" target="_blank">http://marc.info/?l=linux-rt-users&m=138322846828845&w=2
> 上記パッチのみ当てて試したところ、完璧ではないですが随分ましになりました。
3.10用のパッチなのですね。BBBはまだ3.8rtのままなので、cubox 3.10.10-rt7で試してみましたが、uImageが起動しません。パッチの内容(kernel/sched/core.c、kernel/softirq.c、kernel/time/tick-sched.c)は確認し、ビルドは正常終了しています。何か秘密の呪文があるのでしょうか。
lightMPDのサイトを見てきました。丁寧に解説されていますね。カーネルは3.8.13+rt9ということなので、rtカーネルの問題はどのように回避しているのですかね。暇を見て試してみるつもりです。
> http://marc.info/?l=linux-rt-users&m=138322846828845&w=2" target="_blank">http://marc.info/?l=linux-rt-users&m=138322846828845&w=2
> 上記パッチのみ当てて試したところ、完璧ではないですが随分ましになりました。
3.10用のパッチなのですね。BBBはまだ3.8rtのままなので、cubox 3.10.10-rt7で試してみましたが、uImageが起動しません。パッチの内容(kernel/sched/core.c、kernel/softirq.c、kernel/time/tick-sched.c)は確認し、ビルドは正常終了しています。何か秘密の呪文があるのでしょうか。
lightMPDのサイトを見てきました。丁寧に解説されていますね。カーネルは3.8.13+rt9ということなので、rtカーネルの問題はどのように回避しているのですかね。暇を見て試してみるつもりです。
yo 2013/11/11(Mon) 21:07 No.3639
Re: BeagleBone Black(7)
yo 2013/11/11(Mon) 21:08 No.3640
kckさん、はじめまして。
Voyage(インテルマシン)からbbbへ乗り換える方は結構いらしゃいますね。bbbはcuboxより入手が容易ということでしょうか。
おっしゃるように音に関してはbbbの方が断然上だと思います。問題はこのスレッドでさんざん話題になっていますが、rtカーネルだと多少不安定な点ですね(bbbだけの問題ではありませんが)。
回避方法はありますが、はやく障害対応されるといいなぁと思っています。
Voyage(インテルマシン)からbbbへ乗り換える方は結構いらしゃいますね。bbbはcuboxより入手が容易ということでしょうか。
おっしゃるように音に関してはbbbの方が断然上だと思います。問題はこのスレッドでさんざん話題になっていますが、rtカーネルだと多少不安定な点ですね(bbbだけの問題ではありませんが)。
回避方法はありますが、はやく障害対応されるといいなぁと思っています。
yo 2013/11/11(Mon) 21:08 No.3640
Re: BeagleBone Black(7)
yo 2013/11/11(Mon) 21:10 No.3641
twlさん
> ところで皆様に教えていただきたいことがあります。BBBでのarchlinux用のrtset.confの書式の詳細を知りたいのですが、よろしくご指導下さい。cifsマウントの環境です。
この「書式」というのはどういう意味でしょうか。
rtset.confのオリジナルはcubox debian用で、ブート時のrt優先度を設定するするためのスクリプトですが、archではブート時のユーザ処理のやり方が違うので、systemdで実行されるように変更されていると思いますが、そのやり方のことですか ? それとも、rt優先度を設定する方法の解説ですか ?
オリジナルの内容については以下のリンク先に紹介しています。
http://www.symphonic-net.com/kubotayo/articles/articles014.html#001" target="_blank">http://www.symphonic-net.com/kubotayo/articles/articles014.html#001
> ところで皆様に教えていただきたいことがあります。BBBでのarchlinux用のrtset.confの書式の詳細を知りたいのですが、よろしくご指導下さい。cifsマウントの環境です。
この「書式」というのはどういう意味でしょうか。
rtset.confのオリジナルはcubox debian用で、ブート時のrt優先度を設定するするためのスクリプトですが、archではブート時のユーザ処理のやり方が違うので、systemdで実行されるように変更されていると思いますが、そのやり方のことですか ? それとも、rt優先度を設定する方法の解説ですか ?
オリジナルの内容については以下のリンク先に紹介しています。
http://www.symphonic-net.com/kubotayo/articles/articles014.html#001" target="_blank">http://www.symphonic-net.com/kubotayo/articles/articles014.html#001
yo 2013/11/11(Mon) 21:10 No.3641
Re: BeagleBone Black(7)
yo 2013/11/11(Mon) 21:52 No.3642
tinkerさん
3.10を通り越して、3.12ですか。凄いスピードですね。
syuさんのarch最新版で試してみました。起動は問題なく出来ますが、wav(44.1KHz - 192KHz)/flac(44.1KHz)共に細かく震えるような音になります(トレモロ状態)。音源はHD-7A192改。原因調査中です。
3.10を通り越して、3.12ですか。凄いスピードですね。
syuさんのarch最新版で試してみました。起動は問題なく出来ますが、wav(44.1KHz - 192KHz)/flac(44.1KHz)共に細かく震えるような音になります(トレモロ状態)。音源はHD-7A192改。原因調査中です。
yo 2013/11/11(Mon) 21:52 No.3642
Re: BeagleBone Black(7)
yo 2013/11/11(Mon) 22:21 No.3643
cpu負荷が異常ですね。44.1KHz wav再生中です。
top - 22:18:39 up 9 min, 1 user, load average: 2.67, 1.82, 0.88
Tasks: 78 total, 1 running, 77 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 76.9 sy, 0.0 ni, 3.3 id, 17.3 wa, 0.0 hi, 2.5 si, 0.0 st
KiB Mem: 511188 total, 411700 used, 99488 free, 1648 buffers
KiB Swap: 0 total, 0 used, 0 free, 324924 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 25.2 0.0 1:03.81 irq/35-musb-hdr
240 root -54 0 71008 60664 13908 S 17.8 11.9 1:03.52 mpd
273 root 20 0 0 0 0 S 9.0 0.0 0:28.14 cifsd
86 root -54 0 0 0 0 S 8.7 0.0 0:35.22 irq/57-4a100000
87 root -51 0 0 0 0 S 5.3 0.0 0:18.55 irq/58-4a100000
447 root 20 0 4620 1252 928 R 1.6 0.2 0:01.93 top
3 root -2 0 0 0 0 S 1.2 0.0 0:04.62 ksoftirqd/0
11 root 20 0 0 0 0 S 0.6 0.0 0:01.00 rcu_preempt
top - 22:18:39 up 9 min, 1 user, load average: 2.67, 1.82, 0.88
Tasks: 78 total, 1 running, 77 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 76.9 sy, 0.0 ni, 3.3 id, 17.3 wa, 0.0 hi, 2.5 si, 0.0 st
KiB Mem: 511188 total, 411700 used, 99488 free, 1648 buffers
KiB Swap: 0 total, 0 used, 0 free, 324924 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 25.2 0.0 1:03.81 irq/35-musb-hdr
240 root -54 0 71008 60664 13908 S 17.8 11.9 1:03.52 mpd
273 root 20 0 0 0 0 S 9.0 0.0 0:28.14 cifsd
86 root -54 0 0 0 0 S 8.7 0.0 0:35.22 irq/57-4a100000
87 root -51 0 0 0 0 S 5.3 0.0 0:18.55 irq/58-4a100000
447 root 20 0 4620 1252 928 R 1.6 0.2 0:01.93 top
3 root -2 0 0 0 0 S 1.2 0.0 0:04.62 ksoftirqd/0
11 root 20 0 0 0 0 S 0.6 0.0 0:01.00 rcu_preempt
yo 2013/11/11(Mon) 22:21 No.3643
Re: BeagleBone Black(7)
tinker 2013/11/11(Mon) 22:21 No.3644
yoさん
１．lightMPDについて
>rtカーネルの問題はどのように回避しているのですかね
どうなんですかね。独自のpatchが当ててあるとか？
それ以外だと
・メモリー内で処理するから
・小さい構成なのでtask数が少ない
・chrt -f -p 99 `pgrep irq/35-musb-hdr`
以前やってみたことがあるけど、私の環境ではかわりなしでした。
・mpd.confの違い
まずpriorityのところが違いますね。他は、
use_mmap "yes"
buffer_time "2500000"
period_time "500000"
２．3.12について
>細かく震えるような音になります
こちらでもなりましたが、chrt -f -p 55 `pgrep irq/35-musb-hdr`（ethは指定せず）で治まっています（Debian(Wheezy)＋mpd-dsd 0.17.6＋rtop）
mpd.confでbuffer_timeを増やすとかも効くんですかね。
１．lightMPDについて
>rtカーネルの問題はどのように回避しているのですかね
どうなんですかね。独自のpatchが当ててあるとか？
それ以外だと
・メモリー内で処理するから
・小さい構成なのでtask数が少ない
・chrt -f -p 99 `pgrep irq/35-musb-hdr`
以前やってみたことがあるけど、私の環境ではかわりなしでした。
・mpd.confの違い
まずpriorityのところが違いますね。他は、
use_mmap "yes"
buffer_time "2500000"
period_time "500000"
２．3.12について
>細かく震えるような音になります
こちらでもなりましたが、chrt -f -p 55 `pgrep irq/35-musb-hdr`（ethは指定せず）で治まっています（Debian(Wheezy)＋mpd-dsd 0.17.6＋rtop）
mpd.confでbuffer_timeを増やすとかも効くんですかね。
tinker 2013/11/11(Mon) 22:21 No.3644
Re: BeagleBone Black(7)
tinker 2013/11/11(Mon) 23:10 No.3645
yoさん
>cpu負荷が異常ですね
こちらの結果です。flac44.1です。
3.8-rtより負荷が若干高いです。
top - 23:07:46 up 2:22, 1 user, load average: 0.07, 0.13, 0.14
Tasks: 81 total, 1 running, 80 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.1 us, 2.8 sy, 0.0 ni, 92.7 id, 0.0 wa, 0.0 hi, 1.4 si, 0.0 st
KiB Mem: 511188 total, 417236 used, 93952 free, 2988 buffers
KiB Swap: 0 total, 0 used, 0 free, 354264 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 4.9 0.0 5:16.64 irq/35-musb-hdr
2029 mpd 20 0 70308 66m 22m S 3.3 13.3 4:05.57 mpd
2330 root 20 0 4200 1184 840 R 1.3 0.2 0:07.64 top
86 root -51 0 0 0 0 S 0.7 0.0 0:47.29 irq/57-4a100000
1556 root 20 0 0 0 0 S 0.7 0.0 0:26.97 cifsd
87 root -51 0 0 0 0 S 0.3 0.0 0:19.11 irq/58-4a100000
>cpu負荷が異常ですね
こちらの結果です。flac44.1です。
3.8-rtより負荷が若干高いです。
top - 23:07:46 up 2:22, 1 user, load average: 0.07, 0.13, 0.14
Tasks: 81 total, 1 running, 80 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.1 us, 2.8 sy, 0.0 ni, 92.7 id, 0.0 wa, 0.0 hi, 1.4 si, 0.0 st
KiB Mem: 511188 total, 417236 used, 93952 free, 2988 buffers
KiB Swap: 0 total, 0 used, 0 free, 354264 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 4.9 0.0 5:16.64 irq/35-musb-hdr
2029 mpd 20 0 70308 66m 22m S 3.3 13.3 4:05.57 mpd
2330 root 20 0 4200 1184 840 R 1.3 0.2 0:07.64 top
86 root -51 0 0 0 0 S 0.7 0.0 0:47.29 irq/57-4a100000
1556 root 20 0 0 0 0 S 0.7 0.0 0:26.97 cifsd
87 root -51 0 0 0 0 S 0.3 0.0 0:19.11 irq/58-4a100000
tinker 2013/11/11(Mon) 23:10 No.3645
Re: BeagleBone Black(7)
twl 2013/11/11(Mon) 23:55 No.3646
yoさんwrote:
> -snip- そのやり方のことですか ? それとも、rt優先度を設定する方法の解説ですか ?
説明不足で失礼しました。後者の優先度についてのものでしたが、お示しされたリンク先を拝見して解決しました。ありがとうございました。
twl
> -snip- そのやり方のことですか ? それとも、rt優先度を設定する方法の解説ですか ?
説明不足で失礼しました。後者の優先度についてのものでしたが、お示しされたリンク先を拝見して解決しました。ありがとうございました。
twl
twl 2013/11/11(Mon) 23:55 No.3646
Re: BeagleBone Black(7)
yo 2013/11/12(Tue) 22:35 No.3647
tinkerさん
こちらのcpu負荷はmpdが17.8、usbドライバが25.2、ethが8.7と5.3%。尋常ではないです。
%Cpu(s): 0.0 us, 76.9 syというのもまったく奇怪しいので、何か問題があるのでしょう。
tinkerさんとの環境の違いはddcとrootfsですので、どちらかが原因だと思います。
こちらのcpu負荷はmpdが17.8、usbドライバが25.2、ethが8.7と5.3%。尋常ではないです。
%Cpu(s): 0.0 us, 76.9 syというのもまったく奇怪しいので、何か問題があるのでしょう。
tinkerさんとの環境の違いはddcとrootfsですので、どちらかが原因だと思います。
yo 2013/11/12(Tue) 22:35 No.3647
Re: BeagleBone Black(7)
twl 2013/11/12(Tue) 22:53 No.3648
tinkerさん wrote:
> 3.12.0＋rt1を作成しました。今回はFull RTです。
> UPしましたので、よろしければ検証お願いします。
Debian, mpd-0.18.3で試しましたが、残念ながらdsd128, dsd64, pcmいずれのフィアルも再生できませんでした。
次いでArchlinuxで試しましたが、同じmpd-0.18.3の環境ではpcmファイルは再生できました。ただし細かいノイズが混じり、音質としては問題が残りました。mpdがrtの環境ではないので、あくまでも私の環境での結果ですが、dsd128およびdsd64ではノイズがより目立ち、再生には不向きと判断しました。
これとは別にgithubにNelson版3.13カーネルの項目ができていたので、そのzipファイルからカーネルをビルドしましたら3.13ではなく、以下のごとく3.12のカーネルがビルドされました。
Linux arm 3.12.0_BBB_1112-00080-g8ed323e #1 SMP PREEMPT Tue Nov 12 07:51:27 JST 2013 armv7l GNU/Linux
rcではなく、公式の3.12カーネルソ－スからのものと思いますが、このカーネルではdsd128, dsd64, pcmのいずれもノイズの混入は皆無、極めて良好な再生が得られております。mpdは上記同様0.18.3です。
以上、報告申し上げました。
> 3.12.0＋rt1を作成しました。今回はFull RTです。
> UPしましたので、よろしければ検証お願いします。
Debian, mpd-0.18.3で試しましたが、残念ながらdsd128, dsd64, pcmいずれのフィアルも再生できませんでした。
次いでArchlinuxで試しましたが、同じmpd-0.18.3の環境ではpcmファイルは再生できました。ただし細かいノイズが混じり、音質としては問題が残りました。mpdがrtの環境ではないので、あくまでも私の環境での結果ですが、dsd128およびdsd64ではノイズがより目立ち、再生には不向きと判断しました。
これとは別にgithubにNelson版3.13カーネルの項目ができていたので、そのzipファイルからカーネルをビルドしましたら3.13ではなく、以下のごとく3.12のカーネルがビルドされました。
Linux arm 3.12.0_BBB_1112-00080-g8ed323e #1 SMP PREEMPT Tue Nov 12 07:51:27 JST 2013 armv7l GNU/Linux
rcではなく、公式の3.12カーネルソ－スからのものと思いますが、このカーネルではdsd128, dsd64, pcmのいずれもノイズの混入は皆無、極めて良好な再生が得られております。mpdは上記同様0.18.3です。
以上、報告申し上げました。
twl 2013/11/12(Tue) 22:53 No.3648
Re: BeagleBone Black(7)
syu 2013/11/13(Wed) 13:40 No.3649
tinkerさん
3.12.0＋rt1の公開、ありがとうございます。しかもFull RTとは、素晴らしい！
なかなか時間がとれなくて、やっと試してみることができました。まずはarch linuxに入れてみました。build_filesと/lib/modules/にコピーしてselbootで書き換え可能でした。
私の環境ではpcmは24/176.5まで良好。dsd28は良好ですが、dsd56はノイズだけになりました。
>音はVer.1ということで^^;
私は割と良いと思います。音楽に(金田アンプのような)妙な充実感があるのは、もしかしたら「いまいち個性的」な点なのかも(^^;;
usbの%cpuが高くなりますが、full rtだからでしょうかね。
[root@sd-arch ~]# uname -a
Linux sd-arch 3.12.0-rt1_1111-1+ #1 SMP PREEMPT RT Mon Nov 11 20:42:05 JST 2013 armv7l GNU/Linux
[root@sd-arch ~]# mpd --version
mpd (MPD: Music Player Daemon) 0.17.6
pcm 16/44.1-wav再生中。
top - 21:06:37 up 6 min, 1 user, load average: 0.21, 0.47, 0.31
Tasks: 74 total, 1 running, 73 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.7 us, 6.8 sy, 0.0 ni, 87.4 id, 0.0 wa, 0.0 hi, 2.1 si, 0.0 st
KiB Mem: 511200 total, 179192 used, 332008 free, 5792 buffers
KiB Swap: 0 total, 0 used, 0 free, 110772 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 30.1 0.0 2:01.96 irq/35-musb+
244 root -54 0 61612 58616 14304 S 2.6 11.5 0:12.15 mpd
422 root 20 0 5092 1196 928 R 1.3 0.2 0:04.61 top
87 root -54 0 0 0 0 S 1.0 0.0 0:03.20 irq/57-4a10+
261 root -54 0 0 0 0 S 0.7 0.0 0:02.99 cifsd
pcm 24/96-wav 再生中。
top - 21:17:17 up 17 min, 1 user, load average: 0.50, 0.71, 0.50
Tasks: 74 total, 1 running, 73 sleeping, 0 stopped, 0 zombie
%Cpu(s): 6.4 us, 14.4 sy, 0.0 ni, 73.8 id, 0.0 wa, 0.0 hi, 5.4 si, 0.0 st
KiB Mem: 511200 total, 478800 used, 32400 free, 5892 buffers
KiB Swap: 0 total, 0 used, 0 free, 409316 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 30.4 0.0 5:25.98 irq/35-musb+
244 root -54 0 61788 58712 14356 S 6.1 11.5 0:52.90 mpd
261 root -54 0 0 0 0 S 2.6 0.0 0:20.16 cifsd
87 root -54 0 0 0 0 S 1.9 0.0 0:18.26 irq/57-4a10+
pcm24/176.4-wav再生中。数値は高いけどノイズなく良好。
top - 21:28:56 up 29 min, 1 user, load average: 2.70, 1.93, 1.19
Tasks: 74 total, 1 running, 73 sleeping, 0 stopped, 0 zombie
%Cpu(s): 12.8 us, 25.6 sy, 0.0 ni, 54.3 id, 0.0 wa, 0.0 hi, 7.3 si, 0.0 st
KiB Mem: 511200 total, 491736 used, 19464 free, 1648 buffers
KiB Swap: 0 total, 0 used, 0 free, 426588 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 32.3 0.0 9:07.51 irq/35-musb+
244 root -54 0 61788 58712 14356 S 11.8 11.5 1:57.86 mpd
261 root -54 0 0 0 0 S 4.2 0.0 0:45.53 cifsd
87 root -54 0 0 0 0 S 3.3 0.0 0:40.40 irq/57-4a10+
dsd28 dff再生中。
top - 21:10:41 up 11 min, 1 user, load average: 0.03, 0.22, 0.24
Tasks: 74 total, 1 running, 73 sleeping, 0 stopped, 0 zombie
%Cpu(s): 7.7 us, 14.4 sy, 0.0 ni, 70.8 id, 0.0 wa, 0.0 hi, 7.2 si, 0.0 st
KiB Mem: 511200 total, 245320 used, 265880 free, 5828 buffers
KiB Swap: 0 total, 0 used, 0 free, 176176 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 32.5 0.0 3:15.67 irq/35-musb+
244 root -54 0 61788 58712 14356 S 5.8 11.5 0:20.32 mpd
261 root -54 0 0 0 0 S 2.9 0.0 0:05.69 cifsd
87 root -54 0 0 0 0 S 2.3 0.0 0:05.88 irq/57-4a10+
dsd56-dff再生中。ノイズしか聴こえない。(追記：mpdがmpd-dsdでなかったので、当然? mpd-0.17.6-dsd-rtoptでやり直して見ます）
top - 21:20:52 up 21 min, 1 user, load average: 0.33, 0.86, 0.64
Tasks: 74 total, 1 running, 73 sleeping, 0 stopped, 0 zombie
%Cpu(s): 13.3 us, 29.8 sy, 0.0 ni, 44.0 id, 0.0 wa, 0.0 hi, 12.8 si, 0.0 st
KiB Mem: 511200 total, 375516 used, 135684 free, 1756 buffers
KiB Swap: 0 total, 0 used, 0 free, 309760 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 36.5 0.0 6:31.88 irq/35-musb+
244 root -54 0 61788 58712 14356 S 13.6 11.5 1:07.46 mpd
261 root -54 0 0 0 0 S 5.7 0.0 0:26.00 cifsd
87 root -54 0 0 0 0 S 5.1 0.0 0:23.37 irq/57-4a10+
今夜にでも、debianでやってみます。
3.12.0＋rt1の公開、ありがとうございます。しかもFull RTとは、素晴らしい！
なかなか時間がとれなくて、やっと試してみることができました。まずはarch linuxに入れてみました。build_filesと/lib/modules/にコピーしてselbootで書き換え可能でした。
私の環境ではpcmは24/176.5まで良好。dsd28は良好ですが、dsd56はノイズだけになりました。
>音はVer.1ということで^^;
私は割と良いと思います。音楽に(金田アンプのような)妙な充実感があるのは、もしかしたら「いまいち個性的」な点なのかも(^^;;
usbの%cpuが高くなりますが、full rtだからでしょうかね。
[root@sd-arch ~]# uname -a
Linux sd-arch 3.12.0-rt1_1111-1+ #1 SMP PREEMPT RT Mon Nov 11 20:42:05 JST 2013 armv7l GNU/Linux
[root@sd-arch ~]# mpd --version
mpd (MPD: Music Player Daemon) 0.17.6
pcm 16/44.1-wav再生中。
top - 21:06:37 up 6 min, 1 user, load average: 0.21, 0.47, 0.31
Tasks: 74 total, 1 running, 73 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.7 us, 6.8 sy, 0.0 ni, 87.4 id, 0.0 wa, 0.0 hi, 2.1 si, 0.0 st
KiB Mem: 511200 total, 179192 used, 332008 free, 5792 buffers
KiB Swap: 0 total, 0 used, 0 free, 110772 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 30.1 0.0 2:01.96 irq/35-musb+
244 root -54 0 61612 58616 14304 S 2.6 11.5 0:12.15 mpd
422 root 20 0 5092 1196 928 R 1.3 0.2 0:04.61 top
87 root -54 0 0 0 0 S 1.0 0.0 0:03.20 irq/57-4a10+
261 root -54 0 0 0 0 S 0.7 0.0 0:02.99 cifsd
pcm 24/96-wav 再生中。
top - 21:17:17 up 17 min, 1 user, load average: 0.50, 0.71, 0.50
Tasks: 74 total, 1 running, 73 sleeping, 0 stopped, 0 zombie
%Cpu(s): 6.4 us, 14.4 sy, 0.0 ni, 73.8 id, 0.0 wa, 0.0 hi, 5.4 si, 0.0 st
KiB Mem: 511200 total, 478800 used, 32400 free, 5892 buffers
KiB Swap: 0 total, 0 used, 0 free, 409316 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 30.4 0.0 5:25.98 irq/35-musb+
244 root -54 0 61788 58712 14356 S 6.1 11.5 0:52.90 mpd
261 root -54 0 0 0 0 S 2.6 0.0 0:20.16 cifsd
87 root -54 0 0 0 0 S 1.9 0.0 0:18.26 irq/57-4a10+
pcm24/176.4-wav再生中。数値は高いけどノイズなく良好。
top - 21:28:56 up 29 min, 1 user, load average: 2.70, 1.93, 1.19
Tasks: 74 total, 1 running, 73 sleeping, 0 stopped, 0 zombie
%Cpu(s): 12.8 us, 25.6 sy, 0.0 ni, 54.3 id, 0.0 wa, 0.0 hi, 7.3 si, 0.0 st
KiB Mem: 511200 total, 491736 used, 19464 free, 1648 buffers
KiB Swap: 0 total, 0 used, 0 free, 426588 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 32.3 0.0 9:07.51 irq/35-musb+
244 root -54 0 61788 58712 14356 S 11.8 11.5 1:57.86 mpd
261 root -54 0 0 0 0 S 4.2 0.0 0:45.53 cifsd
87 root -54 0 0 0 0 S 3.3 0.0 0:40.40 irq/57-4a10+
dsd28 dff再生中。
top - 21:10:41 up 11 min, 1 user, load average: 0.03, 0.22, 0.24
Tasks: 74 total, 1 running, 73 sleeping, 0 stopped, 0 zombie
%Cpu(s): 7.7 us, 14.4 sy, 0.0 ni, 70.8 id, 0.0 wa, 0.0 hi, 7.2 si, 0.0 st
KiB Mem: 511200 total, 245320 used, 265880 free, 5828 buffers
KiB Swap: 0 total, 0 used, 0 free, 176176 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 32.5 0.0 3:15.67 irq/35-musb+
244 root -54 0 61788 58712 14356 S 5.8 11.5 0:20.32 mpd
261 root -54 0 0 0 0 S 2.9 0.0 0:05.69 cifsd
87 root -54 0 0 0 0 S 2.3 0.0 0:05.88 irq/57-4a10+
dsd56-dff再生中。ノイズしか聴こえない。(追記：mpdがmpd-dsdでなかったので、当然? mpd-0.17.6-dsd-rtoptでやり直して見ます）
top - 21:20:52 up 21 min, 1 user, load average: 0.33, 0.86, 0.64
Tasks: 74 total, 1 running, 73 sleeping, 0 stopped, 0 zombie
%Cpu(s): 13.3 us, 29.8 sy, 0.0 ni, 44.0 id, 0.0 wa, 0.0 hi, 12.8 si, 0.0 st
KiB Mem: 511200 total, 375516 used, 135684 free, 1756 buffers
KiB Swap: 0 total, 0 used, 0 free, 309760 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 36.5 0.0 6:31.88 irq/35-musb+
244 root -54 0 61788 58712 14356 S 13.6 11.5 1:07.46 mpd
261 root -54 0 0 0 0 S 5.7 0.0 0:26.00 cifsd
87 root -54 0 0 0 0 S 5.1 0.0 0:23.37 irq/57-4a10+
今夜にでも、debianでやってみます。
syu 2013/11/13(Wed) 13:40 No.3649
Re: BeagleBone Black(7)
syu 2013/11/13(Wed) 15:01 No.3650
mpd-0176-dsd-rtoptでやり直して見ましたが、dsd56-dffはやはりノイズだけでした。
[root@sd-arch ~]# mpd --version
mpd (MPD: Music Player Daemon) 0.17.6-DSD
[root@sd-arch ~]# mpd --version
mpd (MPD: Music Player Daemon) 0.17.6-DSD
syu 2013/11/13(Wed) 15:01 No.3650
Re: BeagleBone Black(7)
syu 2013/11/13(Wed) 18:33 No.3652
usbの%cpuは私が一番高いんですね。
それにしてもtinkerさんの4.9%は異様に低い(^^;;
tinkerさんがお使いのrootfsに、何か秘密がありそうな気も・・・
tinkerさん
70 root -56 0 0 0 0 S 4.9 0.0 5:16.64 irq/35-musb-hdr
yoさん
70 root -56 0 0 0 0 S 25.2 0.0 1:03.81 irq/35-musb-hdr
私
70 root -56 0 0 0 0 S 30.1 0.0 2:01.96 irq/35-musb+
私の場合、異様に高いのにノイズが出ないのも不思議です。
それにしてもtinkerさんの4.9%は異様に低い(^^;;
tinkerさんがお使いのrootfsに、何か秘密がありそうな気も・・・
tinkerさん
70 root -56 0 0 0 0 S 4.9 0.0 5:16.64 irq/35-musb-hdr
yoさん
70 root -56 0 0 0 0 S 25.2 0.0 1:03.81 irq/35-musb-hdr
私
70 root -56 0 0 0 0 S 30.1 0.0 2:01.96 irq/35-musb+
私の場合、異様に高いのにノイズが出ないのも不思議です。
syu 2013/11/13(Wed) 18:33 No.3652
Re: BeagleBone Black(7)
tinker 2013/11/13(Wed) 18:54 No.3653
yoさん
twlさん
syuさん
検証ありがとうございます。
よろしければ、以下のzImageのテストをお願いします。
https://drive.google.com/file/d/0BxnbJHx0_xurY1RRd3FtenhqaEk/edit?usp=sharing" target="_blank">https://drive.google.com/file/d/0BxnbJHx0_xurY1RRd3FtenhqaEk/edit?usp=sharing
このzImageは、先にUPしたものと同じconfigでbuildしています。違いはソースに以下のpatchを当てています。
https://launchpadlibrarian.net/140553725/ehci-split-bugs" target="_blank">https://launchpadlibrarian.net/140553725/ehci-split-bugs
このzImageであれば、yoさんがおっしゃっていたトレモロは出ないと思います。
今回も手強そうですね。また泥舟なんでしょうか^^;
syuさん
>tinkerさんがお使いのrootfsに、何か秘密がありそうな気も・・・
適当に作ったDebianです。秘密なんか何にもないですよ(笑)
違いは、私のDACのUSBの接続が24/96のclass1なのでfull speedで繋がっているからだと思います。
twlさん
syuさん
検証ありがとうございます。
よろしければ、以下のzImageのテストをお願いします。
https://drive.google.com/file/d/0BxnbJHx0_xurY1RRd3FtenhqaEk/edit?usp=sharing" target="_blank">https://drive.google.com/file/d/0BxnbJHx0_xurY1RRd3FtenhqaEk/edit?usp=sharing
このzImageは、先にUPしたものと同じconfigでbuildしています。違いはソースに以下のpatchを当てています。
https://launchpadlibrarian.net/140553725/ehci-split-bugs" target="_blank">https://launchpadlibrarian.net/140553725/ehci-split-bugs
このzImageであれば、yoさんがおっしゃっていたトレモロは出ないと思います。
今回も手強そうですね。また泥舟なんでしょうか^^;
syuさん
>tinkerさんがお使いのrootfsに、何か秘密がありそうな気も・・・
適当に作ったDebianです。秘密なんか何にもないですよ(笑)
違いは、私のDACのUSBの接続が24/96のclass1なのでfull speedで繋がっているからだと思います。
tinker 2013/11/13(Wed) 18:54 No.3653
Re: BeagleBone Black(7)
syu 2013/11/13(Wed) 22:27 No.3654
>よろしければ、以下のzImageのテストを
私の環境では、%cpuがそれぞれ少しずつ低下する効果がありました。
音は・・・よくわかりません。
dsd56は、やはりジジジジジジってノイズしか出ませんね。
pcm 16/44.1 wav 再生中
top - 06:24:54 up 1:58, 1 user, load average: 0.04, 0.20, 0.31
Tasks: 75 total, 1 running, 74 sleeping, 0 stopped, 0 zombie
%Cpu(s): 5.2 us, 6.8 sy, 0.0 ni, 86.5 id, 0.0 wa, 0.0 hi, 1.6 si, 0.0 st
KiB Mem: 511200 total, 506924 used, 4276 free, 1800 buffers
KiB Swap: 0 total, 0 used, 0 free, 441848 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 29.7 0.0 33:50.41 irq/35-musb+
244 root -54 0 61672 58728 14408 S 2.6 11.5 3:16.35 mpd
425 root 20 0 5092 1196 928 R 1.3 0.2 1:24.50 top
87 root -54 0 0 0 0 S 0.7 0.0 0:56.00 irq/57-4a10+
261 root -54 0 0 0 0 S 0.7 0.0 0:54.86 cifsd
私の環境では、%cpuがそれぞれ少しずつ低下する効果がありました。
音は・・・よくわかりません。
dsd56は、やはりジジジジジジってノイズしか出ませんね。
pcm 16/44.1 wav 再生中
top - 06:24:54 up 1:58, 1 user, load average: 0.04, 0.20, 0.31
Tasks: 75 total, 1 running, 74 sleeping, 0 stopped, 0 zombie
%Cpu(s): 5.2 us, 6.8 sy, 0.0 ni, 86.5 id, 0.0 wa, 0.0 hi, 1.6 si, 0.0 st
KiB Mem: 511200 total, 506924 used, 4276 free, 1800 buffers
KiB Swap: 0 total, 0 used, 0 free, 441848 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 29.7 0.0 33:50.41 irq/35-musb+
244 root -54 0 61672 58728 14408 S 2.6 11.5 3:16.35 mpd
425 root 20 0 5092 1196 928 R 1.3 0.2 1:24.50 top
87 root -54 0 0 0 0 S 0.7 0.0 0:56.00 irq/57-4a10+
261 root -54 0 0 0 0 S 0.7 0.0 0:54.86 cifsd
syu 2013/11/13(Wed) 22:27 No.3654
Re: BeagleBone Black(7)
tinker 2013/11/13(Wed) 23:14 No.3655
syuさん
ありがとうございます。
yoさんのところでは、音が震える状態が出ているそうなんです。
私のところではdsdの再生環境がないので、dsdのテストが出来なくてすいません。
usbのところが従来のfifo onlyもあるので、そのうち試してみます。ただ、こちらの環境だと変化が分からないような気もします。
ありがとうございます。
yoさんのところでは、音が震える状態が出ているそうなんです。
私のところではdsdの再生環境がないので、dsdのテストが出来なくてすいません。
usbのところが従来のfifo onlyもあるので、そのうち試してみます。ただ、こちらの環境だと変化が分からないような気もします。
tinker 2013/11/13(Wed) 23:14 No.3655
Re: BeagleBone Black(7)
twl 2013/11/13(Wed) 23:52 No.3656
twlです。私もtinkerさんの新しいzImageを試させていただきました。機会を与えていただきありがとうございました。
Debian、Archlinuxの両方についてmpd-0.18.3でpcm, DSD128(syuさんのDSD56なんでしょうね、おそらく5.6MHz由来と思いますが)、DSD64のソースを試しましたが、いずれの環境でも基本的なソースファイルの再生は可能でしたが、いずれも程度の違いはあれノイズが混じります。DSD128では前回に比べノイズよりも楽音が明瞭に確認できますが、これで音楽を楽しみなさいといわれると、ちょっと辛いものがあります (^^; 。お許し下さい。
ただ、pcmでは前よりもプチプチノイズが気にならない印象があり、debianでより明確に認識できました。
以下の記録で気になることは、tinkerさんおよび私の結果ではmpdのPRは20となっていますが、syuさん、yoさんでは-54となっています。私の優先度の指定に問題があるのでしょうか。tinkerさんのカーネルを正確に評価できているのかどうか、不安になります。
BBB-Arch DSD128 mpd-0.18.3
top - 22:02:59 up 21 min, 1 user, load average: 0.84, 1.44, 1.08
Tasks: 73 total, 1 running, 72 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 37.4 sy, 0.0 ni, 55.4 id, 0.0 wa, 0.0 hi, 7.2 si, 0.0 st
KiB Mem: 511188 total, 276636 used, 234552 free, 1628 buffers
KiB Swap: 0 total, 0 used, 0 free, 249064 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 34.2 0.0 5:32.67 irq/35-musb+
570 mpd 20 0 82408 11312 4368 S 7.2 2.2 0:13.10 mpd
409 root -54 0 0 0 0 S 4.9 0.0 0:49.78 cifsd
87 root -54 0 0 0 0 S 4.2 0.0 0:44.74 irq/57-4a10+
577 root 20 0 4616 1200 928 R 1.3 0.2 0:00.16 top
88 root -54 0 0 0 0 S 1.0 0.0 0:10.93 irq/58-4a10+
3 root -2 0 0 0 0 S 0.3 0.0 0:02.49 ksoftirqd/0
17 root 20 0 0 0 0 S 0.3 0.0 0:05.58 kworker/0:1
1 root 20 0 4796 2664 1820 S 0.0 0.5 0:02.65 systemd
BBB-Debian DSD128 mpd-0.18.3
top - 22:06:26 up 1 min, 1 user, load average: 1.30, 0.49, 0.18
Tasks: 79 total, 1 running, 78 sleeping, 0 stopped, 0 zombie
%Cpu(s): 10.0 us, 25.1 sy, 0.0 ni, 53.4 id, 1.8 wa, 0.0 hi, 9.6 si, 0.0 st
KiB Mem: 511180 total, 155772 used, 355408 free, 5176 buffers
KiB Swap: 0 total, 0 used, 0 free, 126976 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 32.8 0.0 0:22.91 irq/35-musb-hdr
1958 mpd 20 0 74664 9660 1776 S 7.3 1.9 0:05.80 mpd
1614 root -54 0 0 0 0 S 5.1 0.0 0:03.56 cifsd
85 root -54 0 0 0 0 S 4.5 0.0 0:03.45 irq/57-4a100000
86 root -54 0 0 0 0 S 1.3 0.0 0:00.84 irq/58-4a100000
2272 root 20 0 2672 1064 744 R 1.3 0.2 0:00.52 top
2263 root 20 0 8556 2708 2104 S 0.6 0.5 0:00.77 sshd
3 root -2 0 0 0 0 S 0.3 0.0 0:01.04 ksoftirqd/0
11 root 20 0 0 0 0 S 0.3 0.0 0:00.30 rcu_preempt
なお、比較のために先日私がビルドした3.12(non-RT)のカーネル一式を以下のURLにおきました。私の環境ではpcmからdsd128の再生までノイズなしで使えています。御比較いただければ幸いです。
http://lydia.concorde.gr.jp/luke/twl.tar.xz" target="_blank">http://lydia.concorde.gr.jp/luke/twl.tar.xz
Debian、Archlinuxの両方についてmpd-0.18.3でpcm, DSD128(syuさんのDSD56なんでしょうね、おそらく5.6MHz由来と思いますが)、DSD64のソースを試しましたが、いずれの環境でも基本的なソースファイルの再生は可能でしたが、いずれも程度の違いはあれノイズが混じります。DSD128では前回に比べノイズよりも楽音が明瞭に確認できますが、これで音楽を楽しみなさいといわれると、ちょっと辛いものがあります (^^; 。お許し下さい。
ただ、pcmでは前よりもプチプチノイズが気にならない印象があり、debianでより明確に認識できました。
以下の記録で気になることは、tinkerさんおよび私の結果ではmpdのPRは20となっていますが、syuさん、yoさんでは-54となっています。私の優先度の指定に問題があるのでしょうか。tinkerさんのカーネルを正確に評価できているのかどうか、不安になります。
BBB-Arch DSD128 mpd-0.18.3
top - 22:02:59 up 21 min, 1 user, load average: 0.84, 1.44, 1.08
Tasks: 73 total, 1 running, 72 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 37.4 sy, 0.0 ni, 55.4 id, 0.0 wa, 0.0 hi, 7.2 si, 0.0 st
KiB Mem: 511188 total, 276636 used, 234552 free, 1628 buffers
KiB Swap: 0 total, 0 used, 0 free, 249064 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 34.2 0.0 5:32.67 irq/35-musb+
570 mpd 20 0 82408 11312 4368 S 7.2 2.2 0:13.10 mpd
409 root -54 0 0 0 0 S 4.9 0.0 0:49.78 cifsd
87 root -54 0 0 0 0 S 4.2 0.0 0:44.74 irq/57-4a10+
577 root 20 0 4616 1200 928 R 1.3 0.2 0:00.16 top
88 root -54 0 0 0 0 S 1.0 0.0 0:10.93 irq/58-4a10+
3 root -2 0 0 0 0 S 0.3 0.0 0:02.49 ksoftirqd/0
17 root 20 0 0 0 0 S 0.3 0.0 0:05.58 kworker/0:1
1 root 20 0 4796 2664 1820 S 0.0 0.5 0:02.65 systemd
BBB-Debian DSD128 mpd-0.18.3
top - 22:06:26 up 1 min, 1 user, load average: 1.30, 0.49, 0.18
Tasks: 79 total, 1 running, 78 sleeping, 0 stopped, 0 zombie
%Cpu(s): 10.0 us, 25.1 sy, 0.0 ni, 53.4 id, 1.8 wa, 0.0 hi, 9.6 si, 0.0 st
KiB Mem: 511180 total, 155772 used, 355408 free, 5176 buffers
KiB Swap: 0 total, 0 used, 0 free, 126976 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70 root -56 0 0 0 0 S 32.8 0.0 0:22.91 irq/35-musb-hdr
1958 mpd 20 0 74664 9660 1776 S 7.3 1.9 0:05.80 mpd
1614 root -54 0 0 0 0 S 5.1 0.0 0:03.56 cifsd
85 root -54 0 0 0 0 S 4.5 0.0 0:03.45 irq/57-4a100000
86 root -54 0 0 0 0 S 1.3 0.0 0:00.84 irq/58-4a100000
2272 root 20 0 2672 1064 744 R 1.3 0.2 0:00.52 top
2263 root 20 0 8556 2708 2104 S 0.6 0.5 0:00.77 sshd
3 root -2 0 0 0 0 S 0.3 0.0 0:01.04 ksoftirqd/0
11 root 20 0 0 0 0 S 0.3 0.0 0:00.30 rcu_preempt
なお、比較のために先日私がビルドした3.12(non-RT)のカーネル一式を以下のURLにおきました。私の環境ではpcmからdsd128の再生までノイズなしで使えています。御比較いただければ幸いです。
http://lydia.concorde.gr.jp/luke/twl.tar.xz" target="_blank">http://lydia.concorde.gr.jp/luke/twl.tar.xz
twl 2013/11/13(Wed) 23:52 No.3656
Re: BeagleBone Black(7)
twl 2013/11/14(Thu) 00:24 No.3657
> 先日私がビルドした3.12(non-RT)のカーネル一式を以下のURLにおきました。
書き忘れました。mytekおよびhiFace Evoのmoduleが./3.12.0_BBB_111.../extraから利用可能です。
twl
書き忘れました。mytekおよびhiFace Evoのmoduleが./3.12.0_BBB_111.../extraから利用可能です。
twl
twl 2013/11/14(Thu) 00:24 No.3657
Re: BeagleBone Black(7)
syu 2013/11/14(Thu) 01:16 No.3658
yoさんがNo.3356記事で公開されたdebianhf-rootfsのイメージを使用して、2種類のzImageを試してみました。
結果はarch linuxの場合と同じでした。DSD128がノイズまみれなのも同じです。
twlさん
>syuさんのDSD56
DSD128の間違いです(笑。私、この手の事、よくやらかすんですよね。
私の環境では、31200rtの音はdebianの方が良いと思います。
>音楽に(金田アンプのような)妙な充実感があるのは、もしかしたら「いまいち個性的」な点なのかも(^^;;
この印象が減るようです。
では、寝ます。
結果はarch linuxの場合と同じでした。DSD128がノイズまみれなのも同じです。
twlさん
>syuさんのDSD56
DSD128の間違いです(笑。私、この手の事、よくやらかすんですよね。
私の環境では、31200rtの音はdebianの方が良いと思います。
>音楽に(金田アンプのような)妙な充実感があるのは、もしかしたら「いまいち個性的」な点なのかも(^^;;
この印象が減るようです。
では、寝ます。
syu 2013/11/14(Thu) 01:16 No.3658
Re: BeagleBone Black(7)
twl 2013/11/14(Thu) 07:51 No.3659
> 結果はarch linuxの場合と同じでした。DSD128がノイズまみれなのも同じです。
ご検証ありがとうございました。私のdebian rootfsはwww.armhf.comからのものなので、その違いがあるのかもしれませんね。
なお書き忘れましたが、Archlinux上のDSD再生に関しては、自前カーネルでもノイズが生じ、DSD128でより目立ちます。
twl
ご検証ありがとうございました。私のdebian rootfsはwww.armhf.comからのものなので、その違いがあるのかもしれませんね。
なお書き忘れましたが、Archlinux上のDSD再生に関しては、自前カーネルでもノイズが生じ、DSD128でより目立ちます。
twl
twl 2013/11/14(Thu) 07:51 No.3659
Re: BeagleBone Black(7)
yo 2013/11/14(Thu) 21:06 No.3661
このスレッドは長くなったので新しくします。タイトルは「BeagleBone Black(8)」です。
yo 2013/11/14(Thu) 21:06 No.3661
MPD on CuBoxのDSD再生
いつもお世話になっています。
CuBoxに梅雨入り版を入れております。DSD対応のUSBDACですと完璧に再生されます。
ところが、DSD非対応のUSBDACですと、DSD再生がまったくできません。
同じDSD非対応のUSBDACをPCベースのVoyageMPDにつなぐと、DSDファイルの再生もできるのですが、これはDSD->PCM変換をVoyageMPD側で行っているためだと思います。
同じようにCuBox向け梅雨入り版もDSD非対応DACでDSD->PCM変換を行うことは可能でしょうか？
ちなみに最新版のカーネル3.10対応の梅雨入り版もさっそく試しましたが、状況は同じようでした。ただしこちらは以前の梅雨入り版よりもハイレゾ音源（192/24）の再生が安定しております。
よろしくお願いします。
Re: MPD on CuBoxのDSD再生
yo 2013/10/08(Tue) 21:09 No.3597
selecta さん
> 同じようにCuBox向け梅雨入り版もDSD非対応DACでDSD->PCM変換を行うことは可能でしょうか？
mpd.confの設定を変更すれば可能ですが、cuboxの場合、cpuの性能が不足しますので、ノイズだらけとなります。チューニングで改善できるのかもしれませんが、試したことはありません。
やり方はこのページにあるように、
http://www.symphonic-net.com/kubotayo/articles/articles012.html#026" target="_blank">http://www.symphonic-net.com/kubotayo/articles/articles012.html#026
audio_outputのdsd_usbをコメントアウトすればいいです。
# dsd_usb "no"
尚、カーネルを3.10対応にした場合は/etc/mpd0.confと/etc/mpd1.confを変更し、selmpdする必要があります。
> 同じようにCuBox向け梅雨入り版もDSD非対応DACでDSD->PCM変換を行うことは可能でしょうか？
mpd.confの設定を変更すれば可能ですが、cuboxの場合、cpuの性能が不足しますので、ノイズだらけとなります。チューニングで改善できるのかもしれませんが、試したことはありません。
やり方はこのページにあるように、
http://www.symphonic-net.com/kubotayo/articles/articles012.html#026" target="_blank">http://www.symphonic-net.com/kubotayo/articles/articles012.html#026
audio_outputのdsd_usbをコメントアウトすればいいです。
# dsd_usb "no"
尚、カーネルを3.10対応にした場合は/etc/mpd0.confと/etc/mpd1.confを変更し、selmpdする必要があります。
yo 2013/10/08(Tue) 21:09 No.3597
Re: MPD on CuBoxのDSD再生
yoさん
いつもありがとうございます。mpd.confのdsd_usb "yes"となっていたので気付きませんでしたがその行をコメントアウトしたら可能となりました。
残念ながらご推測のとおりブツ切れで聴けるレベルではありませんでした。。。
いつもありがとうございます。mpd.confのdsd_usb "yes"となっていたので気付きませんでしたがその行をコメントアウトしたら可能となりました。
残念ながらご推測のとおりブツ切れで聴けるレベルではありませんでした。。。
BeagleBone Black(6)
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の表示も正しく設定されてように見えます。
いろいろ試して分かったことはあるのですが、もう少し整理してから書きます。
Re: BeagleBone Black(6)
yo 2013/09/03(Tue) 22:07 No.3510
tinkerさん
> Archってdebianでunstableを使ってるみたいなドキドキ感がありますね^^;
ほんとじゃじゃ馬ですね(^^;;;。昨日出来ていたことが今日は駄目になる世界ですね。
> ２については、yoさん，syuさんの対応の他に、PKGBUILDでは以下のようにしているようです。
これってどこの情報ですか。
> Archってdebianでunstableを使ってるみたいなドキドキ感がありますね^^;
ほんとじゃじゃ馬ですね(^^;;;。昨日出来ていたことが今日は駄目になる世界ですね。
> ２については、yoさん，syuさんの対応の他に、PKGBUILDでは以下のようにしているようです。
これってどこの情報ですか。
yo 2013/09/03(Tue) 22:07 No.3510
Re: BeagleBone Black(6)
tinker 2013/09/03(Tue) 23:21 No.3511
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
}
>これってどこの情報ですか。
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
}
tinker 2013/09/03(Tue) 23:21 No.3511
Re: BeagleBone Black(6)
syu 2013/09/04(Wed) 15:14 No.3512
本日休日なので、昼過ぎから少し試してみました。
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
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
syu 2013/09/04(Wed) 15:14 No.3512
Re: BeagleBone Black(6)
yo 2013/09/04(Wed) 19:23 No.3513
tinkerさん
お答えありがとうございました。
ABSですか。mpdのビルドが簡単になるのなら、試してみますかね。しかし、
sed 's:AVCODEC_MAX_AUDIO_FRAME_SIZE:192000:g' -i src/decoder/ffmpeg_decoder_plugin.c
というのは随分乱暴な修正のしかただと思いますが(ハードコーディング)、どうなのですかね。まあ人のことはいえなけど(^^;;;。
お答えありがとうございました。
ABSですか。mpdのビルドが簡単になるのなら、試してみますかね。しかし、
sed 's:AVCODEC_MAX_AUDIO_FRAME_SIZE:192000:g' -i src/decoder/ffmpeg_decoder_plugin.c
というのは随分乱暴な修正のしかただと思いますが(ハードコーディング)、どうなのですかね。まあ人のことはいえなけど(^^;;;。
yo 2013/09/04(Wed) 19:23 No.3513
Re: BeagleBone Black(6)
yo 2013/09/04(Wed) 19:24 No.3514
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モードです。
とりあえず、こちらで分かっていることを書いておきます。
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 2013/09/04(Wed) 19:24 No.3514
Re: BeagleBone Black(6)
syu 2013/09/05(Thu) 20:04 No.3517
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
やはりこうやるのが王道ですね。
>あとは以下のスクリプトをブート時に起動
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
やはりこうやるのが王道ですね。
syu 2013/09/05(Thu) 20:04 No.3517
Re: BeagleBone Black(6)
tinker 2013/09/05(Thu) 20:17 No.3518
yoさん
>随分乱暴な修正のしかただと思いますが
Archは以前のVer（0.17.3だったかな）でも同じように修正しているみたいです。
まっ、動けばいいかと^^;
>chrt -f -p 49 `pgrep kworker/0:0`
wandboardで故あって同じこと試してるところでした。こちらでは、ksoftirqdを上げてみました。
debian，ubuntuはうまくいってるんですが、Archが・・・
今度、kworkerで試してみます。
>随分乱暴な修正のしかただと思いますが
Archは以前のVer（0.17.3だったかな）でも同じように修正しているみたいです。
まっ、動けばいいかと^^;
>chrt -f -p 49 `pgrep kworker/0:0`
wandboardで故あって同じこと試してるところでした。こちらでは、ksoftirqdを上げてみました。
debian，ubuntuはうまくいってるんですが、Archが・・・
今度、kworkerで試してみます。
tinker 2013/09/05(Thu) 20:17 No.3518
Re: BeagleBone Black(6)
yo 2013/09/06(Fri) 19:16 No.3521
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というやつがしつこく動いていることので、コイツが諸悪の頑強かなと考え、やってみました。
> やはりこうやるのが王道ですね。
ということなので、確実に再生中断が発生する環境で実験してみて下さい。
もっとも、これで再現するとますます謎は深まるのですが(^^;;;。
> 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というやつがしつこく動いていることので、コイツが諸悪の頑強かなと考え、やってみました。
> やはりこうやるのが王道ですね。
ということなので、確実に再生中断が発生する環境で実験してみて下さい。
もっとも、これで再現するとますます謎は深まるのですが(^^;;;。
yo 2013/09/06(Fri) 19:16 No.3521
Re: BeagleBone Black(6)
syu 2013/09/16(Mon) 15:25 No.3531
なかなか時間がとれなくて停滞しています。
>確実に再生中断が発生する環境で実験
私の試せる範囲では、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
では、また。
>確実に再生中断が発生する環境で実験
私の試せる範囲では、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 2013/09/16(Mon) 15:25 No.3531
Re: BeagleBone Black(6)
yo 2013/09/16(Mon) 21:28 No.3533
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版の登場待ちですね。
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版の登場待ちですね。
yo 2013/09/16(Mon) 21:28 No.3533
Re: BeagleBone Black(6)
まさまさ 2013/09/16(Mon) 23:28 No.3538
みなさま お久しぶりです。
コンパイル作業は私にはちょっと敷居が高くて、その後ずっとロムさせていただいておりました。
もしよければ現状でのイメージを公開していただけないでしょうか？
当方ＣＤリップした44.1KHz Flacがほとんどで、現状でも問題は発生しておらず、かなり良い音を楽しませていただいているのですが、みなさまのご苦労のたまものを、ぜひとも聞かせていただければと思っております。
どうぞよろしくお願い致します m(_ _)m
コンパイル作業は私にはちょっと敷居が高くて、その後ずっとロムさせていただいておりました。
もしよければ現状でのイメージを公開していただけないでしょうか？
当方ＣＤリップした44.1KHz Flacがほとんどで、現状でも問題は発生しておらず、かなり良い音を楽しませていただいているのですが、みなさまのご苦労のたまものを、ぜひとも聞かせていただければと思っております。
どうぞよろしくお願い致します m(_ _)m
まさまさ 2013/09/16(Mon) 23:28 No.3538
Re: BeagleBone Black(6)
syu 2013/09/17(Tue) 00:38 No.3539
まさまささん。
確かに、bbb/arch/rtoptとcubox/NFPserverを、imgかtar.gzで公開した方が話が進みますね。上手くいってない場合も皆で検討すれば突破口が見つかるかもしれません。しばし、お時間をいただきます。
確かに、bbb/arch/rtoptとcubox/NFPserverを、imgかtar.gzで公開した方が話が進みますね。上手くいってない場合も皆で検討すれば突破口が見つかるかもしれません。しばし、お時間をいただきます。
syu 2013/09/17(Tue) 00:38 No.3539
Re: BeagleBone Black(6)
yo 2013/09/17(Tue) 20:59 No.3541
syuさん
> 確かに、bbb/arch/rtoptとcubox/NFPserverを、imgかtar.gzで公開した方が話が進みますね。
気長にお待ちします。イメージ化するのが面倒なら、rootfs丸ごとtar.gzで十分だと思います。同じハード構成なのに、nasの違いで現れている現象はかなり差あるので、興味があります。
あと、Cubox+3.10.9+rt5+mpd-dsdの方は梅雨入り版に追加変更した部分だけtar化して公開するのは簡単ですが、興味のある方いますかね。
> 確かに、bbb/arch/rtoptとcubox/NFPserverを、imgかtar.gzで公開した方が話が進みますね。
気長にお待ちします。イメージ化するのが面倒なら、rootfs丸ごとtar.gzで十分だと思います。同じハード構成なのに、nasの違いで現れている現象はかなり差あるので、興味があります。
あと、Cubox+3.10.9+rt5+mpd-dsdの方は梅雨入り版に追加変更した部分だけtar化して公開するのは簡単ですが、興味のある方いますかね。
yo 2013/09/17(Tue) 20:59 No.3541
Re: BeagleBone Black(6)
m 2013/09/18(Wed) 22:46 No.3544
私も 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/
みなさん仰るとおり、良い音ですね！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/
m 2013/09/18(Wed) 22:46 No.3544
Re: BeagleBone Black(6)
syu 2013/09/21(Sat) 21:47 No.3551
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に変わってますね。
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 2013/09/21(Sat) 21:47 No.3551
Re: BeagleBone Black(6)
yo 2013/09/21(Sat) 22:18 No.3552
syuさん & 皆様
こちらも混乱の極みです。
> あと、Cubox+3.10.9+rt5+mpd-dsdの方は梅雨入り版に追加変更した部分だけtar化して公開するのは簡単ですが、興味のある方いますかね。
実は試してみたのですが、同じように奇怪な妖怪に遭遇しています。
tarボールを作り、梅雨入り版にに書き込んでみたのですが、駄目ですね。異常にcpu負荷が高くなり(ほとんど100%)、まともなdsd再生が出来なくなります。tarボールは3.10化した現用のcuboxシステムから作っていますので駄目になる理由がよくわからないのですよね。やっぱりarchには魔物が潜んでいるとしか思えません。ウームです。
こちらも混乱の極みです。
> あと、Cubox+3.10.9+rt5+mpd-dsdの方は梅雨入り版に追加変更した部分だけtar化して公開するのは簡単ですが、興味のある方いますかね。
実は試してみたのですが、同じように奇怪な妖怪に遭遇しています。
tarボールを作り、梅雨入り版にに書き込んでみたのですが、駄目ですね。異常にcpu負荷が高くなり(ほとんど100%)、まともなdsd再生が出来なくなります。tarボールは3.10化した現用のcuboxシステムから作っていますので駄目になる理由がよくわからないのですよね。やっぱりarchには魔物が潜んでいるとしか思えません。ウームです。
yo 2013/09/21(Sat) 22:18 No.3552
Re: BeagleBone Black(6)
まさまさ 2013/09/21(Sat) 22:49 No.3553
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 があるためなのです。
気長にお待ちしております♪
私の 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 があるためなのです。
まさまさ 2013/09/21(Sat) 22:49 No.3553
Re: BeagleBone Black(6)
コウ 2013/09/23(Mon) 16:37 No.3564
yo様、皆様
この度皆様のお陰で何とか運用にこぎ着けました。
改めてお礼を申し上げます。
電源をトランスを使用し、レギュレーターにはローノイズ型の
TPS7A47を使用したところかなりの音質アップとなりました。
スチッチング型のアダプターでは上記と同じ電源対策したvoyage starterkit(シンさんバージョン)の方が良い位でしたが、電源対策する事でBBBが化ます。
S/Nが上がり音の消えゆく様がよく分かり、アーティストの気配を感じる様です。
高音質化に電源対策は必須だと改めて感じた次第です。
以上、そんな事既に知っていると言われそうですが報告させて頂きました。
この度皆様のお陰で何とか運用にこぎ着けました。
改めてお礼を申し上げます。
電源をトランスを使用し、レギュレーターにはローノイズ型の
TPS7A47を使用したところかなりの音質アップとなりました。
スチッチング型のアダプターでは上記と同じ電源対策したvoyage starterkit(シンさんバージョン)の方が良い位でしたが、電源対策する事でBBBが化ます。
S/Nが上がり音の消えゆく様がよく分かり、アーティストの気配を感じる様です。
高音質化に電源対策は必須だと改めて感じた次第です。
以上、そんな事既に知っていると言われそうですが報告させて頂きました。
コウ 2013/09/23(Mon) 16:37 No.3564
Re: BeagleBone Black(6)
まさまさ 2013/09/24(Tue) 02:13 No.3565
> 皆様が実施されている kworker の処理を入れられれば、rt でもパチノイズなく再生できるのでは
今日は思い立って、0731rt で yo さんの No. 3514 の書き込み通りの方法でパチノイズが止まるかどうか、ちょっと敷居が高かったのですが頑張ってやってみました。
スクリプトを起動時に立ち上げるっていう技がわからず、ssh terminalで接続している root アカウントから起動して、プロンプトが返ってこない状態で確認しました。
結果ですが、192K, 96K FLAC ではまったく変化無しでした。
それで JAVS X-DDC の後の DAC が悪いのかと思い、96K まで対応している AV アンプに接続し、96K FLAC を再生してみたのですが、残念ながらまったく同じ状況でした。
ということで、rt のソフトに何か問題がありそうです。
しばし待つしかないみたいですね。
コウさん
電源対策いいですよねー。
私もそろそろ自作しようかと思っています。他の電流を食う機器でも使えるようにLM723のキットを使おうかなと計画しています。
今日は思い立って、0731rt で yo さんの No. 3514 の書き込み通りの方法でパチノイズが止まるかどうか、ちょっと敷居が高かったのですが頑張ってやってみました。
スクリプトを起動時に立ち上げるっていう技がわからず、ssh terminalで接続している root アカウントから起動して、プロンプトが返ってこない状態で確認しました。
結果ですが、192K, 96K FLAC ではまったく変化無しでした。
それで JAVS X-DDC の後の DAC が悪いのかと思い、96K まで対応している AV アンプに接続し、96K FLAC を再生してみたのですが、残念ながらまったく同じ状況でした。
ということで、rt のソフトに何か問題がありそうです。
しばし待つしかないみたいですね。
コウさん
電源対策いいですよねー。
私もそろそろ自作しようかと思っています。他の電流を食う機器でも使えるようにLM723のキットを使おうかなと計画しています。
まさまさ 2013/09/24(Tue) 02:13 No.3565
Re: BeagleBone Black(6)
コウ 2013/09/24(Tue) 19:19 No.3566
まさまさ様
今回手持ちのトランスで組んだ為、一時側電圧が高すぎなので暫定バージョンとしてます。
LM317で一旦電圧落としていますが、2つのレギュレーター共に熱々で常時電源on出来ません。
このままでは怖くてケースに蓋出来ないのでトランス調達し組み直すつもりです。
今回手持ちのトランスで組んだ為、一時側電圧が高すぎなので暫定バージョンとしてます。
LM317で一旦電圧落としていますが、2つのレギュレーター共に熱々で常時電源on出来ません。
このままでは怖くてケースに蓋出来ないのでトランス調達し組み直すつもりです。
コウ 2013/09/24(Tue) 19:19 No.3566
Re: BeagleBone Black(6)
syu 2013/09/28(Sat) 14:02 No.3567
皆様
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
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
syu 2013/09/28(Sat) 14:02 No.3567
Re: BeagleBone Black(6)
syu 2013/09/28(Sat) 19:52 No.3569
皆様
私の環境限定ですが、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ができます。
皆様、ご試用よろしく。
私の環境限定ですが、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 2013/09/28(Sat) 19:52 No.3569
Re: BeagleBone Black(6)
まさまさ 2013/09/29(Sun) 02:00 No.3570
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版で当面過ごすのが良さそうです。
どうもありがとうございました 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版で当面過ごすのが良さそうです。
まさまさ 2013/09/29(Sun) 02:00 No.3570
Re: BeagleBone Black(6)
yo 2013/09/29(Sun) 17:40 No.3571
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負荷、ロードアベレージなど)のに、トラブルは僕のところでしか発生しないというのが不思議ですね。
音は今回のイメージの方が良いようです。
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負荷、ロードアベレージなど)のに、トラブルは僕のところでしか発生しないというのが不思議ですね。
音は今回のイメージの方が良いようです。
yo 2013/09/29(Sun) 17:40 No.3571
Re: BeagleBone Black(6)
yo 2013/09/29(Sun) 20:05 No.3572
直前のメッセージを書き込むちょっと前に、リピートモードにして連続再生していますが、3時間位、止まりませんね。一体どうなっているのだろう。このイメージ、エージングされるのですかね。top画面の状況に変化はありません。もう訳がわからん状態ですね。
yo 2013/09/29(Sun) 20:05 No.3572
Re: BeagleBone Black(6)
まさまさ 2013/09/30(Mon) 01:31 No.3573
ちょっと気になることがあり、もう一度試してみました。
実は他の方の設定を参考にしていて、fstab の cifs 接続で rsize,wsizeに関しては何も設定していなかったので、rsize=130048,wsize=4096 を追加してみました。
これを設定したところ、0731rt では 44.1K ではパチ音無し、96K, 192K ではパチ音ありますが、発生間隔がかなり長くなりました。
次に syu さんのイメージで同様に試したところ、やはり改善されたのですが、44.1K では若干パチ音ありになりました。
発生間隔ですが、一定間隔ではありませんので、何かのタイミングでCPU負荷がたまたま高くなったときに発生するのかもしれません。
とりあえず、0731rt では使えることがわかりましたので、大収穫です！
でも、syu さんのイメージが一番音が良いので、なんとかしてみたいです。不必要なプロセスなどを止めれば良いのでしょうけど、何を削ってよいやら。。。
実は他の方の設定を参考にしていて、fstab の cifs 接続で rsize,wsizeに関しては何も設定していなかったので、rsize=130048,wsize=4096 を追加してみました。
これを設定したところ、0731rt では 44.1K ではパチ音無し、96K, 192K ではパチ音ありますが、発生間隔がかなり長くなりました。
次に syu さんのイメージで同様に試したところ、やはり改善されたのですが、44.1K では若干パチ音ありになりました。
発生間隔ですが、一定間隔ではありませんので、何かのタイミングでCPU負荷がたまたま高くなったときに発生するのかもしれません。
とりあえず、0731rt では使えることがわかりましたので、大収穫です！
でも、syu さんのイメージが一番音が良いので、なんとかしてみたいです。不必要なプロセスなどを止めれば良いのでしょうけど、何を削ってよいやら。。。
まさまさ 2013/09/30(Mon) 01:31 No.3573
Re: BeagleBone Black(6)
syu 2013/09/30(Mon) 18:50 No.3574
まさまささん
お試し、ありがとうございます。
パチノイズは、うちでも稀に出ます。
もっとも過酷な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カードからの方が不利なんです。何が起きてるのかな。
お試し、ありがとうございます。
パチノイズは、うちでも稀に出ます。
もっとも過酷な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カードからの方が不利なんです。何が起きてるのかな。
syu 2013/09/30(Mon) 18:50 No.3574
Re: BeagleBone Black(6)
syu 2013/09/30(Mon) 19:02 No.3575
yoさん、お試しありがとうございます。
アップロードしたファイルは最新版をそのままインストールし、pacman -Syuした後、固定IPにし、rtsetを起動させ、mpd-dsd-rtoptを新しくコンパイルしただけのものです。特殊な魔法はかけていません。
>エージングされるのですかね。
書きませんでしたが、実はうちでも、インストールした最初だけ、dsdが数分～10分ぐらいで止まります。
”一時停止 > 再生”でやり過ごすと、その後は停止しなくなる。
理由は不明ですが、sdカードをミュージックディレクトリに指定するとすぐ落ちたりしますので、LANのどこかが学習しているのかなと、ボンヤリ考えてます。
cpu負荷は、起動する度に変動します。今のところランダムに運次第です。演奏開始した初期の値が高いと、ずっとそのままです。topで表示される負荷の大小と音は無相関な印象ですが、音の良し悪しも、cpu負荷とは無関係に、起動する度に変化しているような印象です。
iriverのサンプルdffでScarlattiは曲の終わりでクラッシュしてましたが、今度のrootfsではクラッシュしません。曲の終わりで音が消え、プログレスバーは次の曲に移動。”一時停止 > 再生”で音が復活します。e-onkyoの２Lレーベルの曲で発生するのと同じ現象です。
まあ、当分は、手に負えませんね(^^;
アップロードしたファイルは最新版をそのままインストールし、pacman -Syuした後、固定IPにし、rtsetを起動させ、mpd-dsd-rtoptを新しくコンパイルしただけのものです。特殊な魔法はかけていません。
>エージングされるのですかね。
書きませんでしたが、実はうちでも、インストールした最初だけ、dsdが数分～10分ぐらいで止まります。
”一時停止 > 再生”でやり過ごすと、その後は停止しなくなる。
理由は不明ですが、sdカードをミュージックディレクトリに指定するとすぐ落ちたりしますので、LANのどこかが学習しているのかなと、ボンヤリ考えてます。
cpu負荷は、起動する度に変動します。今のところランダムに運次第です。演奏開始した初期の値が高いと、ずっとそのままです。topで表示される負荷の大小と音は無相関な印象ですが、音の良し悪しも、cpu負荷とは無関係に、起動する度に変化しているような印象です。
iriverのサンプルdffでScarlattiは曲の終わりでクラッシュしてましたが、今度のrootfsではクラッシュしません。曲の終わりで音が消え、プログレスバーは次の曲に移動。”一時停止 > 再生”で音が復活します。e-onkyoの２Lレーベルの曲で発生するのと同じ現象です。
まあ、当分は、手に負えませんね(^^;
syu 2013/09/30(Mon) 19:02 No.3575
Re: BeagleBone Black(6)
まさまさ 2013/09/30(Mon) 22:47 No.3576
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 にして聞いていますが、昨晩と比較してそんなにパチノイズが発生せず、気にならないレベルになってきました。
当面これで様子見してみます♪
色々と情報をありがとうございます。
SD-Card にコピーしてやってみましたが、syu さんと同じで、
SD-Card の方がパチノイズが良く出るようになってしまいました。
ちょっと調べてみたら、どうもバグっぽいです。
https://groups.google.com/forum/#" target="_blank">https://groups.google.com/forum/#!topic/beagleboard/fOGeXCub9OY
チップの設定を間違っているらしくスピードが出ないみたいです。どうやらパッチもあるみたいです（パッと見で、英語ちゃんと読んでませんが、なんとなくそんな感じみたいです）。。。
もしかして、このパッチで直りませんかね？例えば何かログをSDに書き込もうとして遅いので、処理が待たされ、結果としてパチノイズ発生やDSDが止まってしまうとか。。。
（当たってないだろうなぁ。。。笑）
ちなみに、今は rsize=512000 にして聞いていますが、昨晩と比較してそんなにパチノイズが発生せず、気にならないレベルになってきました。
当面これで様子見してみます♪
まさまさ 2013/09/30(Mon) 22:47 No.3576
Re: BeagleBone Black(6)
m 2013/09/30(Mon) 23:20 No.3577
syuさん
BBB Archアップロードありがとうございました。私も試してみました。
私の環境でも再現性が今一つで報告遅くなりましたが、
DSDは最初数分でstopし、再起動後は数時間大丈夫な場合が多いので、syuさんyoさんと概ね一緒のようです。
>LANのどこかが学習しているのかなと、ボンヤリ考えてます。
Hubでしょうか？
音は落ち着いたやさしい感じですね。
私の環境と音源では 0731rt の方が好みですが、
上流でこれだけ変わるのも面白いですね。
BBB Archアップロードありがとうございました。私も試してみました。
私の環境でも再現性が今一つで報告遅くなりましたが、
DSDは最初数分でstopし、再起動後は数時間大丈夫な場合が多いので、syuさんyoさんと概ね一緒のようです。
>LANのどこかが学習しているのかなと、ボンヤリ考えてます。
Hubでしょうか？
音は落ち着いたやさしい感じですね。
私の環境と音源では 0731rt の方が好みですが、
上流でこれだけ変わるのも面白いですね。
m 2013/09/30(Mon) 23:20 No.3577
Re: BeagleBone Black(6)
syu 2013/10/01(Tue) 00:34 No.3578
まさまささん
情報ありがとうございます。
パッチ当てはよくわかりませんが、同じ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
とやって通常カーネルに戻しておいた方が、問題が起きにくいと思います。
情報ありがとうございます。
パッチ当てはよくわかりませんが、同じ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
とやって通常カーネルに戻しておいた方が、問題が起きにくいと思います。
syu 2013/10/01(Tue) 00:34 No.3578
Re: BeagleBone Black(6)
syu 2013/10/01(Tue) 00:53 No.3579
mさん、ありがとうございます。
>私の環境と音源では 0731rt の方が好み
実はまだ試していません(^^;;; あとで比較してみますね。
>私の環境と音源では 0731rt の方が好み
実はまだ試していません(^^;;; あとで比較してみますね。
syu 2013/10/01(Tue) 00:53 No.3579
Re: BeagleBone Black(6)
まさまさ 2013/10/01(Tue) 00:59 No.3580
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 さんお察しの通り、直りません。。。
気持ち、パチノイズが少なくなったかな？くらいでした。
残念！
やっぱり、当たってませんでしたね（苦笑）
一からコンパイルするのではなさそうだったので、パッチあてにチャレンジしてみました。
# 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 さんお察しの通り、直りません。。。
気持ち、パチノイズが少なくなったかな？くらいでした。
残念！
まさまさ 2013/10/01(Tue) 00:59 No.3580
Re: BeagleBone Black(6)
syu 2013/10/01(Tue) 20:42 No.3582
アップグレードで入るbbb/archの最新カーネルは、いきなり3.12.0-rc2-1-ARCHになっていますが、このカーネルでは bus-width = <0x4>; がちゃんと記述されていました。
3.12-rtが出ると良いですね。
3.12-rtが出ると良いですね。
syu 2013/10/01(Tue) 20:42 No.3582
Re: BeagleBone Black(6)
yo 2013/10/01(Tue) 21:03 No.3583
syuさん
ご返事ありがとうございます。肝心な部分はいまだ闇の中ですが、大分いろいろなことが分かってきましたかね。
> cpu負荷は、起動する度に変動します。
僕のところは文字通りエージングされます。長い時間再生を続けていると良くなります。
ただし、cuboxと異なり今のところ10%以下になることはありません。再生中で試聴している時は、nexus7 ssh端末のtop画面とにらめっこしながら聴いていますが、再生中断はcpu負荷が大きくなった時に発生しています。
インスール直後のまったくエージングされていない時に負荷は極端(50%)に高くなるのですが、これはarch環境の初期化のプロセスがいろいろ動いているためのように見えます(例えばmandbなんかが動いています)。
その後、安定して10%台前半に収まるのですが、時々数十秒のレベルで50%位に跳ね上がるのですよね。この理由がよく分かりません。この状態で再生中断せず連続演奏できるとだんだんcpu負荷が跳ね上がる頻度が低くなり、1時間以上再生続行できている場合は10%台で安定して再生が続きます。
rtカーネルの割り込み処理関連のプロセス管理に起因する障害じゃないかと思います。何か問題があるのでしょうね。lanだと起きにくくなるというのが解せないのですが。
ご返事ありがとうございます。肝心な部分はいまだ闇の中ですが、大分いろいろなことが分かってきましたかね。
> cpu負荷は、起動する度に変動します。
僕のところは文字通りエージングされます。長い時間再生を続けていると良くなります。
ただし、cuboxと異なり今のところ10%以下になることはありません。再生中で試聴している時は、nexus7 ssh端末のtop画面とにらめっこしながら聴いていますが、再生中断はcpu負荷が大きくなった時に発生しています。
インスール直後のまったくエージングされていない時に負荷は極端(50%)に高くなるのですが、これはarch環境の初期化のプロセスがいろいろ動いているためのように見えます(例えばmandbなんかが動いています)。
その後、安定して10%台前半に収まるのですが、時々数十秒のレベルで50%位に跳ね上がるのですよね。この理由がよく分かりません。この状態で再生中断せず連続演奏できるとだんだんcpu負荷が跳ね上がる頻度が低くなり、1時間以上再生続行できている場合は10%台で安定して再生が続きます。
rtカーネルの割り込み処理関連のプロセス管理に起因する障害じゃないかと思います。何か問題があるのでしょうね。lanだと起きにくくなるというのが解せないのですが。
yo 2013/10/01(Tue) 21:03 No.3583
Re: BeagleBone Black(6)
syu 2013/10/01(Tue) 23:53 No.3584
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再生が中断するということなんでしょうね。
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 2013/10/01(Tue) 23:53 No.3584
Re: BeagleBone Black(6)
yo 2013/10/02(Wed) 20:55 No.3585
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負荷が高くなると大きくなりますが、そうでない場合もありますね)。
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 2013/10/02(Wed) 20:55 No.3585
Re: BeagleBone Black(6)
m 2013/10/04(Fri) 02:30 No.3586
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に減ります。）
状況報告でした。
再起動直後から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 2013/10/04(Fri) 02:30 No.3586
Re: BeagleBone Black(6)
yo 2013/10/04(Fri) 19:03 No.3587
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さんはどういう具合にされたのでしょうか。
データの公開ありがとうございます。興味深く拝見しました。なるほどなぁという感じです。
サーバのチューニングなどで、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さんはどういう具合にされたのでしょうか。
yo 2013/10/04(Fri) 19:03 No.3587
Re: BeagleBone Black(6)
syu 2013/10/04(Fri) 20:00 No.3588
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秒おきに移動平均を表示するようですね。
興味深いデータ、ありがとうございます。
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 2013/10/04(Fri) 20:00 No.3588
Re: BeagleBone Black(6)
yo 2013/10/04(Fri) 21:31 No.3589
syuさん
cプログラミングする覚悟があれば、このページの情報は参考になりませんか。
http://d.hatena.ne.jp/naoya/20070518/1179492085" target="_blank">http://d.hatena.ne.jp/naoya/20070518/1179492085
まあ、僕はパスです(^^;;;。
cプログラミングする覚悟があれば、このページの情報は参考になりませんか。
http://d.hatena.ne.jp/naoya/20070518/1179492085" target="_blank">http://d.hatena.ne.jp/naoya/20070518/1179492085
まあ、僕はパスです(^^;;;。
yo 2013/10/04(Fri) 21:31 No.3589
Re: BeagleBone Black(6)
m 2013/10/04(Fri) 22:16 No.3590
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
（出来たとしても音は悪くなりそうなので、僕もパスですが(^^;;;）
ずっと使うものでもないので、特別なことはしていません（笑）。
今回は 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
（出来たとしても音は悪くなりそうなので、僕もパスですが(^^;;;）
m 2013/10/04(Fri) 22:16 No.3590
Re: BeagleBone Black(6)
yo 2013/10/05(Sat) 17:16 No.3591
皆様
システムモニタ用のツールを調べてみました。
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/
システムモニタ用のツールを調べてみました。
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/
yo 2013/10/05(Sat) 17:16 No.3591
Re: BeagleBone Black(6)
syu 2013/10/06(Sun) 14:48 No.3592
皆様
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
後ほど再アップロードします。
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 2013/10/06(Sun) 14:48 No.3592
Re: BeagleBone Black(6)
まさまさ 2013/10/06(Sun) 23:48 No.3593
syu さん
いつもどうもありがとうございます！
残念ながら、私の flac (44.1K, 96K, 192K)ではほとんど変化はわかりませんでした。
しかし早く根本原因が判って修正されると良いですよね。
どこかに書き込んだら、コード書いた人が気づいてくれたりしないですかねぇ。。。
いつもどうもありがとうございます！
残念ながら、私の flac (44.1K, 96K, 192K)ではほとんど変化はわかりませんでした。
しかし早く根本原因が判って修正されると良いですよね。
どこかに書き込んだら、コード書いた人が気づいてくれたりしないですかねぇ。。。
まさまさ 2013/10/06(Sun) 23:48 No.3593
Re: BeagleBone Black(6)
syu 2013/10/07(Mon) 22:24 No.3595
皆様
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
騒ぎが伝わって、何とかなると良いですね。
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
騒ぎが伝わって、何とかなると良いですね。
syu 2013/10/07(Mon) 22:24 No.3595
Re: BeagleBone Black(6)
yo 2013/10/08(Tue) 21:32 No.3598
このスレッド、長くなったので、新しいスレッドに移行します。新スレッドのタイトルは「BeagleBone Black(7)」です(最長不倒ですね)。
yo 2013/10/08(Tue) 21:32 No.3598
cuboxでsamba
ご無沙汰しています。
dsdでの音消え現象について、nasをあれこれ変えて試していました。
たまたま手元にあったalix3d2/voyage、cubox-pro/arch、amd-e350-pc/archなどにsambaを入れ、mpdは停止し、smb/cifsサーバを構築してみましたが、今のところ、どれも音消え解消には至っていません。
私の環境でのbbbは、qnap ts-212をcifsで使う場合に限ってdsdの音消え現象が（ほぼ）皆無ですが、次にマシなのは3.8.11-rt8にしたcubox/archでした。cpuパワーがあるe-350/archは、cubox/archより高頻度にdsdで音が消えます。
この過程で、サーバが変わると音も大幅に変わる経験をしました。音で比較すれば、cuboxRT >> e-350 > ts-212 >> alix3d2の順に劣化すると思います。nasをts-212からcuboxRTに変えたときの印象は、mpdでcuboxからbbbに変えたときの差より大きい気がします。録音側の機材の固有音がはっきり認識できます。
bbbの影で遊んでいるcuboxをお持ちの方は(^^;;;;、お試しのうえ、ご意見をお聞かせください。
sambaの設定は以下のようにしました。
#nano /etc/samba/smb.conf
workgroup = WORKGROUP
server string = Samba Server
log file = /var/log/samba/%m.log
max log size = 1024
dns proxy = no
[Public]
comment = Public
read only = no
locking = no
path = /Public
guest ok = yes
※ /Publicの下に/Musicがあります。
arch linuxでは pacman -S samba で必要なものはすべて入りますが、梅雨入り版の公開以後にarch linuxのファイル構造が変更になっていますので、pacman -Syu で怒られます。
https://www.archlinux.org/news/binaries-move-to-usrbin-requiring-update-intervention/" target="_blank">https://www.archlinux.org/news/binaries-move-to-usrbin-requiring-update-intervention/
対策はあるのですが、面倒ですので、新しくインストールした方が楽だと思います。
cuboxではarch以外まだ試していませんが、cubox/3.8.11-rt8/archでsamba向けにts212の安定性に迫るべくチューニングするとしたら、どんな手段があるのか、ご意見をお聞かせください。
Re: cuboxでsamba
syu 2013/08/23(Fri) 22:29 No.3446
ベテランの皆さんには余計なことですが、私自身のミス発見のため、私がやったsambaインストールの方法を記しておきます。
まずは、yoさんの「サルでも作れる MPD on Arch Linux」を参考にしてください。
http://www.symphonic-net.com/kubotayo/articles/articles015.html#001" target="_blank">http://www.symphonic-net.com/kubotayo/articles/articles015.html#001
次にarch-wikiの「Samba (日本語)」を参考に、作業します。
https://wiki.archlinux.org/index.php/Samba_%28%E6%97%A5%E6%9C%AC%E8%AA%9E%29" target="_blank">https://wiki.archlinux.org/index.php/Samba_%28%E6%97%A5%E6%9C%AC%E8%AA%9E%29
# pacman -Syy
# pacman -Syu
# pacman -S samba
usb-hdd(/dev/sda1)をマウント
# mkdir /Public
# nano /etc/fstab
(追加)
/dev/sda1 /Public ext4 defaults 0 0
# mount -a
smb.confを設定
# nano /etc/samba/smb.conf
workgroup = WORKGROUP
server string = Samba Server
log file = /var/log/samba/%m.log
max log size = 1024
dns proxy = no
[Public]
comment = Public
read only = no
locking = no
path = /Public
guest ok = yes
ユーザーを追加
# pdbedit -a root
smbd、nmbdサービスを開始
# systemctl enable smbd.service
# systemctl enable nmbd.service
# systemctl start smbd.service
# systemctl start nmbd.service
これだけですが、間違いを発見された方は、よろしくご指摘お願いします。
まずは、yoさんの「サルでも作れる MPD on Arch Linux」を参考にしてください。
http://www.symphonic-net.com/kubotayo/articles/articles015.html#001" target="_blank">http://www.symphonic-net.com/kubotayo/articles/articles015.html#001
次にarch-wikiの「Samba (日本語)」を参考に、作業します。
https://wiki.archlinux.org/index.php/Samba_%28%E6%97%A5%E6%9C%AC%E8%AA%9E%29" target="_blank">https://wiki.archlinux.org/index.php/Samba_%28%E6%97%A5%E6%9C%AC%E8%AA%9E%29
# pacman -Syy
# pacman -Syu
# pacman -S samba
usb-hdd(/dev/sda1)をマウント
# mkdir /Public
# nano /etc/fstab
(追加)
/dev/sda1 /Public ext4 defaults 0 0
# mount -a
smb.confを設定
# nano /etc/samba/smb.conf
workgroup = WORKGROUP
server string = Samba Server
log file = /var/log/samba/%m.log
max log size = 1024
dns proxy = no
[Public]
comment = Public
read only = no
locking = no
path = /Public
guest ok = yes
ユーザーを追加
# pdbedit -a root
smbd、nmbdサービスを開始
# systemctl enable smbd.service
# systemctl enable nmbd.service
# systemctl start smbd.service
# systemctl start nmbd.service
これだけですが、間違いを発見された方は、よろしくご指摘お願いします。
syu 2013/08/23(Fri) 22:29 No.3446
Re: cuboxでsamba
m 2013/08/24(Sat) 00:11 No.3448
syu さん
NAS の実験、大変興味深く拝見しました。
（私も NSC2100GT＞＞EX490 という経験をしたので分かります）
そうですか、CuBox はサーバとして使っても良いですか（もう1台ポチっちゃおうかな？）
本題のdsdでの音消えについて
症状は No.2414 の ① に似ていたりしますか？
私の環境では、結局 Hub の交換で解決しました。
（確か Buffalo → アライドテレシス）
参考になれば幸いです。
NAS の実験、大変興味深く拝見しました。
（私も NSC2100GT＞＞EX490 という経験をしたので分かります）
そうですか、CuBox はサーバとして使っても良いですか（もう1台ポチっちゃおうかな？）
本題のdsdでの音消えについて
症状は No.2414 の ① に似ていたりしますか？
私の環境では、結局 Hub の交換で解決しました。
（確か Buffalo → アライドテレシス）
参考になれば幸いです。
m 2013/08/24(Sat) 00:11 No.3448
Re: cuboxでsamba
まさまさ 2013/08/24(Sat) 03:26 No.3451
Syu さん
同じこと考えてる方がいらしたんですね～
実は私も余った CuBox で NAS していました（笑）
今まで、MZK-USBSV という簡易NASみたいなものがあまりにしょぼいので、急遽切り替えた次第です。
nfsd を追加して BBB とは nfs で接続し、CD Ripping 用のPCとは samba で cifs で接続しています。
それから、eSATA 接続とUSB接続で２台のハードディスクをつないでいて、rsync でバックアップを取っています。
現在、それを crontab で真夜中にバッチ処理しようとして調べているところでした。
こちらは、まだrt化はしていないarch linux を使用していますが、
確かに安心して聞いていられる音になっています。
同じこと考えてる方がいらしたんですね～
実は私も余った CuBox で NAS していました（笑）
今まで、MZK-USBSV という簡易NASみたいなものがあまりにしょぼいので、急遽切り替えた次第です。
nfsd を追加して BBB とは nfs で接続し、CD Ripping 用のPCとは samba で cifs で接続しています。
それから、eSATA 接続とUSB接続で２台のハードディスクをつないでいて、rsync でバックアップを取っています。
現在、それを crontab で真夜中にバッチ処理しようとして調べているところでした。
こちらは、まだrt化はしていないarch linux を使用していますが、
確かに安心して聞いていられる音になっています。
まさまさ 2013/08/24(Sat) 03:26 No.3451
Re: cuboxでsamba
yo 2013/08/24(Sat) 13:34 No.3453
syuさん&皆様
実は僕も同じようなことをやっていました。ただ結果が非常に不思議なのですよね。
SheevaPlugとRaspberryPIをサーバ機にして二台のnasを作成し、運用しているのですが、問題のdsd再生でSheevaPlugは簡単に発生、RaspberryPIはほとんど発生しないという現象に遭遇しています。
不思議なのはこの二台のnas、性能にかなりの差があります。CrystalDiskMarkというWindowプログラムでの測定結果です。上がSheevaPlug、下がRaspberryPIです。
-----------------------------------------------------------------------
CrystalDiskMark 3.0.2 (C) 2007-2013 hiyohiyo
Crystal Dew World : http://crystalmark.info/" target="_blank">http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]
Sequential Read : 9.250 MB/s
Sequential Write : 11.544 MB/s
Random Read 512KB : 8.067 MB/s
Random Write 512KB : 11.366 MB/s
Random Read 4KB (QD=1) : 0.577 MB/s [ 140.8 IOPS]
Random Write 4KB (QD=1) : 3.531 MB/s [ 862.2 IOPS]
Random Read 4KB (QD=32) : 0.629 MB/s [ 153.6 IOPS]
Random Write 4KB (QD=32) : 6.828 MB/s [ 1667.1 IOPS]
Test : 1000 MB [Z: 71.8% (1277.6/1780.0 GB)] (x5)
Date : 2013/08/24 10:08:26
OS : Windows 7 Home Premium Edition SP1 [6.1 Build 7601] (x86)
-----------------------------------------------------------------------
Sequential Read : 7.376 MB/s
Sequential Write : 10.976 MB/s
Random Read 512KB : 6.501 MB/s
Random Write 512KB : 10.619 MB/s
Random Read 4KB (QD=1) : 0.433 MB/s [ 105.8 IOPS]
Random Write 4KB (QD=1) : 1.699 MB/s [ 414.9 IOPS]
Random Read 4KB (QD=32) : 0.467 MB/s [ 114.0 IOPS]
Random Write 4KB (QD=32) : 2.776 MB/s [ 677.8 IOPS]
Test : 1000 MB [Y: 36.9% (676.3/1833.8 GB)] (x5)
Date : 2013/08/24 11:04:10
OS : Windows 7 Home Premium Edition SP1 [6.1 Build 7601] (x86)
ご覧の通りRaspberryPIの方が多少性能が低いのですが、問題は発生しないのですよね。謎です。
ちなみにRaspberryPIで再生し、nexus7にcuboxのtop画面を表示しぱなっしにすると、まず再生中断しません。
この場合ネットワーク負荷の条件も通常時より悪くなっているはずなので、「どうなっているのだろか」と狐につままれたという心境です。
実は僕も同じようなことをやっていました。ただ結果が非常に不思議なのですよね。
SheevaPlugとRaspberryPIをサーバ機にして二台のnasを作成し、運用しているのですが、問題のdsd再生でSheevaPlugは簡単に発生、RaspberryPIはほとんど発生しないという現象に遭遇しています。
不思議なのはこの二台のnas、性能にかなりの差があります。CrystalDiskMarkというWindowプログラムでの測定結果です。上がSheevaPlug、下がRaspberryPIです。
-----------------------------------------------------------------------
CrystalDiskMark 3.0.2 (C) 2007-2013 hiyohiyo
Crystal Dew World : http://crystalmark.info/" target="_blank">http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]
Sequential Read : 9.250 MB/s
Sequential Write : 11.544 MB/s
Random Read 512KB : 8.067 MB/s
Random Write 512KB : 11.366 MB/s
Random Read 4KB (QD=1) : 0.577 MB/s [ 140.8 IOPS]
Random Write 4KB (QD=1) : 3.531 MB/s [ 862.2 IOPS]
Random Read 4KB (QD=32) : 0.629 MB/s [ 153.6 IOPS]
Random Write 4KB (QD=32) : 6.828 MB/s [ 1667.1 IOPS]
Test : 1000 MB [Z: 71.8% (1277.6/1780.0 GB)] (x5)
Date : 2013/08/24 10:08:26
OS : Windows 7 Home Premium Edition SP1 [6.1 Build 7601] (x86)
-----------------------------------------------------------------------
Sequential Read : 7.376 MB/s
Sequential Write : 10.976 MB/s
Random Read 512KB : 6.501 MB/s
Random Write 512KB : 10.619 MB/s
Random Read 4KB (QD=1) : 0.433 MB/s [ 105.8 IOPS]
Random Write 4KB (QD=1) : 1.699 MB/s [ 414.9 IOPS]
Random Read 4KB (QD=32) : 0.467 MB/s [ 114.0 IOPS]
Random Write 4KB (QD=32) : 2.776 MB/s [ 677.8 IOPS]
Test : 1000 MB [Y: 36.9% (676.3/1833.8 GB)] (x5)
Date : 2013/08/24 11:04:10
OS : Windows 7 Home Premium Edition SP1 [6.1 Build 7601] (x86)
ご覧の通りRaspberryPIの方が多少性能が低いのですが、問題は発生しないのですよね。謎です。
ちなみにRaspberryPIで再生し、nexus7にcuboxのtop画面を表示しぱなっしにすると、まず再生中断しません。
この場合ネットワーク負荷の条件も通常時より悪くなっているはずなので、「どうなっているのだろか」と狐につままれたという心境です。
yo 2013/08/24(Sat) 13:34 No.3453
Re: cuboxでsamba
tinker 2013/08/24(Sat) 14:01 No.3455
syuさん
最近お見かけしないと思っていたら、なんか楽しそうなことやってたんですね。
すでにご覧になっているかと思いますが、3.10のRT化で新しい発見がありました。BBBでも効果があるかもしれません。
以上、ちゃちゃ＆お知らせでした。
最近お見かけしないと思っていたら、なんか楽しそうなことやってたんですね。
すでにご覧になっているかと思いますが、3.10のRT化で新しい発見がありました。BBBでも効果があるかもしれません。
以上、ちゃちゃ＆お知らせでした。
tinker 2013/08/24(Sat) 14:01 No.3455
Re: cuboxでsamba
syu 2013/08/24(Sat) 16:15 No.3456
mさん
nasで音質はかなり変わりますよね <(^^;
○ gmpc は再生を続けているように見えるが演奏はstop
○ fs=2.8MHz だったのが、fs=176kHz に変わってしまう。
○ gmpc stop→play で再生再開する
○ エラーメッセージなくランダムに発生
まったく同じ症状です。スイッチの安定性ですかね・・
mさんの情報、ちょうど良いタイミングでした。mpdまわりだけハブを専用にしようと、何が適当か考えてた所でした。アライドテレシス良さそうですね。ポート毎にあれこれ設定できるので、CentreCOM GS908XLにしようかと思っています。
No.2451によれば、ハブでも音が変わるのですね。音消えが減って音が静かで透明感が増す可能性がある。ぜひとも試さなければ(笑
nasで音質はかなり変わりますよね <(^^;
○ gmpc は再生を続けているように見えるが演奏はstop
○ fs=2.8MHz だったのが、fs=176kHz に変わってしまう。
○ gmpc stop→play で再生再開する
○ エラーメッセージなくランダムに発生
まったく同じ症状です。スイッチの安定性ですかね・・
mさんの情報、ちょうど良いタイミングでした。mpdまわりだけハブを専用にしようと、何が適当か考えてた所でした。アライドテレシス良さそうですね。ポート毎にあれこれ設定できるので、CentreCOM GS908XLにしようかと思っています。
No.2451によれば、ハブでも音が変わるのですね。音消えが減って音が静かで透明感が増す可能性がある。ぜひとも試さなければ(笑
syu 2013/08/24(Sat) 16:15 No.3456
Re: cuboxでsamba
syu 2013/08/24(Sat) 16:39 No.3457
まさまささん
さすが、いろいろ試されたんですね。
実は、うちでは、cifsとnfsの共存が出来なくて、おかしな状態です。も少し調べてから、あらためて教えていただこうかと思っていますので、よろしく。
さすが、いろいろ試されたんですね。
実は、うちでは、cifsとnfsの共存が出来なくて、おかしな状態です。も少し調べてから、あらためて教えていただこうかと思っていますので、よろしく。
syu 2013/08/24(Sat) 16:39 No.3457
Re: cuboxでsamba
syu 2013/08/24(Sat) 16:57 No.3458
yoさん
>結果が非常に不思議
わたしの場合も、alixがダメで、比較的パワフルなe350にしてもダメで、e350よりかなり遅いMarvell 6281 1.2GHzのts-212が消えないのですから、不思議なんですよね。
インテル系だとダメなのかと、ts-212と同じarm系のcuboxにしたら、音消えがかなり減少。これは上手く行ったと最初は思った位、音消えの頻度は減りました。
今度は、ハブ追加を試して見ます。
>結果が非常に不思議
わたしの場合も、alixがダメで、比較的パワフルなe350にしてもダメで、e350よりかなり遅いMarvell 6281 1.2GHzのts-212が消えないのですから、不思議なんですよね。
インテル系だとダメなのかと、ts-212と同じarm系のcuboxにしたら、音消えがかなり減少。これは上手く行ったと最初は思った位、音消えの頻度は減りました。
今度は、ハブ追加を試して見ます。
syu 2013/08/24(Sat) 16:57 No.3458
Re: cuboxでsamba
m 2013/08/24(Sat) 17:00 No.3459
syu さん
ビンゴでしたか（笑）
同じ規格の Hub だったので不思議ではありますが、アライドテレシス良かったです（というかたぶんこれが正常）。
私は（光メディアコンバータの 100M 律速で）1G は試していませんが、100M の方が音がよいという記事を見たことがあります。
アライドテレシスの中で幾つか試した結果、今は FS708XL を使っています。
古いモデル＞新しいモデルという傾向はあるようです（省エネもやり過ぎると？）。
それから、HDD にも結構な音質の違いがあります。(^^;
つまり何をいじっても変わるってことで、
この辺はしばらく楽しめそうですね（笑）。
ビンゴでしたか（笑）
同じ規格の Hub だったので不思議ではありますが、アライドテレシス良かったです（というかたぶんこれが正常）。
私は（光メディアコンバータの 100M 律速で）1G は試していませんが、100M の方が音がよいという記事を見たことがあります。
アライドテレシスの中で幾つか試した結果、今は FS708XL を使っています。
古いモデル＞新しいモデルという傾向はあるようです（省エネもやり過ぎると？）。
それから、HDD にも結構な音質の違いがあります。(^^;
つまり何をいじっても変わるってことで、
この辺はしばらく楽しめそうですね（笑）。
m 2013/08/24(Sat) 17:00 No.3459
Re: cuboxでsamba
syu 2013/08/24(Sat) 17:07 No.3460
tinkerさん
3.10-rtがbbbで使えて、結果が改善されると嬉しいです。期待してます。(^^;;;
3.10-rtがbbbで使えて、結果が改善されると嬉しいです。期待してます。(^^;;;
syu 2013/08/24(Sat) 17:07 No.3460
Re: cuboxでsamba
yo 2013/08/24(Sat) 17:22 No.3462
syuさん
> 実は、うちでは、cifsとnfsの共存が出来なくて、おかしな状態です。も少し調べてから、あらためて教えていただこうかと思っていますので、よろしく。
この記事
http://www.symphonic-net.com/kubotayo/articles/articles015.html#006" target="_blank">http://www.symphonic-net.com/kubotayo/articles/articles015.html#006
の方法で駄目ですか。僕のところはこの方法で同じハードディスクをcifs/nfsどちらでも使えるようにしています。ただdsdの演奏中断に関してはnfsは効率が良すぎるためか、全敗です。
> 実は、うちでは、cifsとnfsの共存が出来なくて、おかしな状態です。も少し調べてから、あらためて教えていただこうかと思っていますので、よろしく。
この記事
http://www.symphonic-net.com/kubotayo/articles/articles015.html#006" target="_blank">http://www.symphonic-net.com/kubotayo/articles/articles015.html#006
の方法で駄目ですか。僕のところはこの方法で同じハードディスクをcifs/nfsどちらでも使えるようにしています。ただdsdの演奏中断に関してはnfsは効率が良すぎるためか、全敗です。
yo 2013/08/24(Sat) 17:22 No.3462
Re: cuboxでsamba
tinker 2013/08/24(Sat) 17:26 No.3463
syuさん
3.10は今のところ無理ですが、以下のpatchをBBBの3.8-rtに当てます。
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
さらにrtopの当たっていないmpdを使用すると音切れがなくなるかもしれません。
それとtwlさんが使われているmpd-dsdを使ってみましたが、すーっと伸びる感じで好印象です。
https://github.com/lintweaker/mpd-dsd" target="_blank">https://github.com/lintweaker/mpd-dsd
これだけだとスレの趣旨にあわないので・・
音が良くなるかは分かりませんが、sambaとして使うのであれば、RTでないkernelのほうが多分安定します。またSDでbootしているのであれば、logは接続したHDD（or SSD）に書きだすようにしたほうが良いかと思います。
3.10は今のところ無理ですが、以下のpatchをBBBの3.8-rtに当てます。
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
さらにrtopの当たっていないmpdを使用すると音切れがなくなるかもしれません。
それとtwlさんが使われているmpd-dsdを使ってみましたが、すーっと伸びる感じで好印象です。
https://github.com/lintweaker/mpd-dsd" target="_blank">https://github.com/lintweaker/mpd-dsd
これだけだとスレの趣旨にあわないので・・
音が良くなるかは分かりませんが、sambaとして使うのであれば、RTでないkernelのほうが多分安定します。またSDでbootしているのであれば、logは接続したHDD（or SSD）に書きだすようにしたほうが良いかと思います。
tinker 2013/08/24(Sat) 17:26 No.3463
Re: cuboxでsamba
tinker 2013/08/24(Sat) 17:46 No.3465
syuさん
私もTS212を使っているので中を覗いてみました。
何に使っているのまでは調べていませんがramdiskを使っているようです。
/dev/ram0 32.9M 15.2M 17.7M 46% /
この辺りにも秘密があるかもしれません。
私もTS212を使っているので中を覗いてみました。
何に使っているのまでは調べていませんがramdiskを使っているようです。
/dev/ram0 32.9M 15.2M 17.7M 46% /
この辺りにも秘密があるかもしれません。
tinker 2013/08/24(Sat) 17:46 No.3465
Re: cuboxでsamba
syu 2013/08/24(Sat) 20:43 No.3466
tinkerさんのno.3449のご提案から思いついて、cuboxRT-serverで chrt -f -p 53 `pgrep smbd`とやってみました。53が適切かどうかは判断できませんが、１時間以上、dsdが機嫌良く鳴って、ストライキなし。この状態のサーバ側のtopです。
top - 05:32:12 up 1:11, 1 user, load average: 0.13, 0.06, 0.06
Tasks: 68 total, 1 running, 67 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.3 us, 0.7 sy, 0.0 ni, 98.6 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
KiB Mem: 2073524 total, 1499616 used, 573908 free, 4420 buffers
KiB Swap: 0 total, 0 used, 0 free, 1373636 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
190 root -51 0 0 0 0 S 2.3 0.0 1:07.47 irq/29-eth0
352 root -54 0 33204 5968 4412 S 0.7 0.3 0:35.54 smbd
383 root 20 0 4612 1272 1004 R 0.7 0.1 0:12.54 top
1 root 20 0 4772 2596 1800 S 0.0 0.1 0:01.50 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root -2 0 0 0 0 S 0.0 0.0 0:02.69 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:00.05 kworker/u:0
7 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/u:0H
8 root rt 0 0 0 0 S 0.0 0.0 0:00.00 posixcputmr+
このまま続けてみます。
logの保存先はusb-hddに変更しました。やっぱり晒してみると良い事がありましたね。
top - 05:32:12 up 1:11, 1 user, load average: 0.13, 0.06, 0.06
Tasks: 68 total, 1 running, 67 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.3 us, 0.7 sy, 0.0 ni, 98.6 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
KiB Mem: 2073524 total, 1499616 used, 573908 free, 4420 buffers
KiB Swap: 0 total, 0 used, 0 free, 1373636 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
190 root -51 0 0 0 0 S 2.3 0.0 1:07.47 irq/29-eth0
352 root -54 0 33204 5968 4412 S 0.7 0.3 0:35.54 smbd
383 root 20 0 4612 1272 1004 R 0.7 0.1 0:12.54 top
1 root 20 0 4772 2596 1800 S 0.0 0.1 0:01.50 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root -2 0 0 0 0 S 0.0 0.0 0:02.69 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:00.05 kworker/u:0
7 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/u:0H
8 root rt 0 0 0 0 S 0.0 0.0 0:00.00 posixcputmr+
このまま続けてみます。
logの保存先はusb-hddに変更しました。やっぱり晒してみると良い事がありましたね。
syu 2013/08/24(Sat) 20:43 No.3466
Re: cuboxでsamba
syu 2013/08/25(Sun) 11:05 No.3469
おはようございます。
tinkerさん
>sambaとして使うのであれば、RTでないkernelのほうが多分安定
わたしも最初はそう考えて、arch linuxをインストールしたままの状態（3.5.7)でsambaの設定をしたのですが、数分置きにdsdでの音消え現象が発生。3.8.11-rt8に変えても発生頻度はほぼ同じでした。
今朝、もう一度3.5.7を試しましたが、7分ほどで音が消えました。3.8.11-rt8で確認しても同じ程度の発生頻度。
で、chrt -f -p 53 `pgrep smbd` とやってみたんですが、今朝はダメですね。（笑
昨夜は連続7時間越え（cuboxはバッテリ駆動だったのでここで打ち切り）まで試して、音消えは発生しませんでしたが、あれは「深夜には音が良くなる」現象と同じだったのかも。
外来ノイズの量と質がハブなどに影響しているのかもしれませんね。
mpd-dsdトライしてみます。
tinkerさん
>sambaとして使うのであれば、RTでないkernelのほうが多分安定
わたしも最初はそう考えて、arch linuxをインストールしたままの状態（3.5.7)でsambaの設定をしたのですが、数分置きにdsdでの音消え現象が発生。3.8.11-rt8に変えても発生頻度はほぼ同じでした。
今朝、もう一度3.5.7を試しましたが、7分ほどで音が消えました。3.8.11-rt8で確認しても同じ程度の発生頻度。
で、chrt -f -p 53 `pgrep smbd` とやってみたんですが、今朝はダメですね。（笑
昨夜は連続7時間越え（cuboxはバッテリ駆動だったのでここで打ち切り）まで試して、音消えは発生しませんでしたが、あれは「深夜には音が良くなる」現象と同じだったのかも。
外来ノイズの量と質がハブなどに影響しているのかもしれませんね。
mpd-dsdトライしてみます。
syu 2013/08/25(Sun) 11:05 No.3469
Re: cuboxでsamba
syu 2013/08/25(Sun) 11:48 No.3471
yoさん
別スレッドでのtinkerさんのお話では、ts212はnfs3だとのこと。
これで気付いたのですが、cifsとnfsが混在できないと誤認していたのは、あれこれやってるうちに、わたしの頭が混乱していたからのようです。
最初、yoさんの記事を参考に、alixとvoyage linuxでnfsだけ入れて試してみました。記事での /etc/exportsは
nano /etc/exports
/mnt/sdb 192.168.0.*(rw,no_subtree_check,all_squash,sync)
ですから、NFSv3だと思います。この時bbbからマウント出来たのは、rootfsがdebianだったからなのかも。
NFSv4にするには、fsid=0 を指定するとのことで、未検証ですが、例えば、
nano /etc/exports
/mnt/sdb 192.168.0.*(rw,no_subtree_check,all_squash,sync,fsid=0)
とやるらしいです。
yoさんもご指摘のように、nfsだとdsdが散々でした。そこでvoyageにsambaを追加し、cifsで接続できる状態にしたのですが、ここでnfsに戻したところ、接続できなかったのです。
混在できないと誤認したのは、途中で無自覚に、bbbをarch-linuxに切り替えていて、archからはデフォルトでNFSv4になっているので接続できず、サポートしてないと叱られたのだと思います。
これに懲りて、cubox/arch/serverでは、まだnfs入れて試していません。後でやってみようと思います。
別スレッドでのtinkerさんのお話では、ts212はnfs3だとのこと。
これで気付いたのですが、cifsとnfsが混在できないと誤認していたのは、あれこれやってるうちに、わたしの頭が混乱していたからのようです。
最初、yoさんの記事を参考に、alixとvoyage linuxでnfsだけ入れて試してみました。記事での /etc/exportsは
nano /etc/exports
/mnt/sdb 192.168.0.*(rw,no_subtree_check,all_squash,sync)
ですから、NFSv3だと思います。この時bbbからマウント出来たのは、rootfsがdebianだったからなのかも。
NFSv4にするには、fsid=0 を指定するとのことで、未検証ですが、例えば、
nano /etc/exports
/mnt/sdb 192.168.0.*(rw,no_subtree_check,all_squash,sync,fsid=0)
とやるらしいです。
yoさんもご指摘のように、nfsだとdsdが散々でした。そこでvoyageにsambaを追加し、cifsで接続できる状態にしたのですが、ここでnfsに戻したところ、接続できなかったのです。
混在できないと誤認したのは、途中で無自覚に、bbbをarch-linuxに切り替えていて、archからはデフォルトでNFSv4になっているので接続できず、サポートしてないと叱られたのだと思います。
これに懲りて、cubox/arch/serverでは、まだnfs入れて試していません。後でやってみようと思います。
syu 2013/08/25(Sun) 11:48 No.3471
Re: cuboxでsamba
tinker 2013/08/25(Sun) 20:47 No.3474
syuさん
>わたしも最初はそう考えて、arch linuxをインストールしたままの状態（3.5.7)でsambaの設定をしたのですが、～
なかなか考えたとおりに動かないですね^^;
TS-212はNFS3でdebianもubuntuも文句言わないんですよね。
最近Archをアップデートしたら、mpdのライブラリが変わったみたいで以前作ったものが使えなくなってるし（PKGBUILDを見て解決）、Archは慣れていないので大変です。
>わたしも最初はそう考えて、arch linuxをインストールしたままの状態（3.5.7)でsambaの設定をしたのですが、～
なかなか考えたとおりに動かないですね^^;
TS-212はNFS3でdebianもubuntuも文句言わないんですよね。
最近Archをアップデートしたら、mpdのライブラリが変わったみたいで以前作ったものが使えなくなってるし（PKGBUILDを見て解決）、Archは慣れていないので大変です。
tinker 2013/08/25(Sun) 20:47 No.3474
Re: cuboxでsamba
syu 2013/08/27(Tue) 21:49 No.3487
皆様
まだ良い結果は確定していませんが、中間報告。
手元にあった古いハブを総動員してmpd周辺だけ独立させてみましたが、古い100M switchは、ことごとくダメでした。dsdで音消え頻発します。期待のアライドテレシスGS908XLも改善なし(^^;
クロスケーブルで直結してみるかな。
qnapで音消えしないことは私の環境では確実ですので、cifsサーバに秘密があることは確定的かと思います。しかしnas専業メーカの企業秘密が解明できるなど夢想できませんので、現実的にはcuboxのsambaにチューニングでチャレンジするしかない。（qnapに普通のlinux入れてテストしてみる手はある）
いくつか試してみました。まず、smb.confの変更です。
# nano /etc/samba/smb.conf
[global]
; workgroup = WORKGROUP # windowsから使わないのでコメントアウト
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 # 定番のチューニング。100M対応で8192
server string = Samba Server
log level = 0 # logアクセスで遅れが出ないようにlog使わない。
log file = /Public/log/samba/%m.log
max log size = 1024
dns proxy = no
[Public]
comment = Public
read only = no
locking = no
path = /Public
guest ok = yes
# systemctl daemon-reload
# systemctl restart smbd.service
必要ないので、nmbdも停止
# systemctl stop nmbd.service
# systemctl disable nmbd.service
これで、約180分間dsd連続再生できていますが、なにしろ夜ですからね。明日は違う結果が出るかも。
素直にqnap使えば良いわけですし、悪いわけではないのですが、cubox-rt-serverの、滑らか/高コントラスト/高細精が好みなんですよね。
まだ良い結果は確定していませんが、中間報告。
手元にあった古いハブを総動員してmpd周辺だけ独立させてみましたが、古い100M switchは、ことごとくダメでした。dsdで音消え頻発します。期待のアライドテレシスGS908XLも改善なし(^^;
クロスケーブルで直結してみるかな。
qnapで音消えしないことは私の環境では確実ですので、cifsサーバに秘密があることは確定的かと思います。しかしnas専業メーカの企業秘密が解明できるなど夢想できませんので、現実的にはcuboxのsambaにチューニングでチャレンジするしかない。（qnapに普通のlinux入れてテストしてみる手はある）
いくつか試してみました。まず、smb.confの変更です。
# nano /etc/samba/smb.conf
[global]
; workgroup = WORKGROUP # windowsから使わないのでコメントアウト
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 # 定番のチューニング。100M対応で8192
server string = Samba Server
log level = 0 # logアクセスで遅れが出ないようにlog使わない。
log file = /Public/log/samba/%m.log
max log size = 1024
dns proxy = no
[Public]
comment = Public
read only = no
locking = no
path = /Public
guest ok = yes
# systemctl daemon-reload
# systemctl restart smbd.service
必要ないので、nmbdも停止
# systemctl stop nmbd.service
# systemctl disable nmbd.service
これで、約180分間dsd連続再生できていますが、なにしろ夜ですからね。明日は違う結果が出るかも。
素直にqnap使えば良いわけですし、悪いわけではないのですが、cubox-rt-serverの、滑らか/高コントラスト/高細精が好みなんですよね。
syu 2013/08/27(Tue) 21:49 No.3487
Re: cuboxでsamba
yo 2013/08/28(Wed) 18:11 No.3488
syuさん
> qnapで音消えしないことは私の環境では確実ですので、cifsサーバに秘密があることは確定的かと思います。しかしnas専業メーカの企業秘密が解明できるなど夢想できませんので、・・・
ご明察の通りでしょう。
qnapはいろいろなクライアントからの要求に問題なく対応できるよう、最適にチューニングされていて、結果として、再生中断が発生しないということだと思います。ネットワーク周りのドライバも専用なのかもしれませんね。
今回の再生中断は (1)通常のカーネルでは発生しない、(2)rtカーネルであってもrtoptパッチをかけないmpd(mpd-dsd)では発生しない ということを考慮するとかなりレアケースの処理ですね。そういう例外的な処理に対応できるという意味では、「さすがqnap。だてに高いわけじゃない」と思います。
sambaのチューニングだけで対応できるかどうかは分かりません。ネットワークの帯域制御に関してはlinuxは結構いろいろな技が使えるようです。「linux nas 帯域制御 or 制限」とか「linux tc 使い方」などをキーワドにして検索するといろいろな情報が出てきます、基本になるドキュメントのリンクは以下の通りです。
http://linuxjf.sourceforge.jp/JFdocs/Adv-Routing-HOWTO.txt" target="_blank">http://linuxjf.sourceforge.jp/JFdocs/Adv-Routing-HOWTO.txt
リンク先を読んだのですが、根性の無い我が身には「どうすればいいのかサッパリ分からん」状態で止まっています(^^;;;。
僕の環境(cubox 3.10.9+rt5)でmpd-dsdにrtoptパッチをかけてcifsのraspberrypiサーバ実験したのですが、再生中断はsacd一枚で一回起きるかどうかというレベルですね。他の場合より、再現確率はかなり低くなります。面白いですね。
> qnapで音消えしないことは私の環境では確実ですので、cifsサーバに秘密があることは確定的かと思います。しかしnas専業メーカの企業秘密が解明できるなど夢想できませんので、・・・
ご明察の通りでしょう。
qnapはいろいろなクライアントからの要求に問題なく対応できるよう、最適にチューニングされていて、結果として、再生中断が発生しないということだと思います。ネットワーク周りのドライバも専用なのかもしれませんね。
今回の再生中断は (1)通常のカーネルでは発生しない、(2)rtカーネルであってもrtoptパッチをかけないmpd(mpd-dsd)では発生しない ということを考慮するとかなりレアケースの処理ですね。そういう例外的な処理に対応できるという意味では、「さすがqnap。だてに高いわけじゃない」と思います。
sambaのチューニングだけで対応できるかどうかは分かりません。ネットワークの帯域制御に関してはlinuxは結構いろいろな技が使えるようです。「linux nas 帯域制御 or 制限」とか「linux tc 使い方」などをキーワドにして検索するといろいろな情報が出てきます、基本になるドキュメントのリンクは以下の通りです。
http://linuxjf.sourceforge.jp/JFdocs/Adv-Routing-HOWTO.txt" target="_blank">http://linuxjf.sourceforge.jp/JFdocs/Adv-Routing-HOWTO.txt
リンク先を読んだのですが、根性の無い我が身には「どうすればいいのかサッパリ分からん」状態で止まっています(^^;;;。
僕の環境(cubox 3.10.9+rt5)でmpd-dsdにrtoptパッチをかけてcifsのraspberrypiサーバ実験したのですが、再生中断はsacd一枚で一回起きるかどうかというレベルですね。他の場合より、再現確率はかなり低くなります。面白いですね。
yo 2013/08/28(Wed) 18:11 No.3488
Re: cuboxでsamba
syu 2013/08/29(Thu) 19:47 No.3489
yoさん
カーネルが新しいほど良さそうな気がしたので、サーバ側のuImageとmoduleを3.10.9に入れ替えてみました。 .configは梅雨入り版のものを使用し、rt5、Low-Latency、voluntary-Preemptionの3種を試しました。
dsdでの音消えは、どれでも3時間ぐらいは発生しませんが、起き始めると頻発します。bbbをrebootすれば、また3時間以上はOKです。この3種では差はなさそうです。音消えが始まる時点でbbb側に何かあるようで、それを見つけられると良いのですが・・・
面白いのは、それぞれ音質が違うこと。わたしの好みはrt5ですが、疲れたときにはVoluntary-Preemptionがおとなしくて良さそうです。
No Forced Preemption (Server) という選択肢もあるのですが、梅雨入り版の.configでこれを指定してmakeしても、起動途中で止まってしまいます。他にconfigのどこかを変えなければいけないようですね。
>僕の環境(cubox 3.10.9+rt5)でmpd-dsdにrtoptパッチをかけて
さりげなく書いてありますが、これはどうやるのでしょう。わたしにはmpd-dsdのコンパイルの方法からしてわかりません^^;;
時期が来たら、教えてください。
>ネットワークの帯域制御
これは全く手が出ませんが、dstatなるものがあるのに気付きました。topみたいな感じでnetの状態などもモニタ出来るんですね。dsd再生中の負荷もそれほど高いものではなさそうです。
[root@arch-smb ~]# dstat -cdngy
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
1 2 94 1 0 1| 613k 4821B| 0 0 | 0 0 | 557 1053
2 1 93 0 0 4| 768k 0 | 22k 796k| 0 0 | 808 1529
1 0 96 0 0 3| 512k 0 | 15k 525k| 0 0 | 443 815
1 2 93 0 0 4| 768k 0 | 21k 791k| 0 0 | 671 1206
1 1 96 0 0 2| 768k 0 | 22k 791k| 0 0 | 749 1367
1 1 96 0 0 2| 768k 0 | 22k 789k| 0 0 | 614 1185
1 0 97 0 0 2| 384k 0 | 14k 527k| 0 0 | 429 791
2 1 95 0 0 2| 768k 0 | 22k 794k| 0 0 | 754 1419
1 2 94 0 0 3| 768k 0 | 23k 792k| 0 0 | 630 1226
1 0 98 0 0 1| 768k 0 | 22k 794k| 0 0 | 642 1223
1 2 94 0 0 3| 768k 8192B| 22k 791k| 0 0 | 794 1472
1 0 97 0 0 2| 512k 0 | 14k 527k| 0 0 | 441 832
1 0 98 0 0 1| 640k 0 | 22k 789k| 0 0 | 631 1162
3 1 94 0 0 2| 768k 0 | 21k 786k| 0 0 | 798 1460
1 1 96 0 0 2| 768k 0 | 22k 791k| 0 0 | 628 1179
1 0 98 0 0 1| 512k 0 | 14k 528k| 0 0 | 433 803
2 1 94 0 0 3| 768k 0 | 22k 791k| 0 0 | 748 1406
1 3 95 0 0 1| 768k 0 | 22k 795k| 0 0 | 634 1201
1 2 96 0 0 1| 640k 0 | 21k 791k| 0 0 | 640 1197 ^C
[root@arch-smb ~]#
カーネルが新しいほど良さそうな気がしたので、サーバ側のuImageとmoduleを3.10.9に入れ替えてみました。 .configは梅雨入り版のものを使用し、rt5、Low-Latency、voluntary-Preemptionの3種を試しました。
dsdでの音消えは、どれでも3時間ぐらいは発生しませんが、起き始めると頻発します。bbbをrebootすれば、また3時間以上はOKです。この3種では差はなさそうです。音消えが始まる時点でbbb側に何かあるようで、それを見つけられると良いのですが・・・
面白いのは、それぞれ音質が違うこと。わたしの好みはrt5ですが、疲れたときにはVoluntary-Preemptionがおとなしくて良さそうです。
No Forced Preemption (Server) という選択肢もあるのですが、梅雨入り版の.configでこれを指定してmakeしても、起動途中で止まってしまいます。他にconfigのどこかを変えなければいけないようですね。
>僕の環境(cubox 3.10.9+rt5)でmpd-dsdにrtoptパッチをかけて
さりげなく書いてありますが、これはどうやるのでしょう。わたしにはmpd-dsdのコンパイルの方法からしてわかりません^^;;
時期が来たら、教えてください。
>ネットワークの帯域制御
これは全く手が出ませんが、dstatなるものがあるのに気付きました。topみたいな感じでnetの状態などもモニタ出来るんですね。dsd再生中の負荷もそれほど高いものではなさそうです。
[root@arch-smb ~]# dstat -cdngy
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
1 2 94 1 0 1| 613k 4821B| 0 0 | 0 0 | 557 1053
2 1 93 0 0 4| 768k 0 | 22k 796k| 0 0 | 808 1529
1 0 96 0 0 3| 512k 0 | 15k 525k| 0 0 | 443 815
1 2 93 0 0 4| 768k 0 | 21k 791k| 0 0 | 671 1206
1 1 96 0 0 2| 768k 0 | 22k 791k| 0 0 | 749 1367
1 1 96 0 0 2| 768k 0 | 22k 789k| 0 0 | 614 1185
1 0 97 0 0 2| 384k 0 | 14k 527k| 0 0 | 429 791
2 1 95 0 0 2| 768k 0 | 22k 794k| 0 0 | 754 1419
1 2 94 0 0 3| 768k 0 | 23k 792k| 0 0 | 630 1226
1 0 98 0 0 1| 768k 0 | 22k 794k| 0 0 | 642 1223
1 2 94 0 0 3| 768k 8192B| 22k 791k| 0 0 | 794 1472
1 0 97 0 0 2| 512k 0 | 14k 527k| 0 0 | 441 832
1 0 98 0 0 1| 640k 0 | 22k 789k| 0 0 | 631 1162
3 1 94 0 0 2| 768k 0 | 21k 786k| 0 0 | 798 1460
1 1 96 0 0 2| 768k 0 | 22k 791k| 0 0 | 628 1179
1 0 98 0 0 1| 512k 0 | 14k 528k| 0 0 | 433 803
2 1 94 0 0 3| 768k 0 | 22k 791k| 0 0 | 748 1406
1 3 95 0 0 1| 768k 0 | 22k 795k| 0 0 | 634 1201
1 2 96 0 0 1| 640k 0 | 21k 791k| 0 0 | 640 1197 ^C
[root@arch-smb ~]#
syu 2013/08/29(Thu) 19:47 No.3489
Re: cuboxでsamba
syu 2013/08/30(Fri) 17:31 No.3493
前回起動に失敗した3.10.9-No Forced Preemptionですが、初めからやり直したら、起動しました。
[root@arch-smb ~]# uname -a
Linux arch-smb 3.10.9_CuboxNFPsever #1 Fri Aug 30 00:14:46 JST 2013 armv7l GNU/Linux
さすがに安定していますね。10時間以上トラブルなく連続再生できています。
smb.confのコメントアウトや追加部分をすべて元に戻し、nmbdも起動しましたが、問題ありません。音も良好。
結局、最近のsamba(4.0.9-1)と最新のサーバ用カーネル(3.10.9-no forced preemption)を使いさえすれば、 dsd再生向けに特別なチューニングは不要という結果です。（もちろん、わたしの環境に限定してですが）
ローノイズ５V電源を追加調達する必要が生じてしまいました(^^)
皆様、ご支援ありがとうございました。
[root@arch-smb ~]# uname -a
Linux arch-smb 3.10.9_CuboxNFPsever #1 Fri Aug 30 00:14:46 JST 2013 armv7l GNU/Linux
さすがに安定していますね。10時間以上トラブルなく連続再生できています。
smb.confのコメントアウトや追加部分をすべて元に戻し、nmbdも起動しましたが、問題ありません。音も良好。
結局、最近のsamba(4.0.9-1)と最新のサーバ用カーネル(3.10.9-no forced preemption)を使いさえすれば、 dsd再生向けに特別なチューニングは不要という結果です。（もちろん、わたしの環境に限定してですが）
ローノイズ５V電源を追加調達する必要が生じてしまいました(^^)
皆様、ご支援ありがとうございました。
syu 2013/08/30(Fri) 17:31 No.3493
Re: cuboxでsamba
yo 2013/08/30(Fri) 19:38 No.3494
syuさん
書き忘れましたが、tc(traffic-control)のJFdocsのありかです。
http://archive.linux.or.jp/JF/JFdocs/traffic-control.txt" target="_blank">http://archive.linux.or.jp/JF/JFdocs/traffic-control.txt
> さりげなく書いてありますが、これはどうやるのでしょう。わたしにはmpd-dsdのコンパイルの方法からしてわかりません^^;;
これは普通のmpdのビルドといっしょです。僕はsyuさんのBBBイメージ環境でビルドしました。やり方は
http://www.symphonic-net.com/kubotayo/articles/articles015.html#001" target="_blank">http://www.symphonic-net.com/kubotayo/articles/articles015.html#001
に書いた通りですが、注意点を補足すると
事前にcubox梅雨入り版のdebian /root/mpdcuboxに置いてあるmpdビルド用のパッチ一式とmy-configを持ってきておきます。
git clone git://github.com/lintweaker/mpd-dsd
cd mpd-dsd
rtoptパッチをかける場合は(0.17用のものを使います)
patch -p1 < ../mpd-0.17git-20120226rtopt.diff
patch -p1 < ../buffer.c.diff
my-configを環境にあわせて修正
nano ../my-config
最終行(archの場合、gccの指定は不要なので)の
CC=gcc-4.4 CXX=g++-4.4
とその直前の\を削除。以下の行を適当な場所に挿入(こいつをやらないと、ライブラリがないと怒られます。何でcdio-paranoiaが入っていたのかは不明です)
--disable-cdio-paranoia \
あとは通常とおり
pkill mpd
./autogen.sh
sh ../my-config
make && make install
作成されたバイナリはcuboxでも動きます。
というところです。mpd-dsdはmpdのdsd対応の作者のjurgenさんが作成された私家版のようです。とても音が良く、安定していますので、お勧めです。別にdsd再生でなくても使えますので、これに入れ換える一手だと思います。僕はcuboxについては、rtoptパッチをかけなければ、再生中断は発生しませんので、とりあえずはこれで逃げることにしました。
dstatの情報ありがとうございました。これは使えそうですね。
書き忘れましたが、tc(traffic-control)のJFdocsのありかです。
http://archive.linux.or.jp/JF/JFdocs/traffic-control.txt" target="_blank">http://archive.linux.or.jp/JF/JFdocs/traffic-control.txt
> さりげなく書いてありますが、これはどうやるのでしょう。わたしにはmpd-dsdのコンパイルの方法からしてわかりません^^;;
これは普通のmpdのビルドといっしょです。僕はsyuさんのBBBイメージ環境でビルドしました。やり方は
http://www.symphonic-net.com/kubotayo/articles/articles015.html#001" target="_blank">http://www.symphonic-net.com/kubotayo/articles/articles015.html#001
に書いた通りですが、注意点を補足すると
事前にcubox梅雨入り版のdebian /root/mpdcuboxに置いてあるmpdビルド用のパッチ一式とmy-configを持ってきておきます。
git clone git://github.com/lintweaker/mpd-dsd
cd mpd-dsd
rtoptパッチをかける場合は(0.17用のものを使います)
patch -p1 < ../mpd-0.17git-20120226rtopt.diff
patch -p1 < ../buffer.c.diff
my-configを環境にあわせて修正
nano ../my-config
最終行(archの場合、gccの指定は不要なので)の
CC=gcc-4.4 CXX=g++-4.4
とその直前の\を削除。以下の行を適当な場所に挿入(こいつをやらないと、ライブラリがないと怒られます。何でcdio-paranoiaが入っていたのかは不明です)
--disable-cdio-paranoia \
あとは通常とおり
pkill mpd
./autogen.sh
sh ../my-config
make && make install
作成されたバイナリはcuboxでも動きます。
というところです。mpd-dsdはmpdのdsd対応の作者のjurgenさんが作成された私家版のようです。とても音が良く、安定していますので、お勧めです。別にdsd再生でなくても使えますので、これに入れ換える一手だと思います。僕はcuboxについては、rtoptパッチをかけなければ、再生中断は発生しませんので、とりあえずはこれで逃げることにしました。
dstatの情報ありがとうございました。これは使えそうですね。
yo 2013/08/30(Fri) 19:38 No.3494
Re: cuboxでsamba
tinker 2013/08/30(Fri) 20:40 No.3495
syuさん
安定したみたいですね。お疲れ様でした。
>ローノイズ５V電源を追加調達する必要が生じてしまいました(^^)
どこの物を使われていますか？良かったら教えてください。
wandboardもcuboxももうひと伸びがありません。上が詰まった感じなので下も良くないです。
BBBだとバランスとれてるので、スーパーツイータ追加は踏みとどまってます（手持ちでT90A有り）
安定したみたいですね。お疲れ様でした。
>ローノイズ５V電源を追加調達する必要が生じてしまいました(^^)
どこの物を使われていますか？良かったら教えてください。
wandboardもcuboxももうひと伸びがありません。上が詰まった感じなので下も良くないです。
BBBだとバランスとれてるので、スーパーツイータ追加は踏みとどまってます（手持ちでT90A有り）
tinker 2013/08/30(Fri) 20:40 No.3495
Re: cuboxでsamba
yo 2013/08/31(Sat) 08:05 No.3496
syuさん
> さすがに安定していますね。10時間以上トラブルなく連続再生できています。
これはクライアントがBBBの場合もOKでしょうか。
PaspberryPIも3.10.10にできるようなので、挑戦してみますかね。
> さすがに安定していますね。10時間以上トラブルなく連続再生できています。
これはクライアントがBBBの場合もOKでしょうか。
PaspberryPIも3.10.10にできるようなので、挑戦してみますかね。
yo 2013/08/31(Sat) 08:05 No.3496
Re: cuboxでsamba
syu 2013/08/31(Sat) 18:42 No.3498
yoさん
>これはクライアントがBBBの場合もOKでしょうか。
クライアントはbbbだけを試しています。0806rtで、mpdは梅雨入り版の174sを使いました。
>mpd-dsd
github、まだオリエンテーションがついてない状態で、どこから落とせるのかなど、理解できてないんですよね。
教えていただいたところから取得し、rtoptパッチの当たったmpd-0.17.5-dsd-rtoptをbbbで作ってみました。音は174sより良いです。また、0.17.4-rtoptでは、e-onkyoで販売している2Lレーベルのdffでは曲の終わりにノイズが出ていましたが、0.17.5-dsd-rtoptではノイズも出なくなっています。
2L音源のサンプルがここにありました。
http://www.e-onkyo.com/music/album/sample02/" target="_blank">http://www.e-onkyo.com/music/album/sample02/
安定性は、まだ試行回数が少ないですが、音消えが発生し始めるまでの時間が、0.17.4-rtoptよりやや短い印象です。２時間半ぐらいかも。
10時間越えたのは3.10.9でno forced preemptionを指定した場合だけで、それ以外では3時間ほどで音消えが発生し始めました。3.10.10-no forced preemptionも試してみます。
>これはクライアントがBBBの場合もOKでしょうか。
クライアントはbbbだけを試しています。0806rtで、mpdは梅雨入り版の174sを使いました。
>mpd-dsd
github、まだオリエンテーションがついてない状態で、どこから落とせるのかなど、理解できてないんですよね。
教えていただいたところから取得し、rtoptパッチの当たったmpd-0.17.5-dsd-rtoptをbbbで作ってみました。音は174sより良いです。また、0.17.4-rtoptでは、e-onkyoで販売している2Lレーベルのdffでは曲の終わりにノイズが出ていましたが、0.17.5-dsd-rtoptではノイズも出なくなっています。
2L音源のサンプルがここにありました。
http://www.e-onkyo.com/music/album/sample02/" target="_blank">http://www.e-onkyo.com/music/album/sample02/
安定性は、まだ試行回数が少ないですが、音消えが発生し始めるまでの時間が、0.17.4-rtoptよりやや短い印象です。２時間半ぐらいかも。
10時間越えたのは3.10.9でno forced preemptionを指定した場合だけで、それ以外では3時間ほどで音消えが発生し始めました。3.10.10-no forced preemptionも試してみます。
syu 2013/08/31(Sat) 18:42 No.3498
Re: cuboxでsamba
syu 2013/08/31(Sat) 19:11 No.3499
tinkerさん
>ローノイズ５V電源
あれこれ試したわけではないので、これが良いのかどうか不詳なんですが、Fidelixの6wタイプです。cuboxでも6wので問題ないです。このページの下の方。
http://www.fidelix.jp/technology/HiFi%20USB%20filter.html" target="_blank">http://www.fidelix.jp/technology/HiFi%20USB%20filter.html
能書きが多いのが怪しげ^^;;ではありますが、電圧は安定しています。実は、そこにあるusbノイズフィルタの同等品を自作しようとして部品を集めてみたら、サイズのあまりの小ささにメゲて、買うことにしたので、そのついでです。割引のあった時期に買いました。
この他、AC電源まわりは、トランス切り替え式で安定化したり、大型LCフィルター入れたり、あれこれやってます。空間ノイズも多いようなので、アンプ類も高周波ノイズ対策を固めて、普通に言えば、「ガチガチに音を殺した」状態です。この状態の方が「伸び伸びする」気がするので、わたしは好きなんですよね。
>ローノイズ５V電源
あれこれ試したわけではないので、これが良いのかどうか不詳なんですが、Fidelixの6wタイプです。cuboxでも6wので問題ないです。このページの下の方。
http://www.fidelix.jp/technology/HiFi%20USB%20filter.html" target="_blank">http://www.fidelix.jp/technology/HiFi%20USB%20filter.html
能書きが多いのが怪しげ^^;;ではありますが、電圧は安定しています。実は、そこにあるusbノイズフィルタの同等品を自作しようとして部品を集めてみたら、サイズのあまりの小ささにメゲて、買うことにしたので、そのついでです。割引のあった時期に買いました。
この他、AC電源まわりは、トランス切り替え式で安定化したり、大型LCフィルター入れたり、あれこれやってます。空間ノイズも多いようなので、アンプ類も高周波ノイズ対策を固めて、普通に言えば、「ガチガチに音を殺した」状態です。この状態の方が「伸び伸びする」気がするので、わたしは好きなんですよね。
syu 2013/08/31(Sat) 19:11 No.3499
Re: cuboxでsamba
yo 2013/08/31(Sat) 20:15 No.3500
syuさん
> 安定性は、まだ試行回数が少ないですが、音消えが発生し始めるまでの時間が、0.17.4-rtoptよりやや短い印象です。
cuboxの場合は、rtoptパッチをかけなければ、再生中断は発生しません。rtoptと同じように優先レベルの設定をシェルスクリプトで行う手があるので、実験しているところです。これでOKなら、この方法がお勧めですね。ただ、BBBでは効かないようですね。
nasサーバをraspberry + kernel 3.10.10で動かす方法も試行中です。動くカーネルはビルドできたのですが、sambaを4にするのに悪戦苦闘しています。
> 安定性は、まだ試行回数が少ないですが、音消えが発生し始めるまでの時間が、0.17.4-rtoptよりやや短い印象です。
cuboxの場合は、rtoptパッチをかけなければ、再生中断は発生しません。rtoptと同じように優先レベルの設定をシェルスクリプトで行う手があるので、実験しているところです。これでOKなら、この方法がお勧めですね。ただ、BBBでは効かないようですね。
nasサーバをraspberry + kernel 3.10.10で動かす方法も試行中です。動くカーネルはビルドできたのですが、sambaを4にするのに悪戦苦闘しています。
yo 2013/08/31(Sat) 20:15 No.3500
Re: cuboxでsamba
tinker 2013/08/31(Sat) 21:33 No.3501
syuさん
電源の件、ありがとうございます。検討してみます。
BBBのほうは、initrdを使い始めました。
音には関係ないですし安定度も変わりませんが、selpartでの切り替えに失敗することはなくなったような気がします。
電源の件、ありがとうございます。検討してみます。
BBBのほうは、initrdを使い始めました。
音には関係ないですし安定度も変わりませんが、selpartでの切り替えに失敗することはなくなったような気がします。
tinker 2013/08/31(Sat) 21:33 No.3501
Re: cuboxでsamba
syu 2013/08/31(Sat) 23:32 No.3502
yoさん、tinkerさん
BBBでrtoptなしのmpd-0.17.5-dsdを作成して聴いています。これでも十分良い音ですね。ストレスなく聴けて気分良いです（笑
>sambaを4
cuboxのarch-linuxだと、pacman -S sambaで4.0.9-1が入るんですが、raspberry + kernel 3.10.10だと大変そうですね。
BBBでrtoptなしのmpd-0.17.5-dsdを作成して聴いています。これでも十分良い音ですね。ストレスなく聴けて気分良いです（笑
>sambaを4
cuboxのarch-linuxだと、pacman -S sambaで4.0.9-1が入るんですが、raspberry + kernel 3.10.10だと大変そうですね。
syu 2013/08/31(Sat) 23:32 No.3502
Re: cuboxでsamba
yo 2013/09/01(Sun) 19:36 No.3503
syuさん
> BBBでrtoptなしのmpd-0.17.5-dsdを作成して聴いています。これでも十分良い音ですね。ストレスなく聴けて気分良いです（笑
僕の環境だと、rtoptなしのmpd-dsdは cubox 3.10.9+rt5では再生中断は発生しないのですが、BBB 3.8rt(3.8.13)だと発生します。この理由が分からないのですよね。
> cuboxのarch-linuxだと、pacman -S sambaで4.0.9-1が入るんですが、
ということに気が付きまして(^^;;;、raspberry用のarchイメージを使ったら、あっさりインストールできました。syuさんのsambaインストール方法の書き込みに助けられました。raspberryでは enable smbd(nmbd).serviceとstart smbd(nmbd).serviceは不要でした。カーネルの更新も楽ですね。こういう使い方だと、raspberryもなかなか便利です。
cubox 3.10.9+rt5 rtoptパッチありmpd-dsdで試していますが、今のところ再生中断は発生していません(1時間位経過)。
> BBBでrtoptなしのmpd-0.17.5-dsdを作成して聴いています。これでも十分良い音ですね。ストレスなく聴けて気分良いです（笑
僕の環境だと、rtoptなしのmpd-dsdは cubox 3.10.9+rt5では再生中断は発生しないのですが、BBB 3.8rt(3.8.13)だと発生します。この理由が分からないのですよね。
> cuboxのarch-linuxだと、pacman -S sambaで4.0.9-1が入るんですが、
ということに気が付きまして(^^;;;、raspberry用のarchイメージを使ったら、あっさりインストールできました。syuさんのsambaインストール方法の書き込みに助けられました。raspberryでは enable smbd(nmbd).serviceとstart smbd(nmbd).serviceは不要でした。カーネルの更新も楽ですね。こういう使い方だと、raspberryもなかなか便利です。
cubox 3.10.9+rt5 rtoptパッチありmpd-dsdで試していますが、今のところ再生中断は発生していません(1時間位経過)。
yo 2013/09/01(Sun) 19:36 No.3503
Re: cuboxでsamba
syu 2013/09/16(Mon) 19:58 No.3532
linux-3.11.1が公開されていましたので、No Forced Preemption指定でコンパイルし、cubox/arch-smbのuImageとmodulesを切り替えてみました。
https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.11.1.tar.xz" target="_blank">https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.11.1.tar.xz
bbb/archのmpd-0.17.5-dsd/rtoptでdsdファイルも問題なく再生できますが、3.10.10との差は識別できませんでした。bbb/archとの組み合せでは、サウンドステージが深く、実体感の高い音になっていると思います。
https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.11.1.tar.xz" target="_blank">https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.11.1.tar.xz
bbb/archのmpd-0.17.5-dsd/rtoptでdsdファイルも問題なく再生できますが、3.10.10との差は識別できませんでした。bbb/archとの組み合せでは、サウンドステージが深く、実体感の高い音になっていると思います。
syu 2013/09/16(Mon) 19:58 No.3532
Re: cuboxでsamba
syu 2013/09/22(Sun) 15:03 No.3556
私の環境ではyoさんの＃3403のイメージでdsd連続再生できていますので、目下混乱しているBBB/archを公開できても、結果は同じような気がします。
そこで、先に、cubox/archNFPserverをtar.gzで公開します。
rootのパスワードはcuboxです。
usb-hddを接続する設定になっています。
デフォルトのマウント先は/Publicです。
dhcpにしてあります。固定した方が良いかもしれません。
nfsは上手く設定できていませんのでよろしく。
母艦側にてrootで作業
$ sudu su
# mkdir CuboxArchServer
# cd CuboxArchServer
# mkdir arch
CuboxArchNFP.tar.gzをCuboxArchServerディレクトリにダウンロード
※ ubuntuのfirefoxでは落とせない。要Chrome.
https://docs.google.com/file/d/0B76eZMZnaUS-VWQ0Y1BvMEdYbEE/edit?usp=sharing" target="_blank">https://docs.google.com/file/d/0B76eZMZnaUS-VWQ0Y1BvMEdYbEE/edit?usp=sharing
新しいsdカードをリーダーに装填しシングルパーティションを作成
# fdisk /dev/sdX
type o This will clear out any partitions on the drive
type p to list partitions. There should be no partitions left
type n
then p for primary
type 1 for the first partition on the drive
enter twice to select the default first and last sectors
type w Write the partition table and exit
ext3でフォーマット
# mkfs.ext3 /dev/sdX1
書き込む
# mount /dev/sdX1 arch
# tar -xvf CuboxArchNFP.tar.gz -C arch
# umount arch
取り出しをして、Cuboxに装填。
そこで、先に、cubox/archNFPserverをtar.gzで公開します。
rootのパスワードはcuboxです。
usb-hddを接続する設定になっています。
デフォルトのマウント先は/Publicです。
dhcpにしてあります。固定した方が良いかもしれません。
nfsは上手く設定できていませんのでよろしく。
母艦側にてrootで作業
$ sudu su
# mkdir CuboxArchServer
# cd CuboxArchServer
# mkdir arch
CuboxArchNFP.tar.gzをCuboxArchServerディレクトリにダウンロード
※ ubuntuのfirefoxでは落とせない。要Chrome.
https://docs.google.com/file/d/0B76eZMZnaUS-VWQ0Y1BvMEdYbEE/edit?usp=sharing" target="_blank">https://docs.google.com/file/d/0B76eZMZnaUS-VWQ0Y1BvMEdYbEE/edit?usp=sharing
新しいsdカードをリーダーに装填しシングルパーティションを作成
# fdisk /dev/sdX
type o This will clear out any partitions on the drive
type p to list partitions. There should be no partitions left
type n
then p for primary
type 1 for the first partition on the drive
enter twice to select the default first and last sectors
type w Write the partition table and exit
ext3でフォーマット
# mkfs.ext3 /dev/sdX1
書き込む
# mount /dev/sdX1 arch
# tar -xvf CuboxArchNFP.tar.gz -C arch
# umount arch
取り出しをして、Cuboxに装填。
syu 2013/09/22(Sun) 15:03 No.3556
Re: cuboxでsamba
まさまさ 2013/09/23(Mon) 12:41 No.3561
syu さん
どうもありがとうございました♪
今朝までかかって、いままで使っていたのとほぼ同じ環境にセットすることができました。(NFS server 以外)
以前のバージョンは
Linux nas 3.5.7-12-ARCH+ #1 PREEMPT Sat May 4 01:04:13 UTC 2013 armv7l GNU/Linux
syuさんにいただいたバージョンは
Linux nas 3.11.1_CuboxNFPserver #1 Mon Sep 16 13:52:25 JST 2013 armv7l GNU/Linux
それで、BBB/Debian(0731pe)/mpd
Linux beagle 3.8.13-rt9_0731pe-00899-g258c085 #19 SMP PREEMPT Tue Aug 6 01:00:37 PDT 2013 armv7l GNU/Linux
と cifs で接続した結果ですが、
残念ながら私の耳では違いは分かりませんでした。。。
それからパチ音ですが、192K flac で聞き比べましたが
同じくらいの確立で発生していました。
0731rt での発生確率も前のNAS serverと同じくらいでした。
ということで、私の環境では FLAC に関しては NAS server 側バージョンによって変化は無いということになるかと思います。
接続形態ですが、Buffalo LSW4-GT-8NS を中心にして、CuBox と Ether(1G)、BBB と Ether(100M)、Buffalo AirStation と Ether(100M) で接続され、AirStation と iPhone は WiFi 接続して、MPoD でコントロールしています。
NFS に関してですが、/boot をのぞいてみると格闘された跡がありましたので、たぶんご存じとは思いますが、
http://archlinuxarm.org/forum/viewtopic.php?f=33&t=6049" target="_blank">http://archlinuxarm.org/forum/viewtopic.php?f=33&t=6049
に記載がありますが、uname -a で表示されるバージョンと pacman -Q linux-cubox で表示されるバージョンが異なると発生するみたいですね。
linux-cubox の最新バージョンを調べてもわからず、
pacman -S linux-cubox を実行する勇気がなく、このままにしています（軟弱者ですw）
どうもありがとうございました♪
今朝までかかって、いままで使っていたのとほぼ同じ環境にセットすることができました。(NFS server 以外)
以前のバージョンは
Linux nas 3.5.7-12-ARCH+ #1 PREEMPT Sat May 4 01:04:13 UTC 2013 armv7l GNU/Linux
syuさんにいただいたバージョンは
Linux nas 3.11.1_CuboxNFPserver #1 Mon Sep 16 13:52:25 JST 2013 armv7l GNU/Linux
それで、BBB/Debian(0731pe)/mpd
Linux beagle 3.8.13-rt9_0731pe-00899-g258c085 #19 SMP PREEMPT Tue Aug 6 01:00:37 PDT 2013 armv7l GNU/Linux
と cifs で接続した結果ですが、
残念ながら私の耳では違いは分かりませんでした。。。
それからパチ音ですが、192K flac で聞き比べましたが
同じくらいの確立で発生していました。
0731rt での発生確率も前のNAS serverと同じくらいでした。
ということで、私の環境では FLAC に関しては NAS server 側バージョンによって変化は無いということになるかと思います。
接続形態ですが、Buffalo LSW4-GT-8NS を中心にして、CuBox と Ether(1G)、BBB と Ether(100M)、Buffalo AirStation と Ether(100M) で接続され、AirStation と iPhone は WiFi 接続して、MPoD でコントロールしています。
NFS に関してですが、/boot をのぞいてみると格闘された跡がありましたので、たぶんご存じとは思いますが、
http://archlinuxarm.org/forum/viewtopic.php?f=33&t=6049" target="_blank">http://archlinuxarm.org/forum/viewtopic.php?f=33&t=6049
に記載がありますが、uname -a で表示されるバージョンと pacman -Q linux-cubox で表示されるバージョンが異なると発生するみたいですね。
linux-cubox の最新バージョンを調べてもわからず、
pacman -S linux-cubox を実行する勇気がなく、このままにしています（軟弱者ですw）
まさまさ 2013/09/23(Mon) 12:41 No.3561
Re: cuboxでsamba
syu 2013/09/23(Mon) 13:48 No.3562
まさまささん
お試しいただいて、感謝。
やはり変化はほとんど無いようですね。
>uname -a で表示されるバージョンと pacman -Q linux-cubox で表示されるバージョンが異なると発生する
ちょうど今、nfsの件でお尋ねしようと、下書きしていたところでした。
[root@arch-smb ~]# pacman -Q linux-cubox
linux-cubox 3.5.7-12
[root@arch-smb ~]# uname -a
Linux arch-smb 3.11.1_CuboxNFPserver #1 Mon Sep 16 13:52:25 JST 2013 armv7l GNU/Linux
ご指摘の通りでした。
私はイノシシなので、やってみました。(^^;;;
[root@arch-smb ~]# pacman -S linux-cubox
warning: linux-cubox-3.5.7-12 is up to date -- reinstalling
resolving dependencies...
looking for inter-conflicts...
Packages (1): linux-cubox-3.5.7-12
Total Download Size: 14.24 MiB
Total Installed Size: 16.05 MiB
Net Upgrade Size: 0.00 MiB
:: Proceed with installation? [Y/n] n
止めました。(^o^">
/bootに置いてある357uImageが3.5.7-12-ARCH+ですので、これでuImageを上書きして起動したら、nfsのエラーメッセージは出なくなりました。
http://archlinuxarm.org/forum/viewtopic.php?f=33&t=6049" target="_blank">http://archlinuxarm.org/forum/viewtopic.php?f=33&t=6049
これ、知りませんでした。今から解読してみます。
ありがとうございました。
お試しいただいて、感謝。
やはり変化はほとんど無いようですね。
>uname -a で表示されるバージョンと pacman -Q linux-cubox で表示されるバージョンが異なると発生する
ちょうど今、nfsの件でお尋ねしようと、下書きしていたところでした。
[root@arch-smb ~]# pacman -Q linux-cubox
linux-cubox 3.5.7-12
[root@arch-smb ~]# uname -a
Linux arch-smb 3.11.1_CuboxNFPserver #1 Mon Sep 16 13:52:25 JST 2013 armv7l GNU/Linux
ご指摘の通りでした。
私はイノシシなので、やってみました。(^^;;;
[root@arch-smb ~]# pacman -S linux-cubox
warning: linux-cubox-3.5.7-12 is up to date -- reinstalling
resolving dependencies...
looking for inter-conflicts...
Packages (1): linux-cubox-3.5.7-12
Total Download Size: 14.24 MiB
Total Installed Size: 16.05 MiB
Net Upgrade Size: 0.00 MiB
:: Proceed with installation? [Y/n] n
止めました。(^o^">
/bootに置いてある357uImageが3.5.7-12-ARCH+ですので、これでuImageを上書きして起動したら、nfsのエラーメッセージは出なくなりました。
http://archlinuxarm.org/forum/viewtopic.php?f=33&t=6049" target="_blank">http://archlinuxarm.org/forum/viewtopic.php?f=33&t=6049
これ、知りませんでした。今から解読してみます。
ありがとうございました。
syu 2013/09/23(Mon) 13:48 No.3562
Re: cuboxでsamba
yo 2013/09/23(Mon) 15:42 No.3563
syuさん
Cubox-nasアップロードありがとうございました。早速、チューニングしたBBB(3.8rt + arch)に繋ぎ、試してみました。
結果ですが、残念ながらdsd再生でのハングや再生中断は止まりませんでした。
トラブルが発生するまでの時間も同じ位(10分位)です。どうもnasが原因というわけではなさそうですね。音もなかなかさんのご指摘と同じで、僕の環境では玄柴nasと差はないですね。再生状況も同じような感じで、cpu負荷が20%前後と高いです。
top - 09:49:23 up 2 min, 1 user, load average: 0.31, 0.25, 0.11
Threads: 82 total, 1 running, 81 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.8 us, 18.5 sy, 0.0 ni, 77.3 id, 0.0 wa, 0.0 hi, 1.4 si, 0.0 st
KiB Mem: 513408 total, 204696 used, 308712 free, 10784 buffers
KiB Swap: 0 total, 0 used, 0 free, 124748 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 14.1 0.0 0:13.36 irq/35-musb-hdr
373 root -54 0 0 0 0 S 2.3 0.0 0:02.17 cifsd
76 root -54 0 0 0 0 S 1.6 0.0 0:02.00 irq/57-4a100000
403 root -48 0 85916 82228 31080 S 1.3 16.0 0:01.26 mpd
399 root -46 0 85916 82228 31080 S 1.0 16.0 0:00.81 mpd
445 root 20 0 5092 1340 1008 R 1.0 0.3 0:00.74 top
17 root -50 0 0 0 0 S 0.3 0.0 0:00.15 kworker/0:1
77 root -54 0 0 0 0 S 0.3 0.0 0:00.49 irq/58-4a100000
398 root -47 0 85916 82228 31080 S 0.3 16.0 0:00.48 mpd
439 root 20 0 23892 5804 4656 S 0.3 1.1 0:00.57 sshd
1 root 20 0 4796 2680 1808 S 0.0 0.5 0:02.04 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd
Cubox(3.10.9rt5 + arch)だとこんな感じです。
top - 15:22:43 up 6 min, 1 user, load average: 0.61, 0.63, 0.31
Threads: 76 total, 1 running, 75 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.1 us, 4.7 sy, 0.0 ni, 90.0 id, 0.0 wa, 0.0 hi, 4.3 si, 0.0 st
KiB Mem: 1032724 total, 472136 used, 560588 free, 5364 buffers
KiB Swap: 0 total, 0 used, 0 free, 333788 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
68 root -55 0 0 0 0 S 8.123 0.000 0:25.84 irq/24-ehci_hcd
233 root -56 0 0 0 0 S 2.924 0.000 0:11.09 irq/29-eth0
14 root -50 0 0 0 0 S 1.625 0.000 0:05.58 kworker/0:1
387 mpd -28 0 101532 19756 3024 S 0.975 1.913 0:04.53 mpd
386 mpd -29 0 101532 19756 3024 S 0.650 1.913 0:02.47 mpd
3 root -2 0 0 0 0 S 0.325 0.000 0:00.64 ksoftirqd/0
1 root 20 0 4796 2720 1796 S 0.000 0.263 0:01.91 systemd
2 root 20 0 0 0 0 S 0.000 0.000 0:00.01 kthreadd
5 root -50 -20 0 0 0 S 0.000 0.000 0:00.00 kworker/0:0H
7 root rt 0 0 0 0 S 0.000 0.000 0:00.00 posixcputmr/0
8 root 20 0 0 0 0 S 0.000 0.000 0:00.00 kcmosdelayd
cpu負荷で10%以上の差があります。cpuの利用比率でみるとusb2ドライバが差を発生させる原因のようで、やはりnasはあまり関係がなさそうです。
BBBの負荷に関してはNo.3512のsyuさんの負荷状況も似たようなものですので、ハードも同じ、動きも同じ、なのに何故僕の環境でだけ問題が発生するのか、本当に不思議です。
あと、nfsも設定を僕の環境に合わせて試して見ましたが、確かに動きませんね。皆様ご指摘の通りの状況かなと思います。やはり、archは手強いですね。
Cubox-nasアップロードありがとうございました。早速、チューニングしたBBB(3.8rt + arch)に繋ぎ、試してみました。
結果ですが、残念ながらdsd再生でのハングや再生中断は止まりませんでした。
トラブルが発生するまでの時間も同じ位(10分位)です。どうもnasが原因というわけではなさそうですね。音もなかなかさんのご指摘と同じで、僕の環境では玄柴nasと差はないですね。再生状況も同じような感じで、cpu負荷が20%前後と高いです。
top - 09:49:23 up 2 min, 1 user, load average: 0.31, 0.25, 0.11
Threads: 82 total, 1 running, 81 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.8 us, 18.5 sy, 0.0 ni, 77.3 id, 0.0 wa, 0.0 hi, 1.4 si, 0.0 st
KiB Mem: 513408 total, 204696 used, 308712 free, 10784 buffers
KiB Swap: 0 total, 0 used, 0 free, 124748 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 14.1 0.0 0:13.36 irq/35-musb-hdr
373 root -54 0 0 0 0 S 2.3 0.0 0:02.17 cifsd
76 root -54 0 0 0 0 S 1.6 0.0 0:02.00 irq/57-4a100000
403 root -48 0 85916 82228 31080 S 1.3 16.0 0:01.26 mpd
399 root -46 0 85916 82228 31080 S 1.0 16.0 0:00.81 mpd
445 root 20 0 5092 1340 1008 R 1.0 0.3 0:00.74 top
17 root -50 0 0 0 0 S 0.3 0.0 0:00.15 kworker/0:1
77 root -54 0 0 0 0 S 0.3 0.0 0:00.49 irq/58-4a100000
398 root -47 0 85916 82228 31080 S 0.3 16.0 0:00.48 mpd
439 root 20 0 23892 5804 4656 S 0.3 1.1 0:00.57 sshd
1 root 20 0 4796 2680 1808 S 0.0 0.5 0:02.04 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd
Cubox(3.10.9rt5 + arch)だとこんな感じです。
top - 15:22:43 up 6 min, 1 user, load average: 0.61, 0.63, 0.31
Threads: 76 total, 1 running, 75 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.1 us, 4.7 sy, 0.0 ni, 90.0 id, 0.0 wa, 0.0 hi, 4.3 si, 0.0 st
KiB Mem: 1032724 total, 472136 used, 560588 free, 5364 buffers
KiB Swap: 0 total, 0 used, 0 free, 333788 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
68 root -55 0 0 0 0 S 8.123 0.000 0:25.84 irq/24-ehci_hcd
233 root -56 0 0 0 0 S 2.924 0.000 0:11.09 irq/29-eth0
14 root -50 0 0 0 0 S 1.625 0.000 0:05.58 kworker/0:1
387 mpd -28 0 101532 19756 3024 S 0.975 1.913 0:04.53 mpd
386 mpd -29 0 101532 19756 3024 S 0.650 1.913 0:02.47 mpd
3 root -2 0 0 0 0 S 0.325 0.000 0:00.64 ksoftirqd/0
1 root 20 0 4796 2720 1796 S 0.000 0.263 0:01.91 systemd
2 root 20 0 0 0 0 S 0.000 0.000 0:00.01 kthreadd
5 root -50 -20 0 0 0 S 0.000 0.000 0:00.00 kworker/0:0H
7 root rt 0 0 0 0 S 0.000 0.000 0:00.00 posixcputmr/0
8 root 20 0 0 0 0 S 0.000 0.000 0:00.00 kcmosdelayd
cpu負荷で10%以上の差があります。cpuの利用比率でみるとusb2ドライバが差を発生させる原因のようで、やはりnasはあまり関係がなさそうです。
BBBの負荷に関してはNo.3512のsyuさんの負荷状況も似たようなものですので、ハードも同じ、動きも同じ、なのに何故僕の環境でだけ問題が発生するのか、本当に不思議です。
あと、nfsも設定を僕の環境に合わせて試して見ましたが、確かに動きませんね。皆様ご指摘の通りの状況かなと思います。やはり、archは手強いですね。
yo 2013/09/23(Mon) 15:42 No.3563
Re: cuboxでsamba
syu 2013/09/28(Sat) 16:40 No.3568
yoさん
すぐにご返事できなくてすみません。お試しいただき感謝。
>cpu負荷で10%以上の差
私の環境では、起動する度に負荷は変化します。2.8MHz-dsdでも、最大で10%以上は変動するようです。良いときは10%以下になりますし、20%近くに達するときもあります。再生を継続していると負荷は少しずつ低下する傾向がありますが、初期の状態にずっと引きずられたままです。どちらでも音は大差ないのが不思議です。そちらでは、どうですか。
起動シーケンスのちょっとした差が影響している印象です。ここを安定化できると良いんでしょうが、この原因が判明しないことには、対策もしにくいですね。
すぐにご返事できなくてすみません。お試しいただき感謝。
>cpu負荷で10%以上の差
私の環境では、起動する度に負荷は変化します。2.8MHz-dsdでも、最大で10%以上は変動するようです。良いときは10%以下になりますし、20%近くに達するときもあります。再生を継続していると負荷は少しずつ低下する傾向がありますが、初期の状態にずっと引きずられたままです。どちらでも音は大差ないのが不思議です。そちらでは、どうですか。
起動シーケンスのちょっとした差が影響している印象です。ここを安定化できると良いんでしょうが、この原因が判明しないことには、対策もしにくいですね。
syu 2013/09/28(Sat) 16:40 No.3568
BBBファイル表記不具合について
始めまして。
この度皆さんのBBBの記事に触発され私も導入し、漸く音出しに至りましたが、以下の不具合が発生しております。
LinuxはVoyage Startetkitを導入した程度のスキルしかございません。
不具合内容は以下の通りです。
1)アップデート完了後、Mpadに現れるファイルのうち日本人アーチストが全て欠落しております。
又バンド名がアルファベットのバンドはフォルダーは見えますが、日本語の曲名は抜けています。
2)上記に加えアルファベット表記のアーチストでもフォルダーが全く出てこない物やアーチストフォルダー内のアルバムの一部が出てこない物が有ります。
私がインストールした物は
http://www.computeraudiophile.com/content/533-geek-speak-how-build-beaglebone-black-mpd-music-server/" target="_blank">http://www.computeraudiophile.com/content/533-geek-speak-how-build-beaglebone-black-mpd-music-server/ ←こちらです。
#基本は上記に記載された通りに作業しましたが、マウントのコマンドは
この通りではどうしても出来ないため下記の通りとしました。
//192.168.0.**/Multimedeia /music cifs username=****,password=**** 0 0
#こちらの記載もChange the line -> music_directory "/var/lib/mpd/music"
to -> music_directory "/mnt/music"となっておりますが、変更していません。
因みに現用のVoyageでは以下の通り記載して有ります。
//192.168.0.**/Multimedia/music cifs username=****'password=****,uid=mpd,file_mode=0644,dir_mode=0755,iocharset=utf8 0 0
(こちらでは全く問題有りません)
今回BBBに記載した内容はパスワード以下の文言が無い(エラーとなってしまい記載無くしたらマウント出来ました)のが大きな違いですが、
不具合の原因はfstabの記述によるのかどうかがよく分かりません。
 
良きアドバイス頂ければと思い質問させて頂きます。
この程度の情報で原因追求できるか分かりませんが、先ずは
わかる限りの情報を記載しました。
以下が私の使用環境となりますので、参考として下さい。
使用機器
1)NAS(qnap  TS-119PⅡ)+ DDC(PCM2704自作基板)+エレアトのP2D基板+DAC(ES9018自作基板)
以上宜しくお願い申し上げます。
Re: BBBファイル表記不具合について
yo 2013/09/20(Fri) 19:49 No.3547
コウさん
> 今回BBBに記載した内容はパスワード以下の文言が無い・・
これが原因じゃないかと思います。iocharset=utf8というのが言語コードの指定ですので、省略すると日本語が正しく表示されなくなるのではないでしょうか。
,uid=mpd,file_mode=0644,dir_mode=0755,iocharset=utf8
の内容に誤りないのでfstabの記述でエラーになったのは別の原因だと思います。
コピーミスかもしれませんが
> //192.168.0.**/Multimedia/music cifs username=****'password=****,uid=mpd,file_mode=0644,dir_mode=0755,iocharset=utf8 0 0
は二箇所おかしなところがあります。
Multimedia/musicはMultimedia /musicの筈です(しきりの空白が必要)
username=****'password=****はしきりの文字が「'」でなく「,」です。
> 今回BBBに記載した内容はパスワード以下の文言が無い・・
これが原因じゃないかと思います。iocharset=utf8というのが言語コードの指定ですので、省略すると日本語が正しく表示されなくなるのではないでしょうか。
,uid=mpd,file_mode=0644,dir_mode=0755,iocharset=utf8
の内容に誤りないのでfstabの記述でエラーになったのは別の原因だと思います。
コピーミスかもしれませんが
> //192.168.0.**/Multimedia/music cifs username=****'password=****,uid=mpd,file_mode=0644,dir_mode=0755,iocharset=utf8 0 0
は二箇所おかしなところがあります。
Multimedia/musicはMultimedia /musicの筈です(しきりの空白が必要)
username=****'password=****はしきりの文字が「'」でなく「,」です。
yo 2013/09/20(Fri) 19:49 No.3547
Re: BBBファイル表記不具合について
yo様
ご返答頂き有難う御座います。
fstab記述の際にuid=mpd,file_mode=0644,dir_mode=0755,iocharset=utf8
と記載したところマウントエラー発生したので削除していたのですが
試行錯誤してた時だったので、違う箇所でミスが有ったのでしょう。
お手本にしていたサイトの記載例では何度試してもエラーが出てしまうのは何故でしょう？マウント出来ずに2日程費やしてしまいました。
ご指摘の記載ミスはコピーミスです。実際マウント出来ていますので、この部分は問題有りません。帰宅後再度編集してみます。
linuxはちゃんと勉強しないと身につかないですね。
スキル不足の為皆さんが公開するimgを利用出来無いのがもどかしいです！
今後とも宜しくお願いします。
ご返答頂き有難う御座います。
fstab記述の際にuid=mpd,file_mode=0644,dir_mode=0755,iocharset=utf8
と記載したところマウントエラー発生したので削除していたのですが
試行錯誤してた時だったので、違う箇所でミスが有ったのでしょう。
お手本にしていたサイトの記載例では何度試してもエラーが出てしまうのは何故でしょう？マウント出来ずに2日程費やしてしまいました。
ご指摘の記載ミスはコピーミスです。実際マウント出来ていますので、この部分は問題有りません。帰宅後再度編集してみます。
linuxはちゃんと勉強しないと身につかないですね。
スキル不足の為皆さんが公開するimgを利用出来無いのがもどかしいです！
今後とも宜しくお願いします。
Re: BBBファイル表記不具合について
yo 2013/09/20(Fri) 21:34 No.3549
カーネルの設定でutf8が入っていないのですかね。この場合はちょっと大変で、カーネルをビルドし、入れ換える必要があります。僕のdebianのイメージならutf8はOKです(cifsも入れてあります)。
> スキル不足の為皆さんが公開するimgを利用出来無いのがもどかしいです！
Windows環境でddwinを使って書き込むだけですので、多分、audiophileのやり方より簡単だと思います(ddwinのありかはググって下さい)。fstabの設定方法などは同じです。
> スキル不足の為皆さんが公開するimgを利用出来無いのがもどかしいです！
Windows環境でddwinを使って書き込むだけですので、多分、audiophileのやり方より簡単だと思います(ddwinのありかはググって下さい)。fstabの設定方法などは同じです。
yo 2013/09/20(Fri) 21:34 No.3549
Re: BBBファイル表記不具合について
yo様
追加アドバイス有難う御座います。
昨晩は気がついたら眠に落ちてしまい作業出来ませんでした。
本日も仕事の為出来るか分かりませんが、以下の内容で試してみます。
1)yo様のイメージ、No3403 http://www.symphonic-net.com/kubotayo/cgi-bin/downlogs.cgi?id=0B1V9ShHUc5NqM2xra0ZhNENnOFk" target="_blank">http://www.symphonic-net.com/kubotayo/cgi-bin/downlogs.cgi?id=0B1V9ShHUc5NqM2xra0ZhNENnOFk
をダウンロード。
2)7zipで解凍後、DDWINでSDカードにコピー。
3)BBBにカード挿入し内部メモリーにコピー。
4)ディレクトリ作成後、fstab及びmpd.confを編集。
以上の作業を実施し結果報告いたします。
途中どうしても分からない場合は質問させて下さい。
お手数お掛けしますが宜しくお願い申し上げます。
追加アドバイス有難う御座います。
昨晩は気がついたら眠に落ちてしまい作業出来ませんでした。
本日も仕事の為出来るか分かりませんが、以下の内容で試してみます。
1)yo様のイメージ、No3403 http://www.symphonic-net.com/kubotayo/cgi-bin/downlogs.cgi?id=0B1V9ShHUc5NqM2xra0ZhNENnOFk" target="_blank">http://www.symphonic-net.com/kubotayo/cgi-bin/downlogs.cgi?id=0B1V9ShHUc5NqM2xra0ZhNENnOFk
をダウンロード。
2)7zipで解凍後、DDWINでSDカードにコピー。
3)BBBにカード挿入し内部メモリーにコピー。
4)ディレクトリ作成後、fstab及びmpd.confを編集。
以上の作業を実施し結果報告いたします。
途中どうしても分からない場合は質問させて下さい。
お手数お掛けしますが宜しくお願い申し上げます。
Re: BBBファイル表記不具合について
yo様
昨晩上記の工程にて作業しましたがどうしても先に進めず
困り果てています。
yo様のファイルをダウンロードし、解凍、DDwinでSDカードに
書き込みしたものをBBBに挿入しましたがブートしません。
（bootボタン押しながら電源投入しています）。
コピー先のSDカードはフォーマットをFAT32、NTFS両方で試したりしましたが駄目。
コピーソフトもwin32diskimageを使ったりしましたが駄目です。
audiophileのイメージではboot出来るので本体は壊れていません。
大変お恥ずかしい内容ですが、何が原因かご教授頂けると幸いです。
以上よろしくお願いします。
昨晩上記の工程にて作業しましたがどうしても先に進めず
困り果てています。
yo様のファイルをダウンロードし、解凍、DDwinでSDカードに
書き込みしたものをBBBに挿入しましたがブートしません。
（bootボタン押しながら電源投入しています）。
コピー先のSDカードはフォーマットをFAT32、NTFS両方で試したりしましたが駄目。
コピーソフトもwin32diskimageを使ったりしましたが駄目です。
audiophileのイメージではboot出来るので本体は壊れていません。
大変お恥ずかしい内容ですが、何が原因かご教授頂けると幸いです。
以上よろしくお願いします。
Re: BBBファイル表記不具合について
まさまさ 2013/09/22(Sun) 14:57 No.3555
コウさん
> 3)BBBにカード挿入し内部メモリーにコピー。
内部メモリーって、eMMCのことでしょうか？
audiophile のイメージの方では、eMMCへコピーされるようですが、yoさんのイメージは SD Card でそのまま動作すると思います。このあたりで何か操作を間違っていませんでしょうか？
あと SD card の容量はいくらのをお使いですか？
私は 4GB のを使っています。
また、DDwin で SDカードに書き込みを行うのであれば、
SDカードをフォーマットしたりは不要と思います。
何か参考になれば
> 3)BBBにカード挿入し内部メモリーにコピー。
内部メモリーって、eMMCのことでしょうか？
audiophile のイメージの方では、eMMCへコピーされるようですが、yoさんのイメージは SD Card でそのまま動作すると思います。このあたりで何か操作を間違っていませんでしょうか？
あと SD card の容量はいくらのをお使いですか？
私は 4GB のを使っています。
また、DDwin で SDカードに書き込みを行うのであれば、
SDカードをフォーマットしたりは不要と思います。
何か参考になれば
まさまさ 2013/09/22(Sun) 14:57 No.3555
Re: BBBファイル表記不具合について
yo 2013/09/22(Sun) 16:28 No.3557
コウさん
(1)電源を落としてイメージを書き込んだsdカードをセット
(2)ブートボタンを押した状態で電源を入れる
(3)起動ランプがチカチカしだしたら、ボタンをはずす
これで暫く(30秒位)待てば、sshログイン可能な状態になるはずです。
まさまささんが書いていらっしゃるように、イメージの書き込みなので、sdカードのフォーマットは関係ありません。
上記方法で駄目なら、カードによるトラブル位ですかね。他のメーカのカードをお持ちであれば、それで試してみて頂けますか。
あと、タイミングでブート中に止まってしまいログインに辿り着けないということはありますので、何度か試してみて下さい。
シリアル接続されていれば、どこで止まっているかで問題の切り分けが出来るのですが。
(1)電源を落としてイメージを書き込んだsdカードをセット
(2)ブートボタンを押した状態で電源を入れる
(3)起動ランプがチカチカしだしたら、ボタンをはずす
これで暫く(30秒位)待てば、sshログイン可能な状態になるはずです。
まさまささんが書いていらっしゃるように、イメージの書き込みなので、sdカードのフォーマットは関係ありません。
上記方法で駄目なら、カードによるトラブル位ですかね。他のメーカのカードをお持ちであれば、それで試してみて頂けますか。
あと、タイミングでブート中に止まってしまいログインに辿り着けないということはありますので、何度か試してみて下さい。
シリアル接続されていれば、どこで止まっているかで問題の切り分けが出来るのですが。
yo 2013/09/22(Sun) 16:28 No.3557
Re: BBBファイル表記不具合について
コウ 2013/09/22(Sun) 16:56 No.3558
yo様、まさまさ様
この度はアドバイス頂きありがとうございました。
先ほど無事に起動確認出来ました。
boot出来なかった原因についてはおそらく次の通りかと。
*SDカードからブートさせる時S2スイッチを押しながら電源投入していた（audiophileのやりかた）。
他の情報でもSDカードからbootさせるときにはS2スイッチを押しながら電源投入と記載があった事からこのやり方に固執してしまった事です。
まさまさ様の一言でそのまま電源投入したところ無事に起動となりました。
この度はお騒がせして申し訳ございません。
一息ついたら、セッティングに入ろうかと思います。
以上、今後ともよろしくお願いします。
この度はアドバイス頂きありがとうございました。
先ほど無事に起動確認出来ました。
boot出来なかった原因についてはおそらく次の通りかと。
*SDカードからブートさせる時S2スイッチを押しながら電源投入していた（audiophileのやりかた）。
他の情報でもSDカードからbootさせるときにはS2スイッチを押しながら電源投入と記載があった事からこのやり方に固執してしまった事です。
まさまさ様の一言でそのまま電源投入したところ無事に起動となりました。
この度はお騒がせして申し訳ございません。
一息ついたら、セッティングに入ろうかと思います。
以上、今後ともよろしくお願いします。
コウ 2013/09/22(Sun) 16:56 No.3558
Re: BBBファイル表記不具合について
コウ 2013/09/22(Sun) 17:05 No.3559
yo様
コメント入れ違いになっていましました。
私の方ではブートボタンを押しながら電源投入すると
LEDの反応が全く有りません。
私のBBBのバージョンはA5Cなんですがそれが原因？
何とも不思議ではありますが、ブートボタン押さずに
電源投入で起動できました。
以上ご報告まで。
コメント入れ違いになっていましました。
私の方ではブートボタンを押しながら電源投入すると
LEDの反応が全く有りません。
私のBBBのバージョンはA5Cなんですがそれが原因？
何とも不思議ではありますが、ブートボタン押さずに
電源投入で起動できました。
以上ご報告まで。
コウ 2013/09/22(Sun) 17:05 No.3559
Re: BBBファイル表記不具合について
yo 2013/09/22(Sun) 22:20 No.3560
> (3)起動ランプがチカチカしだしたら、ボタンをはずす
というのは僕の勘違いかもしれません。ボタンをはずしたらチカチカしだしたのかもしれません。このタイミングかなり微妙なようで、僕の環境でも、ボタンを外すタイミングがずれると、emmcで起動されるということはありました。一度sd起動になれば、後はその状態が維持されますので、とりあえず問題はなくなったのではないかと思います。
というのは僕の勘違いかもしれません。ボタンをはずしたらチカチカしだしたのかもしれません。このタイミングかなり微妙なようで、僕の環境でも、ボタンを外すタイミングがずれると、emmcで起動されるということはありました。一度sd起動になれば、後はその状態が維持されますので、とりあえず問題はなくなったのではないかと思います。
yo 2013/09/22(Sun) 22:20 No.3560
