イメージよろしくお願いします。 投稿者：yukiki 投稿日：2013/04/20(Sat) 22:58 No.2615    以前カーネルを「置く」件でお世話になった素人です。また今回も当方にとってはハードルが高い内容でした。雛祭りバージョンのような完成したイメージを期待致します！是非よろしくお願いします。 Re: イメージよろしくお願いします。 - yo 2013/04/21(Sun) 17:31 No.2626    yukikiさん > また今回も当方にとってはハードルが高い内容でした。 というのは何のことでしょうか。教えて頂けますか。 Re: イメージよろしくお願いします。 - yukiki 2013/04/21(Sun) 21:54 No.2629    ご回答ありがとう御座います。恥ずかしながら3.8への対応の箇所で「指定」であったり追加であったりと手を加える部分がよく理解出来ないだけです・・・。出来上がったイメージをＳＤカードへ落として、NASの設定をする程度で使用させて頂いている程度の知識です。こんな輩もいるのか程度で覚えて頂けると幸いで御座います。 Re: イメージよろしくお願いします。 - yo 2013/04/22(Mon) 18:40 No.2632    yukikiさん 3.8カーネルのことでしたか。了解です。 arch linux との相性がとてもいいので(音もかなりレベルアップされます)、この形で公開するつもりです。ただ、まだバタバタの状態(別のスレッドでやりとりしています)で、とても公開できるレベルではないので、暫くお待ちください。 Re: イメージよろしくお願いします。 - yukiki 2013/04/23(Tue) 01:21 No.2636    期待して気長に待っています！よろしくお願いします。

CuBoxのシリアル出力はWindows標準ドライバーで認識 投稿者：koji 投稿日：2013/04/19(Fri) 13:16 No.2603    先程、初投稿をさせて頂きましたkojiです。 　一昨日、Cuboxを入手して、インストールや色々な設定でいじりました。 　それで、この手の、モニター画面から離れた場所に設置するマシンとして、シリアル接続端子が最初から内蔵されているのは大変便利だなと思いました。 　オーディオセットを設置している場所と、PCのモニター画面等を設置している場所が離れていることが多いと思います。 　以前、使っていたAtomマシンでは最初のインストールとネットワーク設定までをモニター画面のあるところで作業して、その後オーディオセットのある場所にもっていきSSH経由で色々なと設定を進めました。 （こちらのマシンは安定していたのでハングアップしたり、ブートの途中でこけることがなかったので不都合は感じませんでしたが） 　ただ、こうした場合、SSHデーモンが立ち上がってくれるところまで進んでくれないと、SSHでログインでマシンの状態をモニターすることもできません。また、IPアドレスがDHCPだと接続の度に変わることもあったりで、ログインするまでに手間取る感じがあります。 　CuBoxは、マイクロUSB端子からUSBで接続すれば、シリアルコンソールからログインできるようになっています。 　入手以前に調べていた情報では独自ドライバーをWindowsマシン側にインストールしなければいけないのかなと思っていたら、最近は、Windows7の標準ドライバー？で認識・接続が問題なくできるようです。 　接続して、すぐにTeraTermでシリアル接続することができました。これならば、ノートPCをオーディオセットの近くまで持っていき、ブート段階からずっと見ながら動作を確認しつつ、設定ができました。 　もちろん、設定が終わり、IPアドレスも固定し、SSHデーモンも着実に立ち上がるようになれば、LAN経由で離れたところにあるデスクトップマシンからSSHで入っていじるのをメインにしています。 　ただ、LAN経由で上手くログインできなくなった時に、シリアル経由でCuBoxに入れるというのは、色々といじる上では安心感がとても大きいなと感じました。 　これから、しばらく色々といじって楽しめそうです。 　 Re: CuBoxのシリアル出力はWindows標準ドライバーで認識 - yo 2013/04/19(Fri) 22:12 No.2606    どっかに書いた記憶があるのですが、シリアル接続無しというのは「羅針盤なしにlinuxの荒海を航海する」ようなもので、起動時のトラブルに出会った時はお手上げになりますね。 僕の場合、SmartTVBoxがこれで、起動できないと、手も足もでないです。別のスレッドでtinkerさんに教えてもらったカーネルソースも今のところこれで止まっています。 Re: CuBoxのシリアル出力はWindows標準ドライバーで認識 - koji 2013/04/19(Fri) 22:55 No.2608    yoさん、kojiです。 リプライどうもありがとうございます。ちょうど、先程、別スレッドに書き込みをしていたところです。 > シリアル接続無しというのは「羅針盤なしにlinuxの荒海を航海する」ようなもの 　至言ですね!全く同感です。 　以前、玄箱にDebianを入れて、ファイルサーバや、DLNAサーバーに使っていた時がありました。 　ただ、新しいカーネルソースを持ってきて、コンパイルして再起動したところ、立ち上がりなくなってしまったことがありました。 　ブートの途中で止まってしまっているので、telnetやsshで入りようがなくて、万事休すみたいなことになったことがありました。 　そうしたことがあったので、今回、CuBoxを導入したところ、最初からマイクロusb経由でシリアル接続ができるようになっているのに感心しました。 USB−シリアルの変換ケーブルすら不要ですし、たまたまなのか、私のWindowsマシンでは接続して自動で入ったWindowsの標準ドライバーで何一つ問題なく、認識・接続できました。 　接続当初、エラーメッセージのようなものがずっと出ていましたが、dmesgにn1オプションを与えてやることで、メッセージ表示を抑止することができました。 　それで、その後のCuBoxの設定は、ずっとシリアル接続のコンソール画面で行いました。その間、Linux自体が立ち上がらなくなるということはなかったので、結果的にはSSHでも問題なく設定作業はできたのかも分かりませんが、やはり、色々いじっている時は、いざという時にもシリアルで見れるのは大きな保険のようなものだなと思いました。 　「癖のあるマシン」なのかも分かりませんが、色々といじりがいのある可愛いマシンというのが、CuBoxの印象です。 Re: CuBoxのシリアル出力はWindows標準ドライバーで認識 - yo 2013/04/20(Sat) 18:09 No.2611    kojiさん 僕はcuboxの前は玄柴(とSheevaPlug)を使っていました。これはシリアルがあったので、楽でしたね。 > 「癖のあるマシン」なのかも分かりませんが、色々といじりがいのある可愛いマシンというのが、CuBoxの印象です。 この手のarmアーキテクチュアのマシンはどれもそれなりの癖はありますね。cuboxもいろいろ問題はありますが、比較的使いやすい方かなと僕は思います。 Re: CuBoxのシリアル出力はWindows標準ドライバーで認識 - koji 2013/04/20(Sat) 22:59 No.2616    yoさん、どうもkojiです。 　玄柴ですね。私も、一時購入しようかなと思ったのですが、ちょうど、その頃、Atomの小型マシンを入手することができたので、結局、そちらの方は手を出さずじまいでした。 　私の使ったのは初代玄箱でしたが、玄柴はシリアルが内蔵されていたのですね。 　玄柴で思いだしたのですが、この手のマシンだと、後、ぷらっとホームさんがのOpenBlocksもありましたね。 　かなり以前に、これの初代が出てきた時は、珍しかったこともあって、とても注目していました。 　確かに、arm系はCPUは同じでも、それぞれ個性がありますね。Debianは、そうしたarm系のバージョンも出し続けてくれるのでありがたいですね。 　この手のマシン好きなので、ついつい色々と書き込んでしまいましたが、これからもよろしくお願いします。 Re: CuBoxのシリアル出力はWindows標準ドライバーで認識 - tinker 2013/04/20(Sat) 23:42 No.2617    kojiさん >初代玄箱 私もDebian化して遊んでました。たしかPowerpcでしたね、懐かしいです。 Re: CuBoxのシリアル出力はWindows標準ドライバーで認識 - yo 2013/04/21(Sun) 17:30 No.2625    皆様 玄柴はSheevaPlugのOEMですね。SheevaPlugは真っ白なのに対して、玄柴は真っ黒けです。いまもファイルサーバとして活躍しています。 僕はarmアーキテクチュアというのは苦手で(といいながら4台持っているわけですが^^;;;)、x86仕様で省電力、ヘッドレスのこういうガジェトマシンが出てこないかなと思っています。 Re: CuBoxのシリアル出力はWindows標準ドライバーで認識 - tinker 2013/04/21(Sun) 18:05 No.2628    >x86仕様で省電力 同感ですね。インテルNUCがもっと安くなって、10w以下で動くようになったら使ってみたいです。 インテル Atom Onboardマザーボード BOXDN2800MTなんかを100均のタッパにでも入れて、USBでブートなんかでもいいかなも考えてます。 Re: CuBoxのシリアル出力はWindows標準ドライバーで認識 - koji 2013/04/22(Mon) 13:51 No.2631    tinker様、はじめまして、kojiです。 　私は、arm版のDebianを入れた記憶があるので、 初代ではなく、その次のHGだったかも分かりません。 　いずれにせよ、懐かしいですね。 　でも、子どもの時からのラジオ工作とオーディオ、それとLinuxという二つの趣味が、今交差しているような気がしていて、とても楽しいですね。 　私の子ども時代には、ICとかオペアンプへの移行が始まり（それまでの真空管やトランジスタ時代に比べて）いじるところが少なくなってたような印象がかつてあったのですが、今、PCオーディオは真空管時代のような手作り感が残っていて、面白いです。 　今後ともよろしくお願いします。 Re: CuBoxのシリアル出力はWindows標準ドライバーで認識 - tinker 2013/04/22(Mon) 18:44 No.2634    こちらこそよろしくお願いします。 ここでは少数派のnfsでやってます。roでmountしているのでasyncとかつけて、少しでも早くなれば良いなとか足掻いてます。

cubox pro でUSBメモリに置いた、WAVが再生できない。 投稿者：tairasuke 投稿日：2013/04/21(Sun) 01:28 No.2618    初めまして、最近cunbox proを入手した tairasukeと申します。 VoyageMPDのように自動認識すると 勘違いして、苦戦している者です。 雛祭りバージョンで起動し、XMOS DDCにて NCMPCから見れる、インターネットラジオは 再生できるのですが、USBメモリに置いた.WAV ファイルがマウントできても、DBを更新しても USBが現れません。 SATAでしか読めないようになっているのでしょうか？ NASやSATAでの環境では無いので、御教授願えれば ありがたく存じます。 Re: cubox pro でUSBメモリに置いた、WAVが再生できない。 - yo 2013/04/21(Sun) 17:28 No.2624    tairasukeさん マウントは出来ているようなので、多分、/etc/mpd.confへの音楽用ディレクトリへのリンクがされていないだけだと思います。具体的には mount /dev/sda1 /mnt/usbmem とされ、音楽用ディレクトリは/mnt/usbmem/CDという名前だとすると ln -s /mnt/usbmem/CD/ /var/lib/mpd/music/music で上手くいくと思います。

cannot submit urb (err = -27) -2 投稿者：kid 投稿日：2013/04/21(Sun) 11:58 No.2619    昨日の作業その1 130303のイメージを16GのmicroSDHCに書き込んでから別マシン(ubuntu)に接続、各パーティション内容をtar 書庫に抜き出し。 その後、パーティシンを全部ext3で作成して書庫から書き戻し。 これで起動したubuntuは、xfs構造体のエラーは出ません。 しかしながら、latencytopはインストールできませんでした。リポジトリで解決できないみたいです。それともソフトが存在しないのかな? 2Gで構造体エラーが出なかったのは、パーティションサイズ変更の為に、今回と同様の手順(フゥーマットして流し込み)を とった事が理由だったのかも知れません。 作業その2 Debian 側に17-CFQとlatencytopのインストールを行いました。 latencytopでは使い方が拙いのか問題点は見つけられませんでした。 但し、この版では、gmpcで再生中に「音切れ」が発生すると、gmpcのmpdとの接続が切れているようです。 接続が切れるから音が切れているのか、音が切れる事の原因によって接続が切れるか・・・・。 ubuntu側では、音が止まってしまってもCPUを占領しているプロセスもないし、gmpcの接続は持続したままですので、debianでの挙動はいささか異なっています。 ・・・で、気がついたことをいくつか。 debianで /run/shm/mpd が存在しません。mpd.logが巨大になっています。 ubuntuで、/run/shm/mpd/mpd.logに　mpd.conf の二つ目のdecoder { ... } の解釈ができないみたいなエラーが書かれています。 Re: cannot submit urb (err = -27) -2 - kid 2013/04/21(Sun) 12:31 No.2620    ubuntu で、一曲だけQueueに登録し最後まで再生したら、再生終了時にgmpcのステータスが"Not Connected"になります。 ターミナルは 定期的に"error: Timeout" と出ます。 現状は 17-CFQ + 18y (172sでも同じ) です。reboot以外では直らないみたいです。 Re: cannot submit urb (err = -27) -2 - tinker 2013/04/21(Sun) 13:04 No.2621    selboot 10-CFQ >ソフトが存在しないのかな? http://ja.wikipedia.org/wiki/APT Re: cannot submit urb (err = -27) -2 - kid 2013/04/21(Sun) 13:48 No.2622    こんにちは tinkerさん ubuntu では armで動くlatencytopが存在はないような気がします。 でも、debianには存在する訳ですから、debian用を落としてきてインストールすれば動くのではなかろうかとも思います。 「selboot 10-CFQ」と書かれた意味が不明なのですが、10-CFQを利用の場合は題記のエラーは出ないみたいです。 さらに、mpd stop で stateの退避・復元も更新をしてから行われているみたいです。 Re: cannot submit urb (err = -27) -2 - tinker 2013/04/21(Sun) 15:58 No.2623    >動くのではなかろうかとも思います かもしれませんが、普通はこうします。実行されるときは最後まで読んだあと、自己責任で。 apt-get update apt-get upgrade apt-get install latencytop >「selboot 10-CFQ」と書かれた意味 16-〜（3.6.9）は、相性が悪くまともに動かないdacやddcが存在する。 yoさんもご存知ですが、それがどのdacなのかは個人で把握することは無理でしょう。10-〜は16-〜で動かないdacやddcで動く可能性がある。ただ好みですが16-〜の音の評価のほうが高いようです。 たまたま相性の悪い機器だった場合の対処法は、 ・yoさんが実験中の3.8系のリリースを気長に待つ ・他の機器を試す ・自分で動くものを構築する ・あきらめる 音質重視や今の環境を崩したくないとapt-get upgradeしない方もおられるようです。10-CFQで動くのであればlatencytopのことはしばらく忘れたほうが良いのではないでしょうか。

Cuboxでお勧めの電源対策は？ 投稿者：koji 投稿日：2013/04/20(Sat) 22:46 No.2614    suさん、はじめまして。kojiです。 　私の方で、別スレッドで話題をふってしまい申し訳ありませんでした。新しく、電源対策についてのテーマで移りなおしました。 suさん --------------------------------------------------------- 電源対策ですが、たまたま電源アダプタ付きのHiFi USB NOISE FILTERを試用する機会がありました。評判ほどには、あまり変わらんなあ・・と思いながら、ふと、電源をCuboxに流用してみましたら、これは驚いた。かなり劇的な効果でした。ソフトになり、解像度が数段上がり、へんな響きを伴わない、素直な音に変化しました。フィルターはバスパワー側で使用し、電源はCuboxに回す方が効果的みたいです。試用したFIDELIXの電源は、定常時の電圧が5.04V、電源投入時のピークで5.09Vでしたので、安全に使えると思います。同等品を自作するのも手かなあと思います。 --------------------------------------------------------- 　こういう製品があるのですね。ゆっくりと、この製品のウェブサイトを見てみるようにします。 　 suさん -------------------------------------------------------- バッテリーも試したいと思いますが、Cuboxを破壊しないためには出力を安定化する必要があり、ノイズの面ではどうかなと思っています。 -------------------------------------------------------- 　Cuboxは、定格電圧の幅が狭いというか、厳しいみたいですね。せっかくのCuboxをダメにすることのないように、慎重に選びたいと思います。 　また、色々と情報交換の程、よろしくお願いします。