usb异步传输xmos方案现在成熟稳定，主要还是驱动的成熟，走的是标准asio方案。像甜水网比较火的Audient iD22和echo2等许多专业声卡，均采用xmos的asio方案，录音对延迟的要求极低，对音质的要求不会比回放低，xmos基本都是采用公版的驱动而不需要各家公司独立开发驱动，从这几年发展看来，驱动对各种设备和系统版本都有非常不错的表现，稳定性也很好。但延迟还是做不到fpga方案那么低的延迟，但延迟不代表音质，对于回放来说可以接受的。既然大厂的产品都采用xmos的公版驱动，大家可以diy,我几年前做过一个，对比杨菁的x-spdif还是差一点点，也许是驱动上的差距，硬件用料我还是花了点钱的。最好的输出还是aes较好，同轴输出声音差一些。

在本坛能看到这么专业的讨论真是幸甚至哉

很深奥！！！！！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

WASAPI一样可以输出DoP

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

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

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

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

看了一下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比较大。

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

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，反正。。。人耳听不出来的

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

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

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

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

是的，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？

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

共享模式下，这个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，播放软件一样能测出差异值并补正而且代码十分简单。只是相对的不那么精确，最多就是如果你在看视频的话画面“相对”更加“抖晃”而已（听音乐就完全没影响的）

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

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

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

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

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

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