スピノル
スピノル

マイルーム

スピノルのマイルーム
スピノルのマイルーム
持ち家(マンション) / リビング兼用 / オーディオ・シアター兼用ルーム / 16畳~ / 防音なし / スクリーン~100型 / ~4ch
元自作派
所有製品

レビュー/コメント

レビュー/コメントはありません

カレンダー

          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            

お気に入り製品

お気に入りユーザー

お気に入りユーザーはありません

日記

UNIX を用いる際の落とし穴

このエントリーをはてなブックマークに追加
2010年01月27日

http://upload.wikimedia.org/wikipedia/commons/d/d9/Unix_history-simple.en.svg
こんな感じであり、私の個人的趣味としては;

BSD = SunOS = FreeBSD = Mac OS X →→ SystemV = Solaris = Linux →→→→ Windows

なので、Mac に、Windows とか Linux をインストールするというのは、いわば、
神棚に下駄とかゴム長を置くようなもので、感覚的に非常に違和感があります。

> 手元のノートPCの空き領域で、試してみました。

これは、Windows + Linux なので、まあ、許せる。。

***

なんてことはどうでも良くて、ここで言いたいのは、オーディオマニアが
UNIX を用いる際に留意すべきことで、

それは、何かと言うと、、




(次回に続く、、。)

ではなくて、

http://en.wikipedia.org/wiki/Unix
 Unix was designed to be portable, multi-tasking and multi-user
 in a time-sharing configuration.

ということです。

ここで、multi-user というところに注目して頂きたいのですが、要するに、
知らない人がいっぱい(!)やってきて、好き勝手なことをする訳です。

そのような中で、CPU や、Memory や、I/O といったシステム資源をどのように
配分するか??

1つの手段が、

 pam_limits - PAM module to limit resources
  By default limits are taken from the /etc/security/limits.conf config file.

であり、そのなかの1つの item が、

    <item>
      memlock
      maximum locked-in-memory address space (KB)

ですね。

貴重な実メモリという資源を、誰にどのように優先的に配分するか?

この人(あるいは、グループ。例えば、audio とか。)であれば、
この値の上限までは(もし、要求してくれば!)認めて上げても良い、、。

***

しかしながら、オーディオマニアが音楽再生のために UNIX を用いる際には、
何が起きているかというと、

システム内には、自分一人(!)しかいなくて、しかも、わかった仕事を(!)
わかった量だけ(!)やっているので、、、

# これは UNIX からすれば、(考察の対象外とも言うべき)非常に特殊な状況。

システム資源をどのように配分すべきかなんて問題は、そもそも、最初から
存在していない訳です。

# OS よりさらに偉い、自分という神様が何でも決めれる。

したがって、memlock を設定する必要も、実は初めから、、、、、。

***

ちなみに、以下もついでに引用しておきます。

http://en.wikipedia.org/wiki/Unix
 Unix systems are characterized by various concepts:
 the use of plain text for storing data; a hierarchical file system;
 treating devices and certain types of inter-process communication (IPC) as files;
 and the use of a large number of software tools,
 small programs that can be strung together through a command line interpreter using pipes,
 as opposed to using a single monolithic program that includes all of the same functionality.
 These concepts are collectively known as the Unix philosophy.

簡潔に特徴がまとめられていますね。

次回の日記→

←前回の日記

レス一覧

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

    なるほど、いろいろと見えてきた事もありますね。
    #まあ、僕の場合は音が良ければいいわけなので、そのためにはあるモノ&使えるモノは何でもつかえ、という立場ですが。(笑)

    ただ、これは揚げ足取りではなくて素朴な疑問としてお聞きしますが10.5以降のMacOSは、もっとばりばりにUNIX完全互換ですよね。
    で、GUIでグラフィックな縛りをいるものの、コンソール起動などして野生に戻したら同じ問題が生じるように思うのですが、コマンドラインの再生ではリソースを食わないからはじめからそんな心配はいらない、と言うことになるのでしょうか?

    そもそも入力からDA変換までの長いプロセスの中で、Time Criticalであることは、コンピュータ的負荷としてどうなのでしょう?スタジオのエンジニアなども、その点はコンピュータ屋さんとかなり感覚が違うように思うのですが。その辺りの全体イメージがはっきりしないように、いつも思います。

    by大天使心得 at2010-01-27 10:31

  2. 済みません、ひとつ忘れてました。
    我が家でトリプルブートをしてみたのは実例も多数あったのと、同じハード環境で再生しないと音が違うという事について納得していただけないだろう、と慮んばかってのことです。
    つまりは音質が良い状態をどれが最も達成してくれるか、というセレクションをするための試みの一つです。

    by大天使心得 at2010-01-27 11:00

  3. コメントありがとうございます。

    > #まあ、僕の場合は音が良ければいいわけなので、

    ここが私の一番のネックで、音の評価能力が無いので、いくら屁理屈を並べても、
    根っこが腐ってる(可能性が常に排除できない)。。

    # 理屈というのは言おうと思えば、如何なることでも言えるので、
      音の良し悪しで検証されない限りは、仮にもっともらしく聞えたとしても、
      音楽再生に取っては、何の役にも立たないと言うことですわ。

    > そのためにはあるモノ&使えるモノは何でもつかえ、という立場ですが。

    と言うことなので、耳で聞いて良ければ何でもありでOKなんですが、
    多少コストパフォーマンス的な考慮をするとすれば(←あるまじき、不純な態度?)、

    半日も調べないであれこれ言うのも不適当なんですが、ちょこっと見た限りでは、
    FFADO がらみの話は、未だちょっと端境期ですよね。

    現状、やるとすれば、libffado-2.0.0.tar.gz と、JACK とを、(依存関係を解決して!)、
    自分で compile して install する、あるいは、kernel 2.6.32.5 を入れてみるのかな、、と思うのですが、

    # rt の patch は、2.6.31.12 までかな。けど、私は、、(後述)。
    # いずれにせよ、Ubuntu Studio は、必要ないと思っています。

    ここは、しばらく放置というのも、一つの手ではないかという気もします。

    半年もしない内に、今から始める人はいいよねぇ、、ということに
    なっているんじゃないでしょうか。

    # 趣味なので、自分の好きなタイミングで、自分の好きなことから手を付ければ
      良いのではありますが。

    ***

    > ただ、これは揚げ足取りではなくて

    揚げ足取りは、大好きです。(取るのも、取られるもの。)

    > 素朴な疑問としてお聞きしますが10.5以降のMacOSは、もっとばりばりにUNIX完全互換ですよね。
    > で、GUIでグラフィックな縛りをいるものの、コンソール起動などして野生に戻したら
    > 同じ問題が生じるように思うのですが、コマンドラインの再生ではリソースを食わないから
    > はじめからそんな心配はいらない、と言うことになるのでしょうか?

    すみません。この段落、ご指摘の趣旨が理解できていません。
    そのうち理解できるかとは思いますが、それまでちょっと保留させて下さい。

    ***

    > Time Criticalであることは、コンピュータ的負荷としてどうなのでしょう?

    ここから先は長くなりそうなので、別途としたいのですが、とりあえずの話としては、

    私は、real-time kernel は、音楽再生に関しては、不要だと思っています。
    (なので、rt の patch は、気にしていない。)

    > スタジオのエンジニアなども、その点はコンピュータ屋さんとかなり感覚が違うように思うのですが。

    私は、スタジオに居る方たちは、エンジニア(と呼ばれてはいても)ではなくて、
    アーティストだと思っています。

    # 私の定義では、エンジニアとは設計ができる人のことなので。

    > そもそも入力からDA変換までの長いプロセスの中で、(中略)、
    > その辺りの全体イメージがはっきりしないように、いつも思います。

    私の場合、ダウンロードしたファイル、あるいは、主記憶にロードされたデータ、
    あるいは、SD Card に書かれたデータが神様なので、プロセスとしては、随分と
    単純化しては、考えているわけです。

    (製作工程による相違は大きいと思いますが、関与できない部分なので、
     演奏家の好き嫌いを含め、全てコミで、ソフト探し問題に帰着する。
     おっしゃれた「入力」とは、マイク入力と解釈しています。)

    # ちょっと、ご指摘の趣旨とは話がずれてますか。。

    ***

    > 我が家でトリプルブートをしてみたのは実例も多数あったのと、
    > 同じハード環境で再生しないと音が違うという事について納得していただけないだろう、
    > と慮んばかってのことです。

    神棚の件はともかく、労力を考えると、同じハードを3台並べた方が、ずっと楽ですよね。
    けど、個体差がとか言う人がきっといるからなぁ。。

    byスピノル at2010-01-27 17:36

  4. いろいろとありがとうございます。
    僕らは基本的な知識なしに飛び込んでいるので、こうしてインテリジェンスを提供していただくと助かります。

    >現状、やるとすれば、libffado-2.0.0.tar.gz と、JACK とを、(依存関係を解決して!)、自分で compile して install する、あるいは、kernel 2.6.32.5 を入れてみるのかな、、と思うのですが、

    パッケージの詳細を調べたので依存関係は整理できると思います。Ardourだけが必要なバージョンのファイルを確保出来ないので現行のままになりますが、これは多分問題ないかと。
    ただ、僕の役割は独りの素人として一般的に再現可能なモデルを探す事でもありますから、カーネルの再構築とかになると、ちょっとマニアックの度合いを高めるのでそこまではねえ、と思っております。
    でもやってしまうかも....。

    >ここは、しばらく放置というのも、一つの手ではないかという気もします。
    >半年もしない内に、今から始める人はいいよねぇ、、ということになっているんじゃないでしょうか。

    多分そうなると思います。今後はカーネルにFirewireを組み込むようになっているらしいので、尚更かも。ただ、普通は1394や61883はヴィジュアル用ですから、「オーディオ用」として安定的に動いてくれるかどうかは「?」かもしれません。いずれにせよ様子を見ない事には何ともはや。

    >> スタジオのエンジニアなども、その点はコンピュータ屋さんとかなり感覚が違うように思うのですが。

    >私は、スタジオに居る方たちは、エンジニア(と呼ばれてはいても)ではなくて、アーティストだと思っています。

    おお、なんと素晴らしい返し技!こういう風に言えば末端につながる聞き専のわしらも少しは救われますよねえ。いや両方をたてる深いご配慮、拙者感服つかまつりました。

    #コメントアウトのところは別の話と理解しまして。

    >神棚の件はともかく、労力を考えると、同じハードを3台並べた方が、ずっと楽ですよね。

    うう、お金が。(笑)運ぶのも大変だし。まだわしの人件費の方が人生全て是勉強ということで自己正当化できたりして。

    >けど、個体差がとか言う人がきっといるからなぁ。。

    いる、いる。絶対にいます。同じマシンでもHDの外側と内側では......、という人もいるくらいですからね。

    #そういう人ははじめから人の話を聞かないですから、コミュニケーション・ブレイクダウンです。トホホ。


    リアルタイムカーネル(RT)も結局は割り込みなどのスケジューリングの速度アップがその主たる内容のようですね。いろいろ考えると、リアルタイム優先度の設定については音の出方がかなり変わる、というところがむしろRTのメリットかも知れません。スタジオエンジニアにせよ、聞き専にせよ、結局はその辺りのコントロールがどこまで出来るかに関心が深いはずです。
    ただ、例えばMac OS 10.6でGrand Central Dispatchがなければ絶対に駄目か?というと、殆どらしき64bitアプリがない現状で特に困ってませんし、リアルタイムカーネルが必須かどうかは確かに一考の余地有りだと思います。
    この間いろいろやってみて、久しぶりに32bit君に会うと、「ゆっくりしとるなあ。」と思います。特にgeneric-PAEカーネルで起動すると、「ん?」という感じがつきまといます。やはりメモリも含めて64bitのほうが気持ちいいですね。RTと64bit、義理と人情を秤に掛けりゃ~、どっちが重いんだろ?

    ところで先日の「Tera (=10^12) の世界、もしくは、人類の夜明け」の記事面白かったです。「そう、全ては、あいつが植えつけたのじゃ。」久しぶりに笑ってしまいました。いや、すんません。やっぱりどっかにモノリスが密かに立ってるんでしょうか。
    それにしてもUbuntuのダークマターはどこにあるんだろ。僕的にはさっさとコリジョンして消えて欲しいもんです。ってゆーか、ずっとあるんでしょうね。

    by大天使心得 at2010-01-28 21:22

  5. > ただ、僕の役割は独りの素人として一般的に再現可能なモデルを探す事でもありますから、
    > カーネルの再構築とかになると、ちょっとマニアックの度合いを高めるのでそこまではねえ、
    > と思っております。

    既に限界点を大幅に越えてしまっているような気がします。

    # ふと、後を振り返ると誰も居ない。
      http://8.pro.tok2.com/~susa26/ikoi/kaze.html

    以下は、別途。

    byスピノル at2010-01-28 22:47

レスを書く

レスを書くにはログインする必要があります
ログインする