Usb audio目前已經有三個版本: 1.0,2.0,3.0 。1.0版本雖然出現的最早，但任然在大多數產品上使用，如TI 的 PCM系列usb audio晶片，基本上都是1.0的版本。 這裡有一點需要明確，usb audio的版本並不是對應usb的版本。

同步傳輸：

usb支援的四種傳輸機制： 控制傳輸，中斷傳輸，塊傳輸，同步傳輸，其中同步傳輸適用於實時性要求比較高且對資料誤差有一定容忍的場合，典型的如音訊、視訊輸出。當然這種實時性是以犧牲資料準確率為代價的，Usb協議裡面如何保證同步傳輸的實時性呢？
1. 無握手機制，即不使用retry 機制，所以在要保證同步傳輸的質量，高質量的USB線纜是必要的
2. 定義同步傳輸在所有傳輸方式裡面的頻寬優先順序為最高

反饋引入：

Usb audio的資料都是通過同步傳輸到usb device的，雖然usb host能保證如上幾點，但同步傳輸還是會有以下地點問題：
1. 主機受CPU負載影響，無法保證usb 同步資料的傳送請求間隔
2. 由於usb host與usb device時鐘不可能絕對同步，會導致usb device 端資料buff 出現 over run 或 under run

關於第二點，作以下說明：
比如PC播放一個48K取樣率的音訊檔案，假定usb host按照標準的48K 取樣率傳送資料包，假定usb device端取樣I2S介面播放音訊資料，這裡按照雙通道，16bit資料寬度來計算，I2S理想的時鐘應該為(48K * 16 *2)=1536K，但由於usb device I2S控制器的時鐘生成機制缺陷，比如只能產生1530K 的時鐘，那麼就會導致I2S的資料消耗率小於usb host的資料傳送率，最終就會出現 usb device buff over run

所以同步傳輸引入了同步機制來解決device與host資料不同步的問題。當然，如果不考慮各種相容機制，全部自定義一套傳輸機制也是可以的，如 ：

定義一箇中斷IN端點： usb device 每隔一定間隔返回自己buff的可用空間
定義一個bulk OUT 端點： usb host 用於傳送音訊資料
這樣usb host根據 中斷端點返回的device可用buff空間size，一次傳送 size的資料到device即可。
這樣也可以解決資料不同步問題，不過前提是usb device驅動，連帶播放器應用程式都需要自己動手編寫，工作量就大了。

同步方式：

USB協議定義了同步傳輸的三種同步機制：

1. Asynchronous 
2. Synchronous 
3. Adaptive 

Synchronous模式

Usb device 根據host傳送的SOF幀來同步資料的傳送。SOF幀是資料的起始幀，對於USB full speed 裝置，USB host以 1.00 ms ±0.0005 ms 的間隔傳送SOF幀，對於high speed裝置，間隔是125 µs ±0.0625 µs 。
這裡以full speed裝置為例來說明一種Synchronous同步方式。假定usb device的同步OUT端點設定的資料間隔也為1ms（即一個SOF幀傳輸一次資料），每隔一個SOF ，usb device接收一幀資料後重新啟動一次DMA傳輸，這樣usb device端的資料傳送率就依據usb host 的SOF來同步。但由於usb host資料傳送的不穩定情況和usb device自身傳送時鐘的不同步問題，任然會導致usb device buff的over 或 under，一般的解決辦法是採用resample的方式來保證usb device端的資料已穩定時鐘傳送： 在over時丟棄某些samples，under時插入某些samples。

Adaptive模式

自適應模式，即device端自動適應host端的資料傳送率。如：
1. 雖然host資料傳送不穩定，device端主動調整自身資料傳送時鐘，適應host的資料傳送率
2. device通過resample的方式，插入或者丟棄buff內的samples來保證自身資料傳送率的穩定性

Asynchronous 模式

以上兩種同步方式中原始audio資料總會有損失。而在asynchronous模式下，host會獲取device端實際的資料傳送率來實時調整自身資料傳送率。Device端能依據這一點來保證自身傳送buff的穩定性，從而解決資料同步的問題，如，host端傳送速率為48K，device反饋實際播放速率為46K，那麼主機就會調整自身傳送速率為46K。一種典型的Asynchronous同步方式如下圖：

Device端有兩個同步端點，一個用於音訊資料接收，了一個用於反饋實際資料傳送率。