LadioCastバージョン0.8.1をリリースします。
- LadioCast-0.8.1.dmg (ユニバーサルバイナリ・Mac OS X 10.4 “Tiger” 以降)
0.8.0から0.8.1への変更点は以下のとおりです。
- 入力のステレオチャンネルを個々にパンできるようミキサースイッチを追加
0.8全体、まあこんな感じでしょう。
2009年1月アーカイブ
LadioCastバージョン0.8.0をリリースします。
- LadioCast-0.8.0.dmg (ユニバーサルバイナリ・Mac OS X 10.4 “Tiger” 以降)
0.7.5から0.8.0への変更点は以下のとおりです。
- メイン出力デバイスに指定無し(N/A)を選択できるよう変更
- 出力デバイスのサンプルレートに44100Hz以外のデバイスも選択できるよう変更
- エンコーディングサンプルレートに48000Hzから96000Hzまで計4段階を追加
- システム内部サンプルレートを指定できるよう変更
変更点のうち「システム内部サンプルレート」について説明する必要があると思います。
これはLadioCastの内部音声処理のサンプルレートの意味で、エンコーディングに用いるサンプルレートとは別のものです。
Mac CoreAudioによる処理では一般的にサンプルレート44100Hzが用いられこれは例えばCDのサンプルレートと同じ値です。
Macで使われるほとんどの入力デバイス、出力デバイスでもサンプルレートのデフォルトにこの値が設定されるようです。
よって今回のシステムサンプルレートもデフォルトである44100Hzで通常の処理には十分な値です。
入出力デバイスのサンプルレートは標準アプリケーション「Audio MIDI 設定」によって参照し変更することができます。 多くの場合デフォルトより高いサンプルレートを指定することができるようです。 システムサンプルレートはそのようなCDを超える音質についても品質を落とさず処理できるよう追加した設定です。 従って音声のアナログ部分も含めて相応する高音質な環境がある場合のみそれらに合わせて変更してみて下さい。
なお直接関係ありませんがエンコーディングのサンプルレートについては「自動」をお薦めしています。 エンコーダー自らがその他の設定値から判断する値がほとんどの場合最も良い結果になると思います。 ちなみにシステムサンプルレートを48000Hzに上げエンコーディングビットレートを128kbpsにした場合、Lame MP3エンコーダーはエンコーディングサンプルレートとしても48000Hzを採用するようです。
とりあえずこんなところで。 0.8ではしかし使われなかったコードをずいぶん書いてしまった感。
新年あけましておめでとうございます。
書くネタはありつつずいぶんブログを更新できていませんでした。 久しぶりに手を入れているLadioCastの方はまだまだリリースするには至らない状況ですので、今回は新春にふさわしく予想、というより深読みをしてみましょう。ネタはこのブログでもおなじみlivedoorねとらじから、お知らせ yp・ストリーミングサーバの新ドメイン設定を行ないましたです。
前々からねとらじのストリーミングサーバのアドレスがIPアドレス表記(203.131.199.131というやつね)なのは不思議でした。 ドメイン名を使いたくない政治的な理由があったのか、クライアントソフトウェアのバグ回避のため(実際libshoutにはドメイン名指定での接続に若干バグがあります)だったのか、単なる行きがかり上の話だったのか。 いずれにしても私はその不思議な話につき合う必要を感じなかったので、LadioCastのデフォルトには最初からドメイン名表記(std1.ladio.livedoor.jpというやつね)の方を採用していました。
今livedoorねとらじのストリーミングサーバが正式に(新)ドメイン名を利用した表記(std1.ladio.netというやつね)をアナウンスする理由は何でしょう。 すぐ思いつくのはサービス自体を売却譲渡する展開です!。 抽象的なドメイン名にしておけば、ユーザ側に設定移行の手間をかけることも少く、ねとらじからlivedoorという冠をはずしやすくもなります。 いわば嫁入り支度ですね^^。 まあこれは冗談ですので、本題の負荷対策の可能性の方に移りましょう。
負荷対策の話をする前に「ミラー」について少し。 「負荷分散」のためとして、リスナー数の多い放送をミラー(クライアントソフトウェアで受信した放送をそのまま送信することを指す)して複数放送にするという行為があります。これも私にとって不思議でした。一般的に考えればサーバの「負荷分散」になるのは、相対的に負荷の高いサーバから低いサーバへミラーされる場合のみ。同一サーバの別ポートにミラーされたところで「負荷」が軽くなるわけがありません。むしろミラーと称して同じような設定記述で放送された場合、当該放送をキーワードで自動再生や録音をしているソフトウェアから重ねて接続されてしまい前より負荷が上がるということが起こるでしょう。にもかかわらず、今でこそ2台稼動になったねとらじストリーミングサーバがまだ1台稼動だった時代から、ミラーはありました。なぜでしょうね。
それは「負荷分散」ではなく「接続数分散」をしないと接続できない状態になるからでしょう。 現行のサーバ設定面から見ていくとポート毎の接続数については上限に4000という値を設定している旨、livedoorねとらじのブログに書かれています。これでまずリスナー数4000を超える放送は単一接続ではできないことがわかります。 では接続数が4000までは大丈夫でしょうか?。 これに関しては年末に起ったアニソン三昧中継放送の嵐の中でわかったことがありました。
というところで記事が長くなってしまいましたので^^;、続きはまた次回に書きたいと思います。それでは今年もよろしくお願いいたします。
