VirtualBox上のDebian GNU/Linux xfceでUSBオーディオインターフェースを使う方法

先日、steinberg UR22mkIIと、Roland Rubix22をdebian GNU/Linuxで検証する際、VirtualBox上では音が出なかった(正常にオーディオデバイスとして認識はされているが・・)という事を記しましたが、実機では簡単に動作するものがVirtualBoxではダメという結果に納得が行かないので深堀り調査してみる事にしました。

調べた結果原因がわかりました。Windows 10上のVirtualBox 6.1上で動かしたdebian GNU/Linuxで、steinberg UR22mkIIとRoland Rubix22がきちんと動作する方法が判明しました。

私が疑念を持ったのは、VirtualBoxのUSB認識に原因があるのでは無いか?というところでした。そしてそのモヤモヤが的中し原因はUSBポートの問題だったと判明した訳です。

調査方法

debianでUSB認識を確認(lsusb)

実機上のdebianとVirtualBox上のdebianとで【lsusb -t】コマンドを使って認識状態を確認してみました。大きな違いに気づきました。

きちんと動作しない環境での認識状態

$ lsusb
Bus 001 Device 003: ID 0499:170f Yamaha Corp.
Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

$ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/12p, 12M
|__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 2: Dev 3, If 0, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 2: Dev 3, If 3, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 2: Dev 3, If 1, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 2: Dev 3, If 2, Class=Audio, Driver=snd-usb-audio, 12M

UR22mkIIとRubix22から音が出ないVirtualBox転送速度は12M(USB1.1)と遅い様です。

きちんと動作する環境での認識状態

$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root Hub
Bus 001 Device 003: ID 0499:170f Yamaha Corp.
Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablete
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 480M
|__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 2: Dev 3, If 0, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 2: Dev 3, If 3, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 2: Dev 3, If 1, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 2: Dev 3, If 2, Class=Audio, Driver=snd-usb-audio, 480M

音が出る実機では480M(USB2.0)で接続されていることがわかります。

“VirtualBox上のDebian GNU/Linux xfceでUSBオーディオインターフェースを使う方法” の続きを読む

高知県Go To Eat券対象店リストをCSVで取得~Windows環境にPython3.7 Jupyter Labをインストール

GW連休のため自宅に帰ってきてます。じっくり腰を据えてPythonの学習をしようと思ったらPCデスクに置いてあるWindowsパソコン(デスクトップ)が一番快適なので、WindowsパソコンにAnacondaをインストールしてJupyter Labを使えるようにしました。Anacondaはオールインワンな感じで便利です。

ほぼ半日かかった学習(作業)になったので、きちんとした机と椅子に座って作業できるようにしたのは正解だったかなと思っています。

今回のターゲットは、高知県のGoToEat対象店の一覧をCSVで取得することです。

公式サイトはページ分割されているのでいちいちページを繰って行くのが面倒です。ExcelやGoogleスプレッドシートを使い慣れているとなんかまどろっこしいんですよね。

ただ、スクレイピングは情報提供元のサーバーに負荷をかける場合があるので、なるだけ少ない回数で成功させなくてはなりません。最小限の負荷で一巡させてもらうつもりで解析をしつつPythonスクリプトを作っていきます。

“高知県Go To Eat券対象店リストをCSVで取得~Windows環境にPython3.7 Jupyter Labをインストール” の続きを読む

今日さくらVPS環境がアップデートされたらしい〜完了の通知が来ないけど大幅なメンテが行われたみたいだ

昨年10月頃にさくらインターネットからメールが届いて、システム老朽化に伴い数ヶ月先に大規模なシステムメンテナンスを行うと知らされていました。私が借りているVPSは「大阪リージョン」なのですが、今日(2021/03/15)「論理移設事前作業」が行われるとのことで、念の為お昼前にシャットダウンしておきました。

予定時間は14:00〜17:00と知らされていたので17:30頃にVPSを起動してブログシステムも再開させることになりました。当サイトでは、だいたいお昼のアクセスが多いのですが、今日に限っては接続エラーとなっていたハズです。そういう訳で今日はアクセス数も少ないです。

しかしその後、作業が終わったというメールも届かないし、本当に作業が行われたのかどうかは不明です。VPSコントロールパネル内のお知らせにも掲載されていないし。本当に作業が行われたのだろうか?

探してみたら見つかりました。どうやら無事に作業は終わっているみたいです。

“今日さくらVPS環境がアップデートされたらしい〜完了の通知が来ないけど大幅なメンテが行われたみたいだ” の続きを読む