EZ-USB FX2LP を動かしてみる (38) USB Audio Class 2.0の音が出た

EZ-USBシリーズの前回は3月9日でした．

前回までのあらすじ
会社勤め時代にはアナログ＋デジタル信号処理屋だった平坂久門は、会社を辞めたのを契機にワンチップマイコンなどのシステム物に趣味の幅を広げつつ遊んでいる55歳のアニヲタである．
平坂は「言の葉の庭」を観て以来長らく途絶えていたオーディオ趣味が復活し、最初はサラウンドを鳴らしていたが次第にpure audioへと興味が移り変わり、AK4495 DACを自作してたりする．
ハイレゾDAC基板をコミケで売ろうかなと思ったが、コスト構造上の癌であるDCCをEZ-USBで自作してコストダウンを図ろうとしているところだ．だがそれにはUSB Audio Classという難物が行く手を遮り、人類は滅亡の淵に立たされているのであった．

-----
問題山積だとはいえかろうじて音が出たよ．まずはめでたい．まだ設計資料を公開できる段階ではない．

↓回路のお写真

↓再生アプリはTEAC Hi-Res Editor を使っている    →こちら

↓ブロック図

PCからIsochronous転送でPCM dataが送信される．
EZ-USBは内部FIFOに一旦dataを蓄積する．
FIFOは外部clockで読まれる．(8bit)
8bit dataはシリパラ変換され、I2Sバスを形成し最終的にDAC(PCM5102)へ到達．
analog信号が出力される．

現状の対応状況はこうなっている．
  windows10
  USB Audio Class2.0
  32bit 384kHzのみ
Linuxでもたぶん動くと思うのだが、検証してない．


デバドラについて
windows10のデバドラは、USB汎用デバドラで動いているらしい．汎用デバドラだとこうゆう表示になっちゃうものなの？ まぁ動くのならなんでもいいけどさ．

EZ-USBシリーズの前回で書いたように、CM6631のUAC2.0デバドラはwin10のOS標準で入っているらしい．しかしながら同デバドラはvendor固有の秘密の制御をしていて、使い勝手が悪いというか、解析不能な代物であった．

USBに詳しい人なら、デバドラとUSBデバイスを紐づけるのはVID/PIDであると知っているだろう．
CM6631のVID/PIDは、0x0D8C/0x0004 である．EZ-USBのdevice descriptorにこのナンバーが格納されておれば、windowsは自動的に「解析不能なデバドラ」を紐づけてくれてしまう．余計なお世話だやめてくれ．

今回は、USB汎用デバドラを割り当てて欲しいのでVID/PIDを変更する必要があった．
「generic audio driver VID/PID」で検索して、04D8/000Bだと汎用デバドラに紐づけされるっぽいのでやってみたら上手くいったというわけだ．


フレーム同期を失敗している
フレームとは、Lchの１サンプル＋Rchの１サンプル を指す単位である．
ここでは32bitハイレゾ音源なので、１フレームのサイズは8BYTEsだ．

USBケーブルを流れるaudio dataは、FPGAの回路によって、フレーム毎すなわち8BYTEs毎にブツ切りされ、さらに0-3BYTE目がLch、4-7BYTE目がRchに振り分けられる．

なのであるが、FIFOに積まれるdataにはフレーム区切り情報は存在しない．ブツ切りする手掛かりなど無いのだ．どこからブツ切りし始めれば良いんだい？   →フツーは先頭データからだよね．

先頭データの手がかりとしては、FIFO empty flagが消えた瞬間ぐらいしか思いつかない．FPGAはそのように実装してあるのだが、フレームずれによって再生音が砂の嵐になってしまっている．（フレーム同期がたまたま正しくなった時には音楽が再生される）


数秒に一度の頻度でFIFO emptyが生じる
Isochronous転送がしくじっている感じ．
Linuxでも同様なので、descriptorに何か問題があるのではないかと推測してる．


Sleep制御
16/24/32bitのセレクトは、interfaceのalternate settingで行われる．
すなわちこんな関係． （interface descriptorにこう記述してあるからこうなる）
  alt.0      sleep      →不要なclockを止めたりする
  alt.1      16bit
  alt.2      24bit
  alt.3      32bit

music playerアプリが音楽再生を始めたら、sleep→32bitへチェンジするのは当然の動作と言える．

それでは、music playerが音楽再生をstopした時には 32bit→sleepへチェンジするのだろうか？

USBデバイスの設計としては曲の先頭で念のためにフレーム同期したいので、曲の切れ目でsleepに入れてもらうのが嬉しい．

ところが、TEAC Hi-Res Editorの挙動をUSBデバイス側から見て判ったことは、STOP時には0000000.....が延々と送信され続けているのである．TEAC Hi-Res Editorがkillされたらsleepになる．
う～ん、そうゆう動作なのかぁ．プツッという音が出てしまうのを防ぐには有効なのかもしれない．

翌日追記
うろたえてしまう展開になった．
DACの仕様はBig Endianである．しかし、USBを通じてEZ-USBのFIFOに積まれるデータはLittle Endianなのだと判った．FPGAでLE→BE変換しなくちゃいけないよ．
判ってしまえばやることは難しくないのだが、FF数が36ヶの激安CPLDを採用する目論見が打ち砕かれたよ．エイメン

というわけでまだまだ続くEZ-USBなのでしたー

かしこ

→INDEXページ