MPDでCuesheetを使う為の設定は？
Linuxは全くの素人なのに、ここの掲示板を見てCuBoxを注文しました。数日のうちには届くと思うのですが、その前にいくつか教えていただきたいのです。
１、MuboxのMPDでCuesheetを使うためにConfigをどう設定したらよいですか？
２、Cuesheetと音楽ファイルは別のフォルダーに置いても良いのですか？
３、私はクラシックからジャズ、POPｓまで色んなジャンルを聴くので今まで（Windows環境）ではCuesheetをジャンルごとのフォルダーに分けていました。MPDでもフォルダーを分けることが出来ますか？
Re: MPDでCuesheetを使う為の設定は？
yo 
2013/09/15(Sun) 17:38 
No.3530
maple4062さん
CueシートもMuboxも使っていないので、適切なアドバイスは出来ないのですが・・・
> １、MuboxのMPDでCuesheetを使うためにConfigをどう設定したらよいですか？
このConfigというのは、/etc/mpd.confのことですか。キューシートのConfigという意味が分からないもので。
mpdは0.17以降であれば
Cue Files
No additional steps are needed for cue support in mpd since 0.17. MPD has its own integrated parser which works with both external and embedded cuesheets. For example, the command mpc load albumx/x.cue loads the file music_directory/albumx/x.cue as playlist; or in the case of an CUESHEET tag, mpc load albumx/x.flac
とありますので、特別な設定は不要なのではないでしょうか。
https://wiki.archlinux.org/index.php/Music_Player_Daemon/Tips_and_Tricks#Cue_Files" target="_blank">https://wiki.archlinux.org/index.php/Music_Player_Daemon/Tips_and_Tricks#Cue_Files
の情報です。
CueシートもMuboxも使っていないので、適切なアドバイスは出来ないのですが・・・
> １、MuboxのMPDでCuesheetを使うためにConfigをどう設定したらよいですか？
このConfigというのは、/etc/mpd.confのことですか。キューシートのConfigという意味が分からないもので。
mpdは0.17以降であれば
Cue Files
No additional steps are needed for cue support in mpd since 0.17. MPD has its own integrated parser which works with both external and embedded cuesheets. For example, the command mpc load albumx/x.cue loads the file music_directory/albumx/x.cue as playlist; or in the case of an CUESHEET tag, mpc load albumx/x.flac
とありますので、特別な設定は不要なのではないでしょうか。
https://wiki.archlinux.org/index.php/Music_Player_Daemon/Tips_and_Tricks#Cue_Files" target="_blank">https://wiki.archlinux.org/index.php/Music_Player_Daemon/Tips_and_Tricks#Cue_Files
の情報です。
yo 2013/09/15(Sun) 17:38 No.3530
Re: MPDでCuesheetを使う為の設定は？
yoさん ありがとうございます。
CuBoxが届き、早速MuBoxをインストール（Devバージョンです）しました。
Nasはちゃんと認識しFlacもWaveデータも再生できました。
なかなか力強いというか、音楽の雰囲気をしっかり表現する魅力的な音で満足です。
ところで、Cue sheetですが どのクライアントも（主にMPODを使っています）Cue sheetを認識してくれません。
どうしたら良いのでしょう？？？
CuBoxが届き、早速MuBoxをインストール（Devバージョンです）しました。
Nasはちゃんと認識しFlacもWaveデータも再生できました。
なかなか力強いというか、音楽の雰囲気をしっかり表現する魅力的な音で満足です。
ところで、Cue sheetですが どのクライアントも（主にMPODを使っています）Cue sheetを認識してくれません。
どうしたら良いのでしょう？？？
Re: MPDでCuesheetを使う為の設定は？
yo 2013/09/18(Wed) 21:10 No.3543
maple4062さん
MuBox、無事インストール出来たようでよかったですね。
> どうしたら良いのでしょう？？？
分かりません。
直前のメッセージ(リンク先)の内容は試されたのでしょうか。
mpc load albumx/x.cue
は music_directory/albumx/x.cue をプレイリストとして呼び出す、あるいはCUESHEET tagの場合は
mpc load albumx/x.flac
で呼び出されるとありますが・・・。
この掲示板の情報も役に立つと思います。
http://www.symphonic-net.com/kubotayo/cgi-bin/read.cgi?mode=all&list=topic&no=1948" target="_blank">http://www.symphonic-net.com/kubotayo/cgi-bin/read.cgi?mode=all&list=topic&no=1948
MuBox、無事インストール出来たようでよかったですね。
> どうしたら良いのでしょう？？？
分かりません。
直前のメッセージ(リンク先)の内容は試されたのでしょうか。
mpc load albumx/x.cue
は music_directory/albumx/x.cue をプレイリストとして呼び出す、あるいはCUESHEET tagの場合は
mpc load albumx/x.flac
で呼び出されるとありますが・・・。
この掲示板の情報も役に立つと思います。
http://www.symphonic-net.com/kubotayo/cgi-bin/read.cgi?mode=all&list=topic&no=1948" target="_blank">http://www.symphonic-net.com/kubotayo/cgi-bin/read.cgi?mode=all&list=topic&no=1948
yo 2013/09/18(Wed) 21:10 No.3543
Re: MPDでCuesheetを使う為の設定は？
maple4062 2013/09/19(Thu) 15:48 No.3546
yoさん
ご指摘いただいたコマンド（mpc load albumx/x.cue）も試しましたが no such playlistといわれロードできません。
私ももう少し調べてみますが、詳しい方が居られたら是非ご教授ください。
ご指摘いただいたコマンド（mpc load albumx/x.cue）も試しましたが no such playlistといわれロードできません。
私ももう少し調べてみますが、詳しい方が居られたら是非ご教授ください。
maple4062 2013/09/19(Thu) 15:48 No.3546
久しぶりのx86
メインで使っているPCがあまりにも大食い（は良いとしても）で煩いので、Web閲覧，エクセル（とワード）だけでも使えりゃいいやって、程々のPCを作りました。
Winを入れる前にDebian（64bit版）を入れて遊んでます。
なるだけ安く、静かなことって条件で、XH61Vというベアボーンに、Celeron G1610（4000円くらい）をつけてみました。
ちょっと聞いた感じですが、なかなかいいですね。
901x（Atom N270のネットブック）やwandboardより良さそうです。最近のCPUは音がいいんでしょうか？core iシリーズだったらもっと良いのかもしれませんが、高いので・・・
・ほぼ無音
・CPU温度：mpd使用時で37度くらい
・音は高解像度系
久しぶりにx86のdebianで、kernelの作り方を完璧に忘れていてちょっと困りました^^;
今度の連休中には、当初の目的通りWin機になる予定です。
Re: 久しぶりのx86
yo 2013/09/16(Mon) 22:02 No.3535
tinkerさん
> 今度の連休中には、当初の目的通りWin機になる予定です。
あれれれれ。Windowsなんて軟弱なものをお使いになるのですか ?
僕のメイン機は当然Win7で(^^;;;。AMD-450なのですが、これもかなり静かです。
> 今度の連休中には、当初の目的通りWin機になる予定です。
あれれれれ。Windowsなんて軟弱なものをお使いになるのですか ?
僕のメイン機は当然Win7で(^^;;;。AMD-450なのですが、これもかなり静かです。
yo 2013/09/16(Mon) 22:02 No.3535
Re: 久しぶりのx86
Punky 2013/09/16(Mon) 22:43 No.3536
A successor of ALIX board is coming by the end of this year... Please stay tuned.
~Punky
~Punky
Punky 2013/09/16(Mon) 22:43 No.3536
Re: 久しぶりのx86
tinker 2013/09/16(Mon) 22:47 No.3537
>あれれれれ。Windowsなんて軟弱なものを
内緒ですが・・・エクセルとDocuworksが大好きなんです(笑)
内緒ですが・・・エクセルとDocuworksが大好きなんです(笑)
tinker 2013/09/16(Mon) 22:47 No.3537
Re: 久しぶりのx86
yo 2013/09/17(Tue) 20:58 No.3540
Hi Punky,
> A successor of ALIX board is coming by the end of this year.
Thank you for your information. Very interesting.
> A successor of ALIX board is coming by the end of this year.
Thank you for your information. Very interesting.
yo 2013/09/17(Tue) 20:58 No.3540
ノートでのCuBox Installer
cuboxを購入しました。voyage mubox をインストールしようとしましたが、私のパソコン（Acerのノートブック）ではPUTTYをオープンしようとすると、シリアルポートが開放されないというエラーが出て進みません。
Sonyのノートも試しましたが同様です。HDMIケーブルでも同じエラーが出ます。
ノートでシリアル接続ができた方が居られたら、対策をご教授願いたく。
Re: ノートでのCuBox Installer
yoyo 2013/09/15(Sun) 13:51 No.3529
ドライバーをインストールする必要があったのですね。
ネット検索して漸くわかりました。
ネット検索して漸くわかりました。
yoyo 2013/09/15(Sun) 13:51 No.3529
梅雨入りバージョン Question
こんばんは、wowbvbv＠Taiwanと申します。
When i use 「cubox-audio-130608.img」 in my cubox, It can't boot.
The red LED just blinks, no screen, no IP on my lan.
But 「cubox-audio-130303.img」 works fine.
Here is my question,
How can i set rootfs default debian on 「cubox-audio-130608.img」before dd to SD card ??
Re: 梅雨入りバージョン Question
yo 2013/09/11(Wed) 20:54 No.3525
wowbvbvさん
The default 130608 kernel(Arch Linux) cannot boot sometimes. Please try it again and if it doesn't work please change SD card.
The default 130608 kernel(Arch Linux) cannot boot sometimes. Please try it again and if it doesn't work please change SD card.
yo 2013/09/11(Wed) 20:54 No.3525
Re: 梅雨入りバージョン Question
yoさん
Really thanks!! It worked~~trying boot several times~
Now i can enjoy the fantastic sound from your image.
Thanks again!!
Oops...It seems my dhcp router can't give an ip to Cubox.
I edit the file /etc/network.d/ethernet-eth0 as static ip,
and it works.
Under observation.
Really thanks!! It worked~~trying boot several times~
Now i can enjoy the fantastic sound from your image.
Thanks again!!
Oops...It seems my dhcp router can't give an ip to Cubox.
I edit the file /etc/network.d/ethernet-eth0 as static ip,
and it works.
Under observation.
CuBox の購入について
CuBoxをお蔭様で楽しませて頂いています。 いつもありがとうございます。
今度もう1台購入しようかと思い、SolidRun を眺めていると、CuBox-i というシリーズが予約受付になっているようで4種類のバリエーションが出ているようです。
どれを購入したら良いのか、このシリーズで問題なく今までのように使えるのかアドバイス頂けますでしょうか？
よろしくお願いします。
Re: CuBox の購入について
Phoenicia 2013/09/05(Thu) 19:46 No.3516
面白そうですね。
但し、多分誰もMPD用に使ったことはないでしょうから、問題があるか無いかはわからないと思いますよ。
但し、多分誰もMPD用に使ったことはないでしょうから、問題があるか無いかはわからないと思いますよ。
Phoenicia 2013/09/05(Thu) 19:46 No.3516
Re: CuBox の購入について
tinker 2013/09/05(Thu) 20:42 No.3519
yanamさん
新しいCuboxはi.MX6なんですね。
Phoeniciaさんがおっしゃるように、試してみないと分からないですね。
以下想像など、
１．yoさんのCubox用イメージはSoCが違うので動きません。
２．mpdを動かすだけなら、どれでも動くと思います。
３．yoさんのCubox用イメージのようにRTのKernelで動くものを期待されているなら、少し時間がかかるかもしれません。
・運が良ければ1～2ヶ月。普通に考えると半年以上。
４．ただし、すべてのシリーズでRT Kernelが動くとは限りません。同じi.MX6を使っているwandboardでは以下のとおりです。
・Soloは現時点でRT Kernelは動きません。
・DLite（Cubox-iのi2とUltraの中間みたいな仕様）はkernel.orgの公式ソースで3.10.xでRT Kernelが動きます。
・Quadはpatchを当てることで3.10.xでRT Kernelが動きます
以上から考えると、RT Kernelにこだわるのであれば、Ultra以上が期待できるのかもしれないです。
また、ファイルサーバーを作りたいとかであれば、eSATAが付いているものがいいと思います。
新しいCuboxはi.MX6なんですね。
Phoeniciaさんがおっしゃるように、試してみないと分からないですね。
以下想像など、
１．yoさんのCubox用イメージはSoCが違うので動きません。
２．mpdを動かすだけなら、どれでも動くと思います。
３．yoさんのCubox用イメージのようにRTのKernelで動くものを期待されているなら、少し時間がかかるかもしれません。
・運が良ければ1～2ヶ月。普通に考えると半年以上。
４．ただし、すべてのシリーズでRT Kernelが動くとは限りません。同じi.MX6を使っているwandboardでは以下のとおりです。
・Soloは現時点でRT Kernelは動きません。
・DLite（Cubox-iのi2とUltraの中間みたいな仕様）はkernel.orgの公式ソースで3.10.xでRT Kernelが動きます。
・Quadはpatchを当てることで3.10.xでRT Kernelが動きます
以上から考えると、RT Kernelにこだわるのであれば、Ultra以上が期待できるのかもしれないです。
また、ファイルサーバーを作りたいとかであれば、eSATAが付いているものがいいと思います。
tinker 2013/09/05(Thu) 20:42 No.3519
Re: CuBox の購入について
yanam 2013/09/05(Thu) 21:54 No.3520
Phoeniciaさん、tinkerさん
ありがとうございます。
新しいCuBox-iは似ているようで違うのですね。
残念ながら私の技量では購入しても動かす事は出来そうにはありません。
でもこの価格設定は魅力ですね。
とりあえず現時点では今までの物を購入ですね。
本当にありがとうございました。
ありがとうございます。
新しいCuBox-iは似ているようで違うのですね。
残念ながら私の技量では購入しても動かす事は出来そうにはありません。
でもこの価格設定は魅力ですね。
とりあえず現時点では今までの物を購入ですね。
本当にありがとうございました。
yanam 2013/09/05(Thu) 21:54 No.3520
Re: CuBox の購入について
yo 2013/09/06(Fri) 19:18 No.3522
皆様
cuboxの新型はi.MX6なのですか。これとODROID-U2(Exynos4412)でどちらがいいか悩みますね。性能はExynos4412が上のようですが、仕様はほぼ互角。価格はODROIDの方が安いみたいですが、いい勝負。i.MX6とExynos4412でどっちが音がいいのでしょうか。
しかし、イスラエルと韓国の対決とは、凄い時代になってますね。
cuboxの新型はi.MX6なのですか。これとODROID-U2(Exynos4412)でどちらがいいか悩みますね。性能はExynos4412が上のようですが、仕様はほぼ互角。価格はODROIDの方が安いみたいですが、いい勝負。i.MX6とExynos4412でどっちが音がいいのでしょうか。
しかし、イスラエルと韓国の対決とは、凄い時代になってますね。
yo 2013/09/06(Fri) 19:18 No.3522
BeagleBone Black(5)
tinkerさん
アドバイスありがとうございました。早速試してみました。残念ながら失敗でしたが、興味深い発見もありました。
オプションを指定して再生すると、暫く(10秒から1分くらい)dsd再生し、その後、クライアント側(ncmpc)では再生は継続しているように見え続けますが(時間が更新され、1曲の再生が終わると次の曲に表示は切り替わる)、実際の再生は中断してしまいます(aitlaboのパネル表示も再生停止時にdsdからi2sに変わります)。
オプション無しだと、aitlaboのパネル表示が曲の頭で瞬間的にdsd再生表示になりますが、実際には音は出ず、パネル表示もi2sに変わります(クライアント側の表示は有りの場合と同じで、正常に見えます)。
top画面での状況表示は irq/35-musb-hdr、irq/57-4a100000、mpd共に再生停止後も動いているように見えます(オプション有り無し共に TIME+ が増加し続ける)。
以上は全てrtカーネルの時の話で、preemptでは問題なく再生できます。またcifsの場合は、rtカーネルでオプション無しでも再生できます(ただし時々再生の中断は発生します)。
以上からの考察。
- オプション有りにするとdsd再生されるようになるので、原因はnfsの負荷に関連している ?
- 有りにしても10秒から1分位で再生が停止する理由が問題
- 考えられる可能性は高負荷時のエラー処理の不具合がrtカーネルにあること
- このエラーは他のプロセス、ドライバには見えていないようである(top画面やクライアント側の表示は正常のまま)
- オプション無しにすると、曲頭から上記の状態になるのはnfs負荷が高いためか ?
- preenmptカーネルにはこの問題がない ?
- rtカーネルとcifsの組み合わせでは、この問題が発生しにくいメカニズムがあるのだろう(再生の中断はたまに起きるので)
- wavでほとんど発生しない理由もnfs負荷の問題だと思われる
というところですかね。
えふさんやsyuさんのところで、再生の中断にならず、音切れ(またはノイズ)になる理由がよく分かりませんね。ネットワークの差ですかね。
Re: BeagleBone Black(5)
えふ 2013/08/02(Fri) 20:15 No.3355
yoさん
イメージについてですが、何かよう分からん状態になっています。
0xFFを埋め込んだデータを圧縮したイメージを作成したら、何故かデータサイズが7.4MBなどという値を表示しています。それでもこれを解凍すると、しっかりと7.4GBくらいのサイズとなります。
このような状況と、yoさんの環境での解析も進んでいることからも、当方のイメージを公開するのは意味ないような気がしています。
イメージについてですが、何かよう分からん状態になっています。
0xFFを埋め込んだデータを圧縮したイメージを作成したら、何故かデータサイズが7.4MBなどという値を表示しています。それでもこれを解凍すると、しっかりと7.4GBくらいのサイズとなります。
このような状況と、yoさんの環境での解析も進んでいることからも、当方のイメージを公開するのは意味ないような気がしています。
えふ 2013/08/02(Fri) 20:15 No.3355
Re: BeagleBone Black(5)
yo 2013/08/02(Fri) 21:05 No.3356
テスト確認用にBBB用のdebianhf-rootfsのイメージを公開します。安定版ではありません。debianhfはbone-20なので、貴重かもしれません。
http://www.symphonic-net.com/kubotayo/cgi-bin/downlogs.cgi?id=0B1V9ShHUc5NqbVI5cm9rQ29Ld2c" target="_blank">http://www.symphonic-net.com/kubotayo/cgi-bin/downlogs.cgi?id=0B1V9ShHUc5NqbVI5cm9rQ29Ld2c
7zip圧縮してあります。
boot部分はtinkerさんの0722/0728configを使い github.com/beagleboard 3.8-rtカーネルソースからビルドしたzImage(と*.dtb)に入れ換えています(/buid_filesに置いてあります、peはbasic_rtをpreemptに変更)。
selboot [0722rt|0722pe|0728rt] でzImageを切り替えられます(0722rtはかなり不安定、本来は*.dtbもコピーする必要があると思いますが、手抜き^^;;;)。
ホスト名「beagle」でssh接続できます(avahi)。
rootのパスワードは「bbblack」。
nasもnasの名前で接続できます(winbind)。
mpdはcubox梅雨入り版のものを使用(/root/mpdcubox、mpdのビルド環境は残してあります)。
selmpd [18y|18g|174s|173s] でmpdを切り替えられます。
selboot/selmpdの置き場所は/usr/local/sbin。
/etc/init.d/rtset.confと/etc/rc.localでrt優先レベルを設定。
moduleの作成は省略しています(手抜きです^^;;;)。
既知のバグ
- 再生の中断(直前のメッセージのもの、rtカーネル+nfsで発生、wavでは一回経験しただけ、dffでは多発)
- 再生/再生中断中のハング(0722rtで多発、0728rtで発生)
- 起動時のハング(0722rtで多発、0728rtで発生)
ディフォルトのカーネルは0722rtです。通常の再生用には0722peが安定していますので、こちらをお勧めします。
えふさん、syuさんにお願い。
dsd再生の確認ですが、syuさんがリンクされたChannel Classicのデータを使いましょう。同じデータの方が話が分かりやすいと思います。
データをアップロード後に最終確認していたら、0728rtでcifsに置いてあるスカルラッティ(上記Channel Classicの3曲目)をdsd再生中に
[sched_delayed] sched: RT throttling activated
と表示され、次の曲に移るところでハング。リセット再起動を何度かけても、同じスカルラッティを再生しにいってそのまま停止(再生は曲が終わるまで継続)。どうやってもログイン画面に辿り着けないという状態になりました。
開発環境でmpdのstateファイルをクリアして難を逃れましたが、そういうものだと覚悟してお使い下さい。
http://www.symphonic-net.com/kubotayo/cgi-bin/downlogs.cgi?id=0B1V9ShHUc5NqbVI5cm9rQ29Ld2c" target="_blank">http://www.symphonic-net.com/kubotayo/cgi-bin/downlogs.cgi?id=0B1V9ShHUc5NqbVI5cm9rQ29Ld2c
7zip圧縮してあります。
boot部分はtinkerさんの0722/0728configを使い github.com/beagleboard 3.8-rtカーネルソースからビルドしたzImage(と*.dtb)に入れ換えています(/buid_filesに置いてあります、peはbasic_rtをpreemptに変更)。
selboot [0722rt|0722pe|0728rt] でzImageを切り替えられます(0722rtはかなり不安定、本来は*.dtbもコピーする必要があると思いますが、手抜き^^;;;)。
ホスト名「beagle」でssh接続できます(avahi)。
rootのパスワードは「bbblack」。
nasもnasの名前で接続できます(winbind)。
mpdはcubox梅雨入り版のものを使用(/root/mpdcubox、mpdのビルド環境は残してあります)。
selmpd [18y|18g|174s|173s] でmpdを切り替えられます。
selboot/selmpdの置き場所は/usr/local/sbin。
/etc/init.d/rtset.confと/etc/rc.localでrt優先レベルを設定。
moduleの作成は省略しています(手抜きです^^;;;)。
既知のバグ
- 再生の中断(直前のメッセージのもの、rtカーネル+nfsで発生、wavでは一回経験しただけ、dffでは多発)
- 再生/再生中断中のハング(0722rtで多発、0728rtで発生)
- 起動時のハング(0722rtで多発、0728rtで発生)
ディフォルトのカーネルは0722rtです。通常の再生用には0722peが安定していますので、こちらをお勧めします。
えふさん、syuさんにお願い。
dsd再生の確認ですが、syuさんがリンクされたChannel Classicのデータを使いましょう。同じデータの方が話が分かりやすいと思います。
データをアップロード後に最終確認していたら、0728rtでcifsに置いてあるスカルラッティ(上記Channel Classicの3曲目)をdsd再生中に
[sched_delayed] sched: RT throttling activated
と表示され、次の曲に移るところでハング。リセット再起動を何度かけても、同じスカルラッティを再生しにいってそのまま停止(再生は曲が終わるまで継続)。どうやってもログイン画面に辿り着けないという状態になりました。
開発環境でmpdのstateファイルをクリアして難を逃れましたが、そういうものだと覚悟してお使い下さい。
yo 2013/08/02(Fri) 21:05 No.3356
Re: BeagleBone Black(5)
yo 2013/08/02(Fri) 21:07 No.3357
えふさん
> 0xFFを埋め込んだデータを圧縮したイメージを作成したら、何故かデータサイズが7.4MBなどという値を表示しています。それでもこれを解凍すると、しっかりと7.4GBくらいのサイズとなります。
???。ウームですね。ddしたイメージは7.4GBだったのでしょうか。圧縮して1/1000というのは考えにくいです。僕のやつは2GBが約300MBです。考えられるのは0xffだけのデータなら1/1000になるのかもしれません。
とりあえず、こちらのイメージは何とか公開できましたので、試して頂いて、それから問題解決しましょう。
> 0xFFを埋め込んだデータを圧縮したイメージを作成したら、何故かデータサイズが7.4MBなどという値を表示しています。それでもこれを解凍すると、しっかりと7.4GBくらいのサイズとなります。
???。ウームですね。ddしたイメージは7.4GBだったのでしょうか。圧縮して1/1000というのは考えにくいです。僕のやつは2GBが約300MBです。考えられるのは0xffだけのデータなら1/1000になるのかもしれません。
とりあえず、こちらのイメージは何とか公開できましたので、試して頂いて、それから問題解決しましょう。
yo 2013/08/02(Fri) 21:07 No.3357
Re: BeagleBone Black(5)
tinker 2013/08/02(Fri) 21:10 No.3358
yoさん
単に読み込み速度だけの問題ではなさそうですね。
いまTEST中のzImageは落ちないようになったのですが、負荷も音も0722みたいにはいきません。
ただ自分で使う分には、この位でもいいかなって思ってます。
安定しているのは、以下の理由もあるかもしれません。
・cpufrequtilsで800MHz固定とした（TOPで見ている限り、負荷は1GHzと同じ。熱暴走の可能性もあるので少し控えめに）
・USB給電で使っているのですが、手持ち2A出力のUSB充電器に替えた（IPadの充電もできるよって書いてある物）
単に読み込み速度だけの問題ではなさそうですね。
いまTEST中のzImageは落ちないようになったのですが、負荷も音も0722みたいにはいきません。
ただ自分で使う分には、この位でもいいかなって思ってます。
安定しているのは、以下の理由もあるかもしれません。
・cpufrequtilsで800MHz固定とした（TOPで見ている限り、負荷は1GHzと同じ。熱暴走の可能性もあるので少し控えめに）
・USB給電で使っているのですが、手持ち2A出力のUSB充電器に替えた（IPadの充電もできるよって書いてある物）
tinker 2013/08/02(Fri) 21:10 No.3358
Re: BeagleBone Black(5)
yo 2013/08/02(Fri) 21:53 No.3359
tinkerさん
wav(flac)だけなら0722が最高だと思います。ただ、dsd再生だと0722、0728、どちらも駄目で，preemptカーネルでないと駄目ですね。
「BBBの3.8-rtはdsd再生のリアルタイム処理で何か欠陥がある」というのが僕の推論です。えふさんとsyuさんの検証をお願いします。
wav(flac)だけなら0722が最高だと思います。ただ、dsd再生だと0722、0728、どちらも駄目で，preemptカーネルでないと駄目ですね。
「BBBの3.8-rtはdsd再生のリアルタイム処理で何か欠陥がある」というのが僕の推論です。えふさんとsyuさんの検証をお願いします。
yo 2013/08/02(Fri) 21:53 No.3359
Re: BeagleBone Black(5)
tinker 2013/08/02(Fri) 22:10 No.3360
yoさん
dsdとか24/192とかは、preenmptカーネルで聞くかCuboxに任せたほうが良さそうですね。
便乗UPします。
https://docs.google.com/file/d/0BxnbJHx0_xurMDNoQ2tsSUdyWG8/edit?usp=sharing" target="_blank">https://docs.google.com/file/d/0BxnbJHx0_xurMDNoQ2tsSUdyWG8/edit?usp=sharing
0722より安全で0728より音は良いかなと思います。
yoさんのイメージを使い、mkdir /build_files/0731rt として0731rtの中に展開してください。
切り替えは selboot 0731rt で大丈夫だと思います。
configが必要な時は0731rtで起動後 zcat /proc/config.gz > .config して下さい。
dsdとか24/192とかは、preenmptカーネルで聞くかCuboxに任せたほうが良さそうですね。
便乗UPします。
https://docs.google.com/file/d/0BxnbJHx0_xurMDNoQ2tsSUdyWG8/edit?usp=sharing" target="_blank">https://docs.google.com/file/d/0BxnbJHx0_xurMDNoQ2tsSUdyWG8/edit?usp=sharing
0722より安全で0728より音は良いかなと思います。
yoさんのイメージを使い、mkdir /build_files/0731rt として0731rtの中に展開してください。
切り替えは selboot 0731rt で大丈夫だと思います。
configが必要な時は0731rtで起動後 zcat /proc/config.gz > .config して下さい。
tinker 2013/08/02(Fri) 22:10 No.3360
Re: BeagleBone Black(5)
まさまさ 2013/08/02(Fri) 22:14 No.3361
yo さん
お久しぶりです。
もしかして、NAS側Ethernetが1Gbps、HUBも1Gbps じゃないでしょうか？
そうだとしたら、BBBのEthernetは100Mbpsまでしかスピードが出ないので、NASが1Gbpsで一気に送り出しても、その1/10の速度でしか受信ができないため、途中のHUBでパケットがあふれてしまうのが問題なのではないかと推察しています。
cifsで使われるTCP/IPだと、どのパケットが落ちたかということまで認識して、そこから再送を要求したり、何個まとめて送るかなどを調整して速度調整を図ったりすることができるのですが、nfs だとUDP/IPになり、再送の要求はアプリケーション（この場合にはmpd）側で行うことになりますので、良く考えて作られていないと、だめだめになってしまうかと思われます。
回避策としては、Ethernetの速度の差が発生しないようにすることで、NAS側のEthernetを100Mbpsで固定にしてあげれば良いかと思います。
ただ、厳密なことを言いますと、例えば受信側(mpd側)でなにか大きな処理が発生していて、ethernet側からのパケットの受信処理ができなくなってしまった場合には、同じ問題が発生すると思われますので、tcp/ipを使うcifsを使った方が無難と言えます。まぁ、この辺は音の良さと天秤にかけてどちらをとるかというところになるかと思いますが。。。
Ethernet Interface を 100Mbps に固定する方法ですが、
良く覚えてないのですが、おおむかしの Redhat Linux では if-eth0 ?とかいうファイルに speed 100M ??という記述をいれたような気がしています。
それから、実は私も BBB と Console Cable をオーダしてしまいました(笑)
昨晩ようやく音が出るようになりました。
当初 ddx-c が認識せず、結構あせってたのですが、gdu さん書き込みのComputer Audiophileを見てなんとか解決できました。
mpd.confに結構変更が必要だったのですね。
zeroconf_enabled "yes"
zeroconf_name "Voyage Music Player"
mixer_type "hardware"
bind_to_address "0.0.0.0"
これらを入れたら音が出ました。
お久しぶりです。
もしかして、NAS側Ethernetが1Gbps、HUBも1Gbps じゃないでしょうか？
そうだとしたら、BBBのEthernetは100Mbpsまでしかスピードが出ないので、NASが1Gbpsで一気に送り出しても、その1/10の速度でしか受信ができないため、途中のHUBでパケットがあふれてしまうのが問題なのではないかと推察しています。
cifsで使われるTCP/IPだと、どのパケットが落ちたかということまで認識して、そこから再送を要求したり、何個まとめて送るかなどを調整して速度調整を図ったりすることができるのですが、nfs だとUDP/IPになり、再送の要求はアプリケーション（この場合にはmpd）側で行うことになりますので、良く考えて作られていないと、だめだめになってしまうかと思われます。
回避策としては、Ethernetの速度の差が発生しないようにすることで、NAS側のEthernetを100Mbpsで固定にしてあげれば良いかと思います。
ただ、厳密なことを言いますと、例えば受信側(mpd側)でなにか大きな処理が発生していて、ethernet側からのパケットの受信処理ができなくなってしまった場合には、同じ問題が発生すると思われますので、tcp/ipを使うcifsを使った方が無難と言えます。まぁ、この辺は音の良さと天秤にかけてどちらをとるかというところになるかと思いますが。。。
Ethernet Interface を 100Mbps に固定する方法ですが、
良く覚えてないのですが、おおむかしの Redhat Linux では if-eth0 ?とかいうファイルに speed 100M ??という記述をいれたような気がしています。
それから、実は私も BBB と Console Cable をオーダしてしまいました(笑)
昨晩ようやく音が出るようになりました。
当初 ddx-c が認識せず、結構あせってたのですが、gdu さん書き込みのComputer Audiophileを見てなんとか解決できました。
mpd.confに結構変更が必要だったのですね。
zeroconf_enabled "yes"
zeroconf_name "Voyage Music Player"
mixer_type "hardware"
bind_to_address "0.0.0.0"
これらを入れたら音が出ました。
まさまさ 2013/08/02(Fri) 22:14 No.3361
Re: BeagleBone Black(5)
syu 2013/08/03(Sat) 00:11 No.3362
yoさん
nfsとcifsの件ですが、私はqnap212をcifsで使用しています。dsdがnfsだとトラブル多発しcifsだと少ないと言うことでもないようです。dsd再生はbbbでは瞬断でなく突然の音消え(再生進行)で、一時停止・再生で回復します。頻度は気まぐれで、のっけから音が出ないことも、２０分以上消えないこともあります。現象としてはyoさんのケースと同じだと思います。
余談ですが、arch linuxのrootfsでは、pacman -S nfs_utilsだけではnfsでマウントできず、格闘中です。/etc/conf.d/nfs-common.confをいじらないとだめらしいです。つまり、nfsとの直接比較は出来ていません。
まだ0722で遊んでますが、16/44.1再生中にyoさんがdsdで経験されたエラーメッセージが出ました。初期には4%+α程度だったsyの%cpu(s)が中途からほぼ倍（以下の例では7.6%）に増加し、ksoftirqd/0が上の方に出てくる頻度が増え、しばらくして落ちるときに[sched_delayed] sched: RT throttling activatedが表示されます。
top - 00:20:08 up 5 min, 2 users, load average: 0.09, 0.21, 0.13
Tasks: 75 total, 1 running, 74 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.0 us, 7.6 sy, 0.0 ni, 89.6 id, 0.0 wa, 0.0 hi, 0.8 si, 0.0 st
KiB Mem: 511672 total, 321636 used, 190036 free, 10004 buffers
KiB Swap: 0 total, 0 used, 0 free, 244180 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
69 root -56 0 0 0 0 S 13.9 0.0 0:38.41 irq/35-musb+
321 root 20 0 83648 79648 28268 S 3.0 15.6 0:08.21 mpd
96 root -54 0 0 0 0 S 2.0 0.0 0:05.00 irq/57-4a10+
346 root 20 0 0 0 0 S 1.7 0.0 0:04.36 cifsd
3 root 20 0 0 0 0 S 0.3 0.0 0:00.27 ksoftirqd/0
18 root 20 0 0 0 0 S 0.3 0.0 0:00.29 kworker/0:1
97 root -54 0 0 0 0 S 0.3 0.0 0:01.17 irq/58-4a10+
392 root 20 0 5088 1196 928 R 0.3 0.2 0:00.78 top
1 root 20 0 4792 2644 1816 S 0.0 0.5 0:01.93 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd
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.00 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+
9 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
10 root -2 0 0 0 0 S 0.0 0.0 0:00.07 rcuc/0
11 root -2 0 0 0 0 S 0.0 0.0 0:00.00 rcub/0 [sched_delayed] sched: RT throttling activated
このまま放置していると、以下のメッセージも出ます。
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:254 dev_watchdog+0x105/0x1ec()
NETDEV WATCHDOG: eth0 (cpsw): transmit queue 0 timed out
Modules linked in: autofs4
[<c0010411>] (unwind_backtrace+0x1/0x8c) from [<c0029673>] (warn_slowpath_common+0x33/0x48)
[<c0029673>] (warn_slowpath_common+0x33/0x48) from [<c00296d5>] (warn_slowpath_fmt+0x1b/0x24)
[<c00296d5>] (warn_slowpath_fmt+0x1b/0x24) from [<c02619c5>] (dev_watchdog+0x105/0x1ec)
[<c02619c5>] (dev_watchdog+0x105/0x1ec) from [<c0031929>] (call_timer_fn.isra.27+0x15/0x54)
[<c0031929>] (call_timer_fn.isra.27+0x15/0x54) from [<c0031a8d>] (run_timer_softirq+0x125/0x168)
[<c0031a8d>] (run_timer_softirq+0x125/0x168) from [<c002e495>] (__do_softirq+0x6d/0xf4)
[<c002e495>] (__do_softirq+0x6d/0xf4) from [<c002e53b>] (run_ksoftirqd+0x1f/0x38)
[<c002e53b>] (run_ksoftirqd+0x1f/0x38) from [<c0040be9>] (smpboot_thread_fn+0x139/0x14c)
[<c0040be9>] (smpboot_thread_fn+0x139/0x14c) from [<c003b2ef>] (kthread+0x5d/0x6a)
[<c003b2ef>] (kthread+0x5d/0x6a) from [<c000c6fd>] (ret_from_fork+0x11/0x34)
---[ end trace 5c7d1d96c4d05b79 ]---
debianhf-rootfsのイメージありがとうございます。早速明日にでも試してみようと思います。うちではdebianはさっぱりで、bone20でもだめでした。bone20は、まだここから落とせます。
http://rcn-ee.net/deb/rootfs/wheezy/" target="_blank">http://rcn-ee.net/deb/rootfs/wheezy/
bone20は、debian-7.0.0-console-armhf-2013-05-29.tar.xz 29-May-2013 12:15 117M です。
tinkerさんのzImage,dtbsも週末に試してみます。後追いは楽しいです。
nfsとcifsの件ですが、私はqnap212をcifsで使用しています。dsdがnfsだとトラブル多発しcifsだと少ないと言うことでもないようです。dsd再生はbbbでは瞬断でなく突然の音消え(再生進行)で、一時停止・再生で回復します。頻度は気まぐれで、のっけから音が出ないことも、２０分以上消えないこともあります。現象としてはyoさんのケースと同じだと思います。
余談ですが、arch linuxのrootfsでは、pacman -S nfs_utilsだけではnfsでマウントできず、格闘中です。/etc/conf.d/nfs-common.confをいじらないとだめらしいです。つまり、nfsとの直接比較は出来ていません。
まだ0722で遊んでますが、16/44.1再生中にyoさんがdsdで経験されたエラーメッセージが出ました。初期には4%+α程度だったsyの%cpu(s)が中途からほぼ倍（以下の例では7.6%）に増加し、ksoftirqd/0が上の方に出てくる頻度が増え、しばらくして落ちるときに[sched_delayed] sched: RT throttling activatedが表示されます。
top - 00:20:08 up 5 min, 2 users, load average: 0.09, 0.21, 0.13
Tasks: 75 total, 1 running, 74 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.0 us, 7.6 sy, 0.0 ni, 89.6 id, 0.0 wa, 0.0 hi, 0.8 si, 0.0 st
KiB Mem: 511672 total, 321636 used, 190036 free, 10004 buffers
KiB Swap: 0 total, 0 used, 0 free, 244180 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
69 root -56 0 0 0 0 S 13.9 0.0 0:38.41 irq/35-musb+
321 root 20 0 83648 79648 28268 S 3.0 15.6 0:08.21 mpd
96 root -54 0 0 0 0 S 2.0 0.0 0:05.00 irq/57-4a10+
346 root 20 0 0 0 0 S 1.7 0.0 0:04.36 cifsd
3 root 20 0 0 0 0 S 0.3 0.0 0:00.27 ksoftirqd/0
18 root 20 0 0 0 0 S 0.3 0.0 0:00.29 kworker/0:1
97 root -54 0 0 0 0 S 0.3 0.0 0:01.17 irq/58-4a10+
392 root 20 0 5088 1196 928 R 0.3 0.2 0:00.78 top
1 root 20 0 4792 2644 1816 S 0.0 0.5 0:01.93 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd
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.00 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+
9 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
10 root -2 0 0 0 0 S 0.0 0.0 0:00.07 rcuc/0
11 root -2 0 0 0 0 S 0.0 0.0 0:00.00 rcub/0 [sched_delayed] sched: RT throttling activated
このまま放置していると、以下のメッセージも出ます。
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:254 dev_watchdog+0x105/0x1ec()
NETDEV WATCHDOG: eth0 (cpsw): transmit queue 0 timed out
Modules linked in: autofs4
[<c0010411>] (unwind_backtrace+0x1/0x8c) from [<c0029673>] (warn_slowpath_common+0x33/0x48)
[<c0029673>] (warn_slowpath_common+0x33/0x48) from [<c00296d5>] (warn_slowpath_fmt+0x1b/0x24)
[<c00296d5>] (warn_slowpath_fmt+0x1b/0x24) from [<c02619c5>] (dev_watchdog+0x105/0x1ec)
[<c02619c5>] (dev_watchdog+0x105/0x1ec) from [<c0031929>] (call_timer_fn.isra.27+0x15/0x54)
[<c0031929>] (call_timer_fn.isra.27+0x15/0x54) from [<c0031a8d>] (run_timer_softirq+0x125/0x168)
[<c0031a8d>] (run_timer_softirq+0x125/0x168) from [<c002e495>] (__do_softirq+0x6d/0xf4)
[<c002e495>] (__do_softirq+0x6d/0xf4) from [<c002e53b>] (run_ksoftirqd+0x1f/0x38)
[<c002e53b>] (run_ksoftirqd+0x1f/0x38) from [<c0040be9>] (smpboot_thread_fn+0x139/0x14c)
[<c0040be9>] (smpboot_thread_fn+0x139/0x14c) from [<c003b2ef>] (kthread+0x5d/0x6a)
[<c003b2ef>] (kthread+0x5d/0x6a) from [<c000c6fd>] (ret_from_fork+0x11/0x34)
---[ end trace 5c7d1d96c4d05b79 ]---
debianhf-rootfsのイメージありがとうございます。早速明日にでも試してみようと思います。うちではdebianはさっぱりで、bone20でもだめでした。bone20は、まだここから落とせます。
http://rcn-ee.net/deb/rootfs/wheezy/" target="_blank">http://rcn-ee.net/deb/rootfs/wheezy/
bone20は、debian-7.0.0-console-armhf-2013-05-29.tar.xz 29-May-2013 12:15 117M です。
tinkerさんのzImage,dtbsも週末に試してみます。後追いは楽しいです。
syu 2013/08/03(Sat) 00:11 No.3362
Re: BeagleBone Black(5)
yo 2013/08/03(Sat) 09:44 No.3363
まさまささん
アドバイスありがとうございます。確かに「NAS側Ethernetが1Gbps、HUBも1Gbps」なので、調べてみたら
http://www.ksknet.net/linuxai/ethtool_duplexa.html" target="_blank">http://www.ksknet.net/linuxai/ethtool_duplexa.html
ethtoolというツールで指定できるようですね。試してみます。
> それから、実は私も BBB と Console Cable をオーダしてしまいました(笑)
ようこそBBBクラブに(^^)。怪しい魑魅魍魎だらけの世界ですが、ここで情報交換して、妖怪たちに立ち向かいましょう。
> 当初 ddx-c が認識せず、結構あせってたのですが、gdu さん書き込みのComputer Audiophileを見てなんとか解決できました。
ddx-cというのは何でしょうか。uda3の場合は指定をしなくても認識されるので、gduさんのリンク先のmpd.confの変更の意味がよく分からなかったのですよね。
アドバイスありがとうございます。確かに「NAS側Ethernetが1Gbps、HUBも1Gbps」なので、調べてみたら
http://www.ksknet.net/linuxai/ethtool_duplexa.html" target="_blank">http://www.ksknet.net/linuxai/ethtool_duplexa.html
ethtoolというツールで指定できるようですね。試してみます。
> それから、実は私も BBB と Console Cable をオーダしてしまいました(笑)
ようこそBBBクラブに(^^)。怪しい魑魅魍魎だらけの世界ですが、ここで情報交換して、妖怪たちに立ち向かいましょう。
> 当初 ddx-c が認識せず、結構あせってたのですが、gdu さん書き込みのComputer Audiophileを見てなんとか解決できました。
ddx-cというのは何でしょうか。uda3の場合は指定をしなくても認識されるので、gduさんのリンク先のmpd.confの変更の意味がよく分からなかったのですよね。
yo 2013/08/03(Sat) 09:44 No.3363
Re: BeagleBone Black(5)
yo 2013/08/03(Sat) 09:46 No.3364
syuさん、情報ありがとうございました。
大分見通しがよくなりましたね。
僕の環境でもcifsで再生の中断は発生していますので、僕の環境だけが妖怪だらけ(^^;;;という訳ではないようですね。
> 後追いは楽しいです。
アップロードしたイメージの検証よろしくです。
大分見通しがよくなりましたね。
僕の環境でもcifsで再生の中断は発生していますので、僕の環境だけが妖怪だらけ(^^;;;という訳ではないようですね。
> 後追いは楽しいです。
アップロードしたイメージの検証よろしくです。
yo 2013/08/03(Sat) 09:46 No.3364
Re: BeagleBone Black(5)
まさまさ 2013/08/03(Sat) 11:10 No.3365
> ddx-cというのは何でしょうか。
型番を間違って書いてしまっていました。
JAVS X-DDC のことでした。
ここで間違って書いてしまったのが原因か分からないのですが、昨晩から機嫌が悪くなってしまい音がまったく出なくなってしまいました。
Windows PC に差し替えても同じ症状なので、故障してしまったようです。でも、保障期間内で良かった～。
ちなみに、あの４行を入れるまでは、alsamixer でも認識しませんでした。
なんとなく、zeroconf_enabled "yes" が効いているのかなと思っています。
X-DDCが故障で確認できず、すみません。
型番を間違って書いてしまっていました。
JAVS X-DDC のことでした。
ここで間違って書いてしまったのが原因か分からないのですが、昨晩から機嫌が悪くなってしまい音がまったく出なくなってしまいました。
Windows PC に差し替えても同じ症状なので、故障してしまったようです。でも、保障期間内で良かった～。
ちなみに、あの４行を入れるまでは、alsamixer でも認識しませんでした。
なんとなく、zeroconf_enabled "yes" が効いているのかなと思っています。
X-DDCが故障で確認できず、すみません。
まさまさ 2013/08/03(Sat) 11:10 No.3365
Re: BeagleBone Black(5)
tinker 2013/08/03(Sat) 16:06 No.3366
まさまささん ようこそ。
>JAVS X-DDC のことでした。
私も使ってます。こちらの場合、mpd.confは修正せずに大丈夫でした。
DACとの相性もあるのかもしれませんが、24/96とか24/192で時々ボツボツとノイズが入ります。ちょっと難しいかなって印象です。
>JAVS X-DDC のことでした。
私も使ってます。こちらの場合、mpd.confは修正せずに大丈夫でした。
DACとの相性もあるのかもしれませんが、24/96とか24/192で時々ボツボツとノイズが入ります。ちょっと難しいかなって印象です。
tinker 2013/08/03(Sat) 16:06 No.3366
Re: BeagleBone Black(5)
yo 2013/08/03(Sat) 18:08 No.3367
syuさん
> 余談ですが、arch linuxのrootfsでは、pacman -S nfs_utilsだけではnfsでマウントできず、格闘中です。/etc/conf.d/nfs-common.confをいじらないとだめらしいです。つまり、nfsとの直接比較は出来ていません。
これ見落としていました。
syuさんのアップロードされたarchを使っているのですが、fstabで問題なくmountできています。これも新手の妖怪の一匹ですかね。ちなみに、syuさんのイメージに対して行った変更はホスト名を使えるようにするため
pacman -S avahi nss-mdns
systemctl enable avahi-daemon.service
systemctl start avahi-daemon.service
/etc/hosts、/etc/hostname、/etc/nsswitch.confの変更
とActive_Directoryを有効にするため
pacman -S samba
/etc/samba/smbを作成して
wins support = yes
wins supportだけを有効化
です。不思議ですね。
> 余談ですが、arch linuxのrootfsでは、pacman -S nfs_utilsだけではnfsでマウントできず、格闘中です。/etc/conf.d/nfs-common.confをいじらないとだめらしいです。つまり、nfsとの直接比較は出来ていません。
これ見落としていました。
syuさんのアップロードされたarchを使っているのですが、fstabで問題なくmountできています。これも新手の妖怪の一匹ですかね。ちなみに、syuさんのイメージに対して行った変更はホスト名を使えるようにするため
pacman -S avahi nss-mdns
systemctl enable avahi-daemon.service
systemctl start avahi-daemon.service
/etc/hosts、/etc/hostname、/etc/nsswitch.confの変更
とActive_Directoryを有効にするため
pacman -S samba
/etc/samba/smbを作成して
wins support = yes
wins supportだけを有効化
です。不思議ですね。
yo 2013/08/03(Sat) 18:08 No.3367
Re: BeagleBone Black(5)
えふ 2013/08/03(Sat) 19:36 No.3368
yoさん
0722rtでの第一報です。
>データをアップロード後に最終確認していたら、0728rtでcifsに置いてあるスカルラッティ(上記Channel Classicの3曲目)をdsd再生中に
[sched_delayed] sched: RT throttling activated
と表示され、次の曲に移るところでハング。リセット再起動を何度かけても、同じスカルラッティを再生しにいってそのまま停止(再生は曲が終わるまで継続)。どうやってもログイン画面に辿り着けないという状態になりました。
これが見事に起こりました。この曲単独で再生しても、終わった時点でGMPC、sshdとも接続が切れハング。二度とログインできなくなりました。自前のdebianはyoさんのと少し異なり、電源断後の再起動ではログイン可能です。
この曲データは何かあるのでしょうか。必ずハングするという再現性があります。ただし、Cuboxでは何事もなく終わります。ということなので、
>開発環境でmpdのstateファイルをクリアして難を逃れましたが
具体的にどうしたら良いか教えてください。まだ、0722pe等のテストができていません。
ところで、当方のdebianですが0xff埋め込みはパスして、単にSDカードをイメージ化し更に7zipで圧縮したところ約265MB（google driveでの表示）となりました。アップロードしたものをダウンロードしてWindowsソフトで解凍、更にDD for WindowsでSDに展開という一連の処理を行ったもので無事起動できました。
0722rtでの第一報です。
>データをアップロード後に最終確認していたら、0728rtでcifsに置いてあるスカルラッティ(上記Channel Classicの3曲目)をdsd再生中に
[sched_delayed] sched: RT throttling activated
と表示され、次の曲に移るところでハング。リセット再起動を何度かけても、同じスカルラッティを再生しにいってそのまま停止(再生は曲が終わるまで継続)。どうやってもログイン画面に辿り着けないという状態になりました。
これが見事に起こりました。この曲単独で再生しても、終わった時点でGMPC、sshdとも接続が切れハング。二度とログインできなくなりました。自前のdebianはyoさんのと少し異なり、電源断後の再起動ではログイン可能です。
この曲データは何かあるのでしょうか。必ずハングするという再現性があります。ただし、Cuboxでは何事もなく終わります。ということなので、
>開発環境でmpdのstateファイルをクリアして難を逃れましたが
具体的にどうしたら良いか教えてください。まだ、0722pe等のテストができていません。
ところで、当方のdebianですが0xff埋め込みはパスして、単にSDカードをイメージ化し更に7zipで圧縮したところ約265MB（google driveでの表示）となりました。アップロードしたものをダウンロードしてWindowsソフトで解凍、更にDD for WindowsでSDに展開という一連の処理を行ったもので無事起動できました。
えふ 2013/08/03(Sat) 19:36 No.3368
Re: BeagleBone Black(5)
くるる 2013/08/03(Sat) 19:46 No.3369
横から失礼します
>アドバイスありがとうございます。確かに「NAS側Ethernetが1Gbps、HUBも1Gbps」なので、調べてみたら
http://www.ksknet.net/linuxai/ethtool_duplexa.html" target="_blank">http://www.ksknet.net/linuxai/ethtool_duplexa.html
ethtoolというツールで指定できるようですね。試してみます。
ethtoolでautonegをoffした場合、対向のスイッチ側もautonegをoffして固定設定しないと、フレームロストが発生しますのでお気を付けください。
autonegのadvertiseを変更するなら対向を変更しなくても大丈夫だと思います。
あと、nfsはずいぶん昔からデフォルトでtcpとなっています。
>アドバイスありがとうございます。確かに「NAS側Ethernetが1Gbps、HUBも1Gbps」なので、調べてみたら
http://www.ksknet.net/linuxai/ethtool_duplexa.html" target="_blank">http://www.ksknet.net/linuxai/ethtool_duplexa.html
ethtoolというツールで指定できるようですね。試してみます。
ethtoolでautonegをoffした場合、対向のスイッチ側もautonegをoffして固定設定しないと、フレームロストが発生しますのでお気を付けください。
autonegのadvertiseを変更するなら対向を変更しなくても大丈夫だと思います。
あと、nfsはずいぶん昔からデフォルトでtcpとなっています。
くるる 2013/08/03(Sat) 19:46 No.3369
Re: BeagleBone Black(5)
yo 2013/08/03(Sat) 19:51 No.3370
えふさん
あのスカルラッティはデータに問題があるようです。cuboxで再生してみましたが、同じようにハングしました。従ってこれはプレイリストから削除してテストしましょう。
> 具体的にどうしたら良いか教えてください。まだ、0722pe等のテストができていません。
開発環境で
sudo rm マウントポイント/var/lib/mpd/state
です。
> ところで、・・・無事起動できました。
よろしければアドレスを教えて下さい。
あのスカルラッティはデータに問題があるようです。cuboxで再生してみましたが、同じようにハングしました。従ってこれはプレイリストから削除してテストしましょう。
> 具体的にどうしたら良いか教えてください。まだ、0722pe等のテストができていません。
開発環境で
sudo rm マウントポイント/var/lib/mpd/state
です。
> ところで、・・・無事起動できました。
よろしければアドレスを教えて下さい。
yo 2013/08/03(Sat) 19:51 No.3370
Re: BeagleBone Black(5)
yo 2013/08/03(Sat) 20:10 No.3371
まさまささん、くるるさん
ethtoolをインストールして、やってみました。
root@beagle:~# ethtool -s eth0 speed 100 duplex full autoneg on
Cannot get current device settings: Operation not supported
not setting speed
not setting duplex
not setting autoneg
変なので、確認したら
root@beagle:~# ethtool eth0
Settings for eth0:
Current message level: 0x00000000 (0)
Link detected: yes
root@beagle:~# ethtool -i eth0
driver: TI CPSW Driver v1.0
version: 1.0
firmware-version:
bus-info: 4a100000.ethernet
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
となります。
同じことをcubox-debianでやってみたら
root@(cubox):~# ethtool eth0
Settings for eth0:
Supported ports: [ TP AUI BNC MII FIBRE ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: external
Auto-negotiation: on
Link detected: yes
root@(cubox):~# ethtool -i eth0
driver: mv643xx_eth
version: 1.4
firmware-version: N/A
bus-info: platform
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
とちゃんと表示されます。チップがethtool対応していないということでしょうか。
> あと、nfsはずいぶん昔からデフォルトでtcpとなっています。
これは NFSv4 という意味ですね。
ethtoolをインストールして、やってみました。
root@beagle:~# ethtool -s eth0 speed 100 duplex full autoneg on
Cannot get current device settings: Operation not supported
not setting speed
not setting duplex
not setting autoneg
変なので、確認したら
root@beagle:~# ethtool eth0
Settings for eth0:
Current message level: 0x00000000 (0)
Link detected: yes
root@beagle:~# ethtool -i eth0
driver: TI CPSW Driver v1.0
version: 1.0
firmware-version:
bus-info: 4a100000.ethernet
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
となります。
同じことをcubox-debianでやってみたら
root@(cubox):~# ethtool eth0
Settings for eth0:
Supported ports: [ TP AUI BNC MII FIBRE ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: external
Auto-negotiation: on
Link detected: yes
root@(cubox):~# ethtool -i eth0
driver: mv643xx_eth
version: 1.4
firmware-version: N/A
bus-info: platform
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
とちゃんと表示されます。チップがethtool対応していないということでしょうか。
> あと、nfsはずいぶん昔からデフォルトでtcpとなっています。
これは NFSv4 という意味ですね。
yo 2013/08/03(Sat) 20:10 No.3371
Re: BeagleBone Black(5)
くるる 2013/08/03(Sat) 20:39 No.3372
こんばんは
>とちゃんと表示されます。チップがethtool対応していないということでしょうか。
ドライバが対応してないようですね。
いまどき珍しいです。
ただ、
>root@beagle:~# ethtool -s eth0 speed 100 duplex full autoneg on
この書式は正しいでしょうか？ スピード、duplexを指定していながら、autoneg onだとautonegが有効になって、1G（サポートするなら）で接続しようとする気がします。
100Mで接続しているのは1000BASE-T/FULLを含んだautonegを
行った結果のように見えます。
>とちゃんと表示されます。チップがethtool対応していないということでしょうか。
ドライバが対応してないようですね。
いまどき珍しいです。
ただ、
>root@beagle:~# ethtool -s eth0 speed 100 duplex full autoneg on
この書式は正しいでしょうか？ スピード、duplexを指定していながら、autoneg onだとautonegが有効になって、1G（サポートするなら）で接続しようとする気がします。
100Mで接続しているのは1000BASE-T/FULLを含んだautonegを
行った結果のように見えます。
くるる 2013/08/03(Sat) 20:39 No.3372
Re: BeagleBone Black(5)
すいません。
、
>この書式は正しいでしょうか？ スピード、duplexを指定していながら、autoneg onだとautonegが有効になって、1G（サポートするなら）で接続しようとする気がします。
これは間違いでした。
これで100M/FULLのみをadvertiseするのですね。
問題ないです。
以上です
くるる 2013/08/03(Sat) 20:47 No.3373
すいません。
、
>この書式は正しいでしょうか？ スピード、duplexを指定していながら、autoneg onだとautonegが有効になって、1G（サポートするなら）で接続しようとする気がします。
これは間違いでした。
これで100M/FULLのみをadvertiseするのですね。
問題ないです。
以上です
くるる 2013/08/03(Sat) 20:47 No.3373
Re: BeagleBone Black(5)
まさまさ 2013/08/03(Sat) 22:14 No.3374
くるるさん、yoさん
100Mbpsに固定するのは BBB 側ではなくって、NAS側の方です。
BBB側は、恐らく最大スピードの出る100M/Fullでネゴされると思いますので。
しかし、BBB の Ethernet Chip は特殊なものをつかっているんですかねぇ。サポートされていないとは。
tinker さん、yo さん
X-DDC の件ですが、Windows PC につなぎ直したとき、電源が入りっぱなしになっていたようで、initialize できていなかったようです。さきほど CuBox につなぎ直したら、まったく問題無く音が出ました。
ということでBBB側の問題のようです。それで mpd.conf の4つのパラメータを削除したり、追加したりしてみたのですが、どちらも音が出なくなりました。音が出たのは、いろいろやっていて、偶然出てしまったのかもしれません。
うーん、私も魑魅魍魎の世界にはまってしまったのかもです。
今はあきらめて、yo さんに作っていただいたイメージの0722peに取り掛かってますが、こちらも音がでません。。。
44.1/16 flac を再生させると、パネルの表示はちゃんと44.1KHz って出て、MPoD 側も再生されているようにバーが伸びているんですけど。
やっぱ魑魅魍魎ですね～。
100Mbpsに固定するのは BBB 側ではなくって、NAS側の方です。
BBB側は、恐らく最大スピードの出る100M/Fullでネゴされると思いますので。
しかし、BBB の Ethernet Chip は特殊なものをつかっているんですかねぇ。サポートされていないとは。
tinker さん、yo さん
X-DDC の件ですが、Windows PC につなぎ直したとき、電源が入りっぱなしになっていたようで、initialize できていなかったようです。さきほど CuBox につなぎ直したら、まったく問題無く音が出ました。
ということでBBB側の問題のようです。それで mpd.conf の4つのパラメータを削除したり、追加したりしてみたのですが、どちらも音が出なくなりました。音が出たのは、いろいろやっていて、偶然出てしまったのかもしれません。
うーん、私も魑魅魍魎の世界にはまってしまったのかもです。
今はあきらめて、yo さんに作っていただいたイメージの0722peに取り掛かってますが、こちらも音がでません。。。
44.1/16 flac を再生させると、パネルの表示はちゃんと44.1KHz って出て、MPoD 側も再生されているようにバーが伸びているんですけど。
やっぱ魑魅魍魎ですね～。
まさまさ 2013/08/03(Sat) 22:14 No.3374
Re: BeagleBone Black(5)
tinker 2013/08/03(Sat) 22:49 No.3375
まさまささん
たぶんミュートになってるんだと思います。
alsamixer -c0 で、設定を確認してみて下さい。
たぶんミュートになってるんだと思います。
alsamixer -c0 で、設定を確認してみて下さい。
tinker 2013/08/03(Sat) 22:49 No.3375
Re: BeagleBone Black(5)
まさまさ 2013/08/03(Sat) 23:05 No.3376
tinkerさん
アドバイスどうもありがとうございます♪
残念ながら、最大音量になっていました。
tail -f /var/lib/mpd/mpd.log を見てみたのですが、
曲をスタートさせるときに、
Failed to open mixer for 'My ALSA Device': no such mixer control: PCM
と表示されます。
mpd.conf は music directory と playlist directory を変更したのみで、他には手をつけていません。
ちなみに、起動時からのmpd.logです。
Aug 03 13:56 : config: option 'enabled' on line 19 was not recognized
Aug 03 13:56 : config: option 'dsdsampleformat' on line 20 was not recognized
Aug 03 13:56 : config: option 'tagsupport' on line 21 was not recognized
Aug 03 13:56 : avahi: Service 'Music Player' successfully established.
Aug 03 13:56 : Failed to open mixer for 'My ALSA Device': no such mixer control: PCM
Aug 03 13:57 : client: No such playlist
Aug 03 13:57 : Failed to open mixer for 'My ALSA Device': no such mixer control: PCM
Aug 03 13:57 : Failed to open mixer for 'My ALSA Device': no such mixer control: PCM
Aug 03 13:58 : Failed to open mixer for 'My ALSA Device': no such mixer control: PCM
Aug 03 13:59 : Failed to open mixer for 'My ALSA Device': no such mixer control: PCM
もし他になにかあればお願い致します m(_ _)m
アドバイスどうもありがとうございます♪
残念ながら、最大音量になっていました。
tail -f /var/lib/mpd/mpd.log を見てみたのですが、
曲をスタートさせるときに、
Failed to open mixer for 'My ALSA Device': no such mixer control: PCM
と表示されます。
mpd.conf は music directory と playlist directory を変更したのみで、他には手をつけていません。
ちなみに、起動時からのmpd.logです。
Aug 03 13:56 : config: option 'enabled' on line 19 was not recognized
Aug 03 13:56 : config: option 'dsdsampleformat' on line 20 was not recognized
Aug 03 13:56 : config: option 'tagsupport' on line 21 was not recognized
Aug 03 13:56 : avahi: Service 'Music Player' successfully established.
Aug 03 13:56 : Failed to open mixer for 'My ALSA Device': no such mixer control: PCM
Aug 03 13:57 : client: No such playlist
Aug 03 13:57 : Failed to open mixer for 'My ALSA Device': no such mixer control: PCM
Aug 03 13:57 : Failed to open mixer for 'My ALSA Device': no such mixer control: PCM
Aug 03 13:58 : Failed to open mixer for 'My ALSA Device': no such mixer control: PCM
Aug 03 13:59 : Failed to open mixer for 'My ALSA Device': no such mixer control: PCM
もし他になにかあればお願い致します m(_ _)m
まさまさ 2013/08/03(Sat) 23:05 No.3376
Re: BeagleBone Black(5)
tinker 2013/08/04(Sun) 11:04 No.3377
まさまささん
ミュートじゃなかったんですね。
alsamixerで下から4行目は xMMxではなくx00xになってるってことですね？
mpd.confはimgに入っていたものから修正されましたか？
ミュートじゃなかったんですね。
alsamixerで下から4行目は xMMxではなくx00xになってるってことですね？
mpd.confはimgに入っていたものから修正されましたか？
tinker 2013/08/04(Sun) 11:04 No.3377
Re: BeagleBone Black(5)
tinker 2013/08/04(Sun) 11:22 No.3378
まさまささん
imgの中の/etc/mpd.confを見ると、mixer_typeが有効になってないようですね。どれか一つ（disabled，hardwareなど）有効にしてみてください。
imgの中の/etc/mpd.confを見ると、mixer_typeが有効になってないようですね。どれか一つ（disabled，hardwareなど）有効にしてみてください。
tinker 2013/08/04(Sun) 11:22 No.3378
Re: BeagleBone Black(5)
まさまさ 2013/08/04(Sun) 12:56 No.3379
tinkerさん
いろいろとどうもありがとうございます。
まず、alsamixer ですが、表示はこんな感じです。
lqqqqqqqqqqqqqqqqqqqqqqqqqqqqq AlsaMixer v1.0.25 qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
x Card: JAVS USB Audio 2.0 F1: Help x
x Chip: USB Mixer F2: System information x
x View: F3:[Playback] F4: Capture F5: All F6: Select sound card x
x Item: JAVS Clock Selector [dB gain: 0.00, 0.00] Esc: Exit x
dB gain: 0.00, 0.00 となっていて、その時に上下の矢印キーでgainを - dB にしたりしても、変わりがありませんでした。
それから、 /etc/mpd.conf も mixer_type "disabled" と"hardware" のどちらも試してみましたが、ダメでした。
それ以外にもzeroconf_enabled "yes"やbind_to_address "0.0.0.0"を入れてみたりしましたが、ダメ。。。
ちなみに今回は、どのパラメータで変化があるか確認するために、一つ変更しては、一旦BBBとX-DDCの電源を落として確認しています。
まだ道のりは長そうです。。。。
あ、それから amazon の review で、BBB には revision があると書いてあるのを読み、私は最新と言われている "A5C" というものをオーダしたのですが、皆さんは同じ revision でしょうか？
いろいろとどうもありがとうございます。
まず、alsamixer ですが、表示はこんな感じです。
lqqqqqqqqqqqqqqqqqqqqqqqqqqqqq AlsaMixer v1.0.25 qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
x Card: JAVS USB Audio 2.0 F1: Help x
x Chip: USB Mixer F2: System information x
x View: F3:[Playback] F4: Capture F5: All F6: Select sound card x
x Item: JAVS Clock Selector [dB gain: 0.00, 0.00] Esc: Exit x
dB gain: 0.00, 0.00 となっていて、その時に上下の矢印キーでgainを - dB にしたりしても、変わりがありませんでした。
それから、 /etc/mpd.conf も mixer_type "disabled" と"hardware" のどちらも試してみましたが、ダメでした。
それ以外にもzeroconf_enabled "yes"やbind_to_address "0.0.0.0"を入れてみたりしましたが、ダメ。。。
ちなみに今回は、どのパラメータで変化があるか確認するために、一つ変更しては、一旦BBBとX-DDCの電源を落として確認しています。
まだ道のりは長そうです。。。。
あ、それから amazon の review で、BBB には revision があると書いてあるのを読み、私は最新と言われている "A5C" というものをオーダしたのですが、皆さんは同じ revision でしょうか？
まさまさ 2013/08/04(Sun) 12:56 No.3379
Re: BeagleBone Black(5)
syu 2013/08/04(Sun) 14:26 No.3380
yoさん、tinkerさん
yoさんのimgを試してみましたが、またもや妖怪に遭遇したかも(^^;;
>ディフォルトのカーネルは0722rt
のはずですが、オリジナルのbone20が起動してしまいました。
selboot 0722rt とやっても、起動するのはやはりbone20です。この状態ではhdmiも生きていて device "hw:1,0" と書き換えないと音が出ませんし、topで確認してもrtカーネールではなさそう。
/usr/local/sbin/selbootを下記のように一部改変し、rtカーネルに変更出来るようになりましたが、変ですよねえ。
root@beagle:~# nano /usr/local/sbin/selboot
#!/bin/sh
str="/build_files/"
dirname=$str$1
zimage="/zImage"
dtb="/*.dtb"
filename=$dirname$zimage
if cp $filename /boot/
then
sleep 1s
filename1=$dirname$dtb
cp $filename1 /boot/dtbs/
echo "reboot $1"
sync
sleep 1s
shutdown -r now
else
echo "usage : selboot [0722rt|0728rt|0731rt|0722pe]"
fi
-----
selboot 0731rtでは、
root@beagle:~# uname -a
Linux beagle 3.8.13-rt9_0722kai-00899-gbbecbc0 #6 SMP PREEMPT Wed Jul 31 07:53:11 JST 2013 armv7l GNU/Linux
dff再生中のtopですが、良好だと思います。音消えも発生しません。
top - 05:09:14 up 23 min, 2 users, load average: 0.03, 0.08, 0.07
Tasks: 75 total, 1 running, 74 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.7 us, 11.3 sy, 0.0 ni, 84.8 id, 0.0 wa, 0.0 hi, 1.2 si, 0.0 st
KiB Mem: 513280 total, 115660 used, 397620 free, 4552 buffers
KiB Swap: 0 total, 0 used, 0 free, 43500 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 13.8 0.0 2:58.08 irq/35-musb-hdr
2188 mpd 20 0 75532 71m 22m S 3.6 14.3 0:23.29 mpd
76 root -55 0 0 0 0 S 2.0 0.0 0:10.74 irq/57-4a100000
1636 root -54 0 0 0 0 S 2.0 0.0 0:10.25 cifsd
77 root -51 0 0 0 0 S 0.7 0.0 0:02.14 irq/58-4a100000
2383 root 20 0 4196 1216 884 R 0.7 0.2 0:00.09 top
1 root 20 0 1684 624 520 S 0.0 0.1 0:01.28 init
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:01.13 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
8 root rt 0 0 0 0 S 0.0 0.0 0:00.00 posixcputmr/0
9 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
10 root 20 0 0 0 0 S 0.0 0.0 0:00.16 rcu_preempt
11 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
12 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_sched
13 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 cpuset
まさまささん
BBBのリビジョンですが、購入した店の情報では、私のはA5Aのはずです。確か、yoさん、tinkerさんもA5Aですね。
http://store.techshare.jp/html/page15.html" target="_blank">http://store.techshare.jp/html/page15.html
シールが貼ってある場合がほとんどのようですが、私のBBBにはシールありませんでしたので確認できていません。
A5AとA5Cの違いはhdmiまわりの抵抗値だけだったと思います。
ところで、arch linuxをrootfsにした0722rtですが、nfs関連をいじっていたら、突然ご機嫌良好になり、dffも音消えなく再生できるようになりました。5時間ぐらい、落ちることなく動いています。
pacman -S nfs_utilsが効いたのかなあ？？
yoさんのimgを試してみましたが、またもや妖怪に遭遇したかも(^^;;
>ディフォルトのカーネルは0722rt
のはずですが、オリジナルのbone20が起動してしまいました。
selboot 0722rt とやっても、起動するのはやはりbone20です。この状態ではhdmiも生きていて device "hw:1,0" と書き換えないと音が出ませんし、topで確認してもrtカーネールではなさそう。
/usr/local/sbin/selbootを下記のように一部改変し、rtカーネルに変更出来るようになりましたが、変ですよねえ。
root@beagle:~# nano /usr/local/sbin/selboot
#!/bin/sh
str="/build_files/"
dirname=$str$1
zimage="/zImage"
dtb="/*.dtb"
filename=$dirname$zimage
if cp $filename /boot/
then
sleep 1s
filename1=$dirname$dtb
cp $filename1 /boot/dtbs/
echo "reboot $1"
sync
sleep 1s
shutdown -r now
else
echo "usage : selboot [0722rt|0728rt|0731rt|0722pe]"
fi
-----
selboot 0731rtでは、
root@beagle:~# uname -a
Linux beagle 3.8.13-rt9_0722kai-00899-gbbecbc0 #6 SMP PREEMPT Wed Jul 31 07:53:11 JST 2013 armv7l GNU/Linux
dff再生中のtopですが、良好だと思います。音消えも発生しません。
top - 05:09:14 up 23 min, 2 users, load average: 0.03, 0.08, 0.07
Tasks: 75 total, 1 running, 74 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.7 us, 11.3 sy, 0.0 ni, 84.8 id, 0.0 wa, 0.0 hi, 1.2 si, 0.0 st
KiB Mem: 513280 total, 115660 used, 397620 free, 4552 buffers
KiB Swap: 0 total, 0 used, 0 free, 43500 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
64 root -56 0 0 0 0 S 13.8 0.0 2:58.08 irq/35-musb-hdr
2188 mpd 20 0 75532 71m 22m S 3.6 14.3 0:23.29 mpd
76 root -55 0 0 0 0 S 2.0 0.0 0:10.74 irq/57-4a100000
1636 root -54 0 0 0 0 S 2.0 0.0 0:10.25 cifsd
77 root -51 0 0 0 0 S 0.7 0.0 0:02.14 irq/58-4a100000
2383 root 20 0 4196 1216 884 R 0.7 0.2 0:00.09 top
1 root 20 0 1684 624 520 S 0.0 0.1 0:01.28 init
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:01.13 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
8 root rt 0 0 0 0 S 0.0 0.0 0:00.00 posixcputmr/0
9 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
10 root 20 0 0 0 0 S 0.0 0.0 0:00.16 rcu_preempt
11 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
12 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_sched
13 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 cpuset
まさまささん
BBBのリビジョンですが、購入した店の情報では、私のはA5Aのはずです。確か、yoさん、tinkerさんもA5Aですね。
http://store.techshare.jp/html/page15.html" target="_blank">http://store.techshare.jp/html/page15.html
シールが貼ってある場合がほとんどのようですが、私のBBBにはシールありませんでしたので確認できていません。
A5AとA5Cの違いはhdmiまわりの抵抗値だけだったと思います。
ところで、arch linuxをrootfsにした0722rtですが、nfs関連をいじっていたら、突然ご機嫌良好になり、dffも音消えなく再生できるようになりました。5時間ぐらい、落ちることなく動いています。
pacman -S nfs_utilsが効いたのかなあ？？
syu 2013/08/04(Sun) 14:26 No.3380
Re: BeagleBone Black(5)
まさまさ 2013/08/04(Sun) 15:46 No.3381
syuさん
みなさんはA5A verion でしたか。。。
ちなみに私のBBBですが、コンソールケーブルのピンが無い側のコネクタの外側にバーコードが貼ってあり、そこの最後にA5Cと表示があります。あとワンちゃんの絵が書いてある外箱にも"Rev A5C" と表示がありました。
X-DDCで音が出ない件ですが、ちょっと埒が明かないので、
0722pe をあきらめて、0728rt を試してみようと思い立ちました。
そうしたら、、、
root@beagle:~# selboot 0728rt
reboot 0728rt
; 大幅省略
[ ok ] Starting system message bus: dbus.
[ ok ] Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon.
lockfile creation failed: exceeded maximum number of lock attempts
ここで止まってしまい、ログインできなくなりました。
0722pe だと
; 大幅省略
[ ok ] Starting system message bus: dbus.
[ ok ] Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon.
chrt: failed to get pid 55's policy: No such process
chrt: failed to get pid 54's policy: No such process
rtset start
[ ok ] Starting OpenBSD Secure Shell server: sshd.
[ ok ] Starting the Winbind daemon: winbind.
Debian GNU/Linux 7.0 beagle ttyO0
beagle login: root
Password:
となりなんとかログインできていたのですが。
うーん。。。
私の方では、Computer Audiophileに記載してある方法で、取り組んでみることにしますね。
みなさんはA5A verion でしたか。。。
ちなみに私のBBBですが、コンソールケーブルのピンが無い側のコネクタの外側にバーコードが貼ってあり、そこの最後にA5Cと表示があります。あとワンちゃんの絵が書いてある外箱にも"Rev A5C" と表示がありました。
X-DDCで音が出ない件ですが、ちょっと埒が明かないので、
0722pe をあきらめて、0728rt を試してみようと思い立ちました。
そうしたら、、、
root@beagle:~# selboot 0728rt
reboot 0728rt
; 大幅省略
[ ok ] Starting system message bus: dbus.
[ ok ] Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon.
lockfile creation failed: exceeded maximum number of lock attempts
ここで止まってしまい、ログインできなくなりました。
0722pe だと
; 大幅省略
[ ok ] Starting system message bus: dbus.
[ ok ] Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon.
chrt: failed to get pid 55's policy: No such process
chrt: failed to get pid 54's policy: No such process
rtset start
[ ok ] Starting OpenBSD Secure Shell server: sshd.
[ ok ] Starting the Winbind daemon: winbind.
Debian GNU/Linux 7.0 beagle ttyO0
beagle login: root
Password:
となりなんとかログインできていたのですが。
うーん。。。
私の方では、Computer Audiophileに記載してある方法で、取り組んでみることにしますね。
まさまさ 2013/08/04(Sun) 15:46 No.3381
Re: BeagleBone Black(5)
tinker 2013/08/04(Sun) 17:42 No.3382
まさまささん
最近売ってるのはA5Cみたいですね。いいなぁ、羨ましい。
音出しできていないようですね。alsamixerで見る必要があるのは、画面上ではなく下の方ですよ。
最近売ってるのはA5Cみたいですね。いいなぁ、羨ましい。
音出しできていないようですね。alsamixerで見る必要があるのは、画面上ではなく下の方ですよ。
tinker 2013/08/04(Sun) 17:42 No.3382
Re: BeagleBone Black(5)
tinker 2013/08/04(Sun) 17:48 No.3383
syuさん
0731も一様使えるようで良かったです。
私の環境だと、0731は2日以上連続再生できる事を確認できています。
0731も一様使えるようで良かったです。
私の環境だと、0731は2日以上連続再生できる事を確認できています。
tinker 2013/08/04(Sun) 17:48 No.3383
Re: BeagleBone Black(5)
まさまさ 2013/08/04(Sun) 18:10 No.3384
tinkerさん
alsamixer ですが、下の方はグラフ表示があって、その下に100<>100 って表示されています。
それで下矢印キーを押すと下がりますので、ボリューム自体は最大になっていて、ちゃんと効きそうな気がします。
それで、さきほどの Computer Audiophile に記載してある方法で、再チャレンジしてみました。
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/
ゼロからやり直して、うまく動きました♪
前回うまく行かなかった時には、他の方法とごちゃまぜになって設定を行っていたのが原因かもしれません。
動いた後に、今度は一度すべての電源を落として、再度起動させるということを
念には念を入れて３回もやってみてますので、今度はきっと大丈夫でしょう。
次はもう少し連続して音出ししてみます。
それで、Linux 初心者が気づいた点をば。
1. SDCard で起動したあとに、自動的にeMMC flash memoryにコピーされ、
それ以降は、eMMC flash で立ち上がる
2. apt-get update, apt-get upgrade -y を実行した後に、一度 reboot している。
3. /etc/default/cpufrequtils というファイルを追加している
もし何かヒントになれば幸いです。
alsamixer ですが、下の方はグラフ表示があって、その下に100<>100 って表示されています。
それで下矢印キーを押すと下がりますので、ボリューム自体は最大になっていて、ちゃんと効きそうな気がします。
それで、さきほどの Computer Audiophile に記載してある方法で、再チャレンジしてみました。
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/
ゼロからやり直して、うまく動きました♪
前回うまく行かなかった時には、他の方法とごちゃまぜになって設定を行っていたのが原因かもしれません。
動いた後に、今度は一度すべての電源を落として、再度起動させるということを
念には念を入れて３回もやってみてますので、今度はきっと大丈夫でしょう。
次はもう少し連続して音出ししてみます。
それで、Linux 初心者が気づいた点をば。
1. SDCard で起動したあとに、自動的にeMMC flash memoryにコピーされ、
それ以降は、eMMC flash で立ち上がる
2. apt-get update, apt-get upgrade -y を実行した後に、一度 reboot している。
3. /etc/default/cpufrequtils というファイルを追加している
もし何かヒントになれば幸いです。
まさまさ 2013/08/04(Sun) 18:10 No.3384
Re: BeagleBone Black(5)
tinker 2013/08/04(Sun) 18:26 No.3385
まさまささん
>下の方はグラフ表示があって、その下に100<>100 って表示されています。
確認したいのは100<>100の2つ上がどうなっているかなんです。x00xになっていますか？
>3. /etc/default/cpufrequtils というファイルを追加している
これでもいいのですが、/etc/default/cpufrequtilsは追加せず、/etc/init.d/cpufrequtilsの方をいじるんじゃないかと思います。
簡単にやるには、コマンドから cpufreq-set -c 0 -f 0.80GHz （0.80Hzの部分は設定したい周波数に）と入力するか、rc.localに1行追加すればいいかと思います。
>下の方はグラフ表示があって、その下に100<>100 って表示されています。
確認したいのは100<>100の2つ上がどうなっているかなんです。x00xになっていますか？
>3. /etc/default/cpufrequtils というファイルを追加している
これでもいいのですが、/etc/default/cpufrequtilsは追加せず、/etc/init.d/cpufrequtilsの方をいじるんじゃないかと思います。
簡単にやるには、コマンドから cpufreq-set -c 0 -f 0.80GHz （0.80Hzの部分は設定したい周波数に）と入力するか、rc.localに1行追加すればいいかと思います。
tinker 2013/08/04(Sun) 18:26 No.3385
Re: BeagleBone Black(5)
yo 2013/08/04(Sun) 19:50 No.3387
tinkerさん、カーネルのアップロードありがとうございました。
0731rtを試してみました。なかなかいいですね。安定しているし、音も0722rtと比較して遜色がないという感じです。僕のイメージの0728rtは不要になったようです。
えぶさん、アドレスご連絡いただきありがとうございました。
イメージ試してみました。こちらの環境での動作は僕のアップロードしたイメージと一緒ですね。ということで、dsd再生が途中で中断するというのがrtカーネルの最大の問題点です。
syuさん
> yoさんのimgを試してみましたが、またもや妖怪に遭遇したかも(^^;;
以前、syuさんのイメージを僕が試した時と逆の現象が起きたのではないでしょうか。
> cp $filename1 /boot/dtbs/
これで正解ですね。ただこの変更で何故rtカーネルに切り替わったのかはよく分かりませんね。謎だなぁ。
> dff再生中のtopですが、良好だと思います。音消えも発生しません。
ウーム。僕のところでは発生しました(Channel Classicのデータ)。どんな魔法を使ったのか教えて頂けますか。
まさまささん
僕のBBBのリビジョンですが、シールがはってないので外箱の表記からですがA5Aのようです。
0731rtを試してみました。なかなかいいですね。安定しているし、音も0722rtと比較して遜色がないという感じです。僕のイメージの0728rtは不要になったようです。
えぶさん、アドレスご連絡いただきありがとうございました。
イメージ試してみました。こちらの環境での動作は僕のアップロードしたイメージと一緒ですね。ということで、dsd再生が途中で中断するというのがrtカーネルの最大の問題点です。
syuさん
> yoさんのimgを試してみましたが、またもや妖怪に遭遇したかも(^^;;
以前、syuさんのイメージを僕が試した時と逆の現象が起きたのではないでしょうか。
> cp $filename1 /boot/dtbs/
これで正解ですね。ただこの変更で何故rtカーネルに切り替わったのかはよく分かりませんね。謎だなぁ。
> dff再生中のtopですが、良好だと思います。音消えも発生しません。
ウーム。僕のところでは発生しました(Channel Classicのデータ)。どんな魔法を使ったのか教えて頂けますか。
まさまささん
僕のBBBのリビジョンですが、シールがはってないので外箱の表記からですがA5Aのようです。
yo 2013/08/04(Sun) 19:50 No.3387
Re: BeagleBone Black(5)
tinker 2013/08/04(Sun) 20:48 No.3388
yoさん
0731はmake omap2plus_defconfigでconfigを作成し、0722と見比べながら少し足したあと、不要そうなところを削除しています。
見た目もう少し削れそうなのですが、あれ以上やるとすぐ不安定になります。
こちらでは24/192を諦めてるので、cpufrequtilsで0.70Gまで落として使っています。
1.0GHzで動かすと、SDがKingMax(笑)のせいか再起動失敗とかfsckが動く確率が高いみたいです。
またcpufrequtilsをインストールしていない状況だと、0.3～1.0GHzで可変のようですが、試した印象では（topの結果から）音楽再生時は0.5～0.7GHzでしか動いていないようです。
0731はmake omap2plus_defconfigでconfigを作成し、0722と見比べながら少し足したあと、不要そうなところを削除しています。
見た目もう少し削れそうなのですが、あれ以上やるとすぐ不安定になります。
こちらでは24/192を諦めてるので、cpufrequtilsで0.70Gまで落として使っています。
1.0GHzで動かすと、SDがKingMax(笑)のせいか再起動失敗とかfsckが動く確率が高いみたいです。
またcpufrequtilsをインストールしていない状況だと、0.3～1.0GHzで可変のようですが、試した印象では（topの結果から）音楽再生時は0.5～0.7GHzでしか動いていないようです。
tinker 2013/08/04(Sun) 20:48 No.3388
Re: BeagleBone Black(5)
yo 2013/08/04(Sun) 20:57 No.3389
syuさん
> pacman -S nfs_utilsが効いたのかなあ？？
これはクライアントとしてnfsをアクセスできるようにしただけなので、関係が無いと思います。
どうもネットワーク環境の差が影響しているようですね。くるるさんが指摘されている
> ドライバが対応してないようですね。
> いまどき珍しいです。
というのが怪しいです。
ブリッジ側が100Mで正しく設定されていれば問題を起こさないということなのですかね。
僕のネットワーク環境はルータの先にブリッジ二台を直列でつなげるというかなり特殊な構成なので、それが問題なのかな。ケーブル総延長は50mを超えます。
syuさんのネットワークの構成を教えて頂けますか。
> pacman -S nfs_utilsが効いたのかなあ？？
これはクライアントとしてnfsをアクセスできるようにしただけなので、関係が無いと思います。
どうもネットワーク環境の差が影響しているようですね。くるるさんが指摘されている
> ドライバが対応してないようですね。
> いまどき珍しいです。
というのが怪しいです。
ブリッジ側が100Mで正しく設定されていれば問題を起こさないということなのですかね。
僕のネットワーク環境はルータの先にブリッジ二台を直列でつなげるというかなり特殊な構成なので、それが問題なのかな。ケーブル総延長は50mを超えます。
syuさんのネットワークの構成を教えて頂けますか。
yo 2013/08/04(Sun) 20:57 No.3389
Re: BeagleBone Black(5)
まさまさ 2013/08/04(Sun) 21:10 No.3390
tinkerさん
> 確認したいのは100<>100の2つ上がどうなっているかなんです。x00xになっていますか？
すみません、ここは見逃していました。
ということで、もう一度yoさんのimageをSDに書き込んで立ち上げてみたのですが、、、
なぜだかわからないのですが、今度はちゃんと音が出るのです。。。
そしてalsamixer のご指摘のところはx00xになっていました。
（現在は、音が出るからあたりまえですよね）
0722peでちゃんと動いたので、0728rtを試してみたところ、
192KHz/24bitのflacでご指摘のように時々ボツボツと入りますね。0722peでは出ないみたいでした。
ということで、なんとなく SD Card 書き込みで失敗していたのかもと思っております。
いろいろとお騒がせしてすみませんでした m(_ _)m
> 確認したいのは100<>100の2つ上がどうなっているかなんです。x00xになっていますか？
すみません、ここは見逃していました。
ということで、もう一度yoさんのimageをSDに書き込んで立ち上げてみたのですが、、、
なぜだかわからないのですが、今度はちゃんと音が出るのです。。。
そしてalsamixer のご指摘のところはx00xになっていました。
（現在は、音が出るからあたりまえですよね）
0722peでちゃんと動いたので、0728rtを試してみたところ、
192KHz/24bitのflacでご指摘のように時々ボツボツと入りますね。0722peでは出ないみたいでした。
ということで、なんとなく SD Card 書き込みで失敗していたのかもと思っております。
いろいろとお騒がせしてすみませんでした m(_ _)m
まさまさ 2013/08/04(Sun) 21:10 No.3390
Re: BeagleBone Black(5)
yo 2013/08/04(Sun) 21:19 No.3391
tinkerさん
cpufreqについてはSmartTVBoxで問題を起こしたことがあるので、
http://www.symphonic-net.com/kubotayo/articles/articles014.html#013" target="_blank">http://www.symphonic-net.com/kubotayo/articles/articles014.html#013
削除したら、cpu負荷が増大し、元に戻しました。
BBBはこれが前提となっているようなので、試してみますかね。
cpufreqについてはSmartTVBoxで問題を起こしたことがあるので、
http://www.symphonic-net.com/kubotayo/articles/articles014.html#013" target="_blank">http://www.symphonic-net.com/kubotayo/articles/articles014.html#013
削除したら、cpu負荷が増大し、元に戻しました。
BBBはこれが前提となっているようなので、試してみますかね。
yo 2013/08/04(Sun) 21:19 No.3391
Re: BeagleBone Black(5)
tinker 2013/08/04(Sun) 21:34 No.3392
まさまささん
>なんとなく SD Card 書き込みで失敗していたのかもと思っております。
可能性はありますね。なんにしても動いているようで良かったです。
RTで24/192は、みなさん苦労されてるみたいです。ただRTじゃなくても十分良い音だと思いますよ。
良かったら0731RTも試してみてください。
>なんとなく SD Card 書き込みで失敗していたのかもと思っております。
可能性はありますね。なんにしても動いているようで良かったです。
RTで24/192は、みなさん苦労されてるみたいです。ただRTじゃなくても十分良い音だと思いますよ。
良かったら0731RTも試してみてください。
tinker 2013/08/04(Sun) 21:34 No.3392
Re: BeagleBone Black(5)
まさまさ 2013/08/04(Sun) 22:46 No.3393
tinkerさん
今ようやっと音を聞いてますが（笑）、良いですね！
私の手持ち機器ではNotePC(Core i5 + Win7)上の JRiver Media Center 18で
X-DDC に入力した音が一番良いと思っているのですが、
いちいちPCを立ち上げるのが面倒なので、mpdの構成にしようと思い立ち、
こちらのサイトを見つけ CuBox から始めているのですが、
あともうちょっとという感じだったのですが、BBBでまた一歩近づいたなという感じがしています。
さて、それで0731RTも試してみようと思っておりまして、
> yoさんのイメージを使い、mkdir /build_files/0731rt として0731rtの中に展開してください。
この通りにBBB側で directory は用意し、chown, chgrp で同じようにdebianに設定したのですが、
https://docs.google.com/file/d/0BxnbJHx0_xurMDNoQ2tsSUdyWG8/edit?usp=sharing" target="_blank">https://docs.google.com/file/d/0BxnbJHx0_xurMDNoQ2tsSUdyWG8/edit?usp=sharing
このファイルの落とし方がわからないのです。
PC でクリックするとファイルが壊れてますと言われてしまいますし。。。
BBB 側で落として、展開するコマンドを教えていただけないでしょうか？
初心者で申し訳ないです。。。
よろしくお願い致します。
今ようやっと音を聞いてますが（笑）、良いですね！
私の手持ち機器ではNotePC(Core i5 + Win7)上の JRiver Media Center 18で
X-DDC に入力した音が一番良いと思っているのですが、
いちいちPCを立ち上げるのが面倒なので、mpdの構成にしようと思い立ち、
こちらのサイトを見つけ CuBox から始めているのですが、
あともうちょっとという感じだったのですが、BBBでまた一歩近づいたなという感じがしています。
さて、それで0731RTも試してみようと思っておりまして、
> yoさんのイメージを使い、mkdir /build_files/0731rt として0731rtの中に展開してください。
この通りにBBB側で directory は用意し、chown, chgrp で同じようにdebianに設定したのですが、
https://docs.google.com/file/d/0BxnbJHx0_xurMDNoQ2tsSUdyWG8/edit?usp=sharing" target="_blank">https://docs.google.com/file/d/0BxnbJHx0_xurMDNoQ2tsSUdyWG8/edit?usp=sharing
このファイルの落とし方がわからないのです。
PC でクリックするとファイルが壊れてますと言われてしまいますし。。。
BBB 側で落として、展開するコマンドを教えていただけないでしょうか？
初心者で申し訳ないです。。。
よろしくお願い致します。
まさまさ 2013/08/04(Sun) 22:46 No.3393
Re: BeagleBone Black(5)
tinker 2013/08/04(Sun) 23:31 No.3394
まさまささん
Google Drive詳しくないので、BBB側で落とすのはどうすればいいのか分かりません。winで落としてください。
落としたファイルは、以下の方法で可能です。
１．winで落としたBBBに0731rt.tar.gzをどうにかして持ってくる
・Linux環境があればSDをmountしてコピー
・音楽ソースをNASなどに置いているのであれば、NAS経由で持ってくる。
・WINSCPを使ってSCPで転送する などです。
２．ファイルの展開
・持ってきたファイルを/build_files/0731rtにコピーする
・/build_files/0731rtに移動して tar zxvf 0731rt.tar.gz として展開する。
・/usr/local/sbin/selbootを修正
nano /usr/local/sbin/selboot として以下の行を修正
cp $filename1 /mnt/dtbs/cpを$filename1 /boot/dtbs/ と修正
・0731rtでの切り替えは
selboot 0731rt とコマンドを打ち込んでください。
Google Drive詳しくないので、BBB側で落とすのはどうすればいいのか分かりません。winで落としてください。
落としたファイルは、以下の方法で可能です。
１．winで落としたBBBに0731rt.tar.gzをどうにかして持ってくる
・Linux環境があればSDをmountしてコピー
・音楽ソースをNASなどに置いているのであれば、NAS経由で持ってくる。
・WINSCPを使ってSCPで転送する などです。
２．ファイルの展開
・持ってきたファイルを/build_files/0731rtにコピーする
・/build_files/0731rtに移動して tar zxvf 0731rt.tar.gz として展開する。
・/usr/local/sbin/selbootを修正
nano /usr/local/sbin/selboot として以下の行を修正
cp $filename1 /mnt/dtbs/cpを$filename1 /boot/dtbs/ と修正
・0731rtでの切り替えは
selboot 0731rt とコマンドを打ち込んでください。
tinker 2013/08/04(Sun) 23:31 No.3394
Re: BeagleBone Black(5)
syu 2013/08/04(Sun) 23:33 No.3395
yoさん
まず、selbootの謎。
yoさんのimgではbootパーティションのzImageを書き換えていますが、私のbbbはそこを読みに行かないのです。rootfs側の/boot/にあるzImage、dtbを書き換えるように改変すると動作しました。(^.^)">
元：if cp $filename /mnt/
改：if cp $filename /boot/
LANの構成。
ルータ：BBR-4HG(1.46 Release 0002)
｜１m
ハ ブ：LSW4-GT-8NS/WH(G1)--------------100base 1000base 混在
｜30m |20m
ハ ブ：LSW3-GT-16NSR(D1)-多数混在 ハブ-----------------
｜1m ｜1m ｜1m ｜1m ｜1m
ubuntu-pc(1G) bbb(100) qnap212(1G) ubntu-pc(1G) mac(1G) プリンタ(100)
こんなで、結構長いです。qnap212とはcifsのままです。
まず、selbootの謎。
yoさんのimgではbootパーティションのzImageを書き換えていますが、私のbbbはそこを読みに行かないのです。rootfs側の/boot/にあるzImage、dtbを書き換えるように改変すると動作しました。(^.^)">
元：if cp $filename /mnt/
改：if cp $filename /boot/
LANの構成。
ルータ：BBR-4HG(1.46 Release 0002)
｜１m
ハ ブ：LSW4-GT-8NS/WH(G1)--------------100base 1000base 混在
｜30m |20m
ハ ブ：LSW3-GT-16NSR(D1)-多数混在 ハブ-----------------
｜1m ｜1m ｜1m ｜1m ｜1m
ubuntu-pc(1G) bbb(100) qnap212(1G) ubntu-pc(1G) mac(1G) プリンタ(100)
こんなで、結構長いです。qnap212とはcifsのままです。
syu 2013/08/04(Sun) 23:33 No.3395
Re: BeagleBone Black(5)
yo 2013/08/05(Mon) 20:43 No.3396
syuさん
/bootでしたか。ということは、emmc側のuEnv.txtが/dev/mmcblk0p2を指定していて/bootのzImageと*.dtbが有効になったということでしょうね。
ネットワークの情報ありがとうございました。構成は僕のとあまり差はなさそうですが、連続再生が可能になっているということは、何かが影響しているのでしょう。ハブを取り替えるとか試してみるつもりです。
/bootでしたか。ということは、emmc側のuEnv.txtが/dev/mmcblk0p2を指定していて/bootのzImageと*.dtbが有効になったということでしょうね。
ネットワークの情報ありがとうございました。構成は僕のとあまり差はなさそうですが、連続再生が可能になっているということは、何かが影響しているのでしょう。ハブを取り替えるとか試してみるつもりです。
yo 2013/08/05(Mon) 20:43 No.3396
Re: BeagleBone Black(5)
syu 2013/08/05(Mon) 23:52 No.3397
>emmc側のuEnv.txtが/dev/mmcblk0p2を指定
私のbbbはemmcを何度もいじっていますから、それですね。魑魅魍魎でなくてひと安心です。
yoさんの呪文が効いた(^^;;debianのrootfsとtinkerさんの0731rtの組み合わせが、安定してとても良い音ですので、これでしばらくバタバタせずに音楽を楽しめます。皆様ありがとうございました。
私のbbbはemmcを何度もいじっていますから、それですね。魑魅魍魎でなくてひと安心です。
yoさんの呪文が効いた(^^;;debianのrootfsとtinkerさんの0731rtの組み合わせが、安定してとても良い音ですので、これでしばらくバタバタせずに音楽を楽しめます。皆様ありがとうございました。
syu 2013/08/05(Mon) 23:52 No.3397
Re: BeagleBone Black(5)
まさまさ 2013/08/06(Tue) 01:20 No.3398
tinkerさん
リプライ遅くなってすみません。
Google Drive の件ですが、Windows上のブラウザではダメで、
VMPlayer上の Ubuntu のブラウザで読み込むことができました。
それでBBB上に展開した後、selboot は何も修正せずに動きました。
# cp filename1 /mnt/dtbs/
となぜか最初からコメントアウトしてありましたので、そのままにしてあります。
うーん、ホント音がいいですね♪
44.1/16 Flac を中心に聞いていますが、いつのまにか音楽に没入してます！
特にチェロなんですが、ホールの響きがCuBoxのときより良く再現できてて、かつスピード感があるので、ちょっと背中がぞくぞく来てます！
それから今気づいたのですが、0731rtで44.1/16 flacでも"ボツ"ノイズが入りました。192/24 flacと比較するとその間隔は長くて、別のノイズかと思ったのですが、0722peで聞いてみたら、その場所にはノイズは入っていないので、rt で発生するノイズかと思われます。
syuさん
bbbとqnapは同じLSW3-GT-16NSRに接続されていますので、
bbbへの音楽再生データに限って言えば、この間だけでやりとりされており、
他のハブやPCにパケットは出て行きませんので、ケーブルの取り回しが長いというのは問題にはならないと思いますよ。
リプライ遅くなってすみません。
Google Drive の件ですが、Windows上のブラウザではダメで、
VMPlayer上の Ubuntu のブラウザで読み込むことができました。
それでBBB上に展開した後、selboot は何も修正せずに動きました。
# cp filename1 /mnt/dtbs/
となぜか最初からコメントアウトしてありましたので、そのままにしてあります。
うーん、ホント音がいいですね♪
44.1/16 Flac を中心に聞いていますが、いつのまにか音楽に没入してます！
特にチェロなんですが、ホールの響きがCuBoxのときより良く再現できてて、かつスピード感があるので、ちょっと背中がぞくぞく来てます！
それから今気づいたのですが、0731rtで44.1/16 flacでも"ボツ"ノイズが入りました。192/24 flacと比較するとその間隔は長くて、別のノイズかと思ったのですが、0722peで聞いてみたら、その場所にはノイズは入っていないので、rt で発生するノイズかと思われます。
syuさん
bbbとqnapは同じLSW3-GT-16NSRに接続されていますので、
bbbへの音楽再生データに限って言えば、この間だけでやりとりされており、
他のハブやPCにパケットは出て行きませんので、ケーブルの取り回しが長いというのは問題にはならないと思いますよ。
まさまさ 2013/08/06(Tue) 01:20 No.3398
Re: BeagleBone Black(5)
yo 2013/08/06(Tue) 19:33 No.3399
まさまささん
> # cp filename1 /mnt/dtbs/
これは僕のバグです。
cp $filename1 /mnt/dtbs/
と修正して下さい。真面目に確認をとらないで、とりあえず動いたからアップロードしちゃったというミスです(^^;;;。
> ケーブルの取り回しが長いというのは問題にはならないと思いますよ。
そのようですね。nasとハブ(ルータ)の動作次第ということらしいです。いろいろ試してみましたが、僕の環境ではdsd再生の突然の中断を回避する方法は発見できませんでした。ただ、やり方によって中断がはじまる時間はコロコロ変わりますので、ネットワークのやりとりが関連していることは間違いなさそうです。まあ、基本的には同じカーネルソースとコンフィグを使って、rtだとng、peだとokという点がおかしいので、rtカーネルソースの改修を待つのが正解だと思います。
tinkerさん
cpufreqをインストールしてみましたが、これはお勧めですね。ディフォルのondemandの状態でcpu負荷も下がるし、音も良くなったような気がします(気のせいでしょうが)。
あと、0731版のコンフィグを拝見しました。よくチューニングされていますね。僕が手を出す余地は無さそうです。同じコンフィグでpe版もビルドしてみましたが、なかなかいいです。dsdやハイレソデータの再生はこっちでやるのが正解だと思います。モジュール組み込み無しになっているし、zImageとdtbだけで使えるのもいいですね。0722にこだわる必要はなくなったと思います。
という次第でアップロードしたイメージは変更版に入れ換えるつもりです。
> # cp filename1 /mnt/dtbs/
これは僕のバグです。
cp $filename1 /mnt/dtbs/
と修正して下さい。真面目に確認をとらないで、とりあえず動いたからアップロードしちゃったというミスです(^^;;;。
> ケーブルの取り回しが長いというのは問題にはならないと思いますよ。
そのようですね。nasとハブ(ルータ)の動作次第ということらしいです。いろいろ試してみましたが、僕の環境ではdsd再生の突然の中断を回避する方法は発見できませんでした。ただ、やり方によって中断がはじまる時間はコロコロ変わりますので、ネットワークのやりとりが関連していることは間違いなさそうです。まあ、基本的には同じカーネルソースとコンフィグを使って、rtだとng、peだとokという点がおかしいので、rtカーネルソースの改修を待つのが正解だと思います。
tinkerさん
cpufreqをインストールしてみましたが、これはお勧めですね。ディフォルのondemandの状態でcpu負荷も下がるし、音も良くなったような気がします(気のせいでしょうが)。
あと、0731版のコンフィグを拝見しました。よくチューニングされていますね。僕が手を出す余地は無さそうです。同じコンフィグでpe版もビルドしてみましたが、なかなかいいです。dsdやハイレソデータの再生はこっちでやるのが正解だと思います。モジュール組み込み無しになっているし、zImageとdtbだけで使えるのもいいですね。0722にこだわる必要はなくなったと思います。
という次第でアップロードしたイメージは変更版に入れ換えるつもりです。
yo 2013/08/06(Tue) 19:33 No.3399
Re: BeagleBone Black(5)
tinker 2013/08/06(Tue) 20:36 No.3400
yoさん
環境にもよると思うのですが、Debianが再起動とかselboot（selpartでも）に失敗する場合があるようなので、少し変更しました。変更後、モジュールを使うようにしました。
変更点は（関係無さそうなんですが起動に失敗しなくなりました）
・autofsのあたりをモジュールで追加
・上記変更での増加分はext2，ext3，dosあたりを積極的に使う人はいないかと思いモジュールに変更
https://docs.google.com/file/d/0BxnbJHx0_xurM3FDdGQ3R0hEbE0/edit?usp=sharing" target="_blank">https://docs.google.com/file/d/0BxnbJHx0_xurM3FDdGQ3R0hEbE0/edit?usp=sharing
御迷惑おかけますが、上記configをもとに変更して頂けると、より安全と思いますm(__)m
環境にもよると思うのですが、Debianが再起動とかselboot（selpartでも）に失敗する場合があるようなので、少し変更しました。変更後、モジュールを使うようにしました。
変更点は（関係無さそうなんですが起動に失敗しなくなりました）
・autofsのあたりをモジュールで追加
・上記変更での増加分はext2，ext3，dosあたりを積極的に使う人はいないかと思いモジュールに変更
https://docs.google.com/file/d/0BxnbJHx0_xurM3FDdGQ3R0hEbE0/edit?usp=sharing" target="_blank">https://docs.google.com/file/d/0BxnbJHx0_xurM3FDdGQ3R0hEbE0/edit?usp=sharing
御迷惑おかけますが、上記configをもとに変更して頂けると、より安全と思いますm(__)m
tinker 2013/08/06(Tue) 20:36 No.3400
Re: BeagleBone Black(5)
tinker 2013/08/06(Tue) 21:12 No.3401
yoさん
>cpufreqをインストールしてみましたが、これはお勧めですね
800Mhz or 900MHzあたりに固定するのがよさそうです。debianやArchは気のせいかなくらいの変化しかないのですが、ubuntuだと負荷が下がって、埃っぽさが消えるような気がします。
>cpufreqをインストールしてみましたが、これはお勧めですね
800Mhz or 900MHzあたりに固定するのがよさそうです。debianやArchは気のせいかなくらいの変化しかないのですが、ubuntuだと負荷が下がって、埃っぽさが消えるような気がします。
tinker 2013/08/06(Tue) 21:12 No.3401
Re: BeagleBone Black(5)
tinker 2013/08/06(Tue) 21:50 No.3402
まさまささん
私は16/44.1（Flac）のばっかり聞いてます。
BBBだと、あまり録音の良くない物もそれなりに聞けて、今まで車の中専用と思っていたソースも聞けるようになりました。
>それから今気づいたのですが、0731rtで44.1/16 flacでも"ボツ"ノイズが入りました
X-DDCの場合、24/96や24/192は厳しいのですが、こちらではX-DDCでも16/44.1は大丈夫です。
私のDACは、USB接続がclass１で、16/44.1しか聞かないのでUSBの方につないでいます。
私は16/44.1（Flac）のばっかり聞いてます。
BBBだと、あまり録音の良くない物もそれなりに聞けて、今まで車の中専用と思っていたソースも聞けるようになりました。
>それから今気づいたのですが、0731rtで44.1/16 flacでも"ボツ"ノイズが入りました
X-DDCの場合、24/96や24/192は厳しいのですが、こちらではX-DDCでも16/44.1は大丈夫です。
私のDACは、USB接続がclass１で、16/44.1しか聞かないのでUSBの方につないでいます。
tinker 2013/08/06(Tue) 21:50 No.3402
Re: BeagleBone Black(5)
yo 2013/08/07(Wed) 19:16 No.3403
皆様
アップロードしたdebianhfのイメージを差し替えでおきました。新しいアドレスは以下です。
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
古いイメージは削除してあります。よろしければ差し替えて下さい。古いイメージからの変更点は以下の通りです。
- selbootを*.dtbも入れ換えるように変更(cp $filename1 /mnt/dtbs/)
- /build_filesに0731peを追加、0722peと0728rtを削除
- cpufreqをインストール(apt-get install cpufrequtils cpufreqd)
- /etc/netconfigのv6対応のコメントアウト(rpcbind: cannot create socket for udp6)
昨日tinkerさんがアップロードされたFe_config.gzには対応していませんので、ご注意下さい。
アップロードしたdebianhfのイメージを差し替えでおきました。新しいアドレスは以下です。
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
古いイメージは削除してあります。よろしければ差し替えて下さい。古いイメージからの変更点は以下の通りです。
- selbootを*.dtbも入れ換えるように変更(cp $filename1 /mnt/dtbs/)
- /build_filesに0731peを追加、0722peと0728rtを削除
- cpufreqをインストール(apt-get install cpufrequtils cpufreqd)
- /etc/netconfigのv6対応のコメントアウト(rpcbind: cannot create socket for udp6)
昨日tinkerさんがアップロードされたFe_config.gzには対応していませんので、ご注意下さい。
yo 2013/08/07(Wed) 19:16 No.3403
Re: BeagleBone Black(5)
tinker 2013/08/07(Wed) 20:18 No.3404
yoさん
お疲れ様です。
時間かかりましたけど、なんとか形になりましたね。
次は”Cuboxをさらに良くしよう”でもやりますか(笑)
個人的には”wandboardを何とかしよう”に専念できそうです。
一つ教えてください。
irq/58-4a100000のほうは指定されていないのですが、何か新しい情報を発見されました？
お疲れ様です。
時間かかりましたけど、なんとか形になりましたね。
次は”Cuboxをさらに良くしよう”でもやりますか(笑)
個人的には”wandboardを何とかしよう”に専念できそうです。
一つ教えてください。
irq/58-4a100000のほうは指定されていないのですが、何か新しい情報を発見されました？
tinker 2013/08/07(Wed) 20:18 No.3404
Re: BeagleBone Black(5)
yo 2013/08/07(Wed) 20:51 No.3405
tinkerさん
config-fe試してみました。問題なくビルド、動作しますが、不思議なのは44KHz flacの再生でcpu負荷が1-2%大きくなること(top画面をにらめっこして、聴いています)。autofs動作の影響ですかね。音は差が無いという気がしますが、精神衛生上よくないので(^^;;;、0731を使うかなと考えています。BBBのリアルタイムカーネルを使い初めてから、cpu負荷が気になるので、top画面を見ながら音楽鑑賞するというスタイルになってしまいました。困ったものですね(^^;;;。
> BBBだと、あまり録音の良くない物もそれなりに聞けて、今まで車の中専用と思っていたソースも聞けるようになりました。
同感です。古いソースがとてもよい音でなりますね。1970年以前のアナログソースが素晴らしい音で蘇るという気がします。ただ、dsd再生はやっぱりcuboxですかね。cpu負荷中毒の身としては、10%を超えると我慢出来なくなるのですよね(^^;;;。再生が中断しなければ、BBBのrtカーネルのDSD再生の音はなかなか良いとは思いますが、preemptカーネルの音はイマイチですね。
> irq/58-4a100000のほうは指定されていないのですが、何か新しい情報を発見されました？
発見してません。あれも怪しい妖怪の一匹ですよね(^^;;;。何をしているのだろうか ???
config-fe試してみました。問題なくビルド、動作しますが、不思議なのは44KHz flacの再生でcpu負荷が1-2%大きくなること(top画面をにらめっこして、聴いています)。autofs動作の影響ですかね。音は差が無いという気がしますが、精神衛生上よくないので(^^;;;、0731を使うかなと考えています。BBBのリアルタイムカーネルを使い初めてから、cpu負荷が気になるので、top画面を見ながら音楽鑑賞するというスタイルになってしまいました。困ったものですね(^^;;;。
> BBBだと、あまり録音の良くない物もそれなりに聞けて、今まで車の中専用と思っていたソースも聞けるようになりました。
同感です。古いソースがとてもよい音でなりますね。1970年以前のアナログソースが素晴らしい音で蘇るという気がします。ただ、dsd再生はやっぱりcuboxですかね。cpu負荷中毒の身としては、10%を超えると我慢出来なくなるのですよね(^^;;;。再生が中断しなければ、BBBのrtカーネルのDSD再生の音はなかなか良いとは思いますが、preemptカーネルの音はイマイチですね。
> irq/58-4a100000のほうは指定されていないのですが、何か新しい情報を発見されました？
発見してません。あれも怪しい妖怪の一匹ですよね(^^;;;。何をしているのだろうか ???
yo 2013/08/07(Wed) 20:51 No.3405
Re: BeagleBone Black(5)
tinker 2013/08/07(Wed) 21:05 No.3406
yoさん
>不思議なのは44KHz flacの再生でcpu負荷が1-2%大きくなること
cpufrequtilsの設定で、以下のように変えると少し良くなるかもしれません。
GOVERNOR="ondemand"
MAX_SPEED="1.0GHz"
MIN_SPEED="0.9GHz"
>preemptカーネルの音はイマイチですね
普通に聞くといい音なんですけどね。一度RTの方を聞くと戻れないですよね(笑)
>不思議なのは44KHz flacの再生でcpu負荷が1-2%大きくなること
cpufrequtilsの設定で、以下のように変えると少し良くなるかもしれません。
GOVERNOR="ondemand"
MAX_SPEED="1.0GHz"
MIN_SPEED="0.9GHz"
>preemptカーネルの音はイマイチですね
普通に聞くといい音なんですけどね。一度RTの方を聞くと戻れないですよね(笑)
tinker 2013/08/07(Wed) 21:05 No.3406
Re: BeagleBone Black(5)
通りすがり 2013/08/09(Fri) 06:31 No.3407
たまたま通過したのですが・・
こちらで弄りの対象になっているのは、秋月で販売している
ものですか？
こちらで弄りの対象になっているのは、秋月で販売している
ものですか？
通りすがり 2013/08/09(Fri) 06:31 No.3407
Re: BeagleBone Black(5)
syu 2013/08/09(Fri) 19:29 No.3409
yoさんの新しいイメージ、0731rtが特に素晴らしいです。素のbone20の良さがrt化で磨き上げられ、やや不安定な点を除き、総てのフォーマットで最良ですね。記念碑的成果と言えるかも。
dsdの音消えも皆無(^^;;; うちではcuboxの時からこれが最大の問題でした。改めて梅雨入り版で聴いてみましたが、cuboxでもdsdの音消えは発生しなくなってました。てことは、原因はやはりネットワーク環境なんでしょうが、あまり変えてないんですよ。思い当たることといえば、qnapのファームアップぐらい。同じハブに別の録画用nasとスカパーチューナをぶら下げるなど、ネットワーク環境が悪化しそうなことを試しましたが、トラブル再現しません。学習効果なんてのがハブにあるのかなあ。
qnapがらみですが、昨日、ファームウエアを3.8.3-0426から4.0.2-0726に更新しました。こんなことでも音は変化するんですね。ややボディーが出て、充実。好ましい方向です。
>次は”Cuboxをさらに良くしよう”
今はbbbに差をつけられてますから、cubox頑張れ！。お役には立てませんが、是非。
dsdの音消えも皆無(^^;;; うちではcuboxの時からこれが最大の問題でした。改めて梅雨入り版で聴いてみましたが、cuboxでもdsdの音消えは発生しなくなってました。てことは、原因はやはりネットワーク環境なんでしょうが、あまり変えてないんですよ。思い当たることといえば、qnapのファームアップぐらい。同じハブに別の録画用nasとスカパーチューナをぶら下げるなど、ネットワーク環境が悪化しそうなことを試しましたが、トラブル再現しません。学習効果なんてのがハブにあるのかなあ。
qnapがらみですが、昨日、ファームウエアを3.8.3-0426から4.0.2-0726に更新しました。こんなことでも音は変化するんですね。ややボディーが出て、充実。好ましい方向です。
>次は”Cuboxをさらに良くしよう”
今はbbbに差をつけられてますから、cubox頑張れ！。お役には立てませんが、是非。
syu 2013/08/09(Fri) 19:29 No.3409
Re: BeagleBone Black(5)
yo 2013/08/09(Fri) 21:23 No.3410
syuさん
バグ潰し版のイメージ上手く動いているようでよかったです。
> dsdの音消えも皆無(^^;;; うちではcuboxの時からこれが最大の問題でした。
cuboxでも起きていたのですか。僕のところは「cuboxでは発生せず、BBBでは今回のイメージで改良されず」です。ホントに不思議な妖怪ですね。さらに凄い(?)のは、僕のところでもnexus7でssh接続し、top画面を見ながら聴いていると発生しにくくなること。要するに負荷が高い方が条件がよくなるのですよね。もう、さっぱり分からん状態です。
バグ潰し版のイメージ上手く動いているようでよかったです。
> dsdの音消えも皆無(^^;;; うちではcuboxの時からこれが最大の問題でした。
cuboxでも起きていたのですか。僕のところは「cuboxでは発生せず、BBBでは今回のイメージで改良されず」です。ホントに不思議な妖怪ですね。さらに凄い(?)のは、僕のところでもnexus7でssh接続し、top画面を見ながら聴いていると発生しにくくなること。要するに負荷が高い方が条件がよくなるのですよね。もう、さっぱり分からん状態です。
yo 2013/08/09(Fri) 21:23 No.3410
Re: BeagleBone Black(5)
fumufumu 2013/08/15(Thu) 13:25 No.3415
yoさんのイメージを使わせてもらいました。
ubuntuを導入してなかなかいい音がしていたのでいろいろ試してみようとネットを徘徊していてここにたどり着きyoさんの0731rtを試してみて格段に音が変わり毎日聞いています。
今のところ24時間連続運用でちょうど1週間たちましたが安定して動いています。
dsdの環境がないのでflac 44.1khzの環境ですがグットです。
CPU使用率も１～２％ 楽曲はNASをマウント うちの環境では特に不具合もなく快適です。
ubuntuを導入してなかなかいい音がしていたのでいろいろ試してみようとネットを徘徊していてここにたどり着きyoさんの0731rtを試してみて格段に音が変わり毎日聞いています。
今のところ24時間連続運用でちょうど1週間たちましたが安定して動いています。
dsdの環境がないのでflac 44.1khzの環境ですがグットです。
CPU使用率も１～２％ 楽曲はNASをマウント うちの環境では特に不具合もなく快適です。
fumufumu 2013/08/15(Thu) 13:25 No.3415
Re: BeagleBone Black(5)
yo 2013/08/15(Thu) 21:16 No.3417
fumufumuさん
イメージ、上手く動いているようで良かったです。wavの再生なら、BBBがベストですね。
syuさんのarck linuxもありまして、かなり音色は異なりますが、こちらもお勧めです(#3156)。
イメージ、上手く動いているようで良かったです。wavの再生なら、BBBがベストですね。
syuさんのarck linuxもありまして、かなり音色は異なりますが、こちらもお勧めです(#3156)。
yo 2013/08/15(Thu) 21:16 No.3417
Re: BeagleBone Black(5)
nakanaka 2013/08/16(Fri) 12:33 No.3418
みなさん、HiFaceのドライバインストールでは大変お世話になりました。
BeagleBoneBlack［A5A]を購入しました。私も参加させてください。
後ろ（最後尾？）を置いていかれないように頑張ってついていきます。動作報告などしかできませんが・・・ よろしくお願いします。
ｙｏさんのイメージを導入して、0731rtを使用中。非常に気に入っています。ありがとうございます。
非常にまれですが、プチノイズが入ったり、音が消えることがあります。
環境は、JAVS X-DDCplus、NASはDD-WRTにUSB接続したHDD、CIFSでMount
これで、HiFaceも使えたらいいな～と希望を持って・・・
BeagleBone Black(3)No.3226で書き込まれた手順でインストールした時は、まさまささんと同様にmpd.confの修正が必要でした。
BeagleBoneBlack［A5A]を購入しました。私も参加させてください。
後ろ（最後尾？）を置いていかれないように頑張ってついていきます。動作報告などしかできませんが・・・ よろしくお願いします。
ｙｏさんのイメージを導入して、0731rtを使用中。非常に気に入っています。ありがとうございます。
非常にまれですが、プチノイズが入ったり、音が消えることがあります。
環境は、JAVS X-DDCplus、NASはDD-WRTにUSB接続したHDD、CIFSでMount
これで、HiFaceも使えたらいいな～と希望を持って・・・
BeagleBone Black(3)No.3226で書き込まれた手順でインストールした時は、まさまささんと同様にmpd.confの修正が必要でした。
nakanaka 2013/08/16(Fri) 12:33 No.3418
Re: BeagleBone Black(5)
syu 2013/09/01(Sun) 22:53 No.3505
皆様
arch linuxでpacman -Syuは危険度が高いとtinkerさんもご指摘でしたが、今日、BBBでpacman -Syuをやったら、kernel-3.8.13-9になり、mpdも0.17.5-1になりました。
rebootすると、RTなしの3.8.13-9で起動し、mpdもなにやら野太く押しの強い音に <(^^;; rtoptなしのmpd-dsdにしていたので、mpd.confの変更なしでmpd-0.17.5-1が動いたわけです。
いつもは書き戻せば済んでいたのですが、今回はmpd-dsdが起動しません。仕方ないので、mpd-dsdを再コンパイルしてみたのですがエラー発生。
エラーメッセージはffmpeg_decoder_pluginがどうとかなので、my-configでffmpegをdisable指定したら、コンパイルできました。
rtoptなしのmpd-dsdで聴いていますが、音が割と頻繁に消えます。しばし慣らし運転してみますが、注意が必要でしたね。
arch linuxでpacman -Syuは危険度が高いとtinkerさんもご指摘でしたが、今日、BBBでpacman -Syuをやったら、kernel-3.8.13-9になり、mpdも0.17.5-1になりました。
rebootすると、RTなしの3.8.13-9で起動し、mpdもなにやら野太く押しの強い音に <(^^;; rtoptなしのmpd-dsdにしていたので、mpd.confの変更なしでmpd-0.17.5-1が動いたわけです。
いつもは書き戻せば済んでいたのですが、今回はmpd-dsdが起動しません。仕方ないので、mpd-dsdを再コンパイルしてみたのですがエラー発生。
エラーメッセージはffmpeg_decoder_pluginがどうとかなので、my-configでffmpegをdisable指定したら、コンパイルできました。
rtoptなしのmpd-dsdで聴いていますが、音が割と頻繁に消えます。しばし慣らし運転してみますが、注意が必要でしたね。
syu 2013/09/01(Sun) 22:53 No.3505
Re: BeagleBone Black(5)
tinker 2013/09/02(Mon) 19:58 No.3506
syuさん
Archってdebianでunstableを使ってるみたいなドキドキ感がありますね^^;
こちらで起こったトラブル
１．UPDATE出来なくなった（以前、syuさんが報告済み）
２．mpdがmake出来なくなった（yoさん、syuさんと同様）
３．net関係がnetctlに変更になった（最近のrootfs）
２については、yoさん，syuさんの対応の他に、PKGBUILDでは以下のようにしているようです。
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
Archってdebianでunstableを使ってるみたいなドキドキ感がありますね^^;
こちらで起こったトラブル
１．UPDATE出来なくなった（以前、syuさんが報告済み）
２．mpdがmake出来なくなった（yoさん、syuさんと同様）
３．net関係がnetctlに変更になった（最近のrootfs）
２については、yoさん，syuさんの対応の他に、PKGBUILDでは以下のようにしているようです。
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/02(Mon) 19:58 No.3506
Re: BeagleBone Black(5)
syu 2013/09/03(Tue) 19:40 No.3507
先日、bbbのarch linuxでpacman -Syuをやって失敗しましたが、この際なのでインストールをやり直してみました。
http://archlinuxarm.org/platforms/armv7/ti/beaglebone-black" target="_blank">http://archlinuxarm.org/platforms/armv7/ti/beaglebone-black
ここの [ installationタブ ] のやり方のままですが、BeagleBone-bootloader.tar.gzは新しくなっていて、tar -xvf BeagleBone-bootloader.tar.gz -C bootしたときのエラーメッセージは出なくなっています。
pacman -Syuしたあと、samba cifs-utils alsa-plugins alsa-utils alsaplayer mpd mpc ncmpc git make autoconf automake libtool pkg-config patch と、必要最低限のパッケージを入れました。
yoさんの記事を見ながら、bbb上でmpd-0.17.5-dsdにrtoptを適用して作成。
rtsetはsystemdを使うことにし、これも簡略化。cifsdとmpdも指定に含めました。
[root@arch-mpd ~]# nano /etc/systemd/system/rtset.service
[Unit]
Description=rtset
Requires=network.target
After=network.target
Requires=mpd.service
After=mpd.service
[Service]
Type=forking
ExecStart=/usr/local/sbin/rtset
[Install]
WantedBy=multi-user.target
[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`
chrt -f -p 53 `pgrep mpd`
cifsdやmpdの指定が必要かどうかよくわかりませんが、一応指定してみました。このタイミングなら4つとも指定できます。副作用は、今のところ、ないようです。topの上位4つが固定されてしまいますので、topを眺めながら聴くときに、根拠のない安心感はあります。
dsd再生中のcpu%は、従来は時間とともに徐々に増加する傾向があり、syが18-20%程度まで増えていましたが、今回は時間が経っても増えません。dsdリピート再生、昼間の6時間越え、達成しました ^.^
[root@arch-mpd yan]# uname -a
Linux arch-mpd 3.8.13-rt9_Fe-00899-g46930b7 #1 SMP PREEMPT Wed Aug 7 01:47:34 JST 2013 armv7l GNU/Linux
[root@arch-mpd ~]# top
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
音は全く消えないかというと、特定の音源だけですが、まだ消えます。
mpd-0.17.4-rtoptではe-onkyoの2Lレーベルの曲終端でノイズが出ていましたが、mpd-0.17.5-dsd-rtoptではこのノイズは出ません。代わりに、再生継続のまま無音が続きます。曲の途中で音が消えるわけではないので、実害は減りました。
この現象は、0.18gitでyanさんのパッチ（mpd-rtopt-20130203.diffとmpd-dsdbugfix-20130203.diff）を当てたときに経験したものと同じです。おそらくmpd-dsdで、このパッチと同等の修正が加わったのだろうと思います。
で、教えていただきたいのは、systemdのシステムファイルの書き方です。これで動いてはいますが、全く自信がありません。改善点など、ご指摘よろしく。
追記
副作用らしきものがありました。shutdownの途中で、時間が異様にかかる部分があります。
A stop job is running for /root/music と Unmounting /root/music. の２ヶ所です。ファイルに何か書き加える必要があるようです。
http://archlinuxarm.org/platforms/armv7/ti/beaglebone-black" target="_blank">http://archlinuxarm.org/platforms/armv7/ti/beaglebone-black
ここの [ installationタブ ] のやり方のままですが、BeagleBone-bootloader.tar.gzは新しくなっていて、tar -xvf BeagleBone-bootloader.tar.gz -C bootしたときのエラーメッセージは出なくなっています。
pacman -Syuしたあと、samba cifs-utils alsa-plugins alsa-utils alsaplayer mpd mpc ncmpc git make autoconf automake libtool pkg-config patch と、必要最低限のパッケージを入れました。
yoさんの記事を見ながら、bbb上でmpd-0.17.5-dsdにrtoptを適用して作成。
rtsetはsystemdを使うことにし、これも簡略化。cifsdとmpdも指定に含めました。
[root@arch-mpd ~]# nano /etc/systemd/system/rtset.service
[Unit]
Description=rtset
Requires=network.target
After=network.target
Requires=mpd.service
After=mpd.service
[Service]
Type=forking
ExecStart=/usr/local/sbin/rtset
[Install]
WantedBy=multi-user.target
[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`
chrt -f -p 53 `pgrep mpd`
cifsdやmpdの指定が必要かどうかよくわかりませんが、一応指定してみました。このタイミングなら4つとも指定できます。副作用は、今のところ、ないようです。topの上位4つが固定されてしまいますので、topを眺めながら聴くときに、根拠のない安心感はあります。
dsd再生中のcpu%は、従来は時間とともに徐々に増加する傾向があり、syが18-20%程度まで増えていましたが、今回は時間が経っても増えません。dsdリピート再生、昼間の6時間越え、達成しました ^.^
[root@arch-mpd yan]# uname -a
Linux arch-mpd 3.8.13-rt9_Fe-00899-g46930b7 #1 SMP PREEMPT Wed Aug 7 01:47:34 JST 2013 armv7l GNU/Linux
[root@arch-mpd ~]# top
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
音は全く消えないかというと、特定の音源だけですが、まだ消えます。
mpd-0.17.4-rtoptではe-onkyoの2Lレーベルの曲終端でノイズが出ていましたが、mpd-0.17.5-dsd-rtoptではこのノイズは出ません。代わりに、再生継続のまま無音が続きます。曲の途中で音が消えるわけではないので、実害は減りました。
この現象は、0.18gitでyanさんのパッチ（mpd-rtopt-20130203.diffとmpd-dsdbugfix-20130203.diff）を当てたときに経験したものと同じです。おそらくmpd-dsdで、このパッチと同等の修正が加わったのだろうと思います。
で、教えていただきたいのは、systemdのシステムファイルの書き方です。これで動いてはいますが、全く自信がありません。改善点など、ご指摘よろしく。
追記
副作用らしきものがありました。shutdownの途中で、時間が異様にかかる部分があります。
A stop job is running for /root/music と Unmounting /root/music. の２ヶ所です。ファイルに何か書き加える必要があるようです。
syu 2013/09/03(Tue) 19:40 No.3507
Re: BeagleBone Black(5)
yo 2013/09/03(Tue) 21:59 No.3508
このスレッドも長くなったので新しいスレッドに移行しましょう。タイトルは「BeagleBone Black(6)」です。
yo 2013/09/03(Tue) 21:59 No.3508
kernel3.8/10と最新rtパッチでトラブル
twlさん、tinkerさん
お二人のやりとりを拝見して、久しぶりにcuboxのカーネルビルドをやってみました。BBBがトラブルだらけだったもので、見落としていましたが、この件、BBBでfull-rtが指定出来ない件と関連していたのですね。もしかすると、dsd再生が途中で止まるのも関係ありかもしれませんね。
3.10.6+rt3ですが、僕の環境でもfull-rtで動きました。configは梅雨入り版の3.8用にcgroupを設定したものを使いました。手順はこの記事通りです。
http://www.symphonic-net.com/kubotayo/articles/articles014.html#007" target="_blank">http://www.symphonic-net.com/kubotayo/articles/articles014.html#007
これはいけるかなと思い使いはじめましたが、僕の環境ではmpdがハングしますね。wav(flac)、dsd(dff)の両方で発生します。使ったddcはuda3です。ハングする時間はwavだと10分～30分位。dsdは数分～10分位です。dsdハングの場合は「cannot submit urb (err = -18)」というメッセージがシリアルに出力されますが、wav再生では何も出ません。データはnfsのnasに置いてあります。
まだ確認を開始したばかりでnas環境の変更などはまだ試していません。とりあえずのご報告です。
こっちもトラブル。ウームですねぇ。
mpdのサイズの件は興味深いですね。調べてから書き込みます。0.17.5でしょうか ?
Re: kernel3.8/10と最新rtパッチでトラブル
fHiro 2013/08/23(Fri) 02:39 No.3442
twlさん、みなさん
3.10.6+rt3のcuboxのカーネルビルド、3.8.13+rtで使用していた.configを使ってmake oldconfigでエラー無しで1発でビルドできました、3.10.4の時とはえらい違いです、情報ありがとうございました。
とりあえずMuboxの方に入れて1時間ほど連続再生させていますが、今のところは不具合は起きていません。
とは言え、例の"cannot submit urb(-18)"のエラーは、最低でも丸一日はテストしないとダメなので、まだわかりません。
ただ、自分の環境ではnasをcifsからnfsに変えてからは比較的早く現象が起こるようになったので検証しやすくなっています。
3.10.6+rt3のcuboxのカーネルビルド、3.8.13+rtで使用していた.configを使ってmake oldconfigでエラー無しで1発でビルドできました、3.10.4の時とはえらい違いです、情報ありがとうございました。
とりあえずMuboxの方に入れて1時間ほど連続再生させていますが、今のところは不具合は起きていません。
とは言え、例の"cannot submit urb(-18)"のエラーは、最低でも丸一日はテストしないとダメなので、まだわかりません。
ただ、自分の環境ではnasをcifsからnfsに変えてからは比較的早く現象が起こるようになったので検証しやすくなっています。
fHiro 2013/08/23(Fri) 02:39 No.3442
Re: kernel3.8/10と最新rtパッチでトラブル
tinker 2013/08/23(Fri) 06:52 No.3443
おはようございます。
3.10.9+rt5がリリースされているみたいです。
先のpatchも3.10.8でマージされていますので、urbのエラーは収まると思います。
私も夜に試してみます。
3.10.9+rt5がリリースされているみたいです。
先のpatchも3.10.8でマージされていますので、urbのエラーは収まると思います。
私も夜に試してみます。
tinker 2013/08/23(Fri) 06:52 No.3443
Re: kernel3.8/10と最新rtパッチでトラブル
yo 2013/08/23(Fri) 21:44 No.3445
tinkerさんの情報に助けられ、3.10.9+rt5 を試してみました。状況は改善されましたが、問題点は残っています。
結論を書くと、僕の環境では、cuboxの3.10.9+rt5はBBBの3.8-rt(カーネルのレベルは3.8.13)とほぼ同じ状況となりました。BBBのdsd再生に問題がある(再生が中断する)という件はBBB特有の問題だと思っていましたが、間違いで、最新のrtカーネルで発生するようになったものだということです。
44.1/48KHzのwav(flac)ファイルは問題なく再生でき(只今確認中です、1hはok)、dsd再生は突然再生が中断します。dsd再生中断時にurb (err = -18)は発生せず、mpdもハングしません。dsd再生中断後、再開すると何事もなかったように再生再開できます。cuboxとBBBの違いはfull-rtで動くことができるかどうかだけです。
興味深いのは再生時のcpu負荷がどちらのrtカーネルでも大きくなっていることです。cuboxの場合、古いrtカーネルであればwavで1%～3%、dsdで4%～6%位だったのですが、新しいrtカーネルではそれぞれ4%～7%、8%～12%と倍増します(BBBのnone-rtカーネルとrtカーネルでも同じ)。またdsd再生時にはcpu負荷えらく不安定になることがあって、50%を超えることがあります。
他にも、nasを切り替えてみて、説明のつかない現象を観察しましたが、もう少し整理してから書きます。
結論を書くと、僕の環境では、cuboxの3.10.9+rt5はBBBの3.8-rt(カーネルのレベルは3.8.13)とほぼ同じ状況となりました。BBBのdsd再生に問題がある(再生が中断する)という件はBBB特有の問題だと思っていましたが、間違いで、最新のrtカーネルで発生するようになったものだということです。
44.1/48KHzのwav(flac)ファイルは問題なく再生でき(只今確認中です、1hはok)、dsd再生は突然再生が中断します。dsd再生中断時にurb (err = -18)は発生せず、mpdもハングしません。dsd再生中断後、再開すると何事もなかったように再生再開できます。cuboxとBBBの違いはfull-rtで動くことができるかどうかだけです。
興味深いのは再生時のcpu負荷がどちらのrtカーネルでも大きくなっていることです。cuboxの場合、古いrtカーネルであればwavで1%～3%、dsdで4%～6%位だったのですが、新しいrtカーネルではそれぞれ4%～7%、8%～12%と倍増します(BBBのnone-rtカーネルとrtカーネルでも同じ)。またdsd再生時にはcpu負荷えらく不安定になることがあって、50%を超えることがあります。
他にも、nasを切り替えてみて、説明のつかない現象を観察しましたが、もう少し整理してから書きます。
yo 2013/08/23(Fri) 21:44 No.3445
Re: kernel3.8/10と最新rtパッチでトラブル
twl 2013/08/23(Fri) 22:33 No.3447
tinkerさんからの情報で私も早速3.10.9-rt5をビルド、ついでにmpdも0.17.5に新装(non-rt)、かれこれ２時間ぐらいCuBoxで様子をみています。
URB関連のエラーの有無を見るにはもう少し時間が必要ですが、yoさんの状況とは異なり、現在までNAS経由(CIFS)の音楽ファイルの再生にはまったく問題ありません。DSD128, DSD64, PCMいずれも音質については従来通り高品位な再生音です。
BBBではpreemptのカーネル(3.8.13-bone26)でしかmpdを動かしていないので参考にはならないと思われますが、BBBでのDSD128/64の再生についてもこれまで中断その他の問題は経験しておりません。
twl
URB関連のエラーの有無を見るにはもう少し時間が必要ですが、yoさんの状況とは異なり、現在までNAS経由(CIFS)の音楽ファイルの再生にはまったく問題ありません。DSD128, DSD64, PCMいずれも音質については従来通り高品位な再生音です。
BBBではpreemptのカーネル(3.8.13-bone26)でしかmpdを動かしていないので参考にはならないと思われますが、BBBでのDSD128/64の再生についてもこれまで中断その他の問題は経験しておりません。
twl
twl 2013/08/23(Fri) 22:33 No.3447
Re: kernel3.8/10と最新rtパッチでトラブル
tinker 2013/08/24(Sat) 00:46 No.3449
yoさん
flac24/192で、yoさんが書かれている音切れが発生しました。
twlさんのところでは発生していないことから、rtオプション無しのmpd（0.17.5）で再生したところ、上記音切れは発生しないようです。
mpdだけの問題ではないのでしょうが、この辺から攻めていくしかないかもしれません。
思いつく対策は、
・rt無しのmpdを使用する（効果あり）
・rt有りのmpdを使用し、chrt -f -p 53 `pgrep mpd`と設定する（未検証）
・rt有りのmpdを使用し、mpd.conf内のpriorityを見直す（未検証）
flac24/192で、yoさんが書かれている音切れが発生しました。
twlさんのところでは発生していないことから、rtオプション無しのmpd（0.17.5）で再生したところ、上記音切れは発生しないようです。
mpdだけの問題ではないのでしょうが、この辺から攻めていくしかないかもしれません。
思いつく対策は、
・rt無しのmpdを使用する（効果あり）
・rt有りのmpdを使用し、chrt -f -p 53 `pgrep mpd`と設定する（未検証）
・rt有りのmpdを使用し、mpd.conf内のpriorityを見直す（未検証）
tinker 2013/08/24(Sat) 00:46 No.3449
Re: kernel3.8/10と最新rtパッチでトラブル
fHiro 2013/08/24(Sat) 02:26 No.3450
tinkerさん
3.10.9-rt5情報ありがとうございます、3.10.6-rt3は、やはり数時間でurbエラーが出ていたので、早速3.10.9-rt5をビルドしてみました。.configは3.10.6-rt3で作ったやつでいけました。今回はurbエラーも修正されている可能性が高いとのことなので、期待しつつテストしてみます。
また、現状自分の環境では3.8.xと比べて特にcpu負荷が高くなってはいないようです。
3.10.9-rt5情報ありがとうございます、3.10.6-rt3は、やはり数時間でurbエラーが出ていたので、早速3.10.9-rt5をビルドしてみました。.configは3.10.6-rt3で作ったやつでいけました。今回はurbエラーも修正されている可能性が高いとのことなので、期待しつつテストしてみます。
また、現状自分の環境では3.8.xと比べて特にcpu負荷が高くなってはいないようです。
fHiro 2013/08/24(Sat) 02:26 No.3450
Re: kernel3.8/10と最新rtパッチでトラブル
yo 2013/08/24(Sat) 13:15 No.3452
tinkerさん
アドバイスありがとうございます。さすがの難問もようやく解決したようです。二つのトラブルが同時に絡み合って発生したため幻惑されたというということですかね。
一つ目のトラブルは最新のrtカーネルでwav又はdsdを再生中にmpdハングアップが発生するというもの。urbエラーが出力されるものはこのトラブルです。この問題は3.10.9+rt5で解決されたようですね。
もう一つのトラブルは最新のrtカーネルで何らかの仕様変更があり、yanさんのrtoptパッチが対応出来ていないため、dsd再生が中断することがあるというもの。こちらは、当面、tinkerさんが提示された解決方法か古いrtカーネルを使うという方法で回避するしかないようです。
こちらはsyuさんのスレッドで話題になっているようにnasとネットワークをチューニングして解決するという手も有るようですね。
BBBからはじまって、悪戦苦闘しましたが、ようやく光が見えてきたようです。
アドバイスありがとうございます。さすがの難問もようやく解決したようです。二つのトラブルが同時に絡み合って発生したため幻惑されたというということですかね。
一つ目のトラブルは最新のrtカーネルでwav又はdsdを再生中にmpdハングアップが発生するというもの。urbエラーが出力されるものはこのトラブルです。この問題は3.10.9+rt5で解決されたようですね。
もう一つのトラブルは最新のrtカーネルで何らかの仕様変更があり、yanさんのrtoptパッチが対応出来ていないため、dsd再生が中断することがあるというもの。こちらは、当面、tinkerさんが提示された解決方法か古いrtカーネルを使うという方法で回避するしかないようです。
こちらはsyuさんのスレッドで話題になっているようにnasとネットワークをチューニングして解決するという手も有るようですね。
BBBからはじまって、悪戦苦闘しましたが、ようやく光が見えてきたようです。
yo 2013/08/24(Sat) 13:15 No.3452
Re: kernel3.8/10と最新rtパッチでトラブル
tinker 2013/08/24(Sat) 13:48 No.3454
yoさん
wandboardの場合、rtにできるVerが3.10.xしかないので必死(笑)で調べたのですが、USBのhigh speedの方にはいろいろ問題があるみたいですね。
こんなpatchもあるみたいで、先に紹介したpatchを当てる前に使っていました。
https://launchpadlibrarian.net/140553725/ehci-split-bugs" target="_blank">https://launchpadlibrarian.net/140553725/ehci-split-bugs
>rt有りのmpdを使用し、mpd.conf内のpriorityを見直す（未検証）
どのくらいが適切なのか分からないので、全体を-5したものと-10したもので試してみました。
-10だと試した時間内では音切れは出ませんでした。ただ何というか。。。息苦しさ？抑圧感？みたいな感じがあって、あまり好きになれないです。当然、環境によって異なるとは思いますが。
今回の成果はBBBの方にも反映できそうですね。
現在、3.10.8でマージされたpatchを当て、個人的に不要になった部分（swap、nfs）を削ったものを動かしています。
DSDの検証は出来ないので、yoさんが時間取れるときにでも、同様の仕様で検証をして頂ければと思います。
wandboardの場合、rtにできるVerが3.10.xしかないので必死(笑)で調べたのですが、USBのhigh speedの方にはいろいろ問題があるみたいですね。
こんなpatchもあるみたいで、先に紹介したpatchを当てる前に使っていました。
https://launchpadlibrarian.net/140553725/ehci-split-bugs" target="_blank">https://launchpadlibrarian.net/140553725/ehci-split-bugs
>rt有りのmpdを使用し、mpd.conf内のpriorityを見直す（未検証）
どのくらいが適切なのか分からないので、全体を-5したものと-10したもので試してみました。
-10だと試した時間内では音切れは出ませんでした。ただ何というか。。。息苦しさ？抑圧感？みたいな感じがあって、あまり好きになれないです。当然、環境によって異なるとは思いますが。
今回の成果はBBBの方にも反映できそうですね。
現在、3.10.8でマージされたpatchを当て、個人的に不要になった部分（swap、nfs）を削ったものを動かしています。
DSDの検証は出来ないので、yoさんが時間取れるときにでも、同様の仕様で検証をして頂ければと思います。
tinker 2013/08/24(Sat) 13:48 No.3454
Re: kernel3.8/10と最新rtパッチでトラブル
yo 2013/08/24(Sat) 17:17 No.3461
tinkerさん
> 現在、3.10.8でマージされたpatchを当て、個人的に不要になった部分（swap、nfs）を削ったものを動かしています。
これはNelson版の3.10.xを使い、対応するrtパッチをあてたという意味ですか。
実は古いカーネルに戻せば何とかなるかなと考え、Nelson版の3.6.x(xは11なので対応するrtパッチはあります)を使って試そうとしているところです。
> 現在、3.10.8でマージされたpatchを当て、個人的に不要になった部分（swap、nfs）を削ったものを動かしています。
これはNelson版の3.10.xを使い、対応するrtパッチをあてたという意味ですか。
実は古いカーネルに戻せば何とかなるかなと考え、Nelson版の3.6.x(xは11なので対応するrtパッチはあります)を使って試そうとしているところです。
yo 2013/08/24(Sat) 17:17 No.3461
Re: kernel3.8/10と最新rtパッチでトラブル
tinker 2013/08/24(Sat) 17:33 No.3464
yoさん
>これはNelson版の3.10.xを使い、対応するrtパッチをあてたという意味ですか。
BBBの3.8-rtに当てました。patchは3.8以上（もしかすると3.6でも使えるかも）で使えます。
twlさんが使われているmpd-dsdを試しています。本家の0.17.5より爽やかな感じです。
>これはNelson版の3.10.xを使い、対応するrtパッチをあてたという意味ですか。
BBBの3.8-rtに当てました。patchは3.8以上（もしかすると3.6でも使えるかも）で使えます。
twlさんが使われているmpd-dsdを試しています。本家の0.17.5より爽やかな感じです。
tinker 2013/08/24(Sat) 17:33 No.3464
Re: kernel3.8/10と最新rtパッチでトラブル
fHIro 2013/08/25(Sun) 00:03 No.3467
皆さん
3.10.9+rt5で24時間以上テストを続けましたが、urbエラーは起こりませんでした。
nfsにしてからはほぼ数時間でNGだったのを考えると私の環境ではもう起こらないでしょう。
音質は少なくとも3.8.X系に劣っていることは無いと思うので、3.8.11から移行いたします。
自分の環境を一応載せておきます。
MuboxないしArch linuxでmpd0.17.4の安定版+yanさんのrtパッチ
Javs X-DDC使用
ソースはalacが大半、全てPCMです(DSD環境はありません)
NAS(ReadyNas Ultra)をGigabit hub経由で有線接続、nfsでrsize=8192にしています。
3.10.9+rt5で24時間以上テストを続けましたが、urbエラーは起こりませんでした。
nfsにしてからはほぼ数時間でNGだったのを考えると私の環境ではもう起こらないでしょう。
音質は少なくとも3.8.X系に劣っていることは無いと思うので、3.8.11から移行いたします。
自分の環境を一応載せておきます。
MuboxないしArch linuxでmpd0.17.4の安定版+yanさんのrtパッチ
Javs X-DDC使用
ソースはalacが大半、全てPCMです(DSD環境はありません)
NAS(ReadyNas Ultra)をGigabit hub経由で有線接続、nfsでrsize=8192にしています。
fHIro 2013/08/25(Sun) 00:03 No.3467
Re: kernel3.8/10と最新rtパッチでトラブル
tinker 2013/08/25(Sun) 09:40 No.3468
fHIroさん
NFSでも大丈夫そうですね。
>NAS(ReadyNas Ultra)をGigabit hub経由で有線接続
ReadyNasはNFS4ですか？
私が使っているQNAP TS-212はNFS3で、Arch Linuxだとなんか設定しないといけないみたいで、面倒なので最近cifsを使っています。
ただArch Linuxはほとんど使ってなくて、定期的にUPDATEだけ動かしています（なかなか馴染めないです）
NFSでも大丈夫そうですね。
>NAS(ReadyNas Ultra)をGigabit hub経由で有線接続
ReadyNasはNFS4ですか？
私が使っているQNAP TS-212はNFS3で、Arch Linuxだとなんか設定しないといけないみたいで、面倒なので最近cifsを使っています。
ただArch Linuxはほとんど使ってなくて、定期的にUPDATEだけ動かしています（なかなか馴染めないです）
tinker 2013/08/25(Sun) 09:40 No.3468
Re: kernel3.8/10と最新rtパッチでトラブル
syu 2013/08/25(Sun) 11:14 No.3470
tinkerさん
別スレッドの話題ですが、
>QNAP TS-212はNFS3で、Arch Linuxだとなんか設定しないといけない
あら、そうなんですか。わたしはcifsとnfs、両方設定したらnfsが接続できなくなると誤認していました。archからはnfs4でなくnfs3で接続しなきゃいけなかったんですね。
スレ違い、ご容赦。
別スレッドの話題ですが、
>QNAP TS-212はNFS3で、Arch Linuxだとなんか設定しないといけない
あら、そうなんですか。わたしはcifsとnfs、両方設定したらnfsが接続できなくなると誤認していました。archからはnfs4でなくnfs3で接続しなきゃいけなかったんですね。
スレ違い、ご容赦。
syu 2013/08/25(Sun) 11:14 No.3470
Re: kernel3.8/10と最新rtパッチでトラブル
fHiro 2013/08/25(Sun) 19:30 No.3472
tinkerさん
Readynas ultraですが、NFS3のようです。マニュアルでもそうですし、nfsstat -mで見ても、vers=3でした。
nas側設定はNFSを有効にする以外は割り当てるスレッド数のみです。arch側はnfs関連に加えてrpcbindサービスを入れたと思います。(確かarch wikiを見てやりました)
今回バージョン確認でnfsstat -mを見て気づいたんですが、プロトコルがtcpになっていました。
udpの方が軽そうなので/etc/fstabで試しに明示的にudpを指定してみたところ、マウント不可でした。
Readynas ultraですが、NFS3のようです。マニュアルでもそうですし、nfsstat -mで見ても、vers=3でした。
nas側設定はNFSを有効にする以外は割り当てるスレッド数のみです。arch側はnfs関連に加えてrpcbindサービスを入れたと思います。(確かarch wikiを見てやりました)
今回バージョン確認でnfsstat -mを見て気づいたんですが、プロトコルがtcpになっていました。
udpの方が軽そうなので/etc/fstabで試しに明示的にudpを指定してみたところ、マウント不可でした。
fHiro 2013/08/25(Sun) 19:30 No.3472
Re: kernel3.8/10と最新rtパッチでトラブル
yo 2013/08/25(Sun) 20:24 No.3473
tinkerさん
BBBの3.8-rtにdrivers/usb/host/ehci-sched.cのパッチをあて、mpdをmpd-dsdに入れ換えBBBで試してみました。カーネルビルドのコンフィグはtinkerさんのfeを使いました。
これで全て解決と期待して試したのですが、BBBはそんなに甘くないですね(^^;;;。見事に失敗、dsd再生の中断、mpd(カーネル)のハング、両方とも発生します。nas、dffファイルなどは全く同じ条件で(nfsです)、cubox 3.10.9+rt5でmpd-dsdに入れ換え試したら、こちらは全く問題なし。見事に再生できます。
面白いのは、例によってnexus7でcpu負荷状況をモニターしながら聴いたのですが、cuboxは問題が起こる以前の3%～6%位の負荷状況なのに、BBBは以前と同じく10%以上のcpu負荷となること。多分これが諸悪の頑強だと思います。何が原因でこうなるのかが分からないのですが。
ということで、BBBに関しては振出に戻るです。ウームだなぁ(^^;;;。
仰るように、mpd-dsdは素晴らしく音がいいですね。音の透明感が最高、とてもリアルです。これはお勧めですね。これでyanさんのパッチがかけられれば、鬼に金棒なのだけど。
BBBの3.8-rtにdrivers/usb/host/ehci-sched.cのパッチをあて、mpdをmpd-dsdに入れ換えBBBで試してみました。カーネルビルドのコンフィグはtinkerさんのfeを使いました。
これで全て解決と期待して試したのですが、BBBはそんなに甘くないですね(^^;;;。見事に失敗、dsd再生の中断、mpd(カーネル)のハング、両方とも発生します。nas、dffファイルなどは全く同じ条件で(nfsです)、cubox 3.10.9+rt5でmpd-dsdに入れ換え試したら、こちらは全く問題なし。見事に再生できます。
面白いのは、例によってnexus7でcpu負荷状況をモニターしながら聴いたのですが、cuboxは問題が起こる以前の3%～6%位の負荷状況なのに、BBBは以前と同じく10%以上のcpu負荷となること。多分これが諸悪の頑強だと思います。何が原因でこうなるのかが分からないのですが。
ということで、BBBに関しては振出に戻るです。ウームだなぁ(^^;;;。
仰るように、mpd-dsdは素晴らしく音がいいですね。音の透明感が最高、とてもリアルです。これはお勧めですね。これでyanさんのパッチがかけられれば、鬼に金棒なのだけど。
yo 2013/08/25(Sun) 20:24 No.3473
Re: kernel3.8/10と最新rtパッチでトラブル
tinker 2013/08/25(Sun) 20:53 No.3475
fHiroさん
ReadynasもNFS3なんですね。
Archってこまめに見てないと、突然、設定が大幅に変更されるんですよね。
面倒くさがりなんで、もう全部Debianでいいよ～って感じに最近なってきています^^;
ReadynasもNFS3なんですね。
Archってこまめに見てないと、突然、設定が大幅に変更されるんですよね。
面倒くさがりなんで、もう全部Debianでいいよ～って感じに最近なってきています^^;
tinker 2013/08/25(Sun) 20:53 No.3475
Re: kernel3.8/10と最新rtパッチでトラブル
tinker 2013/08/25(Sun) 21:02 No.3476
yoさん
検証ありがとうございます。
やっぱりBBBは手強いですね。
こちらは16/44.1専用って割りきってメインで使ってます。
wandboardもだいぶ良くなりましたが、まだまだBBBのほうが良いです。
検証ありがとうございます。
やっぱりBBBは手強いですね。
こちらは16/44.1専用って割りきってメインで使ってます。
wandboardもだいぶ良くなりましたが、まだまだBBBのほうが良いです。
tinker 2013/08/25(Sun) 21:02 No.3476
Re: kernel3.8/10と最新rtパッチでトラブル
fHiro 2013/08/31(Sat) 16:24 No.3497
3.10.10-rt7が出ていたので、cuboxに入れてみました。3.10.9-rt5で使った.conifgを使ってmake oldconfigで特に追加も無くビルドも滞りなく完了。とりあえずMuboxに入れましたがurbエラーが復活する事も無く、正常稼動しています。
urbエラーの出ないrtカーネルだと、nfsで基本OKなんですが、rsizeを65536にするとたまにノイズが乗るので8192にしています。
urbエラーの出るカーネルだと、65536は数分しか持たずに止まります、1024だとかなり粘る感じ(数時間程度)
いずれもPCM(44.1kh)の場合です。
urbエラーの出ないrtカーネルだと、nfsで基本OKなんですが、rsizeを65536にするとたまにノイズが乗るので8192にしています。
urbエラーの出るカーネルだと、65536は数分しか持たずに止まります、1024だとかなり粘る感じ(数時間程度)
いずれもPCM(44.1kh)の場合です。
fHiro 2013/08/31(Sat) 16:24 No.3497
3.11 kernel for BBB
twlです。
3.11.0のkernelがgithub.com/RobertCNelson/linux-dev経由でビルド可能な状態となっているので、先日からこの新しいカーネルをBBBで試しています。
3.11.0-rc6および3.11.0-rc7のカーネルビルドを行いましたが。ビルド自体には問題はありませんでした。いずれもBBB自体は素直に起動しますが、USB関連のものがものがまったく認識されず、接続しているUSB DDCもsoundcardとして認識されず、mpdが動きません。
rc6およびrc7とも、dmesgでは以下のエラーが出現します。
[ 4.006964] usbcore: registered new interface driver usbtest
[ 4.013750] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
[ 4.022085] platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral
.configでもUSB関連はしっかり設定しているつもりですが、何回試しても上記のエラーが記録されます。問題解決のためのお知恵を皆様から拝借したいと考えております。どうかよろしくお願いいたします。
twl
Re: 3.11 kernel for BBB
tinker 2013/08/29(Thu) 22:04 No.3491
twlさん
Nelsonさんのところのコメントを見ると壊れてるみたいですね。
Correct usb is broken on the v3.11-rcX branch. The drivers/bindings/etc are still being discussed last week on linux-omap
Nelsonさんのところのコメントを見ると壊れてるみたいですね。
Correct usb is broken on the v3.11-rcX branch. The drivers/bindings/etc are still being discussed last week on linux-omap
tinker 2013/08/29(Thu) 22:04 No.3491
Re: 3.11 kernel for BBB
twl 2013/08/29(Thu) 23:37 No.3492
tinkerさん、早速の情報ありがとうございました。
そうですか、それでは3.11のビルドもUSBの件が落着するまで、気長に待つしかなさそうですね。
twl
そうですか、それでは3.11のビルドもUSBの件が落着するまで、気長に待つしかなさそうですね。
twl
twl 2013/08/29(Thu) 23:37 No.3492
Mpd rt patch
Hello
i have this problem with ubuntu e arch...patch mpd-0.17git-20120226rtopt.diff
http://imgur.com/j83oOlk" target="_blank">http://imgur.com/j83oOlk
where i can download last patch mpd-rtopt-20130203.diff?
this is offline
http://a-mne-idz.narod2.ru/voyage/mpd-rtopt-20130203.diff" target="_blank">http://a-mne-idz.narod2.ru/voyage/mpd-rtopt-20130203.diff
Thanks
Re: Mpd rt patch
yo 2013/08/27(Tue) 21:30 No.3485
Hi Mxx.
You can get it from this link(Click doesn't work. Please copy&paste following line directly in your Brouser).
https://skydrive.live.com/?cid=CE384832F08DA832&id=CE384832F08DA832" target="_blank">https://skydrive.live.com/?cid=CE384832F08DA832&id=CE384832F08DA832!105
Original message by yan(auther of rtopt patch) is here.
http://www.symphonic-net.com/kubotayo/cgi-bin/read.cgi?mode=all&list=topic&no=2297#2323" target="_blank">http://www.symphonic-net.com/kubotayo/cgi-bin/read.cgi?mode=all&list=topic&no=2297#2323
You can get it from this link(Click doesn't work. Please copy&paste following line directly in your Brouser).
https://skydrive.live.com/?cid=CE384832F08DA832&id=CE384832F08DA832" target="_blank">https://skydrive.live.com/?cid=CE384832F08DA832&id=CE384832F08DA832!105
Original message by yan(auther of rtopt patch) is here.
http://www.symphonic-net.com/kubotayo/cgi-bin/read.cgi?mode=all&list=topic&no=2297#2323" target="_blank">http://www.symphonic-net.com/kubotayo/cgi-bin/read.cgi?mode=all&list=topic&no=2297#2323
yo 2013/08/27(Tue) 21:30 No.3485
arch linux kernel 3.8.13 + rt12 patchで問題解決
kojiです。
CuBoxのarch linux上でkernel3.8.13+rtパッチだと、当方の環境でエラーが出ていました。（そのため3.8.10+rtで使っていました）
エラーの内容は、何曲か演奏するとcannot submit urb (err = -18)が出て、mpdが停止するというものでした。
その後、先週末にリリースされたrt12で試してみたところ、当方の環境では上記の問題が解決しているようです。
まだ、このカーネルでの起動での演奏２時間くらいですが、エラーが出ることもなく、鳴り続けています。
取り急ぎ、報告まで
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
koji 2013/06/24(Mon) 23:12 No.3018
上記のメッセージを書いて、10分くらいしてから、エラーが出て止まりました。
dmsegでみると、以下のエラーが延々と続いています
[ 4179.623101] cannot submit urb (err = -18)
[ 4179.625804] cannot submit urb (err = -18)
検証不十分なままの書き込みすみませんでした。
しばらくは、3.8.10+rtで様子見モードでいきたいと思います。
dmsegでみると、以下のエラーが延々と続いています
[ 4179.623101] cannot submit urb (err = -18)
[ 4179.625804] cannot submit urb (err = -18)
検証不十分なままの書き込みすみませんでした。
しばらくは、3.8.10+rtで様子見モードでいきたいと思います。
koji 2013/06/24(Mon) 23:12 No.3018
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
twl 2013/06/25(Tue) 08:00 No.3021
同じく3.8.13-rt12ですが、カーネルビルド直後からの運用にて現在まで問題なく動いております。Cubox Proを使用中です。ご報告まで。
top - 07:59:07 up 1 day, 21 min, 1 user, load average: 0.41, 0.43, 0.48
Tasks: 66 total, 1 running, 65 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.7 us, 9.1 sy, 0.0 ni, 85.6 id, 0.0 wa, 0.0 hi, 1.7 si, 0.0 st
KiB Mem: 2073492 total, 215104 used, 1858388 free, 15712 buffers
twl
top - 07:59:07 up 1 day, 21 min, 1 user, load average: 0.41, 0.43, 0.48
Tasks: 66 total, 1 running, 65 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.7 us, 9.1 sy, 0.0 ni, 85.6 id, 0.0 wa, 0.0 hi, 1.7 si, 0.0 st
KiB Mem: 2073492 total, 215104 used, 1858388 free, 15712 buffers
twl
twl 2013/06/25(Tue) 08:00 No.3021
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
koji 2013/06/25(Tue) 11:23 No.3022
twlさん、こんにちは
貴重な動作報告情報どうもありがとうございます。
3.8.13-rt12で一日以上動いているようですね。
私の方では、みみず工房のWebsiteの「cubox カーネル3.8+RTPatchのビルド方法」のアーティクルの中で説明して頂いてる方法で3.8.4くらいから3.8.10まで問題なく動作してきました。
その後、いじる時間をとれず、久しぶりに3.8.13の前のパッチ辺りでビルドしたところ、前のメッセージのようなエラーが出るようになった次第です。
configは上記のアーティクルで紹介されているものを使ってビルドしていますが、twlさんの方で動作しているカーネルの
configのポイント等をご教示頂けるとありがたいです。
koji
貴重な動作報告情報どうもありがとうございます。
3.8.13-rt12で一日以上動いているようですね。
私の方では、みみず工房のWebsiteの「cubox カーネル3.8+RTPatchのビルド方法」のアーティクルの中で説明して頂いてる方法で3.8.4くらいから3.8.10まで問題なく動作してきました。
その後、いじる時間をとれず、久しぶりに3.8.13の前のパッチ辺りでビルドしたところ、前のメッセージのようなエラーが出るようになった次第です。
configは上記のアーティクルで紹介されているものを使ってビルドしていますが、twlさんの方で動作しているカーネルの
configのポイント等をご教示頂けるとありがたいです。
koji
koji 2013/06/25(Tue) 11:23 No.3022
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
fHiro 2013/06/25(Tue) 15:15 No.3026
kojiさん、こんにちは
同じくarch linuxでの3.8.x+rtxでの状況報告です。
3.8.9+rt4
3.8.10+rt6
3.8.11+rt8
は全く問題ありませんでした。3.8.11+rt8は数日間の連続再生も試しました。
3.8.13になってから様子がおかしくなって
3.8.13+rt9 → 数分で cannot submit urb(err = -18)
3.8.13+rt10 → ほぼOKだが、数時間～半日くらいでやはり同じエラー
3.8.13+rt11 → このバージョンでは上記エラーは出ていませんが丸1日くらいしか連続再生テストはしていません。
3.8.13+rt12 → 丸一日くらい再生させると上記のエラーが出たり出なかったり。
と微妙な状態です。
.configは、yoさんの3.8.xのカーネルビルドの記事＋archスレの情報でcontrol groupを生かした状態で、3.8.xずっと共通でやっています。3.8.13で変更すべき箇所があれば自分も知りたいです。
同じくarch linuxでの3.8.x+rtxでの状況報告です。
3.8.9+rt4
3.8.10+rt6
3.8.11+rt8
は全く問題ありませんでした。3.8.11+rt8は数日間の連続再生も試しました。
3.8.13になってから様子がおかしくなって
3.8.13+rt9 → 数分で cannot submit urb(err = -18)
3.8.13+rt10 → ほぼOKだが、数時間～半日くらいでやはり同じエラー
3.8.13+rt11 → このバージョンでは上記エラーは出ていませんが丸1日くらいしか連続再生テストはしていません。
3.8.13+rt12 → 丸一日くらい再生させると上記のエラーが出たり出なかったり。
と微妙な状態です。
.configは、yoさんの3.8.xのカーネルビルドの記事＋archスレの情報でcontrol groupを生かした状態で、3.8.xずっと共通でやっています。3.8.13で変更すべき箇所があれば自分も知りたいです。
fHiro 2013/06/25(Tue) 15:15 No.3026
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
twl 2013/06/25(Tue) 20:44 No.3030
kojiさん、fHiroさん、今晩は。3.8.13-rt12のbuildに使用した.configの件ですが、お返事が遅れ失礼しました。
kojiさん wrote:
> configは上記のアーティクルで紹介されているものを使ってビルドしていますが、twlさんの方で動作しているカーネルの
> configのポイント等をご教示頂けるとありがたいです。
fHiroさん wrote:
> .configは、yoさんの3.8.xのカーネルビルドの記事＋archスレの情報でcontrol groupを生かした状態で、3.8.xずっと共通でやっています。
> 3.8.13で変更すべき箇所があれば自分も知りたいです。
不思議ですね。私も皆さん同様、yoさんが4/19/13に書かれた「cubox カーネル3.8+RTPatchのビルド方法」の指示に従った.configファイルをベースにbuildしているのですが、特に内容を意図的に変更した記憶はありません。ただ、3.8.10から3.8.11のbuildに移行した際、一度だけ、make menuconfigの途中で設定の不備があると叱られ、その部分を適当に変更、結果として問題なく3.8.11のbuildができた記憶があります。その時にdiffを保存しておけばよかったのですが、今はどこを修正あるいは追加したか記憶に残っておりません。申し訳ありません。
一応、現行の3.8.13-rt12build時の小生の.configを以下のURLに置きましたので、ご照覧下さい。お役に立てれば幸いです。
http://lydia.concorde.gr.jp/luke/CFG3813" target="_blank">http://lydia.concorde.gr.jp/luke/CFG3813 (なお、このファイルは一ヶ月後には消去いたします。)
ところで、皆さんが問題にされているエラーはurb関連のもののようですね。3.6.9カーネルでも一時問題になったようですが、このエラーは使用しているUSBデバイスに依存する可能性はないのでしょうか。私はDDCとしてAmanero Combo384を常用していますが、このDDCでのトラブルは経験しておりません。他にMytek USB2.0およびHiFace Evoを使うことはありますが、いずれのドライバーモジュールでも現行のカーネルを含め、urbエラーによる音切れの経験はありません。ただし使用時間は数時間に限られます。
最後に、現在私の使用しているMPDはJurgen Kramerさんのソース(https://github.com/lintweaker/mpd-dsd" target="_blank">https://github.com/lintweaker/mpd-dsd)をコンパイルしたものであることを追加しておきます。もしかしたらこのMPDバイナリの違いがエラーの有無になっている可能性も否定はできないですね。
皆様のお役に立てれば幸いです。
twl
kojiさん wrote:
> configは上記のアーティクルで紹介されているものを使ってビルドしていますが、twlさんの方で動作しているカーネルの
> configのポイント等をご教示頂けるとありがたいです。
fHiroさん wrote:
> .configは、yoさんの3.8.xのカーネルビルドの記事＋archスレの情報でcontrol groupを生かした状態で、3.8.xずっと共通でやっています。
> 3.8.13で変更すべき箇所があれば自分も知りたいです。
不思議ですね。私も皆さん同様、yoさんが4/19/13に書かれた「cubox カーネル3.8+RTPatchのビルド方法」の指示に従った.configファイルをベースにbuildしているのですが、特に内容を意図的に変更した記憶はありません。ただ、3.8.10から3.8.11のbuildに移行した際、一度だけ、make menuconfigの途中で設定の不備があると叱られ、その部分を適当に変更、結果として問題なく3.8.11のbuildができた記憶があります。その時にdiffを保存しておけばよかったのですが、今はどこを修正あるいは追加したか記憶に残っておりません。申し訳ありません。
一応、現行の3.8.13-rt12build時の小生の.configを以下のURLに置きましたので、ご照覧下さい。お役に立てれば幸いです。
http://lydia.concorde.gr.jp/luke/CFG3813" target="_blank">http://lydia.concorde.gr.jp/luke/CFG3813 (なお、このファイルは一ヶ月後には消去いたします。)
ところで、皆さんが問題にされているエラーはurb関連のもののようですね。3.6.9カーネルでも一時問題になったようですが、このエラーは使用しているUSBデバイスに依存する可能性はないのでしょうか。私はDDCとしてAmanero Combo384を常用していますが、このDDCでのトラブルは経験しておりません。他にMytek USB2.0およびHiFace Evoを使うことはありますが、いずれのドライバーモジュールでも現行のカーネルを含め、urbエラーによる音切れの経験はありません。ただし使用時間は数時間に限られます。
最後に、現在私の使用しているMPDはJurgen Kramerさんのソース(https://github.com/lintweaker/mpd-dsd" target="_blank">https://github.com/lintweaker/mpd-dsd)をコンパイルしたものであることを追加しておきます。もしかしたらこのMPDバイナリの違いがエラーの有無になっている可能性も否定はできないですね。
皆様のお役に立てれば幸いです。
twl
twl 2013/06/25(Tue) 20:44 No.3030
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
fHIro 2013/06/26(Wed) 00:37 No.3035
twlさん、ありがとうございます。
アップしていただいた.configをチェックしてみましたが、cgroupsがらみのところ以外は同じでした。
twlさんが述べられている通りUSBデバイス&ドライバに依存する問題の可能性が強いと思います。3.8.9+rt以前のdmaバッファを使い切ってしまうのと似ていますが、でも症状的には自分の環境ではずっと軽いです。(usbデバイスはx-ddc）
アップしていただいた.configをチェックしてみましたが、cgroupsがらみのところ以外は同じでした。
twlさんが述べられている通りUSBデバイス&ドライバに依存する問題の可能性が強いと思います。3.8.9+rt以前のdmaバッファを使い切ってしまうのと似ていますが、でも症状的には自分の環境ではずっと軽いです。(usbデバイスはx-ddc）
fHIro 2013/06/26(Wed) 00:37 No.3035
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
koji 2013/06/26(Wed) 01:02 No.3036
fHIroさん、twlさん kojiです。
まとめレス失礼します。
fHIroさんのところでも、私のところと同じエラーメッセージのようで、同様の症状の方が他にもおられることが確認でき、貴重な情報ありがとうございました。また、これまでのカネールのバージョンごとの検証結果も参考になります。私のところで、使っているのは、3.8.10-rt6です。
また、機会があれば、3.8.11+rt8も試してみたいと思います。
twlさん、早速、configのご紹介ありがとうございました。
私の方でも、diffをとってみましたが、fHIroさんご指摘のcgroupsがらみくらいでした。
でも、一応検証をしてみようと思い、ご紹介頂いたconfigでmakeしたカーネルを入れてみました。
ところが、やはり１時間少しで、cannot submit urb (err = -18)のエラーが出て演奏が止まってしまいます。
fHIroさんの書かれている通り、機種依存による部分が大きいのかも分かりませんね。
参考までに、当方の環境を記しておきますと、
CuBox→M2Tech hiface two pro→Lux DAC-100
という構成です。
aplay -lの結果は、
**** List of PLAYBACK Hardware Devices ****
card 0: M20 [M2Tech USB Audio 2.0], device 0: USB Audio [USB Audio]
Subdevices: 0/1
と、認識はされているようですが…
引き続き、様子をみていきたいと思います。
まとめレス失礼します。
fHIroさんのところでも、私のところと同じエラーメッセージのようで、同様の症状の方が他にもおられることが確認でき、貴重な情報ありがとうございました。また、これまでのカネールのバージョンごとの検証結果も参考になります。私のところで、使っているのは、3.8.10-rt6です。
また、機会があれば、3.8.11+rt8も試してみたいと思います。
twlさん、早速、configのご紹介ありがとうございました。
私の方でも、diffをとってみましたが、fHIroさんご指摘のcgroupsがらみくらいでした。
でも、一応検証をしてみようと思い、ご紹介頂いたconfigでmakeしたカーネルを入れてみました。
ところが、やはり１時間少しで、cannot submit urb (err = -18)のエラーが出て演奏が止まってしまいます。
fHIroさんの書かれている通り、機種依存による部分が大きいのかも分かりませんね。
参考までに、当方の環境を記しておきますと、
CuBox→M2Tech hiface two pro→Lux DAC-100
という構成です。
aplay -lの結果は、
**** List of PLAYBACK Hardware Devices ****
card 0: M20 [M2Tech USB Audio 2.0], device 0: USB Audio [USB Audio]
Subdevices: 0/1
と、認識はされているようですが…
引き続き、様子をみていきたいと思います。
koji 2013/06/26(Wed) 01:02 No.3036
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
twl 2013/06/26(Wed) 07:26 No.3037
twlです。皆様の問題解決にはお役に立てませんでしたが、当座の問題点についてちょっとまとめてみます。
1. urbエラーの発生に関しUSBデバイスの機種依存性があるかもしれない。
fHiroさんはX-DDC、kojiさんはHIFACE TWO-Proを使用されています。お二人ともDAC接続にはRCAケーブルによるS/PDIF使用ということでよろしいでしょうか。
仮にそうであれば、私の場合はDDCからI2S接続で自作キットのBuffalo-IIIに接続していますので、I2SとS/PDIF接続の違いがエラー発生に関連する可能性も示唆されます。
もっとも、X-DDCの場合はHDMIケーブルでのI2S接続が可能なようですので、もしこの環境でエラーが生じているのであれば、私の推測は間違っているかもしれません。
2. 音源のソースはNASかあるいはHDDなどCubox直結のUSBメディアか。
urb関連のエラーをググってみると、HDDなどのUSBデバイス経由の音源であれば、そのデバイスがエラーの原因となる可能性が指摘されています。私の場合にはNASでもUSB HDDでもどちらの音源でもエラーは発生していませんが、間にUSBハブを介在させるとエラーが消えた、という不思議な？報告もあります。ちなみにNASはSynology DiskStation (DS106e) 接続の1.0T e-SATAドライブを使用しております。
以上、ご検討いただれば幸いです。
twl
1. urbエラーの発生に関しUSBデバイスの機種依存性があるかもしれない。
fHiroさんはX-DDC、kojiさんはHIFACE TWO-Proを使用されています。お二人ともDAC接続にはRCAケーブルによるS/PDIF使用ということでよろしいでしょうか。
仮にそうであれば、私の場合はDDCからI2S接続で自作キットのBuffalo-IIIに接続していますので、I2SとS/PDIF接続の違いがエラー発生に関連する可能性も示唆されます。
もっとも、X-DDCの場合はHDMIケーブルでのI2S接続が可能なようですので、もしこの環境でエラーが生じているのであれば、私の推測は間違っているかもしれません。
2. 音源のソースはNASかあるいはHDDなどCubox直結のUSBメディアか。
urb関連のエラーをググってみると、HDDなどのUSBデバイス経由の音源であれば、そのデバイスがエラーの原因となる可能性が指摘されています。私の場合にはNASでもUSB HDDでもどちらの音源でもエラーは発生していませんが、間にUSBハブを介在させるとエラーが消えた、という不思議な？報告もあります。ちなみにNASはSynology DiskStation (DS106e) 接続の1.0T e-SATAドライブを使用しております。
以上、ご検討いただれば幸いです。
twl
twl 2013/06/26(Wed) 07:26 No.3037
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
fHiro 2013/06/26(Wed) 19:23 No.3042
twlさん、ありがとうございます。
とりあえず私の環境を挙げます。
・Cubox->X-DDC->同軸S/PDIF->DAC
・音源はNAS(ReadyNAS Ultra)に置き、Gigabit hub経由の有線接続
・データ形式はほとんどがAlac(apple lossless),44.1kh
・mpdは5月半ばのgit版、あるいは1.74安定版
どちらもそれぞれに対応するyanさんpatchでrt化
--------------------------------
現在は、3.8.13+rt12で常時再生させて様子見です。
3.8.13+rt12にしてから例のエラーが出たのは、ログを見てもまだ1度しかないので、そのまま使っても差し支えない程度ではあります。
kojiさんと比べると症状は軽いようです。
また、このエラーが出ても以前のdmaバッファが足りなくなる問題の時と比べると、OS自体は健全で、ssh接続も普通にできる状態なので扱いやすいです。dma問題の時はシステム自体がくさってフリーズに近い状態でした。
ただあくまでもこれも自分の環境だけの話かも知れません。
とりあえず私の環境を挙げます。
・Cubox->X-DDC->同軸S/PDIF->DAC
・音源はNAS(ReadyNAS Ultra)に置き、Gigabit hub経由の有線接続
・データ形式はほとんどがAlac(apple lossless),44.1kh
・mpdは5月半ばのgit版、あるいは1.74安定版
どちらもそれぞれに対応するyanさんpatchでrt化
--------------------------------
現在は、3.8.13+rt12で常時再生させて様子見です。
3.8.13+rt12にしてから例のエラーが出たのは、ログを見てもまだ1度しかないので、そのまま使っても差し支えない程度ではあります。
kojiさんと比べると症状は軽いようです。
また、このエラーが出ても以前のdmaバッファが足りなくなる問題の時と比べると、OS自体は健全で、ssh接続も普通にできる状態なので扱いやすいです。dma問題の時はシステム自体がくさってフリーズに近い状態でした。
ただあくまでもこれも自分の環境だけの話かも知れません。
fHiro 2013/06/26(Wed) 19:23 No.3042
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
koji 2013/06/26(Wed) 19:44 No.3043
twlさん、fHIroさん、kojiです。
■fHIroさんの書き込みを参考に、3.8.11+rt8のカーネルをビルドして、昨晩からずっとリピート再生した状態で出て、先程帰ってみたところ、18時間近く問題なく再生できています。
・uname -a
Linux alarmcubox 3.8.11-rt8_CuboxAudioRTuned #1 PREEMPT RT（略）
・top - 19:23:45 up 17:41（略）
どうもご教示ありがとうございました。
■twlさん、どうも問題点の整理ありがとうございます。
>1. urbエラーの発生に関しUSBデバイスの機種依存性があるかもしれない。
>fHiroさんはX-DDC、kojiさんはHIFACE TWO-Proを使用されています。お二人ともDAC接続>にはRCAケーブルによるS/PDIF使用ということでよろしいでしょうか。
はい、当方ではDDC-DAC間は同軸ケーブル（Beldenのケーブルで自作）による接続をしています。
>2. 音源のソースはNASかあるいはHDDなどCubox直結のUSBメディアか。
こちらは、Debianを入れたサーバーに置いてあるflacファイルとaacファイルを、nfsでマウントする形で使っています。
これまで、Linuxマシン同士の場合は（バックアップ用途だったので）rsync、Windowsマシンとの接続ではsambaを使っていましたので、nfsによるマウントはVoyage MPDをAtomマシンに導入してから使い始めたところです。
なので、当初のfstabは、マウント元とマウント先を記述しただけのものでした。それでも、Atomマシンの方では問題なく再生できていました。
その後、Cuboxを購入して、yoさんの雛祭りバージョンを使わせて頂いたのですが、当初、cannot submit urb (err = -27)（この時は、-18ではなく、-27でした）のエラーが出てダウンしました。
最初はUSB関係なのでハードウェア的な問題かとにらんで、ケーブルを変えたり、接続端子を変えてみたり、ハブを介してみたりと色々とやってみましたが、症状は変わりませんでした。
それで、ダメ元で、fstabにrsize=8192のオプションを加えたところ、ピタッとエラーが止まり、以降、3.8.13以前までは使えるようになっていました。
当方の環境については、上記のような次第です。
一度、USBメモリー等にファイルをコピーしてみて、マウントする等、問題を切り分けられるようにしてみたいと思います。
引き続き、よろしくお願いします。
■fHIroさんの書き込みを参考に、3.8.11+rt8のカーネルをビルドして、昨晩からずっとリピート再生した状態で出て、先程帰ってみたところ、18時間近く問題なく再生できています。
・uname -a
Linux alarmcubox 3.8.11-rt8_CuboxAudioRTuned #1 PREEMPT RT（略）
・top - 19:23:45 up 17:41（略）
どうもご教示ありがとうございました。
■twlさん、どうも問題点の整理ありがとうございます。
>1. urbエラーの発生に関しUSBデバイスの機種依存性があるかもしれない。
>fHiroさんはX-DDC、kojiさんはHIFACE TWO-Proを使用されています。お二人ともDAC接続>にはRCAケーブルによるS/PDIF使用ということでよろしいでしょうか。
はい、当方ではDDC-DAC間は同軸ケーブル（Beldenのケーブルで自作）による接続をしています。
>2. 音源のソースはNASかあるいはHDDなどCubox直結のUSBメディアか。
こちらは、Debianを入れたサーバーに置いてあるflacファイルとaacファイルを、nfsでマウントする形で使っています。
これまで、Linuxマシン同士の場合は（バックアップ用途だったので）rsync、Windowsマシンとの接続ではsambaを使っていましたので、nfsによるマウントはVoyage MPDをAtomマシンに導入してから使い始めたところです。
なので、当初のfstabは、マウント元とマウント先を記述しただけのものでした。それでも、Atomマシンの方では問題なく再生できていました。
その後、Cuboxを購入して、yoさんの雛祭りバージョンを使わせて頂いたのですが、当初、cannot submit urb (err = -27)（この時は、-18ではなく、-27でした）のエラーが出てダウンしました。
最初はUSB関係なのでハードウェア的な問題かとにらんで、ケーブルを変えたり、接続端子を変えてみたり、ハブを介してみたりと色々とやってみましたが、症状は変わりませんでした。
それで、ダメ元で、fstabにrsize=8192のオプションを加えたところ、ピタッとエラーが止まり、以降、3.8.13以前までは使えるようになっていました。
当方の環境については、上記のような次第です。
一度、USBメモリー等にファイルをコピーしてみて、マウントする等、問題を切り分けられるようにしてみたいと思います。
引き続き、よろしくお願いします。
koji 2013/06/26(Wed) 19:44 No.3043
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
twl 2013/06/26(Wed) 22:17 No.3047
fHiroさん、kojiさん、S/PDIFでの接続環境の情報ありがとうございました。お二人とも音源はNASを利用されていることから、HDDなどのUSBデバイスがらみのエラーではないようですね。
S/PDIFの環境がこのエラーに関与しているのかどうか検証したく、先程mpd稼働のままでUSB接続をAmaneroからHiface Evoに変更、そこからS/PDIFでBuffalo III DACに接続しましたが、皆さんのエラーが再現されるかどうか、これから明日ぐらいまで様子をみて見ます。接続変更から約30分後の現在では問題ありません。
fHiroさんに関してはこのsubmit_urbエラーの影響は極めて小さいようですね。私の使用しているMPDにはyanさんpatchはあてていないのですが、おそらくこの違いによるエラーではないだろうと思われます。
kojiさんは
> それで、ダメ元で、fstabにrsize=8192のオプションを加えたところ、ピタッとエラーが止まり、
> 以降、3.8.13以前までは使えるようになっていました。
とありますが、私のfstabではyoさんの指示に従い以下にお示しするようにrsize=130048となっています。NASのマウント形式はnfsではなくcifsでありlinuxとWindowsの違いはありますが、再度ダメ元で試されてはいかがでしょうか。
//192.168.0.99/satashare/DSD /dsd128 cifs username=xxxxx,password=xxxxx,uid=mpd,file_mode=0666,dir_mode=0766,iocharset=utf8,rsize=130048,wsize=4096,cache=strict,sec=ntlmv2 0 0
十分には理解していないのですが、submit_urbエラーはUSBを介して送受信されるデータの順番待ちがうまくいかない場合に起きるようですね。 データのqueueがいっぱいになっていても充足されていなくとも起きるようです。もしかしたらrsizeの設定がこの部分に関与しているかもしれず、申し上げた次第です。
twl
S/PDIFの環境がこのエラーに関与しているのかどうか検証したく、先程mpd稼働のままでUSB接続をAmaneroからHiface Evoに変更、そこからS/PDIFでBuffalo III DACに接続しましたが、皆さんのエラーが再現されるかどうか、これから明日ぐらいまで様子をみて見ます。接続変更から約30分後の現在では問題ありません。
fHiroさんに関してはこのsubmit_urbエラーの影響は極めて小さいようですね。私の使用しているMPDにはyanさんpatchはあてていないのですが、おそらくこの違いによるエラーではないだろうと思われます。
kojiさんは
> それで、ダメ元で、fstabにrsize=8192のオプションを加えたところ、ピタッとエラーが止まり、
> 以降、3.8.13以前までは使えるようになっていました。
とありますが、私のfstabではyoさんの指示に従い以下にお示しするようにrsize=130048となっています。NASのマウント形式はnfsではなくcifsでありlinuxとWindowsの違いはありますが、再度ダメ元で試されてはいかがでしょうか。
//192.168.0.99/satashare/DSD /dsd128 cifs username=xxxxx,password=xxxxx,uid=mpd,file_mode=0666,dir_mode=0766,iocharset=utf8,rsize=130048,wsize=4096,cache=strict,sec=ntlmv2 0 0
十分には理解していないのですが、submit_urbエラーはUSBを介して送受信されるデータの順番待ちがうまくいかない場合に起きるようですね。 データのqueueがいっぱいになっていても充足されていなくとも起きるようです。もしかしたらrsizeの設定がこの部分に関与しているかもしれず、申し上げた次第です。
twl
twl 2013/06/26(Wed) 22:17 No.3047
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
twl 2013/06/27(Thu) 07:31 No.3051
twlです。
> S/PDIFの環境がこのエラーに関与しているのかどうか検証したく、-snip- DACに接続しましたが、
> 皆さんのエラーが再現されるかどうか、これから明日ぐらいまで様子をみて見ます。
と申し上げましたが、S/PDIF接続から約９時間後の現在、mpd接続に関するエラーは生じていません。短絡的な結論ですがS/PDIFとsubmit_urbエラーの関連はなさそうと思われます。やはり、このエラーについては説明の困難ななんらかの機種依存性があるのかもしれませんね。
twl
> S/PDIFの環境がこのエラーに関与しているのかどうか検証したく、-snip- DACに接続しましたが、
> 皆さんのエラーが再現されるかどうか、これから明日ぐらいまで様子をみて見ます。
と申し上げましたが、S/PDIF接続から約９時間後の現在、mpd接続に関するエラーは生じていません。短絡的な結論ですがS/PDIFとsubmit_urbエラーの関連はなさそうと思われます。やはり、このエラーについては説明の困難ななんらかの機種依存性があるのかもしれませんね。
twl
twl 2013/06/27(Thu) 07:31 No.3051
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
koji 2013/06/27(Thu) 20:00 No.3059
twlさん、fHiroさん、kojiです。
お二人から、3.8.13+r12で問題なく動作されている報告があり、当方の環境を見直してみようと思いました。
twlさんから
>とありますが、私のfstabではyoさんの指示に従い以下にお示しするようにrsize=130048となっています。NASのマウント形式はnfsではなくcifsでありlinuxとWindowsの違いはありますが、再度ダメ元で試されてはいかがでしょうか。
とのサジェスチョンがあり、fstab周りをいじってみました。
Googleで、nfsでマウンとする際のオプションの最適値などを調べてみたのですが、ネットワークの速度、HDDのキャッシュサイズ等が関係するようで、様々な記述がありました。（ちなみに、現在のrsize=8192も、man fstabの記述を参考に入れてみたものです）
それで、まず、調べたサイトに記されていたrsize=32768と大きくしてみましたが、より短時間の3分くらいでエラーメッセージが出て演奏停止になるようになりました。
rsizeのオプションを外してみたりしてみましたがエラーが出る症状は変わらずでした。
調べてみた結果、「1024の倍数のオプションを与えていく」との記述があったので、一番少ない、rsize=1024を指定してみたところ、これまでのところ安定して動作するようになりました。
・top - 19:54:38 up 3:10（略）
現在、連続再生をさせて３時間が経過していますが、エラーが出ることなく演奏できています。
さらに、2048など、数値を詰めてみるべきかも分かりませんが、とりあえず、私の環境ではrsizeを1024に指定してやることで解決の糸口が見えてきたようです。
このまま、明朝まで、さらに様子をみて、追加報告をしたいと思います。
お二人の書き込みがとても参考になりました。どうもありがとうございました。
お二人から、3.8.13+r12で問題なく動作されている報告があり、当方の環境を見直してみようと思いました。
twlさんから
>とありますが、私のfstabではyoさんの指示に従い以下にお示しするようにrsize=130048となっています。NASのマウント形式はnfsではなくcifsでありlinuxとWindowsの違いはありますが、再度ダメ元で試されてはいかがでしょうか。
とのサジェスチョンがあり、fstab周りをいじってみました。
Googleで、nfsでマウンとする際のオプションの最適値などを調べてみたのですが、ネットワークの速度、HDDのキャッシュサイズ等が関係するようで、様々な記述がありました。（ちなみに、現在のrsize=8192も、man fstabの記述を参考に入れてみたものです）
それで、まず、調べたサイトに記されていたrsize=32768と大きくしてみましたが、より短時間の3分くらいでエラーメッセージが出て演奏停止になるようになりました。
rsizeのオプションを外してみたりしてみましたがエラーが出る症状は変わらずでした。
調べてみた結果、「1024の倍数のオプションを与えていく」との記述があったので、一番少ない、rsize=1024を指定してみたところ、これまでのところ安定して動作するようになりました。
・top - 19:54:38 up 3:10（略）
現在、連続再生をさせて３時間が経過していますが、エラーが出ることなく演奏できています。
さらに、2048など、数値を詰めてみるべきかも分かりませんが、とりあえず、私の環境ではrsizeを1024に指定してやることで解決の糸口が見えてきたようです。
このまま、明朝まで、さらに様子をみて、追加報告をしたいと思います。
お二人の書き込みがとても参考になりました。どうもありがとうございました。
koji 2013/06/27(Thu) 20:00 No.3059
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
fHito 2013/06/27(Thu) 23:08 No.3062
皆さん、情報ありがとうございます。
私の方ですが、
3.8.13+rt12が今日、例の cannot submit urb (err = -18)を出しました。この4日間で2回目ですが、長時間連続再生とは関係ないような感じです。いずれにしろかなりの低頻度です。
fstabのnasマウント設定はcifsでtwlさんとほぼ同じです。(cache=strictが入っていない以外)
3.8.13+rt11だけがこのエラーを今まで確認していないので、試しにrt11でしばらく動かしてみます。
自分としてはこの手の作業は苦にならないので、楽しんでやっています。時々カーネルビルドすると手順も忘れなくて良いですし:)
私の方ですが、
3.8.13+rt12が今日、例の cannot submit urb (err = -18)を出しました。この4日間で2回目ですが、長時間連続再生とは関係ないような感じです。いずれにしろかなりの低頻度です。
fstabのnasマウント設定はcifsでtwlさんとほぼ同じです。(cache=strictが入っていない以外)
3.8.13+rt11だけがこのエラーを今まで確認していないので、試しにrt11でしばらく動かしてみます。
自分としてはこの手の作業は苦にならないので、楽しんでやっています。時々カーネルビルドすると手順も忘れなくて良いですし:)
fHito 2013/06/27(Thu) 23:08 No.3062
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
koji 2013/06/27(Thu) 23:39 No.3063
こんにちは、kojiです。
先程の書き込みの後、5時間くらいまで再生できていたのは確認しているのですが、その後、別の部屋に行き、先程戻ってきたら例のエラーメッセージをはいてとまっていました。
以前に比べると、かなり改善しましたし、これだけの時間再生できるならば実用上は問題ないとも言えますが…
引き続き、また、色々といじってみたいと思います。
先程のメッセージでほぼ解決みたいなニュアンスでの書き込みになってしまったので、取り急ぎ、その後の経過報告です。
先程の書き込みの後、5時間くらいまで再生できていたのは確認しているのですが、その後、別の部屋に行き、先程戻ってきたら例のエラーメッセージをはいてとまっていました。
以前に比べると、かなり改善しましたし、これだけの時間再生できるならば実用上は問題ないとも言えますが…
引き続き、また、色々といじってみたいと思います。
先程のメッセージでほぼ解決みたいなニュアンスでの書き込みになってしまったので、取り急ぎ、その後の経過報告です。
koji 2013/06/27(Thu) 23:39 No.3063
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
fHiro 2013/06/29(Sat) 00:24 No.3070
こんばんは。
rt13が出ているのを発見してしまったので入れ替えてテストしてみます。
rt13が出ているのを発見してしまったので入れ替えてテストしてみます。
fHiro 2013/06/29(Sat) 00:24 No.3070
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
fHiro 2013/06/30(Sun) 03:07 No.3085
こんばんは、kojiさん、twlさん
rt13ですがKernel Bootingから先に進まず起動しないので今のところテストできません。以前のyoさんの記事を見てboot.scrにvmallocを復活させてみましたが、だめでした。何かミスしてるのかも知れません。。
rt13ですがKernel Bootingから先に進まず起動しないので今のところテストできません。以前のyoさんの記事を見てboot.scrにvmallocを復活させてみましたが、だめでした。何かミスしてるのかも知れません。。
fHiro 2013/06/30(Sun) 03:07 No.3085
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
twl 2013/07/01(Mon) 02:26 No.3091
fHiroさん、お返事が遅くなりましたが私も同様です。rt13を従来のconfigでビルドしましたが、
Uncompressing Linux... done, booting the kernel.
ここから先に行ってくれません。何度やっても同じなので、現在はrt12に戻っているところです。
twl
Uncompressing Linux... done, booting the kernel.
ここから先に行ってくれません。何度やっても同じなので、現在はrt12に戻っているところです。
twl
twl 2013/07/01(Mon) 02:26 No.3091
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
ｆHiro 2013/07/01(Mon) 16:09 No.3092
twlさん、kojiさん
情報ありがとうございます、やはりrt13でまさかのbootせず、ですね。時間があるときにいじってみようと思います。
あと、もし梅雨入り版のmpd.confをお使いの場合、別スレのアップサンプリングのところに載っているように、player outputの優先度をFIFO:54->53に(ひな祭り版相当)戻した方が良いです。
自分の環境だと、これを54にすると例のcannot submit urb(error = -18)がすぐ出るようになりました。
その辺りの状況からするとやはりmpdをrt化している場合に出る現象かも知れません。
情報ありがとうございます、やはりrt13でまさかのbootせず、ですね。時間があるときにいじってみようと思います。
あと、もし梅雨入り版のmpd.confをお使いの場合、別スレのアップサンプリングのところに載っているように、player outputの優先度をFIFO:54->53に(ひな祭り版相当)戻した方が良いです。
自分の環境だと、これを54にすると例のcannot submit urb(error = -18)がすぐ出るようになりました。
その辺りの状況からするとやはりmpdをrt化している場合に出る現象かも知れません。
ｆHiro 2013/07/01(Mon) 16:09 No.3092
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
koji 2013/07/01(Mon) 22:09 No.3094
fHiroさん、twlさん
いじる時間がなくて、遅ればせながら、私の方でもrt13パッチでのカーネルを作成して起動してみました。
すでに、皆さんから途中で止まるとの報告が上がっていたので、シリアル接続をして様子を確認しました。
皆さんと同様、uImageを読みに行くところでUncompressing…とずっと出たままとまってしまいますね。
以降、このuImageから来るエラーメッセージが表示もされないので、解決の糸口がみえにくいですね。
さしあたっては、次のrt14が出るのを待つ…という感じでしょうか？
いじる時間がなくて、遅ればせながら、私の方でもrt13パッチでのカーネルを作成して起動してみました。
すでに、皆さんから途中で止まるとの報告が上がっていたので、シリアル接続をして様子を確認しました。
皆さんと同様、uImageを読みに行くところでUncompressing…とずっと出たままとまってしまいますね。
以降、このuImageから来るエラーメッセージが表示もされないので、解決の糸口がみえにくいですね。
さしあたっては、次のrt14が出るのを待つ…という感じでしょうか？
koji 2013/07/01(Mon) 22:09 No.3094
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
twl 2013/07/03(Wed) 00:30 No.3099
twlです。3.8.13-rt13でとりあえずbootできる状態になりました。
従来のconfigでは何度buildしても、boot時に'Uncompressing Linux... done, booting the kernel.'以上には進まないので、rt12とrt13のpatchファイルのdiffをとってみたところ、rt13での変更部分はすべて'ifdef CONFIG_PREEMPT_RT_BASE'を含む記述になっていました。従ってこの設定を避ければとりあえずbuild可能と判断しました。
カーネルのmake menuconfigにおけるPREEMPT_RT関連の設定は、従来
( ) No Forced Preemption (Server)
( ) Voluntary Kernel Preemption (Desktop)
( ) Preemptible Kernel (Low-Latency Desktop)
( ) Preemptible Kernel (Basic RT)
(X) Fully Preemptible Kernel (RT)
となっていますが、この設定では自動的にCONFIG_PREEMPT_RT_BASE=yとなってしまうため、
( ) No Forced Preemption (Server)
( ) Voluntary Kernel Preemption (Desktop)
(X) Preemptible Kernel (Low-Latency Desktop)
( ) Preemptible Kernel (Basic RT)
( ) Fully Preemptible Kernel (RT)
と、敢えてFully Preemptible Kernelを外した設定にしました(CONFIG_PREEMPT__LL=y)。従ってこの設定はyoさん方が目指しているrtカーネルに相当するものかどうかがちょっと微妙なところなのですが、とりあえず、この設定でbuildとすると、voila!、通常にbootでき、現在mpd自体も順調に稼働しています。
boot.scrはyoさんおすすめのboot2.txtを基本としたもので、大きな変更はありません。なお、boot時にCGROUP関連が設定されていないとのmessageがいつもうるさく出るので、上記の変更に加え、CGROUPの設定もyesにしてあります(CONFIG_CGROUPS=y)。
この設定がいいのかどうかこれから検討が必要ですが、とりあえず経過を報告させていただきます。
twl
従来のconfigでは何度buildしても、boot時に'Uncompressing Linux... done, booting the kernel.'以上には進まないので、rt12とrt13のpatchファイルのdiffをとってみたところ、rt13での変更部分はすべて'ifdef CONFIG_PREEMPT_RT_BASE'を含む記述になっていました。従ってこの設定を避ければとりあえずbuild可能と判断しました。
カーネルのmake menuconfigにおけるPREEMPT_RT関連の設定は、従来
( ) No Forced Preemption (Server)
( ) Voluntary Kernel Preemption (Desktop)
( ) Preemptible Kernel (Low-Latency Desktop)
( ) Preemptible Kernel (Basic RT)
(X) Fully Preemptible Kernel (RT)
となっていますが、この設定では自動的にCONFIG_PREEMPT_RT_BASE=yとなってしまうため、
( ) No Forced Preemption (Server)
( ) Voluntary Kernel Preemption (Desktop)
(X) Preemptible Kernel (Low-Latency Desktop)
( ) Preemptible Kernel (Basic RT)
( ) Fully Preemptible Kernel (RT)
と、敢えてFully Preemptible Kernelを外した設定にしました(CONFIG_PREEMPT__LL=y)。従ってこの設定はyoさん方が目指しているrtカーネルに相当するものかどうかがちょっと微妙なところなのですが、とりあえず、この設定でbuildとすると、voila!、通常にbootでき、現在mpd自体も順調に稼働しています。
boot.scrはyoさんおすすめのboot2.txtを基本としたもので、大きな変更はありません。なお、boot時にCGROUP関連が設定されていないとのmessageがいつもうるさく出るので、上記の変更に加え、CGROUPの設定もyesにしてあります(CONFIG_CGROUPS=y)。
この設定がいいのかどうかこれから検討が必要ですが、とりあえず経過を報告させていただきます。
twl
twl 2013/07/03(Wed) 00:30 No.3099
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
fHiro 2013/07/03(Wed) 22:59 No.3107
twlさん、情報ありがとうございます。
試してみます、patch差分も見てみようと思います。
試してみます、patch差分も見てみようと思います。
fHiro 2013/07/03(Wed) 22:59 No.3107
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
fHito 2013/07/08(Mon) 00:59 No.3143
twlさん、kojiさんこんばんは。
私の環境でもBasic RTをOFFにしてビルドすると、正常に起動することを確認しました。
その後
3.8.13+rt12
3.8.13+rt13
の状態のソースファイルを比較すると
変更のあるのは、patchファイルからもわかりますが
linux-3.8.13/include/linux/list_bl.h
のみでした。中身を見ると
/////////////
static inline void hlist_bl_lock(struct hlist_bl_head *b)
{
#ifndef CONFIG_PREEMPT_RT_BASE
bit_spin_lock(0, (unsigned long *)b); // -> こっちはrt12と同じ
#else
raw_spin_lock(&b->lock); // -> rt13での追加
__set_bit(0, (unsigned long *)b);
#endif
}
static inline void hlist_bl_unlock(struct hlist_bl_head *b)
{
#ifndef CONFIG_PREEMPT_RT_BASE
__bit_spin_unlock(0, (unsigned long *)b); // -> こっちはrt12と同じ
#else
__clear_bit(0, (unsigned long *)b); // -> rt13での追加
raw_spin_unlock(&b->lock);
#endif
}
で処理を分けているところのみがrt13で追加されています。
ので、rt13でBasic RTをOFFにすると実質rt12と同じものになっていると思われます。
//////////////////
list_bl.hは
make list head locking RT safeと言うことなので
何らかの資源の排他管理を行っているようなのですが、このロックと解放
処理がrt13で変更されて、raw_spin_lock()という仕組みを使うようになっています。
この解放待ちでデッドロックになっているような気はしますが、rt12までの仕組みも基本は同じようなことをしていますし、謎です。
list_bl.hはRTパッチ全般で使用されているので、実際に止まっている箇所を特定するにはデバッガか、怪しい箇所にコンソールメッセージを仕込むとかだと思いますが、linuxに詳しくないのでそれもままなりません。
VMWare Playerがあまりに遅くて(起動に5分とか)やる気が失せるほどなので、SSDに換えたところ爆速になりました。
VMWareのubuntu起動も20秒程度です。HDDがいかにシステムの足を引っ張っているかがわかりました。
私の環境でもBasic RTをOFFにしてビルドすると、正常に起動することを確認しました。
その後
3.8.13+rt12
3.8.13+rt13
の状態のソースファイルを比較すると
変更のあるのは、patchファイルからもわかりますが
linux-3.8.13/include/linux/list_bl.h
のみでした。中身を見ると
/////////////
static inline void hlist_bl_lock(struct hlist_bl_head *b)
{
#ifndef CONFIG_PREEMPT_RT_BASE
bit_spin_lock(0, (unsigned long *)b); // -> こっちはrt12と同じ
#else
raw_spin_lock(&b->lock); // -> rt13での追加
__set_bit(0, (unsigned long *)b);
#endif
}
static inline void hlist_bl_unlock(struct hlist_bl_head *b)
{
#ifndef CONFIG_PREEMPT_RT_BASE
__bit_spin_unlock(0, (unsigned long *)b); // -> こっちはrt12と同じ
#else
__clear_bit(0, (unsigned long *)b); // -> rt13での追加
raw_spin_unlock(&b->lock);
#endif
}
で処理を分けているところのみがrt13で追加されています。
ので、rt13でBasic RTをOFFにすると実質rt12と同じものになっていると思われます。
//////////////////
list_bl.hは
make list head locking RT safeと言うことなので
何らかの資源の排他管理を行っているようなのですが、このロックと解放
処理がrt13で変更されて、raw_spin_lock()という仕組みを使うようになっています。
この解放待ちでデッドロックになっているような気はしますが、rt12までの仕組みも基本は同じようなことをしていますし、謎です。
list_bl.hはRTパッチ全般で使用されているので、実際に止まっている箇所を特定するにはデバッガか、怪しい箇所にコンソールメッセージを仕込むとかだと思いますが、linuxに詳しくないのでそれもままなりません。
VMWare Playerがあまりに遅くて(起動に5分とか)やる気が失せるほどなので、SSDに換えたところ爆速になりました。
VMWareのubuntu起動も20秒程度です。HDDがいかにシステムの足を引っ張っているかがわかりました。
fHito 2013/07/08(Mon) 00:59 No.3143
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
twl 2013/07/08(Mon) 07:33 No.3144
fHiroさんwrote:
> list_bl.hは
> make list head locking RT safeと言うことなので
> 何らかの資源の排他管理を行っているようなのですが、このロックと解放
> 処理がrt13で変更されて、raw_spin_lock()という仕組みを使うようになっています。
>
> この解放待ちでデッドロックになっているような気はしますが、rt12までの仕組みも基本は同じようなことをしていますし、謎です。
fHiroさん、解析ありがとうございました。
http://www.spinics.net/lists/linux-rt-users/msg10198.html" target="_blank">http://www.spinics.net/lists/linux-rt-users/msg10198.htmlを参照すると、今回のlist_bl.hがらみの問題は背景に
include/linux/jbd_common.hの変更があるようです。私はこの変更の詳細についての知識はありませんが、JBDはext3の
journalingに関して使われているシステムのようです。
現在私の環境ではbootやrootfsにはext3を用いているので、これをext4にするともしかして状況が変わるのかもしれません。
まだ憶測の段階ですが時間があったらちょっと試してみます。
twl
> list_bl.hは
> make list head locking RT safeと言うことなので
> 何らかの資源の排他管理を行っているようなのですが、このロックと解放
> 処理がrt13で変更されて、raw_spin_lock()という仕組みを使うようになっています。
>
> この解放待ちでデッドロックになっているような気はしますが、rt12までの仕組みも基本は同じようなことをしていますし、謎です。
fHiroさん、解析ありがとうございました。
http://www.spinics.net/lists/linux-rt-users/msg10198.html" target="_blank">http://www.spinics.net/lists/linux-rt-users/msg10198.htmlを参照すると、今回のlist_bl.hがらみの問題は背景に
include/linux/jbd_common.hの変更があるようです。私はこの変更の詳細についての知識はありませんが、JBDはext3の
journalingに関して使われているシステムのようです。
現在私の環境ではbootやrootfsにはext3を用いているので、これをext4にするともしかして状況が変わるのかもしれません。
まだ憶測の段階ですが時間があったらちょっと試してみます。
twl
twl 2013/07/08(Mon) 07:33 No.3144
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
fHiro 2013/07/09(Tue) 01:40 No.3150
twlさん、情報ありがとうございます。
私も、ext3の1パーティション構成なのでext4に変換して試してみましたが残念ながら
booting the kernel.から先には進みませんでした。
いちおう手順ですが
ext3 -> ext4への変換は
VMWare上のubuntuで
tune2fs -O extents,uninit_bg,dir_index /dev/sdf1
e2fsck -fDC0 /dev/sdf1
cuboxに差して3.8.13-rt11で正常起動を確認
kernel.logでext4になっていることを確認。
3.8.13-rt13にしてcubox reboot で起動せず...
です。とりあえず私の環境での結果報告でした。
私も、ext3の1パーティション構成なのでext4に変換して試してみましたが残念ながら
booting the kernel.から先には進みませんでした。
いちおう手順ですが
ext3 -> ext4への変換は
VMWare上のubuntuで
tune2fs -O extents,uninit_bg,dir_index /dev/sdf1
e2fsck -fDC0 /dev/sdf1
cuboxに差して3.8.13-rt11で正常起動を確認
kernel.logでext4になっていることを確認。
3.8.13-rt13にしてcubox reboot で起動せず...
です。とりあえず私の環境での結果報告でした。
fHiro 2013/07/09(Tue) 01:40 No.3150
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
fHiro 2013/07/09(Tue) 02:18 No.3151
ext4のノンジャーナルにしていなかったのに気づいたので引き続きノンジャーナル化してテストしてみました。
tune2fs -c 0 -O ^has_journal /dev/sdf1
e2fsck -fDC0 /dev/sdf1
cuboxのkernel.logで
Jul 9 02:10:07 localhost kernel: EXT4-fs (mmcblk0p1): mounted filesystem without journal. Opts: (null)
ノンジャーナルのext4を確認。
で結果ですが、rt13ではやはり起動せずでした。
ただ気のせいかも知れませんが、ジャーナルレスの方が音が良いような気がするのでこのままにしようと思います。
tune2fs -c 0 -O ^has_journal /dev/sdf1
e2fsck -fDC0 /dev/sdf1
cuboxのkernel.logで
Jul 9 02:10:07 localhost kernel: EXT4-fs (mmcblk0p1): mounted filesystem without journal. Opts: (null)
ノンジャーナルのext4を確認。
で結果ですが、rt13ではやはり起動せずでした。
ただ気のせいかも知れませんが、ジャーナルレスの方が音が良いような気がするのでこのままにしようと思います。
fHiro 2013/07/09(Tue) 02:18 No.3151
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
twl 2013/07/09(Tue) 20:49 No.3152
fHiroさん、ext4ファイルシステムとrt13とのtrialおよびその結果のご報告、ありがとうございました。大変参考になりました。私もext4を試してみましたが、fHiroさんと同じ結果でした。
＃でも、ジャーナルレスの方が音が良いというのは思いがけない収穫でしたね。
いずれにしても考えつくことも尽きた状態ですので、rt14あたりが発表されるまで、私もちょっと様子見の状態になろうかと考えております。
twl
＃でも、ジャーナルレスの方が音が良いというのは思いがけない収穫でしたね。
いずれにしても考えつくことも尽きた状態ですので、rt14あたりが発表されるまで、私もちょっと様子見の状態になろうかと考えております。
twl
twl 2013/07/09(Tue) 20:49 No.3152
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
fHiro 2013/07/09(Tue) 21:15 No.3153
twlさん、こんばんは。
１つ気になるのは、3.8.xになってからcubox固有パッチが無いので適用せずにカーネルをビルドしていることです。
3.6.9までは固有パッチのあたったカーネルソースが有ります。その後カーネルにcuboxのパッチが取り込まれた結果不要になったのかどうかが私にはわかりません。ただカーネルソースに取り込まれたとした場合にはビルド時に何らかの指定が必要になるはずですが、それが.config設定には入っていないような気がします。
いずれにせよ、現状ではrtの更新待ちですね..
１つ気になるのは、3.8.xになってからcubox固有パッチが無いので適用せずにカーネルをビルドしていることです。
3.6.9までは固有パッチのあたったカーネルソースが有ります。その後カーネルにcuboxのパッチが取り込まれた結果不要になったのかどうかが私にはわかりません。ただカーネルソースに取り込まれたとした場合にはビルド時に何らかの指定が必要になるはずですが、それが.config設定には入っていないような気がします。
いずれにせよ、現状ではrtの更新待ちですね..
fHiro 2013/07/09(Tue) 21:15 No.3153
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
tinker 2013/07/10(Wed) 21:31 No.3163
fHiroさん
patchの話しじゃなくてすいません。
>ただカーネルソースに取り込まれたとした場合にはビルド時に何らかの指定が必要になるはずですが、
Device Treeで最低限の機能を組み込んでいるようです。
make dtbs
cd arch/arm/boot
cat zImage dts/dove-cubox.dtb > zImage.cubox
固有patchではないので、例えばオプティカルなどは動かないようです。
dtsに対するpatchを公開されている方がいらしゃいます。残念ながら3.8のものはないようです。
http://moinejf.free.fr/" target="_blank">http://moinejf.free.fr/ （画面右上のほう）
patchの話しじゃなくてすいません。
>ただカーネルソースに取り込まれたとした場合にはビルド時に何らかの指定が必要になるはずですが、
Device Treeで最低限の機能を組み込んでいるようです。
make dtbs
cd arch/arm/boot
cat zImage dts/dove-cubox.dtb > zImage.cubox
固有patchではないので、例えばオプティカルなどは動かないようです。
dtsに対するpatchを公開されている方がいらしゃいます。残念ながら3.8のものはないようです。
http://moinejf.free.fr/" target="_blank">http://moinejf.free.fr/ （画面右上のほう）
tinker 2013/07/10(Wed) 21:31 No.3163
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
fHiro 2013/07/11(Thu) 17:48 No.3169
tinkerさん、こんにちは。
device treeの方に入っていたんですね。アドバイスいただいて、ありがとうございます。
実はそもそもdts自体良くわかっていないので^^;;
教えていただいた、リンク先のページ何かすごく前にも見たことがあります、3.10-rc1のパッチが載っていますね。
改めてhttp://www.xilka.com/sheeva/" target="_blank">http://www.xilka.com/sheeva/の方を見てみると、DTパッチと言うのがあったりするので(前は意味が良くわからなかった)、と3.8.xで使えるものもあるかもです。
カーネル3.8.xは13で打ち止めなので、rtも3.9か3.10に移行ですね。またいろいろありそうです。
普通にオーディオ機器としてcuboxを使うのには全く推奨できない楽しみ方ですはありますが。。
voyage mpdのcuboxも出たようですし、squeeze boxもcuboxで動くようですし、興味は尽きません。
device treeの方に入っていたんですね。アドバイスいただいて、ありがとうございます。
実はそもそもdts自体良くわかっていないので^^;;
教えていただいた、リンク先のページ何かすごく前にも見たことがあります、3.10-rc1のパッチが載っていますね。
改めてhttp://www.xilka.com/sheeva/" target="_blank">http://www.xilka.com/sheeva/の方を見てみると、DTパッチと言うのがあったりするので(前は意味が良くわからなかった)、と3.8.xで使えるものもあるかもです。
カーネル3.8.xは13で打ち止めなので、rtも3.9か3.10に移行ですね。またいろいろありそうです。
普通にオーディオ機器としてcuboxを使うのには全く推奨できない楽しみ方ですはありますが。。
voyage mpdのcuboxも出たようですし、squeeze boxもcuboxで動くようですし、興味は尽きません。
fHiro 2013/07/11(Thu) 17:48 No.3169
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
tinker 2013/07/11(Thu) 19:37 No.3171
fHiroさん
rtのpatchが出るとすれば3.10.xですね。3.10も3.8みたいな音だったら良いなと思ってます。
>普通にオーディオ機器としてcuboxを使うのには全く推奨できない楽しみ方ですはありますが。。
これはこれで楽しいんで^^;
rtのpatchが出るとすれば3.10.xですね。3.10も3.8みたいな音だったら良いなと思ってます。
>普通にオーディオ機器としてcuboxを使うのには全く推奨できない楽しみ方ですはありますが。。
これはこれで楽しいんで^^;
tinker 2013/07/11(Thu) 19:37 No.3171
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
koji 2013/07/11(Thu) 22:38 No.3175
fHiroさん、tinkerさん、kojiです。
この間、ほとんどいじる時間がとれず、皆さんの検証の書き込みを拝見させて頂いていました。
次は、3.10ベースなのですね。楽しみに待ちたいと思います。
>普通にオーディオ機器としてcuboxを使うのには全く推奨できない楽しみ方ですはありますが。。
故・長岡氏の「手段が目的となることを趣味という」という言葉を思いだしました(^_^)
でも、音が確かに変わっていくので、いじっていて楽しいですよね。
>voyage mpdのcuboxも出たようですし、squeeze boxもcuboxで動くようですし、興味は尽きません。
上記の書き込みで、Voyage Muboxがリリースされたのを知りました。今度、時間がとれる時に、インストールしてみたいと思います。
どうもありがとうございました。
この間、ほとんどいじる時間がとれず、皆さんの検証の書き込みを拝見させて頂いていました。
次は、3.10ベースなのですね。楽しみに待ちたいと思います。
>普通にオーディオ機器としてcuboxを使うのには全く推奨できない楽しみ方ですはありますが。。
故・長岡氏の「手段が目的となることを趣味という」という言葉を思いだしました(^_^)
でも、音が確かに変わっていくので、いじっていて楽しいですよね。
>voyage mpdのcuboxも出たようですし、squeeze boxもcuboxで動くようですし、興味は尽きません。
上記の書き込みで、Voyage Muboxがリリースされたのを知りました。今度、時間がとれる時に、インストールしてみたいと思います。
どうもありがとうございました。
koji 2013/07/11(Thu) 22:38 No.3175
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
fHiro 2013/07/12(Fri) 02:29 No.3180
皆さん、
寝る前になんとなくrtのページをリロードしたらrt14を発見w！
結果は・・・,めでたくブートしました:D
まだ1時間程度ですが、urbのエラーは出ていません。
例の include/linux/list_bl.hですが、修正が入っていました。
----------いちおうソースの修正部分を載せておきます ------------------
static inline void hlist_bl_lock(struct hlist_bl_head *b)
{
#ifndef CONFIG_PREEMPT_RT_BASE
bit_spin_lock(0, (unsigned long *)b);
#else
raw_spin_lock(&b->lock);
#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
__set_bit(0, (unsigned long *)b); -> rt13ではこれが生きていた。
#endif
#endif
}
static inline void hlist_bl_unlock(struct hlist_bl_head *b)
{
#ifndef CONFIG_PREEMPT_RT_BASE
__bit_spin_unlock(0, (unsigned long *)b);
#else
#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
__clear_bit(0, (unsigned long *)b); -> rt13ではこれが生きていた。
#endif
raw_spin_unlock(&b->lock);
#endif
}
-------------------------------------------------
CONFIG_PREEMPT_RT_BASEが定義されていない場合の処理との互換性を取るためかと思っていた
__set_bit(0, (unsigned long *)b);
__clear_bit(0, (unsigned long *)b);
ですが、rt14では
CONFIG_SMP
CONFIG_DEBUG_SPINLOCK
のいずれかを定義している場合のみ生きるようになっていました。
寝る前になんとなくrtのページをリロードしたらrt14を発見w！
結果は・・・,めでたくブートしました:D
まだ1時間程度ですが、urbのエラーは出ていません。
例の include/linux/list_bl.hですが、修正が入っていました。
----------いちおうソースの修正部分を載せておきます ------------------
static inline void hlist_bl_lock(struct hlist_bl_head *b)
{
#ifndef CONFIG_PREEMPT_RT_BASE
bit_spin_lock(0, (unsigned long *)b);
#else
raw_spin_lock(&b->lock);
#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
__set_bit(0, (unsigned long *)b); -> rt13ではこれが生きていた。
#endif
#endif
}
static inline void hlist_bl_unlock(struct hlist_bl_head *b)
{
#ifndef CONFIG_PREEMPT_RT_BASE
__bit_spin_unlock(0, (unsigned long *)b);
#else
#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
__clear_bit(0, (unsigned long *)b); -> rt13ではこれが生きていた。
#endif
raw_spin_unlock(&b->lock);
#endif
}
-------------------------------------------------
CONFIG_PREEMPT_RT_BASEが定義されていない場合の処理との互換性を取るためかと思っていた
__set_bit(0, (unsigned long *)b);
__clear_bit(0, (unsigned long *)b);
ですが、rt14では
CONFIG_SMP
CONFIG_DEBUG_SPINLOCK
のいずれかを定義している場合のみ生きるようになっていました。
fHiro 2013/07/12(Fri) 02:29 No.3180
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
twl 2013/07/12(Fri) 07:50 No.3181
fHiroさん、rt14のおしらせ、ありがとうございました。
私も先程このrt14カーネルをbuild、問題なくbootできmpdも順調に稼働しています。とりあえず、ご報告まで。
twl
私も先程このrt14カーネルをbuild、問題なくbootできmpdも順調に稼働しています。とりあえず、ご報告まで。
twl
twl 2013/07/12(Fri) 07:50 No.3181
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
twl 2013/08/20(Tue) 07:24 No.3432
twlです。
このスレッドのタイトルで続けていいものかどうか迷いましたが、とりあえず報告です。
去る８月12日に3.10.6-rt3が発表されたことを以下のURLで知りました。特徴としてv3.8のパッチがいくつかあてられ、armではRT-FULLがサポートされたとのこと、
https://lwn.net/Articles/563165/" target="_blank">https://lwn.net/Articles/563165/
早速rtパッチ付きのカーネルをarchlinuxでビルドしてみました。古い3.8.11-rtから3.8.13-rtで用いていた.configがそのまま通り、昨夜からCuBox上で動いていますが、立ち上げから約９時間、mpdの再生は円滑、特にトラブルには遭遇しておりません。音質の評価は主観的なものですが、not badといったところです。
[root@alarmcubox ~]# uname -a
Linux alarmcubox 3.10.6-rt3_CuboxAudioRTuned #1 PREEMPT RT Mon Aug 19 09:31:48 JST 2013 armv7l GNU/Linux
top - 07:15:20 up 8:54, 1 user, load average: 0.67, 0.66, 0.60
KiB Mem: 2073228 total, 178192 used, 1895036 free, 9844 buffers
-snip-
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1091 mpd 20 0 79848 9160 4284 S 4.6 0.4 25:57.89 mpd
以前に3.10.4のrt kernelを試した際にはうまく動作しなかったのですが、今回のrt3パッチで旧3.8の環境が一部組み込まれたことにより、3.10-rtの環境にうまく移行できそうな気配です。
以上、おしらせでした。
このスレッドのタイトルで続けていいものかどうか迷いましたが、とりあえず報告です。
去る８月12日に3.10.6-rt3が発表されたことを以下のURLで知りました。特徴としてv3.8のパッチがいくつかあてられ、armではRT-FULLがサポートされたとのこと、
https://lwn.net/Articles/563165/" target="_blank">https://lwn.net/Articles/563165/
早速rtパッチ付きのカーネルをarchlinuxでビルドしてみました。古い3.8.11-rtから3.8.13-rtで用いていた.configがそのまま通り、昨夜からCuBox上で動いていますが、立ち上げから約９時間、mpdの再生は円滑、特にトラブルには遭遇しておりません。音質の評価は主観的なものですが、not badといったところです。
[root@alarmcubox ~]# uname -a
Linux alarmcubox 3.10.6-rt3_CuboxAudioRTuned #1 PREEMPT RT Mon Aug 19 09:31:48 JST 2013 armv7l GNU/Linux
top - 07:15:20 up 8:54, 1 user, load average: 0.67, 0.66, 0.60
KiB Mem: 2073228 total, 178192 used, 1895036 free, 9844 buffers
-snip-
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1091 mpd 20 0 79848 9160 4284 S 4.6 0.4 25:57.89 mpd
以前に3.10.4のrt kernelを試した際にはうまく動作しなかったのですが、今回のrt3パッチで旧3.8の環境が一部組み込まれたことにより、3.10-rtの環境にうまく移行できそうな気配です。
以上、おしらせでした。
twl 2013/08/20(Tue) 07:24 No.3432
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
fHiro 2013/08/20(Tue) 22:28 No.3433
twlさん、3.10.6-rt6のお知らせありがとうございます。
実は自分も3.10.4+rt2を軽く試したのですが、うまくビルドできなかったので、様子を見ておりました。3.10.6+rt試してみます。
3.8.13+rt14ですが、NASをcifs->nfsに変えたところurbエラーが頻発するようになったため、現状は最安定の3.8.11+rt8で使用しています。音質的にも3.8.13+rt14よりこちらの方が良い感じがします。
実は自分も3.10.4+rt2を軽く試したのですが、うまくビルドできなかったので、様子を見ておりました。3.10.6+rt試してみます。
3.8.13+rt14ですが、NASをcifs->nfsに変えたところurbエラーが頻発するようになったため、現状は最安定の3.8.11+rt8で使用しています。音質的にも3.8.13+rt14よりこちらの方が良い感じがします。
fHiro 2013/08/20(Tue) 22:28 No.3433
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
tinker 2013/08/21(Wed) 19:44 No.3434
twlさん
Cuboxでも出来るんですね。以前、別スレでPREEMPTでもエラーが出るようなこと書いてあったので、難しいのかと思ってました。
wandboard dlの場合は、以下のpatchを当てないとPREEMPT 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
一つ教えてください。
twlさんが記載されているmpdなんですが、RES，SHRとか%MEMが通常より極端に小さいようですが、何か特殊な事されていますか？
1091 mpd 20 0 79848 9160 4284 S 4.6 0.4 25:57.89 mpd
Cuboxでも出来るんですね。以前、別スレでPREEMPTでもエラーが出るようなこと書いてあったので、難しいのかと思ってました。
wandboard dlの場合は、以下のpatchを当てないとPREEMPT 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
一つ教えてください。
twlさんが記載されているmpdなんですが、RES，SHRとか%MEMが通常より極端に小さいようですが、何か特殊な事されていますか？
1091 mpd 20 0 79848 9160 4284 S 4.6 0.4 25:57.89 mpd
tinker 2013/08/21(Wed) 19:44 No.3434
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
twl 2013/08/22(Thu) 00:49 No.3435
tinkerさん、今晩は。
> Cuboxでも出来るんですね。以前、別スレでPREEMPTでもエラーが出るようなこと書いてあったので、
> 難しいのかと思ってました。
私はそういう知識もなくCuBoxを購入、指南場所としてのみみず工房でyoさんの書かれるままに従ってきただけなので、単に運がよかっただけなのだろうと思っております。カーネルをビルドしてからpreemptとかpreempt_rtの意味を後で学ぶようないい加減な人間ですので。
> 一つ教えてください。
> twlさんが記載されているmpdなんですが、RES，SHRとか%MEMが通常より極端に小さいようですが、
> 何か特殊な事されていますか？
そういうご指摘を受けるまではこれが当たり前なんだろうと考えておりましたが、このArchlinux/Cuboxで動くmpdによる負荷は軽めなんですね。でも、CPUに関してはBBBカーネルで行われているようなcpufrequtilsの設定などは行っておりません。/etc/mpd.confに関してもほぼdefaultに近い設定、buffer_time、period_timeおよびpriorityなどの設定は削除してあります。
mpdはgithub経由でコンパイルした0.17.4-DSDを用いていますが、正規の0.17.4版と大きな違いはないと思われます。ただしコンパイルの際、glib2-0がインストールされていない等、色々文句を言われるので、とりあえずglib-2.34.0をあらかじめコンパイル、インストールして./configureが通るようにしてあります。それでもあれがない、これがないと色々叱られるので、autoconfやautomakeをインストールした状態でautogen.shでconfigureを作成、これをもとにコンパイルしたmpdを使用しております。これは0.17.4のコンパイルでも同様です。ただ、%MEMが小さいのはおそらくビルドしたカーネルの性格がそのまま出ているのではと考えております。
実はBBBのスレッドを横目でみながら私も密かにBBBで遊んでいました (^^; 。しかしarchlinuxのrtカーネルビルドに比べ、かなり無理なパッチを当てないと動作しない状況、しかもそこまで努力してもpreempt_rtというかRT_FULLの環境が得られないというのは、patchの使用は最小限という私の趣旨と合わないので、現在は無理のない状況での設定でBBB上のmpdをCuBox上のmpdと比較試聴している状態です。
このスレッドとしては不適当かもしれませんが、比較のためにBBB上で動かしているDebian Wheezy版およびArchlinux版でのmpd動作状況を、現在のCuBoxの状況を含め、お示しさせていただきます。
用いたカーネルはDebianがBBB-eMMC-flasher-debian-7.1-2013-07-22.img(bone24が入っています)およびArchLinuxARM-am33x-latest.tar.gz(3.8.13-7-ARCH)です。Debian版ではDSD128まで途切れることなく心地よい音楽再生が得られていますが、Archlinux版ではDSD128は楽音の変質が著明、DSD64では一応正常な再生は可能なものの、静音時にプチプチと細かなノイズが発生します。いずれもPCM再生ではまったく問題ありません。
BBB arch
Linux alarm 3.8.13-7-ARCH #1 SMP Sat Jul 13 11:54:56 CDT 2013 armv7l GNU/Linux
top - 23:24:36 up 24 min, 1 user, load average: 1.18, 0.62, 0.40
-snip-
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
184 mpd 20 0 89156 11628 5484 S 4.6 2.3 1:20.77 mpd
BBB debian
Linux arm 3.8.13_0811+ #2 SMP PREEMPT Sun Aug 11 09:10:16 JST 2013 armv7l GNU/Linux
top - 23:27:32 up 0 min, 1 user, load average: 0.81, 0.24, 0.08
-snip-
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1894 mpd 20 0 72564 6752 1836 S 8.5 1.3 0:02.68 mpd
現在稼働中のCuBox Archlinux (3.10.6-rt3_CuboxAudioRTuned #1 PREEMPT RT)
top - 00:44:47 up 1 day, 8 min, 1 user, load average: 0.33, 0.47, 0.54
-snip-
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1088 mpd 20 0 79796 9168 4276 S 5.0 0.4 70:45.08 mpd
長文、お詫び申し上げます。
twl
> Cuboxでも出来るんですね。以前、別スレでPREEMPTでもエラーが出るようなこと書いてあったので、
> 難しいのかと思ってました。
私はそういう知識もなくCuBoxを購入、指南場所としてのみみず工房でyoさんの書かれるままに従ってきただけなので、単に運がよかっただけなのだろうと思っております。カーネルをビルドしてからpreemptとかpreempt_rtの意味を後で学ぶようないい加減な人間ですので。
> 一つ教えてください。
> twlさんが記載されているmpdなんですが、RES，SHRとか%MEMが通常より極端に小さいようですが、
> 何か特殊な事されていますか？
そういうご指摘を受けるまではこれが当たり前なんだろうと考えておりましたが、このArchlinux/Cuboxで動くmpdによる負荷は軽めなんですね。でも、CPUに関してはBBBカーネルで行われているようなcpufrequtilsの設定などは行っておりません。/etc/mpd.confに関してもほぼdefaultに近い設定、buffer_time、period_timeおよびpriorityなどの設定は削除してあります。
mpdはgithub経由でコンパイルした0.17.4-DSDを用いていますが、正規の0.17.4版と大きな違いはないと思われます。ただしコンパイルの際、glib2-0がインストールされていない等、色々文句を言われるので、とりあえずglib-2.34.0をあらかじめコンパイル、インストールして./configureが通るようにしてあります。それでもあれがない、これがないと色々叱られるので、autoconfやautomakeをインストールした状態でautogen.shでconfigureを作成、これをもとにコンパイルしたmpdを使用しております。これは0.17.4のコンパイルでも同様です。ただ、%MEMが小さいのはおそらくビルドしたカーネルの性格がそのまま出ているのではと考えております。
実はBBBのスレッドを横目でみながら私も密かにBBBで遊んでいました (^^; 。しかしarchlinuxのrtカーネルビルドに比べ、かなり無理なパッチを当てないと動作しない状況、しかもそこまで努力してもpreempt_rtというかRT_FULLの環境が得られないというのは、patchの使用は最小限という私の趣旨と合わないので、現在は無理のない状況での設定でBBB上のmpdをCuBox上のmpdと比較試聴している状態です。
このスレッドとしては不適当かもしれませんが、比較のためにBBB上で動かしているDebian Wheezy版およびArchlinux版でのmpd動作状況を、現在のCuBoxの状況を含め、お示しさせていただきます。
用いたカーネルはDebianがBBB-eMMC-flasher-debian-7.1-2013-07-22.img(bone24が入っています)およびArchLinuxARM-am33x-latest.tar.gz(3.8.13-7-ARCH)です。Debian版ではDSD128まで途切れることなく心地よい音楽再生が得られていますが、Archlinux版ではDSD128は楽音の変質が著明、DSD64では一応正常な再生は可能なものの、静音時にプチプチと細かなノイズが発生します。いずれもPCM再生ではまったく問題ありません。
BBB arch
Linux alarm 3.8.13-7-ARCH #1 SMP Sat Jul 13 11:54:56 CDT 2013 armv7l GNU/Linux
top - 23:24:36 up 24 min, 1 user, load average: 1.18, 0.62, 0.40
-snip-
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
184 mpd 20 0 89156 11628 5484 S 4.6 2.3 1:20.77 mpd
BBB debian
Linux arm 3.8.13_0811+ #2 SMP PREEMPT Sun Aug 11 09:10:16 JST 2013 armv7l GNU/Linux
top - 23:27:32 up 0 min, 1 user, load average: 0.81, 0.24, 0.08
-snip-
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1894 mpd 20 0 72564 6752 1836 S 8.5 1.3 0:02.68 mpd
現在稼働中のCuBox Archlinux (3.10.6-rt3_CuboxAudioRTuned #1 PREEMPT RT)
top - 00:44:47 up 1 day, 8 min, 1 user, load average: 0.33, 0.47, 0.54
-snip-
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1088 mpd 20 0 79796 9168 4276 S 5.0 0.4 70:45.08 mpd
長文、お詫び申し上げます。
twl
twl 2013/08/22(Thu) 00:49 No.3435
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
tinker 2013/08/22(Thu) 18:49 No.3437
twlさん
私のとこは、3.10.6をFULL RTに出来るまで1週間かかってます。やっぱり日頃の行いってやつでしょうか(笑)
twlさんのmpdはmpd-dsdのもので、RTパッチがかけてあるのかは分かりませんが、RTとしては動かしていないというところでしょうか。それでRESとかSHRが小さいんですね。
BBBは苦労しましたが、勉強になったことも沢山ありました。
今回3.10.6であれこれやったことも、BBBの方に還元できるかもしれないです。
先述のpatchは3.10.8に取り込まれたようです。
このpatchは3.8.xにも使えますので、このスレ本来の目的どおり3.8.13のエラーを回避できる可能性があります。
BBBではcpufrequtilsを使いましたが、Cubox，wandboardでは使っていません。
代わり（でもないですが）に、wandboardでは、Debian及びUbuntuにcgroup-binをインストールしてcgroupを使えるようにしています。何となく動いてはいるようです（CPU0,1でそれなりに負荷を分散）
top - 18:29:37 up 20:19, 1 user, load average: 0.00, 0.02, 0.05
Tasks: 75 total, 1 running, 74 sleeping, 0 stopped, 0 zombie
%Cpu0 : 1.1 us, 0.4 sy, 0.0 ni, 98.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 1.4 us, 1.0 sy, 0.0 ni, 97.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 1032624 total, 539132 used, 493492 free, 58900 buffers
KiB Swap: 0 total, 0 used, 0 free, 397516 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
56 root -54 0 0 0 0 S 9.6 0.0 129:44.75 irq/72-ci13xxx_
2369 mpd 20 0 83040 70m 25m S 2.3 7.0 26:07.33 mpd
2983 root 20 0 5704 1224 880 R 0.7 0.1 0:00.17 top
50 root -55 0 0 0 0 S 0.3 0.0 2:57.61 irq/150-2188000
1503 root -54 0 0 0 0 S 0.3 0.0 1:40.52 cifsd
私のとこは、3.10.6をFULL RTに出来るまで1週間かかってます。やっぱり日頃の行いってやつでしょうか(笑)
twlさんのmpdはmpd-dsdのもので、RTパッチがかけてあるのかは分かりませんが、RTとしては動かしていないというところでしょうか。それでRESとかSHRが小さいんですね。
BBBは苦労しましたが、勉強になったことも沢山ありました。
今回3.10.6であれこれやったことも、BBBの方に還元できるかもしれないです。
先述のpatchは3.10.8に取り込まれたようです。
このpatchは3.8.xにも使えますので、このスレ本来の目的どおり3.8.13のエラーを回避できる可能性があります。
BBBではcpufrequtilsを使いましたが、Cubox，wandboardでは使っていません。
代わり（でもないですが）に、wandboardでは、Debian及びUbuntuにcgroup-binをインストールしてcgroupを使えるようにしています。何となく動いてはいるようです（CPU0,1でそれなりに負荷を分散）
top - 18:29:37 up 20:19, 1 user, load average: 0.00, 0.02, 0.05
Tasks: 75 total, 1 running, 74 sleeping, 0 stopped, 0 zombie
%Cpu0 : 1.1 us, 0.4 sy, 0.0 ni, 98.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 1.4 us, 1.0 sy, 0.0 ni, 97.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 1032624 total, 539132 used, 493492 free, 58900 buffers
KiB Swap: 0 total, 0 used, 0 free, 397516 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
56 root -54 0 0 0 0 S 9.6 0.0 129:44.75 irq/72-ci13xxx_
2369 mpd 20 0 83040 70m 25m S 2.3 7.0 26:07.33 mpd
2983 root 20 0 5704 1224 880 R 0.7 0.1 0:00.17 top
50 root -55 0 0 0 0 S 0.3 0.0 2:57.61 irq/150-2188000
1503 root -54 0 0 0 0 S 0.3 0.0 1:40.52 cifsd
tinker 2013/08/22(Thu) 18:49 No.3437
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
twl 2013/08/22(Thu) 20:34 No.3439
tinkerさん wrote:
> 私のとこは、3.10.6をFULL RTに出来るまで1週間かかってます。やっぱり日頃の行いってやつでしょうか(笑)
いえいえ、BBBでのtinkerさんやyoさんの熱心なやり取りを拝見しておりますと、生半可な気合いではBBBに入っていけないなと思っていた次第です。
> twlさんのmpdはmpd-dsdのもので、RTパッチがかけてあるのかは分かりませんが、RTとしては動かしていない
> というところでしょうか。それでRESとかSHRが小さいんですね。
ご指摘のごとくRTパッチはかけておりません。そういうことがtopの結果に現れているのですね、なるほど。
> 今回3.10.6であれこれやったことも、BBBの方に還元できるかもしれないです。
> 先述のpatchは3.10.8に取り込まれたようです。
そうですか、それは楽しみですね。でもそうなるとCuBoxで結構満足している私ももう少し真面目にBBBに取り組む必要がおきそうです。
> このpatchは3.8.xにも使えますので、このスレ本来の目的どおり3.8.13のエラーを回避できる可能性があります。
実は今回CuBox上の3.10.6-rt3カーネルで皆様ご経験のURBエラーを初経験、めでたくお仲間になることができました (^^)。
ほぼ48時間連続稼働していたmpdから楽音が再生されなくなったので何事かと思って調べたらCuBoxがハングしていました。再起動してlogを見たら、おなじみのurb submitエラーの痕跡あり、エラーの出自をたどると以下のようなOopsエラーから出発していることが分かりました。
Aug 21 00:26:11 alarmcubox kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
Aug 21 00:26:11 alarmcubox kernel: pgd = ed220000
Aug 21 00:26:11 alarmcubox kernel: [00000000] *pgd=2d145831, *pte=00000000, *ppte=00000000
Aug 21 00:26:11 alarmcubox kernel: Internal error: Oops: 80000007 [#1] PREEMPT ARM
Aug 21 00:26:11 alarmcubox kernel: Modules linked in:
Aug 21 00:26:11 alarmcubox kernel: CPU: 0 PID: 1143 Comm: mpd Not tainted 3.10.6-rt3_CuboxAudioRTuned #1
Aug 21 00:26:11 alarmcubox kernel: task: ed094b40 ti: ed27e000 task.ti: ed27e000
Aug 21 00:26:11 alarmcubox kernel: PC is at 0x0
Aug 21 00:26:11 alarmcubox kernel: LR is at rt_spin_lock_slowlock+0x34/0x258
Aug 21 00:26:11 alarmcubox kernel: pc : [<00000000>] lr : [<c04742ac>] psr: 600f0013
Aug 21 00:26:11 alarmcubox kernel: sp : ed27fe08 ip : 000200d2 fp : 00000000
-snip-
Aug 21 00:26:11 alarmcubox kernel: [<c009c094>] (SyS_read+0x3c/0x70) from [<c000e240>] (ret_fast_syscall+0x0/0x30)
Aug 21 00:26:11 alarmcubox kernel: Code: bad PC value
Aug 21 00:26:11 alarmcubox kernel: ---[ end trace 0000000000000002 ]---
Aug 21 00:26:11 alarmcubox kernel: note: mpd[1143] exited with preempt_count 1
Aug 21 00:26:11 alarmcubox kernel: delay: estimated 0, actual 1103
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)
Aug 21 00:26:11 alarmcubox kernel: delay: estimated 1810, actual 1103
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)
Aug 21 00:26:11 alarmcubox kernel: delay: estimated 2161, actual 1103
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)
おそらく3.8.x-rtカーネルの伝統を引き継いだバグのようなので、debugを目的としたKernel Oops Reportを送るべき問題のようですが、とりあえずOopsによる被害はさして大きくないのでCuBoxではそのままこの新しいRTカーネルでmpdを動かしております。
twl
> 私のとこは、3.10.6をFULL RTに出来るまで1週間かかってます。やっぱり日頃の行いってやつでしょうか(笑)
いえいえ、BBBでのtinkerさんやyoさんの熱心なやり取りを拝見しておりますと、生半可な気合いではBBBに入っていけないなと思っていた次第です。
> twlさんのmpdはmpd-dsdのもので、RTパッチがかけてあるのかは分かりませんが、RTとしては動かしていない
> というところでしょうか。それでRESとかSHRが小さいんですね。
ご指摘のごとくRTパッチはかけておりません。そういうことがtopの結果に現れているのですね、なるほど。
> 今回3.10.6であれこれやったことも、BBBの方に還元できるかもしれないです。
> 先述のpatchは3.10.8に取り込まれたようです。
そうですか、それは楽しみですね。でもそうなるとCuBoxで結構満足している私ももう少し真面目にBBBに取り組む必要がおきそうです。
> このpatchは3.8.xにも使えますので、このスレ本来の目的どおり3.8.13のエラーを回避できる可能性があります。
実は今回CuBox上の3.10.6-rt3カーネルで皆様ご経験のURBエラーを初経験、めでたくお仲間になることができました (^^)。
ほぼ48時間連続稼働していたmpdから楽音が再生されなくなったので何事かと思って調べたらCuBoxがハングしていました。再起動してlogを見たら、おなじみのurb submitエラーの痕跡あり、エラーの出自をたどると以下のようなOopsエラーから出発していることが分かりました。
Aug 21 00:26:11 alarmcubox kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
Aug 21 00:26:11 alarmcubox kernel: pgd = ed220000
Aug 21 00:26:11 alarmcubox kernel: [00000000] *pgd=2d145831, *pte=00000000, *ppte=00000000
Aug 21 00:26:11 alarmcubox kernel: Internal error: Oops: 80000007 [#1] PREEMPT ARM
Aug 21 00:26:11 alarmcubox kernel: Modules linked in:
Aug 21 00:26:11 alarmcubox kernel: CPU: 0 PID: 1143 Comm: mpd Not tainted 3.10.6-rt3_CuboxAudioRTuned #1
Aug 21 00:26:11 alarmcubox kernel: task: ed094b40 ti: ed27e000 task.ti: ed27e000
Aug 21 00:26:11 alarmcubox kernel: PC is at 0x0
Aug 21 00:26:11 alarmcubox kernel: LR is at rt_spin_lock_slowlock+0x34/0x258
Aug 21 00:26:11 alarmcubox kernel: pc : [<00000000>] lr : [<c04742ac>] psr: 600f0013
Aug 21 00:26:11 alarmcubox kernel: sp : ed27fe08 ip : 000200d2 fp : 00000000
-snip-
Aug 21 00:26:11 alarmcubox kernel: [<c009c094>] (SyS_read+0x3c/0x70) from [<c000e240>] (ret_fast_syscall+0x0/0x30)
Aug 21 00:26:11 alarmcubox kernel: Code: bad PC value
Aug 21 00:26:11 alarmcubox kernel: ---[ end trace 0000000000000002 ]---
Aug 21 00:26:11 alarmcubox kernel: note: mpd[1143] exited with preempt_count 1
Aug 21 00:26:11 alarmcubox kernel: delay: estimated 0, actual 1103
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)
Aug 21 00:26:11 alarmcubox kernel: delay: estimated 1810, actual 1103
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)
Aug 21 00:26:11 alarmcubox kernel: delay: estimated 2161, actual 1103
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)
Aug 21 00:26:11 alarmcubox kernel: cannot submit urb (err = -18)
おそらく3.8.x-rtカーネルの伝統を引き継いだバグのようなので、debugを目的としたKernel Oops Reportを送るべき問題のようですが、とりあえずOopsによる被害はさして大きくないのでCuBoxではそのままこの新しいRTカーネルでmpdを動かしております。
twl
twl 2013/08/22(Thu) 20:34 No.3439
Re: arch linux kernel 3.8.13 + rt12 patchで問題解決
yo 2013/08/22(Thu) 22:16 No.3440
このスレッド、長くなりましたので、「kernel3.8/10と最新rtパッチでトラブル」というタイトルで続けます。
yo 2013/08/22(Thu) 22:16 No.3440
