Roland DUO-CAPTURE/TRI-CAPTUREはLinuxで使用可能

 RolandUSBオーディオインタフェース製品であるDUO-CAPTURE(UA-11)、TRI-CAPTURE(UA-33)を入手しました。いずれも2011年発売で約10年前の製品ということになります。
 

Windows

 個人的にはRolandは新OSのドライバサポートを早期に打ち切るイメージがあるのですが、2015年リリースのWindows10にはいずれも正式に対応しています。
 なお、最近リリースになったばかりのWindows11ではDUO-CAPTUREが非対応*1とされ、TRI-CAPTUREは検証中だそうです。
www.roland.com
 

Linux

 Linux(ALSA)だとどうなのか実機を入手する前に簡単に確認したのですが、以下の2点から対応状況が不明でした。

  1. ALSA公式のSound Card Listに載っていない
    Matrix:Vendor-Roland Edirol - AlsaProject
  2. snd-usb-audioのソースコード(quirks.c, quirks.h, quirks-table.h)に機種固有のコードが無い
    usb « sound - kernel/git/torvalds/linux.git - Linux kernel source tree

 実機を入手後、Ubuntu20.04環境でテストしてみたところ以下の通り、UA-11、UA-33のいずれも特に問題無く動作しました。

  • UA-11の[SAMPLE RATE]と[EXT]スイッチの組み合わせがいずれの場合(44.1kHz or 48kHz, 16bit or 24bit)でも録音・再生共に問題ありませんでした。
SAMPLE RATE EXT SW REC PLAY USB VID:PID NOTES
44.1kHz ok ok 0582:012B 24bit 44.1kHz
44.1kHz ** ok ok 0582:0137 16bit 44.1kHz (work as USB Audio class compliant device)
48kHz ok ok 0582:012B 24bit 48kHz
48kHz ** ok ok 0582:0137 16bit 48kHz (work as USB Audio class compliant device)

※EXTスイッチが**の時はクラスコンプライアントなオーディオデバイスとして動作するようです*2。つまり、非公式ながらWindows98SE辺りからWindows11やiOSも含めてOS標準ドライバで動作すると考えられます*3

  • UA-33の[SAMPLE RATE]が44.1kHz or 48kHzのいずれでも録音・再生共に問題無く、[SAMPLE RATE]が96kHzで[SAMPLE MODE]がPLAY or RECのいずれでも、再生または録音が問題無く行えました。
SAMPLE RATE SAMPLE MODE REC PLAY USB VID:PID NOTES
44.1kHz - ok ok 0582:0132 24bit 44.1kHz
48kHz - ok ok 0582:0132 24bit 48kHz
96kHz PLAY - ok 0582:0132 24bit 96kHz(half duplex)
96kHz REC ok - 0582:0132 24bit 96kHz(half duplex)

 (Linuxだからとかではなく)機器の仕様としてサンプリング周波数が96kHzの場合、録音または再生だけの半二重となります。単純計算すると24bit 96kHzでステレオ2chのPCMデータ転送の場合、24*96000*2=4608000すなわち約4.6Mbpsの帯域幅が要求されます。全二重として録音再生の上り下りで2倍の帯域幅を消費しても、USB1.1のFullSpeedなら12Mbpsですから足りそうな気もしますが、オーバーヘッドを加味すると安定動作しないとか、何らかの理由があるのでしょう。

 なお、両モデルともUSB1.1で動作するようです。また、UA-11の方は特筆すべき低消費電流ですので、シングルボードコンピュータと組み合わせて使うのも面白そうです。

Model bcdUSB MaxPower
UA-11 1.10 96mA
UA-33 1.10 450mA

 

機器個別のquirksがソースコードに無いのにLinuxで動作する原因

 ところで、USB AudioクラスコンプライアントではないVendor Specificな動作モードでもUA-11が動作したり、完全にVendor SpecificなUA-33も動作するのは何故かとソースコードを調べてみたら、2013年の以下のコミットで対応したようです。
kernel/git/torvalds/linux.git - Linux kernel source tree
 このコミットにはざっくりと「Vendor SpecificなDevice ClassでVendor IDがRolandYAMAHAで転送モードにisochronousを使うような機器ってオーディオデバイスやろ?データフォーマットが特定できたらPCMデバイスとして動かしたるわ。」みたいな万能コードが含まれており、RolandYAMAHAの大量の機材がALSAで動作するようになっています*4。このため、snd-usb-audioのquirks系のソースコードUA-11やUA-33の機器固有のコードが無くても動作するようになったようです。
 



以上。

*1:後述の通りEXTスイッチを**にすれば非公式ながら16bit限定で普通に使用できるはずです。

*2:従来のRoland/EdirolUSBオーディオバイスのAdvanced Driver SWのON/OFFがEXT SWの*/**に対応するようです。何故こんな解り難い表記方法に変更したのだろうか?

*3:この時、bcdADC=1.00なのでUSB Audio device class revisionは1

*4:UA-11やUA-33は純粋にオーディオだけのデバイスですが、このコミットにはMIDIについても同様のロジックが含まれており、クラスコンプライアントではないVendor SpecificなRoland/YAMAHA製のシンセサイザーに内蔵されているようなUSB-MIDIバイスの多くも動作するようになっています。