MPD on Cubox(18)
公開したcuboxのイメージではプライオリティの設定やmpd関連のファイルのメモリ常駐化をブート時の処理で行っていますが、この方法について紹介します。
ブート時に処理を行う自作スクリプトの一覧です。
| スクリプト名 | 処理内容 | 置き場所 |
|---|---|---|
| rtset.conf | プライオリティの設定 | /etc/init.d/rtset.conf |
| shmset.conf | mpd関連のファイルのメモリ常駐化 | /etc/init.d/shmset.conf |
| rc.local | cifsプライオリティの補正他 | /etc/rc.local |
処理内容について補足します。
rtset.confはブートじに、優先度の設定を行っています。
chrt -f -p 54 `pgrep irq/24-ehci_hcd`
chrt -f -p 55 `pgrep irq/29-eth0`
chrt -f -p 53 `pgrep cifsd`
ターミネート時にled表示の停止を
echo default-on > /sys/class/leds/cubox:red:health/trigger
sleep 1
echo none > /sys/class/leds/cubox:red:health/trigger
(led表示の停止は最後のコマンドだけでOKなはずなのですが、上手くいかないことがあるので、一旦点灯させ、時間をおいてから、実行させています)。
shmset.confは tag_cache、state、sticker.sqlをブート時に/var/lib/mpd/から、/run/shm/mpdに作成し、
mkdir /run/shm/mpd
cp /var/lib/mpd/tag_cache /run/shm/mpd
cp /var/lib/mpd/state /run/shm/mpd
cp /var/lib/mpd/sticker.sql /run/shm/mpd
touch -r /var/lib/mpd/tag_cache /run/shm/mpd/tag_cache
touch -r /var/lib/mpd/state /run/shm/mpd/state
touch -r /var/lib/mpd/sticker.sql /run/shm/mpd/sticker.sql
chown -R mpd:audio /run/shm/mpd
echo "update"
ターミネート時に保存させています。
if [ ! -e /var/lib/mpd/tag_cache ] || [ /run/shm/mpd/tag_cache -nt /var/lib/mpd/tag_cache ]
then
cp /run/shm/mpd/tag_cache /var/lib/mpd/
echo "new tag"
fi
if [ ! -e /var/lib/mpd/state ] || [ /run/shm/mpd/state -nt /var/lib/mpd/state ]
then
cp /run/shm/mpd/state /var/lib/mpd/
echo "new state"
fi
if [ ! -e /var/lib/mpd/sticker.sql ] || [ /run/shm/mpd/sticker.sql -nt /var/lib/mpd/sticker.sq$
then
cp /run/shm/mpd/sticker.sql /var/lib/mpd/
echo "new sticker.sql"
fi
rc.localは以下の通りです。
mount /dev/mmcblk0p1 /media chrt -f -p 53 `pgrep -n cifsd` chrt -f -p 53 `pgrep -o cifsd` /usr/local/sbin/led
最初のmountはselboot、selpartのためのものです。その後のcifsdの優先度の設定はrtset.confの設定だけでは起動タイミングが合わないので、ここで補正しています。最後はled表示のスクリプトの起動。
これらのスクリプトをブート時やターミネート時に起動させるためには標準の書式に合わせる必要があります(rc.localは除く)。この標準の書式は /etc/init.d/skeleton にあります。rtset.confの場合はこんな具合です。
#!/bin/sh
### BEGIN INIT INFO
# Provides: rtset
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Set RT priority at boot time
# Description: Set RT priority at boot time
### END INIT INFO
rtset_start () {
....
}
rtset_stop () {
....
}
case "$1" in
start)
rtset_start
;;
stop)
rtset_stop
;;
*)
echo "Usage: $0 {start|stop}"
exit 2
;;
esac
「BEGIN INIT INFO」から「END INIT INFO」までが、ヘッダー行です。これがないと、後記するスクリプトの登録が綺麗に出来ないので適当に作成しておきます。rtset_startとrtset_stopに実際の処理行を書いて、case文で呼び出すという形をとります。
作成したスクリプトについては実行権を付ける必要があります。
chmod 755 /etc/init.d/rtset.conf chmod 755 /etc/init.d/shmset.conf
以上の内容についてはここに丁寧な解説があります。
こうやって作成したスクリプトをブート時、ターミネート時の処理に組み込む方法ですが
update-rc.d -f shmset.conf start 20 2 3 4 5 . stop 01 0 1 6 . update-rc.d -f rtset.conf start 80 2 3 4 5 . stop 01 0 1 6 .
で出来ます。rc.localの起動はカーネルの処理に組み込まれていますので、登録は不要です。
update-rc.dの使い方についてはここを参照して下さい。
登録したスクリプクトの削除は
update-rc.d -f rt.conf remove update-rc.d -f shmset.conf remove
となります。
以上の内容はubuntu、debianで共通なのですが、linuxの世界、そんなに甘くはない(^^;;;。どういうわけかdebianの方はupdate-rc.dのstartの後の起動順番の指定が上手くいかないのですよね。
仕方がないので、rc.localで補正するという方法をとっています。
linuxの起動スクリプリトに関してはこのヘージが面白いです(RHLの話なので、Debian系列とは多少異なります)。作者は中小企業の現役IT担当者だそうですが、そのシステム奮闘記というブログの記事です。linuxの仕組みを知りたい方にはお勧め。
(PC_Audio) 2013/05/18
掲示板表示方法の変更
ここのところ掲示板でやりとりしたトピックをこちらに書き込むことが多くなっています。掲示板で情報共有し、いろいろやりとりして展開し、整理し終わったら、サイトに書き込むというスタイルはとても効果的ですね。という次第で、なるべく多くの方に参加して頂きたいと思っています。
問題はこのスクリプト、大変に重宝していますが(作者には感謝です)、古いタイプなので、多少癖のあること。
コードやダンプをそのまま書けるとか、サイズをいくらでも大きくできるとか、リンクをいくら書き込んでもいいなどメリットは大きいです。
ただ、最新のブログで使われているコメント欄などと比較すると、機能面では多少見劣りします。一番不便なのは、スレッドが大きくなると最新の書き込みまで辿り着くのに時間がかかることです。トラブル対応の書き込みなどどんどんスレッドが大きくなると、最新の書き込みに到着するのにPageDownキーを連打しないといけないので大変です。
という次第で、トップ画面をトピックビューに変更し、フォーマットも多少変えてみました。
after
before
という具合です。これで最新の記事タイトルをクリックし、ctrl+［End］(firefoxの場合)すれば、最新の書き込みを読むことができます。一週間以内に変更されたスレッドはボールド表示してあります。クッキーを使って読んでないスレッドだけ表示することも可能だと思いますが、ヘッポコプログラマには大変なので、パスです(^^;;;。
新規書き込みのフォームがトップ画面にないのが気にはなりますが、画面上段の ［new message］をクリックすれば表示できますので、この方法で対応して下さい(もちろんスレッド表示に戻して新規書き込みすることも出来ます)。
あとは、自分用のメモですが、変更したのはlib/list_log_topic.plだけ。トップ画面の変更はinit.cgiで対応出来ました。
list_log_topic.plの変更は表示順番とスレッド行の書き込みの部分で最終書込み時間と現在時間を比較し、1週間以内ならボールドにしただけ。全部で20行位です。日時の比較はperlのtimelocal関数を使って、簡単に出来ました。楽なものですね。
(others) 2013/05/11
カウントダウン・メルトダウン
福島第一原子力発電所事故の詳細を描いたノンフィクションドキュメンタリー、上下2巻900ページを超える大作です。各種事故調査委員会の報告書を読む気力はないので(^^;;;、こちらを読んでみました。作者は船橋洋一さん。民間事故調の推進役でジャーナリストです。
「カウントダウン・メルトダウン」というタイトルは(福島原発、日本の原子力政策、東電、原子力ムラの)メルトダウンの過程を、現地、官邸、東電、原子力ムラ、米国など様々の関係者のからみあいを中心にカンウントダウンしながら記述したという意味らしいです。
福島原発事故とは、NRCカストー日本サイト支援部長によると
「人類の歴史の中でフクシマは『自然と物理学』との戦いを極限まで強いられた戦場だった。戦争の一歩手前、しかし、戦争よりある意味ではもっと過酷な試練だった。戦争では降伏という選択がある。しかし、フクシマではそんな贅沢は許されない。自然と物理学とどこまでも戦い抜く以外ない。サンフラシスコ大地震からスリーマイル、あるいはチェルノブイリまでの70年間の試練をフクシマではわずか7日間で経験した」
ということらしいです。
内容は下手なスリラー小説顔負けの怖さ。
刻一刻と日本崩壊の危機がせまるのに、必死に頑張る現場を置いてけぼりに、有効な対策を打ち出せない官邸、逃げまくる東電本社、保身に走る霞が関の官僚、まったくピンぼけの原子力ムラ、ハラハラするだけのアメリカといった関係者の姿がリアルに記述されています。怖いですよ。
最終章は、なんと「神の御加護」というタイトルです。最悪の事態を避けることが出来たのは「神の御加護」によるという意味です。凄いタイトルですね。被害にあった皆様には申し訳ありませんが。
「神の御加護」とは
- 地震が日中に起こった。夜に起こったら、初期の救援活動がはるかに難しかっただろう。
- 土日ではなく平日の金曜日だった。そのため多数の従業員がプラント内で働いていた。
- 風向きが11日から14日まで太平洋の方に吹いていた。もし、この間、風が内陸に向かって吹いていたら、放射能汚染ははるかに深刻だっただろう。
- 14日の3号機水素爆発の際、自衛隊に負傷者を出したが、奇跡的に死者が出なかった。死者が出ていた場合、その後の作戦はもっと難しくなっただろう。
- 4号機の燃料プールに何かの弾み(3号機の水素爆発?)で4号機炉内の水が流れ込み、水量が維持できた。(以降は補筆です)、もし、水量が維持できなかったら、数十倍の放射能が放出され、東日本全体が汚染されていただろう。
- 4号機の爆発と同時に2号機のサプレッション・チャンバーの圧力が急低下した。どこかに穴があいて、大量の放射性物質を放出した。そのことは不幸なことだったが、そのため格納容器そのものの爆発を防ぐことができた。もし、2号機格納容器が爆発していたら、誰も近づけなくなっていただろう。
- 地震発生の30分後に株式市場が閉まった。緊急対応の時間的余裕ができ、14日月曜日の政府・日銀の緊急措置が効果的に行えた。
- 放射能リスクが米大陸まで及ばなかった。もし、及んだ場合は、トモダチ作戦はまったく正確の異なるものとなっていただろう。
ということです。なるほどなぁ。
この時、「MPD on 玄箱」に熱中していたのですが(こことここに日記風に書いています)、能天気でしたね。
まあ、事態が楽観できないとは知っていたが、これほどとは知りませんでした。この国からみると、元寇以来の悪運(^^;;;の強さですね。
(review) 2013/04/27
cubox カーネル3.8+RTPatchのビルド方法
掲示板でやりとりをして、ビルド方法が分かりましたのでご紹介します。情報を提供していただいた t-taさんに感謝します。
linuxのカーネルは3.8になって大幅な修正が入ったようで、例えば以前話題にした dma coherent_pool の作成方法が変ったとか、rtカーネルで「Fully Preemptible Kernel」指定して「High Memory Support」が可能になった(これでcuboxのメモリを1GBに戻せます)などいろいろな改良がされています。音の印象もかなり変わります。環境次第だとは思いますが、僕の環境ではこちらの方がいいです。
cuboxのカーネルのビルド方法についてはこのサイトのあっち-こっちに書いたので、そちらを参照して下さい。説明済の部分はコマンドのみ羅列しておきます。
また、arm用の開発環境は準備されているという前提で説明します。最後のモジュールの展開以外は全て開発環境での作業です。
# ソースとパッチのダウンロード(アドレスは変わっているかもしれません) wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.8.4.tar.xz wget https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patch-3.8.4-rt2.patch.bz2 # 展開 tar -Jxvf linux-3.8.4.tar.xz # 展開ディレクトリに移動 cd linux-3.8.4 # パッチの適用 bzcat ../patch-3.8.4-rt2.patch.bz2 | patch -p1 # 環境変数の設定 export ARCH=arm export CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf-
さてここからが3.8対応のための部分です。
コンフィグの準備
コンフィグはt-taさんが作成されたものがお勧めです(というか 3.6以前のものは使えません)。
リンク先からダウンロードしてもいいのですが、wgetを使えないので、僕はテキストの内容をcopy&pasteしました。
emacs .config リンク先のテキストをcopy&paste
コンフィグを修正
make menuconfig
以下を修正する必要があります。
Device Drivers ---> Generic Driver Options --->
ディフォルトの状態に対して
「path to uevent helper」を削除 「Maintain a devtmpfs filesystem to mount at /dev」から「Include in-kernel firmware blobs in kernel binary」までを指定 「Contiguous Memory Allocator」を指定 「Size in Mega Bytes」を128MBに
以上を変更する理由については、掲示板のこの書き込みとこの書き込みを参照して下さい。
makeの仕方も3.8になって変わりました。
make -j2 uImage cp arch/arm/boot/zImage arch/arm/boot/zImage.orig make dtbs cat arch/arm/boot/zImage.orig arch/arm/boot/dts/dove-cubox.dtb > arch/arm/boot/zImage make -j2 uImage
なにが変わったかというと「make dtbs」によって
Build device tree blobs for enabled boards
する作業が必要になったことです。変わった理由についてはこのページで詳しく解説されていますので、そちらを参照して下さい。
次にモジュールの作成
make -j2 modules mkdir ../modules INSTALL_MOD_PATH=../modules make modules_install # cd to user directory sudo chown -R root:root modules cd ../modules sudo tar zcf ../modules.tar.gz *
これはj2指定が必要なことを除いて、以前debianのインストールで解説した内容と同じです。
次にboot.scrを作成する必要があります。
cd .. emacs boot2.txt 以下の内容を書き込み、保存 echo ======== Setting bootargs ======== setenv bootargs 'console=ttyS0,115200n8 vmalloc=144M coherent_pool=96M root=/dev/mmcblk0p2 rw rootdelay=3 --no-log --verbose' echo ======== Loading kernel ======== ext2load mmc 0:1 0x00200000 /boot/uImage echo ======== Booting kernel ======== bootm スクリプトを作成 mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n 'Boot setup script for SD' -d boot2.txt boot.scr
これはrootfsが2番目のパーティションに置いた場合のスクリプトです。他のパーティションを使う場合は「root=/dev/mmcblk0p2」の「2」を適当な変えて下さい。ポイントは「root=/dev/mmcblk0p2」の直後にある「rw」という指定です。これがないとubuntu-coreやarchのrootfsだとログインメッセージに辿り着けません。詳しくは掲示板のこのあたりを参照して下さい。
あとは作成したuImage、modules.tar.gzとboot.scrを起動用マイクロsdカードにコピーして開発環境での作業は終わりです。
mkdir /media/boot mkdir /media/rootfs sudo mount /dev/sdb1 /media/boot sudo mount /dev/sdb2 /media/rootfs mkdir /media/boot/boot cp linux-3.8.4/arch/arm/boot/uImage /media/boot/boot/ cp modules.tar.gz /media/boot/ cp boot.scr /media/boot/boot/
あとは作成したsdカードでcuboxを起動し、モジュールを展開します。
mount /dev/mmcblk0p1 /media cd / tar pxvzf /media/modules.tar.gz
(PC_Audio) 2013/04/19
latencytop
これは掲示板でNukbeeさんとPhoeniciaさんに教えてもらったものです。使ってみるとなかなか面白いので、ご紹介します。
latencytopというのはtopのlatency版です。現在稼働中のプロセスの中でどこにlatencyが発生しているかをリアルタイムに表示してくれる。latencyというのはコンピュータ内で発生する処理待ちの時間のことで、音楽再生の場合は音切れ(ノイズ)の原因となります。詳しくはここ(コンピュータの場合なので、割り込みレイテンシーのことです)を参照して下さい。
さて、latencytopですが、情報はインタネット内に山ほどあるので、そちらをご参照下さい。
上記リンク先にも解説がありますが、latencytopを動かすにはカーネルの設定が必要です。
Kernel hacking の CONFIG_LATENCYTOP=y オプションを有効化する必要があります。mytekのドライバに関する記事でご紹介した uImage-17-CFQ/Deadline では、この指定を有効にしました。cuboxでlatencytopを動かすには、記事を参照してカーネル 17-CFQ/Deadlineをインストールして下さい。
また、latencytopを、
apt-get install latencytop
でインストールして下さい。
latencytop
と起動すると
このような画面が表示されます。
上段がシステム全体の遅延発生の状況。下段が指定したプロセスの遅延発生の状況です。下段にどのプロセスを表示させるかはその下に表示されるプロセス名をカーソルを移動し指定することで決定出来ます。
表示は周期的に変わりますが、「-t -2」というオプションで時間を指定出来ます。
表示される内容の意味についてはソースコードを先頭にのコメントに解説があります。
* The information is exported via /proc/latency_stats and /proc/＜pid＞/latency. * These files look like this: * * Latency Top version : v0.1 * 70 59433 4897 i915_irq_wait drm_ioctl vfs_ioctl do_vfs_ioctl sys_ioctl * | | | | * | | | +----> the stringified backtrace * | | +---------> The maximum latency for this entry in microseconds * | +--------------> The accumulated latency for this entry (microseconds) * +-------------------> The number of times this entry is hit * * (note: the average latency is the accumulated latency divided by the number * of times)
ここに情報がありますが、
/proc/latency_stats and /proc/＜pid＞/latency
はディフォルトでは有効でないので、/proc/sys/kernel/latencytop を有効にすることで見ることが出来るようになるようです。
やりかたは
echo 1 > /proc/sys/kernel/latencytop
で有効化
echo 0 > /proc/sys/kernel/latencytop
で無効化されます。
(PC_Audio) 2013/04/13
armアーキテクチュアでのcpu周波数変更
タイトルの通りですが、試してみました。結果は失敗です。お勧めできません。
ある方から「cuboxでcpuのクロックアップって出来ないの ? 」というメールを頂戴しました。なるほど面白そうだなと思いました。intelマシンではマニアの話題となっていて、今ではbiosの設定で簡単に出来るということは知っていましたが、armマシンではどうなるのだろう。biosは無いので、どうやるのかしら。調べてみました。
こことここにlinuxのcpu周波数変更の方法の詳しい解説があります(解説はintelアーキテチュアがメインですが、armアーキテチュアでも同じです)。linux kernelの電力管理機構とパフォーマンス制御にいつてはこの論文 が参考になります。
要するに「使用しているCPUがクロックや電圧の変更をする機能を持っていて、ドライバが提供されている」ということが条件になるようです。
cuboxのcpuはARMv7なので、cpu電力管理には対応していますが、ドライバが無いため、cpu周波数変更はできないようです。カーネルビルドでもmenuconfigに
[*] CPU Frequency scaling
というメニューが現れないので、設定出来ません。
という次第で、この件は残念ながら駄目という結論だったのですが、Cortex A8 のSmartTVBoxは周波数変更が可能なようです。
menuconfigで
CPU Power Management ---> に CPU Frequency scaling ---> という項目があり、
これを選択し
[*] CPU Frequency scaling とすると
こんな画面が表示されます。
Default CPUFreq governor
というのが、周波数を緒性する際の動作モードです。ondemand(負荷に合わせてクロックを素早く調整)、conservative(負荷に合わせてクロックをゆっくり調整)、powersave(最低のクロック)、performance(最高のクロック)、userspace(ユーザ指定のクロック)という五つのモードが指定可能です。周波数を固定にする場合はuserspaceを指定することになります。
と指定してビルドすれば、五つのモードを切り替えて使えるようになります。
ビルドした周波数調整機能を有効にするには周波数調整デーモンとユーティリティをインストールする必要があります。
apt-get install cpufrequtils cpufreqd
インストール後に
root@android:~# ls /sys/devices/system/cpu/cpu0/cpufreq/ affected_cpus cpuinfo_transition_latency scaling_cur_freq scaling_min_freq cpuinfo_cur_freq related_cpus scaling_driver scaling_setspeed cpuinfo_max_freq scaling_available_frequencies scaling_governor stats cpuinfo_min_freq scaling_available_governors scaling_max_freq user_event_notify
に情報が作成されます。例えば
root@android:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq 1008000
と1GHzで動いていることが分かります。
さて、cpu周波数情報をチェックします。
root@android:~# cpufreq-info
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
driver: sun4i
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 2.00 ms.
hardware limits: 60.0 MHz - 1.01 GHz
available frequency steps: 30.0 MHz, 48.0 MHz, (略) 864 MHz
available cpufreq governors: interactive, conservative, ondemand, powersave, userspace, performance
current policy: frequency should be within 60.0 MHz and 1.01 GHz.
The governor "userspace" may decide which speed to use
within this range.
current CPU frequency is 1.01 GHz (asserted by call to hardware).
cpufreq stats: 30.0 MHz:nan%, 48.0 MHz:nan%, (略) 576 MHz:nan%
ガバナーを変更するには
cpufreq-set -g performance
周波数を変更するには
cpufreq-set -c 0 -f 0.90GHz
という具合に自在に変えることができます。
ところで、SmartTVBoxのCPU周波数ははディフォルトの設定で最大の1.00GHzとなっています。従って、intelマシンのようにクロックアップは出来ません(出来るのかもしれないが、最悪ハードを壊す可能性があるのでお勧めできません)。しかし、オーディオ用にはcpuは速ければ良いというわけでは無く、必要最小限で動かし省電力にした方が有利というアイディアもあるかなと思い試してみました。
結果は失敗でした。cpufreqデーモンはcpu消費が大きく、これが動いていると再生にノイズがのってしまうのですよね。しかし、デーモンを止めてしまうと周波数の変更は出来ないので、結局、armアーキテクチュアでこの機能はタブレットなどで省電力のために使われるということのようですね。
(PC_Audio) 2013/03/30
MPD on Cubox(17)
雛祭りバージョンのリリースノート記事の終わりに『今回のレベルアップではいろいろなトラブルに遭遇しました』と書きました。その内容をご紹介します。
実は、リリースノート記事の中に書き込もうとしたのですが、書き始めたら、何が何だか分からなくなるということに気が付き(^^;;;、やめることにしました。公開したイメージの使い方の注意事項ということになります。Linuxの知識を前提とする話題なので、「俺はディフォルトのubuntu-coreのままで何も変更しないで使う」という方はパスして下さい。
ext4 ジャーナル無効指定
これはトラブルではありません。
雛祭りバージョンではdebian側をノンジャーナルのext4版にしています。ファイルシステムの効率面では有利になりますが、データ保全には不利となります。突然のシャットダウンなどで、間違いなくデータは欠損しますし、場合によるとシステムが動かなくなる可能性もあると思います。まあ、音楽を再生するだけのシステムなので、効率を優先させた方がよかろうと考え、この設定としました。
なお、スパーブロックが障害となりシステムが立ち上がらなくなった場合は、別のlinuxシステムを使いfsckすれば、リカバリできます(これはノンジャーナルのext4だけに限った話ではないですが)。
rootfsでのext3/4の利用
この件は年末バージョンで気が付いていたのですが、原因が分かりませんでした。今回、調査し、カーネルビルドのコンフィグの Kernel Features —> Preemption Model の設定が Basic RT になっている時発生すると分かりました。ここを Fully Preemptible Kernel (RT) にすれば、ext3/4 は使えるようですね。
実は最初(ノベンバー版)は Full RTを指定していたのですが、メモリ問題があって(ここを参照)、Basic RT に変更しました。どうもこれが悪かったかみたいですね。Basic RT と Full RT の違いですが、ここに情報があります。「Basic RT は Full RT のデバッグ用に一部の PREENPT_RT オプションの spin_locksを休止(sleeping)させないで動かすためのもので、消えてしまうから、気にしなくてもいい(Don’t worry about it)」とあります。
という次第で元に戻しました。
ただ問題点が一つあって、Full RT だと High Memory Support が無効となり、boot.scrでvmallocを指定していないと、256MB vmallocにとられてしまい、他のメモリと共用できないことです。まあ、仕方がないので、boot.scrで必要(96MB)な分だけvmallocをアサインするようにしました。
一部のddcで連続演奏するとmpdがハング
これは直前の記事を参照して下さい。カーネルのバージョンが3.6以降で発生する問題です。カーネルの問題なので、対応方法はなく、便宜的な方法ですが、dmaバッファのサイズを大きくし、実用上は問題ないレベルで連続演奏できるよう回避しました。ただし、dsdネイティブ再生ではまだ短いという問題が残っています。これも対応可能なので、直前の記事を参照して下さい。掲示板のこのスレッドに詳細な情報があります。
xfsの構造体エラー
これは年末版でも同じですが
root@cubox:~# ls /usr/bin/ ls: ディレクトリ /usr/bin/ を読み込んでいます: 構造体を内容消去する必要があります
というエラーになります。/var/log/systemには以下のようなログメッセージが残ります。
Mar 20 10:30:25 localhost kernel: e8982000: 58 46 53 42 00 00 10 00 00 00 00 00 00 06 3b 00 XFSB..........;. Mar 20 10:30:25 localhost kernel: XFS (mmcblk0p2): Internal error xfs_da_do_buf(2) at line 2192 of file fs/xfs/xfs_da_btree.c. Caller 0xc0255b24 Mar 20 10:30:25 localhost kernel: Mar 20 10:30:25 localhost kernel: Backtrace: Mar 20 10:30:25 localhost kernel: [] (dump_backtrace+0x0/0x10c) from [ ] (dump_stack+0x18/0x1c) Mar 20 10:30:25 localhost kernel: r6:c059a2ac r5:00000001 r4:c059a2ac r3:c061f87c Mar 20 10:30:25 localhost kernel: [ ] (dump_stack+0x0/0x1c) from [ ] (xfs_error_report+0x5c/0x68) Mar 20 10:30:25 localhost kernel: [ ] (xfs_error_report+0x0/0x68) from [ ] (xfs_corruption_error+0x58/0x74) Mar 20 10:30:25 localhost kernel: r4:e04e2800 Mar 20 10:30:25 localhost kernel: [ ] (xfs_corruption_error+0x0/0x74) from [ ] (xfs_da_read_buf+0x174/0x18c) Mar 20 10:30:25 localhost kernel: r6:0000d2ff r5:e7e23d78 r4:00000075 Mar 20 10:30:25 localhost kernel: [ ] (xfs_da_read_buf+0x0/0x18c) from [ ] (xfs_dir2_leaf_readbuf+0x22c/0x618) Mar 20 10:30:25 localhost kernel: [ ] (xfs_dir2_leaf_readbuf+0x0/0x618) from [ ] (xfs_dir2_leaf_getdents+0x138/0x3d4) Mar 20 10:30:25 localhost kernel: [ ] (xfs_dir2_leaf_getdents+0x0/0x3d4) from [ ] (xfs_readdir+0xcc/0xd4) Mar 20 10:30:25 localhost kernel: [ ] (xfs_readdir+0x0/0xd4) from [ ] (xfs_file_readdir+0x48/0x58) Mar 20 10:30:25 localhost kernel: [ ] (xfs_file_readdir+0x0/0x58) from [ ] (vfs_readdir+0x84/0xa8) Mar 20 10:30:25 localhost kernel: r6:c00cad98 r5:e09d6f54 r4:e13176c0 Mar 20 10:30:25 localhost kernel: [ ] (vfs_readdir+0x0/0xa8) from [ ] (sys_getdents64+0x6c/0xd0) Mar 20 10:30:25 localhost kernel: [ ] (sys_getdents64+0x0/0xd0) from [ ] (ret_fast_syscall+0x0/0x30) Mar 20 10:30:25 localhost kernel: r7:000000d9 r6:000d500c r5:000d5008 r4:000a6b1c Mar 20 10:30:25 localhost kernel: XFS (mmcblk0p2): Corruption detected. Unmount and run xfs_repair
エラーメッセージのいう通りに、xfs_check、xfs_repair をかけても何もエラーは検出されません。
不思議なのは
root@cubox:~# which which /usr/bin/which
と/usr/binの中のプログラムが表示できることです。どうも、/usr/binが使えないということではなく、ディレクトリ情報が適切にセットされていないということのようです。xfsとcubox専用パッチの組み合わせで発生する問題です。11月版のxfsシステムではcubox専用パッチをあてていないので、この問題は発生しません。
この件、mpdの音楽再生に関しては影響ないようで、実害はありません。
ただ、問題なのはubuntu側でシステムの更新作業などの作業を行うことはできないことです。理由はよく分かりませんが、例えばmpdのビルドを行うことはできません。
回避方法としては、debian側はext4なので、この問題は発生しません。開発作業はdebian側で行って下さい。
selboot問題
雛祭りバージョンでは
selboot [16-CFQ|16-Deadline|10-CFQ|10-Deadline]
という形でカーネルを切り替えることが出来ます。
これは /usr/local/sbin/selboot というシェルスクリプトで行っています。それぞれカーネルをbootパーティションの/build_filesに置いておき、/bootにuImageと名前を変えてコピーするという方法で切り替えを行っています。この時、bootパーティションをマウントする必要があります。
このマウントをselbootで行おうとしたのですが、上手くいかないのですよね。何故かエラーになり、マウント出来ません。シェルスクリプトによるコマンドの実行って、完了同期をとらないといけないということなのですかね。
よく分からないので、rc.localでマウントすることにしました。
トラック間の音切れ
mpdは完全ギャップレス再生ですが、ubuntu-core版のmpd関連のモジュールを全て最新にしたら、ごくわずかの音切れが発生するようになりました。何故かdebianでは最新にしても発生しません。
この音切れ「ごくわずか」と書きましたが、普通に聞いている分にはほとんど気が付かないレベルです。しかし、aitlaboのdacでdsdネイティブ再生していると、ちょっとでも連続していないと5秒間の中断が発生しますので、音楽を曲のあたまの部分が切れてしまい、使い物になりません。しかたがないので、関連のモジュールを年末版に戻し回避することにしました。
どのモジュールの更新が悪かったは分かっていません。ubuntu-core 12.04.2で同じことを試してみましたが、問題はありませんでした。ということは、この現象が12.04.1で発生したのは2月の初めでしたので、今は直っている可能性はありますね。
勇気ある方は雛祭りバージョンで試してみて下さい(^^;;;。
やり方は
apt-get install libflac-dev libogg-dev libvorbis-dev libid3tag0-dev libmad0-dev libcue-dev libasound2-dev apt-get install libsamplerate0-dev libshout3-dev libaudiofile-dev libresample1-dev libsamplerate0-dev apt-get install libavformat53 libavcodec53 libavutil51 libavformat-dev libavcodec-dev libavutil-dev apt-get install libsndfile1-dev libmms-dev libavahi-client-dev libavahi-glib-dev aptitude install libcurl-dev libcurl4-openssl-dev
です。
mpdのapeファイル対応
mpdの最新版(git版?)では、ape再生のサポートは積極的には行わないという方針のようです。
このページをご覧ください。mpdのメンテナー(内容から判断すると、多分、Max Kellermannさんご本人)が書かれた文だと思います。要するに「MonkeyAudioのライセンスはオープンの世界からみると掟破りなので、真面目にサポートする気はないよ。flacでいいじゃないの」ということです。
gitの最新版(18y)ではapeファイルの再生は出来ません(最悪ハングします)。また、データベース更新でもapeファイルが存在すると認識でハングしてしまうことがありました(雛祭りバージョンでは回避できているようですが)。
もともと、apeファイルはデコードに負荷がかかりすぎるという問題がありますので、圧縮率が高いと0.17系列のmpdでも満足に再生できません。上記アナウンスにしたがい、とっとと apeファイルは flacに変換するというのが正解かと思います。
実は、pcオーディオを本格的にはじめる前にリッピングしたデータは全部apeに変換して保存していました。全部で1000曲位あります。「どうしたものかいな」とPhoeniciaさんに相談したら、「dBpowerAMP Music Converterというのがあるよ」というご返事。試してみました。素晴らしい。半日かかりましたが、1000曲一発で変換できました。
本題と関係ありませんが、ape形式のファイルは負荷のかかった再生が出来るので、システムのチューニングには最適です。雛祭り版はこれを使ってチューニングしました。lan関連のドライバの優先度を高くすると音切れが無くなります。音にもよさそうですね。という次第でテスト用に一部を残しておくことにしました。
cifsdの二重起動
この件は11月版から発生していて、原因は分かっていません。
内容はタイトルの通りでcifsdが二重に起動されてしまうというものです。ubuntu-core、debianの両方で発生します。
多分、cifs関連のライブラリ(winbindを含む)のインストールの仕方が悪いのだと思いますが、いろいろ試していますが解決しません。音楽再生には特に実害は無いと思います。
問題はcifsdの優先度の設定を/etc/init.d/rtset.confで
chrt -f -p 53 `pgrep cifsd`
とやっているのですが、これではどちらか片方のcifsdのレベルだけしか変更されないということになります。
仕方がないので、/etc/rc.localで以下の通り
chrt -f -p 53 `pgrep -n cifsd` chrt -f -p 53 `pgrep -o cifsd`
と無理やり両方のレベルを上げています。
あまりスマートでないけど、まあしょうがないですね(^^;;;。
70-persistent-net.rules
この件は既出です。ここを参照して下さい。
led表示
年末版のdebianではled表示が出来ないという問題がありました。このため、雛祭りバージョンではdebian側のled表示をやめました。その後、掲示板でのtinkerさんとのやりとりで、この原因が分かりました。
debianがarmelだったので、led表示が出来なかったということです。上記リンク先でtinkerさんから教えていただいたarmhfのdebianを試してみたら、led表示できることを確認しました。
debian版がarmel
これも上記リンク先の掲示板スレッドに情報がありますが、debian版はarmelです。作者(僕のことです)はてっきりarmhfだと思っていたので(^^;;;、バグではありませんが、問題でしたね。しかし、カーネル(uImage)がarmhfでrootfsがarmhfで動くとはビックリ。linuxって案外融通無下なのですねぇ。
ubuntu-coreはarmhfなので、けがの功名で、armelとarmhfのrootfsを聴き比べることができます。mpdとか関連のライブラリもarmelとarmhfに分かれて設定されていますので、かなり音は変わります。どちらが良いかは環境次第だと思いますが、よろしければお試し下さい。
ubuntu-coreとdebianのブート起動シーケンスの違い
rt優先レベルの設定(/etc/init.d/rtset.conf)とmpd関連ファイルのメモリ化(/etc/init.d/shmset.conf)はブート起動シーケンスの中で行っています。/etc/init.d にスケルトンフォーマットに合わせたスクリプトを置き、update-rc.d で起動タイミングを設定するという方法です。
問題はこの方法がdebianでは上手く働かないことです。update-rc.dで起動シーケンスに組み込まれるのですが、起動順番が無視され、無条件にデーモン起動の終わった後となってしまいます。これだと shmset.confがmpd立ち上げ後に起動されmpd関連ファイルのメモリ化が上手くいかないのでよね。
何故、姉妹ディストリビューションなのに差が出るのか謎ですが、debian wheezy は systemdに移行中だからということなのですかね。
まあ、いずれにしても、どうしようもないので、tagcacheは/var/lib/mpd/に残すことにしました。
Voyage MPD との違い
これもトラブルではありません。掲示板のこのスレッドを参照して下さい。
一番大きい違いはファイルシステムの read-only化です。これについては出来ることは分かっていますが、面倒なので、やる気はありません。read-onlyにしたから、電源をバチバチ落としてかまわないというのは乱暴な話だと思います。
あと、autofsやrubyなどインストールされていませんが、これらはapt-getで簡単にインストール出来ます。自力で対応して下さい。
こういう具合に書き出してみると、満身創痍、cubox-audio linux 傷だらけですね(^^;;;。
尚、以上の内容に関して掲示板で多くの方からアドバイスを頂戴しました。お名前は省略した方もいらっしいますが、改めてお礼申し上げます。
(PC_Audio) 2013/03/21
Kernel 3.6 でのmpd連続再生
今回も掲示板のこのスレッドとこのスレッドによります。
この記事に書きましたが、arm版の linux kernel 3.6 には一部のddcで長時間の連続再生できないという問題があります。雛祭り版では、arch/arm/mach-dove/common.c にパッチをかけ、dma coherent_poolを32MBに拡張して対応させました。
この値はwavやflacであれば4時間以上連続再生できるのですが、dsdネイティブ再生だと1時間程度しかもたないようです。どうも、再生音楽のデータサイズによって連続再生できる時間が決まってくるようですね。
僕の環境でdsdネイティブの再生確認していたのですが、sacd一枚分丁度1時間位なので、見落としていて、mさんのご指摘で気が付きました。
対応方法ですが、バッファサイズを拡大するしかないです。やり方はかずひこさんから「boot.scrのカーネルパラメータの変更できるはずだよ」と教えて頂いていたので、それで試してみました(掲示板一番目のリンクの最初の書き込み)。この方法で問題なく対応できるようですね。やり方をご紹介します。
雛祭り版ではbootパーティションの/bootのboot.scrを同じディレクトリ(雛祭り版では/media/boot)に置いてあるboot2-mmc.scr(ubuntu用)とboot3-mmc.scr(debian用)を入れ換えるという方法でubuntuとdebianの切り替えを行っています。この二つのスクリプトの元になるソースをboot2-mmc.txtとboot3-mmc.txtとして残してありますので、これを修正してdma coherent_poolとvmallocを拡大して、コンパイルすれば、対応できます。作業は雛祭り版で立ち上げたcubox本体で出来ます。
# rootでログイン # boot.scrコンパイル用パッケッージをインストール apt-get install uboot-mkimage # /media/bootに移動 cd /media/boot # boot2-mmc.scr(ubuntu側)を更新するのであれば nano boot2-mmc.txt setenv bootargs 'console=ttyS0,115200n8 root=/dev/mmcblk0p2 rootdelay=3 --no-log --verbose' # という行があるので、以下の通り修正 setenv bootargs 'console=ttyS0,115200n8 vmalloc=144M coherent_pool=96M root=/dev/mmcblk0p2 rootdelay=3 --no-log --verbose' # vmalloc=144M coherent_pool=96M という部分を追加、vmallocは coherent_pool + 32M 以上にして下さい # 変更内容を保存し、終了 ctrl+o -> ctrl+x # コンパイル mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n 'Boot setup script for SD' -d boot2-mmc-dma.txt boot2-mmc.scr # あとは selboot u # でboot.scrに反映できます。
僕も問題を起こすaitlabo dacユーザなので、自分用にアーカイブを作成し、サーバに保存してあります。
こちらで対応することも出来ます。cuboxがネットワークに繋がるのであればこちらの方が簡単です。やり方は
wget "http://mimizukobo.sakura.ne.jp/cgi-bin/downlog.cgi?edata/bootscr.tar.xz" -O bootscr.tar.gz cd / tar -Jxvf /root/bootscr.tar.xz selpart u
なお、この現象ですが全てのddc(dac)で発生するわけではなく、一部のddc(dac)だけです。このあたりは多分パソコンとddcのdma転送の方法に依存するようですね。
fHiroさんからのコメントですが、「連続再生中はdmaのパケットバッファをクリアしない構造(おそらくギャップレス再生などと関連あり？)になっているようです。DDC/DACによって現象が異なるのは、DMAのパケット長などが各HWによって異なる為でしょうか」ということのようですね。
また、これもfHiroさんから指摘されていますが、バッファを拡大するという完全な対策ではなく、回避策です。途中で再生を止めて、再度再生することで演奏はいくらでも連続させることができますが、限度があるようです。停止と再生を長時間繰り返すとバッファの状態が奇怪しくなり、開始に時間がかかるようになります。
この場合はmpdをリスタートさせれば、バッファの状態を元に戻し対応できるようです。そういう意味ではカーネルのちゃんとした修正が必要です。ただ3.7でも確認しましたが、この障害は残っていますね。
t-taさんから情報を頂きましたが、3.8でもこの問題は残っているようです。リンク先のリンクにあるようにusb非同期転送でリーク問題が発生していて、まだ解決されていなようですね。
以上、お名前をあげた方々にはお世話になりました。感謝いたします。
(PC_Audio) 2013/03/16
snd-usb-mytek
今回の書き込みは掲示板のこのスレッドとこのスレッドによります。
掲示板で香港のNukbeeさんから「Mytek DSD-192 DAC用のlinux対応のドライバがあるのだけど、cuboxで使えるようにしてくれないか」というリクエストを頂きました。ドライバのありかはここです。このgithubのデータとNukbeeさんに教えて頂いたスレッドの関係がよく分からないのですが、このドライバの作者はmpdのDSD対応を行っている Jurgen Kramerさんのようですね。
さて、このドライバですが、hiFace用のsnd-usb-asyncaudioと同じように自力でビルドする必要があります。その際、カーネルヘッダーが必要というのも同様です。snd-usb-asyncaudioの記事でも書いたように、これは/lib/modules/カーネル名/buildがカーネルソースのリンクであることを参照しているだけですので、開発環境でカーネルをビルドしている場合はMakefileの当該部分をカーネルソースを示すディレトリに変更してやれば対応できます。要注意なのは snd-usb-mytek 場合 Terratec 6Fire の USB2 ドライバをベースに作成されたもであることです。カーネルビルド時にTerratec 6Fireを組み込んでいないと
mytekusb2/chip.c:225:9: note: #pragma message: Build for kernel older then version 3.3
というコンパイルエラーになります。
snd-usb-mytekでも、snd-usb-asyncaudioでもビルドにはカーネルヘッダーが必要と書かれていますが、これはカーネルヘッダーそのものが必要という意味ではなく、カーネルソースが必要という意味です。それぞれのドライバのビルド時にカーネルソースのディレクトリを参照するようですが、この時カーネルモジュールがちゃんと用意されていないと上手くいかないようですね。
Nukbeeさんから「カーネルヘッダーを用意してくれ」とお願いされたのですが、カーネルヘッダーだけでなく、ビルド済のカーネルソースが必要となり、sdカード内の空き領域が足らなくなる可能性があるので、僕の開発環境でドライバをビルドすることにしました。snd-usb-mytekのビルドの仕方はsnd-usb-asyncaudioとほぼ同じなので省略します。
ビルドしたモジュールとカーネルは公開してあります。以下、掲示板にも同じ内容を書き込んでいますが、公開したアーカイブの雛祭りバージョンへのインストールの仕方です。
# rootでログイン login as: root root@cubox.local's password: Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.6.9-rt21_CuboxAudioRTuned+ armv7l) # アーカイブをダウンロード root@cubox:~# wget "http://mimizukobo.sakura.ne.jp/cgi-bin/downlog.cgi?edata/Mytek.tar.xz" -O Mytek.tar.gz # ダウンロードしたアーカイブを展開 root@cubox:~# sudo tar -Jxvf Mytek.tar.gz ./modules-17.tar.gz ./snd-usb-mytek.ko ./uImage-17-CFQ ./uImage-17-Deadline # uImageを保存用ディレクトリ(/media/build_files/)に展開 root@cubox:~# cp uImage-17-CFQ /media/build_files/ root@cubox:~# cp uImage-17-Deadline /media/build_files/ # ルート(/)に移動 root@cubox:~# cd / # ライブラリモジュールを展開 root@cubox:/# tar pxvzf /root/modules-17.tar.gz # snd-usb-mytek.koを保存するディレクトリを作成し、そこにコピー root@cubox:/# mkdir /lib/modules/3.6.9-rt21_CuboxAudioRTuned_forMytech/extra root@cubox:/# cp /root/snd-usb-mytek.ko /lib/modules/3.6.9-rt21_CuboxAudioRTuned_forMytech/extra/ # 新しいカーネル(CFQ 又は Deadline)でリブート root@cubox:/# selboot 17-CFQ 例はCFQです。 login as: root root@cubox.local's password: Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.6.9-rt21_CuboxAudioRTuned_forMytech armv7l) # snd-usb-mytek.koを組み込み root@cubox:~# insmod /lib/modules/3.6.9-rt21_CuboxAudioRTuned_forMytech/extra/snd-usb-mytek.ko root@cubox:~# depmod -a # ブート時にモジュールを自動組み込みさせるために、「snd-usb-mytek」という行を /etc/modules の終わりに追加 to load in boot process root@cubox:~# nano /etc/modules snd-usb-mytek root@cubox:~# reboot # snd_usb_mytek が組み込まれていることを確認 root@cubox:~# lsmod Module Size Used by snd_usb_mytek 16228 0
なお、snd_usb_mytekドライバの動作にはMytek社のサイトにある次の三つのファームウェア
- mytekl2.ihx
- mytekcf.bin
- mytekap.ihx
が必要で、これらを /lib/firmware/mytek にコピーする必要があります(mkdir /lib/firmware/mytekで作成)。詳細はgitファイルのFIRMWAREをご覧ください。
また、debian側でもカーネルのコピー以外は同じ操作をする必要があります。
(PC_Audio) 2013/03/09
MPD on Cubox(16)
cubox用の新しいイメージを公開します。雛祭りバージョンということになりますね。主な変更点はandroid用と同様にカーネルとrootfsをチューンアップした点です。
イメージは以下のリンクからダウンロードできます。
概要
カーネルはcubox固有パッチのかかったrabeehさんの最新版(1月の話なので、もう最新ではないかもしれませんが)を使い(カーネルのヴァージョンは3.6.9)、Phoeniciaさんが作成されたチューンアップ版のコンフィグをそのまま頂戴し、rootfsのチューンアップに対応するため System Features —> Preemption Model の設定を Fully Preemptible Kernel (RT) に変更しました。
rootfs側は優先度とバッファコントロール値を見直し(/etc/init.d/rtset.confと/etc/mpd.conf)、ubuntu-coreのxfs作成オプションを設定し(-l size=32768b,version=2)、debianのファイルシステムをext4(NoneJournal)に変更しました。
その他、チューンアップとは関係ありませんが、最新のmpd(18y、173s)をmmsを有効にしてビルド、追加し、snd-usb-asyncaudioを組み込んであります。
カーネルのチューンアップ
カーネルのチューンアップは4種類のカーネルを選択出来るようにしてあります。カーネルはヴァージョン 3.4.24と3.6.94をPhoeniciaさんが作成されたチューンアップ版のコンフィグを使い Default I/O scheduler をCFQとDeadlineの二つの指定でビルドしたもの組み合わせの4つが選択できます。選択方法は
selboot [16-CFQ|16-Deadline|10-CFQ|10-Deadline] 16-CFQ : 3.6.9 CFQ版 16-Deadline : 3.6.9 Deadline版 10-CFQ : 3.4.24 CFQ版 10-Deadline : 3.4.24 Deadline版
です。このためubuntu-coreとdebianの選択は
selpart [d|u]
と変更しました。スクリプトは/usr/local/sbinに置いてあります。
また4種類のカーネル、Phoeniciaさんが作成されたコンフィグと関連ドキュメントは/media/build_filesに置いてあります。
ディフォルトは3.6.9 CFQ版、ubuntu-coreとしてあります。
rootfsのチューンアップ
rootfs側の大きな変更はdebianのrootfsをノンジャーナル指定のext4にした点です。これは音の面では有利に働くはずですが、綺麗にシャットダウンしないとデータが紛失します。電源オフは必ずshutdownを使ってやって下さい。
ext3/4を使うためには、カーネルの指定を Full RT にする必要があるようなので、boot.scrでのvmallocメモリ指定を復活させました(この件は掲示板でも t-ta さんが話題にされていて、、cubox専用パッチのかかった kernel 3.6.9 と kernel 3.6.11用のrtパッチ(rt30)を組み合わせるという解決策があるようですが、とりあえずディフォルトの 3.6.9 + rt24 で作成しています)。
また、年末版debianではled表示が出来ないというバグと(このためシリアルコンソールからログイン出来なくなる)、ブート起動のシーケンスがコントロールできないという問題があります。このためmpdワークファイルの常駐メモリ化とled表示機能はdebian側からは削除しました。
mpdのチューンアップ
mpdの追加はyanさんが最新のrtoptパッチを公開されましたので、これを使い最新版(2月24日)のgitでビルドしました。当然 mpd-dsdbugfix-20130203.diff もかけてあります。選択名は18yです。あと0.17.3のステーブル版も公開されたようなので、こちらも旧rtoptパッチをかけビルドしました。選択名は173sです。したがって、selmpdの使い方は
selmpd [18y|18g|173s|172s|jk]
となります。ディフォルトは18yです。
yanさんのパッチ一式についてはubuntu側の /root/mpdcubox に残してあります。 また、掲示板で n’GuinさんからNHK-FMとottavaを聞けるようにしてほしいとの要望を頂戴しましたので、今回ビルドしたmpd(18y、173s)はmmsに対応させました。
snd-usb-asyncaudioの組み込み
snd-usb-asyncaudioですが、組み込んであります。従って、該当のハードを接続してあれば、認識するはずです。内容については少し前の書き込みを参照して下さい。
ただし、僕はハードをもっていないので、確認できていません。接続報告をお待ちします。
その他
公開にあたりお名前をあげている方にはお世話になりました。改めてお礼申し上げます。
また、今回のレベルアップではいろいろなトラブルに遭遇しました。内容については過去の書き込みや掲示板をご参照ください。何とか解決できたのはインタネット情報のおかげです。皆様ありがとうございました。
なお、公開されたバイナリイメージは無保証です。僕は内容について一切の責任はもちませんので、ご自身のリスクでお試し下さい。
(PC_Audio) 2013/03/03
SDカードイメージの作り方
今回は自分用のメモです。作成したシステムを公開用のイメージするためのノウハウです。
マイクロSDカードをnullクリア
この操作は後述するイメージファイルの圧縮のためで、通常は不要です。 nullというのは16進で all zero(0x00) のデータのことです。
dd if=/dev/zero of=/dev/mmcblk0
/dev/zeroというのはゼロデータのことです。
これでやっていたのですが、Phoeniciaさんから「アクセス回数を減らせるのでオールビットオン(0xFF)でクリアした方がいいよ」と教えて頂きました。その方法です。
tr "\000" "\377" < /dev/zero | dd of=/dev/mmcblk0
trコマンドを使って0x00を0xFFに変えています。
結構時間がかかりますが、これをやっておかないと、圧縮率が低くなるので、1時間位じっと我慢。
ちゃんと0xffクリアされたかは、以下のコマンドで確認できます。
yo@ubuntu:~$ od -tx1z /dev/mmcblk0 [sudo] password for yo: 0000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >................< * 35520000000
圧縮方法
シンプルにgzipで圧縮率をあげるのが、簡単です。
dd if=/dev/mmcblk0 | gzip -9 > cubox-audio.img.gz
これは30分位時間がかかります。
gzipによる圧縮は圧縮は時間がかかりますが、展開は圧縮率をあげても案外速いのが取り柄ですね。展開は10分かからないと思います。
圧縮率を上げたいのなら7zipというやつがお勧めです。ただ、linuxの場合ディフォルトでは入っていないので
apt-get install p7zip-full またはvortexboxなら yum install p7zip
でインストールします。
圧縮方法は
7za a -mx=9 /music/cubox-audio130223.img.7z /music/cubox-audio130223.img
ただし、気の遠くなるほど時間がかかるのが難点です。 試しに両方を比較してみました。
[vortexbox.localdomain ~]# tr "\000" "\377" < /dev/zero | dd of=ff.img count=10000 [vortexbox.localdomain ~]# gzip -9 ff.img [vortexbox.localdomain ~]# tr "\000" "\377" < /dev/zero | dd of=ff.img count=10000 [vortexbox.localdomain ~]# 7za a -mx=9 ff.7z ff.img [vortexbox.localdomain ~]# ls -l ff* -rw-r--r-- 1 root root 904 Feb 23 16:00 ff.7z -rw-r--r-- 1 root root 5120000 Feb 23 15:59 ff.img -rw-r--r-- 1 root root 5002 Feb 23 15:59 ff.img.gz
となり7zipの方が圧倒的に圧縮率は良いです。ただ、7zipは圧縮にかかる時間は倍以上になります。
ログファイルのクリア
証拠隠滅のため(^^;;;、いくつかのファイルをクリアします。
nano /etc/fstab reboot rmdir /music /sacd rm /etc/udev/rules.d/70-persistent-net.rules rm /tmp/mpd/* rm /var/log/* rm /var/lib/mpd/* rm /var/lib/mpd/music/* rm .bash_history
一番最初の設定ファイルは何故クリアするのかについては次を参照。 二つ目の/run/shm/mpdのクリアはmpd関連のワークファイルをメモリに常駐化するよう方式を変えたので、必須です。これをやらないとゾンビの如く(^^;;;、ワークファイルが復活します。
ネットワーク
最初、イメージをコピーしたsdhcカードをPhoeniciaさんにお送りして確認をお願いしたのですが、ネットワーク接続が何故か出来ない。いろいろ試行錯誤して頂き、分かったのはeth1を使って設定すればOKになるということでした。
ググってみて分かったのは、僕のところの設定が/etc/udev/rules.d/70-persistent-net.rulesに残ってしまい、これが頑張っているので、eth0が使えなくなるということ。ネットワークではかなり有名なトラブルらしく、70-persistent-net.rulesで検索をかけると情報は山ほど出てきます。
対応策は簡単でこのファイルをデリートしてシステムを作成すればいいようです。ちなみにこのファイルの冒頭のコメントは以下の通りです。
# This file was automatically generated by the /lib/udev/write_net_rules # program, run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single # line, and change only the value of the NAME= key.
知らなかったなぁ(^^;;;。
(PC_Audio) 2013/02/23
SDカードイメージの編集の仕方
Phoeniciaさんから「cubox/androidイメージを別のlinuxマシンで編集する方法を紹介した方がいいのじゃないのか」という提案がありました。最初からネットワーク接続をipアドレス固定にして繫ぎたい場合には、この方法しかありません。また、linux開発環境を使って、sdカードイメージの設定ファイルなどをいじる場合にも有効です。やり方はlinux愛用者からみれば、常識ですが、慣れていない方のために出来るだけ丁寧に解説します。
使用するカードはcuboxの場合はマイクロsdカード、SmartTVBox(以降、Androidと表記します)の場合は通常のsdカードとなります。また、sdカードは4GB以上だとsdhcカードとなりますが、いちいち区別するのは面倒なので、以下の説明では全てsdカードと表記します。
事前知識(本題に入る前の長～い前置き)
本題に入る前にイメージの構成とその編集に何故linuxマシーンを使うか説明しておきます。
ダウンロードしたイメージファイルはddwinなどのWindowsのツールを使ってsdカードに書き込めるのですが、残念ながら、Windowsでその内容を参照更新することは出来ません。これはsdカードに書き込まれた中味のファイルシステムがWindowsでは認識されないフォーマットだからです。
ファイルシステムとは何かについて解説しだすと、きりがないので、ここを参照して下さい。Windows、linux、Macはそれぞれ異なったファイルシステムをベースにしています。それぞれのOSでサポートされていないファイルシステムの中味は読み書きすることができません。Windowsはこの許容度が特に低く、Windows以外のOSのファイルシステムの媒体を読み書きすることが出来ません。従って、linux用のイメージを読み書きするにはlinuxを使う必要があります。
さて、公開しているイメージの構成は以下の通りです。
cubox-audio 121222版
| パーティション番号 | 内容 | ファイルシステム |
|---|---|---|
| 1 | boot | ext2 |
| 2 | ubuntu-core rootfs | xfs |
| 3 | debian rootfs | ext2 |
android-audio 130114版
| パーティション番号 | 内容 | ファイルシステム |
|---|---|---|
| 1 | boot | fat16 |
| 2 | ubuntu-core rootfs | ext4 |
パーティションとはsdカード上の区画のことです。cubox121222ではsdカードを三つにわけて、android130114では二つに分けて使っています。
区画の分割の仕方は先頭のパーティションがboot用のパーティション、以降がrootfs用のパーティションになります。bootとは電源を入れてlinuxが開始されるまでの初期設定を司る処理(ファイルシステムの認識はこちら)のことで、rootfsとはその後のシステムの立ち上げを司る処理(ネットワークの設定、音源の認識、mpdの立ち上げなど)のことです。boot部分はrootfsの内容にかかわらず共通化されていて、例えば、android用のオリジナルのbootを使って、今回作成したandroid用のubuntu-coreのrootfsを動かすということも可能です。
bootパーティションのファイルシステムは使用するハードウェア(ファームウェア)により決まります。cuboxの場合はext2かext3、androidの場合はfat16となります。rootfsパーティションは、bootパーティションで作成したカーネルによって、どんなファイルシステムが使えるか決まります。カーネルについても説明しだすときりがないので、ここを参照して下さい。とても良く説明されています。androidで使われているfat16というのはWindows用の古いファイルシステムですので、これだけはWindowsから読み書きできます。従って、androidのイメージのカーネルの入れ換えをWindowsからもできるわけです。
上記の通り公開したイメージではext2/4、xfsを使っています。これらは全てlinux専用のファイルシステムです。Windowsからは読み書きできません。それぞれのファイルシステムがどんな特徴をもっているかについては上記リンク先を参照して下さい。
これで「長～い前置き」は終わりです。ただ、もう一つだけ補足。
要注意なのは、cuboxのrootfsはubuntu-core用とdebian用の二つがあることです。この二つのパーシティションは独立です。ubuntu-coreで立ち上げている時、debian側のパーティションは見えません。逆に、debianで立ち上げている時はubuntu-coreは見えません。設定ファイルはそれぞれ別に自身のパーティションに用意されています。設定ファイルの変更は両方のパーシィションに行う必要があります。
事前準備
Voyage MPDマシンにsdカードリーダを繫いで、イメージを編集します。
使うlinuxマシンはVoyage MPDマシンを前提に説明し、他のlinuxでどうなるかはアトランダムに補足します。まあ、このサイトをご覧になっている大半の方はVoyage MPDをお使いでしょうから、この方法がいいでしょう。
usb接続タイプのsdカードリーダを使います。標準のsd(hc)カードとマイクロsd(hc)カードの両方を取り合えるタイプが便利かと思います。linuxでのsdカードリーダの接続ですが、僕の手持ちの2台のカードリーダは問題なくVoyage MPDで認識できました。市販の普通(?)のリーダなら問題なく繋がると思います。
カードリーダを接続し、Voyage MPD を立ち上げます。
この時、ハードによっては最初からsdカードを差し込んでいると、これがブート用ディスクとbootファームが勘違いして、上手く立ち上がらないことがありますので(僕のatomマシンがそうでした)、ご注意下さい。
ログインと読み書き可能なモードの設定
ログイン画面が表示されますので、ユーザ名(root)とパスワードを入力。
ユーザ名は「root」として下さい。これはその後システムファイルを変更するので、変更権限をもたせるためです。パスワードはディフォルトの状態では「voyage」です。
ログイン完了後に
remountrw
と入力して下さい。これはVoyage MPDの場合、立ち上げ直後はファイルシステムはread(読み出し)のみ可能なモードなので、それを読み書き可能にするためのVoyage MPD専用のコマンドです。Voyage MPD以外のlinuxであれば、これは不要です。
sdカードのセットとマウント
イメージを書き込んだsdカードをカードリーダにセットします。
さて、ここから話がややこしくなります。
マウント、マウントポイント、ディレクトリなどWindowsユーザにはなじみのないテクニカルタームが登場します。ここに日経BP社の見事な解説がありますので、ご参照下さい(冒頭のディレクトリというタイトルで引用している部分です)。
また、以降の解説はcuboxの場合です。androidの場合はrootfsパーティションは一つなので、ややこしさはそれほどではないと思います。適宜読み替えて下さい。
linuxでは常時接続されていない機器(デバイスdeviceと呼び、/dev/nnnで参照します)を使う場合はマウント(mount)という操作が必要です。
sdカードをlinuxマシンに差し込み、内容を読み出すには差し込んだsdカードをlinuxマシンに認識させるため、マウントする必要があります。
fdisk -l
でデバイス名を調べ、適当なマウントポイントを作成(mkdir)し、調べた名前で/mediaというマンウトポイントにマウントする。結構面倒ですね。
しかし、最近のlinuxシステムではこのマウント処理をオートマウント機能により自動化してくれるものがあります。Voyage MPD にもこの機能が導入されていますので、カードリーダにセットされたsdカードは自動認識されます。マウント処理に関して、何も気にすることはありません。これで、メデタシメデタシとなるはずなのですが、残念ながら、そうは問屋が卸さない。敵(linux)はそんなに甘くはありません。
root@voyage:~# df -T Filesystem Type 1K-blocks Used Available Use% Mounted on rootfs rootfs 9606112 2448092 6670048 27% / udev devtmpfs 10240 0 10240 0% /dev tmpfs tmpfs 206388 312 206076 1% /run 一部省略 tmpfs tmpfs 1031924 24420 1007504 3% /var/lib/mpd tmpfs tmpfs 1031924 24420 1007504 3% /var/lib/alsa /dev/sdb3 ext2 1729528 948980 692692 58% /media/usb0 //xxxxxxxxxxxxx/CD cifs 1866460612 1337620020 434029920 76% /music //xxxxxxxxxxxx/share/sacd cifs 1938181376 519724124 1418457252 27% /sacd /dev/sdb1 ext2 13879 6538 6625 50% /media/usb1
上記はVoyage MPDでsdカードを差し込んだ直後に
df -T
というコマンドでマウントしているデバイスの内容を表示させています。「-T」というオプションをつけることによって、ファイルシステムのタイプを付けて表示してくれます。「df」コマンドはシステムの状況を確認するのに便利ですので、覚えておいた方がいいでしょう。
さて、注目してほしいのは最後の4行です。
nasの音楽用ディレクトリがマウントされている前後に、/dev/sdb3(debianのパーティション)が/media/usb0というマウントポイントに、/dev/sdb1(bootパーティション)が/media/usb1というマウントポイントに自動マウントされています。
「あれ、/dev/sdb2(ubuntuパーティション)はどうなったの ? 」となります。どうも、ファイルシステムがxfsだと、自動マウントされないようです。残念ながら、自力でマンウトする必要があります。
mount /dev/sdb2 /media/usb2
と操作して下さい。もう一度「df -T」と入力してみます。
/dev/sdb2 xfs 1732608 876532 856076 51% /media/usb2
という行が最後に追加されているのが確認できるでしょう。無事、ubunti-coreのrootfsもマウント出来ました。
しかし、以上解説した方法はあまりお勧めできません。
/media/usb0がパーティション番号3のdebianのrootfs /media/usb1がパーティション番号1のboot /media/usb2がパーティション番号2のubuntuのrootfs
となっていて間違えやすいからです。どうも「恩が仇」になっているという気がする。
という次第で、余計なお世話を謹んで辞退して、自力でマウントすることにしましょう。
umount /media/usb* これは多分不要ですが、気分が悪いので/media/unb(n)というマウントポイントをまとめてアンマウントします mkdir /media/boot mkdir /media/ubuntu mkdir /media/debian マウントポイントを作成します mount /dev/sdb1 /media/boot mount /dev/sdb2 /media/ubuntu mount /dev/sdb3 /media/debian マウントします。/dev/sdb1の部分は環境依存です。上手くいかない時は「fdisk -l」デバイス名を確認。
これで、ようやく自在にboot、ubuntu、debianのパーティションを自在に操作できることになりました。
sdカードのルートディレクトリへの移動
またまた、本題に入る前に長～い前置きです。linuxにおけるディレクトリの指定の仕方について説明します。
まず、ディレクトリとは何かですが、Windowsのフォルダーのことです。これも解説しだすときりがないので、ここを参照して下さい。
linuxにおけるディレクトリの指定には二つの方法があります。絶対的な指定方法と相対的な指定方法です。絶対とは、今どこのディレクトリにいるかに影響されずディレクトリ名を指定する方法、相対とは、今いるディクトリからどこのディレクトリを指定するか指定する方法です。つまり、ディレクトリの指定が今いるディレクトリに影響されるか、そうでないかです。どちらの方法を使うかお好み次第です。
ディレクトリの移動には「cd」というコマントを使います。少しやってみましょう。
root@voyage:/# cd /etc root@voyage:/etc# cd network root@voyage:/etc/network# cd .. root@voyage:/etc# cd ../root root@voyage:~# cd /etc/network root@voyage:/etc/network# cd ../../ root@voyage:/# cd /root root@voyage:~#
rootでログインした直後に、ディレクトリの絶対指定で「/etc」というディレクトリに移り、相対指定「network」で「/etc/network」に移り、相対指定「..」で「/etc」に戻り、相対指定「../root」で元のディレクトリに戻り、再び、「/etc/network」で直接/etc/network移り、「../../」で「/」(これをルートディレクトリといいます)に移り、「/root」(これはrootユーザのホームディレクトリです、ホームディレクトリについては後で説明します)で元に戻って来ました。
このように、絶対指定はディレクトリ指定の先頭を「/」ではじめます。相対指定は「./」ではじめるか、「..」ではじめるか、./を省略して直接ディレクトリ名ではじめるかです。「..」は多少特殊な指定方法で今いるディレクトリの一つ上のディレクトリ(親ディレクトリといいます)を意味します。従って「../../」は二つ上のディレクトを意味します。
このように相対指定では今どこのディレクトリにいるか(これをカレントディレクトリといいます)を知った上で操作する必要があります。「pwd」というコマンドで表示させることが出来ます。
root@voyage:~# pwd /root
このように、rootでログインするとカレントディレクトリは /root となります。
実は、普通のlinuxシステムならカレントディレクトリを知る方法はもう一つあります。コマンドプロンプトをチェックする方法です。
上記のpwdとコマンドを入力した時、「root@voyage:~# 」と表示されていますね。これがコマンドプロンプトです。コマンドの入力を促すためのlinuxが出力する表示ですが、この「root@voyage:~」という部分は「アンタはrootというユーザ名でvoyageのシステムにログインしていて、今「~(チルダ)」というところにいるよ」とlinuxが教えてくれいるのです。「~(チルダ)」はそのユーザのホームディレクトリを意味します。ホームディレクトリとはユーザがいろいろな作業をする時の拠点となるディレクトリのことです。
linuxでの通常の作業はこのホームディレクトリの下にツリー構造で自分専用のディレクトリツリーを作成し、構成します。しかし、システムの設定に関連するファイルは特定のユーザのためのものではないので、/etc というディレクトリに集められています。
以上の内容がディレクトリ操作の基本です。
本題に戻します。
「sdカードのルートディレクトリへの移動」ですが、ここまで理解できていれば、簡単です。
cd /media/ubuntu 又は cd /media/debian
とすればいいです。
設定ファイルの変更
ようやく本題にたどり着きました(^^;;;。
後は適当なエディターを使って設定ファイルを書き換えるだけです。
適当なエディターと書きましたが、Voyage MPD のディフォルトで使えるものはviとnanoしかありません。「linuxの奥義を極めたい」というのなら、viが適当でしょうが、コマンドとデータの書き込みを分離した操作方法は難解で、へなチョコWindowsユーザ(僕がそうです)にはとても太刀打ち出来ません。という訳で、普通(?)のWindowsユーザには、nanoをお使いになることをお勧めします。
nanoの起動方法は
nano ディレクトリ指定/ファイル名
です。
sdカードのルートディレクトリへの移動している場合は相対指定の方が簡単です。例えば、ネットワークの設定ファイルであれば
nano etc/network/interfaces
となります。 nanoの操作方法はWindowsのエディターと大体同じです。画面上で直接文字記号の入力が出来、カーソル、deleteキー、bsキーなどもWindowsと同じように使えます。ファイルの保存はctrl+oでガイドが出ますので、改行。終了はctrl+xです。このあたりもWindowsの普通のプログラムと同じですので、使い易いと思います。コピー&貼り付け機能はありませんが、sshクライアントの機能で代用できます。
ここまで、えらく長～い書き込みになりましたね。
ようやくエディターを使ってlinux環境を自在に設定できるところまで辿り着いたのですが、疲れ果てたので(^^;;;、続きは『近い内に』。
(PC_Audio) 2013/02/23
snd-usb-asyncaudio
snd-usb-asyncaudioというのはオランダの Michael Nazzareno Trimarchi さんが公開している M2Tech hiFace用の usb audio ドライバです。hiFaceと同じチップを使っている North Star Design “Essensio”、CHORD QBD76HDSD/QuteHD などでも使えるようです。
snd-usb-asyncaudio のビルドですが、カーネルヘッダーが必要です。ただし、カーネルをビルドした環境があれば、Makefile を変更して、カーネルソースのあるディレクトリを指定することで、簡単にビルドできます。
例えば僕の開発環境のandroidの場合
export ARCH=arm export CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- git clone git://github.com/panicking/snd-usb-asyncaudio.git cd snd-usb-asyncaudio emacs Makefile KDIR := /lib/modules/$(shell uname -r)/build この行はカーネルのソースがあるディレクトリにリンクされることになりますので KDIR := ../linux-sunxi に変更 make
これでビルドできます。linux-sunxiというのはandroidのソースが展開されているディレクトリです。
実機への組み込みはカレントにsnd-usb-asyncaudio.koを置いて
cp snd-usb-asyncaudio.ko /lib/modules/3.0.52-t3_SmartTV_UAC2.0/kernel/sound/ insmod /lib/modules/3.0.52-t3_SmartTV_UAC2.0/kernel/sound/snd-usb-asyncaudio.ko depmod -a nano /etc/modules 末尾に snd-usb-asyncaudio という行を挿入 再起動 reboot 組み込みの確認 lsmod
です。
という次第で、cubox用のものもビルドしましたので、公開します(121222版用です)。
xz -dv で展開したsnd-usb-asyncaudio.koを
/lib/modules/3.4.19-rt30_CuboxAudioRTuned/kernel/sound/
にコピーしてお使いください。組み込み方は上記の内容を参考にして下さい。
なお、えふさんから、MPD on android のsnd-usb-asyncaudio.koはhiFace Proを繫ぐとノイズまみれになると報告を頂いています。SmartTVBoxのバスパワーのusb接続での問題であることが考えられますが、cuboxでも駄目だとなる可能性もありますので、ご了解ください。cuboxでも駄目の場合は Trimarchi さんドライバはインテル系マシン専用ということになりますね。
(PC_Audio) 2013/02/09
MPD on Android(3)
Phoeniciaさんが MPD on Android のさらにチューニングされたカーネル(uImage)を作成されたので、公開します。
内容を、Phoeniciaさんから頂戴したメールと僕のメールから抜粋して、ご紹介します。
さて、SmartTV用カーネルは本当の最終版を作りました。 何だか音が変わったような。 半ばやけくそでサイズを小さくするのに拘ったのと、カーネルによるタスクエラー監視 やメモリエラー発生時のリカバリー処理などを外しています。 不特定多数のアプリを動かす訳ではないのでこれでいいかなと思います。 これで通常動作時topで見るタスク数は53まで減っています。 これ以上やると、先ずapeの再生が、ノイズが乗る→ハングする となります。 更に削るとハイビットレートがNGとなり、全く使い物にならなくなります。 今日ずっと聞いていて、31番に変えて以降何かが変わった気がしていたのは どうも音が前に飛んでくるようになったのではないかと気づきました。
僕のご返事。
最新版の32-CFQを聴いてみました。素晴らしいですね。 音の鮮度が断然上がっていますね。これはお勧めだと思います。 apeファイルも再生してみましたが、いいです。「紅葉襲」の和楽器と打楽器が ほんとにリアルです。是非公開しましょう。
という次第です。興味のある方はお試し下さい。
カーネル本体と関連するドキュメントをアーカイブしたものを以下のリンク先からダウンロードできます。
アーカイブの内容は以下の通りです。
/build_files/config-130127-32-CFQ /build_files/uImage-32-CFQ /build_files/config-130127-32-CFQ_All_Item.txt /build_files/kernel_Build-32.txt /usr/local/sbin/selboot
インストールの仕方は、ダウンロードしたアーカイブを適当な場所に置き、前々回公開したイメージでシステムを立ち上げ、ルートディレクト(/)に移動し、アーカイブを展開すればいいです。
cd / tar -Jxvf /ダウンロードしたファイルを置いたディレクトリ名/android-kernel-32-CFQ.tar.xz
uImage名が30番台になったのでselbootも変更しています。アーカイブに入れてありますので、上記の操作で入れ代わります。ブートカーネルの指定方法は「uImage-」以降を入力して下さい。新しいカーネルを指定する場合は
selboot 32-CFQ
となります。
また、MPD on androidイメージのブートパーティションはfatですので、Windowsを使ってカーネルだけ入れ換えることができます。xz形式はbitzipperかlhazで解凍できるようなので、これで解凍し、build_files内のuImage-32-CFQをuImageとリネームし、ブートパーティションのuImageと入れ換えて下さい。入れ換える前にオリジナルのuImageはバックアップしておいた方がよいかと思います。
20130206追記
ある方から『カーネルを適当な場所に置き、展開する』するとはどういう意味ですか ?」という質問がありました。確かにlinuxに慣れていない方からみると意味不明かもしれませんので、追記しておきます。
「置く」というのは
tar -Jxvf /ダウンロードしたファイルを置いたディレクトリ名/android-kernel-32-CFQ.tar.xz
の「/ダウンロードしたファイルを置いたディレクトリ名/」と入力できる場所にダウンロードしたファイルを持ってくる(移動、コピー)するという意味です。
持ってくる方法としては
- nasを使う(Windowsのコピーを使う)
- usbメモリを使う(Windowsのコピーを使う)
- linuxのwgetコマンドを使う(linuxのwgetコマンドを使う)
などの方法があります。
nas接続しているならば一番目の方法がお勧めです。
やり方は簡単で、nas のルートディレクトリ(/etc/fstabに追加した行の //192.168.n.n/XXXX /music cifs …となっている行のXXXのことです)にアーカイブ(android-kernel-32-CFQ.tar.xz)をコピーしておいて
cd / tar -Jxvf /music/android-kernel-32-CFQ.tar.xz
と入力して下さい。
正常に終了した場合は展開されたディレクトリ名ファイル名が連続して表示されるはずです。
二番目の方法はSmartTVBoxの場合、セルフパワー型電源のディスクが必要です。三番目の方法は、Googleドライブを使っているため、ダウンロードするurlの取得が難しいので、解説は省略します。という次第で一番目の方法をお勧めします。
(PC_Audio) 2013/02/02
top page previous page next page
