USB音频声卡的时钟同步方式同步、自适应、异步的理解和优缺点

wxleasyland

一、USB的isochronous“等时传输模式”
USB音频声卡采用isochronous“等时传输模式”（有人也叫同步传输、实时传输），能保证实时传输数据，但错误容忍，出错不重传。

它是实时传输，所以USB电脑端发出多少速率的数据，USB接收端（USB声卡）就得接收多少速率。

比如电脑发送44.1KHZ的，声卡就接收44.1KHZ。

二、关于时钟同步
电脑内有一个晶振，可分频出一个44.1KHZ，进行音乐播放。

USB声卡自己得有一个晶振才能工作，它也可分频出一个44.1KHZ，供给I2S信号或DAC。

问题来了，晶振是有误差的，这两个44.1KHZ不可能完全一模一样，电脑可能是44.100KHZ，USB声卡可能是44.098KHZ，误差约50ppm，很正常的情况。

虽然声卡晶振分频出来是44.098KHZ，但声卡认为它就是工作在44.100KHZ下。

好吧，如果二者时钟独立运行，那么1个小时会误差0.2秒，会出现不同步！ 即电脑播了1个小时的数据，USB声卡实际是无法播完的，要多0.2秒才能播完。  如果声卡也要1小时播完，那这1小时就需要丢掉0.2秒的数据。

所以二者的时钟必须要同步一致才行，因此USB音频规定了一是采用“等时传输模式”，二是设备需要指定为3种同步方式之一：同步（synchronous），适应（adaptive），异步（asynchronous）。（摘自USB2.0规范）

1. Synchronous同步方式

发送端Fs locked to SOF, Uses implicit feedback(SOF)  使用隐式反馈，数据速率Fs与SOF同步

接收端Fs locked to SOF, Uses implicit feedback(SOF)  使用隐式反馈，数据速率Fs与SOF同步

二种设备的时钟都需要通过PLL与USB的SOF时钟同步（1ms一个）。这样数据速率就同步了。

可以工作在一个固定速率、数量有限的速率、或可编程速率。

2. Adaptive自适应方式

发送端Fs locked to sink, Uses explicit feedback(isochronous pipe)  使用显式反馈，数据速率Fs与接收端同步

接收端Fs locked to data flow, Uses implicitfeedforward (data stream) 使用隐式前馈，数据速率Fs与数据流同步

自适应发送端，它产生数据的速率由接收端控制，接收端提供反馈给发送端，发送端就知道目标数据速率。

自适应接收端，数据速率信息是嵌入在接收到的数据流里的，即根据一段时间内接收到的样本数量来知道当前速率值。

可工作在一个速率附近、在多个速率间选择、或多个速率段内。

发送端必须要从HOST接收明确的反馈信息，这样它才能准确生成HOST需要的样本数量。

3. Asynchronous异步方式

发送端Free running Fs, Provides implicitfeedforward (data stream)   提供隐式前馈，数据速率Fs自由运行

接收端Free running Fs, Provides explicit feedback(isochronous pipe) 提供显式反馈，数据速率Fs自由运行

（注意“提供”与“使用”的区别。“提供”是要提供东西出去，“使用”是接收东西来用）

异步发送端发送样本数据，一个帧内发送的数据量就隐性指出了数据速率。

异步接收端则必须提供明确的反馈信息给驱动程序。

注意，这里的发送端、接收端均是指USB设备，即发送端→USB HOST－电脑CPU－USB HOST→接收端。比如发送端是一个USB麦克风，接收端是一个USB声卡。

当我们用电脑给USB声卡播放音乐时，只有声卡这个接收端（设备），是没有发送端（设备）的！！  所以可以忽略上面的发送端说明。

三、分析

电脑播放器播放音乐时：是按一个固定的速率，比如44.1KHZ，发给USB的数据流速率固定。

如果USB声卡是Synchronous方式：那它的时钟将通过PLL直接与SOF时钟同步，即与电脑就同步了。

如果USB声卡是Adaptive方式：那么数据速率Fs是与来的数据流同步，即根据一段时间内的接收到的样本数量来知道当前速率值。因为电脑播放的数据速率是固定的，所以声卡的时钟就和电脑同步了，即与电脑的44.1KHZ实际时钟频率同步，把自己的44.098KHZ时钟通过PLL纠正成44.1KHZ时钟了。 如果电脑时钟是44.102KHZ，那就纠正成44.102KHZ，电脑发多快，它就收多快。

如果USB声卡是Asynchronous方式：那么Fs根据声卡自己的频率运行（名义上是44.1KHZ，但实际频率有误差，比如44.098KHZ），声卡必须反馈告诉电脑想接收的数据量，以进行流控。但电脑播放的数据速率是固定的，是按电脑自己的时钟的，不会改变，因此声卡要的数据总会偏多或偏少，时间久了都会造成缓冲区清空或溢出，从而影响播放，要重新同步下。所以用Asynchronous方式是不合适的。除非电脑的驱动程序单独编制，想一个办法以处理这种数据流不同步的情况。  这也许就是XMOS子卡需要单独安装驱动的原因。

网友文章《基于USB异步技术的高保真音频回放真相》说：

“

同步模式：USB声卡的时钟直接来自PC的Usb控制器时钟，所以这个时钟质量非常低，也受传输介质质量的影响，所以很少使用

自适应模式：声卡不断调节的时钟（调节周期是10ms）造成了很大的jitter，给声音造成了可闻的影响，所以这个方法的局限在于时钟变动引入的时钟抖动，而不在于音频数据流没有错误或再处理

异步模式：USB声卡的时钟频率固定不变，所以（时钟）质量相当好。但USB控制器时钟是固定的，频率不可调，也不会受USB声卡控制。（二者不同步）解决方法只有一个：（驱动程序）启用速率匹配器，合并一部分数据或对数据插值来减少或增加数据，间接地放慢或加快传数速度，这就意味着原始音频数据已被修改。所以，这个方法保证了时钟的质量却牺牲了原始音频数据的保真

如果采用USB“块传输模式”，市面上还没有这种产品。

”

我觉得有道理，和我分析的一致。

另外，USB传输的所有数据包内都有带有CRC校验，声卡能知道“等时传输模式”时数据是否有错，但是是没有出错重传的。

我觉得采用正规USB屏蔽线，长度缩短些，一般不会出现数据传输错误，主要还是时钟抖动jitter的问题。这是USB音频的硬伤了。

以上为个人观点。

aarwwefdds

异步模式：USB声卡的时钟频率固定不变，所以（时钟）质量相当好。但USB控制器时钟是固定的，频率不可调，也不会受USB声卡控制。（二者不同步）解决方法只有一个：（驱动程序）启用速率匹配器，合并一部分数据或对数据插值来减少或增加数据，间接地放慢或加快传数速度，这就意味着原始音频数据已被修改。所以，这个方法保证了时钟的质量却牺牲了原始音频数据的保真

闭源代码不说，开源代码里我从来没见过驱动实现了SRC。而且这种SRC是要竭力避免的

关于ASYNC和其它方式的实现区别我在这个帖子里有说
http://www.erji.net/forum.php?mod=viewthread&tid=1987631&extra=

在代码里可以看到，ASYNC和其它同步方式影响的就是“下一个包大小”
http://lxr.free-electrons.com/source/sound/usb/pcm.c

1. 1467         for (i = 0; i < ctx->packets; i++) {
   
2. 1468                 if (ctx->packet_size)
   
3. 1469                         counts = ctx->packet_size; /* 如果已经有packet_size则使用。一般在ASYNC隐式反馈，或者adaptive或者sync模式下会使用 */
   
4. 1470                 else
   
5. 1471                         counts = snd_usb_endpoint_next_packet_size(ep); /* 使用来自ASYNC显式反馈的数据决定下一个包的大小 */
   

复制代码

1. 145 int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep)
   
2. 146 {
   
3. 147         unsigned long flags;
   
4. 148         int ret;
   
5. 149
   
6. 150         if (ep->fill_max)
   
7. 151                 return ep->maxframesize;
   
8. 152
   
9. 153         spin_lock_irqsave(&ep->lock, flags);
   
10. 154         ep->phase = (ep->phase & 0xffff)
    
11. 155                 + (ep->freqm << ep->datainterval);
    
12. 156         ret = min(ep->phase >> 16, ep->maxframesize);
    
13. 157         spin_unlock_irqrestore(&ep->lock, flags);
    
14. 158
    
15. 159         return ret;
    
16. 160 }

复制代码

这个ep->freqm是由
http://lxr.free-electrons.com/source/sound/usb/endpoint.c的snd_usb_handle_sync_urb设置的，也就是处理反馈数据的函数

并且实际上，每次数据包的大小包含的sample数也是有限制的，代码里有写，XMOS文档里也明确提出来了，不是说你DAC想拿多少就能给多少的。
根据规范每个USB frame的时钟本身还有个最大jitter的限制，超过这个限制USB设备端就会完全无法与主机端沟通（out of sync 失去同步），这个限制设定本身已经考虑到了USB BUS上可能的最大时钟抖动

wxleasyland

不好意思，比较菜，程序看不来。

XMOS这个反馈机制能让电脑播放器播放得快点或慢点吗？
就是说，XMOS声卡反馈给USB电脑驱动让它发送慢一点，电脑驱动再反馈给播放器让它数据发慢一点？

播放器只能按电脑自己的时钟来播放的吧？播放数据速率是恒定的，应该是慢不下来的吧？
所以，从长时间来说，声卡要求电脑放慢一点，但播放器又慢不下来，那缓冲区肯定要溢出的。。。

aarwwefdds

wxleasyland 发表于 2017-9-17 22:31
不好意思，比较菜，程序看不来。

XMOS这个反馈机制能让电脑播放器播放得快点或慢点吗？

事实上 在要求音画同步的场合（例如看视频） 默认情况下你的时钟是跟着声卡走的。声卡驱动确实会反馈延迟信息（不只是USB而是所有声卡都会，这是强制要求），轻微的速度不匹配的结果是画面丢帧或重复帧，因此会导致画面轻微抖晃不平顺，没对比过的话是发现不了的

而在只听音乐的场合这不会带来什么问题，因为不需要做音画同步，最多只需要轻微调整一下软件的播放时间走的快慢而已

而你说的不以声卡时钟为标准而是以PC时钟为标准的软件确实有，第三方软件ReClock的默认设置下就是这么做的，这个软件可以让画面减少被动丢帧/重复产生的抖晃。但ReClock的核心机制正是像你说的SRC，这导致了不能源码输出，是否要用它其实是有争议的

看视频我个人比较推荐madvr的smooth motion frc选项，可以在不SRC音频的前提下对画面做处理和补偿。强迫症可额外用关闭了SRC功能的Reclock做WASAPI独占输出，跳过系统混音器降低一些潜在延迟的不稳定

wxleasyland

谢谢建议。看视频时，确实也有这个问题，不过人的注意力一般在看画面，对音乐要求稍低一些了。问题太复杂，还是先研究下只听音乐时的情况吧。
   
一、UAA，WASAPI
   
   下图是微软UAA架构图（参见百度WASAPI）：
   
   
   audio engine估计就是做音效、SRC之类处理的。声卡驱动是直接控制声卡的。windwos自带USB声卡驱动。
   
   可见，走shared mode时，需要先经过audio engine，再进入声卡驱动。
   
   走excusive mode时，直接进入声卡驱动。播放器播什么，就直接给声卡驱动发给声卡，不会经过任何修改、SRC。
   
   一般API接口都是走“shared mode”。而用WASAPI时可以选择用“excusive mode”，所以foobar、winamp均可另外安装第三方WASAPI输出插件。
   
mp3→播放器in插件→PCM→播放器音效插件→播放器WASAPI插件→“excusive mode”→WINDOWS内置声卡驱动→声卡
   
   我们肯定不会用音效插件。但是，这个wasapi插件的设计也很重要，它是否内部有SRC？
   
   如果声卡驱动说我只支持44.1KHZ，而播放器给的PCM是48KHZ，如果wasapi插件支持SRC，那它就SRC后再给声卡。如果不支持SRC，就不能播放了。 这与wasapi插件的设计很有关系。
   
   声卡的驱动程序一般不做SRC的事吧？声卡支持什么采样率，声卡的驱动程序就报告支持什么采样率，不做转换。

   另外，用WASAPI方式来听，确实能有提升，估计WINDOWS能对WASAPI任务优先处理，保证其速度和时效，从而时钟精度更好。

二、分析只听音乐时
   
1. USB声卡自适应方式，肯定是声卡随着PC发来的速率进行时钟调整，声卡是被动的。软件上走excusive mode，可保证数据不经过修改。  但USB时钟的稳定性、数据流的稳定性会影响声卡的时钟PLL，故声卡时钟会有JITTER。
   
2. USB声卡的异步方式，声卡必须提供明确的反馈信息给windows驱动程序，以让HOST进行流控。问题来了，这个驱动程序是WINDOWS自已编写的，它内部是怎么控制数据流的？
   
   在shared mode时，是否是让audio engine进行SRC，以进行流控？
   
   在excusive mode时，是否就是什么也不做，不同步就不同步？
   
3. XMOS之类的异步声卡，比较特殊，是需要另外安装声卡驱动，即不使用windows的标准USB驱动。然后播放器也需要安装第三方ASIO插件。即XMOS是另开了一条路，走的是单独的通道。
   
   mp3→播放器in插件→PCM→播放器音效插件→播放器ASIO插件→XMOS驱动→XMOS
   
   好吧，XMOS驱动程序没有做SRC，那ASIO插件呢？
   
   好吧，其实大家都不SRC也可以，不流控也可以，只是播放久了会有一点点不同步而已，对听歌来说无所谓的。
   

最后，有没有高手能解惑一下？

aarwwefdds

共享模式下，这个Audio Engine会做混音和SRC/FX/音量调节之类的事情（这里有些可以offload给硬件，但至少USB不支持offload给硬件）。

独占模式下，直接与声卡驱动互动。

ASIO/WASAPI之类的API本身是没有SRC功能的，不信就去翻文档，翻英文的，MSDN一大堆。这些插件也不需要实现什么SRC，要做SRC都是播放软件自己做的。

至于“单纯的播放音频”，你咋就想不明白呢，和我之前跟你说的“音画同步”的原理是一样的，无论是否含有视频正常情况下播放软件都是以声卡反馈的时间延迟为准，什么进度条什么播放时间都是播放软件以声卡的间接反馈来调整，给你举个视频的例子是让你方便理解...

而且你大可放心，PC和DAC有偏差也不会差太远，因为UAC和USB协议本身就限制了DAC时钟和Host它最大允许偏差多远。而且现代PC的时钟精度其实是很精准的，完全没有那么不堪，精度达到纳秒级别对于现代CPU轻而易举的事情。只是因为1用不上，2高精度时钟占用资源，所以不用而已

p.s.其实声卡驱动自身也不用怎么“反馈”给播放软件（不要搞混了，这里说的是驱动给播放软件反馈），播放软件自己就能测出来缓存实际空掉的时间与设定值的差异，所以说我一直说的“反馈”其实多数情况下是间接的。而这个计算在ASIO和WASAPI Event下将会更加准确因为声卡驱动直接通知播放软件什么时候该写数据了。但不要再误解，就算不用ASIO和WASAPI，播放软件一样能测出差异值并补正而且代码十分简单。只是相对的不那么精确，最多就是如果你在看视频的话画面“相对”更加“抖晃”而已（听音乐就完全没影响的）

aarwwefdds

顺带一说 bulk模式的声卡我听说是有的 穷邦弄过

wxleasyland

是的，WASAPI作为API本身是没有SRC，但foobar的WASAPI插件倒是有可能。

看了您的描述，大概知道了：

mp3→播放器in插件→PCM→播放器OUT插件→endpoint buffer→USB异步驱动→异步声卡

播放器把数据通过API接口发给endpoint buffer；
驱动程序定时从endpoint buffer取数据发给声卡，没数据了就通知播放器传数据；
声卡把数据调整量反馈给USB HOST，即USB驱动程序；
驱动程序下次就少发或多发数据；
播放器OUT插件发现自己的缓冲数据变少或变多，就让播放器调整播放速度；
这样，达到了播放器的速度与声卡同步的目的。

也就是说，播放器是按照电脑的时钟工作的，但同时也在异步声卡的影响下调整数据发送速度。

照理说异步是很好的一个工作方式，但是：

“对于USB界面自身，需要监控自身主时钟与来自主机的SOF包之间的时间，计算出偏差不断给Host反馈。并且因为Host发送速率和实际播放速率并不一致，USB界面自身需要合成与播放相关的Clock（对于德西架构的DAC 最重要的是MCLK），这个合成实现具体做法十分影响最终出来的效果，这对嵌入式开发者是一个不小的挑战。早在十年前TAS1020就已经有异步模式，但需要自己开发单片机程序，开发难度高于像现在XMOS这样的一体式方案，最终出来的jitter也没有现在的XMOS/Amanero等界面那么优异。”

也就是说，对播放器来说调整容易，但对声卡来说，要实现准确的异步反馈，电路复杂开发难度大工作量大，不容易做好，所以还不如就用自适应方式简简单单，效果还不错。  所以异步方式一直用不好，直到XMOS出来后，开发就简单多了，效果也好多了。


还有问题，就是这样的话，XMOS为什么不直接用WINDOWS内置的USB声卡驱动就好了？WINDOWS内置驱动应该支持USB音频异步吧？难道只是为了实现ASIO？

aarwwefdds

因为Win这鬼玩意在Win10之前的系统只支持UAC1而不支持UAC2。而大多数UAC1最多只能稳定支持24/96格式，再往上就不那么好使了

此外，Win10最新版已经有官方UAC2支持，XMOS可以不用再装驱动。不过如果不那么在意额外装个厂商驱动的话还是建议装。从Linux开源代码里就可以看出很多厂商的UAC2实现是不标准的，以至于内核开发者要针对各种蛋疼实现做特殊处理

另外除了厂商驱动和系统驱动以外，还有第三方通用UAC1/2驱动。

p.s.XMOS不同的厂家固件也是不一样的，有些厂家的XMOS同样可以运行于UAC1模式，此时对大多数Win10以前的操作系统也是免驱的。有些高端DAC甚至有UAC1/2切换功能

aarwwefdds

wxleasyland 发表于 2017-9-18 21:10
是的，WASAPI作为API本身是没有SRC，但foobar的WASAPI插件倒是有可能。

看了您的描述，大概知道了：

另外我曾经看自称是开发者的人说过，其实以前在专业音乐制作领域的客户（也就是厂商）更倾向于“自适应”方案，而在HiFi领域则更倾向“异步”。同样的异步方案他们给HiFi厂商，厂商就用了，但是给音频制作领域的就宁愿用“自适应”

因为自适应方案“时钟”灵活性大。异步方案在这个场景下会吃瘪：一端用ASYNC输入，另一端用ASYNC实时监听（输出）。因为有两个主时钟存在，PC此时不得不做SRC，对声音的影响很大。

UAC2引入了Clock Domain。就好了不少

另外还有一点是，在DS架构高性能DAC大行其道之前，在大家都还在用R2R做HiFi DAC的时候，时钟抖动对于DAC几乎没影响，最多只是影响抖晃率，而这个比起对DS架构DAC的影响小太多了。DS架构时钟直接参与波形还原，时钟不稳定直接导致波形还原变得不那么精确，这直接反应出来的就是各种次生噪声；R2R的话你可以想象一下就是1kHz变成了1.002kHz，反正。。。人耳听不出来的

wxleasyland

谢谢！还需要消化消化。。。。
真的要看过所有的标准，才能有这么深的理解啊。
比“我只说结论，没时间解释”的那个强多了，

wxleasyland

看了一下WINAMP的WASAPI插件YASAPI的工作原理介绍，翻译如下：

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
http://out-yasapi.sourceforge.net/

There are two sides the YASAPI plugin has to take into account:   YASAPI需要一边处理WASAPI侧，一边处理WINAMP侧
•    the WASAPI side, and
•    the Winamp side.

The YASAPI plugin implements the first two strategies, i.e. the ones based on the push model.   使用PUSH方式。
The push model, in principle, works as follows:   原理如下
1.    Query the size of the buffer shared with the audio device.  查询与声卡共享的缓冲大小
2.    Fill in completety the buffer shared with the audio device.  装满缓冲
3.    Start playing.               开始播放
4.    Loop until the track is played:   一直做如下循环直到播完
      1.    Sleep half of the time corresponding to the size of the buffer shared with the audio device.  睡眠 缓冲可以播完的时间的 一半时间
      2.    Into the buffer shared with the audio device, fill in the gap which was growing free by playing during sleep.    充满缓存，即把在睡眠时由于播放而自由生长的空白缓存进行充满。
5.    Sleep until the possibly remaining filled rest of the buffer shared with the audio device was played. 睡眠  直到剩余的缓冲数据被播完
6.    Stop playing.  停止

But the YASAPI plugin not only has to take into account the WASAPI side (the loop consisting of sleeping and writing to the audio device),   but also the Winamp side because Winamp provides the audio samples which should be played in an completely unpredictable way.    但是winamp侧提供的数据样本量也是不可预测的

The YASAPI plugin decouples the two sides by means of a ring or circular buffer.     YASAPI采用一个“环缓冲”来解决这个问题      That way,
•    Winamp can luckily write to the ring buffer whenever it likes without caring about WASAPI, and       winamp侧可以随时写入“环缓冲”，不用顾及WASAPI侧
•    WASAPI can luckily read from the ring buffer and write to the audio device wehenever it likes without caring about Winamp.        WASAPI侧可以随时从“环缓冲”读出数据，并写入声卡，而不用顾及winamp侧
According to step 2 of the push model sketched above, it shoud become clear that the ring buffer should be at least as large (or larger) as the buffer the plugin's WASAPI component shares with the audio device.    根据上面的步骤2， 可以知道这个“环缓冲”应该要至少与 插件WASAPI组件与声卡共享的缓冲大小 一样大，或更大。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－
由此可见，WASAPI插件是声卡驱动程序要多少数据，就提供多少数据，完全按照声卡的来。

而WINAMP提供给WASAPI插件的数据是按WINAMP自身的解码速度来的。

所以WASAPI插件建立了一个环缓冲来使二者不会冲突。

另外，在exclusive方式下，YASAPI不会做SRC。  在share方式下，YASAPI可以设置成SRC成系统设定的采样率。

由此，如果声卡是USB异步方式，声卡要多少数据，驱动程序就给多少数据，WASAPI插件就要补多少数据到缓存中。声卡完全是按自己的时钟自由运行！

如果声卡是USB自适应方式，驱动程序给多快的数据流，声卡就PLL适应成多快。故声卡时钟JITTER比较大。

icm

aarwwefdds 发表于 2017-9-19 09:55
因为Win这鬼玩意在Win10之前的系统只支持UAC1而不支持UAC2。而大多数UAC1最多只能稳定支持24/96格式，再往 ...

win10创意者版对UAC2的支持并不好xmos的芯片设备管理里会有惊叹号（固件读取不正常），没有asio模式不能直出DSD格式音频对高码流的DXD也支持的不好而且容易出爆音。有驱动的建议还是尽量使用驱动。

wxleasyland

200元左右的Amanero或者XMOS  USB转I2S子卡，哪个好一些呢？  看上Amanero，但肯定是非原版的。

aarwwefdds

icm 发表于 2017-9-20 10:51
win10创意者版对UAC2的支持并不好xmos的芯片设备管理里会有惊叹号（固件读取不正常），没有asio模式不能 ...

WASAPI一样可以输出DoP

另外UAC2支持已经进入正式版了，好像好了很多。虽然多少还是有一些问题

aarwwefdds

wxleasyland 发表于 2017-9-20 12:34
200元左右的Amanero或者XMOS  USB转I2S子卡，哪个好一些呢？  看上Amanero，但肯定是非原版的。

说老实话 差不多。你听不出来的

现在的DS DAC对时钟抖动的敏感度低了很多了

icm

aarwwefdds 发表于 2017-9-20 13:38
WASAPI一样可以输出DoP

另外UAC2支持已经进入正式版了，好像好了很多。虽然多少还是有一些问题

还是有问题，我就在用win10+xmos不装驱动很不好用。

rgwan

wxleasyland 发表于 2017-9-18 21:10
是的，WASAPI作为API本身是没有SRC，但foobar的WASAPI插件倒是有可能。

看了您的描述，大概知道了：

你还是没理解到点上。声卡本身使用自己独立于主机的本地时钟运行，并不需要根据主机的速率调频。

然后每隔一段时间报告主机这段时间播了多少采样。主机因此调整自己的发送速率匹配声卡的播放速率，保证声卡内FIFO正常工作。也就是说，时钟基准在声卡这里。应用程序按照声卡的节奏给声卡发数据。

PS，我写过UAC1的异步和同步模式的固件。STM32做的。事实上对于STM32这种没有APLL的芯片而言，实现异步更方便。因为没有办法去用PLL lock住USB的SOF时标，也没有办法根据USB的数据流恢复时钟。

因此，只能用独立时钟，独立时钟如果不用异步模式的话，过一会儿就要FIFO欠载啪啪响了，所以对于这种芯片，让电脑跟随声卡时钟，异步是唯一的选择。

梦冒险

win10早就开始封锁高端声卡了，硬解声卡全部强制软解。

tenglizo

很深奥！！！！！