I2Sの世界第二幕(4)


海外から購入できる組み立て済のHDMI変換基板を紹介しておきます。


このdiyAudioのスレッドも参考になると思います。

今年の6月に開始されたスレッドですから、随分新しいのですが、案外情報がないのですね。グローバルに見ても、HDMI-I2Sインターフェースはマイナーなのかもしれません。

「俺は海外から輸入なんてことは嫌いだ」という方はこちらをご覧下さい。

  • HDMI-I2S送受信基板
    やなさんのサイトにある基板です。送信と受信がセットになっていて、一部の部品が添付されたセットです。
    当然全ての部品を自分で揃え、ハンダ付けする必要があります。


日本でI2S接続にこだわっているのはFidelix社でしょうね。同社のDAC CAPRICEは5年以上前からHDMI-I2S接続可能でした。また、この接続を使って、DSDネイティブモードでの再生が可能でした。当然、再生環境は極めてタイトでしたが(Windowsで専用ドライバ、専用プレーヤがないと再生できなかった筈です)。

同社のサイトにI2Sに関するユニークな考察記事があります。代表の中川さんが書かれたものです。先見性は凄いと思います。

これらの記事は2010年頃のものです。PCオーディオが始まったばかりの頃にもかかわらず、中川さんはI2S接続に注目し、議論していました。素晴らしいですね。

最後にこれはmoOdeの掲示板で見付けたスレッド。今年の2月です。

やり取りを読んで頂くとお分かりになると思います。rpiとmoOdeを使ってI2S GPIOボードを繫ぐのが当たり前の連中の間でも、「HDMIを使って、rpiとキツネDACを簡単に繫げる」という事実があまり理解されていないことがよく分かります。

グーグル翻訳で訳してみましょう。

こんにちは!皆様

最近、Holo Spring 2 DACを入手し、pi3をHDMI(i2s仕様)経由でi2sに接続しようとしました。 Moodeのi2sオーディオデバイスの下には「Holo Spring 2 DAC」はありません。 リストにあるほとんどすべてのi2sデバイスを試しましたが、運はありませんでした。 サポートされている互換性のあるデバイスや回避策はありますか?
-------------------------------
Raspberry Piは、HDMIポートでI2Sをサポートしていません。 Piに接続できる何らかのI2S-to-HDMIコンバーターボードを入手する必要があります。

moOdeのI2Sデバイスリストのデバイスは、Raspberry Piの40ピンヘッダーに接続し、I2S信号を伝送するGPIOピンを使用します。

中川さんの記事から10年経っても、世の中まったく変わっていない。困ったものです。

ところで、このグーグル翻訳は手直ししたのは頭の「皆様」だけ(元は「全員」となっていました)です。素晴らしい精度ですね。これを使って、僕のサイトもグーバル化対応させるかなと考えています。またまた脱線ですね(^^;;;。

以上で第二番目の茨、接続の茨の説明はお終いです。

続いて第三の茨。ドライバの茨。
互換性、接続に茨があるのは分かる。「しかし、何でドライバに茨の刺があるのじゃ」という質問はあろうかと思います。当然ですね。

ところが、あるのですね。理由は次の通り。

GPIO直結の音源基板(DAC)はそれぞれ専用のdtboを指定して、構成情報をドライバに渡す方式をとっていいます。ところが、HDMI接続するDACには専用のdtboなんて変なものはありません。当然です。この連載の最初に書いたように、HDMI接続はDDCとの間で行われ、直結するわけではないからです。直結しようなんて考える人はこのサイトの記事を読む変人だけです(^^;;;。

では、どうするか。
rpiには rpi-dac.dtboという名前のディフォルトのドライバの設定がありますから、これを指定すればいいです。但し、問題が二つあります。

  • mclk信号が必要なDACは使えない
  • rpi-dacでも駄目なことはある


どういう意味か順番に説明します。



写真はAitDACをi2s接続で、rpi-3BとSMPDを使い、接続した時のものです。
AitDACはUSB入力した場合もDDC基板から直接i2s信号を取り出し、アイソレータ基板を介しi2s信号を受けるという構成になっています。従って、rpiと接続する場合もご覧のようにrpi-3Bを箱の中に入れて、直接このアイソレータ基板に接続することになります。

この写真をご覧いただくとお分かりのようにrpi-3BとAitDACを直接では間にDAC基板(hifi-dac-hat)を間に入れています。これはmclk信号をこの基板から取り出すためです。前回ご説明したように、rpiからGPIO経由でmclk信号は出力されません。

MCLKについてはwikipediaでは以下の通り説明されています。

Master clock (typically 256 x LRCLK)
This is not part of the I2S standard but is commonly included for synchronizing the internal operation of the analog/digital converters.
A multiplexed data line for upload.

日本語の説明です(これは前回リンクしたraspberry-pi-2i2s-dacによります)。

mclk (Maser Clock)
SYSCLK(System Clock)とも記述される。デジタル信号の動作基準となるクロック信号。一番高い周波数が使われる。DAコンバータの内部処理で(オーバサンプリングやΔΣ変調の)クロックとして使われる。ICによっては、外部からクロックを供給せずに、上記3信号と同期するようにしてMCLKの供給が必要になることがある。コンバータ側に用意されていて、転送は不要というDACが多い。

ちょっと脱線しますが、rpiのmclkの扱いについては問題があり、登場初期の頃から指摘されてきました。diyAudioでのスレッド(Raspberry Pi: external I2S master clock PCM_MCLK)をご紹介します。このスレッドの最初の方の書き込まれたメッセージにあるリンク先も参考になります。HIFIDUINOというサイトの記事Raspberry Pi B+ Digital Audioです。rpiとbbbを比較した最後の結論の表がありますが、これを見ると一目瞭然。明らかにbbbが優れていると分ります。bbbの現状を考えると残念です。たかじんさんのサイトでも同じような記事(RaspberryPi vs Beagle Bone I2S信号について)がありますね。
この辺りは、rpi-2/3になって、ある程度解決したようですが、外部からのmclkクロックを受けられないという仕様には変更はありませんので、rpiの残された弱みですね。

本題に戻ります。 rpiにmclkを必要とするDACを繫ぐ場合、写真のようにGPIOピンからi2s信号を取り出せて、マスターモードで動き、mclk信号を取り出せる基板が必要です。



上の写真はhifi-dac-hatのmclk信号を取り出している部分です。ご覧のように、基板のmclk信号を出している部分へのハンダ付けが必要となります。詳細は僕の掲示板でやり取りしていますので、そちらを参照してください。拙宅だからこのハンダ付けをしてもらったkomaさんから提供された拡大写真もお見せしましょう。



ハンダ付けなんて出来ないよという方はこの基板を使うという方法もあるようです。僕は使ったことがないので、有効なのかどうかよく分かりません。ご参考まで。

hifi-dac-hatを使った場合はドライバ用の設定は

dtoverlay=allo-boss-dac-pcm512x-audio

とする必要があります。
また、AitDACと接続する場合はmpd.confで32ビット固定にしないと上手くいきませんでした。

audio_output_format			"*:32:*"

ところで、このやり方でSMPDとAitDACを接続した肝心の音ですが、BBBを使った方法と比較すると劣ります。クリアさが明らかに不足するのですよね。まあ、BBBを使った方法ではクロックにNEUTRONを使っているということもありますが、理由はよく分かりません。不思議です。

面白いのは、キツネDACの場合は、mclkは不要ですが、間にhifi-dac-hatを入れ、HDMI接続した方が明らかに音は良いです。ヴェールを一枚剥いだというレベルで、音場の広さや音のクリアさが優れます。この辺も不思議です。この場合もクロックをrpiでなく、hifi-dac-hatのクロックを使うマスターモードで動かしているという理由はありそうです。
キツネDACのUSB入力はかなり優れた性能で、音も良いのですが、やはりHDMI接続には負けますね。特にこのhifi-dac-hatを入れた音は素晴らしいです。格が違うというレベルで差があります。このDACはrpiからHDMI接続して繫ぐ一手です。rpiを中に入れて、直付けしたらもっと良いだろうなぁと思っているのですが、ちょっとリスクが多いので、実現出来ないのは残念です。

それでは二番目の「rpi-dacでも駄目なことはある」に移ります。
「rpi-dacでも駄目」の原因の大半は一番目の互換の茨、二番目の接続の茨です。互換性のとれないボードを使ったとか、接続が間違えたという類ですね。しかし、稀には摩訶不思議なこともおきます。
ここにその例のスレッドがありますので、ご覧ください。
投稿順に並べてご覧頂くと分かりやすいですが、キツネDACでどうやってもrpi-dacを使えないので、悩んでいた時のことです。SMPDフォーラムにたまたま「InnoMaker HiFi DAC HATがAmazonで買える様です」という投稿があったので、溺れる猿は藁をも掴む。便乗質問しました。結局、SMPDでパパリウスさんが作り込んだdsctrサービス(GPIOのdrive strengthを設定)の問題と分かりました。取り敢えず設定値を適当に変更し、問題はクリアしました。
まあ、例外的なトラブルだとは思いますが、ご参考まで。


さて、ここまでで、「I2Sの世界第二幕」で説明しようと考えていた内容は全て書きました。しかし、最後に得意の卓袱台返し(^^;;;。
連載中にPassさんにSB32+PROをヘッダーピンを取り出せるように改造してもらいました。さらに、今回の最初に書きましたが、IANのrpiのヘッダーピンに直付けするタイプのHDMI変換基板をgetしました。この二つを組み合わせた音が凄いのです。HIFI DAC HATボードと GLA I2S-TX-C1変換基板による組み合わせの音と比較すると、ヴェールを一枚剥がした位の音の差があります。勿論、SB32+PROとIANのHDMI変換基板の方が良いのですが、入り口のちょっとした違いでこれほどの差が生じるとは思いませんでした。



前回の書き込みで、冒頭のPhile-webのhirofukuyaさんの記事に関連して、中間部分でi2s信号はノイズに弱いわけではないと書き込みました。これに関して、Passさんから、i2s信号はmclkの周期でデジタルな値として取り出されるのだから、瞬間的なノイズだけでは、そのノイズがデジタルの値に大きく影響したとしても、一つのmclkのデジタル値が変わるだけであり、そのまま音質の悪化には繋がらない筈だという反論を頂戴しました。その通りだと思います。
その反論の中で、「DACチップは演算素子ではなく、積算機だと思っていただくと分かりやすいかもです。入力されてきた電圧を各Bitごとに重みづけされた抵抗に流して、電流値を積算して出力します。なので入力されてくる電圧が変動すると出力も変動します。」という指摘があり、「なるほどなぁ」と思いました。

上記したような、HDMI変換基板という入り口の部分を変えただけで、音が変わるといのはこの「電圧の変動が出力(電流」)に影響を与えている」としか思えません。また、rpiが電圧変動に強い電源を使うと音質改善出来るという事実もこの説明を裏付けます。まあ、お猿としては、この辺りをもう少しちゃんと説明出来るようになったら、第三幕を開幕して、説明したいと思います。
以上で「I2Sの世界第二幕」は終幕です。

(PC_Audio)   2019/11/23

コメントする

I2Sの世界第二幕(3)


接続の茨の話に入る前に少し脱線します。Phile-webのhirofukuyaさんの記事です。

この二つの記事はrpiでi2s信号の受け渡しを行う時の問題点を明快に論じたもので、大変に興味深いです。信号の処理で電源にノイズがのったりすると簡単にビットエラーが発生し、音質の悪化に繋がるという指摘が分かりやすく解説されています。
rpiを使った音楽再生で電源の重要性はあっちこっちで議論されています。
高音質化に注力したSMPDのサイトでは、当然、この話題が一番人気になっています。
ラズパイ用の電源というスレッドが出来ていまして、DC-ARROW、その改造、スイッチング電源、リニア電源、バッテリーなど話題は多岐にわたるのですが、議論沸騰しています。会員制のフォーラムですが、問題の無いスレッドは公開されていますので、興味のある方はどうぞ。

そのスレッドで活発に発言されているジャイアンさんのサイトも必読です。馬力のあるスイッチング電源を使い、コモンモードチョークコイルと三端子レギュレータを使ってローノイズ化を図る。さらに、その先のパワートランジスタを適切に選び、二段の構成にする。この構成、仮にジャイアン=Pass方式と呼びますが、凄い威力ですよ。僕はPassさんに製作してもらったものを使っているのですが、rpiに関しては素晴らしい音質に変わります。この方式は音楽専用に使っているPC(SoC)には効果があるようで(Windowsですが、HQPlayerが動くラッテパンダでも効果的でした)、お勧めです。
こちらは回路図付きで詳細な解説をされていますので必読です。
また、こちらは最初の実験段階での記事ですが、同じく必読です。このシリーズ全体の記事が興味深いですね。

本題に戻ります。
接続の茨は、rpiのGPIOピンとHDMI変換基板をどう繫ぐかという関門です。以前は、rpiのGPIO接続に関する情報が少なく、難関な関門だったのですが、今では一般化し、情報だらけですね。大した苦労もなく、正解に辿り着けます。 しかし、折角の茨の道です。そう簡単に正解に辿り着いては面白く有りません。i2a信号とは何かというところから、とりあえず脱線状態を継続しながら、説明を始めます。


この連載、シリーズ三回目になりますが、過去、i2s信号そのものの説明をしたことがありません。
何故か。
著者が良く分かっていなかったからです(^^;;;。
「お前、全く知らないことについて、延々と10回以上記事を書いてきたのか」と怒られそうですが、本当にそうなのだから、仕方がないです。こういうのを開き直りというのです(^^;;;。某国某政党某幹事長の得意技です(^^;;;(^^;;;。

という訳で、苦しい時のwikipediaだのみ。日米両方のサイトをチェックしてみました(日本アメリカ)。

はっきり書くと、日本語サイトはgood、英語サイトはexcellentという出来栄えです。という訳でここから先は英語サイトの情報をメインに解説します。和名は日本語サイトを参考にしました。 英語サイトの冒頭の部分を思いっきり意訳してみます。

I2S(eye-squared-ess アイスクエアドエスと発音します)は、デジタルオーディオデバイスを接続するための並列の信号線が3本ある電気的シリアルバスインターフェイス規格です。電子機器のIC間でPCMデータを通信するために使用されます。I2Sバスはクロック信号とシリアルデータ信号を分離して取り扱います。その結果、USBなどのシリアルデータからクロックを回復する必要がある非同期通信システムより、より簡単な方法でデジタルデータを送受信することができます。I2Sは、I2S(アイスクエアドエスと呼ぶ)またはIIS(アイツーエスと呼ぶ)と綴られます。同じような名前であるが、I2S向I2C(アイアイシー)バスとは無関係です。

この説明はi2s通信とUSB通信の違いを明快に分からせるという目的で意訳しました。原文には「並列の信号線が3本ある」とか「USBなどのシリアルデータから」とかいう記述はありません。但し、それ以外の部分はほぼ原文のままですので、間違ってはいないと思います。

この並列3本の信号線を使ったデータの送り方ですが、オン・オフだけののデジタルデータです。英語版から図を頂戴しますが、こんな感じです。



ここにも、例によってi2sの茨の刺が存在します。呼び名の茨です。信号線の呼称がバラバラなのです。
図の各信号線の状態を示す横の線に対し、左端の上段がwikipediaでの呼称、下段が僕がこれまで使ってきた呼称です。
順番に説明します。以下の説明は英語wikipediaの解説をベースにしています。合わせて、 Raspberry Pi とVolumioで最先端オーディオを楽しむ その2 メイン・パーツはI2S-DACボードの説明を参考にしています。

BCLK(Bit Clock) = SCK(Serial Clock)
信号のオンオフで一ビット分のデータ(DATA)の時間を示すクロック。LRCKに同期してn倍の周波数が使われる。
LRCLK(LeftRight Clock) = WS(Word Select)
信号のオンオフでステレオ右左2チャンネル分の時間を示すクロック。一番低い周波数が使われる。サンプリング周波数と同じ周期になる。CDの場合は44.1kHzで分割されることになる。
音声信号のLチャネルとRチャネルを区別する目的で使われる。WDCLK(Word Clock - ワードクロック)と記述されることもある。
DATA = SD(Serial Data)
信号をシリアルデータと処理し、信号のオンオフでその信号位置のビットがオンかオフかを示す。
PCMデータ(デジタル化された音声データのビット列)本体のデータ信号。この値が数値として変換されて、DAコンバータで使われる。


つまり、BCLKを使って信号1ビットの値を決まり、LRCLKを使ってビットを集めた一単位分のデータの数値を決まるということになります。
上記の図でもその辺りは分かりますが、直前のリンク先の記事にも大変に興味深い写真が掲載されています。オッシロで撮ったMCLKを含む画面です。これは上記に説明したことをそのまま目で見ることが出来るという感じですので、是非ご覧になって下さい。


ところで、図のSerial Data部分でLSB/MSBという技術用語が使われていますが、これを理解するには、エンディアンというガリバー旅行記に出てくる言葉を知っている必要があり(もちろん冗談ですよ)、

ビッグエンディアンとリトルエンディアンという語は、ジョナサン・スウィフトの風刺小説『ガリヴァー旅行記』の中のエピソードに由来する。ガリバー旅行記の第1部「小人国」では、ゆで卵を丸い方(大きい方)の端 (big end) から割る人々(英: Big Endians)と尖った方(小さい方)の端 (little end) から割る人々 (Little Endians) との対立が描かれている。

簡単に説明することは困難です。リンク先を参照して下さい。
要するにコンピュータ歴でいうと太古の古代以前の世界、アンモナイトとかシーラカンスの時代に発生した宗派対立が現代までメンメンと続いているということです。
エンディアンについてもその歴史を辿る書き物ですね。

ところで、冒頭に「信号の処理で電源にノイズがのったりすると簡単にビットエラーが発生し、音質の悪化に繋がる」という記事を紹介しましたが、これはi2s方式がUSB転送よりノイズに弱いということを意味しているわけではありません。
むしろ、逆です。USB、spdifといったシリアル伝送に対してi2sは4つの信号線が独立したパラレルな転送方式なのでノイズには強いです。USB方式はノイズに弱いことは最初から意識されていて、誤り訂正方法を伝送方式毎に規格化しカバーしています。コンピュータとのデータ転送はいくらでもリトライ出来ますからこれで十分です。問題はこれをオーディオに使うと、オーディオ再生ではリトライが出来ないので、大量のデータロスが発生する可能性があることです。
この辺りDACの設計次第ということはありますが、「USBでもi2sなみの精度で使える」というようなキャッチフレーズを見かけますが、これは奇怪しいと思います。

これでi2s信号の説明はお終いです。と書くと真面目な読者から「MCLKはどうしたのだ」と突っ込まれそうなのですが、MCLKはi2s規格には無い信号です。ここら辺もi2sが茨の道たる所以ですね。規格に無い信号が普通に使われていて、誰も論じることが無いという意味で。いい加減が当然の世界なのですね。
MCLKについては次回に説明します。

さて、ようやく本論に入ります。ところが、これもいつもの手口ですが、あっと言う間に終わるのですよね(^^;;;。

まずrpi側をどうすればいいかを紹介します。



上図がその正解です。Dimdim’s BlogのThe Raspberry Pi: Audio out through I2Sという記事に掲載されている写真です。
この記事もrpiを使ってHDMI-i2s接続する方は必読のドキュメントです。作成されたのは2014年の12月です。rpi-2b+が登場した直後だったのでしょう。BuffaloのDACとの接続の説明になっています。当時、HDMI-i2s接続出来る数少ないハードだったと思います。しかし、5年前の記事がまだ有効ということは、rpiもi2s接続もその後大きな変化は無かったということですかね。


実際に僕のrpi-3bの接続状況をお目にかけましょう。



写真に写っている基板はrpi-3bではなく、inno社のHIFI DAC HATです。直接、繫ぐことも可能ですが、故あってこういう繋ぎ方をしています。どういう故かについては次回ご紹介します。
このボードはGPIOピンに直接差し込む方式なので、ピンの並びはrpiと全く同じです。画面一番右の白い□がプリントされ三角印で示されているピンが一番ピンとなります。従って、以下の通り接続されています。

2番(黒) 5V
6番(白) GND
12番(黄) BCLK
35番(緑) LRCK
39番(青) GND
40番(赤) DATA

2番と6番のピンはHDMI変換基板に5Vの電源を供給するためのものです。
その他のピンはDimdim’s Blogの写真にある通りでGNDを含め4本のピンで接続するということになります。ケーブルはHDMI変換基板に添付されていたものをそのまま使っています。多少長めですが、この位なら許容範囲内ということです。
いずれにしてもケーブルの長さには制限がありますので(10センチ程度)、変換基板とrpiをあまり離すことはできません。
i2s信号についてはこのほかにMCLKというクロック信号がありますが、これはキツネDACと繫ぐ場合は使われません。DAC側のクロックが使われるからです。

次にHDMI変換基板側の接続ですが、これは基板次第で様々です。通常は基板のピン側に表示があるはずです。僕の使っているGLA I2S-TX-C1に関する写真をご覧いただきましょう。



rpi側での各ピンケーブルが対応するHDMI変換基板にピンに刺さっていることがお分かりかと思います。
これで、接続の茨の道はクリアしました。要するに必要な情報はありますので、間違えないように繫ぐということになります。

以上で本論の説明の終わりです。簡単だったでしょ。

(PC_Audio)   2019/11/17

コメントする

I2Sの世界第二幕(2)


前回、キツネDACの入力側の写真を撮ったのにご紹介するのを忘れていました。



最近の中国製DACはだいたいこういう感じで、USB3.0、AES、SPDIF(同軸)、OPT(光)、HDMIと全ての入力が可能となっています。このHDMIジャックにrpiからの出力を直接繫ぐわけです。

さて、前回はMatrix X-spdif2のマニュアルからHDMI i2s接続インターフェースに関する図をご紹介しました。ネットを検索して見つけたこの他のHDMI i2s接続インターフェース情報をご紹介しましょう。

これが大変なのですね。魑魅魍魎の世界です。

この魑魅魍魎度合い知る方法。「i2s pinout hdmi」でググって下さい。検索結果からi2s-HDMI接続のイメージの一覧をクリック。「i2s pinout hdmi」というキーワードに関連する様々なイメージを表示することができます。これが興味深いです。

参考になるので、幾つかをご覧いただきましょう。



Gustard X20、このページに残っています。 もう一つの設定の図があるはずですが、捜したが見つかりませんでした。中国勢の筆頭、米国の標準には素直には従わないと頑張っているようです(^^;;;。




TOPPING D-70、TOPPINGサイトから。
中国勢ですが、PS_AUDIO方式にも合わせますよというスタンスです。何でも繫いであげるということですね。
この図でHDMI端子とピン番号の対応が分かるので掲載しました。




これはrpiではなく、BBBのGPIOのピン配置図。HIFIDUINFO(BEAGLEBONE BLACK for AUDIO)に情報があります。
まだ情報は残っていました。良かったですね。




現時点で標準に近いPS_AUDIO方式のフォーマットを図示したものです。
SBC I2S Outputからの引用です。

きりがないので、この位にしますが、ご参考になりましたでしょうか。i2s-HDMI接続の魑魅魍魎度合いがお分かり頂けたかとと思います。
最後の図は The Art of Sound というレビューサイトの投稿。一年位前のものですが、SBC(Single Board Computer 要するにSoCのことです)を使い、i2s接続し、直接音源に繫ぐメリットと方法を分かりやすく解説したもので、大変に良く説明されていると思います。ご一読をお勧めします。

あと、注意しないといけないのは、HDMI-i2s変換基板を選ぶ時にDACの規格に合ったものを選ぶ必要があるということです。当たり前ですが、PS_AUDIOならPS_AUDIO、GustardならGustardで、同じ規格に合わせる必要があります。HDMI-i2s変換基板もこれに合わせて、基板を変えて対応しています。下図は僕の使っているGLA I2S-TX-C1の場合です。



このようにPS_AUDIO方式ならC1を、Gustard方式ならC2を選ぶ必要があります。

さて、「互換の茨」の説明の最後に魑魅魍魎の度合いが一番分かりやすい表をご覧いただきましょう。sonore社が i2s-HDMI関連のインターフェース情報をまとめたエクセル表(i2sというタイトル)です。
リンク先のエクセル表の「HDMI I2S FORMAT」というタブをクリックしてみて下さい。



このように非常に横長なエクセル表が表示されます。上図は全体の半分以下です。列がメーカー&機種、行がピン番号となります。つまり、それぞれの機種がどのピンをどの信号に割り当てているかが一覧できます。
まだ右に20機種以上隠れています。カラムのAからANまで。使っていない列もありますが、39機種のフォーマットを一覧にした表となります。まあよく調べたものだと感心します。
調査した時期が書かれていないのですが、登場する機種からみて比較的最近(といっても2年位前)と推定できます。

さて、この表から魑魅魍魎度合いを分析してみます。

まったく同じという列はほとんどありません。まだ規格が統一されていないことを意味します。だいたい同じというものはCOMMENTSという最終行で基本的にどの規格に属するかが注記されています。この基本的な規格の種類の数だけで、PS Audio Spec、W4S Spec、Hifime Spec、Rockna Spec、SMSL Spec、LKS Spec、Gustard Spec1、Gustard Spec2、JAVS Spec、Singxer Specと10種類あります。Gustardに至っては一つのメーカーで二つの規格を持っています。どういうつもりなのですかね。中国製のDACも大所はテンデンバラバラですね。
というわけで、この表を見ると、絶望的な気分になります。

救いはPS Audio Specのものが過半数近くあること。また、and otherSpecs also avaialbleとあるものが結構ありますので、このあたりを選べば何とかなりそうです。
また、表を丁寧にみると、一部の全く特殊な方式のものを除けば、結局、前回のA/B definitionの二つのタイプに大枠では分類出来ることが分かります。

大雑把にいうと、A definition = Gustardなど中国製DAC、B definition = PS Audio アメリカ製となりますので、「ここでも熾烈な米中貿易戦争なのだ」ということになるのですかね(^^;;;。そんなはず無いか。
何れにしても、A definition と B definition の差は前回のX-spdif2のマニュアルの図で示したようにDATAとLRCKのプラスマイナスの位置がひっくり返しになっているだけです。従って、前回ご紹介した Breakout Terminals Solderless Connectorを使えば、簡単に対応可能です。どういう接続になっているか確認し、LANケーブルとネジ回しを使えば、音は出ます。
というわけで、魑魅魍魎の世界ではありますが、めでたく互換性の茨はクリアしました。
次の接続の茨に進みます。長くなったので、次回に。

(PC_Audio)   2019/11/02

コメントする

  

I2Sの世界第二幕(1)


i2s接続については、5年以上前にこのサイトの掲示板で「RasPiからのI2S直接入力」「BBBのI2S interface」という二つのスレッドが立ち上がりました。PCオーディオの世界で、i2sに関して論議された初めてのケースではないかと思います。
当時、この掲示板でのやりとりをまとめ、4回の「I2S接続」という記事を公開しました。PCを使ったi2s再生に関して書かれた最初期の記事だったと思います。



写真はこの記事の一回目に掲載したIrBerryDACの写真です。
たかじんさん設計のこの基板はraspberry pi B+(2の付かない無印の古い版)対応のもので、コンデンサーや抵抗は自分でハンダ付けして作成しました。当時は、今のようなGPIOピンの部分で接続すれば、そのまま繋がり、使えるような基板は存在していませんでした。僕はこの基板で初めて基板のハンダ付けを経験しましたが、上手くいかず、たかじんさんにメールして、助けてもらって、何かとか動かしたという記憶があります。
今や、ハンダ付けしないと使えないような基板はほとんど有りません。良い時代になったものです。

i2sという規格は、CDプレーヤの内部でトランスポート部分とDAC部分のインターフェースとして普通に使われている規格ですが、市販のオーディオ機器でi2s接続している部分が外に見えるということはありませんでした。

PCオーディオでi2sという規格が注目されたのは、rpi(raspberry pi)やbbb(beagle bone black)がGPIOという仕組みを使えるようにして、そのインターフェースを公開したからです。このGPIOに、i2sで使う信号(DATA、BCLK、LRCLK、MCLK)を割り当て、パソコン(SoCと呼んだ方が適切ですかね)からGPIO出力することで、パソコンによるオーディオ機器への直接のi2s接続が可能となったわけです。
さっきから、GPIOという用語を乱発していますが、いちいち説明しているときりがないので、リンク先を参照して下さい。

冒頭の写真のようなGPIO直結型のi2s DAC基板は、簡単にi2s接続が出来て、音が素晴らしいことから、rpi用のものを中心にだんだん数が増えてきました。VolumioやMoodeといったrpiではメイジャな音楽ソフトがi2s接続基板をサポートするようになり、普及は進みました。
GPIO直結のi2s DAC基板は初期にはbbb用のものもあったのですが、マイナーなbbbにはサボートする使いやすい音楽ソフトが有りませんでした。また、ドライバもboticだけで、なかなか最新のlinuxバージョンに追いつかないという状態が続きました。この結果、bbbは、今や、完全にマイナーな存在となってしまったのは残念です。

三年位前に「I2Sの世界」というタイトルで7回の連載記事をアップしたことがあります。その第一回目の記事で当時のハードの状況を書いています。
冒頭部分を引用してみましょう。

UPnPとI2SがPC/ネットワークオーディオの世界で良い音を出すための最新のキーワードだと思っています。
UPnPは Volumio vs JPLAY/lightMPD連合軍というソフトウェアの世界ですが、I2Sは RaspberryPI vs BeagleBone BlackというSoCの世界です。どちらもグローバルで鈍感なガリバーに対して零細だけどgenuineな小人が真実の音を求めて戦いを挑むという構図なのはいっしょです(^^;;;。


そして、それから3年。UPnPはすっかり当たり前になりましたが、I2Sはさっぱり。
その次の行。グローバルで鈍感なガリバー(Volumio、rpi)はますます栄え、genuineな小人(lighuMPD、SMPD、bbb)はひたすら純度をあげるという感じになっていますね。JPLAYについてはコメントしないのが賢明でしょう(^^;;;)。

当時、rpiのGPIOに直付けするi2sインターフェース基板が普及し始めたころだったと思います。一回目の記事のなかでいくつかを紹介しています。
この数と種類はこの3年で大幅に増えました。先に書いたようにrpi用のものばかりです。Volumio、Moodeといったイジャーで、使いやすい音楽ソフトが積極的にサポートしたからというのが大きい理由でしょう。

当時とあまり変わっていないのは、DACへのHDMI接続のi2sインターフェースの搭載です。日本製DACのメーカー製品でi2sインターフェースを持っているものは、現時点では、ゼロだと思います。

HDMI接続のi2sインターフェースを持つDACが増えない理由はサボートするソフトがVolumio、Moodeといったrpi専用の音楽ソフトだけだからだと思います。先程、Volumio、Moodeを「メイジャーで使いやすい」と書きましたが、そう考えるのは音楽再生はLinuxでやるのが当たり前という一部の偏った変人だけで、PCオーディオの世界といえども、Windows派が大部分で、Linuxはマイナーです。従って、メイジャーな世界しか相手にしない日本のオーディオメーカーはそんな変人を相手にすることはありません。

i2s接続するなら、DAC基板をベースに自作するか、ベンチャー系列の製品かという構図は5年前から変わっていません。ただ、海外製品(特に中国製の製品)にはHDMI接続でi2s接続が出来るようにしているものがいくつか登場しています。例えば、Gustard、Matrix、TOPPING、L.K.S AudioなどのDACは、高級機(といっても値段はそれほど法外ではありませんが)であれば、全てHDMI接続可能なようです。

さて、今回のI2Sの世界第二幕は、このi2sインターフェースの搭載のDACがもっと普及すればいいなと考え、書いています。
理由は、RPIを使って、ダイレクトにDACのi2sインターフェースに接続する構成の音が素晴らしいからです。
直前の文でわざわざ「RPIを使って、」というフレーズを入れたのは意味があります。その意味とは、現在、これらのDACのi2sインターフェースはHDMI出力機能をもつ高級なDDCを使うために設計されていて、RPIなどのSOCを使って、接続されることを想定していないことです。



写真はAPU1d(lightMPD upnpgw)+APU2c4d(lightMPD 1.20)をMatrix X-spdif2に接続し、キツネDACをHDMI i2s で繫いでいる写真です。積み重ねている機器の一番上がMatrix X-spdif2、真ん中がバックエンドのAPU2c4d、一番下がフロントのAPU1dとなります。このように真ん中にあるバックエンドのAPU2c4dからはUSBで信号が出力され、一番上のDDC側(Matrix X-spdif2)でUSB信号をi2sインターフェースに変え、HDMIケーブルを使い、キツネDAC側に送り出すということになります。

APU(lightMPD) --USB2.0--> Matrix X-spdif2 --i2s--> HDMIインターフェース --> Holo Spring (キツネ)DAC

という具合ですね。

これに対して、rpiに直結した場合の写真をお目にかけます。



ご覧のようにrpiにinno社のHIFI DAC HATボードをGPIO直結し、上部に突き出ているGPIOピンを使い、HDMI変換基板にショートピンで接続します。HDMI変換基板のHDMI端子とキツネDACのHDMI端子をケーブルで繫ぎます。

残念ながらこの直結方式はまだPCオーディオの世界でも市民権を獲得していません。

実は写真構成で、SMPDを使いキツネDACと繫いだ時、DSD再生が出来ないというトラブルが残っています。詳細はここにあります。
この時、どうしても原因が分からず、日本の代理店のサポートにメールしたのですが、こちらの接続形態を理解してもらうまでに数回のメールのやりとりが必要でした。
常識的なDDCを使ったHDMI接続しか知らないサポートの方には、パソコンから、直接、HDMI接続でDACに接続出来るという知識が無いのですね。おそらく想像を絶する世界だったのでしょう。いくら丁寧に説明しても、理解して頂けませんでした。「もう、面倒だ。直接メーカーと連絡させてくれ」とお願いしたところ、やっと理解してもらいました。

というわけで、得意の超マイナー路線。このパソコンとDACを、HDMI基板を使い、直接HDMI信号のやりとりをする方法を何回かに分けて解説します。

当然、利用するソフトはSMPDとなります。VolumioとかMoodeといったメイジャ(rpiの世界の中での話ですよ。世の中全体では、マイナーかもしれません)なソフトは相手にしません。
折角、良い音を出すためにベストの方法を探ろうとしているのに、わざわざ音の悪くなるソフトを選択するというチョイスはあり得ませんので。

さて、ご説明したように、パソコンを使ったHDMI-i2s接続はPCオーディオのサポートの専門家でさえ知らない内容なので、当然、茨の道が待ち受けています。

どんな茨の道なのか確認しましょう。

①互換性の茨
SOC+HDMI変換基板側とDAC側でHDMIインターフェースの方式を合わせる必要があります。非互換だらけの迷路の世界に迷い込むことになります。
②接続の茨
SOCとHDMI変換基板を接続する必要があります。簡単なのはお使いのSOCに合わせてGPIO直結できるタイプの変換基板を使うことです。これなら差し込むだけすみます。
駄目なら、短いケーブルを使って、接続するわけですが、意味不明なrpiのGPIO仕様を解読する必要があります。
③ドライバの茨
GPIOピンの位置が分かったから、HDMI基板とその通り接続しても、繋がるという訳ではありません。大部分のDACはrpiからのi2s信号をそのままでは受けられません。DACにあった適切なボードを選択し、対応するドライバを選択する必要があります。

では最初の茨の道から。

第一の茨はこのHDMIインターフェース部分がまだ完全に標準化されていないことです。その例をお目にかけましょう。最初にご覧いただいたDDCのMatrix X-spdif2のマニュアルから。



Matrix X-spdif2とキツネDACがi2sのHDMIインターフェースで接続されます。インターフェースはHDMI-PS-AUDIO方式と呼ばれるものです。これは上の図で B definitionと呼ばれる形でHDMIケーブルの信号線を使っています。
A definitionはGustard社が採用する方式ですが、違いは上手に説明がある通り、赤い部分のプラスマイナスが逆になっているだけです。これについては謎だらけです。詳細は後述します。
Matrix X-spdif2は裏にあるディプスイッチでこの方式が切り換えられるようになっていて、自社(Matrix)のDACと繫ぐ場合は B definitionで接続するようになっています。何故、上図が標準のHDMI-PS-AUDIO方式を最初に出てくるA(定義)にしないで、Bにしているのかこれも謎です。
こういう具合にHDMI接続の世界は謎の大陸です。この程度は当たり前でこれにメゲテいては先に進めません。



Matrix X-spdif2ではこのA/B(定義)の切替を機器の裏面にあるディプスイッチで行えるようになっています。上図の真ん中のスイッチです。

現時点ではHDMI-PS-AUDIO方式をとるDACが多く、Gustardなどの中国製DACの一部が上記のA definitionをとっているようです。PS Audioが提唱するHDMI-PS-AUDIO方式についてはここ(I2S standards from PS Audio)で情報発信され、議論されているようです。

また、古の古代(もちろんデジタル歴の話ですよ。西暦では2~3年前)には、JAVS社のHDMI-JAVS-LINKという規格があったようで、ここ(JAVS UDT-1 と DAC-2 と HDMI-Audio)に情報があります。

さて、Matrix X-spdif2ではディプスイッチで切り換えているのですが、この切替が出来ないハードを使う場合、問題となります。当然、rpiを使う場合も同じように問題となります。世の中、同じようなことに悩むマニアが多いと見えて、これに対応するガジェットがあります。



Breakout Terminals Solderless Connectorという名前で、こういう製品です。AliExpressなどで購入することができます。
この製品、名前の通りの製品で、パックリあいて、ハンダ付け無しで使えるHDMIコネクターです。
蓋を空けるとこういう具合になっています。



名前の通り、写真のようにネジで細かいケーブルを自由につなぐことが出来ます。従って、規格がどうなっていようが対応出来るという、便利な製品です。ハンダ付けは苦手というお猿(^^;;;には必須のアイテムですね。
これは強力で例えば先程definition Aの受け側とBの送り側での変換なども内容もネジ回し一つ出来ます。

唐突ですが、長くなったので、以降は次回。

(PC_Audio)   2019/10/28

コメントする

Symphonic MPD讃(5)


Symphonic MPDのフォーラムをご紹介します。

前回、ご紹介したようにこのフォーラムは会員制です。しかし、ソースコードの非公開に伴い外部に見せることができないコンテンツ(例えばシステムイメージのダウンロード)以外は会員以外の人も閲覧することが出来るようにしています。
この外部から閲覧している方が結構多いのですね。会員が見られるトップページのユーザ機能を使うと誰がアクセスしているか、チェックすることが出来ます。



チャット機能があるので、そのために誰がオンラインがチェック出来るようになっているらしいのですが、ご覧のようにゲストが何人オンライン中か分かります。
これはある平日の7時台の状況です。時間帯を考えると結構賑わっていますね。まあブラウザのタブ機能を使っている方が大部分で、この全てが実際に閲覧中という訳では無いと思いますが、それでも、20人がこの時間にオンラインで、そのうち14人がゲストというのが凄いですね。会員数の倍以上の数の一般の方がアクセス中ということになります。


以前、Phile-webのコミュニティで活動していた頃、このサイトは主にSMPDの新版をダウンロードするために使われていました。今回、このフォーラムに機能にSMPD R&Dクラブの活動を移したので、以前このサイトに存在した全て機能をフォーラム機能に移行させています。
このフォーラム機能は強力なので、そういうことが出来るわけですね。

さて、この強力なフォーラム機能をご紹介しようと思いますが、その前にパパリウスさんに質問しました。



ということです。

Debian + Node.js + nginx + MongoDB という構成で動いているようですね。掲示板用のソフトはNodeBBという名前です。大変素晴らしいソフトだと思いますが、日本語の情報がほとんどなくて、前文のリンク先以外は「Bluemix と NodeBB を利用して最新のフォーラムをデプロイするというIBMが公開している技術文書位ですね。

Node.js というのは何かというと、サーバサイドのJavaScript環境です。こちらインタネットに十分な日本語情報がありますね。

JavaScriptはブラウザ上でプログラムを動かすために作られた言語ですが、この言語をブラウザとしてでは無く、サーバ側でも動くようにしたのがNode.jsです。
つまり、NodeBBというのは掲示板としてサーバで動くJavaScriptということになります。

こうやって、NodeBB が nginx(Webサーバ) + MongoDB(データベース)と組み合わされて動いているということですね。

という訳で、NodeBB そのものは環境さえ作成すれば、比較的簡単に運用できそうですね。まあ、Linuxお猿にはなかなか厳しい関門ではありますが(^^;;;。
ただ、先程書いたように日本語の情報が殆どないので、掲示板としての使い方の解説はありません。
そこで、8通ほど投稿して試してみた範囲で解明したNodeBB掲示板の使い方の解説です。以降は僕が使ってみて分かった内容の記述ですので、内容に責任は持てません。また、会員としてのアクセスですので、非会員の方がどうなるのかは保証できません。ということでご了解をよろしくお願いします。

会員登録の仕方

前回の書き込みを参照して下さい。

会員として登録できる方はSMPDの利用者のみとなります。i2sユーザという、一般のオーディオマニアから見れば、特殊なユーザのみ会員になれるということになります。

以下はパパリウスさんからの登録案内のメールです。

(1) 下記サイトにアクセスし、右上の「登録」ボタンからユーザ登録をお願いいたします。
https://mpd.sytes.net

(2) 事前連絡いただいたユーザ名・メールアドレスと一致していることが確認できましたら、配布ページへのアクセス権を付与いたします。

(3) 「symphonic-mpdへようこそ!」という件名の確認メールが届きます。確認メール本文にあるリンクをクリックいただくと、入会手続きは全て完了となります。



図1 見出し画面のアイコンの使い方

前回の記事でご紹介したように、会員と非会員でメニューを分けるなどというのはお茶の子のなのでしょうね。
ご参考までに非会員が閲覧出来ない「R&D Club」のメニューをご覧いただきましょう。

     見出し画面



こういう具合にスレッドで掲示したい内容を分けて掲載する方法により、フォーラム機能だけで、サイトの運営が出来るようになっているわけです。

画面左上、左から順番に「未読」、「最近」、「タグ」、「ユーザ」となります。

「未読」
未読のスレッド数が表示され、クリックすると未読スレッドの一覧が表示されます。
「最近」
クリックすると全てのスレッドが新しい順に一覧表示されます。
「タグ」
タグが使えるようですが、使い方がよく分かりません。
「ユーザ」
ユーザ一覧が表示されます(この記事の一番最初の画面もタブを選択すると、表示できます)。

右上、左から順番に「検索」、「通知」、「チャット」、「プロフィール」となります。

「検索」
サーチ機能だと思います。
「通知」
後述する、ウォッチ機能を指定したスレッドに投稿があった時、教えてくれるようです。
「チャット」
試したことは有りませんが、チャット出来るのですかね。
「プロフィール」
自分のプロフィールに設定した画面が表示されます。
僕の場合はフェースブックでも使っている20年位前の写真を使っています。詐欺だと訴えられそうですが(^^;;;。



図2 記事画面のアイコンの使い方

     記事画面



画面左下にある歯車のようなアイコンは重要です。これで自分が投稿した内容の修正、削除が出来ます。

また画面右下のメニューはスレッドの先頭のメッセージと最後のメッセージの後に表示されるようです。内容はタイトル通りですが、返信はこのメニューを使って行います。返信を新しいスレッドとして投稿することも出来ます(最初に何か新しい話題を書き込みたい時に使います)。
他のメニューの機能はメニューラベルにある通りですが、並べ替え機能があるのは便利ですね。新しい順、古い順のどちらでも表示させることが出来ます。

記事の書き方

上記の通り、返信ボタンを使って、記事を投稿します。新しいトピックであればスレッドとして返信すれば、新規スレッドを起こすことが出来ます。

     書き込み画面



このスクリプトの最大の特長はMarkdown書式が使えることですね。実は、僕のサイトの記事はこの書式で書いています。Markdownは通常のテキスト文の中にリンク、引用、画像の貼り付けなどのHTML書式を使わずに簡単に出来ることが特長です。
書き込み画面の上段にあるアイコンがこのMarkdown書式のために使われています。
左から、太字、イタリック、箇条書き、消し線、コードの引用、リンク、画像となります。実際にクリックして、Markdown書式でどういうコードになるか表示されています。その次のボタンが絵文字の引用となりますが、これは画面に表示されているよう豊富な絵文字から自在に選ぶことができて便利ですよ。
投稿するのは画面右上の>ボタンを押すだけです。とても簡単。
画面右上のボタンでキャンセルや縮小化も出来ますので、便利です。

NodeBBの書き込み用エディターの使い勝手は本当に素晴らしいです。掲示板のエディター機能でこれだけの操作性の持つものは無いと思います。史上最高最強の掲示板エディターでしょうね。


NodeBBの強力な機能に支えられて、SMPDの新サイトは順調に立ち上がっているようです。
いままでは機能面で制約の多いコメント欄での運用だったので、自由に出来なかったことが、自在になったことが大きいですね。電源、CDリッピングなどテーマ別にスレッドが立ち上げられ、活発な議論が展開しています。i2s接続のみ可能な音楽プレーヤを使うというマニアックな方々が集まったクラブだから、議論がどんどん深まります。素晴らしいです。

(PC_Audio)   2019/10/12

コメントする

Symphonic MPD讃(4)–入会案内


Symphonic MPDですが、Phile-webのコミュニティを利用してR&D Clubの活動を行っていましたが、最近、全てを自前のサイトで運用するように変更されました。こちらが新しいコミュニティのサイトです。



新しいコミュニティに移った経緯については、僕のサイトの掲示板にパパリウスさんがコメントされていますので、そちら参照して下さい。「Symphonic MPD Q&A用の緊急避難スレッド」「Symphonic MPD Q&A用の緊急避難スレッド」のスレッドにコメントがあります。

この新しいサイトにより、SMPD R&D Clubによる運用も本格的に展開される環境が整備されたのかなと思います。いままでは、Phile-webのコミュニティを間借りして、活発な議論が行われていたわけですが、コメント欄を利用するという形なので、機能面で制限がありました。
新サイトにより、この制限が無くなり、フォーラムの機能も圧倒的に拡大されました。10日間で200メッセージ位投稿されていますので、スムーズに立ち上がっているようですね。

また、会員制をとる原因となったGPL違反という指摘に関しては、独立したことにより、一般企業内の内部のLinuxシステムの利用と同じ形態となります。従って、指摘された問題点を完全にクリア出来るようになったと思います。企業内部でのみ利用されるLinuxシステムは、ソースコードが非公開であっても、GPL違反ということにはなりません。同じように会員制により、限定されたメンバのみが利用するSMPDシステムも、ソースコードを開示されていなくても、GPL違反にはならないだろうということです。

ということで、メデタシメデタシなのですが、パパリスウさんが、Phile-webを退会して、新サイトを立ち上げられたので、Phile-webにあった過去のブログとコメント情報が全て消えてしまいました。このため、何もSMPDについて知識のない方が、いきなり新しいサイトを見ると、会員制に移行した経緯の情報が無いので、面食らうかもしれません。

SMPDとは何かの説明は「Announcements symphonic-mpdからのお知らせ」の「symphonic-mpdの世界」あります。また、SMPDの開発のヒストリーについては「R&D ClubResearch and Development Clubへようこそ」の「リリースノート」に残されています。このページは新サイトのSMPD R&D Clubの会員だけしか見ることが出来ません。
非会員の方は上記のリリースノートのリンクをクリックすると、ログイン画面が表示され、メールアドレスとパスワードを要求する画面が表示されます。この先には進めません。リリースノートが非公開の理由については後で述べます。




ここでは、開発の歴史に関し、リリースノートの替わりになるネットワークでの情報をご紹介しましょう。
SMPDに関して、過去、いくつかのサイトで情報が公開されています。

symphonic-mpd 新生ディストリビューション
初期のSMPD V0.3について、たかじんさんのサイトに書かれた記事です。
コメント欄のボリュームがもの凄く(パパリウスさんも登場しています)、「確かにそうだったなぁ」と懐かしいですね。
「symphonic-mpd にOLED表示を付ける方法」という記事もあります。
symphonic-mpd関連記事をまとめてみました
SMPD公式サイト内のジャイアンさんのカテゴリ内にあるリンクページ。ジャイアンさんの過去の記事をご本人が整理されたリンクページです。リンク先は全て、ジャイアンさんのサイトの記事になります。
SMPDのバージョンを重ねながらの変遷を知ることが出来ます。Linuxのテクニカルな使い方の解説により、どう変わっていったか垣間見ることができます。
Symphonic MPD讃
これは僕のサイトの記事です。何で自分のサイトの記事を紹介するのだと言われそうですが、V0.2-V 0.3の登場時点からV0.8-V0.9の間の変遷を直接的に書いている記事が他に無かったので、リンクしました。V0.4のあと半年位の休止期間を置いて、再登場(2018年6月)。直後のV0.6でXenomaiを採用。V0.7-V0.8でXenomai使い方を徹底的に改良したということが分かります。XenomaiについてはSymphonic MPD讃3で解説しています。
PC Audio音質向上施策のまとめ
ゴンザエモンさんのSMPD関連のページのまとめたリンクページです。SMPD、ラズパイだけでなく、さまざまな環境のlinuxで動く音楽ソフトを対象とされていて、膨大なボリュームとなります。SMPについては0.8以降の最新版に関する内容です。
ケンのオーディオメモ(ラズパイのリンクページ)
ラズパイのリンクページですが、半分以上はSMPDに関する記事です。今年の7月から書かれていますので、全てV0.8最新版の内容です。すっきり纏められいるので、分かりやすくてお勧めです。


上記の記事やリリースノートを見れば、SMPがどのように開発されて来たかフォローできます。

さて、現会員にとって、SMPD R&D Club 設立の経緯は当たり前で、誰でも知っている(、だから会員になった)わけです。
しかし、新たにSMPDの存在を知り、SMPDのサイトをアクセスした方々から見ると、「何故、会員制をとっているのか。何故、自由にソフトをダウンロードし、感想を書き込むことが出来ないのだろうか。」と不思議に思われでしょう。

インタネットで、SMPDが会員制になったことについて書かれているのは、たかじんさんの「symphonic-mpd v0.8 以降はR&D Club限定に」という記事位ですかね。しかし、この記事でも会員制になった理由については「大人の事情がある」とだけしかコメントしてありません。具体的な理由は説明されていません。
大人の事情(GPL対応)とは現会員にとっては周知の事実で、いまさらだからということだと思いますが、新しくSMPDに興味を抱き、会員になろうとされる方々には、この大人の事情は知っておいた方が良い事柄だと思います。

というわけで、ここでは、この大人の事情について紹介します。著作権に関する法務マターなので、多少話がややこしくなりますが、会員になりたい方はお付き合いください。

まず、「GPLとは何か」というところから話をはじめる必要があります。

GPL(General Public License 一般公衆利用許諾契約書)というのは、Linuxにおいて一般的なソフトウェア利用のライセンスの一つです。GNUプロジェクトが作成したライセンスで、自由なソフトウェアの利用、解析、配布、改変を保証することを目的として開発されました。Linuxカーネルもこのライセンスに基づいています。
我々がLinuxを使う場合、当然カーネル込みで使っていますので、GPLを承諾し、使っています。承諾しなければ、使うことは出来ません。
これはマイクロソフトのWindowsを使うとき、Windowsのソフトウェア契約を承諾し、使っているのと同じことです。
ソフトウェアを初めて動かした時、ライセンス契約画面が表示されます。面倒な英文は読んでいないが、OKボタンは押さないと先に進めないので、内容を理解しているかどうかは別にして(^^;;;)、ボタンをクリックしているはずです。これでGPLを承諾したことになります。

LinuxがGPLを採用した理由は、マイクロソフトのWindowsの閉鎖的なライセンスでは、自由な開発が出来ないからです。
オープンにいろいろなグループがソフトウェア開発を行い、次々と開発を展開していくためには、誰でも中味の見えるシステムにする必要があります。このためには、ソースコードを開示して、ソフトウェア開発を行うことが必須となります。従って、GPLというライセンスで、ソースコードの開示を義務付けようというわけです。GPLをオープンなシステム開発の縛りにしています。

という訳で、GPLは、Linuxの世界でソフトウェアを公開する場合は、守るべき基本的なルールとなっています。例えば、誰でもLinuxカーネルのソースコードを見ることができます。また、それをベースに自分好みのシステムをカスタマイズすることが可能です。これをカーネルのビルドといって、Linuxにはお猿並の知識しかない僕でさえ、やったことがあります。
更に、自由な開発を維持させるため、GPLは、GPLが適用されたソフトウェアを使って開発された新しいソフトウェアもGPLライセンスを継続して適用することを要求しています。従って、Xenomai、ALSA、MPDなどのLinuxカーネルを利用し(ソースコードを改造して)、開発されたソフトウェアプログラムにもGPLが適用されます。この結果、カーネルだけでなく、これらの派生ソフトウェアを使い、改造したソフトウェアを公開する場合も、ソースコードを開示することが義務づけられます。
以上の仕組みでLinuxはWindowsとは全く逆の開放的な開発を可能とし、オープンなシステムを実現しているわけです。

このLinuxのオープンなシステムとそれを担保するGPLという仕組みは一般の企業からいうとやっかいなしろものです。彼らは自分たちのノウハウは秘密にして、公開する場合は特許なり、著作権なりを主張し、その仕組みを使って、ビジネスを行っているわけなので。
従って、ソースコードを公開しろという契約は、悪魔に魂を売り渡すようなもので、とても受け入れられないということになります。

もっとも、だからといって、「それなら、Windowsを使えばいいじゃん」とはいきません。

Windowsでの開発で、カーネルのソースコードを参照し、手を入れたいとしても、マイクロソフトが認めてくれません。つまり、悪魔は最初から「アンタの魂(カーネルの改造)には興味はないよ。俺の魂(カーネル)を見せてやるから、それに従え。俺の魂に従って開発する場合は、守秘義務契約を結んでもらうぞ。約束を破って、魂の中味(ソースコード)を外部に流出させたら、牢屋にぶち込むぞ」といってくるわけです。

つまり、Linuxの場合は、あちらが立てば(カーネルソースを改造できる)、こちらが立たず(オープンになってしまう=ノウハウを秘密にできない)。Windpwの場合は、こちら立てば(クローズドで開発できる=ノウハウを秘密にできる)、あちらが立たず(カーネルソースを改造できない)。となるわけです。
Linuxの開発コミュニティでも、そのあたりの事情は承知していて、Windowsに対抗するため、GPLで逃げ道を用意しています。逃げ道とは会員制なり企業内部での利用を意味します。この逃げ道について、SMPDが会員制公開となった経緯で説明します。

Linux を使いカーネルなどに手を入れ、ソースコードを公開して例は多々あります。例えば、今、話題のDirretaは自社のサイトでソースコードをダウンロード出来るようにしていますね。テレビやDVDレコーダなどLinuxを使う製品だと、製品のマニュアルにGPLが載っていて、メーカーのサイトでソースコードを開示しています。誰も読む人はいないでしょうが(^^;;;)。

これで前段の説明は終わりです。ここから、本題のSMPDが何故会員制をとることになったかの説明になります。

SMPDですが、Linux、ALSA、MPDなどのソースコードを参考とし、部分的に改造しているようです。改造することは、GPLに従うソフトウェアを使う時の当然許される権利ですから、何の問題もありません。しかし、この改造したソフトをシステムとしてネットで公開していました。この場合、ソースコードの公開の要求があった時、先に述べたように、GPLに従い、ソースコードを開示する義務があります。

今年の3月7日に、次のような問い合わせがブログのコメント欄にありました。

SYMPHONIC-MPD のソースコードはどこから入手できますか?

https://www.gnu.org/licenses/gpl-faq.ja.html#GPLRequireSourcePostedPublic

URLのリンク先はGNUによる「GNUライセンスに関してよく聞かれる質問」ページの「GPLは、改変された版のソースコードを公に発表することを要求しますか ? 」という問に対する答えの部分です。

GPLでは、あなたが改変した版をリリースすることは要求してはいません。改変を加えて、リリースせずに個人的に使うのはあなたの自由です。これは組織(企業を含む)でも同様で、ある組織は、改変した版を用意してそれを組織外にリリースすることなく内部的に利用することができます。

しかし、もしあなたが改変された版を何らかの形で公にするならば、GPLはあなたが改変したソースコードをユーザがGPLのもとで入手できるようにすることを要求します。

すなわち、GPLは改変されたプログラムを特定のやり方でリリースする許可を与えていますが、別の形でのリリースは許可していないのです。しかし、リリースするかどうかはあなた次第です。


これに対するパパリウスさんのご返事です。

symphonic-mpdは私が個人的に利用するために開発しておりましたが、Webページ上で不特定多数の方がダウンロードできるようにしておりましたので、個人利用・内部利用の範疇から逸脱した状態となっておりました。
ご指摘に感謝するとともに、Web上での公開を停止し、GPL違反を是正いたしましたのでここにご報告いたします。

今後は個人利用、および内部利用(知人・友人等)を徹底し、Linux/ALSA/mpd配布元の権利を侵害しないよう留意して参ります。
今後ともどうぞよろしくお願いいたします。

というものでした。もちろん要求があった人に何からの方法で開示すればいいわけですから、別の対応方法もあったかと思いますが、ソースコードを開示しないというパパリウスさんの強い意志により、会員制となったわけです。このやりとりは冷静沈着で適切な対応だったと思います。

もちろん、パパリウスさんはソース公開の原則の重要性はよく承知しているはずです。Linuxカーネルなどの公開がされていなければ、これらを改造して作成された改造SMPDは存在しなっかったわけですから。
ただ、ソースコードの公開というのは整理された形で行われれば、意味はありますが、開発中の雑然とした状態での開示はあまり意味がありません。また、中途半端な公開はオリジナルのソースの理解に誤解を与える可能性もあります。これらを考慮し、SMPDソースを現時点では公開しないのが妥当と判断されたということだと思います。

さて、GPLですが、1991年のv2と2007年のv3があります。v2とv3の違いについてはここ(日経XTECH)に紹介されています。v3が適用されるソフトウェアはまだ少なく、Linux、ALSA、MPDなどはv2のままです。先程のGNUのQ&Aもv3への言及はあります。このQ&Aは大変良く書かれていると思いますので、ご一読をお勧めします。

「会員制ならソースコードは非公開でかまわない」という判断はこのV2のライセンスに基づくものです。V2のライセンスですが、ここに和訳があります。
「まあ一応目を通しておくか」と考え、読んでみましたが、チンプンカンプン(^^;;;。「なるほど、これじゃ、件の投稿もこのリンクを引用するわけにはいかなかったのだろうな」と納得しました。



例えば、先程の「改造することは、GPLに従うソフトウェアを使う時の当然許される権利ですから、何の問題もありません。」という内容は6項で定義されています。

6. あなたが『プログラム』(または『プログラム』を基にした著作物全般)を 再頒布するたびに、その受領者は元々のライセンス許可者から、この契約書で 指定された条件と制約の下で『プログラム』を複製や頒布、あるいは改変する 許可を自動的に得るものとする。あなたは、受領者がここで認められた権利を 行使することに関してこれ以上他のいかなる制限も課すことができない。あな たには、第三者がこの契約書に従うことを強制する責任はない。

となります。いかがですか。いろいろな条件を考慮し、定義するから、どうしても文章は長く、複雑になります。すんなり、頭に入らなくなるのですよね。
もっとも、この内容だと組織の定義はそんなに厳密にする必要はないと思いました。「要するに外に出さなければ、OK」という解釈が可能なようです。
というわけで、上記のQ&Aが分かりやすいです。SMPDが会員制になった理由のポイントとなるのは、Q&Aの冒頭の部分です。引用します。

『GPLでは、あなたが改変した版をリリースすることは要求してはいません。改変を加えて、リリースせずに個人的に使うのはあなたの自由です。これは組織(企業を含む)でも同様で、ある組織は、改変した版を用意してそれを組織外にリリースすることなく内部的に利用することができます。』

このようにGPLは改造したら、なにがなんでもソースコードを開示しろといっているわけではありません。個人としての利用であれば開示は不要ですし、組織であっても内部で使っている分には開示する必要はありません。という訳でSMPDシステムの公開は会員制となりました。
最初の方に書いたリリースノートが非公開なのもこれが理由でしょうね。リリースノートとはシステムの改版履歴であり、内部でのみ必要な情報ですから。

こういう経緯で、SMPD R&D Clubは、取り敢えず、Philewebでのコミュニティをそのまま維持しながら、スタートしました。
今回、これが新しいフォーラムに移行する形になりました。これは正解でしょうね。
これで、R&D CLUBは完全に独立したわけですから、「組織内部での利用だ」ということを独自のフォーラムが担保してくれるわけですから。


さて、以上を理解し、承認しただけでは、R&D Clubの会員になることは出来ません。
非会員がSMPDのサイトをアクセスするとこんな画面が表示されます。



一番右に「ユーザ登録のお願い」という案内があるので、「なるほど、登録すればいいのね」と考え登録しようとクリックすると、「 R&D Clubの皆様へのご案内」というスレッドを表示することが出来ます。
しかしその内容は以下の通りです。



つまり、これはPhile-webで登録済の旧会員が、新フォーラムに登録するための案内なのですね。
新会員の登録は従来のルールが引き続き継続しているようです。以下、R&D Clubの会員規約からの引用です。

入会について
クラブ代表者と直接のつながりをもつメンバー(以下、プライムメンバー)は、友人・知人を当クラブに推薦することができます。
クラブ代表者はプライムメンバーからの推薦を吟味し、入会の可否を決定します。

2019/05/11追記
推薦の条件につきましては、プライムメンバーご自身の判断にお任せいたします。
ごく普通にコミュニケーションが取れ、文章を理解でき、想像力が働き、自分の行動に責任を取れる方であれば問題ありません。
推薦してもよいと判断されましたら、「ハンドルネーム」と「メールアドレス」をsymphonic.mpd@gmail.comご連絡ください。
私の方からR&D Clubの案内をご本人にお送りします。


ということなので、会員になりたい方は以下の内容で僕にメールを下さい。所定の条件をクリアできれば、パパリウスさんにご紹介(推薦)いたします。所定の条件とは上記に引用部分に書かれいる通りです。

①お名前
②メールアドレス
③ユーザ名(このユーザ名で登録を行い、書き込みもこのユーザ名で投稿されることになります)

あと、初対面の方は
④自己紹介
もお願いします。

初対面の方とは、以下のand条件です。

  • 僕の掲示板に書き込んだことが無い
  • メールのやりとりをしたことが無い
  • オフラインで合ったことが無い

「and条件」と書いても意味不明ですね。上記条件の一つにも該当しない場合という意味です。

自己紹介の内容はオーディオ歴、SMPDに興味をもった理由、どう使うつもりか、Linux歴(無いと推薦しないという訳ではありません)、GPLを知っているか(知らなければ推薦しないというわけではありません)を含めて下さい。
名前とメールアドレスだけでは所定の条件をクリアされているか判断できないので、お手数ですがお願いします。尚、個人情報については外部に公開しないことをお約束します。

メールのタイトルは「SMPD会員推薦依頼」として下さい。このタイトルで自動振り分けしますので、よろしくお願いします。

メールを頂戴したあと、会員規約の承認をお願いしています。規約の主旨は

  • GPLを理解し、適正な運用を心がけること
  • 内部で使用可能なソフトウェアを外部に公開(持ち出さない)こと

です。この書き込みで書いたGPLを守ることをお約束頂くためのものです。よろしくお願い致します。

ご注意ですが、SMPDは開発途上のソフトウェアです。最新のリリースには常にバグが残っている可能性があります。ハードとの適合性にも何の保証もありません。操作性についてはympdベースですので、快適とはいえません。nasがなければ動きません。
さらに、Linuxに関し、ある程度の知識がないと、使いこなすことは難しい部分があります。
そのあたりをご承知(覚悟)の上でメールして下さい。僕のメールアドレスはこのページの一番下にあります。

(PC_Audio)   2019/10/05

コメントする

YouTube ゴジラ大会


こうなると病膏肓としか言いようがないとは思いますが(^^;;;、ゴジラ大会です。前回の記事を書くのに捜しまわったわけですが、捨てるには惜しいので。


伊福部昭トリビュート その1 ゴジラ上陸~ゴジラ復活す~ゴジラ登場 / シン・ゴジラ対エヴァンゲリオン交響楽
プロのオーケストラだと思いますが、演奏が素晴らしい。オケ版としてお勧め。


吹奏楽のための「ゴジラ」- 2. March 東京音楽大学
自衛隊のマーチの演奏ではこれがベストワン。
というかマーチだけの演奏。最後はやけのやんぱち大学所蔵の大事なパイプオルガンまて使って、盛り上げるのが凄いです。


吹奏楽のための「ゴジラ」
上記のゴジラ部分、これも演奏がいいです。


Zapping Godzilla(シン・ゴジラ/伊福部昭メドレー)/ 國學院大學ギターアンサンブル2016

ギターアンサンブルでゴジラという発想が凄い。演奏も十分。自衛隊のマーチの処理はいまいち。映像処理はシンプルだけど効果的です。


弦楽四重奏版ゴジラ

YAMATO String Quartetによる演奏。編曲は近藤和明氏。演奏も編曲も素晴らしいと思いますが、やっぱりこの曲はオーケストラか吹奏楽ですね。俺は煩いのは嫌いだという方にはお勧め。


ピアノ版ゴジラ

ピアノ版。演奏、編曲ともに優等生的。ワクワクしません。伊福部の曲でなく芥川の曲のように聴こえます。芸大風(アカデミック)だといっているわけです。


組曲『シンゴジラ』弦楽四重奏版

組曲『シンゴジラ』弦楽四重奏版。Shin-Godzilla Suite String quartetとあるが、多分打ち込みでしょうね。よくここまでやったものだと感心します。素晴らしい出来ではあるが、うこちみの限界もあり、ちょっと単調ですね。
残念。


以上。暴評多謝。どの動画も楽しみました。

(PC_Audio)   2019/09/29

コメントする

License Expired Godzilla の再来襲


今回は折角だから、僕のお気に入りのYouTube動画をご覧になりながら、読んで下さい。

伊福部昭 バンドのための「ゴジラ」ファンタジー 洗足学園音楽大学 Senzoku Gakuen College of Music

素晴らしい演奏と編曲だと思います。映像もよく出来ています。

さて、別に旧JPLAY日本語デスクがいなくなったからゴジラは消えたというわけではないので、復活したライセンスにも、当然、襲いかかって来ました。

Hi Marcin, 

License Expired Godzilla has appeared again in my i9 machine just now. 
Error Code is 0 -> 30. 
First it appered suddenly with error code 0 and I reinstalled femto. 

In the first rebort immediately after reinstallation of femto, 
I called TurboActivate.exe in my JPLAY folder and confirmed my license. 
Confirmation has ended successfully. 

But after that, I started JPLAY setting and found error code 30. 
I retried reinstallation but same result. 
After that, I tried TurboActivate's input of my i9 license key(xxxx-xxxx-xxxx-xxxx-xxxx). 
But result was same(error code 30). 

I don't know what to do. Please give me some advice. 

これに対するマーシンの返事は定型のもので、「最新版をダウンロードして、再インストールしろ。時間を確認しろ。インタネットとの接続を確認しろ。タスクマネジャを使って、JPLAYサービスが動いていることを確認しろ」というものなので省略。

It doesn't work. 
I tried it according to your advice but the result is same (error code 30). 
TurboActivate's confirmation and reinput of my license is same result. 
And I tried bios clear but same result.  
What is error code 30 ? 

これに対するマーシンの答えは

It's simply trial expired, but there could be 2 other reasons:
1) date, time and timezone set incorrectly
2) can't activate to activation server

がerror code 30の理由。だから、最初のメールで「時間を確認しろ」といってきたわけですね。ところが、その後は「wydayのサイトの情報を使って、ネットの接続を確認しろ」「タスクマネジャを使って、JPLAYサービスを再起動してみろ」という感じ。最後は

I see that there is a new turboactivate version available, 
I will check it out and see if it helps.

という内容なので、分かってないなという様子でした。それで、こういう具合に確認しました。

I confirmed JPLAYservice start 
and task manager's service tab is checked, 
Also network completely works because I can use my NAS. 

I have two licenses. So I suspect there happens an inconsistency 
between the license and model information managed by your server 
and the license information of my hardware.

この後ライセンスキーに関するやり取りがあって、その後、彼から

Thank you. Looks ok on my side: have you made any hardware modifications 
since the activation?

これで分かりました。僕のリプライ

I cann't remember surely but there is a possibility that 
I changed lan from lan card to internal(motherboard) lan. 

This is because microsoft Windows 10 did not support 
the intel lan chip of my mother board, so I had used Realtek net card. 

どうも、このlan構成の変更がゴジラの再来襲を招いたようです。マーシンからの返信。

This could be the reason... the hardware ID is modified when either CPU, 
motherboard or network adapter changes. The best case is that I reset 
the activation. Which license code is it?

という訳で、これで解決するはずだったのですが、困ったことに、二つのライセンスのどちらがi9マシンに使ったのか覚えていない。従って、僕の返事は

I'm not sure which is which
I assume this one is for i9 machine 以下略

彼からリセットしたよというご返事をもらい、やってみたが、駄目。仕方がないので、駄目だよとリプライしたら、彼からのご返事。

I deactivated the other license code. I can only see external IP 
address and the activation date, nothing else unfortunately

これで、ようやく解決しました。しかし、マーシンが “external IP address and the activation date” しか分からないとは知らなかった。「nothing else unfortunately」とは、ご同情します。wyDay社のサーバ機能は問題だらけのようです。
というわけで、最後の僕のメールは重要なので、日本語に訳して、ご紹介します(実際には、二つのメールに分かれて書かれていますが、ひとまとめにしました)。

マーシンさん

最終的になんとか動きました。ゴジラは海に帰っていきました。

このメールのやり取りはTurboActivateの問題点を
我々に教えてくれたと思います。
僕の意見は次の通りです。

僕はJPLAYが認証機能を外付けにしているのはもっともだと思っています。
なぜなら音楽プレーヤを開発するために貴方が保持する貴重な人材を
無駄に使うことはないからです。認証機能などという特殊な処理は
それに特化した会社に任せることが賢明です。

問題はwyDay社の実力です。

wyDay社の顧客の大半は単純な認証処理を行う顧客ばかりなのだと
思います。それらの顧客は、彼らのソフトウェアを最初に
認証されたハードウェアで固定的、永久的に使い続けられるだけで
十分満足する顧客ばかりなのだと思います。

しかしながら、JPLAYが要求する機能はもっと複雑です。
つまり、認証は半年毎に新しいハードウェアに切り換えることが
出来ます。またデュアル構成を意識し、二台のハードウェアに
一つのライセンスが割り当てられます。

この複雑性が問題を引き起こしているのだと思います。

今回の僕のトラブルを例にとり説明してみましょう。
問題は二つありました。

一つ目はLAN構成を変更したことにより、クライアント側の認証が
無効になってしまったこと。
二つ目はサーバ管理者にトラブル対応に必要なハードウェア情報が
提供されないこと。
順番に説明します。

1. LAN構成の変更の件

貴方はJCat LANカードを販売していますね。もし、このカードを買った
お客様が「カードを付けたら、ゴジラが出たぞ」と言われたらどうしますか。

これ以上の説明は不要かと思います。LANカードを変えるだけで、
クライアント側の認証が無効になるとは何たる仕様かと思います。

wyDay はマザーボードを認識するために、Biosに書き込みをしています。
当然、どういうCPUが使われている情報をもっています。どのような
LANチップを使っているのかという情報もクライアント側にあるはずです。
従って、LAN構成が変わっただけだということは認識出来るはずです。

マザーボードもCPUも前のままなのに、LAN構成が変わっただけで
クライアント側の認証が無効になるとは、一体どういう認証チェックを
行っているのでしょうか。
マイクロソフトでさえ、LAN構成の変更は認めているのですよ。
マイクロソフトが出来ることをこの会社が出来ないということは、この
会社の技術力のレベルをはっきりと示しています。

2. サーバ管理者に必要な情報が与えらていない件

貴方は「不幸なことに、私は外部ipアドレスと認証した日付以外、何も
分からないのだ」と書かれました。
何と言う理屈に合わない仕様であるか。

このサーバー管理者に余計な情報を渡さないという仕様は、
サーバ管理者とサポート担当者が別々である時は不正防止のためには
必要だと思います。
しかしながら、サポートとサーバー管理を一人の人間が行っている
場合は意味がありません。逆に問題解決な必要な情報が提供されない
という意味では問題があります。
出来の悪いシステムですね。

もう一つ付け加えます。

以下はwyDayのプライバシーポリシーから引用です。
"wyDay uses collected information for the following general purposes: 
products and services provision, billing, identification and authentication, 
services improvement, contact, and research."
笑っちゃいました。
顧客に満足に問題解決に必要な情報を与えもしないで、よくこういうセリフを
書けるものだと感心しましたね。

他にもいろいろ問題はあるだろうが、この位で十分でしょう。

さて以上の状況を踏まえての僕の貴方(マーシン)への提案です。
「当面はこのシステムを使わざる得ないのだろうから、じっと我慢、
運用で対処するしかない」というものです。

僕は貴方の半年に一回再アクティベーションが出来るというルールは
適切な規則だと思っています。
しかし、今回の僕のケースのようなトラブルはこの回数にカウントすべき
ではないと考えます。
勿論、wyDayのシステムが正しく動作し、こういう問題を発生させない
ことが好ましい。しかし、この会社にそういう賢い振る舞いを
期待出来ないとしたら、運用で対処するしかないです。
従って、僕の今回のはアクティベーションは例外として処理すべきです。

今回の二つの問題点はwyDayにとっても真剣に考慮すべき問題だと
思います。
僕は貴方にwyDay の掲示板か、メールで今回の件について抗議する
ことをお勧めします。

以上です。書きすぎた面も多々あるかと思います。
ご参考になれば、幸いです。

さて、このメールに対するマーシンの返信です。

Thank you for your input. Today I am testing the new version of 
TurboActivate.? I hope it works smoother.
・・(再アクティベーションのルールに関して)・・
I agree, this is a problem, but I am not so strict about the one 
deactivation policy per 6 months. Some customers replaced hardware more 
often, because of the failure or other reason and I made exception 
without question asked and deactivated their PCs. I say on the website 
that there is 1 free deactivation per 6 months just to prevent piracy, 
because of the way how turboactivate is set to work with jplay.

ということです。マーシンさんは、今後、適切に対応されると思います。

そして、最後に、こちらで動画を締めることにいたします。ゴジラといったら自衛隊です。

陸・海・空自衛隊音楽隊 シン・ゴジラ、ヤシオリ作戦、凱旋行進曲

ヴェルディ、アイーダ、凱旋行進曲で終わるのがいいですね。

(PC_Audio)   2019/09/08

コメントする

UPnPの世界 第二幕 その5(Linux連合軍)


例によって本題に入る前の前置きです。
前回、「donuts.shop73さんが rpi2 upnpgw-usb + smpdplayer という構成において、aplayとMPDの間で分割するという独創的な発想をされた」と書いたのですが、ご本人から、「それはちょっと違う。」という訂正の依頼がありました。頂戴したメールの関連する部分を引用します。

今回追加された記事の「aplayのみを独立させ、mpdとncatでつなぐ」構成
ですが、SMPDのv0.4系時に、PPAP方式としてパパリウスさんが提案され、
当時としては結構な人が試していたと記憶しています。
自分はただ、この方式をハイレゾ対応に発展させただけであって
独創的なのは今も昔もパパリウスさんです。
あと、lightMPDのdigififanさんも忘れてはいけません。
自分はこれらをありがたく利用させていただいているだけです。

ということです。

まあ、しかし、SMPDのv0.7系で、SMPDがXenomai対応された状態で、この方式を試されたのはdonuts.shop73さんだけであり、さらにそれを見事に実装されたわけだから、donuts.shop73さんの独創性も何ら引けをとるものでは無いと思いますが、上記のご本人のコメントを残しておきます。

さて本題に入ります。

Linuxを使ったUPnP方式のフロントとして使えるのは以下の通りです。

1) lightMPD-upnpgw(apu1/2)
digififanさん作、BackEndはMPDで構成されるシステムとなる。具体的にはlightMPD-upnpgw(apu1/2)のplayer、SymphonicMPDレンダラ化(rpi-2b/3b)したものなどが使われる。
在り処はこちら
2) rpi2 upnpgw-usb(smpdplayer対応、rpi2/3(+))
donuts.shop73さん作、BackEndはaplayで構成されたシステム(smpdplayer)専用となる。
在り処はこちら。かなり古い版となります。僕は最新版を使っています。
3) rpi2 upnpgw-usb(upnpgw-usb対応、rpi2/3(+))
上と同じものです。設定ファイルが異なるだけ。BackEndはMPDで構成されるシステムとなる。同じrpi2 upnpgw-usbの設定ファイルの変更でBackEndを構成するのが普通の使い方である。従って、rpi2/3で統一された構成となる。
4) lightMPDraspi-armv7/armv8(-64)(rpi用)
digififanさん作、基本的にはapu版のlightMPD-upnpgwをrpi全機種に展開させたものだと思います。「と思います」と書くのは僕は使っていないので、よく分からないからです。
在り処はこちら
5) lightMPD UPnP-Adapter版(BBB/BBG用)
yo作。これはサポート停止となっておりお勧めできません。作者がいうのだから、間違いありません(^^;;;。ただ、BBB/BBG用のfront用システムはこれだけかもしれませんね。
在り処はこちら

というところで、ここでは僕が使っている最初の二つについてご紹介します。

lightMPD-upnpgw(apu1/2)

はっきり言ってしまうと、僕は、Linuxを使って、Frontを構成するハードはapu1/2しかないと思っています。理由は、それ以外のハードは足回りが弱すぎるからです。
LAN端子が一つしかとれないarmアーキテチュアのハードにFrontを構成させようなんて、無謀の極み。クジラに山登りさせようというようなものです。
という訳で、僕はFrontは lightMPD-upnpgw apu1、BackEndはレンダラ化したSymphonicMPD(rpi-3b)という構成でメイン機を使っています。

この構成でのFrontの lightMPD-upnpgw apu1 の設定方法ですが、実は、Front lightMPD-upnpgw apu1 とBackEnd lightMPD-upnpgw apu2 v1.20という構成の場合とまったく同じです。つまり、BackEndがレンダラ化したSymphonicMPDであっても、lightMPD-upnpgw apu2 v1.20であっても変わりません。意外に思われるかもしれませんが、Front(upmpdcli+polipo) vs BackEnd(MPD)という構成には変わりないので、当然そうなるということなのですね。
備忘録として設定方法を残しておきます。

[network]
        interface=eth0
        address=192.168.1.80
        gateway=192.168.1.1
        netmask=255.255.255.0
        nameserver=192.168.1.1
        domain=xxxx.xxxx.xxxxx.xxxx.jp

[ntp]
        server=192.168.0.0
        ntpd=no
        timezone=Asia/Tokyo


[network:player]
        interface=eth1
        address=10.0.0.1
        netmask=255.255.255.0

[cpuaffinity]
        type=0

[irqpriority]
        setdefault=no

[telnetd]
#  yes | no
        enable=yes
        port=23

[upmpdcli]
        enable=yes
        upnpiface = eth0
        mpdhost=10.0.0.2
        mpdport=6600
        friendlyname=UpLightMpd
        ohproductroom=UpLightMpd
        openhome = 1
        ohmetapersist = 1
        logfilename=/var/log/upmpdcli.log
        loglevel = 3

[polipo]
        enable=yes
#
        proxyAddress = 0.0.0.0
        allowedClients = 10.0.0.2
#
        chunkHighMark = 1024
        chunkLowMark = 256
        chunkCriticalMark = 768
        objectHighMark = 2048
#
        dnsQueryIPv6 = no
        cacheIsShared = false
        dnsUseGethostbyname = yes
        disableConfiguration = true
        disableIndexing = true
        disableLocalInterface = true

[nat]
        masquerade=network:player
        dnsforwarding=yes
        ntpforwarding=yes
        8022=10.0.0.2:22
        8080=10.0.0.2:80

polipo.confとupmpdcli.confはこちらで設定された内容が反映されるので、修正は不要です(というかこちらもディフォルトのまま)。[nat]はSMPDに合わせて8022と8080を設定しています。

rpi2 upnpgw-usb(smpdplayer対応)

smpdplayer対応する場合は、Frontとして使えるのはrpi2 upnpgw-usbだけです(rpi2 という名前がついていますがrpi3でも問題なく使えます)。
この場合、Front側には2回線必要となりますが、LAN接続用USBアダプタを使います。USBを使い、直接接続するという方法も使えるようです。このUSBを使い、直接接続するという方式ですが、LANアダプタを持っていない時の代用という感じですが、それなりに使えます。音も悪くはないと思います。5) lightMPD UPnP-Adapter版(BBB/BBG用)でも、donuts.shop73さんの顰みにならい、僕もこの方法を取り入れています。

さて、ここからは盛大に脱線します。

このUSB直結で思い出したのが最新のDiretta製品です。
図をOliospecの商品説明のページから引用します。




このPC1とPC2の繋ぎの部分はUSB直接接続です。utpというのは USB接続のケーブル長制限を緩和させるための仕組みで、USB直結であることには変わりありません。
Oliospecの商品は上の図の左側のPC1の部分とSU-8というDDCをセットにして販売しているものですが、このPC1の部分はDirettaそのものです。従って、これだけ注文すれば、謎につつまれたDiretta本体を比較的安価に入手出来るということになります。
右側のPC2の部分は自前で用意する必要があります。Diretta対応のASIOドライバを組み込んだ標準のWindows10のPCオーディオ用プレーヤシステムを構築するだけなので、問題はないでしょう。プレーヤはASIO対応しているプレーヤソフトなら、何でも使えるのですかね。「ご用意頂いたWindowsPCにASIO出力に対応した再生アプリをインストールしてください」とあるので、ASIO対応したプレーヤなら使えるように読めますが、よく分かりません。
この図が公開され、「Direttaとは」という丁寧な解説がされて、初めてDirettaの仕組みがよく分かったという感じです。
今まで、ラズパイでのDirettaについては、philewebにいろいろ(ここここ)な記事が掲載されていますが,今回の製品説明が一番分かりやすいです。設計者が解説されたのだと思いますが、さすがですね。図のOSとある部分がLinuxに変わったと見れば、リンク先でゴタゴタと説明されている内容がすっきりと納得できました。
ネットワークのやり取りにTCP-IPでなくUDPを使っているというのがミソであるようです。また、ip-v6を使っていますが、これは互換性確保のためで、性能云々とは関係ないという作者の発言がありますので、多分その通りなのでしょう。
結局、この図でいうと、PC1のDiretta sink、Buffer controlとPC2のASIO API、Diretta ASIO、Diretta Sync Master という部分がDirettaの実態のようです。

「何でUPnPの話をしているのにDirettaなのか」という方はいらっしゃると思いますが、この意味不明さがこのサイト(みみず工房)の特長です。
本題に戻ります。

設定もこの構成がディフォルトになっていて、このディフォルトの構成であれば外部への固定ipアドレスを設定する以外は設定の変更は不要です。固定ipアドレスを設定するLAN端子はUSB側のeth1であることに注意する必要があります。あと[nat]の設定と[telenet]の設定は変更しておいた方が良いでしょう。
あと、rpi2 upnpgw-usbとsmpdplayerの最新版はそれぞれ20190814です。興味のある方はこちらの書き込みを参照して下さい。
なんと、脱線から戻った後は2パラグラフのみ。これで終わりです(^^;;;。

(PC_Audio)   2019/08/30

コメントする

ブニアティシヴィリのシューベルト





最近、CDを買うのにジャケットで選ぶという変な癖がついてしまいました(^^;;;。
もちろん何でもいいと言う訳ではなくて、好みの演奏家のCDで、知っている曲という条件は付ける訳ですが。

これもそうで、「あれ、このオフェーリアもどきは誰だろう」とジャケットを手にとり、ブニアティシヴィリの新譜と知る。ジャケットの写真は、当然、ブニアティシヴィリさんご本人でした。


しかし、最近のヨーロッパのはずれ(などと書くと、また放送禁止用語を使ったと怒られるかもしれないが、個人のブログなのだから、ある節度があれば、後は勝手でしょ)から出てくる女流演奏家は何でこんなに覚えにくく、舌を噛みそうな名前ばかりなのですかね。ブニアティシヴィリしかり、コパチンスカヤしかり、バティアシュヴィリしかり。

演奏曲目はこんな感じです。





要するにシューベルトの最晩年の曲を集めたということになるらしい。最後の曲はちょっと違ってリストの編曲した歌曲セレナーデのピアノ版です。


ブニアティシヴィリさんご自身が二つのライナーノートを書いていて、それぞれのタイトルが「NOTES OF A FEMONIST」と「DEATH AND THE MAIDEN」。





何が書いてあるかというと、これが全然曲の解説になっていないのですよね(^^;;;。上は「NOTES OF A FEMONIST」の冒頭の英語部分とブニアティシヴィリ=オフェーリアの写真。





これは「NOTES OF A FEMONIST」の冒頭のドイツ語部分と別のブニアティシヴィリ=オフェーリアの写真。




そして、これは、「DEATH AND THE MAIDEN」のフランス語の部分とクレジットと不思議な写真です。


それぞれ言語の「DEATH AND THE MAIDEN」の後には Khatia Buniatishvili という筆者名はあるが翻訳者のクレジットはありません。
ということは、多分、ブニアティシヴィリさんは母国語のグルジア語(かしら?、ジョージア語といわないといけないのですかね、それとも別の言語 ? )で書き、影武者翻訳家が訳したということでしょうね。僕は英語しか読めませんから、英語で読んでみましたが、超難解な英文です。相当に文学的(詩的)表現で半分も意味が分からない(^^;;;。
タイトル「NOTES OF A FEMONIST」の通り、何かフェミニズムとシューベルトのこの曲は関係があるよといっているらしいのですが。



演奏は極端な強弱なダイナミズムを強調した演奏です。まあこのピアノソナタはシューベルトの死の直前に作曲された曲で普通のピアニストでも強弱の差は大きいのですが、それでも pppp~ffff か ppppp~fffff 位です。この演奏は表情記号の限界を突破していて、ppppppp~fffffff位になります。冒頭の弱音部分を普通の弱音に合わせて聞いていたら、第1楽章123小節と124小節のffzで、女房が飛んできて「アンタ、何を大きい音を出しているのよ」と怒鳴り込まれました(^^;;;。

ただその振幅の大きさをまったく違和感なく聴かせるのがブニアティシヴィリさんの凄いところですね。アルゲリッチさんも真っ青、裸足で逃げ出すというレベルです。



とここまで書いて、そういえばレコ芸の先月号にこのCDの評があったなと思い出しました。濱田さんの文を読んでビックリ。同じですね。指摘している内容が。その部分を引用します。

周知のようにこれまでいくつもの名演を生んできたソナタだが、カティアは、明らかにそれらのどれとも似ていない、ユニークな演奏をここに刻んでいる。演奏は多くの例にならってひそやかに静謐に始められるが、一般の楽譜の2ページ目に入ったところからにわかに波立ちを強め、嵐のようなクライマックスに達する。このクライマックスを強調する例はもちろん他にもあるが、カティアの場合には、内からの、ある痛切な衝動を感じさせる。


さすがですね。濱田さんは僕がリスペクトする評論家ですが、ほぼ同じ感想を、僕とは全く異なる見事な表現でまとめられています。面白いので、具体的に対比し、ご覧頂きましょう。

僕    => 普通のピアニストでも強弱の差は大きいのですが、それでも pppp~ffff か ppppp~fffff 位です。
濱田 => 周知のようにこれまでいくつもの名演を生んできたソナタだが

僕    => この演奏は表情記号の限界を突破していて、ppppppp~fffffff位になります。
濱田 => カティアは、明らかにそれらのどれとも似ていない、ユニークな演奏をここに刻んでいる。

僕    => 冒頭の弱音部分を普通の弱音に合わせて聞いていたら
濱田 => 演奏は多くの例にならってひそやかに静謐に始められるが、

僕    => 第1楽章123小節と124小節のffzで、
              女房が飛んできて「アンタ、何を大きい音を出しているのよ」と怒鳴り込まれました
濱田 => 一般の楽譜の2ページ目に入ったところからにわかに波立ちを強め、
              嵐のようなクライマックスに達する。

僕    => ただその振幅の大きさをまったく違和感なく聴かせるのがブニアティシヴィリさんの凄いところですね。
              アルゲリッチさんも真っ青、裸足で逃げ出すというレベルです。
濱田 => このクライマックスを強調する例はもちろん他にもあるが、
              カティアの場合には、内からの、ある痛切な衝動を感じさせる。

いかがですか。こうやって対比してみるとよく分かりますね。同じものを聴き、まったく同じように感じているのに、言葉にするとこれだけ表現が変わる。まあ、「僕は絶対に音楽雑誌に評論を書くような身になれないなぁ」と痛感いたしましたです(^^;;;。

(music)   2019/08/22

コメントする

top page     previous page     next page

mail