[Linux]PulseAudioのDLNA Sinkを使ってみた

先日引っ越したわけですが、それに伴いPCの音響周りが様変わりいたしまして。
これまではPCからHDMIにてAVアンプに映像と音声を出力して、AVアンプから7.1chスピーカ構成となっていたわけですが、現在はAVアンプはリビングにTV周りとつながっており、PCは自室にてPCディスプレイと直結。
このため、PC内の音楽を再生するには自身がDMSを立て、AVアンプからアクセスして再生するとか、まぁいくつかの方法が考えられるわけです。
が、私が知る限り、DLNAクライアントでアルバムシャッフルに対応したものは見たことがありません・・・。
いわんや、うちのAVアンプ（ONKYO TX-NA579）も当然対応しておりません。

うーん、どうしようもないんかなーと思ってダメ元で「PulseAudio DLNA」でぐぐってみたところ、なんとPulseAudioのSinkとしてDMRを使うことができる、まさに私が欲していたばっちりなプロジェクトがGithubにあるじゃないですか！！！
masmu/pulseaudio-dlna · GitHub
これにはなかなか興味を惹かれまして。
導入を試みていたのですが、本日ようやく音を出すことができたのでそのやり方をば。

事前準備

まず事前準備として、Firewallにて適当なポートを開けてやります。DMRからpulesaudio-dlnaで公開するDMSにアクセスできるようにしてやらないといけないんですね。
引数無しでpulseaudio-dlnaを起動した場合、8888番で待ち受けます。これをそのまま使ってもいいでしょうし、何かとバッティングしているなら適当な番号で公開しましょう。ポートの開け方についてはここでは説明を省かせていただきます・・・（Fedora20以上ならFirewalldのはず。iptablesを使っている場合はそちらで設定ください）。

DMRへ接続

ポートが空いたらDMRへ接続です。なお、私の場合は自動探索でなぜかうまくDMRを見つけてくれなかったのでURL直接指定です・・・。
DMRのサービスURLについてはgupnp-universal-cpというアプリで調べることができます。DLNA周りでいろいろと調べるなら入れておいて損はないアプリです。
うちのアンプの場合はサービスURLは下記のようになります（ポート番号とかは適当です）。
http://xxx.xxx.xxx.xxx:1234/upnp_descriptor_0
これを指定してpulseaudio-dlnaを起動するには以下のように実行します。

$ pulseaudio-dlna --renderer-urls http://xxx.xxx.xxx.xxx:1234/upnp_descriptor_0

このあたりは機種によってまちまちでしょうから環境に合わせて設定ください。。。
うまくいけば「INFO:root:"TX-NA579" registered.」みたいなメッセージが出ます。

音を再生

DMRへ接続が完了したらpavucontrolなどから再生Sinkデバイスをpulseaudio-dlnaによって接続されたDMRに変更して通常通り再生すればOK！
DMRから音が流れだしたら成功です！

その他

デフォルトでは再生音はmp3にエンコードされてDMRに転送されるようですが、うちの環境ではmp3への変換がうまくできなかったのかエラーを起こしていたのでエンコード形式はwavにしております。これもpulseaudio-dlnaの引数に「--encoder wav」と指定すればOKです。ただ、どうもPulseAudioの設定は無視されている模様？
当方の設定では48000Hz/32bit le形式にしており、PulseAudio的にはDMRのSinkもその形式になっているのですが、AVアンプが再生しているストリームの形式を確認すると44100Hz/16bit なんですよねぇ。これだとハイレゾ音源がダウンサンプリングされてしまうのでせっかくのDLNAを活かせていないような気も・・・Orz
ただ、このPulseAudioのSinkプラグインの方式では、元のファイル情報は残っていないだろうから難しいのかな・・・？
ココらへんはソースを見ながら追いかけて行ったらどうにか出来たりするのかしら。フォーマット指定はあるけどサンプリングレートとかビットレートについては指定できないんだよなぁ。でも多分やってできないことはないだろうからそこは要調査かな。

ということで、非常にニッチなアプリでしょうがPC（Linux）の音をDLNA経由でアンプから再生したい人は一度お試しあれ。
ストリーム扱いなのでPCからの音すべてがDLNA経由でAVアンプから再生されます。結構面白いです。

まだまだ不安定ですが、こういう自由度がLinuxはたまりませんなぁ・・・ｗ

[Linux][Fedora]Fedora22へアップグレード

ということでFedoraのアップグレード記録。
今回もアップグレードはFedUpを使用しました。
しかし今回のアップグレードはなぜか大変苦戦・・・。途中で自身の引越も挟んだためにちゃんと動くようにできるまでにかなり掛かってしまいましたがなんとかなりました！
ということでTopはPlasma5のデスクトップ絵。天気予報のウィジェットは野良のものをインストールしました。まだPlasma5用のウィジェットは数が少ないようですねぇ。
そのうち増えてくるとは思いますが、なんのかんのとKDE5になって仕様が変わっているようで、そこいらはまだまだ触りきれておりません・・・。
かなり見た目がおしゃれになったなーという感じ。KDE4の頃から大好きでしたがより好きになりました。
ただ、まだ安定はしてないようですかねぇ？　うちの環境だとめちゃくちゃCPUリソースをPlasma5が持って行くんですが他の方だとどうなんでしょう・・・？　GPUをうまく使えていない・・・？
このあたり、Waylandになったら改善されるんですかねぇ？　Gnomeの方はWayland対応が進んでいるとかいないとか。Gnomeは使ってないのでさっぱり分かりませんが。KDEがWayland対応するのを楽しみに待っておくとしましょう。

それでは今回の悪戦苦闘日記。
気付けばFedora22がリリースされたということで、引越を週末に控えた土曜日にささっとFedUp。これ自体はすんなり完了したんです、えぇ。　ただFedUpを使ったのが運の尽きだったかも知れません・・・。
FedUpが完了し、Fedora22を起動しようとするとブート開始直後にフリーズ。なんじゃこれ、さっぱり分かんねぇ！って思って旧カーネルを選択肢てみても全く同じ所でフリーズ。　せめてEmergency Modeに落ちてくれたらと思うものの、そんなことはなくフリーズ。

埒が明かないので、Grubに登録してあったレスキューモード用のカーネルで起動してみると、こちらは起動。とりあえずjournalctlで起動エラーの内容を確認してみると、なんとUEFIにて指定しているvfatのEFIパーティションのマウントに失敗。これのせいで起動できていないという感じに。

※ なお、これは後で判明しますが全く関係なかったようで、真因は別に有りました。

おいおいおいおい一体どうなってやがると。vfatがマウントできないって一体何の冗談かと。dracutでinitramfsを作るときにvfat用のモジュールが取り込まれなかったとでも？　そんな馬鹿げた話があるか！　とかやさぐれながら、とりあえず検索してみると同様のエラーで起動できなくなった案件がちらほらと。
が、悲しいかなどの案件も未解決のままでレスが終わっている・・・。
これ、もしかしてやべぇのかなとか思いながらも自身の引越なんかもあって１週間ほど放置してたんですが、まぁ触ってないので久々に触ってももちろん起動してくれるわけもなく。

dracutでinitramfsを作りなおしてみてももちろんダメ。レスキューモードで起動して、それぞれのbootやらefiパーティションやらをマウントしてchrootしてdracutでinitramfs再生成してもダメ。というかレスキューモードで起動した時にはvfatが読み込まれていないのか知らないけれどefiパーティションをマウントできないのよねー。その状態でinitramfsを再生成してもそりゃダメだろうと。

そいじゃーFedora22のLiveUSBだと起動するのかしら、と試しにLiveUSBを作って起動したらすんなり起動。あぁ美しいかなPlasma5のデスクトップ・・・！
くっそこれを早く使いたい！　LiveUSBが起動するということはハード的には問題なく、なんかの設定だろクソ！って思いながらここでもchrootしてinitramfsを再生成してみたけどやっぱりダメだった・・・Orz

ココらへんで挫けそうになったんですが、そういやまだ試してなかったなと思ってランレベル1、シングルユーザーモードで起動してみたところなんとすんなり起動。
ちゃんとefiパーティションもマウントされている。　あっれあっれ、なにこれどうなってんの？　と思いつつ、そのままtelinitでランレベル5で起動しようとするとフリーズ。
HAHAHA、おいまさかこれXが起動できないとかそういうオチか？　え？　って思いながら次はランレベル3で起動したらなんと起動。
これはいよいよXが怪しい、そう思ってstartxしたら案の定起動失敗。
ログを確認したところ、どうもABIのバージョン不一致。しかもradeon。

なるほど、バージョンがおかしくなっているのだというのならパッケージ更新してやろうじゃねぇの、って更新しようとしたら800MB程度の大漁のパッケージがあったんでちょっとWait。多い、これ全部やっておまけに起動しなかったら悲しいぞ、ということでX関連だけアップグレード。

そうするとstartxでのABIバージョン不一致によるエラーは解消。されたものの、やっぱり立ち上がらない。
今度はブロックデバイスファイルにアクセスできないというエラー。まぁ一般ユーザーでの実行だしね、仕方ないね、無意味だろうけどブロックデバイスへのアクセス権限を666にしてみようか、ってやってみたら、エラーは消えたもののXは起動しない。
そしたらsudoでX起動したらどうなるんだろう、ってやってみたらX起動するじゃないですか・・・！

でもroot権限でXが起動したところで仕方ないし、この状態でtelinit 5ってやってもやっぱりフリーズ。

くっそあと少しなのに・・！って思いながら、もうこうなりゃしかたない、残りの更新パッケージ全部当ててやるか・・・！って当てたところなんとすんなり起動Orz
EFIパーティションがマウントできないとかいうjournalctlのエラーは一体何だったのかと。

どうも、FedUpのタイミングが悪かったのかなんなのか、fc22のパッケージとfc21のパッケージが混在していたためにXがうまく起動しなかったのが原因だったようです。最新パッケージに更新したことでバージョンの不一致等が解消され、無事起動したようでした。

しかしながら解せないのはFedUpで実行したのになんでそんなパッケージの混在が発生してしまったのか。基本的には全部最新のパッケージにしてくれるはずだと思ってたんだけどなあ・・・・。　つまるところ、chrootでやるべきはinitramfsの再生成ではなく、dnf updateだったようですOrz

何はともあれ、Plasma5による新しいKDEを楽しんでいます。
まだちょっと不安定なところも有り、KDE4.0の頃を思い出しますが、そこから怒涛の勢いで更新されてすぐ安定しましたし、そんなに心配は要らないですかね。
目下の課題は接続環境が変わったために音が鳴らなくなってしまったこと・・・。ここはまぁUSB DACなんかを追加して環境を整えたいところですねー。

あと、いよいよ22でyumがdnfに完全に置き換わりました。yumだとインストール済みのパッケージに対してinstallコマンドを実行したらupdate扱いでコマンドを実行してくれたんですが、dnfだとinstallコマンドとupdateコマンドは完全に分かれてるっぽい？　installだと「最新だよ！」って言ったくせに、updateコマンドだと更新を取ってきたりしてちょっと面食らいました。　そういえばインストールされていないパッケージに対してupdateコマンドは実行しなかったなぁ。そっちを試しても面白かったかも知れない。

ま、今回もいろいろと勉強になりました（笑）
やっぱFedoraはこうでないとな・・・！