ポタフェス2013 ご報告。

0 comments

Posted on 27th 12月 2013 by admin in Tips |イベント情報 |ものつくりの現場から

去る12/21(土)~12/22(日)におこなわれた「ポタフェス2013」に参加しました。
今回のポタフェスは年末の秋葉原で開催されたこともあり、来場者がなんと2万人!
国内でも最大級のイベントになったと言っても過言ではありません。
開催時の模様を少しだけ撮影してまいりましたので、ご覧ください。

今年も昨年同様、ヴェルサール秋葉原で開催されました。
会場入り口
出入り口の様子。昨年とは違う意気込みを感じます。

1Fスペースには即売ブースが設営されていました。
即売コーナー
いつも賑わっています。

イベントスペースではアーティストによるライブを開催。
イベントスペース
すごい盛り上がりです。

2F入り口付近の様子。少し人が少ない感じがしますが…。
2F入り口

どちらの導線にも多数の来場者!
会場内 会場内

さて、当社ブースの出展内容をご案内。

REX-Kシリーズ自作Kitの4種。
自作キット
製品の詳細はこちら! ⇒ http://www.ratocaudiolab.com/product/kit/

先日発表したフルバランスヘッドホンアンプ「REX-KEB02AK」!
REX-KEB02AK
Astel&Kern製AK100/AK120をメインターゲットにした
バランス駆動型ポータブルヘッドホンアンプの登場です。
製品版の外観を変更し、よりAK100/AK120に印象が近寄りました。

製品の詳細はこちら! ⇒ http://www.ratocaudiolab.com/product/rex_a/rex_keb02ak/

こちらはREX-KEB02AKのセットアップ例とアナログ入力専用のREX-KEB01シリーズ
REX-KEB01シリーズ
REX-KEB01を所有するたくさんのユーザー様が弊社ブースに訪問くださいました。

製品の詳細はこちら! ⇒ http://www.ratocaudiolab.com/product/kit/rex_keb01/

ご来場、誠にありがとうございました。

モニターブログのご紹介

0 comments

Posted on 21st 11月 2013 by admin in お知らせ |ものつくりの現場から |製品情報

本日は、これまでに弊社のオーディオ製品をモニターしていただいたブロガーさんたちのブログをご紹介いたします。
ユーザーさんの声をみなさんの製品選びの参考にしていただければ幸いです。

 

===================
ウスクヒロク 八方衆人様
===================
モニター製品▼16bit/44.1kHz,48kHz対応USBヘッドホンアンプ「REX-A1648HA1」
REX-A1648HA1
掲載ブログ▼
ラトック REX-A1648HA1を試す。その1導入編
ラトック REX-A1648HA1を試す。その2RCA編
ラトック REX-A1648HA1を試す。その3 ヘッドフォン編
ラトック REX-A1648HA1を試す。その4比較編
ラトック REX-A1648HA1を試す。その5 とりあえずまとめ
ラトック REX-A1648HA1を試す。その6 社外アダプタ編

 

===================
名盤CD紹介 週末園藝家様
===================
モニター製品▼24bit/96kHz対応USBヘッドホンアンプ「REX-A2496HA1」
REX-A2496HA1
掲載ブログ▼
「REX-A2496HA1」到着
USB接続ヘッドホン・アンプ「REX-A2496HA1」の感想、仕様など
「REX-A2496HA1」の音質(スピーカー篇)
「REX-A2496HA1」の音質(ヘッドホン篇)
「REX-A2496HA1」の音質(ヘッドホン篇の続き)

 

===================
MacBSの日常生活的日記 MacBS様
===================
モニター製品▼DSD & PCM 24bit/192kHz対応USB D/Aコンバーター「RAL-DSDHA1」
RAL-DSDHA1
掲載ブログ▼
RATOC RAL-DSDHA1 レビュー 到着編
RATOC RAL-DSDHA1 レビュー 音質編
RATOC RAL-DSDHA1 DSD変換編

 

===================
とーさんのブログ とーさん様
===================
モニター製品▼USB Wireless Audio Adapter EX「REX-Link2EX」
REX-Link2EX
掲載ブログ▼
USBワイヤレスオーディオアダプターEX REX-Link2EX:第1回レビュー
USBワイヤレスオーディオアダプターEX REX-Link2EX:第2回レビュー
USBワイヤレスオーディオアダプターEX REX-Link2EX:第3回レビュー
USBワイヤレスオーディオアダプターEX REX-Link2EX:第4回レビュー

 

===================
MacBSの日常生活的日記 MacBS様
===================
モニター製品▼USB Wireless Audio Adapter EX「REX-Link2EX」
REX-Link2EX
掲載ブログ▼
RATOC REX-Link2EX レビュー 接続編
RATOC REX-Link2EX レビュー 音質編

 

===================
MacBSの日常生活的日記 MacBS様
===================
モニター製品▼24bit/96kHz対応USBヘッドホンアンプ「RAL-2496HA1」
RAL-2496HA1
掲載ブログ▼
RATOC RAL-2496HA1 レビュー 到着編
RATOC RAL-2496HA1 レビュー イヤフォン編
RATOC RAL-2496HA1 レビュー 比較編
RATOC RAL-2496HA1 レビュー まとめ編

バランス駆動型ポータブルヘッドホンアンプの電池持続時間はどのくらい?

0 comments

Posted on 2nd 5月 2013 by admin in Tips |ものつくりの現場から |武者修行

本日は、先月発売されたバランス駆動型ポータブルヘッドホンアンプREX-KEB01F
連続再生時間についてお話ししたいと思います。

REX-KEB01F

この製品の特徴の1つである連続再生時間は、
公称値で約50時間となっています。

50時間の連続再生が出来るなら、
通勤/通学の往復に1日約2時間使用しても、
およそ1ヶ月間は充電なしで使用できる計算になります。

1日2時間×1週間に5日使用×5週間=50時間
※使用する乾電池や放電など、環境の違いにより再生時間は異なります。

これでも十分な再生時間と言えますが、
実際はどれだけ再生できるのでしょうか?

今回は日立マクセル製アルカリ乾電池(LR03(BS)/1.5V 3本)と、
Panasonic製EVOLTA(ニッケル水素充電池)(HHR-4MWS 3本)を使用し、
実際の連続再生時間を実測してみました。

さて、結果は…、

アルカリ乾電池  ⇒100時間
ニッケル水素充電池⇒110時間

両乾電池ともに公称値の倍となる100時間の連続再生が可能でした。

100時間を越えた時点でアルカリ乾電池の電圧は急降下し、
若干ながら音質にも変化が現れたので、この時点でストップとしました。
充電式のEVOLTAは100時間を越えても、全く音質や電圧に変化が現れず、
容量が切れるまでしっかりと駆動していました。

100時間も使えるポータブルアンプ。
充電回数が少なくて済むので、使う場所がいろいろ増えそうですね。

#39 USB Audioについて(その7 補足….Jitterの話の前に。)

6 comments

Posted on 3rd 3月 2010 by admin in ものつくりの現場から

USB Audioもあちこちで取り上げられるようになり、クロックやケーブルに関する議論が盛り上がっています。しかしながら、クロックに関しては前回までの当Blogで説明したようにほとんどが間違った思い込みで語られています。とりわけPC側(音楽データの送り出し側)に関する誤解・珍説が多く「PCのクロックの精度が影響する」というような説が流布されています。同じようにJitterに関しても「Jitterの実体」を見たこともないまま「ジッタ、ジッタ」と騒いでいます。この連載ではJitterの実体と実態を示しながらどこで発生する(大きくなる)のか、対策は何なのかということについて説明したいと思います。ただし、「Jitterが少ないから音がいい」と言っているのは「ジッタ、ジッタ」と騒いでいる人達です。私たちはそう結論づけているわけではありませんが原音再生にはJitterが少ない方がよいと考えています。

 

Jitterの話を進める前に再度USB Audioパケットの伝送についておさらいをしておきましょう。#37にYHさんからコメント(ご質問)をいただいていますので回答を兼ねて説明したいと思います。これまでの図版をもう一度参照しながら読み進めてください。

 

これまで説明したように再生するためのAudio Dataは録音あるいはRippingされてdataとして記録された時点でサンプリングクロックとは直接的な関係がなくなります。どれだけのSampling RateでA/D変換されたのか、すなわち一組のデータはどういう時間軸(Sampling Rate)で採取されたのかという属性情報によって意味づけされるバイナリデータ(’0’と’1’の列)として扱われます。これがUSBという伝送路を通してUSB-DACなどに送り込まれます。

 
USBはデータ伝送のためのしくみですので、ベルトコンベアや鉄道のようなものと考えることができます。usbaudio.sysで使用されるFull Speed(12Mbps)のIsochronous転送は、ちょうど1mS(1フレーム間隔)おきに定時発車する電車に決まった数の乗客を乗せて運んでいるようなものです。列車は定時運行と速度維持のために完全に独立した計時機構(USBクロック)を持っています。このクロックもAudio StreamのClockとは直接関係がありません。

 
PC側のSoftware,Hardwareが関与するのは、Storage Device(HDDやSSD,USB Flash memoryあるいは SD CardなどのFlash Memory)から主記憶(RAM)上に音楽データを読み出すこと、読み出したデータを属性情報に従ってUSBスタックに積み上げることだけです。属性情報にはA/D変換された際のSampling RateやCh.数(Stereoかmonoralか)、Ch.あたりの解像度(bit数)にもとずくバイト数(16bit/Ch.なら2Bytes,24bit/Ch.なら3Bytes)が含まれていますので、PC側のSoftwareは1mSの間にAudio Streamとして転送される(D/A変換される)べきバイト数のデータを揃え、10mS分をUSBスタックに積み上げてusbaudio.sys(WindowsPCの場合)に渡します。usbaudio.sysはこれをUSBの計時機構(クロック)にしたがって、USB-DACなどのUSB Audio Deviceに送りつけます。したがって、PCのクロックはRAMやDeviceからの読み出し、バスマスタ転送、DMA転送などでは使用されますが、それによって読みだされる楽曲データが影響されることはありません(データ化けをすればError訂正されます)し、元のA/D変換時のサンプリング情報が変わってしまうようなことはありません。PC側でA/D変換時のようにPCのクロックを使用して44.1kHzや96kHzでサンプリングを行って楽曲データを読み出し、USBバス上に送り出しているわけではありません。間違えないでください。

 
USB Audio Device側では1mSごとにSOF(Start of Frame)検出割り込みが発生します。SOF割り込みは新しいフレームの始まりの検出と同時にひとつ前のフレームの受信完了を意味しますので、SOF割り込みが上がってきた時点ではEndpointにひとつ前のフレームで受信したIsochronous Outパケットで運ばれてきたデータが入っています。RAL-2496UT1で採用したTAS1020Bでは、あらかじめ1組のSammpling RateあたりのByte数を設定しておくと、何組のデータを受信したかを通知してくれます。そこでRAL-2496UT1内部のFirmwareがこの通知を受け取って44/45あるいは88/89が続いていればAudioのベースクロックを22.5792MHzに、48あるいは96が続いていれば24.576MHzに設定します。もし、これら以外の数が通知されれば、例えばUSB通信上で発生したErrorでデータが落っこちた場合や、全く入っていなかった場合などにはそれまで使用していたベースクロックをそのまま使用します。したがって、YHさんからのご質問にあるような43組のサンプリングデータが間違って送られてきたような場合でも、RAL-2496UT1の場合にはそれまで使用していたベースクロックを維持しますのでDACへ送り込むLRCLK(Sampling Clock)が狂ってしまうことはありません。また、初期設定として16bit/44.1kHzモードに設定していますので、bit数の情報がこなかった場合や変な数のIsochronousパケットが続いた場合でも狂ってしまうことはありません。

 

ただし、Audio用のベースクロックをFirmwareで設定するのではなく、Wired Logic(Hardware)でPLLを設定することによって作り出している場合は方法によっては変な数が来ると狂うことがあるかも知れませんが、実際に実験を行って確かめたわけではありません。

 
また、上記のように元々USB AudioはASYNC(送信側にClockがなく、受信側が独立したClockを持っている)ですので、YHさんの2番目のご質問のように何らかの方法で送信側がSetする1mS以内にD/A変換すべきデータの数と受信側が生成するSampling Clockを一致させ、Startを同期させないとバッファのオーバーフロー、アンダーフローが発生しやすくなります。

 

まずオーバーフローですが、オーバーフローが発生するのは一つ前のフレームで受信したデータを次のフレームの受信が終わる(次のSOFを検出するまでに)までAudio Streamとして転送しきれなかった場合に発生します。#37でも説明しましたが、Audio Stream作成時にはひとつ前のフレームで受信したデータを一定の間隔で送り出さなければなりません。しかし、次のフレームのパケットがEnd Pointにドサッと一気に書き込まれますので、一つ前に受信したデータが上書きされてしまう可能性があります。これを避けるためにEnd pointを複数個用意しておいて次々に切り替えてゆく方法や、リング状のバッファを用意しておいてハツカネズミの車のようにくるくると回す方法があります。TAS1020Bでは少ないRAMを有効に活用するため後者の方法を採用しています。したがって、回転(Sampling Clockによる読み出し)さえ止まらなければバッファがオーバーフローすることはありません。しかし、輪の直径が小さい(円周が短い)と読み出し位置が書き込み位置に追いつかれたり、追い抜かれてしまうとオーバーフローが発生しています。これを回避するためには輪の直径をうまく決めておかねばなりません。そこがFirmwareの勘所です。

 

SOF-SOF間隔が1mSちょうどで、LRCLK(Audio StreamのSampling Rate)も正しければこの状態で問題が発生することはありませんが、Audio Streamを作成するために音楽(曲)の始まりとLRCLKの最初のL-Ch.のエッジを同期させてStartさせる必要があります。そのため、SOFとSampling ClockのStartは少しずれることになります。このズレが一定であれば問題は生じませんが、ズレが大きくなると次のSOFが来てもまだバッファ内にAudio Streamとして未転送のデータが残っている場合があります。この場合も、この残りの処理をうまく行わないとLRがひっくり返ったりします。

 
アンダーフローはパケット内部のデータが足りない、あるいはパケットが届かなかったという場合に発生します。この場合、バッファ内部に残っている以前のデータをそのまま使用してAudio Streamを作成し続けるか、ゼロデータ(無音)を出し続けるか、Audio Streamを止めるかというどれかを選択しなければなりません。Audio Data(LRCLK,BCLK)を止めると後段のDACなどがリセットされる場合があるので一般的にはゼロデータを送り出します。そうすると前後の音によっては「バチッ」という音になってしまいます。これに関してはPC側を何とかしないと、Device側では「なるべく人の耳に聞こえにくくする」というゴマカシの対策しか今のところはありません。TAS1020BなどのUSBコントローラにはSOFを検出してから1mSを過ぎても次のSOFを検出できなかった場合、偽のSOF検出割り込み(PSOF)を発生させる機能もあります。しかし、現実にはPSOF割り込みは上がってきたことがありません。
USB経由でAudioデータを受信し、Audio Streamを生成するしくみについて理解していただけましたか?Jitterの話に進む前にこのしくみと「PCのクロックの精度がUSB-DACのD/A変換用のクロックに影響する」という説は正しくないということを理解しておいてください。

#38 USB Audioについて(その6 Host側のドライバについて)

6 comments

Posted on 10th 2月 2010 by admin in ものつくりの現場から

 前回の記事(#37)について早速「えるえむ」さんからコメントをいただきましたので、その回答も兼ねてHost(PC)側がどのようにして音楽データをUSB_Bus上に送り出しているのかということについて簡単に説明しておきます。Host側の動作を理解していただいた上でJitterなどの話を進めたほうがわかりやすいと思いますので。

Z38-1

<図-38-1 USB Audio 関連Softwareの階層>

 USB Audio 機器ベースのPC_Audioに関係しているドライバ、アプリケーションソフトウェアの構造を簡単に示したものが図-38-1です。このような階層構造(OSI)は25年以上も前に大型計算機の通信ソフトウェアで使われてきたものです。同図はWindowsPCの場合ですが、MacOS XやSolaris,Linuxも同じような構造をしています。一番ケーブルに近いところはハードウェア(USBコントローラLSI)でPCI_BusやCardBusスロットを経由する場合もあります。最近は大半がMother Boardに実装されているChip Set(LSI)に組み込まれ、内部のSouth(PCI) Bridge経由でCPUのBusに接続されています。これらのコントローラにはLowSpeedとFull Speed(12Mbps、USB AudioはUSB 2.0と称していますが、ほとんどの製品はこのFull Speedで動作しています。)を受け持っているUHCIあるいはOHCIアーキテクチャのコントローラ、High-Speed(480Mbps、昔の呼び方ではUSB 2.0)を受け持つEHCIアーキテクチャのコントローラの3種類があり、それぞれに対応したミニポートドライバがWindowsやMacOSなどのOSに既に組み込まれています。ちなみにWirelessUSBの場合はWHCI、SuperSpeedUSB(USB 3.0)の場合はXHCIと呼ばれます。IEEE1394の場合もOHCIアーキテクチャと呼ばれています。

 RAL-2496UT1などのUSB Audioの場合はUHCIかOHCIアーキテクチャのコントローラ経由で通信することになります。UHCIというのはintelが提唱したアーキテクチャでintelのChip Set以外ではVIAのChipで使用されており、ほとんどの処理をSoftwareによるポーリングで行うので構造が簡単ですがソフトウェアのオーバーヘッドが大きく、リアルタイム処理向きではありません。対抗するOHCIはOpenの頭文字が示すようにCompaq,NS,Microsoftによって提唱され、NECやNvidea、AMDなど多数の会社が採用しているアーキテクチャで、ほとんどの処理をコントローラ自身が自分で行います。Software(CPU)はDescriptor ChainをSetしてコントローラに実行指令を出すだけでよいのでリアルタイム向きで優れているのですが、その分コントローラの設計が難しくなり構造も複雑ですので価格が高くなります。実際にOHCIアーキテクチャが使われているChipはAMD-CPU用のChip SetおよびNECのUSBコントローラChipです。

 USB DACなどのUSB Audio出力ではIsochronous転送が使用されていますので、全体のCPU負荷が小さければOHCIでもUHCIでも動作に差はありませんが、音楽編集や録音、Mixingなどでインタラプト転送、コントロール転送、バルク転送などが使用されている場合はUHCIよりはOHCIの方を使用したほうがよい結果が得られると思います。なぜなら、OHCIでは32mSごとに最低1度はインタラプト転送を受け付けたり、1フレーム期間内に複数のコントロール転送や2回以上のバルク転送を実行できますがUHCIではこれらは実行できません。

 USBポートにUSB機器が接続されるとまずLow SpeedかFull Speedかが2本の信号線(D+とD-)の状態で判断されます。続いて、USB機器の種類や属性を引き出すためのGET_Descritorが発行され、機器側はDevice Descriptorを返送します。Descriptorを解析した結果USB Audioの規格に準拠したAudio DeviceであることがわかればAudio Class Driverとしてusbaudio.sysがロードされます。続いてDevice Managerによって、その上にKernaelmixerあるいはASIOなどの中間のDriver(Client Driver)がロードされます。さらにその上にiTunesやMedia Player, foobar2000などのアプリケーションがユーザー(みなさんです)によってロードされれば、最終的に図-38-1のような階層構造が出来上がります。

 この図からおわかりのようにRAL-2496UT1などのUSB Audio機器はASIOドライバから見て、下位のusbaudio.sysを経由してにアクセスされますので「USB Audio規格に準拠しているUSB Audio機器は基本的にASIOドライバに対応している」ということになります。したがって、iTunes(QuickTime Player)などのアプりケーションがASIOドライバを使用するようにアプリケーションの入出力を設定すればOKです。その設定を行わなければKernelMixerが有効になりますのでRAL-2496UT1などのUSB Audio機器へのアクセスはKernelMixor経由となります。Windows Vista SP2以降(Windows 7も)では従来のDirectX(Sound)だけでなくKernelMixer内部の機能を選択(パススルー)することができるWASAPI(Windpws Audio Session APplication Interface)というAPIが新たに用意されていますので、これを使用してUSB Audio Deviceを排他モードに設定し、bit数やfsをWAVファイルのヘッダ部に書かれているものを指定するという方法もあります。もっと、簡単な方法はUSB Audio DeviceのDescriptorの記述を16bit/44.1kHzのみなどにしてしまうという方法もあります。この方法で16bit/44.1kHzのWAVファイルのみを再生すればKernelMixer内部のSRC機能を実質的にPassさせることができると思います。FostexのHP-A3の場合は、Descriptorに16bit/96kHzと24bit/96kHzにのみ対応としか記述されていませんので、KernelMixerなどのSRC機能を使用せずに16bit/44.1kHzのWAVファイルをオリジナルとおりに再生しようとするとPC側でエラー表示がでて再生できません。したがって、先ほど「USB Audio規格に準拠しているUSB Audio機器はASIOドライバに対応している」と書きましたがUSB Audio機器側がSRCなしでASIOドライバを通して送り出されて来る音楽データのbit数/fsに対応していなければなりません。RAL-2496UT1では16bit、24bitの各解像度で44.1kHz,48kHz,88.2kHz, 96kHzの各fsに対応していますのでWASAPIやASIOドライバを使用すれば、PC側のSRC機能なしでたいていのWAVファイルやAIFFファイルをそのまま再生できます。iTunes(QuickTime)のWASAPI使用の設定方法についてはラトックプレミア楽天市場店店長Blogを参照してください。

Z38-2

<図-38-2 WAVファイルがUSB転送のためのIsochronous Out パケットに編集されるしくみ>

 図-38-2をご覧ください。iTunesなどのアプリケーションは指定されたAIFFもしくはWAV(どちらも非圧縮PCM)ファイルをHDDやSSD、FlashMemoryなどの記憶媒体から読み出してRAM上で編集します。編集といっても簡単でファイルのヘッダに格納されているfmtチャンク(format情報。chunkは'ぶつ切り'のひとかたまりという意味です)内部のbit数(L,R各チャンネルあたりの)やfs情報を元に、dataチャンクから取り出した実際のサンプリングデータのブロックを下位のドライバに引き渡すだけです。usbaudio.sysではこの上位から渡された10mS(10フレーム)分のデータブロックを各フレームのパケット用にfs/1000組ずつ(44.1kや88.2kの場合の分け方は#37参照)整列させます。OHCIの場合にはとても簡単で各パケット分のデータと荷札(Packet-IDと順番、Timestampなどが記載された)、次のメモリブロックの場所を記載した送り状をひとつのメモリブロックに格納してチェイン上に並べておきます。そしてOHCIコントローラに最初のメモリブロックの場所を指示して実行命令を出しておけば後はOHCIコントローラが内部のインターバルタイマの1mS間隔にしたがって、USB Bus上に送り出してゆきます。UHCIコントローラのミニポートドライバは作ったことがありませんのがこんなに簡単(CPUのすることが少ない)ではないようです。

 この図からおわかりのようにHost(PC)側ではfsによるサンプリングなどは行っていません。サンプリングされたデータ列をデータが作成されたbit数、fsに基づいてRAM(メモリ)上で整理しているだけです。サンプリングレ?トや解像度を変換しない限り非圧縮のPCMデータに対してはbitの追加や変更などは行いません。また、HDDなどの記録媒体に関係なくRAM上に読み出されたデータは同一です。 したがって、「HDDなどの回転体を使用するとJitterが増えて音が悪くなる」とか「PCのClockがゆらいでJitterが増える」、「PCのClockがUSBケーブルを通ってUSB Audio機器側のfsに影響する」というような評論記事はすべて???です。実際の再生はUSB Audio機器内部で作成したClockによりAudio信号に変換されます。したがって、再生時(I2S作成時)のClockはデータ送り出し側とは完全に独立していますのでAsynscということになりますが、曲の最初を同期させなければ正しく再生できませんので何らかの方法が必要です。そこだけに注目するとSYNCということになり、Isochronous転送は受信が終わるまでバイト数がわからず、しかもそのバイト数でしかfsを判断できないということを考えればAdaptiveということにもなります。要はIsochronous転送の動作モードの指定はどうでもいいのです。プロトコルアナライザで観測している限りでは動作モードbitをいろいろ変えてみても何も変わりません。

 USB Audioで問題なのはいろんなアプリケーションが動作している場合、Isochronou転送用のパケットが用意されていないことがあるということです。また、WindowsもMacOSもUSBのミニポートドライバなどが特権モード(Kernelモード)から優先度の低いユーザモードに移されてしまいましたので、PowerManagementなどの特権モードで動作するドライバにPacketデータのセットが邪魔をされてしまうことがあります。これらの問題が「ブチッ!」という再生時の音切れの原因のひとつになります。実際にWindowsVistaではNEC製USBコントローラを使用した私たちの製品(PCIボードおよびCardBus Card)の動作が非常に遅くなります。いろいろ調査したところMicrosoftのPowerManagementドライバが常時USBコントローラ(OHCI/EHCI)を監視しておりバルク転送などの動作の邪魔をしていることがわかりました。でもMicrosoftからは「悪ぃ、悪ぃ、Windows7では直しておくよ」という回答でした。約束通りWindows7では修正されていますがVistaユーザはどないすれば….

 同様にMicrosoftではIsochronous Packetへのデータセットが間に合わずに発生する音切れ(Scratch noise like a vinyl recordというらしいのですが)について統計を取って調査をしています。その結果、この音切れを発生させる最大の要因はPowerManagementであり、ノートPCをバッテリで動作させている状態が最も発生しやすいとの結果を発表しています。「PC_Audioで最もいい音を出すにはノートPCをバッテリ駆動で動作させる」という記事をよく見かけますが、これは音切れの発生率が最も高くなることがあるということに気をつけてください。

 余談ですがintel-Macが発表される1年くらい前にMacOSでもUHCIをサポートするということが発表されたことがあります。その事実が示すようにintel-MacのUSBポートはUHCIアーキテクチャを採用しています。OHCI用のドライバはまだ残されていますのでPCIeボードを使用すればOHCIアーキテクチャが使用できますが、NECのUSBコントローラ搭載のPCIeボードはありません。NECのUSB 3.0コントローラ搭載のPCIeボードでEHCIとOHCIを使用するという手はありますが、USB 3.0のDriverはまだ提供されていません。通信用のファームウェアを書くたびにMC6800系はよく出来ていたのになぁ~と懐古趣味に浸っています。でも、このScratchノイズが解決すればUSBはPC_Audioの信号伝達手段として最も普及すると思います。

 次回はJitterについて説明します。

#37 USB Audioについて(その5 bit数とSampling Rateはどのようにして決められるか)

2 comments

Posted on 2nd 2月 2010 by admin in ものつくりの現場から

 前回の図-36-1を理解していただけましたか? 同図のようにUSB信号線上はUSBの転送レート(この場合は12Mbps)によるPacket転送であり、USB Audio DataそのものはPacketの中の単なるバイナリデータとして扱われます。データはUSBの転送ルールにしたがってIsochronous転送されますので、USB-Host(PC)やUSB Audio Deviceのコネクタ部や基板パターン、PHY(Chipの物理層)周辺、ケーブルなどのどちらかといえばアナログ部の影響を受けます。何らかの問題がある場合はデータの不一致や誤認識、欠落が発生します。これが発生しないようにクリアすべき電気的な基準がUSB規格で規定されています。

 Full Speed(12Mbps)も低速とは言え高速シリアル転送ですのでジッタに関する規定もあり、測定時には一目で判定できるようにアイパターンが規定されています。これまでの私たちの経験では、USB Audio機器が正しく認識されないようなケーブルや、データ転送の途中で転送を止めてしまうようなケーブルはこのアイパターンテストで不合格となります。

 USBの転送時に使用されるClockは両側のUSBコントローラの発振回路(TAS1020Bでは6MHzの水晶を使用し、内部のPLL回路でFull Speed転送に必要な48MHzを作成しています。)でつくられていますが、Audio DataがIsochronous Packetとして転送される場合、受信側は送信側のSpeedに合わせるため、PLL回路を動作させて送信側のClockに追従してLockさせたClockを使用します。したがって、前回の図-36-1からもおわかりのようにPCからのUSB Clockおよび受信側のUSB ClockはAudio DataをI2Sに変換するためのAudio Clockとは全く別のClockです。Host(PC)から送り出されてくるUSB DataからS/PDIFのようにAudio用のClockを作成しているわけではありません。ましてやPCのClockがアプリケーションソフトウェアの動作により影響されてゆらいだままノイズを載せてUSB Audio機器に入り込んでくるということはありません。iTunesでCover Flowなどを動作させるとUSB Audio接続のAudio機器~ブツブツ音が聞こえるというのは別の原因です。

 PCとUSB Audio機器双方のUSBコントローラ相互間はSYNCモードですが、PC側と機器側のAudio Clock(LRCLK,MCLK)は完全に独立したClockを使用しますので一般的な定義ではASYNCということになります。しかし、サンプリング周波数と位相(LRCLK)、各Ch.のbit数が一致しないと音楽の始まりやつながり、テンポや音程が無茶苦茶になってしまいます。MIDIの場合は音符のコードや小節ごとの同期コードなどが決められていましたがUSB Audioの場合はそんなものは何もなく、いきなりバイナリ('0'と'1'の組み合わせ)データが送られてきます。したがって、単なるASYNCではStart bitもStop bitもありませんのでどこが曲の始まりか、どちらがL.Ch.のデータかR.Ch.のデータかわからなくなってしまいますので送り出し側(PC)と受信側(USB Audio機器)の間でSoftware(プロトコル)レベルで同期をとることが必要です。

 図-37-1を参照してください。前回の図-36-1ではfs(LRCLK)が48kHzで1mSのUSB Frame間に整数個のデータがきちんと収まる場合を図示していますが、図-37-1ではCDを非圧縮でRippingした44.1kHzのデータの場合を図示しています。CDがUSBよりも10年も前に普及し、音楽ソースとして無視できない存在ですのでUSB Audioの規格を決めた人達もずいぶん苦労されたようですが、この44.1kHzや88.2,176.4kHzというfs(1msで割り切れない)にはずいぶん苦労させられます。これまでも何度かお話しましたが、44.1kHzの場合、USB Audio Driverの10mS分のスタック上に1パケットあたり44サンプル分のデータが9パケット分と45サンプル分のデータが1パケット分積み上げられ、順番にUSB Bus上に送り出されます。

37_20100202a2

<図-37-1>fs=44.1kHzの場合

 以下は図-37-1を参照しながら読み進めてください。

 まず最初のPacketの受信が終了し、次のFrameのSOFが検出されると最初の44組のデータをI2Sに変換しなければなりません。ただし、LRCLKは44.1kHzですので次のSOHまでの1mSまでの期間に2.27μS(1.0mS – 1/44.1k x 44 )の隙間(GAP)ができてしまいます。音楽の途中でこんなGAPがあると音が狂ってしまったり、バチッというLPレコードの引っかき傷のような音が出てしまいます。そのため、次のパケットの先頭一組を取りだしてきてくっつけます。2番目のパケット内のデータを送り終わった後では4.54μS、3番目のパケット内のデータを送り終わった後では6.81μS…とだんだんGapが大きくなり、9番目のパケット内のデータを送り終わった後には20.43μSとなります。この時点で10番目のパケットの最初の組をくっつければ10番目を転送した直後は11番目(最初のFrameは転送しないので)のSOHに一致します。したがって、USB Audio機器側でもPacket10個分(10mS分)のバッファメモリを用意すればSoftwareやHardwareが簡単になりますが、16bit/44.1kHzで1,764バイト(4×441)、24bit/96kHzにも備えておくとすると5,760バイト(6×960)のRAMが必要となります。現時点で入手可能なUSB Audio StreamコントローラのTAS1020Bを例に取るとEndpointやBufferとして使えるRAMは最大で1304バイト程度ですので10mS分のバッファは用意できません。TAS1020Bではひとつながりのリング状にバッファを設定することに(Circular Buffaer)よって、この44.1kHzベースのAudio dataに対応しています。

  パケット内のデータを取り出しI2S(LPCM) Streamに変換するためには各Ch.(L,R)のbit数、fsに関する情報が必要です。USB DACやUSBトランスポートなどのIsochronous Out転送の場合、これらのパラメータを決定する主導権はPC上のSoftware(iTunes/QuickTime PlayerやMedia Player,KernelMixerなど)にあります。また、実際に使用する上でも、楽曲ファイルのフォーマットに従って転送が行われ、USB Audio機器側では何の操作する必要がないほうが最も使いやすいと思います。たとえば16bit/44.1kHzでRippingされた楽曲ファイルを選択すればUSB Audio機器やAudio機器側で何も操作せずとも16bit/44.1kHzで再生され、24bit/96kHzでRippingされた楽曲ファイルを選択すれば同様に24bit/96kHzで転送されて再生されるという具合です。

 Isochronousの転送モードがASYNCであるか、SYNCかAdaptiveであるのかに関係なくUSB AudioではHost側(PC)がUSB Audio Deviceから取得したDevice Descriptorを解析し、その機器が24bitにも対応しているのか、それとも16bitだけにしか対応していないのかInterface descriptorを元に判断します。そして、Audio Data Streamに関するInterface Setごとに、ReadyかどうかをRequestを出してUSB Audio機器側に問い合わせます。

 本Blogの#33-図-2に示すRAL-2496UT1の例ではInterface Set#1が16bit用、Interface set#2が24bit用として記述されていますので、PCからSet#2はReadyかどうか、Set#1はReadeyかどうかというRequestが発信されてきます。USB Audio機器(RAL-2496UT1)側ではこの時点ではPCからどんなフォーマットのAudio Data Streamが送られてくるのかということが不明ですので、とりあえず、すべてのRequestに対してReadyを返しておきます。

 PC側でiTunesやMediaPlayer,fooberなどのアプリケーションを起動するとQuickTime Player, Control panel, アプリケーション自体の設定に基づいて、bit数を指定するためのSet InterfaceRequestがUSB Audio機器に送られます。このRequestに対してUSB Audio機器がReadyを返せば、その時点でそれ以降のAudio Data Stream転送で使用されるbit数が決定されることになるわけです。RAL-2496UT1の場合は図-37-2のように音楽データ(Isochronous)に先立って、Set Interfaceが送られて来ます。ただし、bit数が既知(ひとつ前の楽曲再生と同じ場合はSet Interface Requestは発行されませんので、USB Audio機器側は同じbit数のモードを維持し続けなければなりません。次に再生する楽曲のbit数が変更される場合は前述のようにそのbit数に対応したSet InterfaceがHost(PC)から発行されます。図-37-2の場合は24bitのAudio Data Streamを送るということをPCからRAL-2496UT1に通知していることを示しています。

37-20100202b

Packet 5102 がSET_INTERFACE Request で Alternative Setting#2(02, Ch.あたり24bit)を指定しています。

<図-37-2 USB Host(PC)からUSB Audio Device に対するbit 数の指定>

 サンプリング周波数(fs)の指定に関しても同様にHost(PC)はInterface Descriptorを参照します。#33-図-2RAL-2496UT1の場合は16bit、24bitそれぞれのbit数で44.1,48,88.2,96kHzの4種類に対応していると記述していますのでPCはiTunesやMediaPlayerなどの指定にしたがって、どれかのサンプリング周波数に基づいてファイルから読み出したAudio Dataを{(bit数/8) x (fs/1000)}バイトずつ一つのパケットに詰め込みます。例えば24bit/96kHzの場合は(6 x 96)バイトを一つのパケット(1mS分)に詰め込むことになります。

 その後、Audio Dataが詰め込まれたパケットを10個ずつusbaudio.sysに渡して転送実行を命令します。これらのパケットがぞろぞろとUSB bus上を一列縦隊行進しながらUSB Audio機器にやってきます。ところがUSB Audio機器側には、bit数の時のように届く予定のAudio Dataに関してあらかじめfsに関する情報は何も通知されていません。したがって、USB Audio機器側では届いたPacket内のAudio Dataのバイト数からfsを算出しなければなりません。各Ch.のbit数はあらかじめわかっていますからバイト数を6(24bit)もしくは4(16bit)で割り、その商に1,000を掛けるとfsが得られます。前述のようにfsが44.1kHzの場合には商が44であったり45であったりしますが、それはF/Wでfs=44.1kHzと処理することにすればOKです。88.2kHzの場合には88組のパケット4個に続いて89組のパケットが1個という順番で送られてきますので商が88か89だったらfs=88.2kHzと処理することになります。

 Isochronous転送でモードがASYNCの場合にはプロトコルの規格上はDevice側で使用するfsを問い合わせるRequestとそれに対する応答用のEndpointがやり取りされることになっていますが、現実にはそんな面倒なことは行われていません。また、規格上はパケット内のバイト数をCheckしてfsを割り出すのはAdaptiveモードですが、Isochronous Out EndpointのMode bit(ASYNC、SYNC,AdaptiveのModeセット用)をいくら換えてもHost側の挙動には変化がありません。USB Audio機器側がfsを検出するためには、Host(PC)側はパケットサイズによって通知するしかありません。

 Deveice DescriptorのInterface Setの記述方法を一つのbit数/fsごとに記述する方法によりSet Interface requestでbit数/fsを選択する方法もありますが、KernelMixerなどが、機器が対応している最高の組み合わせに内部で勝手にサンプリングレート変換を行ってしまうという問題があります。また、USBマイコン側の問題としてはDevice Descriptor用にそんなに大きなEndpointを用意できないという問題もあり難しいところです。また、QuickTimeやFooberなども指定したbit数が常に使用されてしまうという問題がありますので、この記述方法は最近ではあまり使用されていません。 ただし、独自のfs、bit数設定用のApplicationをあらかじめインストールするタイプのUSB DACなどはこの方法を採用していますが、独自のアプリケーションやドライバをインストールしなければならないこと、OSやiTunes、MediaPlayerなどのVersionが変わるたびにそれらに対応した新しいドライバやアプリケーションが必要になるという問題などがあります。 また、FOSTEX HP-A3のように16/96kHzと24/96kHzにのみ対応と記述されたDevice Descriptorを持つUSB Audio機器の場合、KernelMixerなどがDescriptorに基づいてUSB Audio出力のfsをすべて96kHzにサンプルレート変換して送り出します。たとえば16/44.1kHzでRippingされた音楽ファイルを再生する際にはPC側のSoftwareでサンプルレート変換が行われます。この場合もfsの指定などのRequestはPCからは発行されず、すべてのIsochronousパケットのサイズ(バイト数)が576または384となるだけです。

 USB Audioでbit数やサンプリング周波数が決められている方法はこのようなシンプルな方法です。プロトコルの規格上はいろいろと面倒なことが記載されていますが、USB DACやUSBヘッドホン、USBスピーカーなどのIsochronous Out専用の場合はこのような簡単な方法が採用されています。

 「USB Audioでのサンプルレートの指定方法」について昨年10月にYHさんからコメントをいただいておりますので回答させて頂きます。

 ご質問の件は上記のように「パケット内のバイト数により指定されている」というのが現実です。USB Audioの規格書では「implicitな指定」と記述されています。また同じコメントで「データパケットの間隔をPLLで逓倍してDACのClock(I2SのLRCLKやMCLK)を作成している。」と記述されている他のblogに関しても言及されていましたが、これはYHさんのおっしゃるとおり正しくありません。DAC用のClockはPC側のクロックとは全く関係なくUSB機器側で作成します。USBで必要な48MHzや12MHzなど内部のマイコンの動作クロックの作成に使用される6MHz水晶発振子を共通に使用して周波数シンセサイザで24.576MHzや22.5792MHzを作成しています。あるいは別に搭載されているAudio専用の水晶発振回路でそれらの周波数のClockを作成しているかのどちらかです。どちらを選ぶかはそれらのMCLKそのものやMCLKから作成されたfs(LRCLK)のJitterが少ない方ということを基準にすればよいと思います。前回の#36でも説明しましたがUSBのSOFの間隔(Frame間隔・1ms)は一定ですが、パケットとパケットの間隔は一定ではありません。したがって、YHさんのご意見が正しいということになります。

 「バイナリデータの不一致」に関して「えるえむ」さんからも昨年12月にコメントをいただいております。今回の記事をお読みいただければおわかりのように、ファイルから読み出したバッファメモリ上の音楽データは、当然HDDなどに記録されたものと「バイナリ一致」が保証されていますが、usbaudio.sysへの10ms分・10個のパケットの引き渡し以降は一切、Errorチェックも訂正もありません。Isochronous Dataが壊れているというErrorは通知されますが再送要求などはありません。また、Isochronousデータは受信が終わって初めてサイズがわかるという代物です。なぜ、Errorチェックや再送要求があるBulk転送が使用されないのかということは別稿で説明します。

 USB Audio Streamの転送についてはこれくらいにして次回はJitterについて実測結果などをもとにお話を続けたいと思います。

#36 USB Audioについて(その4 実際の転送について)

0 comments

Posted on 22nd 1月 2010 by admin in ものつくりの現場から

USB機器が必ず備えていなければならないDevice Descriptorについて前回まででひととおり説明しましたので、それが実際にどのように使われているのかということについて見てゆくことにしましょう。

 USBの規格は近日中に3.0に改称されますが、既存のUSB 2.0, 1.1をすべて含むことになっています。したがって、USB Audio機器のほとんどは今年の夏頃からはUSB 3.0準拠 Full Speed対応というのが正確な呼び方になります。

 USBに限らず、PC関連の規格は互換性維持のために順守すべき物理的、電気的仕様やプロトコルについて規定しています。したがって、規定されていることすべてに準拠する必要はありませんが互換性維持、PnP実現のためには最低限守らねばならないことが多々あります。規格をはみ出す部分はVendor Uniqueとして対応可能となっていますが、それはあくまでもプロトコルの部分で、物理仕様や電気仕様は必ず守る必要があります。これを守らないとUSB機器が認識されない、データが化けるなどのトラブルを引き起こします。特にUSBケーブルに関して、「オーディオグレードのケーブル」というケーブルが出回り始めていますが電気仕様や物理仕様を順守しているのかがあいまいなので注意が必要です。

 USB Audioの伝送が一般のシリアル伝送(RS232Cなどと呼ばれる)やMIDIと全く違うということは図-36-1を見ればおわかりと思います。同図は話を分かりやすくするため、音楽を再生する場合(Isochronous Out)の場合について説明しています。USB Audioの場合は1フレーム期間内(1mS)にPacket(小包)の形でAudio Dataが次々と送られてきます。そのPacket内のデータがUSB Audio Device内部のIsochronous Out Endpointと呼ばれるメモリバッファにどんと配達されます。USB Deviceが受信する場合はInではなくOutです。間違えないようにしてください。

Z36-1

<図-36-1 USB Audio Streamの転送>


 USB Device内のUSB Audio Stream Contoroller(面倒なので以降はUSBマイコンと呼びます)はSOF(Start of Frame)やIsochronous packet受信完了を検知して、このEndpoint内部のAudio dataを次のFrameが始まるまでに取り出しておかねばなりません。のんびりしていると次のFrameが始まり次のPacketがどんと配達され、上書きされてしまい音楽データが壊れてしまうことになります。要するに宅配Box内部の小包をすぐ取り出しておかないと、次の便の小包を上から押し込まれてつぶされてしまうというわけです。したがって、1mSのFrame期間の間の最初の300μSくらいはIsochronous Packetの受信に費やされてしまいますので残りの期間のうちの500μSくらいの間に取り出しておく必要があります。実際にはDMAでFIFOに転送したり、ピンポンバッファと呼ばれるEndpoint 2個分の大きさのバッファを用意してFrameごとにすり替える方法などがあります。私たちがよく使用しているTAS1020BではCircular Bufferという方式でポインタ(バッファメモリアドレス)を操作して、バッファメモリを帯のようにつなげて一周させるという方法を採用しています。この方法は少ないメモリを有効に活用するためにはいい方法ですが、読み出しポインタが書き込みポインタを追い越してしまわないように気をつける必要があります。

  USBマイコンはAudio DataをBufferやFIFOに取り出したあと、Audio DataをI2S(LPCM)に変換して決められた間隔(サンプリング周波数・fs)で正しい順序で送り出さねばなりません。たとえばfsが48kHzの場合には20.8333μS間隔で1mS以内に48組のAudio Dataを送り出す必要があります。USB Audio Stream伝送の最大の難点はこの部分で、1mS間隔でPacketが届き、しかも1mSのうちのどの時点で届くかは決まっていないにもかかわらず、次のFrameまでにこのPacketを取り出しておいて、次のFrame期間内に一定の間隔(fs)で送り出さねばなりません。したがってUSB 規格書の5.12.4.1章で説明されているIsochronousのAsync,Sync,Adaptiveの各Mode bitに関係なく、USB AudioのOut転送はこのルールを守らねばなりません。そして音楽データの順番が狂わないよう、また途中で欠落しないよう各Frame(SOF)とI2SのLRCLKの最初のエッジの同期を取っておく必要があります。

 もうすこしわかりやすく説明するために図-36-2を示しておきます。FIFO-Bufferは同図のように大きなタンクと考えることができます。約1mSおきに上部からバケツで水(混じりあわないで順番は守られると考えてください。)がザバッ、ザバッと注入されます。下の取り出し口から一定の速度(fs)で4単位(16bit)もしくは6単位(24bit)一組で順番とおりに途切れることなく取り出しているのと同じことです。48kHzや96kHz、192kHzのように整数の場合はひとつのFrame(1mS)の間に送り出さなければならないAudio Dataの組も整数(割り切れる)なのでまだ問題は少ないのですが、44.1kHzや88.2kHzの場合は割り切れないので難しくなります。以前にも説明しましたが、44.1kHzの場合には44組のDataが入ったPacketが9frame続けて送られた後、45組のDataが入ったFrameがひとつ送られます。要は10mSの間に441組のDataを送り出せるように辻褄を合せているわけです。88.2kHzの場合は88組のFrameが9個と90組のFrameが1個で10mSの間に882組となるようにUSB上に送り出されます。

Z36-2

<図-36-2 USB上のIsochronous PacketとAudio Data Stream(I2S)の関係>

 Windowsのusbaudio.sysではWindows Meあたりから改良されUSBスタック上に10mS分のAudio Dataを積み上げておくような仕様になっています。44.1kHzの場合は441組のAudio Dataを積み上げておくわけです。それまでは2ないしは3mS分のスタックしかなかったため再生時にブツ、ブツという音がすることがありましたが、10mSとすることにより44.1kHzや88.2kHzのAudioStreamに対応しやすくなり改良されていたわけです。

 USB Isochronous Packetで送られてきたAudio Dataは単にメモリ上の連続したbit列でしかありません。これをUSBマイコンがI2S(LPCM)のDataとして整列させるためには各Ch.あたりのbit数と順番をあらかじめ知っておく必要があります。また、fsも知っていなければI2Sデータを作りだすことができません。Network Audioの場合やFlash Memory Audioの場合はWAVファイルやAIFFファイルなどの楽曲ファイルのヘッダ部も一緒にDevice側に送られてきますので、Device側のマイコンはヘッダの情報を読み出してfsやbit数、Ch.数などの情報を得ることができます。また、一般的にはWAVなどの楽曲ファイルとは別にタイトル名、各トラックの曲名、時間(TOC情報)、アーティスト名などを含んだメタファイル(iTunesやMediaPlayerなどアプリケーションによって独自の形式です)やジャケット写真などのjpegファイルもDevice側に転送されてきます。しかし、USB AudioではAudio Dataだけしか転送されませんので、USB Device側のUSBマイコンは他の方法でbit数やfsを知る必要があります。

 この方法については次回で。昨年、長期間お休みをさせていただいている間にいただいたYHさん、「えるえむ」さんからのコメントに対する回答は今後の説明のなかで行わせていただきます。

#35 番外編 CES2010

0 comments

Posted on 15th 1月 2010 by admin in ものつくりの現場から

 今年もCESに行ってきました。今週一杯はSanta Claraに滞在していますので番外編でCESで見たものの報告をします。いろんなWebで速報版がでていますので、それらに掲載されていなかったものについて触れたいと思います。

 今年のCESはSands Expo(10年前までCOMDEXの際に、私たちがBoothを出していたなつかしい展示場です)、South Hallの1/4、Hiliton展示場の1/3が使用されず、人出は12万人と昨年を7,000人ほど上回ったようですがずいぶんと縮小されていました。狭くなった分、混み合っているような印象を受けましたが主催者の作戦と思います。

 High-Performance Audio(CESでは高級Audioをこのように呼んでいます)の会場もHotelの2フロア+4室、会議フロアの一部に縮小されていました。CESは東京インターナショナルオーディオショウのように一般のオーディオ愛好者に音を聞いてもらうことが目的ではなく世界各地から来るバイヤーに新商品を見せて商談するための展示会ですので、Hotelの一室のベッドを運び出して音を出しています。そして、大声で挨拶や商談をしていますので、とてもじっくりと音を聴けるような雰囲気ではありません。 そういう中で目立ったのは、ほとんどの部屋でNoteBook PC+iTunesでUSB経由のデモを行っていたということです。商談中、CDの掛け替えを気にしなくともよい、いろんなCDを持ち込まなくともよいというメリットがありますが、PCとUSB接続できるDACやDAC内蔵アンプなどが着実に増えていることは間違いありません。また、USB-Bポートだけでなく、USBフラッシュメモリ上の音楽ファイルの再生に対応するためのUSB-AポートやWiFi(LAN)用のアンテナ、EU圏内のDVBに対応した同軸ケーブルコネクタを装備したDACやアンプも目立ちました。どうやらアナログFM放送の時代は終わりつつあるようです。CDプレーヤも何回かRippingして一致するかどうかをCheckしてから、バッファメモリ上のデータを送り出すというような製品が増えています。

 NetWork Audioなどが普及するのを見るのは、草創期からLANに関わってきた一人として嬉しく思いますが、メーカの関係者の多くが著作権保護にまるで無関心なのには心配になります。NAS内の音楽データがNetwork上に漏れ出すと止めようがなくなりますから、そのうちNetwork DACなどを作っているとWinnyの作者のように起訴されたり、Memory Bufferなどを持つDACのメーカが録音保証金を払わなければならなくなるかも知れません。

 著作権が保護されずに作曲家や演奏家、CDなどの制作者が生活に窮するようなことになれば、コンテンツが少なくなり(著作権の切れた50年前の演奏ばかりが残る)、「コンピューター、ソフトなければ、ただの箱」と同様、「DAC、コンテンツなければただの箱」になってしまいます。

(1)dCSのUSB DAC
 DACで有名なUKのdCSもdCSとしては初めてのUSB-DACを発表、デモしていました。24bit/96kHzのUSB Audio Streamにも対応しているとのことです。デモは音源がないとのことでCDを非圧縮AIFFでRippingした16bit/44.1kHzのデータをiTunes を使用してMac Proから送り出していました。他社の製品とちがうところはdCSらしく、外部クロック生成機器と接続し、外部クロックを供給しているところです。パンフレットにはUSB Audio StreamをIsochronous転送のAsyncモードを使って伝送していると記載しており、わざわざ「SRCのAsyncモードと誤解しないこと」と記述しています。ただ説明はUSBの規格書の記述そのままです。本連載で順次説明しますが実際に行われていることとは違いますので、外部クロック(fs)とUSB Streamをどのように同期させているのか興味があります。USB Audioの音質を追求するとこのような形になるのかも知れません。私たちも昨年夏にすでにDACからのfs(LRCLK)入力をS/PDIF出力のMaster Clockとして使用するUSB Transportを作成し、EUのメーカーに組込用に提供しています。

 DAC以降の機器はJeff RolandのアンプとFocalのスピーカーを使って行われており、なかなかいい音でした。ちなみにJeff Roland Gr.の部屋でも同じDAC,Clock発生器を使用してデモが行われていました。

 Model名はDebussy DACですが、まだdCSのHP<www.dcsltd.co.uk>には掲載されていません。USB->S/PDIFコンバータの方のModel名はPUCCINI U-Clockで、こちらからfs Clockを供給していました。Debussy内蔵のClockが信用できれば必要ないと思えるのですが。あまり写りがよくありませんが写真-35-1,2を参照してください。

P35-1 
<写真-35-1>一番上の段がDebussy DAC、3段目がPUCCINI U-Clock

P35-2
<写真-35-2> dCS Debussy DAC

(2)PS AudioのuPnP対応DAC(USB入力もあります)
 PS Audioの部屋ではuPnPを使用して、iPod TouchやiPhoneですべてをコントロールするDAC(Model名は PS PerfectWave DAC)のデモを行っていました。iPhoneをuPnP対応コントローラとして使用する機器で有名なものはLinn DSシリーズですが、PS Audioの製品は選曲、演奏開始、停止だけでなくDACの入力切り替えやその他の機能設定などすべて行うことができます。PCとLANで接続した状態でiPhoneからコントロールを行うためには、PCがDLNAサーバとして機能することが必要ですがWindows7の標準機能として組み込まれていますので問題はないようです。したがって、LANポートが必須ですが、PerfectWave DACではOptionでLANポートを組み込むようになっています。Network Optionなしの場合は一般的な赤外線リモコンを使用しますが、こちらはあまりおもしろくありませんでした。Digital入力はDLNA対応Network(24/192対応)、USB(24/96対応)、AES,COAX、Toslink,HDMI(ただしコネクタのみHDMIでPS Perfect Transport専用I2S入力)です。こちらは<www.psaudio.com>に掲載されていますので参照してください。

(3)MagicoのHardDisk Tranport?
 テクニカルブレインの黒沢社長と会場で出会い、「別の階(35階)でアンプのデモを行っているからおいでよ」と誘われてMagicoの部屋にいってみました。新製品の高級スピーカーをテクニカルブレインのプリアンプ+パワーアンプ4台でバイアンプ駆動していました。音源は2track/38cmのオープンリールのテープデッキとUS$60,000というハードディスクDAC(?)でした。大きさは大型のPCケースと同じで詳しい内容は不明でしたが、とにかくCD直接ではなく、HDD上にRippingしたものを再生しているというのが驚きでした。MagicoのHPにはSpeaker Systemしか掲載されいませんので、どこかの製品と思いますがUS$60,000という価格にも驚きました。

(4)ついでに
 私たちの製品、Super Speed USB(USB 3.0)対応のHostAdapter 2種類CES直前にLogo認証Testに合格し、CESのUSB Tech Zone NEC Bothで展示・デモが行われました。Logo認証Testの合格は国内ベンダでは今のところ私たちだけです。USB 3.0やUSB 2.0というのは規格名を表すというように改訂され、それぞれが下位の規格(数字が小さいもの)を含むというようになりましたので、USB 2.0対応のUSB DACと称していてもほとんどの製品が旧USB 1.0のFull Speed(12Mbps)で動作していますので惑わされないようにしてください。

 Audio Stream(LPCM)を対象とする場合はFull SpeedではIsochronous転送に従う限り24bit/96kHzが最高です。24bit/192kHzをIsochronous転送で扱うためにはHigh Speed(480Mbps)が必要となります。Boothの写真は写真-35-3,4です。

P35-3
<写真-35-3>左上のパッケージ2個が弊社HostAdapter

P35-4
<写真-35-4>右側2製品が弊社HostAdapter

 寄り道はこれくらいにしておきます。USB Audioはアマチュアでも自作できそうなので真空管アンプつくりの次の楽しみとして浮上しそうです。しかもdigitalのいいところ(誰がつくっても差がない)でEUの歴史あるメーカーが発表しているUSB DACであればそう難しくはありませんし、F/W、H/Wを正しく作れば音質面でもいい勝負ができます。Network AudioはDLNAなどライセンスが絡んでいますのでアマチュアでは手を出しにくいという問題があります。USB Audioで自作の楽しみを取り返しましょう。

 それでは、このへんで。

#34 USB Audioについて (その3 Device Descriptor編 #2)

0 comments

Posted on 8th 1月 2010 by admin in ものつくりの現場から

 2010年明けましておめでとうございます。
 本年もよろしくお願い申し上げます。

  今年はPC_AudioやUSB Audio, Network Audioが昨年よりももっと盛んになりそうな予感がします。海外のSoftware屋さんやHardware屋さんに負けていられませんので今年もCESを見に行くことにしています。また、Digital Audio関係の仕事をしている新しい半導体設計ベンチャー企業を見つけに行くために私たちの現地法人のあるSilicon Valleyにも立ち寄って来ます。

 前回はUSB機器(Device)が備えていなければならないDescriptorの先頭部について説明しました。今回はUSB Audio Device固有の部分、さらにそのAudio Deviceがサポートしているformatなどの情報が記載されている部分(Interface Descriotor)について解説します。これらのDescriptorはAudio Deviceには必須で記述を間違えるとusbaudio.sysがloadされなかったり、USB Audio Deviceとして正しく設定されません。Device Managerで見ると「USBオーディオデバイス」が登録されていないあるいは黄色の'!'マークが付けられてしまうという結果を引き起こします。 usbaudio.sysがLoadされなかった場合やUSBオーディオデバイスとして正しく設定されていない場合は、iTunesやMedia Playerなどのアプリケーション、ASIOやKernelMixerなどのミドルウェアから無視され、USBポートからはAudio Data Streamが出力されなくなります。さらにInterface Descriptorは16bitあるいは24bitというAudio Dataの分解能を指定するためにも使用されますので、この部分は非常に大切です。

 (1)Interface Descriptor #0 (Audio Terminalに関するDescriptor)

 前回の図-2を参照してください。前回はConfiguration Descriptorまで解説しましたので、46行目(申し訳ありません。前回のリストはusbviewのハードコピーですので行番号が入っていません。)、MaxPowerの次にInterface番号0に関するInterface Descriptorが記述されています。これはAudio Deviceが備えている機能に関する記述で、ClassやSub Classに関する記述、ヘッダ部、入力機能、出力機能の順に記述されています。

 最初の部分にはInterface ClassがAudioであることを記述しています。この記述が正しくないもしくは存在しないとUSB Audio DeviceとしてHostに認めてもらえず、WindowsPCの場合はusbaudio.sysがLoadされません。

 次のInterface Sub Classは表-34-1のように4種類のCodeが決められています。RAL-2496UT1の場合はVolumeや再生、停止、巻き戻しなどの制御ボタンを持っていることをHostに通知するためにAudio Control(0x01)をsetしてあります。実際にS/PDIF出力のVolumeをHostから制御したり、制御ボタンを持っているわけではありませんがTerminalに関する記述を行う場合にはこのCodeをSetしておくのが一般的です。

H34_1 
<表-34-1>Audio Interface Subclass Codes

  その次の部分はusbviewのコメント出力では"Audio Control Interface Header Descriptor"となっていますので、日本語のコメントもそれに合わせてありますが内容は"Audio Class-Specific Descriptor"(Audio Class 固有のDescriptor)です。Descriptor Typeが0x24ですので、Audio Class Interfaceに関するDescriptorであることがわかります。Sub Classは0x01ですので表-34-2からHeaderに関する記述で、その次のADC(Audio Device Class Specc)が0x0100ですので、Audio Device ClassSpec. 1.00準拠ということになります。

H34_2

<表-34-2>Audio Class-Specific AC Interface Descriptor Subtypes

 Header部の次にInput Terminal(入力)に関する記述を行います。Descriptor Sub Typeには表-34-2からInput_Terminalを示す0x02を選択してsetしています。注意すべきなのはUSBの場合、DeviceはHostに対して従属関係にあることおよび信号線がD+,D-の2本一組で方向を切り替えて一方通行の通信を行うため、HostからのRequestやCommandがないと何の通信も行ってはいけないことになっています。したがって、IN、OUTという表記もすべてHostを基準に決められており、OUTというのはHostからDeviceへの方向、INというのはDeviceからHostへの方向を示します。ただし、本Descriptorの場合は、AudioTerminalに関する記述ですので、Audio Terminalの入力、出力を規定します。したがって入力はHostからのUSB Streamingであるということを記述します。これらの関係(topology)は図-34-1を参照してください。このTopologyをWindowsやMacOSに認識してもらうためにUSB Device Descriptorを正確に記述しなければならないというわけです。Plug & Playは使う方はとても便利ですが、つくる方は大変なのです。

D34_1 
<図-34-1>USB TransportのTopology

 Output Terminalに関する記述も同じようにDescripterTypeは0x24、Sub TypeはOutput Terminalを示す0x03とし、TerminalTypeは0x0605(S/PDIF)としておきます。TerminalTypeは今のところDevice Managerなどで表示されるi-conと名称に反映されるだけで、それ以外は特に参照されてはいません。RCA-JackによるAnalog Outとする場合は0x0601をSetすればOKです。

(2)Interface Descriptor #1(USB Audio Stream 受信機能に関する記述)

 Configuration DescriptorのNumInterfacesが0x03でしたので、RAL-2496UT1は3組のInterface(#0,#1,#2)を持っているということをOSに通知しています。#0は上記のAudio Terminalに関するものでした。#1はAudioらしい、bit数、fs(Sampling周波数)などを記述したDescriptorです。このInterface Descriptorは3個のInterface Setを含んでおり、それぞれMute用(音声出力停止)、16bit Stream用、24bit Stream用という役割分担をしています。そして、これらのInterface Setはusbaudio Classのさらに上位のClass Driver(Kernal Mixer, QuickTime Player, ASIO など)やiTunesなどのApplicationから曲の演奏開始前や停止時にbit数を指定するためや、Audio出力を停止するためにSet Interface Requestで使用されます。ただし、別稿で説明しますがUSB Audioの規格では、fs(Sampling周波数)の指定はSet Interface Requestではなく、1フレームの間(1ms)に送り出されるUSB Audio Streamのサンプル数によって行われます。もし、Set Interface RequestによりUSB Audio Device側のbit数とfsを同時に指定する場合はApplicationやDevice Driverを独自仕様で作成してInstallしておく必要があります。

 Interface Set#0(AlternateSettingが0x00)は音声出力停止用のDescriptorです。この場合はNumEndpointsを0x00にSetしておき、Isochronousパケット受信用のEndpointを使用しないことを記述しておきます。Endpointが使えないため、HostはAudio Data Streamを送ってきません。

 Interface Set#1(AlternateSettingが0x01)は16bitのAudio Data Stream用のDescriptorです。Audio Data Streamを受信するためNumENdpointsを0x01にSetし、Isochronousパケット受信用のEnd Pointを使用すると記述しておきます。それに続いてAudio Streaming Class固有のDescriptorを記述します。TerminalLinkには先程、Input Terminal Descriptorで記述したTerminal ID(0x03)をSetしておく必要があります。データ形式はLPCMであること、L,Rの2ch.のStereoであること、各Ch.あたり16bitなので2バイト必要なことなどを記述しておきます。次に対応しているfs(Sampling周波数)をまとめて記述しておきます。
RAL-2496UT1の場合は44.1kHz、48kHz、88.2kHz、96kHzに対応していますのでそれぞれをHz単位で24bitの2進数に変換して記述します。Hostからのbit数やfsの指定方法については別稿で説明しますが、OSやDriver、ApplicationによってバラバラなのでDevice側としてはそれらすべてに対応しておかなければならず、Descriptorの記述をどうすべきか悩ましいところです。またコントローラによってはRAM(Endpointの数やサイズ)やROMの大きさに制限があるため、あまり大きなサイズのDescriptorは記述することができません。

 Audio Streaming Formatに続いて、Endpointに関するDescriptorを記述します。ここではUSBの転送タイプがIsochronousと記述しておく必要があります。またusbviewでは無視されて表示されていませんがIsochronousの転送モードとしてSynchronous、Asynchronous、Adaptiveの3種類のどれに対応しているかということを記述するbit fieldがあります。最近AyerのQB-9の広告などでAsynchronous転送ということが宣伝されていますが、このbit fieldに何を記述してもUSB Audio Data Streamの転送には全く変化はありません。つまり、usbview同様、usbaudio.sysやMacOSのusbaudio Driverなどもこのbit fieldを無視しているのです。AsynchronousをSetしておくと、HostはDevice側が使用するfsを知るためのrequestを発行しなければならないのですが、そういうrequestは発行されません。このあたりの話は後ほどUSB Audio Streamの転送の実際について説明します。

 24bit用のInterface Set#2に関するDescriptorがその後に続きます。内容は16bit用と比べてL,R各ch.あたりのバイト数、bit数、パケットの最大サイズが異なるだけで他の部分は同じです。

 最後には3番目のInterface(Interface Number #2)としてHID device用のDescriptorを追加してあります。これはRAL-2496UT1固有のコマンドやRequest、FirmwareをUSB経由でupdateするために必要なものです。Audioとは直接関係がありませんので説明は省略します。

 次回はこのDescriptorがHostに読み込まれ、USB Audio deviceとして認識され、楽曲の再生が開始されるまでのUSB Bus上でのやりとり、要するにbit数はどのようにしてHostから指定されるのかということについて説明してゆきます。

#33 USB Audioについて (その2 Device Descriptor編 #1)

0 comments

Posted on 22nd 12月 2009 by admin in ものつくりの現場から

 USBは簡単に1本のケーブル(USBメモリーのようにケーブル不要のものもありますが)でいろんな機器を接続するだけですぐ使える状態になるということを目標に規格化されました。USB1.0として公表される前は、MicrosoftのWinHECやintelのIDF、PCIのDeveloper会議などで提唱者のPapertさんがセントロニクスのプリンタケーブル、RS232Cのケーブル、SCSIケーブルなどの束をお坊さんの七條袈裟のように身に纏い、右手には1本のUSBケーブルを持って、「これらすべてのパラレルケーブルがこれ一本になる!」とプレゼンしていました。その時はUSBオーディオなどとは思いもよりませんでした。またAudio Video関係は放送局や録音スタジオ用などを含めてIEEE1394(i-Link)が優勢でしたので、AV分野ではIEEE1394が勝つものと思っていました。たしか当時はMIDI(ASYNCシリアル)をUSB上に移植しようというのがUSB オーディオの始まりだったと記憶しています。

 その後、1998年にUSB Device Class Definition for Audio Device 1.0, USB Device Class Definition for Audio Dataformat 1.0, USB Device Class Definition for Audio Terminal Type 1.0が制定され、現在私たちが使っているUSBオーディオの基本形が出来上がりました。これらの規格は2006年5月にそれぞれ2.0に更新されていますが、DolbyやDTS,MP3,AACなど圧縮フォーマットの取り扱いやMulti ChannelのLPCMなどの取り扱いが追加されているだけです。私たちが対象としているLPCM-2ch.に関してはRev.1.0から何も変更されていません。Terminal typeでは1.0の頃からUSB Transport用にS/PDIF outputという種別がありましたので、この種別コードを使用したUSBデバイスをWindowsに接続するとS/PDIFというアイコンが表示されます。

  USBポートに何らかのUSB機器を接続すると、OS(WindowsやMacOS、Linuxなど)がUSB機器に対してDevice Descriptorと呼ぶ機器固有の情報を提供するように要求します。その後、その情報を解析しOS内部に登録します。この一連の操作がEnumerationとかConfigurationと呼ばれ、Registryと呼ばれる内部領域に登録されます。このへんがUSB機器にとっての第一関門です。さらにOSはそれぞれのUSB機器に対応したDevice Driverをロードします。ロードする際にはRegistryや*.infと呼ばれる特別な情報ファイルを参照します。USBオーディオ機器の場合はusbaudio.sys(Windowsの場合)というDriverがロードされなければなりません。ここまで到達してはじめてWindowsではデバイスマネージャのデバイス(種類別)表示でUSBコントローラーの下にUSB複合デバイスとして、さらにサウンド、ビデオ、およびゲームコントローラーの下にUSBオーディオデバイス(Windows7、VistaではUSB機器のDevice Descriptorに記述されているモデル名)が黄色の!マークや赤のX印なしで表示されるようになります。ここまで到達するためにはUSB機器側ではOSが発行するRequestに対して応答しなければならないだけではなく、上記の3種の規格書で定義されているDeveice Descriptorの個々の内容に従って間違いなく記述されたDeveice Descriptorを返送しなければなりません。みなさん方は自分でDescriptorを記述することはまずありませんのでこれらの文書は必要はありませんが興味のある方はwww.usb.orgからzipファイルの形でdownloadできますので参照してみてください。TIのPCM2704などを使用してUSB DACを自作される場合はVendor名やModel名などが書き換え可能領域としてユーザーに開放されていますのでこれらの文書を参照されるのもよいと思います。

 実際のUSB機器内部のDevice Descriptorを読みだして表示させるユーティリティがMicrosoftから提供されています。本来はWindows DDK(Device Driver Development Kit)に含まれていてMSDNからfreeでdownloadできたのですが今は見当たりません。しかし、usbview.exeで検索するとdownload可能なサイトを見つけることができます。図-1のようにピンクに色が変わっている機器がEnumerationとCondigurationが完了している機器を示します。各機器の詳細な情報を表示させるためにはOptionsタブのConfig Descriptorにチェックマークを付けてFileのRefleshをクリックしてください。図-2は実際にRAL-2496UT1のDevice Descriptorを読みだしたものです。Device Descriptorから読みだされた情報、特にInterface Descriptorはusbaudio.sysやMediaplayer, Quicktime Player, Mixerなどでも参照され、USBから送り出すオーディオデータのサンプリング周波数やbit数が決定されます。

PCAudioBlog_22Dec2009_fig1

<図-1>usbview の EnumerationとCondigurationが完了している機器

<図-2>USB Audio Device の Device Descriptor例(RAL-2496UT1)

 したがって、Deviece Descriptorを見るとそのUSBオーディオ機器が持つ能力をすべて知ることができます。

 Device Descriptorは図-2の左側のコメントに示すようなブロックに分かれています。2番目のConnection StatusはDescriptorに記述されているものではなくusbviewが現在の接続状況を表示するために付け足したものです。先頭のDevice Descriptor部はUSB機器すべてに共通でオーディオ機器であろうがHDDであろうがキーボードやマウスでも同じ書式です。idVendor欄のVendor CodeはUSB I/Fによって割り当てられたベンダコードで私たちの会社は1412なので16進の0x0584が記述されています。その次のidProductは私たちが割り当て、USB I/Fに登録します。その下には製造者名、型番などが記述されている場所へのindexが記述されていますのでusbviewが読みだして表示しています。これらの製造者名や型番はWindowsではコントロールパネルやデバイスマネージャで表示されます。上記のようにPCM2704ではこの部分は書き換えることができますので、PCM2704を購入して自分でUSB DACを作られる方は100円くらいの256ByteのSEEPROMを追加して挑戦してみて下さい。USBオーディオデバイスとしてmy nameが表示されるのも楽しいものです。

 その次のControl転送、interupt転送用のEndpoint Descriptor 2個(入出力用)はResetなどのCommandやStatusの受け渡しのためにUSB機器が必ず備えていなければならないものです。Configuretaion descriptorも同様で、ここではBus_Poweredという記述子と消費電流の記述子に注目しておいてください。

 それに続いていよいよUSB Audio固有のInterface Descriptorが登場しますが、説明は次回以降で..