syuさん

またまた、syuマジックですね(^^)。lan直結とは !!!!

写真ですが、下の方はI2sのためのbbbと関連の基板だから、上の部分だけ注目でいいのですよね。
apuは一台しか持っていないので、妥協して(^^;;;、usb接続のlan変換用アダプタを使い、これとcuboxを組み合わせ、試してみるかなと思います。

yoさん

>マジック
^^;;
こんなことで変わるはずはないと思っていたので、大幅な変化は意外でした。ハブを通さないから信号相関ノイズが少なくなるんでしょうかね。ハブには別のポートで接続されているので、コモンモードノイズはそっちから入りそうだし。

LAN直結はサーバのテストなんかではよく見かけます。自家業務用サーバ(ubuntu)も二重化してデータ保護していますが、二重化サーバ同士はLAN直結で運用しています。

>usb接続のlan変換用アダプタ
これをハブに接続して、元々のLANポートを直結用に使用すればよさそうですね。

komaさん

cuboxやbbbでsdカードに音楽データを置き、そこから直接再生して見たことがありますが、音は改善しないか悪化するケースが多かったように思います。

「ethernetを経由することで音が良くなる現象」がキーポイントではないかと思います。どの伝送系でもノイズ増加は避けられませんが、ethernetのような混入するノイズの信号相関が低い伝送系を介在させることで、信号相関ジッタなど音を汚くするノイズが減少しているのではないかと妄想しています。

ソニーのアンプを設計している某氏など、ethernetを何度も経由してデータのやり取りを繰り返すほど音が良くなるなどと公言されているようですよ。リッピングしたデータをethernet経由でコピーを繰り返すほど良くなるとか^^。やってみます？

>たとえば4コアCPU激速マシンにRAIDを組んでそこに音楽データーを保存してmpdを介して音楽再生

どうですかね。apuはheadlessでグラフィック系のノイズが混入する機会が少ないのが最も効いているような気がします。

効果の程は不明ですが、apuをサーバにする場合に軽量化kernel(no forced preemption)を使っていますので、とりあえずyoさんのアップローダに上げておきます。

http://mimizukobo.sakura.ne.jp/upload/linux-image-3.14.13-40720nfd_3.14.13-40720nfd-10.00.Custom_amd64.deb" target="_blank">http://mimizukobo.sakura.ne.jp/upload/linux-image-3.14.13-40720nfd_3.14.13-40720nfd-10.00.Custom_amd64.deb
http://mimizukobo.sakura.ne.jp/upload/linux-headers-3.14.13-40720nfd_3.14.13-40720nfd-10.00.Custom_amd64.deb" target="_blank">http://mimizukobo.sakura.ne.jp/upload/linux-headers-3.14.13-40720nfd_3.14.13-40720nfd-10.00.Custom_amd64.deb

voyage-0.9.2_amd64をPXEインストールしてから適用します。
http://www.voyage.hk/download/ISO/amd64/voyage-0.9.2_amd64.iso" target="_blank">http://www.voyage.hk/download/ISO/amd64/voyage-0.9.2_amd64.iso

syuさん

> これをハブに接続して、元々のLANポートを直結用に使用すればよさそうですね。

とりあえず、それで試してみるつもりです。
上手くいったら、もう一台apuとなりますかね(僕のNewAlixはβ版だから ^^;;;)。

別の書き込みになりますが

> どうですかね。apuはheadlessでグラフィック系のノイズが混入する機会が少ないのが最も効いているような気がします。

これは僕も同感です。むやみとcpuパワーを増やしても無意味だと思いますね。やっぱり、音にはグラフィック無しというのは強力だと思います。

LAN直結をNo.4905とは別の方法で試してみました。
apu1c4/voyage-linux(amd64)で構成したサーバにハブ機能を追加する方法です。

サーバのeth1とクライアントのeth1だけを直結します。こうするとクライアント側のLANポートはひとつですみます。直結LANケーブルのトラフィックは増えますがたいした量ではないはずです。

サーバ側のkernelはbridgeが使える構成が必要ですが、voyage linux(amd64)には入っています。
No.4925の軽量化カーネルには入っていませんので再コンパイルが必要です。

Networking --->
Networking options --->
<M>802.1d Ethernet Bridging
Device Drivers --->
Network device support --->
<M>Universal TUN/TAP device driver support

設定は

[server側] eth0:static(0.0.0.0) eth1:static(0.0.0.0) vbr0:static(192.168.11.102)

root@voyage-nfs:~# nano /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 0.0.0.0

auto eth1
iface eth1 inet static
address 0.0.0.0

auto vbr0
iface vbr0 inet static
address 192.168.11.102
netmask 255.255.255.0
network 192.168.11.255
bridge_ports eth0 eth1
bridge_stp off

root@voyage-nfs:~# nano /etc/exports

/Public 192.168.11.101(rw,no_subtree_check,all_squash,sync)

---

[mpd側] eth0:down eth1:static(192.168.11.101)

root@voyage-mpd:~# nano /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth1
iface eth1 inet static
address 192.168.11.101
netmask 255.255.255.0
network 192.168.11.0

root@voyage-mpd:~# nano /etc/fstab

fstab 192.168.11.102:Public/Music /music nfs rsize=24576,wsize=8192 0 0
====

bbbのようなLANポートがひとつの機種でのLAN直結がしやすくなると考え、今回のbridge方式を試してみました。

音は良好ではありますが、残念ながらNo.4905の直結LAN方式と比べると細精感は大幅に低下します。No.4905方式の「肝」の部分がすっぽり抜け落ちます。空間再現、実在感、細かい質感みたいな部分です。

LAN直結をさらに別の方法で試してみました。サーバのLANポートをフル動員し、サーバのハブ機能をeth2でも使えるようにしました。サーバのeth0をethernet、サーバのeth1をクライアントのeth0、サーバのeth2をクライアントのeth1に接続します。

設定は

[server側] eth0:static(0.0.0.0) eth1:static(0.0.0.0) eth2:static(0.0.0.0) vbr0:static(192.168.11.102)

root@voyage-nfs:~# nano /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 0.0.0.0

auto eth1
iface eth1 inet static
address 0.0.0.0

auto eth2
iface eth2 inet static
address 0.0.0.0


auto vbr0
iface vbr0 inet static
address 192.168.11.102
netmask 255.255.255.0
network 192.168.11.255
bridge_ports eth0 eth1 eth2
bridge_stp off

root@voyage-nfs:~# nano /etc/exports

/Public 192.168.11.1/24(rw,no_subtree_check,all_squash,sync)

---

[mpd側] eth0:static(192.168.11.101) eth1:static(192.168.11.103)
[誤記がありましたので修正しました]

root@voyage-mpd:~# nano /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.11.101
netmask 255.255.255.0
network 192.168.11.0

auto eth1
iface eth1 inet static
address 192.168.11.103
netmask 255.255.255.0
network 192.168.11.0

root@voyage-mpd:~# nano /etc/fstab

fstab 192.168.11.102:Public/Music /music nfs rsize=24576,wsize=8192 0 0
====

GMPCの接続先は192.168.11.103に変更します。
サーバのハブ機能が192.168.11.101と192.168.11.103をどのように使い分けるか明確には定義されていませんが、LANポートの点滅状態を見ると、192.168.11.101でmusicデータ、11.103でその他に大まかに使い分けてくれているように見えます。

No.4905比で、音は過剰な細精感がなくなります。それに関連した高域の刺激感がなく、これが一番自然な感じですが、硬いという意見も。

連投ごめんなさい。

しばらく聴いてみましたが、結局、No.4905が最良と結論しました。これが良い原因がほとんど不明なのが問題ですが、ともかく結果さえ良ければ・・

>tiny-core linux についてはご存じない方も多いかと思いますが、シンプル、超小型のkernelとinitrdで構成される興味深いディストリビューションです。CuboxやBeagleBoneBlack用のMPD搭載システムでLightMPDというシステムがありますが、このオリジナルはこれだと思います(オリジナルの意味はそのまま移植という意味ではなく、コンセプトが同じという意味です)。こちらはLightMPDと違い、僕の環境でも安定動作しますし、音もいいので、お勧めです。

とのことで、興味をひかれました。つきましては、ディスクイメージを公開していただきたいと思います。
現在、newALIXをSDカードで使っています。システムにはインストールしたくないので、USBかSDから起動するシステムを考えています。
よろしくお願いします。

syuさん
＞音は改善しないか悪化するケースが多かった

今回のNEW ALIXでSDカードに音楽データを入れて
試聴してみてほしいです。音の色が濃いです(笑)
私の耳、環境がおかしいのかも知れませんが．．．

4905の
>描写は極めて細密になりますが、線は細くなり、音量が下がった感じになり、低音は軽すぎるほど軽く、弾力性に富みますが、押し出してくる量感は低くなります。聴感上の周波数バランスがかなり変わります。空間描写は相当に明確になっていると思います。
に興味を持ちました。
　ここでは基板そのものをいじることはないようですが、ファインメットシートを両面テープで基板面やあまり発熱しないICにぺたぺた貼り付けるだけでほぼ同じ傾向の音になります。ちなみにファインメットシートはノイズイーターとして作用していると思われています。私は基板破壊を覚悟でさらにコンデンサ追加を行い、温室の改善を目指しますが、ファインメットシートを張るだけであれば基盤を壊す可能性はほとんどないと思います。お勧めします。

yseki118さん

> つきましては、ディスクイメージを公開していただきたいと思います。

tiny-core linux の場合、イメージにしても、特にインストールが簡単になるわけではないので、僕はパスです。あと、NewAlixの場合、システムの置き場所のディフォルトは内蔵ssdだと思います。この点でもイメージ化は意味が無いとと考えます。
システムの作り方についてはそのうちサイトに書き込むつもりです。

yoさん
>イメージ化は意味が無いと考えます。システムの作り方についてはそのうちサイトに書き込むつもりです。

了解しました。
tiny-core linuxのシステムの作り方の記事を、楽しみに待っています。
レスありがとうございました。

syuさん

lan直結方式で音がでました。再生中の写真です。
http://mimizukobo.sakura.ne.jp/upload/079.JPG" target="_blank">http://mimizukobo.sakura.ne.jp/upload/079.JPG
サーバ機はatom機。cuboxだと、ドライバのインストールが必要だと分かったこと、usbポートが不足するため、ハードdiskとlan対応のusbアダプタが重なること、を回避するためatom機にしました。使ったatom機は以前サイトで紹介したことがありますが、
http://mimizukobo.sakura.ne.jp/articles/articles006.html#046" target="_blank">http://mimizukobo.sakura.ne.jp/articles/articles006.html#046
この機種です。

atom機のソフトはVoyageMPD 0.9.2にファイルサーバ機能を追加しました。やり方はsyuさんと同じようなものなので省略。NewAlixのカーネルはVoyageMPD 0.9.2 オリジナルとsyuさん作のrtカーネルの両方を適宜とっかえひっかえしながら、使いました。nasはとりあえずnfsを使用。cifsもインストールしてあるので、こちらもそのうち試してみるつもり。
atom機の前面のusbポートにusb-lan変換アダプタ(eth1に固定されます)をつなぎ、NewAlixと直結接続。後面のusbポートにnas用ハードディスクをつないでいます。usb-lan変換アダプタは Kontron (Industrial Computer Source / ICS Advent) DM9601 というもの。VoyageMPD 0.9.2だと、何もしなくても認識しました。
ネットワークの設定は#4905のdhcp方式と#4946/7のbridge方式(多少アレンジ)の両方で試してみました。
dhcp方式では、atom機のlan端子(eth0)とNewAlixのeth1を直結接続するつもりだったのですが、atom機のlan端子(eth0)をdhcp側にしないと、ネットワークの認識が出来なくなります。理由は不明、調査中です。このため、usb-lan変換アダプタ(eth1)とNewAlix eth1を直接接続しました。
Bridge方式はそれぞれのeth0側を直結しています。この方が直結したlanの負荷を軽くできるはずなので。
結局、サーバ、クライアント共に、dhcpはeth1(atom側はusb-lan変換アダプタ)で、bridgeはeth0(atom側は内蔵lan)で直結したことになります。

音ですが、おっしゃるように大きく変わりますね。ビックリです。「コーンタイプとコンデンサータイプのスピーカくらい違う」という表現にざぶとん十枚です(^^)。またdhcpにするか、bridgeにするかでも変わります。僕の環境ではbridgeがお勧め。これだと昔使っていたQuad ESL63を彷彿させる音がします。

動作状況はいろいろチェックしてみましたが、syuさんの結果とは多少異なります。dhcp/bridgeどちらのやり方でもeth0側が優先して動いている感じです。結果的に、bridge方式では90%以上が直結回線で処理されることになります。bridge方式の音の良さはこれが理由かと思います。
他にも挙動不審な動きはいっぱいあるので、謎解きはこれからです。

いずれにしても、これは脱法ドラッグ並に(^^;;;中毒性のあるつなぎ方なので、一度味わうとこれなしでは済まなくなりそうです(~~;;;(~~;;;。bbb用にesata対応のハードディスクケース(cuboxにつなぐつもり)と追加のusb-lan変換アダプタを注文しちゃいました。

yoさん

>大きく変わりますね。ビックリです。

ね、ビックリですよね。でも単純直結とbridgeで私と評価が異なるのは好みの違いなのか環境によるのか・・・うちの環境では、単純直結のやわらかな響きは、bridge２種類では不可能なレベルなんですよね。でも別スレッドに書いたようにbotic-v1が僅差で優位(高精細なのにソフト)でした。

>これは脱法ドラッグ並
「危険ドラッグ」と呼び換えることになったそうですが、所詮言葉の誤魔化し。あれは正しくは「合成麻薬」ですから、ここも正しく麻薬的とでもしておきましょうか　^^;;

>bbb用にesata対応のハードディスクケース(cuboxにつなぐつもり)と追加のusb-lan変換アダプタを注文

これで合理的な理由が付いたことになるので、ここはapu1d4をpc engineのshopに注文でしょうね。ケース付き運賃込みUS$211程度で数日で到着でした。

が、今見たら、先日まで500台以上ストックがあったapu1d4が売り切れています。ケースも色を選べないです。売れてますね。
http://www.pcengines.ch/order1.php?c=4" target="_blank">http://www.pcengines.ch/order1.php?c=4

syuさん

apu1の方が強力だとは思うのですが、ハードディスクをsata-esata接続する時、ケースに穴を開けないといけないので、思案しているのですよね。
別スレッドですが、bbbのusbネッワークアダプタ対応のドライバの動かし方は謎ですね。僕のアダプタのドライバ(DM9601)もあるのですが、認識されません。modprobeも
root@bbb:~# modprobe dm9601
ERROR: could not insert 'dm9601': Exec format error
とエラーになります。変だなぁ。

yoさん

>ケースに穴

無理にはお勧めしませんが、こんなのありますよ。

ＳＡＴＡ－７Ｐ
Ｓｅｒｉａｌ　ＡＴＡプラグ　７Ｐ　カバー無し
https://www.sengoku.co.jp/mod/sgk_cart/detail.php?code=4AK6-MAEU" target="_blank">https://www.sengoku.co.jp/mod/sgk_cart/detail.php?code=4AK6-MAEU
製作例
http://ameblo.jp/suzume-pc/entry-11428640773.html" target="_blank">http://ameblo.jp/suzume-pc/entry-11428640773.html

アンテナ用の穴がふたつあります。sataケーブルの片側を切断すれば穴を通りますので、通してから切断端にsataコネクタをハンダ付けすれば使えるかもしれません。

私は何となくですがsata(e-sata)でのHDD直結はノイズ源になりそうな気がして敬遠しています。

>ドライバの動かし方
別のアダプタでも同じなんですね。ここは「助けてtinkerさん！」ですかね^^;

syuさん

> アンテナ用の穴がふたつあります。sataケーブルの片側を切断すれば穴を通りますので、通してから切断端にsataコネクタをハンダ付けすれば使えるかもしれません。

ご教授ありがとうございます。僕のNewAlixは初期型なので、アンテナ用穴が無いのですよね。ハンダ付けは1.25mmピッチとあるから、超絶技巧のレベルですね。残念ながら諦めます。

ところで、どうも、syuさんのところと僕のところでは直結方式の挙動が違うようなので、少し長くなりますが、データを先ず貼り付けます。

ブリッジ接続(eth0側が直結)
サーバ側
/etc/network/interfaces
auto eth0
iface eth0 inet static
address 0.0.0.0

auto eth1
iface eth1 inet static
address 0.0.0.0

auto br0
iface br0 inet static
address 192.168.0.30
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.0.1
bridge_ports eth0 eth1
bridge_stop off
bridge_maxwait 5

/etc/exports
/mnt/sdb 192.168.0.*(rw,no_subtree_check,all_squash,sync)

クライアント側
/etc/network/interfaces
auto eth0
iface eth0 inet static
address 192.168.0.18
netmask 255.255.255.0
broadcast 192.168.0.255

auto eth1
iface eth1 inet static
address 192.168.0.38
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.0.1
dns-nameservers 192.168.0.1

/etc/fstab
192.168.0.30:/mnt/sdb /mnt/sdb nfs rsize=8192,wsize=4096 0 0

結果
root@voyage:~# cat /proc/interrupts
CPU0 CPU1
0: 119 0 IO-APIC-edge timer
4: 1 7 IO-APIC-edge serial
8: 0 1 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
17: 810 77392 IO-APIC-fasteoi ehci_hcd:usb1, ehci_hcd:usb2, ehci_hcd:usb3
18: 0 0 IO-APIC-fasteoi ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7
19: 29 3839 IO-APIC-fasteoi ahci
40: 735 48344 PCI-MSI-edge eth0
41: 15 376 PCI-MSI-edge eth1
NMI: 0 0 Non-maskable interrupts
LOC: 29485 42058 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 0 0 Performance monitoring interrupts
IWI: 0 0 IRQ work interrupts
RTR: 0 0 APIC ICR read retries
RES: 143015 44895 Rescheduling interrupts
CAL: 6 12 Function call interrupts
TLB: 498 414 TLB shootdowns
ERR: 0
MIS: 0

root@voyage:~# ping -c 10 192.168.0.30
PING 192.168.0.30 (192.168.0.30) 56(84) bytes of data.
64 bytes from 192.168.0.30: icmp_req=1 ttl=64 time=0.176 ms
64 bytes from 192.168.0.30: icmp_req=2 ttl=64 time=0.381 ms
64 bytes from 192.168.0.30: icmp_req=3 ttl=64 time=0.383 ms
64 bytes from 192.168.0.30: icmp_req=4 ttl=64 time=0.405 ms
64 bytes from 192.168.0.30: icmp_req=5 ttl=64 time=0.390 ms
64 bytes from 192.168.0.30: icmp_req=6 ttl=64 time=0.383 ms
64 bytes from 192.168.0.30: icmp_req=7 ttl=64 time=0.408 ms
64 bytes from 192.168.0.30: icmp_req=8 ttl=64 time=0.393 ms
64 bytes from 192.168.0.30: icmp_req=9 ttl=64 time=0.396 ms
64 bytes from 192.168.0.30: icmp_req=10 ttl=64 time=0.208 ms

--- 192.168.0.30 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9002ms
rtt min/avg/max/mdev = 0.176/0.352/0.408/0.082 ms


単純直結(eth1側が直結)

サーバ側
/etc/network/interfaces
auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet static
address 192.168.0.17
netmask 255.255.255.0
broadcast 192.168.0.255

/etc/exports
/mnt/sdb 192.168.0.*(rw,no_subtree_check,all_squash,sync)

クライアント側
/etc/network/interfaces
auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet static
address 192.168.0.18
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255

/etc/fstab
192.168.0.17:/mnt/sdb /mnt/sdb nfs rsize=8192,wsize=4096 0 0

結果
root@voyage:~# cat /proc/interrupts
CPU0 CPU1
0: 119 0 IO-APIC-edge timer
4: 1 7 IO-APIC-edge serial
8: 0 1 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
17: 168 15923 IO-APIC-fasteoi ehci_hcd:usb1, ehci_hcd:usb2, ehci_hcd:usb3
18: 0 0 IO-APIC-fasteoi ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7
19: 28 3906 IO-APIC-fasteoi ahci
40: 55 8610 PCI-MSI-edge eth0
41: 0 35 PCI-MSI-edge eth1
NMI: 0 0 Non-maskable interrupts
LOC: 18481 23378 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 0 0 Performance monitoring interrupts
IWI: 0 0 IRQ work interrupts
RTR: 0 0 APIC ICR read retries
RES: 59504 41608 Rescheduling interrupts
CAL: 13 7 Function call interrupts
TLB: 489 484 TLB shootdowns
ERR: 0
MIS: 0

root@voyage:~# ping -c 10 192.168.0.17
PING 192.168.0.17 (192.168.0.17) 56(84) bytes of data.
64 bytes from 192.168.0.17: icmp_req=1 ttl=64 time=0.302 ms
64 bytes from 192.168.0.17: icmp_req=2 ttl=64 time=0.298 ms
64 bytes from 192.168.0.17: icmp_req=3 ttl=64 time=0.439 ms
64 bytes from 192.168.0.17: icmp_req=4 ttl=64 time=0.467 ms
64 bytes from 192.168.0.17: icmp_req=5 ttl=64 time=0.444 ms
64 bytes from 192.168.0.17: icmp_req=6 ttl=64 time=0.465 ms
64 bytes from 192.168.0.17: icmp_req=7 ttl=64 time=0.478 ms
64 bytes from 192.168.0.17: icmp_req=8 ttl=64 time=0.466 ms
64 bytes from 192.168.0.17: icmp_req=9 ttl=64 time=0.471 ms
64 bytes from 192.168.0.17: icmp_req=10 ttl=64 time=0.332 ms

--- 192.168.0.17 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9006ms
rtt min/avg/max/mdev = 0.298/0.416/0.478/0.071 ms
root@voyage:~# ping -c 10 192.168.0.7
PING 192.168.0.7 (192.168.0.7) 56(84) bytes of data.
64 bytes from 192.168.0.7: icmp_req=1 ttl=64 time=0.233 ms
64 bytes from 192.168.0.7: icmp_req=2 ttl=64 time=0.391 ms
64 bytes from 192.168.0.7: icmp_req=3 ttl=64 time=0.393 ms
64 bytes from 192.168.0.7: icmp_req=4 ttl=64 time=0.401 ms
64 bytes from 192.168.0.7: icmp_req=5 ttl=64 time=0.397 ms
64 bytes from 192.168.0.7: icmp_req=6 ttl=64 time=0.397 ms
64 bytes from 192.168.0.7: icmp_req=7 ttl=64 time=0.396 ms
64 bytes from 192.168.0.7: icmp_req=8 ttl=64 time=0.261 ms
64 bytes from 192.168.0.7: icmp_req=9 ttl=64 time=0.305 ms
64 bytes from 192.168.0.7: icmp_req=10 ttl=64 time=0.235 ms

--- 192.168.0.7 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9006ms
rtt min/avg/max/mdev = 0.233/0.340/0.401/0.074 ms


昨日のメッセージに書き込んだように僕のところはどちらの方式でもeth0が優先されるようで、この原因が謎です。syuさんのところとの違いはいろいろあるのですが、nfsのexportsの仕方の問題かなとも思います。僕は
/mnt/sdb 192.168.0.*(rw,no_subtree_check,all_squash,sync)
syuさんは
/Public 192.168.10.101(rw,no_subtree_check,all_squash,sync) 192.168.11.7(rw,no_subtree_check,all_squash,sync)
となっています。
syuさんに合わせなかった理由は二つ目の192.168.11.7が何のアドレスなのか分からなかったからなのですが、教えて頂けますか。

yoさん

最も違うのはbridgeの構成ですかね。

私：
auto vbr0
iface vbr0 inet static

vはvirtualでしょうか。

yoさん：
auto br0
iface br0 inet static

どっちでも動くんでしょうが、私はvbr0とbr0の違いはよくわかってないまま設定しています。

192.168.11.7はbbbです。ここは影響していないと思います。

apu1c4-server(amd64)の設定を変更し、ハブとはeth1で接続、bbbとはeth0でbridge、apu1c-mpdとはeth2で独立直結方式にしてみました。

[/etc/network/interfaces]

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 0.0.0.0

auto eth1
iface eth1 inet static
address 0.0.0.0

auto vbr0
iface vbr0 inet static
address 192.168.11.102
netmask 255.255.255.0
network 192.168.11.0
bridge_ports eth0 eth1
bridge_stp off

auto eth2
iface eth2 inet static
address 192.168.10.102
netmask 255.255.255.0
network 192.168.10.0
broadcast 192.168.10.255

これで正常に動作しています。

root@voyage-nfs:~# ifconfig

eth0 Link encap:Ethernet HWaddr xxxxxxxxxxxx
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:625717 errors:0 dropped:0 overruns:0 frame:0
TX packets:1039053 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:68065255 (64.9 MiB) TX bytes:1294908456 (1.2 GiB)

eth1 Link encap:Ethernet HWaddr xxxxxxxxxxxx
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:94359 errors:0 dropped:0 overruns:0 frame:0
TX packets:48118 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9610244 (9.1 MiB) TX bytes:7853728 (7.4 MiB)

eth2 Link encap:Ethernet HWaddr xxxxxxxxxxxx
inet addr:192.168.10.102 Bcast:192.168.10.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9748 errors:0 dropped:0 overruns:0 frame:0
TX packets:69835 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1619414 (1.5 MiB) TX bytes:101147666 (96.4 MiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:680 errors:0 dropped:0 overruns:0 frame:0
TX packets:680 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:45696 (44.6 KiB) TX bytes:45696 (44.6 KiB)

vbr0 Link encap:Ethernet HWaddr xxxxxxxxxxxx
inet addr:192.168.11.102 Bcast:192.168.11.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2400 errors:0 dropped:518 overruns:0 frame:0
TX packets:499 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:442674 (432.2 KiB) TX bytes:77498 (75.6 KiB)

切り替え比較が簡単になりました。

syuさん

> どっちでも動くんでしょうが、私はvbr0とbr0の違いはよくわかってないまま設定しています。

あら。僕もよくわかってないままbr0です。vbrという記述のサイトがなかったもので(^^;;;。

> 192.168.11.7はbbbです。ここは影響していないと思います。

うーむ。そうでしたか。
こうなると、何故、syuさんのところはeth0/1で均等に負荷分散され、僕のところはeth0に集中するのか。謎は深まるばかりですね。カーネルの差ですかね。もう少し試してみます。

サーバ機がlan端子が3つあるapu1か一つしかないそれ以外の機種かでネットワークの振る舞いが変わるのですかね。直結方式の怪しい挙動に関してもう少し追加します。

nfsのオープンに関してですが、atomサーバ側を
/etc/exports
/mnt/sdb 192.168.0.*(rw,no_subtree_check,all_squash,sync)
とすれば、apu1クライアント側からマウント出来ます。
しかし、atomサーバを
/mnt/sdb 192.168.0.18(rw,no_subtree_check,all_squash,sync)
として、apu1クライアントからマウントすると
root@voyage:~# mount -a
mount.nfs: access denied by server while mounting 192.168.0.17:/mnt/sdb
というエラーになるのですよね。
ところがatomサーバを
/mnt/sdb 192.168.0.18(rw,no_subtree_check,all_squash,sync) 192.168.0.9(rw,no_subtree_check,all_squash,sync)
として、apu1クライアントからマウントすると、マウントできます。
以上の実験でapu1クライアントの/etc/fstabは全て
192.168.0.17:/mnt/sdb /mnt/sdb nfs rsize=8192,wsize=4096 0 0
となっています。

これは何を意味するかというと、「atomサーバのdhcp接続されている192.168.0.9を通って直結回線側の192.168.0.17:/mnt/sdbが認識されている」ということのように見えます。
僕とsyuさんで直結方式の評価が多少ずれるのもこのあたりに理由がありそうです。

yoさん

独立直結方式で長時間連続再生後もこんな値です。
root@voyage-mpd:~# cat /proc/interrupts

40: 9778 208587 PCI-MSI-edge eth0
41: 3383 124981 PCI-MSI-edge eth1

もう一度確認したいのは、直結側のアドレスです。
eth0とeth1はネットワーク識別部分の最後の８bitを別々にして切り離す必要があります。(Mask:255.255.255.0)
私の場合は、eth0=xx.xx.11.xx 、eth1=xx.xx.10.xxで、それぞれが別のネットワークとして識別されます。

[eth0/mpd]<-xx.xx.11.xx->[ethernet]
[eth1/mpd]<-xx.xx.10.xx->[eth1/server]

サーバ側もeth0はxx.xx.11.xxでethernetですが、eth1はxx.xx.10.xxとeth1/mpd専用です。
ethernetからはxx.xx.10.xxには接続できません。

root@voyage-mpd:~# ip a
1: lo:（略）

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether xx:xx:xx:xx:xx:a0 brd ff:ff:ff:ff:ff:ff
inet 192.168.11.101/24 brd 192.168.11.255 scope global eth0
valid_lft forever preferred_lft forever

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether xx:xx:xx:xx:xx:a1 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.101/24 brd 192.168.10.255 scope global eth1
valid_lft forever preferred_lft forever

4: eth2: （略）

この状態でvoyage-mpd側のeth1に接続されたケーブルを抜くと再生が止まります。
またeth0側を抜くとGMPCが接続できなくなります。

[eth0:192.168.11.102]<-->[ethernet](control)
| |
[server] +<-->[eth0/mpd:192.168.11.101](control)
|
[eth1:192.168.10.102]<----------->[eth1/mpd:192.168.10.101](music data専用)

yoさん

>「atomサーバのdhcp接続されている192.168.0.9を通って直結回線側の192.168.0.17:/mnt/sdbが認識されている」

ここですかね。直結回線側は例えば192.168.1.xなど、192.168.0.xで識別されるネットワークとは別のネットワーク識別部にしておく必要があります。

>mount.nfs: access denied by server while mounting

このエラーは私も経験しました。/etc/exportsの変更などを繰り返していると突発的に発生することがあるそうです。

syuさん

> ここですかね。直結回線側は例えば192.168.1.17:/mnt/sdbなど、192.168.0で識別されるネットワークとは別のネットワーク識別部にしておく必要があります。

大正解です。アドバイスありがとうございました。サーバ側を192.168.1.17、クライアント側を192.168.1.18にしてfstab、exportsも変更したら単純直結方式でeth1が使われるようになりました。音も大きく変わりましたので、これがsyuさんが絶賛されている音に近いと思います(bridge方式でeth0側を直結させた音に近いです)。

root@voyage:~# cat /proc/interrupts
CPU0 CPU1
0: 119 0 IO-APIC-edge timer
4: 1 8 IO-APIC-edge serial
8: 0 1 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
17: 2884 265141 IO-APIC-fasteoi ehci_hcd:usb1, ehci_hcd:usb2, ehci_hcd:usb3
18: 0 0 IO-APIC-fasteoi ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7
19: 27 3885 IO-APIC-fasteoi ahci
40: 64 3078 PCI-MSI-edge eth0
41: 960 132940 PCI-MSI-edge eth1
NMI: 0 0 Non-maskable interrupts
LOC: 67245 103086 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 0 0 Performance monitoring interrupts
IWI: 0 0 IRQ work interrupts
RTR: 0 0 APIC ICR read retries
RES: 350264 51892 Rescheduling interrupts
CAL: 8 11 Function call interrupts
TLB: 536 515 TLB shootdowns
ERR: 0
MIS: 0

ただ、僕の環境だと、こんどはeth1側に集中ということになるのはやっぱり不思議です。クライアント側のカーネルはsyuさんが公開された3.14.12-rt9です。

yoさん

私の方では、USB-LANアダプタをvoyage-nfs（server）に挿してeth3を作ってみたんですが、 cat /proc/interrupts にはeth3が現れません。

>こんどはeth1側に集中
なぜでしょうね。テストソースがハイレゾばっかりとかではないですか？
eth1のケーブルを抜去したら演奏が停止し、eth0を抜いたらGMPCがつながらない状態なら、それで良いんじゃないかと思いますよ。

さて、bridgeとindependent、どっちを好とするか、私は聴くたびに評価が変わったりしてるんですよね。

syuさん

> 私の方では、USB-LANアダプタをvoyage-nfs（server）に挿してeth3を作ってみたんですが、 cat /proc/interrupts にはeth3が現れません。

これは僕のatomサーバでも現れません。ただ、対応するusbの割り込み回数は確実に増加しますので、そういうものなのかなと思っています。
root@atom:~# cat /proc/interrupts
CPU0 CPU1
0: 126697 0 IO-APIC-edge timer
1: 3 0 IO-APIC-edge i8042
7: 18 0 IO-APIC-edge
9: 0 0 IO-APIC-fasteoi acpi
12: 4 0 IO-APIC-edge i8042
14: 0 0 IO-APIC-edge ata_piix
15: 0 0 IO-APIC-edge ata_piix
16: 49 0 IO-APIC-fasteoi uhci_hcd:usb5, i915
18: 0 0 IO-APIC-fasteoi uhci_hcd:usb4
19: 3224 0 IO-APIC-fasteoi ata_piix, uhci_hcd:usb3, i801_smbus
23: 776354 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb2
44: 3999 0 PCI-MSI-edge eth0
NMI: 0 0 Non-maskable interrupts
LOC: 81986 180829 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 0 0 Performance monitoring interrupts
IWI: 5901 6043 IRQ work interrupts
RTR: 0 0 APIC ICR read retries
RES: 59809 86102 Rescheduling interrupts
CAL: 188 188 Function call interrupts
TLB: 297 372 TLB shootdowns
ERR: 18
MIS: 0
割り込み番号の23番がapu1クライアントのeth1と単純直結しているusbアダプタ対応の割り込みです。

> なぜでしょうね。テストソースがハイレゾばっかりとかではないですか？

44.1HHz wavかflacだけです。

> eth1のケーブルを抜去したら演奏が停止し、eth0を抜いたらGMPCがつながらない状態なら、それで良いんじゃないかと思いますよ。

これはその通りになります(結構なバッファリングしているのか、停止まで数秒かかったのにはビックリ)。原因が分からないのはスッキリしませんね。

> さて、bridgeとindependent、どっちを好とするか、私は聴くたびに評価が変わったりしてるんですよね。

確かに微妙な差がありますね。bridgeの方がちょっとキツメですかね。僕は、ブラシーボもあるかと思いますが、今のところindependentです。

yoさん、皆様

No.4987の設定はbbbのi2s-botic-v1と比較するのが目的でした。この設定のままクライアントのvoyage-mpdにeth1とeth2を両方とも割り当てると、音楽専用回線もそれ以外の回線も、両方直結できます。

[server]--+[bridge]<-->[eth0]<-->[ethernet](control)(192.168.11.x)
| |
| +[bridge]<-->[eth1]<-->[eth0/mpd](control)(192.168.11.x)
|
|
+<-[independent]-->[eth2]<-->[eth1/mpd](music) (192.168.10.x)

これでまた音が変わります。高域がスッキリして、明瞭度が上がり、5kHz付近から上限まで素直にフラットに再現できている印象です。今まで聴こえていなかった高域の音がはっきり聴こえます。これが最も好みな音ですが、システムによってはキラキラ/ギラギラになってしまうかもしれません。

今までシリアルケーブルで音質が損なわれる印象はあまりなかったのですが、この設定では明らかに悪い影響が聴き取れます。シリアルケーブルを接続すると、ジッタが増えた時のようなイライラ感が高域に付加されてしまいます。

===設定===

[/etc/network/interfaces]

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 0.0.0.0

auto eth1
iface eth1 inet static
address 0.0.0.0

auto br0
iface br0 inet static
address 192.168.11.102
netmask 255.255.255.0
network 192.168.11.0
gateway 192.168.11.1
bridge_ports eth0 eth1
bridge_stp off

auto eth2
iface eth2 inet static
address 192.168.10.102
netmask 255.255.255.0
network 192.168.10.0
broadcast 192.168.10.255
=====

この設定ではindependent回線をeth2にしていますが、私の試した範囲で、eth0やeth1に割りつけても動作しませんでした。（設定はできるがpingが通らない）

root@voyage-nfs:~# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.00xxxxxxxxxx no eth0
eth1
root@voyage-nfs:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.11.1 0.0.0.0 UG 0 0 0 br0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
192.168.11.0 0.0.0.0 255.255.255.0 U 0 0 0 br0

===mpd側の状態===

root@voyage-mpd:~# cat /proc/interrupts

40: 21272 406074 PCI-MSI-edge eth0
41: 10864 244263 PCI-MSI-edge eth1

root@voyage-mpd:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.11.1 0.0.0.0 UG 0 0 0 eth0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.11.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

syuさん

> No.4987の設定はbbbのi2s-botic-v1と比較するのが目的でした。この設定のままクライアントのvoyage-mpdにeth1とeth2を両方とも割り当てると、音楽専用回線もそれ以外の回線も、両方直結できます。

サーバのeth0はbbbを外して、ハブにつないだということですね。

> 今までシリアルケーブルで音質が損なわれる印象はあまりなかったのですが、この設定では明らかに悪い影響が聴き取れます。

これはクライアントのapu1cにつないだシリアルケーブルという意味でしょうか。

いずれにしても面白そうですね。ethが三つないと出来ない世界なので、apuをもう一台オーダするしかなさそうだなぁ。

しかし、この接続でも、クライアント側(?)のeth0とeth1で負荷が分散されていますね。どういう魔法なのかしら。

yoさん

実はだいぶ前からこの接続は試していたのですが、明瞭な高域が出る割にいまいち刺激的で、これはダメだと判断していたのです。今日クライアント側のシリアルケーブルを外してみたら意外に好ましい音に変身して、これなら使えるとなったわけです。サーバにもシリアルケーブル接続をしていません。

ハイハットの音も自然ですが充実したエネルギーを感じます。Hilary Hahn の Bach Ciaccona など圧倒的な実在感だと思います。

>サーバのeth0はbbbを外して、ハブ
こちらでは、ハブ接続がeth0かeth1かの差は少ないです。

>eth0とeth1で負荷が分散

クライアントのeth0はGMPCなどですから、この類のソフトに何を使うかでもトラフィックは増減すると思います。あまりこだわらなくてもいいのかなと思っています。

yoさん　komaさん　皆様

ここしばらくLANの設定で「音が音で音だ」と書いていたわけですが、最終形に行き着いた感があります。
そこで、ssd(m-sata)に置いたデータ、bridge経由、independent経由、それぞれを比較しやすくする設定を試みました。

LANの接続や設定はNo.5002のままです。

私の場合 mpd の music_directory は /music ですので

# umount /music
# mkdir /music/br0
# mkdir /music/ind
# mkdir /music/ssd

# nano /etc/fstab

192.168.10.102:Public/Music /music/ind nfs rsize=24576,wsize=8192 0 0
192.168.11.102:Public/Music /music/br0 nfs rsize=24576,wsize=8192 0 0

bridge と independent 両方で mount してしまいます。
# mount -a

voyage-mpd の /music/ssd にもテストデータをコピーします。
# mkdir nfs
# mkdir mpd
sshfsでマウント。
# sshfs root@192.168.11.102:/ nfs
# sshfs root@192.168.11.101:/ mpd
パスワードを入力。nautilusをrootで起動。
# nautilus
適当にnfsにある音楽データをvoyage-mpd:/music/ssdにコピーし、終わったら、
# umount mpd
# umount nfs

gmpcを起動しupdate。Databaseを表示させると、br0、ind、ssdのフォルダが見えるはずです。
各曲をそれぞれ３種類の接続方法で順に登録してPlaylistを作成します。こうすると、３種類の接続を瞬時切り替えで比較できるわけです。

スピーカとヘッドフォン両方でやってみましたが、この条件では３種類の区別は私には不可能でした。全く同じに聴こえます。LANの接続が同じならbridgeとindependentの差は、私にとってですが、無いかあっても無視しうる程度。ssdでも差はわかりません。利便性を考えれば、bridgeで十分ということになりました。

差があると感じた音の差が本当に区別できているのか、好悪をそこそこ確かに判定できているのか、ブラインドで検定するスクリプトなど、あると便利かも知れませんね。

syuさん

聞き比べのための環境設定と正直な評価結果に頭が下がります。

syuさんは決して「音が音で音だ」に囚われていない方だと思います。

syuさんレポートありがとうございます。
私もこんな事して切り替えて聴いていました。(笑)

#!/bin/bash

dav1=`ls /var/lib/mpd/music/usbmount/usb0/`
server1=`/bin/ping -c 2 192.168.11.2 | grep errors`
server2=`/bin/ping -c 2 192.168.11.3 | grep errors`

if [ -n "$dav1" ]
then
echo ""
echo "SDカード存在する"
echo ""
/usr/bin/mpc ls usbmount/usb0 | /usr/bin/mpc add
/usr/bin/mpc update
/usr/bin/mpc volume 100
else
echo ""
echo "SDカード存在しない"
echo ""
if [ ! -n "$server1" ] && [ -n "$server2" ]
then
echo "---------------------------------------"
echo "server1:192.168.11.2"
echo "---------------------------------------"
mount -t nfs 192.168.11.2:/var/video/CD-MOTO2 /var/lib/mpd/music
/usr/bin/mpc update
/usr/bin/mpc volume 100
echo "---------------------------------------"
/bin/df
echo "---------------------------------------"
else
if [ -n "$server1" ] && [ ! -n "$server2" ]
then
echo "---------------------------------------"
echo "server2:192.168.11.3"
echo "---------------------------------------"
mount -t nfs 192.168.11.3:/var/video/CD-MOTO2 /var/lib/mpd/music
/usr/bin/mpc update
/usr/bin/mpc volume 100
echo "---------------------------------------"
/bin/df
echo "---------------------------------------"
fi
fi
fi

kojiです。

XMOSのDDCカードが安く手に入ったので、New Alixにつないでみました。
　接続して起動させたところ、一発で認識してくれました。（XMOSチップのカードなので当然かも分かりませんが…）

・aplay -l　の結果は、次の通りです。
**** ハードウェアデバイス PLAYBACK のリスト ****
カード 0: x20 [xCORE USB Audio 2.0], デバイス 0: USB Audio [USB Audio]
サブデバイス: 0/1
サブデバイス #0: subdevice #0


・cat /proc/asound/card0/stream0　の結果

XMOS xCORE USB Audio 2.0 at usb-0000:00:12.2-1, high speed : USB Audio

Playback:
Status: Running
Interface = 1
Altset = 1
Packet Size = 185
Momentary freq = 191994 Hz (0x17.ffd0)
Feedback Format = 16.16
Interface 1
Altset 1
Format: S24_3LE
Channels: 2
Endpoint: 1 OUT (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000
Data packet interval: 125 us
Interface 1
Altset 2
Format: S32_LE
Channels: 2
Endpoint: 1 OUT (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000
Data packet interval: 125 us
Interface 1
Altset 3
Format: SPECIAL
Channels: 2
Endpoint: 1 OUT (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000
Data packet interval: 125 us

Capture:
Status: Stop
Interface 2
Altset 1
Format: S32_LE
Channels: 2
Endpoint: 2 IN (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000
Data packet interval: 125 us
[root@arch ~]#



　Voyage MPD 0.92でも、Arch Linuxでも問題なく動いています。特に、以前の環境だと安定させるまでに苦労したハイレゾファイル（24bit/192khz）の再生も、全く問題なくできました。
　ほとんど確実に、エラーの出ていたVoyage MPD 0.92のデフォルトのMPD(0.18系）でも問題ありません。Arch Linuxも問題ありませんでした。

　一応、i2s出力端子も備えているらしいですが、現状は、同軸接続で、バスパワーという状態です。それでも、そんなに悪い音はしません。私が聴く音楽では、Arch Linuxの方が、弦がぶつかる音や、ブラシでドラムをこする音等で、生々しい音がします。
　動作確認のため、半ばテスト用に買ったのですが、予想に反して？効果がありました。

　セルフパワー化等、おいおい手を入れてやろうかと思います。

kojiさん
DDCの品名を教えてください。

komaさん、kojiです。

オークションで出ていたものです。
USB DAC用DSD対応XMOS DDC S/PDIF変換アダプター
という名前で検索をかければ、出てくるかと思います。

　ただ、私が購入した時より、500円程高くなっています。

　私の場合はテスト用での購入だったのであまり調べずに買いました。
　もっと、探せば、安くて良いものがあるのではないかと思います。

syuさん、ご報告ありがとうございます。興味深く読みました。

以前に書いたのですが、結局、直結状態でnasのデータがどれだけやりとりされるかではないのですかね。多ければ多いほど効果はあるということだと思います。その意味ではindependentが有利な筈ですが、リアルな処理では、それ程、差は出ないということだと思います。

ところで、もう一台apu1cを注文しちゃいました。昨日、香港を旅立ったようだから、来週には到着するでしょう。
syuさんと同じ構成で試してみたいということですが、もう一つの理由ははI2S接続のBBBとつないでみたいからです。一台でもbridgeなら出来るようですが、independentも試してみるために。
無線LAN付きです。どうせ二台にするなら、同じものでは面白くなかろうと思いまして。無線は音に悪いという話ですが、mini-PCI moduleだから、ちょっと違うのではなかろうかと思っています。神話が本当かどうか確認するつもりです。

BBBがusb-lan変換アダプタを認識しないという問題はクリアしました。こちらの話題ではないので、もう一つのスレッドに書き込みます。

yoさん

>もう一台apu1c
apu1 duoクラブへようこそ^^;

>無線は音に悪いという
>神話が本当かどうか確認

yoさんらしくて良いですね。usb-lanが使えるkernel作成、頑張ってみます。

Phoeniciaさん

コメントありがとうございます。

実は「音が音で音だ」は大好きなんですよね。「瞬時比較で何が判るものか」って意見に共感するところがあるんです。

「真剣に比較するならチョイ聴きなどしてはならない。少なくとも１楽章だけでも通して聴いて、できれば全楽章を聴いて、どちらが深く印象に刻まれたかで評価しなさい。」
てのが、知人の音楽評論家の意見で、このヒトは曲が終わるまで聴かないと意見を言うのを許してくれませんです。

でも、ホーンスコーカのボイスコイルが熱でバラけてノイズを出しているのに私が(曲が終って）指摘するまで気付かない、という致命的な欠点も有していた個体であるのは事実なのでした。

yo様
New alix(10)の記述の中に、

>CuboxやBeagleBoneBlack用のMPD搭載システムでLightMPDというシステムがありますが、このオリジナルはこれだと思います(オリジナルの意味はそのまま移植という意味ではなく、コンセプトが同じという意味です)。こちらはLightMPDと違い、僕の環境でも安定動作しますし、音もいいので、お勧めです。

とあります。7/26時点での記述ですので、読者はBBB等を使っての感想なのだと推測出来るのですが、8/8にnewALIX用のlightMPDが発表されました。うっかりすると、newALIX用のlightMPDの動作が安定していないように誤読される可能性があります。
newALIXでもlightMPDは動作が安定しないのでしょうか。検証された上での表現に改めていただきたいと思います。もし、事実と違うと言うことでしたら、lightMPDの作者に失礼にあたると思います。
また、聴かれた上で、tiny-core linuxの方が高音質であるということでしたら、我々にも比較可能な形で公開していただきたいと思います。できましたら、ディスクイメージで提供していただけるとありがたいです。


yseki118

yseki118さん

引用されたフレーズはさほど問題のある内容とは思えませんが、「デジファイのおと」を覗いて、ようやく何故yseki118さんがこだわられているのか理由が分かりました。確かに去年の終わり頃の感想をもとにしていますので、情報は古いですね。次回の更新時にその旨補足するつもりです。

なお、僕はTiny-Core LinuxとlightMPDの比較をするつもりはありません。lightMPDは巧妙なデザインの素晴らしいソフトだと思います。ちゃんと鳴ればですが(などと書くと、また顰蹙をかうかな^^;;;)。

yo様
レスありがとうございます。
私はANDBOX44でPCオーディオを始めました。その時には、「みみず工房」さんのイメージファイルのお世話になりました。
今回newALIXを使って、そのポテンシャルの高さに驚いている者の一人です。PCオーディオ愛好家の一人として、newALIXから、どこまで凄い音が出せるのか興味があります。
つきましては、私のようなLINUX初心者でもできるようなtiny-core linuxの導入の方法をご教授願えれば、幸いです。
ホームページへの掲載をお待ちしています。


yseki118

yseki118さん

イメージの公開って、結構、大変なのですよね。arm対応の音楽ソフトは一昨年の終わり頃はまったく無かったので、僕のイメージを公開しました。しかし、昨年の後半位からmubox、volumioなど海外製の良くできたディストリビューションが次々と登場したので、「老兵は猿のみ(凄い変換だなぁ、賢い^^;;;、もちろん「去る」です)」と思い、さっさと止めました。
lightMPDも確かそのころ登場したソフトですが、何しろ不安定でしたね。限界までチューニングするというコンセプトだから、仕方がないと思いますが、あれだけ手を広げると大変でしょうね。作者の頑張りに期待です。
あと、ちょっと気になるのは、ほとんど一人で開発されているようだということ。海外のソフトの場合は強力なサポータ陣がいるので、活発な開発が出来るということがあります。僕の場合もカーネルのチューニングはほんとどPhoeniciaさんにお任せでした。掲示板は結構活発になっているようだから、オネダリさんだけでなく、もっとサポートを強力に応援する勝手連が出てくるといいですね。もっとも、そのためには、もうすこしソフトの中味を「見える化」しないと駄目だと思いますが。このあたりが文字通りの「矛盾」、矛と楯ですよね。
以上、余計なお世話だと思いますが(^^;;;、「デジファイのおと」を覗いての感想でした。

lightMPDは以前は不安定だったんですね。
最初はどれもそうでしょうけど、今はとても安定してます。
自分でチューニングしたい人には不向きですが、非常に手軽かつ音が良く、サポートもよいので、すごく良いと思います。
作ってる人がよくわかってる人なのですよね。
中身を知りたい人向けじゃなくて、ブラックボックス化したい人向けなので、別の世界ですね。

くるるさん

> 中身を知りたい人向けじゃなくて、ブラックボックス化したい人向けなので、別の世界ですね。

おっしゃる通りだと思います。使った時の僕の感想は「これじゃ、何も出来ない。とっととオサラバしよう(^^;;;」でしたから。今回、apu1対応の版を使う気にならないのも同じ理由からです。

tiny-core linux の場合、GUIで使う分にはLinuxの世界はブラックボックス化されていますが、CUIだと一応中を覗けるし、弄ることも可能です。このあたりが、僕がtiny-coreとつき合ってみようと思った理由ですね。

安定しているということなので、lightMPDのapu1版を試してみました。
僕の環境はssdがディフォルトなので、sdカードリーダを接続し、ブートハードの指定が出来るようシリアルでつなぎながら接続しました。ビックリしたのは、そのままシリアルでログインまで辿り着いたこと。rootで入れて、中味も覗けました。これは以前は出来なかったと思いますので、改良されたということですかね。
ブートに使ったsdカードを終了時に切り離してread-only化しているので、中を弄ることは出来ませんが、どんな仕組みか見えるようになったのはありがたいです。また、切り離されたsdカードは再度mount出来ますので、中にある設定ファイルを直接書き換えることが出来ます。これはいちいちwindowsにつなぎ直さなくてよいので、とても便利。おかげで簡単に設定が出来て、音を出すことができました。
動作状況も皆様ご指摘のように安定しています(フェーズテックHD-7 192改と接続)。これなら操作性も良いし、十分使えそうですね。

ところで、中味が見える化されると、busyboxベース、rootfsを全面的にinitrd化、read-only化の手法など、tiny-core linuxとの共通点が目につきますね。まあ、このあたりは組み込みシステムの常識的デザイン手法だろうから、たまたま同じような感じになったということですかね。
音に関する感想は、また物議を醸すといけないので(^^;;;、差し控えます。

新しいBIOSを入れてみたらブートデバイスの切り替えボタンがF12からF10へ変更になっていました。これはwindowsが母艦の人は問題はないと思いますがLinuxを母艦にしてgtktermを使ってシリアル接続している方には致命的です。なぜならgtktermでF10はメニュー表示に割り当てられているためです。

komaさん、こんにちはkojiです。

Linuxを母艦に使っておられるようでしたら、screenはいかがでしょうか？
　最初、minicomを使ってみたのですが、UTF-8に対応していない？みたいで、APU01側のlocalesをja_JP.UTF8に設定したところ、盛大に文字化けしてしまいました。それで、screenを入れて試してみたところ、文字化けもなく、あっさりとつながりました。

使っておられるDistributionが分かりませんが、おそらく、screenは大体用意されているかと思います。
　インストールをして、
screen /dev/ttyUSB0　115200
等で簡単に入れます。（/dev/tty以下は環境次第ですが）

　使い始めの当初戸惑ったのは、screenからの抜け方でした。
ctrl+Dとかではなく、ctrl+Aの後、kで、yes選択でした。

　既にご存じかも分かりませんが、参考まで

kojiさん、ありがとうございます。
screen 試してみました。表示は問題ないです。
ただ、viでのテキスト編集が上手くいかなくなりました？
うーん何か設定があるかもなので弄ってみます。

皆様

screenだと、日本語表示が出来るのですか。僕はminicomを使っているのですが、「まあ、シリアル表示だら、こんなものか」と諦めていました。kojiさん、情報ありがとうございました。

ところで、この件(ファンクションキーの変更)は
http://mimizukobo.sakura.ne.jp/cgi-bin/read.cgi?mode=all&list=topic&no=4938" target="_blank">http://mimizukobo.sakura.ne.jp/cgi-bin/read.cgi?mode=all&list=topic&no=4938
に対応するための処置でしょうね。多分、多数のmacユーザからのクレームが殺到。対応したら、こんどはlinux gtktermにひっかかっちゃった、ということでしょう。PC Engine社の技術スタッフも大変ですね。同情します。
スレッドではcorebootの仕様が問題と書いたけど、間違っていましたね。むしろ、シリアル接続するプログラムの仕様の問題で、プログラム側の機能をファンクションキーとかctrl+nなどの簡単な操作で呼び出す作りにしてはいけないということでしょう。実際、終了操作やメニュー表示などで、screenはkojiさんの書かれた通り。minicomも ctrl+A -> z でメニューが表示され、そこからqを押してyesを選ぶと終了できるようになっています。
WindowsではどうかなとPuttyを調べたらalt+f4で終了でした。これは、altキーってwindows専用という感じがあるから、OKなのでしょうね。

家の環境だと日本語表示出来ませんでした。minicom．．．

ACアダプターをスイッチング電源からアナログACアダプターに変更しました。
驚くほど音が向上しました。ベールが2枚～3枚剥ぎ取られたようです。解像度が上がり細かい音が聞こえてきます。ダイナミックレンジが広がり、音楽が楽しめます。
電源にお金をかけるとさらに素晴らしい音が出ます。

New Alixの電源ですが、今度は単一電池を８本直列につなぎ１２VにしてNew Alixにつなぎました。
結論から言うと、素晴らしい音でした。この音を聞くと後戻りできません。今のところ電池駆動が最高の音を奏でています。
友人所有のB&W800Diamondで聴きました。ビル・エバンスのワルツフォデヴィが前で演奏しているようでした。
作成は、協立電子から単一電池の電池ボックスとDCプラグを購入して接続するだけです。
一度試して見られたらよいかと思います。

New Alixの電源ですが、今度は太陽光発電で駆動してみました。
２０W程度出力する太陽光パネル、１２VUPS電源、１２Vでのシステムコントローラー（日本製）を購入し、１２V直流が確実に出力されていることを確認して、New Alixに接続しました。
電池駆動に比べて駆動力が増し、しかも繊細感が出ています。
素晴らしい音です。まだ、いろいろと調整が要りますが、最高の音を奏でています。電池に比べてまだ不確定要素があるのでしばらく様子を見ながら聴いていきます。皆様、太陽光発電での駆動は電池に比べて問題もはらんでいるかもしれません。
どうか、自己責任でチャレンジされる方はされたら良いと思います。