今回はDockteckの「7-in-1」USB TypeCハブのレビューです。 本来ならばMacBook Airで使うつもりだったのですが、Macより先にこれが届いてしまったので、スマートフォンで動作確認しました。 このハブはAmazonで購入しました。タイムセール中に購入したので、価格はおよそ3900円でした。 外観はこんな感じです。Macでいうスペースグレイとほぼ同じ色をしています。 ポートは7つあり、左側から、LANポート、TypeC入力端子(給電専用)、USB3.0 TypeA × 2、SDカードスロット、microSDカードスロット、HDMI端子となっています。 TypeC端子は通信機能は持たずホスト機器への給電専用となっています。この端子は、ホスト機器を充電しながら使うだけでなく、USBハードディスク等消費電力の大きい機器を繋ぐときに、補助電源として機能します。なお、このハブが常時8W消費するので、65Wの充電器を繋いだ場合実質ホストに供給されるのは57Wとなります。 ハブで使用されているチップはVIAの統合チップです。おそらくSDカードリーダーやイーサネットアダプタが内部で接続されています。 まずはLANポートが使えるか確認してみます。 USBイーサネットに対応しているXperia 5を検証に使いました。 ルーターとは1Gbps (1000BASE-T)で接続しています。 無事認識されました。 LANケーブルを挿した状態でハブを接続したとき、認識までは5秒程度かかりました。 事前にハブを接続しているときは1秒もかかりませんでした。 スピードテストをしてみました。 ・・・？ 普通だと700Mbpsぐらい出るのですが思うように速度が出ません。「もしかしてXperia 5ってUSB2.0までの対応なのか？」と思いましたが、USB3.1対応らしいです。これは怪しいですね。簡素な設計でギガビットイーサネットの速度が活かせていないようです。 テスト中pingの値が200msまで上がることもあり、チップが弱いのか相性なのか・・・。そこまでは分かりませんでした。 ちなみに、USBイーサネット変換にASIX AX88179Aというチップを使用しているようです。これ自体はギガビット対応なのですが、エントリーモデルだからでしょうか。ただ、まだXperia 5が原因である可能性は否定できないので、MacBook到着後改めて検証します。 それに、驚きなのは通信ランプがかなり眩しいことです。なぜか白色LEDです。 商品説明だと、お馴染みの緑色LEDになっています。ここら辺が中華っぽいところですね…。 他の端子についても検証しました。 USB端子は問題なく動作しました。2つのポートにUSBメモリを挿して、全部使った状態でも不安定になることはありませんでした。 USBポートは3.0までの対応となっており、最大5V 1.6Aまで供給できるようです。 SDカードスロットも問題ないようです。 HDMIは認識しましたが480pでしか使えませんでした。謎です。これもXperia 5との相性問題があるため、MacBook到着後にもう一度検証します。 総合評価としては「△よりの◯」です。まだあやふやな部分があります。検証結果に変わったことがあれば記事を更新したいと思います。 Amazonでのご購入はこちら→ https://amzn.to/3bcFmeE

前回に続きsndcpy関連の話です。 sndcpyのサーバーは、ソースコードを読むと分かるように複数クライアントの接続を想定していません。 そのため、録音しながらモニタリングできないのです。ならば複数接続できるようにしてやろう、ということでPythonでTCPサーバーを作ります。 仕組み まず、すべてのクライアントに同じデータを送信する必要があります。 1つの変数にデータを入れていって、各クライアントを処理するプロセスがそれを読み取ればいいのではないかと考える方もいるかと思いますが、それだと矛盾が起きたり後にバグに繋がる可能性があるので、クライアントごとにキューを持たせ、sndcpyのサーバーからデータを受け取ってそれぞれのキューに入れていくようにします。クライアントに配信するプロセスは自身のキューを読むだけで済むのでバグの原因になりにくいです。 実装 まずsndcpyのサーバーに接続します。 sndcpy = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sndcpy.connect(('localhost', 28200)) threadingを使ってバッググラウンドでキューに貯めていってもらいます。 queuesという配列に入っているクライアントに全部入れています。 queues = [] stopFlag = False def data_queue(): while not stopFlag: data = sndcpy.recv(1024) for q in queues: q: queue.Queue = q['queue'] q.put(data) data_queue_thread = threading.Thread(target=data_queue) data_queue_thread.start() stopFlagを用意しているのはプログラムが完全に止まるようにするためです。 スレッドが動いているとメインプログラムが終了してもいつまでも全体が止まりません。Ctrl+Cでも止められなくなります。 次にキュー管理用の関数を作ります。 def create_queue(): qid = str(uuid.uuid4()) d = {'queue': queue.Queue(), 'id': qid} queues.append(d) return qid def get_queue(qid): for q in queues: if q['id'] == qid: return q def delete_queue(qid): for q in queues: if q['id'] == qid: queues....

この記事は前回の「Androidで劣化無しでデジタル録音！「sndcpy」を使う」に関連する記事です。 前回、sndcpyはデフォルトでサンプリング周波数が48kHzに固定されていると書きました。今回は自由にサンプリング周波数を変えられるように改造してみます。他の部分にも手を加えていきます。 なお、この記事は専門的なものを取り扱うので少し難しいかもしれません。ソースコードは https://github.com/rom1v/sndcpy にあります。Javaで書かれており、Android Studioでビルド可能です。 早速改造していきます。 サンプリング周波数の設定はRecordService.javaの43行目で定数として定義されています。 private static final int SAMPLE_RATE = 48000; 定数のため、このままだと宣言後に再代入できないので、finalを消します。 private static int SAMPLE_RATE = 48000; 次に、amコマンドでIntentとして値を渡せるように改造します。 このアプリは、まずアプリの起動時(onCreate())に権限確認をしていて、権限があることを確認してからonActivityResult()の中でサービスを開始しています。その部分がMainActivity.javaの49行目、53行目～60行目となります。 サービスを開始する際はRecordServiceのstart()を呼び出していて、その時にIntentも渡しているので、そこにサンプリング周波数の情報も入れます。 data.putExtra("SAMPLE_RATE", mSampleRate); RecordService.start(this, data); RecordServiceのstart()ではIntentからサンプリング周波数の情報を取り出してSAMPLE_RATEに代入します。 private static int SAMPLE_RATE = 48000; private static int SAMPLE_RATE_REAL = 0; //... public static void start(Context context, Intent data) { SAMPLE_RATE_REAL = data.getIntExtra("SAMPLE_RATE", 48000); SAMPLE_RATE = SAMPLE_RATE_REAL; Log.d(TAG, "Current SAMPLE_RATE is " + SAMPLE_RATE + " Hz"); //... } SAMPLE_RATE_REAL に代入しているのは実装上の都合です。この変数はSAMPLE_RATEと同様に定義します。 getIntExtraの第2引数にはデフォルト値が指定できるので、何も指定されなかったときは48kHzにしています。...

注意: sndcpyはAndroid 10以降で使えます。 たまにゲームの音楽などを録音したくなるときがあります。画面録画で簡単にできますが、Androidの標準機能だとモノラルになったり、サードパーティのアプリを使ってステレオで録音できたとしても、音が圧縮されているので音質が悪かったりします。 こういうのは音に敏感な自分にとって許せないので、簡単にかつ高音質に録音できる方法はないのか探っていました。 一番手っ取り早いの方法としてアナログケーブルで繋いで録音するというものがありますが、現代のPC、とりわけノートパソコンではLINE IN端子がないためこの方法が使えるのは限定的です。自分は入力端子付きのPCがあるためできなくはないのですが、メインPCではないので操作が面倒です。 もう一つの方法として、sndcpyというツールを使ってネットワーク・USB経由でデジタル録音する方法がありますので、紹介します。 sndcpyとは sndcpyは、rom1v(Romain Vimont)さんによって作られたフォワーディングツールです。 以下の図のような構成で音をPCで聴けるようにしています。 sndcpyのサーバーがAndroid上で動作し、ADBのトンネルを経由してPC側で再生します。 ダウンロードと準備 sndcpyを使うにはVLCが必要です。 https://www.videolan.org/vlc/index.ja.html からダウンロードしてインストールします。 sndcpyの最新バージョンは https://github.com/rom1v/sndcpy/releases からダウンロードできます。 sndcpy-v◯.zip はsndcpy単体で、sndcpy-with-adb-windows-v◯.zipはADBが付属しています。 まだADBをインストールしてない場合は後者をダウンロードしたほうがいいかと思います。 解凍するとsndcpy (Linux用シェルスクリプト)、sndcpy.apk (Androidにインストールする用のパッケージ)、sndcpy.bat (Windows用バッチスクリプト)が入っています。 使ってみる あらかじめadb connectなどのコマンドを使ってAndroid端末と接続します。 ※Android 11からはワイヤレスデバッグが使えます コマンドプロンプトなどを開いて .\sndcpy.bat と入力すれば、端末にsndcpy.apkがインストールされてサービス起動します。 数秒後に再生が始まります。音楽を流してみたり、ゲームを起動するとPCで音が流れるはずです。 通知欄にはsndcpyが常駐しています。「STOP」をタップすると止まります。 WindowsではCtrl+Cで止められないので端末側から止める必要があります。 聴くだけであれば、今のようにADBで繋いでバッチスクリプトを起動するだけでOKです。 録音する 実は、sndcpyの仕組みとしては端末側でサーバーを立ち上げてUNIXソケットをPC側のTCPポートにフォワーディングして、VLCを起動し再生する、という操作をスクリプト化しているだけなので、これを応用すれば録音が可能です。 sndcpyが端末にインストールされている前提で作業を進めていきます。 バッチスクリプトを読んでいくと、まず最初にフォワーディングの設定をしています。 %ADB% %serial% forward tcp:%SNDCPY_PORT% localabstract:sndcpy || goto :error %SNDCPY_PORT% は行頭で宣言されており、デフォルトで28200になっています。PCからは、localhost:28200でアクセスできるということになります。 普段使うときはこのコマンドラインを使います。ポートは28200に固定しています。 adb forward tcp:28200 localabstract:sndcpy さらに読むと、端末側にインストールしたsndcpyのサービスをadb経由で起動させていることがわかります。 これは接続を切断するごとに実行する必要があります。切断するといちいちサービスが停止してしまうようです。 %ADB% %serial% shell am start com.rom1v.sndcpy/.MainActivity || goto :error 普段使うときはこうします。...

AndroidでWi-Fiアナライザーなるものはたくさんありますが、その中でも細かい仕様が覗けるいい感じのアプリがあったので紹介します。 analitiというアプリがおすすめです。 アプリはGoogle Play ストアに公開されています。 このアプリの使い方について説明していきます。 使い方 権限付与（初回のみ） アプリを起動すると権限を付与するように求められます。 「I’LL GIVE MY PERMISSION」をタップして、「アプリの使用中のみ」を選んで許可します。 トップ画面 アプリを起動するとまずこの画面がトップで表示されます。最初に表示する画面は設定の「Launch Activity」から変更できます。 IPアドレスがもろに表示されているのでスクショするときは注意が必要です。 WiFi Networks 一番下のメニューから「Networks」を選ぶと表示される画面です。 スキャンで検出されたアクセスポイントが記録されていきます。リストはアプリを閉じるまで保持されます。 ↓↑マークは現在接続しているアクセスポイントであることを意味します。 この画像でAC1733となっている部分は、ルーターの性能によって変わります。802.11acで最大リンク速度867MbpsのルーターならAC867に、802.11axで最大リンク速度4804Mbpsの場合はAX4804となります。 MACアドレス部分をタップするとそのアクセスポイントの詳細情報を見ることができます。 Nowは現在のリンク速度、Signal Capabilityはルータが提供可能な最大リンク速度、(デバイス名) Capabilityは端末が対応する最大リンク速度を指します。 Phy Technologiesでは、このアクセスポイントの場合 11ac 最大1733Mbps (AC1733)、11n 最大600Mbps (N600)、11a 最大54Mbps (a54)に対応していることが分かります。 SU-MIMOとMU-MIMOはアンテナの数と思って構いません。受信x送信 の形式で書かれています。このルータはそれぞれ4本搭載していることが分かります。MU-MIMOは対応している場合のみ表示されます。 MCS Indexは、その数値に対応するバンド幅・伝送レート・変調方式の情報を指します。インデックスの対応表は https://mcsindex.com/ で見ることができます。 スクショでは見えていませんが、Associated client stationsはそのアクセスポイントに接続している端末の数を指しています。この数値はメーカーによって見えたり見えなかったりします。未認証でもスキャンした時点で見えます。 WiFi Signals List この機能へはハンバーガーメニューからアクセスできます。 WiFi Networksとほぼ画面は変わらないのでスクショは貼りません。 一定間隔でスキャンしていってその時検出されたアクセスポイントだけが表示されるという点が異なります。 Handover Analyzer 信号強度、リンク速度、GoogleへのHTTP pingの値をリアルタイムグラフで見れる機能です。 注意点 端末のチップセットやOSのバージョンによっては表示される情報が少ない場合があります。 おわりに とても細かいところまで見れるので重宝しています。 街中のアクセスポイントを観察してみたりして、「11ax対応で4804Mbps対応なのすご！」とか勝手に自分ではしゃいでたりします。ちなみに、まだ2.4GHz帯で11nを使っているところが多いみたいです。そのようなバンドの普及度も気にしながらぜひ見てみてください。