USB audio同步问题及Jitter分析
Usb audio目前已经有三个版本: 1.0,2.0,3.0 。1.0版本虽然出现的最早，但仍然在大多数产品上使用，如TI 的 PCM系列usb audio芯片，基本上都是1.0的版本。 这里有一点需要明确，usb audio的版本并不是对应usb的版本。
1. 同步传输
usb支持的四种传输机制： 控制传输，中断传输，块传输，同步传输，其中同步传输适用于实时性要求比较高且对数据误差有一定容忍的场合，典型的如音频、视频输出。当然这种实时性是以牺牲数据准确率为代价的，Usb协议里面如何保证同步传输的实时性呢？
1） 无握手机制，即不使用retry 机制，所以在要保证同步传输的质量，高质量的USB线缆是必要的
2）定义同步传输在所有传输方式里面的带宽优先级为最高
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驱动，连带播放器应用程序都需要自己动手编写，工作量就大了。
3. 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端有两个同步端点，一个用于音频数据接收，一个用于反馈实际数据发送率
4. 为什么USB Audio会产生jitter或数据丢失
1. Host太繁忙，导致Host USB的数据包未来得及在指定时间（比如1ms）送到USB buffer处。
2. Device端的USB（PHY）和audio clock（I2S， LRCLK）的clock无法精确同步，比如full speed的usb的
clock为12M， 当audio的采样率为44.1khz时，USB的clock就无法整除Audio的clock， 这样USB就无法
传送和audio 码流相匹配的数据量。
3. Device端的系统过于繁忙，使得USB收到的数据无法及时的通过DMA传到I2S controller的FIFO里，
或无法及时通知ALSA数据已经收到。
4. 如果audio的clock需要改变。
从根本上解决USB audio数据丢失的问题，就必须采用Async方式，设备端的audio clock不改变，用feedback
的方式改变host发送数据的快慢。
另外，有一个文章：
usb音频传输的优劣，可供参考
链接如下：
https://blog.****.net/imxiangzi/article/details/78473245