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)が表示されています。

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さん
>新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さん 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でクロスコンパイルしたファイルのやりとりなどで重宝しています。

やれることは、やっておこうということで。
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さん

新版公開深謝。

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の音質判定が困難に。しばし聴き比べてみます。

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

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でかなり満足ですが、次にも期待しています。

syu さん

ご無沙汰しております。
>前回、dsd128が問題なく再生できると書きましたが、実は再生できたのは新しいuda2の方で、uda3ではありませんでした。uda3でのdsd128は31200rt2-131118でも、ノイズだけになります。
ここ、教えてください。
「新しいuda2」＝「⑥USB DUAL AUDIO基板 Version2 (通称UDA2再生専用基板)」
「uda3」＝「④USB DUAL AUDIO基板 (通称UDA(DoP版)」
という理解で良いですか？
syuさん環境 0731rt でDSD再生問題ない、というのはもしかして「新しいuda2」のみ、だったりしますか？

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は聴き込むほどに良いですよ。
何度も連発すると信頼度を損ねますが、過去最高です。

rootfsをdebian(bone20)とarch最新版で差し替えて、31200rt2/mpd0176dsd-rtoptでの比較をしてみました。

どちらも良いですが、より精緻に感じるのはarchですね。高域の歪みがやや少なくなる印象です。あくまで私の環境での比較です。いよいよ返却するait-dacを使用しました。古いdCSは、やはり古かった(^^;;

combo384なんてのも話題のようですが、どなたかお試しの方、使用感をお聞かせ下さい。

> 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

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が良いような気もします。

twlさん
>BBBの環境でのrtカーネルによるnoiseless再生が本当に可能な状況なのかどうか
3.8-rtの時もnoneRTならDSDの再生も大丈夫と、yoさんも言われていましたね。
lightMPD（No.3634記）とういものが、DSDの再生も可能らしいですよ。

syuさん
いろいろ情報ありがとうございます。UDA基板の違いではないのですね。
syuさんは何れも S/PDIF を使われているようで、私の環境（uda3=>dac I2S入力）との違いが気になります。
ait-dac 良いですよね、試聴記を楽しみにしています。
USB や内部配線やらで色々実験出来る（好みの音を作れる）のも楽しいところです。

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種類になります。

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がダメなのは、全く意外ですね。

twlさん

いろんな情報ありがとうございます。combo384を主にご使用なんですね。私の環境ではuda3(DoP版)とuda2(再生専用版)でdsd再生に大きな差が出ますので、combo384はまた違った反応を示す可能性もありそうです。数週以内にはcombo384もテストできそうです。

twlです。

> 私の環境ではuda3(DoP版)とuda2(再生専用版)でdsd再生に大きな差が出ますので、

私も今はディスコンになった初期のDoP対応UDA基板を使用しています。といっても再生が目的ではなくADC経由でのDSD録音が目的なのですが。

それでもたまにはエレアトさん自作のWindows用ソフトでDSDファイルを再生、USB接続のUDA基板上のI2S/DSD経由でBuffalo DACに流して聞いたりしています。使い勝手は最悪なソフトですが、さすがに本家、基板経由の再生音は素晴らしいです。

> 数週以内にはcombo384もテストできそうです。

最近ではES9018のDACにCombo384とアイソレーターを組み込んだものを紹介しているガレージメーカーさんもあるので、このような環境だとBBBのRTカーネルの意義も変わるかもしれませんね。いずれにしても今後のsyuさんのご報告を楽しみにしております。

syuさん
詳細なご説明ありがとうございます。
DSD再生stopの状況（BBBは送ったけれど、DACには届いていない）からすると
どうも、両者の間にある DDC 周りが怪しいと思っています。
（CuBoxはOKなので、BBBの動作マージン？も足りないのでしょうか）
ait-dac お買い上げでほぼ環境も揃うということでご報告を楽しみにしております。

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さん

ご指摘のノイズは、これと同様でしょうか、それとも別の発生状態でしょうか。波高のあるノイズか、瞬断か、どちらに近いでしょう。

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

syuさん、twlさん
検証ありがとうございます。
どこかに解決のヒントがあるのかなと思いましたが、なかなか上手くいかないですね。

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

twlさんの場合、私の環境でのノイズとは違うノイズらしいのが、BBBの不思議ですね。

私の環境ではFPとFDは良い音が出ますが、BDとBPはダメなのも不思議。twlさんの場合、BDとBPよりもFD、FPの結果が悪いけど、こちらの方が合理的だと思うんですよね。

皆様

ご覧の皆さんで、うちではFDかFPで音が出てるよって方は居られるんでしょうか。詳細なコメントいただけると有難いですが、「音が出てます」ってだけで、詳細コメントなしでも良いですから、ご報告いただけると嬉しいです。もしかして、FPとFDでまともに音が出てるのは、tinkerさんと私の環境だけなんでしょうか。

tinkerさん

私の環境では、31200rt2シリーズ（FDとFP)は抜群に良い音ですので、普遍性を獲得すべく、何とかしましょう(他力本願)(^^;;;

私の環境でも夜間は昼間より改善するなど、環境・電源ノイズが影響している印象もあるので、電源まわりのノイズフィルターを全部外し、近くの工場が操業している時間帯に試してみようかと思っています。いつになるかは保証外ですが・・。

皆様

僕の環境(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は関係なさそうですね。

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上で作っているのでいつ終了するか、予測できません。(^^;

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

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さんのカーネルがどうなるかですね。他の皆様は、どうでしょう。

どうにも解せないので、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にすると発生しなくなるということですが、原因がよく分からないですね、。

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

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

皆様
検証ありがとうございます。
鳴らすための条件は、とても厳しそうですね。
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さん、お疲れ様です。

> >BBB上で作っているのでいつ終了するか、予測できません
> チャレンジャーですね～。時間はどの位でした？

チャレンジャーといえば聞こえはいいですが、単なる馬鹿ですね。(^^;

夜7時ぐらいにrtのパッチを当てたビルド作業をBBB上で開始、私は12時過ぎには就寝、unameで見ると翌日の午前３時ぐらいにはカーネルは出来上がっていたようです。朝の６時前後に起床してビルドを確認後、make modulesを開始。それを放置したまま仕事にでかけ、夜帰宅するとエラーなくmoduleが出来ているのでほっとする、といったようなペースです。昨夜はCuBox用の3.12rtカーネル、BBB用のrtカーネルおよびnon-RTカーネルのビルドを同時進行させていたので、クロスコンパイル用のMacを含め、都合３台のPCが私が寝ている間仕事していたようです。(^^;

皆様、本日休日の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

twlさん
結構時間かかるんですね。

UPされているイメージを試してみました。
yoさんが書かれている再生中断は、CMAを確保していない事が関係しているかもしれないですね。
私がUPしたものは、何も考えずに128M確保しています。
yoさんのところでは30分くらいで再生中断とのことなので、128Mでも足りないのかもしれませんが。

yoさん
再生中断は、FDとFPの両方で発生しますか？

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で試してみるという手はありますかね。

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さんとの大きな差です。不思議です。

yoさん

> かなりのモジュールを組み込んでいますよね(ビルドで時間がかかる大きい理由も
> そのためだと思います)。このあたりに環境差による問題を引き起こす要因が潜ん
> でいるという気がするのですが。

おっしゃる通り、defaultのままでmake moduleしています。これはまずkernelのbuild自体をとにかくエラーなく終了させることを目的にしたためです。それでもrt4のバージョンではすこしは不要なmoduleを削ったのですが。でも再生音の質に関わる可能性が大きいですよね。もう少し煮詰めてみます。

tinkerさん

> yoさんが書かれている再生中断は、CMAを確保していない事が関係しているかもしれないですね。

アドバイスありがとうございます。次回のビルド時の参考にさせていただきます。

syuさん

> 今のところcombo384は最適ではなさそうですが、ハードルが高いけど良さそうと言う点で、combo384で粘って
> みるのは推奨です。

ハードルは高くないと思いますが、combo384のファームウェアは最新の状態(確か1.68だったと思いますが)ですよね。以前yoさんの雛祭りバージョンをお試し中にファームウェアを更新したら、再生音が激変した記憶がありますので、ご参考まで。

ということで皆様のアドバイスのもとに3.12rt4のカーネルビルドを再検討してみます。ありがとうございました。

twl

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を選り好みする傾向があるかも。

syuさん

> 私の環境でbdとbpが依然として上手くないのがyoさんとの大きな差です。不思議です。

これは見落としていました。
僕の環境でfd/fpとbd/bpの差はあまりないです。音もfdがベストと思いますが、僅差ですね。再生中断の発生の仕方も同じような感じです。
uda2/3位しか差はないのだけど、ネットワークとかnasが関連しているのですかね。ただ、archについてはcifsだから同じですね。

twlさん

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

> Evoご使用の方々には朗報かもしれませんが、この結果から考察すると、カーネル自体の抱えるUSB関連の問題とは別に、どうも使用するUSB DDCの違いによるプロセス負荷の大小が再生ノイズの発生に大きく影響しているようです。

usbドライバ(ddc)の違いによりrtカーネルの問題点が引き起こされると考えた方が良いと思います。同じrtカーネルで、標準のドライバであれば負荷が高くなり、Evo対応のドライバだと通常の負荷に戻るということは、ドライバによってrtカーネルの振る舞い方が変わるということではないでしょうか。Preemptだと問題は発生しないのも同じことだと思います。
3.6%というのはrtカーネル3.8.11以前とだいたい同じですから、この状態なら問題は発生しないようですね。

という次第で正常に聞こえていても、irq/35-musb-hdrが20%以上というのは気持ちが悪いのですよね。

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

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系列では未確認ですが)。

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

このスレッドは長くなったので新しくします。タイトルは「BeagleBone Black(9)」です。