Ubuntu 14.10 で M-AUDIO Fast Track C400 を使用する2014年12月04日 12時17分24秒

alsamixer でのボリューム調整の様子

最近、仕事用のメインマシンを Ubuntu で運用している T.MURACHI です。

音楽ツールの開発にいい加減取り掛かりたいので、 GCC が使いやすい環境ということで Windows 離れを図ったのですが、ここしばらく、使用しているサウンドデバイスである Fast Track C400 から音が出ない現象に悩まされておりました。しかし実際のところ、なんてことのない原因だったことが先日判明したので、お恥ずかしい話ながら、似たような USB オーディオデバイスの Linux での使用を検討している方向けに、情報を開陳しておこうと思った次第であります…。

音量の設定は PulseAudio 側のみではなく alsamixer でも必要ですよ!!

…要点としては以上になります(恥)。

よくわからない方のために一応手順を示しておきますね。

  1. Ubuntu 14.10 (14.04 LTS でもいいや) をインストールする。この時点で、 Fast Track C400 であれば、 USB で接続されていれば認識されている。
  2. 「システム設定」を開き、「サウンド」アイコンをダブルクリック。「サウンドの出力先」に「Fast Track C400」を選ぶ。「モード」は、普通にステレオで使うのであればどれでも構わない (実際に 4.1/5.0/5.1ch 使うのであれば、好きなのを選べば良い)。
  3. ターミナルを起動する。 Windows キーを押すと出てくるリソース検索窓の入力欄に「terminal」と入力すると、「端末」という名前のアプリケーションが候補に出てくるので、それを選んで起動してあげれば ok 。
    • どうせ Linux とか使う奴はしょっちゅうターミナル使うことになるんだろうからドックにアイコン登録しとけ。
  4. ターミナル上で「alsamixer」とタイプし、 Enter する。 alsamixer が起動する。
  5. カーソルキーの左右で、チャンネルと端子の対応を選択することができる。例えば、「PCM1-Out1」は、 ch.#1 のサウンドを Out1 端子から出力する、という意味になる。カーソルキーの上下で、選んだ組み合わせのボリュームを変更できる。こうした操作により、任意の組み合わせのボリュームを調整する。
    • 例えば単にステレオにしたい場合で、 Out1 端子を左スピーカーに、 Out2 端子を右スピーカーに接続している場合、「PCM1-Out1」と「PCM2-Out2」のボリュームを Max にしてあげれば ok 。
  6. 音を鳴らす任意のアプリを動かして、ちゃんと音がなることを確認する。

alsamixer での設定は、通常は一度設定してしまえば OS を再セットアップするんでもない限り保存される模様。ただし、ふとした時に音が出なくなったとお悩みの際には都度この設定を確認してみるといいと思う。

Ubuntu 14.04 を最初に設定した時には音がなっていたような気がしていたのだが、もしかしたらその時にも調べて alsamixer でボリューム調整していたのかもしれない。で、カーネルが更新されたとかのタイミングでリセットされたとか… 設定できる内容を見る限りデフォルトは全チャンネルボリューム 0 じゃないとおかしい気がするので、多分そんなところだったんじゃないかなぁと反省… orz

ちょwwwwはやwwwwww2008年04月16日 10時50分46秒

harapeko.jp の後継サーバはこいつにしてみました。専用サーバのくせして安いのはいいが、CentOS プリインストールのまま何もいじってないしコントロールパネルみたいな便利なものもセキュリティやら監視やらの特別なサービスもなあんもないよー、全部 ssh で設定がんがってねーという、実に漢らしいサービス内容に惚れ込みましたw。収容データセンターがソフトバンク IDC だってのが微妙に気にはなりますが。。。

で、オンライン登録時に「納品できるのに 2週間ぐらいかかります」とか表示されてたので、まぁ現行 harapeko.jp ドメイン消滅やら登記完了やらが重なってむしろ丁度いいかな、設定に時間かかったらドメイン取り直したのにもてあましちゃってあれかもしれないけど、とりあえず気長に待つかぁ、とか思っていたわけですが、登録した翌日には納品書が届きましたよ。これにはさすがに驚いた。設定も完了していて、既に自由に使える状態に。これはうれしい誤算だ。w

そんなわけで、取り急ぎ、apache だけ設定を済ませてみました。いや、 mod_perl とか組み込んでないし全然完璧じゃないですが、とりあえず動いてるっちゅーことで。

sendmail と sftp も設定しちゃわないとなぁ。。。

さくらレンサバに入れたTracから通知メールが飛ばせない2008年04月03日 16時05分58秒

前々から使っているさくらレンタルサーバ上に、最近 Trac を入れて使おうとしているのですが、メール通知の設定をしても、通知メールがうまいこと飛んでこなくて困っています。

trac.ini の [notification] ディレクティブの設定内容は以下の通り (ドメイン名、メールアドレスは便宜上変えてあります)。

[notification]
always_notify_owner = true
always_notify_reporter = true
always_notify_updater = true
mime_encoding = base64
smtp_always_bcc =
#smtp_always_cc = example@example.sakura.ne.jp
smtp_default_domain =
smtp_enabled = true
smtp_from = example@example.sakura.ne.jp
smtp_password =
smtp_port = 587
smtp_replyto = example@example.sakura.ne.jp
smtp_server = example.sakura.ne.jp
smtp_subject_prefix = __default__
smtp_user =
use_public_cc = false
use_short_addr = false
use_tls = false

smtp_always_cc のコメントアウトをはずすと、そこで指定したメールアドレスがレンタルサーバー上に設定されたアドレスであれば、そのアドレスにだけはメールが届きます。

smtp_always_cc をコメントアウトしたままの場合、以下のような動作になるようです。

  • Ticket の報告者がレンタルサーバー上に設定されたメールアドレスを設定している場合、通知メールは問題なく配信される。

  • Ticket の報告者がレンタルサーバー外の (例えば ISP などが提供する) メールアドレスを設定している場合、通知メールは届かない。そして、log/trac.log には以下のようなエラーログが出力される。

    2008-04-03 16:13:26,873 Trac[web_ui] ERROR: Failure sending notification on change to ticket #3: {u'murachi@example.ne.jp': (553, '5.3.0 <murachi@example.ne.jp>... Please receive your mail before sending')}
    Traceback (most recent call last):
      File "/home/example/local/lib/python2.4/site-packages/trac/ticket/web_ui.py", line 562, in _do_save
        tn.notify(ticket, newticket=False, modtime=now)
      File "/home/example/local/lib/python2.4/site-packages/trac/ticket/notification.py", line 129, in notify
        NotifyEmail.notify(self, ticket.id, subject)
      File "/home/example/local/lib/python2.4/site-packages/trac/notification.py",line 216, in notify
        Notify.notify(self, resid)
      File "/home/example/local/lib/python2.4/site-packages/trac/notification.py",line 115, in notify
        self.send(torcpts, ccrcpts)
      File "/home/example/local/lib/python2.4/site-packages/trac/ticket/notification.py", line 275, in send
        NotifyEmail.send(self, torcpts, ccrcpts, hdrs)
      File "/home/example/local/lib/python2.4/site-packages/trac/notification.py",line 368, in send
        self.server.sendmail(msg['From'], recipients, msgtext)
      File "/usr/local/lib/python2.4/smtplib.py", line 691, in sendmail
        raise SMTPRecipientsRefused(senderrs)
    SMTPRecipientsRefused: {u'murachi@example.ne.jp': (553, '5.3.0 <murachi@example.ne.jp>... Please receive your mail before sending')}
    

別に通知機能自体は今すぐ必要なわけではないんですが、何でこうなっちゃうのかだけは一応知っておきたいので、とりあえずメモってみます。。。

そもそもさくらのレンサバの sendmail がそういうものなのかなぁ。。。あ、ちなみに smtp_port が 587 になってますが、25 のままでももちろんダメでした。


Thu Apr 3 21:30:39 JST 2008 - 追記

とりあえず調べてみたらエラーの内容はなんとなくわかってきた。

  • SMTPRecipientsRefused は、 Python のモジュール smtplib が送出する例外で、すべての受取人が (sendmail コマンドによって) 弾かれた場合にのみ発生するらしい。
  • ログの最終行の 553 という数字は、 sendmail コマンドが返すエラーコードで、不正中継っぽいもの (spam の踏み台である可能性があるケース) を弾いたときのものっぽいです。

さくらのレンサバの sendmail コマンドのポリシーがどうなってるのかがいまいちよくわからんのですが、その辺の設定が仮に変えられるのだとして、その為に spam の踏み台になるリスクが生まれるんだとするとそれはさすがにまずいので、この辺は良く調べてから対応したほうがよさそう。そもそも回避できないのかもしれないけど。。。

当面は通知なしで運用しようかな。(←ひよったw)

はまちちゃんとこに IPA からよくわからないメールが届いた件2007年02月06日 00時24分12秒

??? なんか、お礼のメールが来たみたいだけど、これってよーするに「受理しました」ってことなの? それとも「受理はしてない (だから仕事はしない) けど、とりあえずお礼のメールだけ返してうやむやにしておきます」ってこと? おいら、じぇんじぇんわかりましぇん >< 。

受理された脆弱性はその概要がここに表示されるらしい (Tue Feb 6 10:43:43 JST 2007 追記: Web サイトの脆弱性はここに表示されるわけではないっぽいです。謹んで訂正) んだけど、はまちちゃんとこにきたメールに書かれてるような書式の ID は見当たらないし、Yahoo! がどうこう、なんて記述も見当たらないし。。。

はまちちゃんが言いたいこともわかるけど (おいらも一部似たようなこと書いたし)、その気持ちが IPA たんには伝わりにくそうな態度しかとってなかったっていう意味では五十歩百歩かなぁ。面白かったけど。

とにもかくにも、IPA がちゃんと仕事をしてくれることを願ってやみません。。。


Tue Feb 6 10:43:43 JST 2007 - 追記

はてブのコメントにて指摘がありました。JVN はあくまで「ソフトウェア製品の脆弱性関連情報」を扱うサイトであって、Web サイトが脆弱であることに関連する情報を扱っているわけではない、ということかと思われます (なのよね?)。謹んで訂正。。。

ああ、そうか。2007年02月03日 10時22分32秒

このコメント書いてから、ふと思ったんだけど、氏名公表しちゃっても構わない人が、氏名公表したくない人の代わりに報告してあげればいいんだ。

ちうわけで、ぜーじゃくせー発見したけど IPA に氏名公表したくない、ってひとは、以下のアドレスまでその内容をメールしてくだちゃれ。暇だったらおいらが代わりに IPA に報告するかもしれないし、しないかもしれませんw

main-window (あ) harapeko.jp

# はまちちゃんにもメールしてみますた。

リファラースパムがどーたらこーたら2007年01月21日 00時54分02秒

んー、よーするに Referer が本当にリンク元になってるかどうか、その URL にアクセスして調べるようにすればよくね? なんて言ってみる。まぁ、大手サイトだとそんなん重くてやってらんないだろうけど (トラックバックの「言及リンク」チェックほど甘くは無いか)。

うちみたいに、月 10,000 PV 行かないようなサイトならそれなりに有効な気がする。

アクセスログ調べるときにうざいって言うだけの話なら、統計取るときに調べてはじくスクリプト書けば ok だわね。

綺麗なコードを心がける。2007年01月13日 03時45分00秒

賛否両論出ているようですが。。。おいらとしては概ね賛同。

コードを綺麗に書くことによって得られる最大の利点は、メンテナンス性にあります。可読性の低いコードは、修正や拡張が困難になる。ソフトウェア資産は蓄積されてゆくものだから、メンテナンス性の低いコードが量産されれば、それをメンテナンスし続ける企業にとっては不良債権にもなりかねないわけです。

実際それが原因で一方的に契約を切られた挙句、1年間近く無償の瑕疵保証対応に駆り出され続けた某社の人たちを現場で見てきたわけですが。。。

で、話を記事のほうに移すわけですが、冒頭のサンプルプログラムに対する批判が多いっすね (^_^; 。客観性を排除してこのサンプルに限って議論するなら、リスト 2 が優れているのは、二人のプレイヤーの対称性、可換性を、うまく表現している点にあると思う。「一般化できる問題は、できる限り一般化する」というのはプログラミングにおける基本中の基本。プレイヤー 1 よりプレイヤー 2 の方が勝っている場合と、逆の場合とで、別個にコードの記述が存在するようでは、後の仕様変更で、片方のケースしか仕様変更が適用されなかったというミスに繋がりかねない。これを「メンテナンス性の欠如」と言わずして、なんと言おうか。

但し、リスト 1 の方が、リスト 2 よりも可読性は高そうだ恐らく、このサンプルがいまいち納得されにくくなっている一番の要因は、この点にあるんじゃないかと思う。リスト 2 に対しては、適切なコメント付けが必要になるんではないかと思う。逆にいえば、適切なコメントが追加されるのであれば、リスト 2 がリスト 1 より劣っていると言える理由は、他にはなくなるんじゃないかと思う。インデントに関する好みとか、細かい部分での意見の分裂はあるかもしれないけど。

汚いコードができる理由については、最初、3 つの項目を見たときには、「なんか微妙に体育会系っぽい意見だなぁ」とか思ってしまったわけですが、読み進んでいくうちに概ね納得しました。まぁ、プログラミングって、キータイプが速けりゃ仕事も早く片付くってもんでもないし、一般化・抽象化できる要素を洗い出す作業に時間をかけるより、コピペしちゃったほうが早い、ってのも確かなんだよね。ブラッシュアップ工数を見積もりに計上したいってのが、多くの開発者にとっての本音でもあり。。。

学習については、、、おいらの体験談を明かすならば、大学ではもっぱら C と BASIC とアセンブリ言語ぐらいしか講義としては扱われなかったってこともあって、当時 C++ や Java で取り入れられ始めていた「例外」って概念を知らなかった。入社一年目の仕事で、とある C++ で書かれたプログラムのメモリエラー検出を、new 演算子が返すポインタの NULL チェックでやるのをやめて、bad_alloc 例外を検出する方法で書き直そう、という話があって、そのときおいらが担当していたモジュール (NG 喰らった前任者が残していった、それこそ不良債権w) でも対応作業を行ったわけですが、なんだか 2000 行近くある関数内の至るところに new が散りばめられていて (^_^; 、まぁ、関数内全部 try で括っちゃえばよかったんですが、それをやらずに散りばめられた new ごとに対応する trycatch を書いて、なんてことをやっていたら、後のコードレビューで流石に顰蹙買ってしまいまして、なんてことをやらかしたこともあったもんで、、、ただ体験的に綺麗なコードを書くことを心がけることの重要性を知らしめるのも重要っちゃ重要なのですが、やっぱりプログラミングスタイルを決定付ける様々な概念に対して、知識を深めることもまた、同時に同じくらい重要なんだろうなぁという気はするのでありまする。

熱意ってのは、よーするに優先度の問題ってことかな。大切なことだとは分かっていても、どうしても軽視してしまいがち、ってのはあるかもしれないね。だからこそ、それを適切に評価する機会を設けるってのは、大切なことだと思う。コードレビュー、ちゃんとやってますか?

無線LANセキュリティ関連メモ2006年12月28日 00時38分51秒

  • 訂正ありご注意→セキュリティのセの字も考えてないライブドアの公衆無線LANサービス (Web屋のネタ帳 さま)

    MACアドレスのよくある誤解その2: 「MACアドレスはその機器(PC等)の持ち主しか知りえない」

    そんなわけない。Windowsのコマンドプロンプトを開いて「arp -a」とたたいてみよう。

  • livedoor Wirelessのラの字も考えてないWeb屋のネタ帳の誤読記事 (最速インターフェース研究会 さま)
    実際のところは事前にWEPキー(申込み時にユーザー毎に割り当てられる10文字程度の英数字)を機器にあらかじめ設定しておくことが必要
    これも間違い。そういう形態でサービス提供することは不可能だと思う。書いていい話なのかどうかわからないけど自分が知る限りlivedoor WirelessのWEPキーはユーザー毎ではなく全ユーザー共通。これは低価格の公衆無線LANでは(たぶん)一般的なんじゃないかと思う。複数使い分けられるのはあった気がする。
  • livedoor Wirelessの話の続き (最速インターフェース研究会 さま)
    2. 技術的な抑止力があるかどうか
    担当者じゃないんで知りませんが、同じMACアドレスが物理的に離れたアクセスポイントで使われてたら不正利用だってのはわかるよね。あとMACアドレスで製品名わかるはずなのでゲーム機でSPAM送信してたらおかしいとか、そういう。
  • HiromitsuTakagiのブックマーク / 2006年12月27日
    不正アクセス禁止法2条の定義の「識別符号」。ISBN4-8037-0915-7によると「識別符号は利用権者等に付されるものでなければならない」「機器に付される識別情報は識別符号に該当しない」とあるが、3条2項2号に該当するか?

なるほど。。。いろいろと勉強になりますた。そんだけ。w

そういやおいらの周囲には NDS 持ってる人が結構いるから、このへん↓もついでにリンクしとこう。

不安な方は設定修正いたしまする。>関係者各位

議事録ドリブン2006年12月13日 11時37分16秒

まずはツアーを見て頂きたい (ナレーターおねーちゃんの絵が微妙だとか言うな)。Sargasso XM というツールの出来についてはどうかは知らないが、この「議事録ドリブン」という考え方は圧倒的に正しいと思うし、そのスタイルを強制する為のシステムであるという点に大きな意義があるように思う。

この製品を使わずとも、職場の人間に、先のツアーを見せてあげるだけでも、次回以降の会議がかなり有意義なものになるのではないだろうか。

  • 会議とは、議事録を共同で作成する作業である。
  • 会議はテーマを明確にし、そのテーマに沿った議論のみを行うべきである。
  • 会議の目的は議論ではなく、結論を出すことである。

経営情報2006年12月07日 11時00分42秒

経営情報学についてはあんまり興味のないおいらなのですが、上記記事が結構面白かったので、著者の方のサイトを覗いてみました。

経営と情報に関する私の主張の中で、ERPパッケージ批判という記事があり、まだこれぐらいしか目を通していないのですが、これがまた面白い。要チェックです。