谷本 心 in せろ部屋 このページをアンテナに追加 RSSフィード

2017-01-11

TT-BA09で、テレビの音声をBluetoothで無線化してみた(成功編)

BABYMETALのライブが放送される時期だけWOWOWを契約する、ちょっとWOWOWにとっては迷惑気味なメイトのCERO-METALデス!


さて、普段ヘッドホンで音楽を聴くようになってから、テレビでもライブなどを観る時にはテレビのスピーカーでは物足りなくなり、ヘッドホンで聴くようになりました。ただ3mぐらいのケーブルを使ってもテレビまで近いですし、キッチンで料理や洗い物をしながらテレビを観る時になんかには使えません。

そんな背景から、テレビの音声をワイヤレスにしてヘッドホンで聴きたいなーと思っていました。


ちょうどWOWOWBABYMETAL東京ドームライブが放送される年末年始のこのタイミングで、テレビの音声をBluetoothで飛ばして、ヘッドホンで聴ける環境を作ることにしました。


何がいるの?

そもそも、テレビの音声をBluetoothで飛ばすには何が必要か、という整理からです。接続の流れはこんな感じになります。


テレビ → Bluetoothトランスミッター → Blueotoothレシーバー → ヘッドホン


テレビからの音声入力を受けてBluetoothで飛ばすものを「トランスミッター」と呼び、Bluetoothで受信をする方を「レシーバー」と呼びます。ITエンジニアの皆様方にも分かりやすく説明すると、トランスミッターがWi-Fiルーターに相当し、レシーバーWi-Fi子機に相当します。

またレシーバーとヘッドホンをケーブルで繋ぐものもあれば、ヘッドホン自体がレシーバーになるワイヤレスヘッドホンなどもあります。


製品の選び方

Bluetoothトランスミッターやレシーバーを選ぶ際の観点になるのが、次の2つです。

  • 音声入力の方式(ヘッドホンジャック、赤と白のRCAピンプラグ、光デジタルなど)
  • 対応コーデックSBCAACapt-X、LDACなど)

音声入力の方式はまぁ分かるので割愛するとして、よく分からないのがコーデックです。

ざっくり調べた感じ、次のような違いがあるようです。

  • SBC: ほとんどの機器が対応するけど、音質が悪い。
  • AAC: 主にApple製品で使われる。SBCより音質が良い。
  • apt-X: Androidや多くの機器で使われる。AACより遅延が少ない。
  • apt-X HD: apt-Xをさらに高音質にしたもの。まだ対応製品が少ない。
  • LDAC: ハイレゾ音源に対応するもの。音質は一番良いがソニー製品でしか採用されていない。

対応製品が多いapt-Xが、現在ではほぼスタンダードになってるようです。apt-Xに対応したトランスミッターはいくつかあるのですが、AACやLDACに対応した単体のトランスミッターというのは、ちょっと見つけられませんでした。


実際に買った製品

それで今回用意したのは、次の製品です。

この組み合わせで、ばっちりワイヤレスで視聴できる環境が整いました。


TT-BA09

音声のトランスミッター、レシーバーの両方に使える製品です。TaoTronics社からは似たような製品がいくつか出ているのですが、このTT-BA09は光音声入力があったので、これを選びました。ちなみにTT-BA09には音量を調整する機能がありません。


TT-BA08

上の製品と同じく音声のトランスミッター、レシーバーの両方に使える製品です。TT-BA09よりも一回り小さな製品です。

こちらはレシーバーとして使う際に音量の調整ができるようになっています。通常、光音声入力では出力側での音量調整ができず、レシーバーで音量調整する必要があるため、これを選びました。


それで、繋いでみると。

さすがは同じメーカーの同一シリーズの製品でしょうか、全く何の問題もなく接続できました。

接続はこんな流れです。


テレビ → (光音声出力) → TT-BA09 → (Bluetooth/apt-X) → TT-BA08 → (ケーブル) → ヘッドホン


Bluetoothを切断/再接続をしても、全く問題なく音声を聞くことができます。

また、テレビの音量を変えてもヘッドホンから聞こえる音量は変わらないため、テレビは消音にし、音量をTT-BA08で調整するような使い方になります。音量を調整できないレシーバーだと、こういう事ができないんですよね。


遅延とか音質は?

Bluetoothでよく言われるのが音声の遅延。

apt-Xでは40msほどの遅延があると言われており、口と声がズレるのを気にする僕としては、遅延があるのははっきり分かります。遅延があまり分からない人でも、テレビとヘッドホンの音を両方出せば、はっきりとズレていることは分かるでしょう。

ただ、そうは言っても40msですから、ズレを検出しようとしない限りは、さほど気にならない程度でした。


そして気になる音質ですが、これはとても良いです。

ショボいテレビのスピーカーに比べれば音声はクリアに聞こえ、特に海外映画などの英語もだいぶ聞き取りやすくなりました。音楽番組などもしっかり低音が聞こえるのは、さすがヘッドホンですね。

音楽番組を流しっぱなしにしながらリビングキッチンでウロウロしても、ヘッドホンで聴けるのは最高です。


・・・ということで、特にトラブルも起きることないつまらない話になったのですが、実はこの前に、別メーカーの製品との組み合わせでトラブルがありました。せっかくなので、それについては、また改めて書きたいと思います。


See you!

2016-12-08

Optimizing JavaというJavaパフォーマンス系の書籍が面白そう

急激な冷え込みのせいで「寒い!」というつぶやきがTLに散見されるこの頃ですが、皆さんお風邪など召していらっしゃらないでしょうか。

否応なしに寒いという言葉に反応してしまう、けなげなエンジニアの @ です。


このエントリーは Java Advent Calendar 2016 の8日目です。

昨日は @ さんの「Java Stream APIでハマったこと」で、

明日は @ さんの「マイクロベンチマークツール、JMHについて」でした。


今日のエントリーでは、Javaのパフォーマンス系書籍を紹介したいと思います。

Optimizing Java - O’Reilly Media

URLを見るにつけ、あのオライリー様のサイトですら拡張子が由緒正しい .do なのですから、日本のSIerStrutsを使うことをどうして否定できましょうか。

いえ、今日はそんな話題ではありません。


紹介したいのは上のリンク先の本、「Optimizing Java - Practical Techniques for Improved Performance Tuning」です。名前の通り、Javaのパフォーマンスに関する書籍です。まだEarly Releaseの段階で、全体の1/3ほどしか書かれていませんが、現状の版を入手したので紹介したいと思います。


ここまでで、「あれ、なんか似たような本がなかったっけ」と思った方がいらっしゃるかも知れません。そう、オライリー社からは2015年に「Javaパフォーマンス」という書籍が出版されています。

Javaパフォーマンス - O’Reilly Japan

こちらの日本語版では、私も監訳者まえがきを書かせて頂き、Java Day Tokyoで寺田佳央さんと共にサイン会を行いました。

当時はきっと「この寺田さんの横にいて本に落書きしてる人、誰なんだろう」と思われていたかも知れませんが、私を誰だと思ってるんでしょう、せろさんだぞ?


この2冊について、比較しながら紹介しましょう。


目次

Javaパフォーマンス」の目次は、次の通りです。

1章イントロダクション
2章パフォーマンステストのアプローチ
3章Javaパフォーマンスのツールボックス
4章JITコンパイラのしくみ
5章ガベージコレクションの基礎
6章ガベージコレクションアルゴリズム
7章ヒープのベストプラクティス
8章ネイティブメモリのベストプラクティス
9章スレッドと同期のパフォーマンス
10章Java EEのパフォーマンス
11章データベースのベストプラクティス
12章Java SEAPIのパフォーマンス

JavaのメモリやGCスレッドに関する紹介から、SE / EEやデータベースのパフォーマンスに広げた話をしています。


一方、「Optimizing Java」の目次は次の通りです。

Chapter 1Optimization and Performance Defined
Chapter 2Overview of the JVM
Chapter 3Hardware and Operating Systems
Chapter 4Performance Testing
Chapter 5Measurement and Bottom-Up Performance
Chapter 6Monitoring and Analysis
Chapter 7Hotspot GC Deep Dive
Chapter 8Garbage Collection Monitoring and Tuning
Chapter 9Hotspot JIT Compilation
Chapter 10Java Language Performance Techniques
Chapter 11Profiling
Chapter 12Concurrent Performance Techniques
Chapter 13The Future

うん、ほとんど一緒やん?


「Optimizing Java」には、「Javaパフォーマンス」では触れられていたSEやEEの話などはないため、そこが差分になりそうにも見えます。ただ正直、「Javaパフォーマンス」の10章以降はちょっと薄口な感じでしたので、そこを飛ばせばほとんど同じ内容を網羅していると言えます。


では、何が違うんでしょうか。


Javaパフォーマンス vs Optimizing Java

僕が見た限りでは「Javaパフォーマンス」は教科書に近い内容、「Optimizing Java」はやや読み物寄りの内容になっています。

「Optimizing Java」は、現在執筆されているChapter 5までしか読めていませんが、「Javaパフォーマンス」には書かれていなかったOSJVM周りのレイヤーの話や、テスト戦略の話など、少し目線が違った内容を書いていました。


たとえば、Javaのクラスファイルが「0xCAFEBABE」から始まっていることは、Javaに詳しい方なら既にご存じかと思います。ただ、その先はどうなっているのか。

書籍では次のように紹介されています。

  • Magic Number (0xCAFEBABE)
  • Version of Class File Format
  • Constant Pool
  • Access Flags
  • This Class Name
  • Super Class Name
  • Interfaces
  • Fields
  • Methods
  • Attributes

この先頭を取って

M V C A T S I F M A、

語呂合わせして

My Very Cute Animal Turn Savage In Full Moon Areas

なんて紹介されています。


「僕のとってもかわいい猫は、満月のエリアで凶暴になる」

・・・覚えやすいんですかね、これ?


あ、なんかふざけた本だなと思ったかも知れませんが、もちろん技術的な面もきちんと紹介されています。

あくまで上に書いたようなウィット(?)も挟みながら、Javaの領域だけでなく、必要に応じて低レイヤーにも触れて紹介する本となっているわけです。そのため、「Javaパフォーマンス」を読んだ方でも楽しめる本になるのではないかと思います。


で、いつ出るの? 日本語版は?

この本は2017年3月に出版予定となっています。


また、皆さん気になる日本語版ですが、残念ながらまだ翻訳されることは決まっていないようです。

ただ原著の人気が高かったり、この後に公開される6章以降の内容が「Javaパフォーマンス」とはまた違った切り口であり楽しめるのであれば、翻訳される可能性も十分にあるんじゃないかなと思っています。


そんなわけで、日本語版が出ることを祈りながら、このエントリーを書きました。

Stay tuned, see you!

2016-01-01

[]AWS LambdaでJavaとNode.jsとGoの簡易ベンチマークをしてみた。

あけましておめでとうございます!

現場でいつも締め切りに追われデスマーチ化している皆様方におかれましては、年賀状がデスマーチ化していたのではないかと憂慮しておりますが、いかがお過ごしですか。

エンジニアの鑑みたいな僕としましては、年始の挨拶はSNSでサクッと済ませ、年末年始は紅白など見ながらAWS Lambdaのソースコードを書いていました。


ということで、Lambda。

Lambdaを書く時に最初に悩むのは、どの言語を選択するか、なのです。


まず手を出すのは、サクッと書けるNode.js。

ただNode.jsの非同期なプログラミングになかなか馴染めず、わからん殺しをされてうんざりしていました。みんなどうしているのよとtwitterで問いかけたところ @ からPromiseを使うべしと教わり、なるほど確かにこれは便利ですナと思いつつも、これが標準で使えないぐらいLambdaのNode.jsが古いところにまたうんざりしました。


では手に馴染んでるJavaを使ってみたらどうかと思ったら、メモリイーターだし、なんとなくパフォーマンスが悪い感じでした。詳しいことは後ほどベンチマーク結果で明らかになるわけですが。


それなら消去法で残ったPythonなのですが、僕マジPython触ったことないレベルであり、これは若者たちに任せることにしているので、Pythonも選択肢から消えて。


本来、Lambdaみたいな用途にはGoが向いているはずなのだけど、いつ使えるようになるんだろうなぁなどと思って調べてみたら、Node.jsからGoを呼び出すというテクを見つけて、こりゃいいやとなりました。

http://blog.0x82.com/2014/11/24/aws-lambda-functions-in-go/


ただGoを呼ぶにしてもNode.jsを経由するためのオーバーヘッドはあるわけで、じゃぁ実際にどれぐらいパフォーマンス影響があるのか、調べてみることにしました。


処理の中身

簡単に試したいだけだったので、数行で済む程度のごく簡単な処理を書いてベンチマークすることにしました。


1. 引数で渡されたJSONをパースして、中身を表示する

2. DynamoDBから1件のデータを取得する


当初は1だけだったのですが、あまり性能に差が出なかったので2を追加した感じです。そんな経緯のベンチマークなので、実装も雑ですが、とりあえずソースをGitHubに置いておきました。

https://github.com/cero-t/lambda-benchmark


実行結果
回数Java(1)Java(2)Node.jsGo
1回目218006700900600
2回目13007300800500
3回目19000500200500
4回目10001300200400
5回目500200400500
6回目400100200500
7回目400300400500

時間はいずれもミリ秒のBilled duration。


Java(1) : メモリ192MB。処理中にAmazonDynamoDBClientを初期化

Java(2) : メモリ192MB。処理前に(コンストラクタで)AmazonDynamoDBClientを初期化

Node.js : メモリ128MB

Go : メモリ128MB


メモリの実使用量は

Java : 68MB

Node.js : 29MB

Go : 15MB

でした。


考察など

正味の話、Lambdaで行っている処理などほとんどないので、性能的には大差ないかと思っていたのですが、思ったより特性が出ました。これは処理時間というよりは、関連ライブラリのロード時間な気がしますね。


Javaは最初の数回が20秒、実装を改善しても7秒とかなり遅かったのですが、ウォーミングアップが終わった後は200msぐらいまで早くなりました。呼ばれる頻度が高い処理であれば良いのでしょうけど、たまに呼ばれるような処理では、この特性はネックになる気がします。


ちなみにJavaだけは192MBで計測しましたが、最初にメモリ128MBで試したところ、30秒ぐらいで処理が強制的に中断されたり、60秒でタイムアウトするなど、計測になりませんでした。こういう所を見ても、Javaを使う時にはメモリを多め(CPU性能はメモリと比例して向上)にしなくてはいけない感じでした。


Node.jsも少しはウォーミングアップで性能が変わりますが、最初から性能は良い感じです。


Goを使った場合は性能が安定しており、ウォーミングアップしても性能が変わりません。メモリ使用量が少ないのも良いですね。Node.jsから呼び出す際のオーバーヘッドがあるせいか、性能的にはウォーミングアップ後のJavaやNode.jsに一歩劣る感じでした。


なお、Pythonの実装をしてくれる人がいらっしゃれば、プルリクしていただければ、データを追加したいと思います。


結論

繰り返しになりますが、雑なベンチマークなので特性の一部しか掴んでないと思います。

そもそもJavaだけメモリが1.5倍になっている(=CPU性能も1.5倍になっている)ので公平ではないですし。


ただ「たまに行う処理」を「少ないリソース」で行うという観点では、Goで実装するのが良さそうです。GoはそのうちLambdaでも正式サポートされそうですしね。

きちんとしたベンチマークは、また別の機会にじっくり行ってみたいと思います。


ということで、Goを使う大義名分ができたベンチマークでした!

See you!

2014-12-14

[][]MyBatisをやめて、JdbcTemplateを使うわ。

以前のエントリーで、DBアクセスにはMyBatisを選んだと書きました。

http://d.hatena.ne.jp/cero-t/20141212/1418339302


そしたら渋谷JavaのLTで @ さんに拾ってもらっちゃいました。

http://www.slideshare.net/yukung/j-ooq-shibuyajava9


そんなこともあってMyBatisイチオシなエンジニアに思われたかも知れませんが、

ごめんなさい、

あの記事はあくまでも伏線で、僕、もうMyBatis使ってないんです!


MyBatisを使って半月ぐらいして、

どうにも我慢できなくないことが出てきました。


1. Spring Bootとの連携がイマイチ

Spring BootでMyBatisを使おうとすると、

前回のエントリーで書いた通り、ちょっと設定ファイルが必要になったり、

その設定ファイルの読み込みに失敗して、謎の無限ループが起きることがあるなど、

やや不可解なことがあります。


設定ファイルの問題というなら、設定ファイルを使わず、

ソースコードだけで設定できれば良いのですが、その方法も、結局よく分かりませんでした。


まぁMyBatisAutoConfigurationとかができてからが本番というか、

ないなら自分で作るゾ、ぐらいの勢いで挑む必要があるように思いました。


2. XMLにSQLを書くと、インデントががが。

じゃぁMyBatisAutoConfigurationを作れば良いわけですが、

そういう気になれなかったのは、やっぱり、

XMLファイルにSQLを書くのが嫌だったから、でした。


だって、標準的なフォーマッタでフォーマットした瞬間、

インデントが全部消えるじゃないですか。


自動フォーマットをこよなく愛する僕としては、

フォーマットする手段がないというのは、いただけませんでした。


3. そこでJdbcTemplateですよ

じゃぁ何を使ってるのか?

で、結局、Springに標準でついているJdbcTemplateを使っています。


無設定で使えて、値のバインドは適切にできて、

NamedParameterJdbcTemplateならSQLに変数が使えて、

Entityにはアノテーションとか付けなくて良くて、

余計な機能はなくて、シンプルに使える感じでした。


ただ、もちろん、JdbcTemplateも欠点だらけです。

 ・publicフィールドに対応していない

 ・Java8のLocalDateなど、Date and Time API (JSR-310) に対応していない

 ・RowMapperを求めるAPIになっているなど、APIに古くさいものが混ざっている

 ・そもそも、SQLファイルを読み込む機能なんてない!


なので、これらを補うような

独自ラッパーでラッピングして使うことにしました。


詳しい紹介はまた改めて書くとして、モノはここに置いています。

https://github.com/cero-t/sqltemplate


独自ライブラリではなく、Spring標準のJdbcTemplateを

ちょっとだけラッピングして使っているだけなので、

政治的な意味で使いやすいかな、と思っています。

2013-10-02

[]俺様とJavaOne 2013(後編)

いよいよJavaOne最終日です。

最終日はCommunity Keynoteと、いくつかのセッションを行なうだけで

夕方ぐらいには閉幕してしまいます。


Day 5 : 子供のプログラミング、どうしていますか?

Community Keynote

最終日、最初のセッションはコミュニティキーノート、

かつては、Gosling's Toy Showなどが行なわれていたイベントですね。

このキーノートで日本の皆さんにお伝えしたい事は、ただ一つ。


#てらだよしお が、Tシャツを投げていました!


あぁ、写真とか撮ってないです、すみません。

たぶん誰か撮ってます、そっちに期待してください。


私の席からは見えませんでしたが、James GoslingもTシャツを投げていたそうなので

この瞬間、てらだよしおはJames Goslingに匹敵するエンジニアだった、ということですね!


それはさておき、

このコミュニティキーノートで一番印象に残ったのは、教育の話です。

10〜14歳の子供を対象にしたDevoxx 4 kidsというイベントの様子が紹介され、

子供が「やった、動いた!」などと言いながら、プログラミングを楽しんでいました。


また、会場にはArun Guptaの10歳の息子、Aditya Guptaが登場して、

Minecraftというゲームをハックした時の考え方などを紹介しました。

「これはEclipseという開発環境で」「左側のソースファイルの一覧があって」などと

10歳の子供が説明するだけで会場は大盛り上がりなのですが、

恐らく、彼自身はなぜ会場が盛り上がっているのか分からなかったに違いありませんw


10歳の子供が、数千人(?)の大人を相手に、

大して緊張する様子もなく、声を震わすこともなく、説明しきった様子は圧巻でした。

会場のスタンディングオベーションも、決して過大評価ではなかったと思います。

本当に素晴らしかったです。


Devoxx 4 kidsの動画や、Aditya Guptaの発表を見るにつけ、

同世代の子供を持つ親としては、そろそろ子供に楽しいプログラミングを

教えてもいいかな、という気持ちになってきましたね。


私自身、プログラミングを始めたのは、この年代だったと記憶しています。

一つの素養として身につけるには、決して早くない時期でしょう。


今度、科学未来館に行って、プログラミングできるおもちゃを買ってくるかな。


[CON4695] Java Memory Hogs

OracleのNathan Reynoldsによるセッション。

Keynoteが終われば帰る人も多い中、部屋は満席で立ち見が出るほどでした。

やっぱりメモリ系やGC系セッションは人気があります。


本当はこの前にいくつかのセッションを入れていたのですが、

Community Keynoteの後にJames Goslingとの記念写真撮影に並んでいるうちに

予約していたセッションが満席になってしまったり、

ランチで少し遠目に出ているうちに逃してしまったりなどして、

最終日のセッションはこれ一本になりました。てへぺろ。


さて、

このセッションのテーマはJOverflowを使ったヒープメモリの診断です。

というかJOverflowって、ただのヒープダンプを解析できるだけではなくて、

無駄なヒープの使い方を指摘する機能まであるんですね。いいですねこれ。


このセッションでは、実際のJavaEEアプリケーションのヒープダンプを取り、

それをJOverflowで診断して検出した問題について、改善方法や結果が示されました。


たとえば英数字しか入らないStringをcharではなくbyteで保持したら

7%ぐらいメモリ効率が上がったとか

同じ文字列のStringがたくさん重複していたからString.intern()で改善したとか

空の配列やCollectionがたくさんあったからLazy初期化するようにしたとか

そういう話です。


このセッションを通して感じたことは

「JOverflowは、ヒープダンプのFindBugs」だということですね。


たとえば空のCollectionがたくさんあるとか、

同じ文字列のStringの重複がたくさんあることなどは、

理論上は「減らせば良い」わけですが、Lazy初期化やinternを使った処理を書くとなると

パフォーマンスへの影響や、可読性の低下(処理の複雑化)は多少なりあるため

なかなか全ての場所で、理論通りにコーディングするわけにもいかないと思います。


その点、JOverflowを使い、実際に動かしたアプリケーションのヒープダンプを解析することで

「本当に問題になるところ」が分かるため、実際的に改善すべきポイントを掴めるわけです。

このアプローチ、まさにENdoSnipeと同じですね!(←これが言いたかったの?)


大事なことなのでもう一度言いますが、

「JOverflowは、ヒープダンプのFindBugs」です。

ぜひ試してみましょう。


JavaOne 2013最後のセッションでしたが、かなり面白い内容でした。


JavaOneを終えて、最後に。

そんなわけで、これでJavaOne 2013は終わりです。


今年のJavaOneで一番印象的だったことは、

もちろん私自身が初めてスピーカーを務めたことですが、それを除けば、

子供へのプログラミング教育の話でした。


同世代の子を持つ私としては、

Devoxx 4 kidや、10歳のAditya GuptaによるCommunity Keynote発表などは

非常に印象的でワクワクすると同時に、負けていられないという気持ちになりました。


一方で、Javaも転換期に来たのかな、という印象もありました。


少し話はそれますが、

先日、「教育」に関する有名ブロガーのつぶやきが話題になりました。

人が教育の話をしはじめるのは、自分の成長に限界が見えた時、

要するに「自分の成長よりも、後進の成長のほうが価値がある」と考えるようになった時だ、

というアレです。


この話も踏まえると、このJavaOneで「子供の教育」の話がなされるというのは

多くのJavaの開発者たちが、あるいは、Javaそのものが転換期に来た、

悪く言えば「焼きが回った」ところにさしかかったのかな、という印象になったわけです。

いや、たぶんに感覚的な話なんですけどね。


また、今回は新しい情報がほとんどないJavaOneでしたが、

個人的に(弊社的に)言えば、Flight RecorderやMission Controlの

裏側の仕組みや、今後目指すところを聞いたことで、

ENdoSnipeの開発も改めて頑張ろうという気になりました。


ENdoSnipeを、Duke's Choice Awardをとれるぐらいの秀逸なプロダクトにしたいなと、

そんな大きな野望を持ちながら帰国の途につきました。


よし、頑張ろう!