2014年3月20日木曜日

曲の再生


Androidで音楽再生をしていて一番最初に気になったのが再生中に途切れることでした。
youtubeや動画再生では途切れることが無かったので何故だろうと直接的な原因がはっきりしません。

一般的な概念から整理すると、音の再生は無圧縮状態で高ビットレートにすればするほど負荷が高くなりストレージやメモリー転送レートの限界を超えると基本的には音飛びや途切れが発生します。
圧縮されているものでは高ビットレートにすればするほど負荷が高くなるのは当たり前なのですが、圧縮されている分ストレージなどの補助記憶装置からの転送レートを超えることができます。
しかしながら展開アルゴリズムがハードウェアレベルで実装されていない場合や複雑なアルゴリズムが必要な場合はそれなりの展開時間がかかるようになります。
ハードウェアやソフトウェアで展開アルゴリズムを実装する場合にはある程度の誤差や機能を切り捨てて高速化する手法が取られることも少なくありません。

ソフトウェアレベルの話になると、短時間(数秒もの)の再生以外は物理的にメモリー上に再生バッファを持ってそこから再生するわけですが、この再生バッファの大きさが足りない状況では簡単に再生の音声が途切れることになります。
再生バッファの大きさはOSの制約やハードウェア、ドライバに依存する部分が高く、一般的に普通に使っていて音切れや音飛びが発生する場合は使用時の処理負荷が高くなった時に発生しやすくなります。

こんなところが一般的な話ですが、Androidの話に戻すと音声ファイルの再生に関して一般的な再生コーディックは大抵ハードウェアレベルで実装されているようですが、機種によりさまざまな実装が行われているようです。
ハードウェアで実装されていない場合はソフトウェアによる実装しか方法は無いのですが、どうもWindowsのようなコーディックを単純にインストールすれば再生できるようになる訳ではないようで再生アプリケーションに頼るしかないようです。

最初タブレットで音声ファイルを再生しようとした時に、タブレットではほとんど手持ちのwmaファイルがほとんど再生できなく、あきらめてファイル形式を変換するしかないのか?というところから出発しました。
あきらめているさなかに、試しに携帯で再生してみるとそのまま再生できることがわかりました。実際に再生ができるようになると、今度は再生中の音切れが気になりだしました。
様子を見ながら再生していると、だいたい1~2分で1回音切れが発生する感じでした。一曲5~6分のものが多いので一曲あたり2、3回発生することになります。
(実はこの手の再生時の音切れはWindows Mobileでも発生することがありました。S21HTでOSのアップデートやパッチで頻度は減るようになったもののどうしても音切れがあり、その際に標準のプレーヤではなくTCPMP(The Core Pocket Media Player)を利用した経験があります。
さらにそれ以前ではHPのPDAでWindows Mobile 2003 Second Editionでは最初はまったく問題が無かったのですが、ファームウェアアップデートでOSのバージョンを上げた後、音楽再生で音切れが発生するようになったり、再生が途中で止まるようになったりといろいろと不具合がありました。)

ようやくここでAndoroidでもこの手の問題が一般的で、みんなは標準的なプレーヤーを捨ててメジャーなアプリで再生しているのかもしれないと考えるようになりました。(今更的な発想ですが(笑))

いろいろと検索したり試した結果、やはりプレーヤーをかえるといくらかましになるものもはありましたが、なかなかきれいに再生してくれるようなものは見つかりませんでした。
Windowsで有名なWINAMPがその中でも結構軽く作られているようでよかったのですが、音切れがなくなることはありませんでした。(しかも見つけたときはちょうどAndroid版の開発中止が発表されました)

ほとんどのプレーヤはUI部分のみ作成されていて肝心の再生部分はAPIレベルでの再生を行っているだけのものが多く、ハードウェアで実装されていない圧縮形式のファイルを利用することはできません。
どうせならタブレットでも再生できるものが無いのか調べて見るようになり、ソフトウェア側で直に圧縮されたものを展開しているものはないかと探してみました。
そして見つけたものがVLCというものでした。VLC自体はオープンソースのようでいろいろなバイナリーがリリースされているようで、私が利用しているものはVLC for Android v0.1.4というものです。
確かにタブレットでもwmaファイル(可変圧縮のもの)でも再生できるようになりましたが、残念なことに音切れどころか再生直後から音が飛でしまいとてもガッカリしましたが、設定項目を見ていくうちに高度なデバッグ→オーディオ出力という項目が目に付きました。
説明に「オーディオ出力に使用するメソッドを変更します。」とあります。
実際に見てみると
  • AudioTrack(Java)
  • AudioTrack(ネイティブ)
  • OpenSL ES
と3種類の出力方法があるらしく、最初は「AudioTrack(Java)」になっているのですがこれを「AudioTrack(ネイティブ)」に変更したところ劇的に再生がスムーズになりました。


音楽再生は現在でもこのVLCをメインで使っています。

しかしAndroidは見えないところでアプリが頻繁に入れ替わり立ち代り起動しているのでインストールしているもので足を引っ張るものが数多くVLCを使っていても音切れは発生してしまいます。

原因はAndroidの仕組みがそうなっているので仕方がない部分もあるようですが、できる限りスムーズに再生してくれるものがあるといいのですが。
Androidのバージョンもどんどん上がっているので上位になれば改善するのでしょうか?

2014年3月18日火曜日

バッテリー情報

先日(もう2週間ほど前になるのだろうか?)枕元でタブレットの電源が切れている状態で朝を迎えていた。

充電ケーブルはつなげたままなのに…。

電源を入れたところほぼ電池は空の状態。

いくつか原因を考えてみるものの
・物理的なバッテリーの故障
・電源供給の問題(ケーブル破損やアダプタなど)
・加熱によりる充電停止

電源供給はそのまま充電ができていたので問題が無い。
そもそも充電停止が行われるかどうかもわからないが、電源ケーブルがつながっているのに放電状態でそのまま落ちてしまうのだろうか?

システムログも見れないし、これといって具体的な調査もできなかったがその後どうも充電がおかしいようなきがしてならない。
いままでは使いながら結構早く充電できたのにいまはあまりにも充電時間がかかるように感じるのと下手をすると電源ボタンを押してスリープ状態にならないと充電されないような感じになっています。

表示上だけの問題なのか、インストールしているアプリが悪さをしているのか判断もできないのでまずはバッテリーの情報を見ながら様子を見ていたのですが、もう少しハードよりの情報が見たいのでアプリを作るところから始めてみました(笑)

どこのブログでも大抵「いまさら」とか、「この程度のもの」とか書いてありますがAndroid初心者にとってはまったく見当もつきませんでしたが、確かに情報を受け取ってデバッグ環境でデバッグログに表示するだけならソースも単純でそのまま動きそうでしたが、画面に表示させるだけなのにいろいろと壁がありました。

レシーバーを定義してその中でアクティビティー上に表示させる方法が最初に悩んでしまいました。
いろいろなソースを見て試して見ましたが、レシーバーに対してアクティビティーを保持させておくのが一番しっくり行ったのでその方法で実装しました。
アクティビティーのライフサイクルの中にだけレシーバーが存在させるのが負荷も少ないだろうというのが一番大きかったのかな。

表示上では単純なリストビュー表示がいろいろと試行錯誤を繰り返すことに…。
思想の違いはいろいろありそうなもののWindowsなどのものとさして変るわけではなかったのが救いですが、その定義の仕方がまったくわからない。そしてちょっと欲を出してアイコン表示やレイアウトに手を入れてみようかと試行錯誤しましたがあまりにも上手く行かないのであきらめました(笑)

最後はローカライズを試してみようとまったく明るくない中国語のローカライズもやってみました。グーグル翻訳と他の日中辞典サイトを使いつつなんとか翻訳。
そもそも中国語が大きく分けて2種類あってどうせなら台湾の方が見ても解るようにと思ったものの、どっちだ?というところから始まりました。そのぐらいまったく中国語知らない。

そんな試行錯誤した結果がこちら


このアプリはこちらからダウンロードできます。PlayStoreじゃないので設定が必要ですが何の権限も不要です。(需要はなさそうですが(笑))

いろいろと渡り歩いている最中にdelphiでandroidアプリを作ると面白そうだなぁとは思ったのもの、仕組み的にいろいろと面白そうなことになってそうでした。

2014年3月17日月曜日

Playストアの表示バグ

Android端末を使い始めてから最初の頃から気になっていたPlayストアの表示バグ。
画像が非同期で表示されるのでスクロールさせている間に表示すると画像だけ表示されないバグが一向に治る気配が無い。

この手の表示バグは初期の頃のWindowsアプリケーションでも多かったが、Androidはまだまだ発展途上ということでしょうか?(笑)

最初は安いタブレットなのでグラフィックスドライバ絡みのバグかとも思ったのですが、スマホでも発生するのでおそらく画面再描画処理のInvalidateが上手く行ってないだけなのだと思います。
憶測ですが、ダウンロードスレッドからのViewへの再描画処理内でpostInvalidateされていないだけのような気がします。

処理負荷から考えればできる限り再描画範囲は限定されるべきで必要以上の再描画は行わないに越したことが無いのですが、表示されないのは非常に使っていて気になってしまいます。

ビルドバージョン バージョン: 4.6.17

2014年3月4日火曜日

メモ:なぜか未来日(2022年)で存在したPicasaのアルバム

いつも写真で特定のアルバムだけが一番最初に表示されていて気にはなっていたのですが、昔にPicasaにアップロードしたものが未来日付でアップされていたためだったようです。
日付の変更ができたらよかったのですが、できないようなので一度ダウンロードして再度アップロードしなおして今日の日付になったのでめでたしめでたし?
そのまま削除してもいいのですが、資料をスキャンしたものなのでどこからでも見れると便利なものなので。

他に方法があるかもしれないのでメモとして記録…他の方法があるといいけれど。

chrome

いつからかは覚えていないが、気づいたらchromeのスクロールがおかしくなっていました。
chromeはほとんど使っていないのですが、やはりそれでも気になるこの不具合。
chrome://flags ですこし試してみた範囲では何も変らず。結局この症状の発生するタブレットではアップデートを削除してプレインストールのバージョンまで戻して回避するしかなさそうです。

スマホで撮影して比較してみました。
Chrome 28.0.1500.94 1500094
OS: Android 4.1.2
ビルドID: d04997a8-846b-4ed0-8470-2ce21d63f4f0

Chrome 33.0.1750.136 1750136
OS: Android 4.1.2
ビルドID: 582969eb-6f20-4ee1-88f2-8252611c1e60

撮影はスクロールしかさせてませんが、現象として、スクロールや拡大/縮小などの画面更新の補完処理がうまく行われていない様子です。

古いタブレットは使うなということでしょうかねw