应F大建议，把我另外一贴回复DAC工作过程和影响因素发一下

andygaof

黑袍雷斯林 发表于 2017-2-25 23:15
All USB transfers carry a CRC (checksum) that indicates whether an error has occurred ，所有算法， ...

可以是一回事，PHY芯片集成与否是另外一回事。

qq1653304183

黑袍雷斯林 发表于 2017-2-25 22:51
http://www.xmos.com/fundamentals-usb-audio

业内相关人士的确基础更扎实这个没话说，但是有些时候，虽 ...

抱歉我读书少，没看错的话，这段说的是 USB Audio Class 1.0 吧？

臭名昭著的USB Audio Class 1.0早都没人用了的。

XMOS支持USB Audio Class 2.0，支持现在常提到的“USB异步传输”模式。
异步传输每次发包都会有反向应答帧，一方面表示帧正确接收，同时还要报告声卡时钟与主机（PC端）时钟的差异，以便主机端调整数据发送速率。
如果丢包，就不会有应答帧，主机端等待应答帧超时就会再次发送丢失的帧。

这就是通信中最基本的“停等协议”，这么简单的道理，用膝盖都能想出来。
有些人自称多少年通信专业经验，却连基本的“停等协议”都想不到。
如果这也能叫有通信专业经验，那我只能说你可能是假通信专业。

andygaof

qq1653304183 发表于 2017-2-26 07:33
抱歉我读书少，没看错的话，这段说的是 USB Audio Class 1.0 吧？

臭名昭著的USB Audio Class 1.0早都 ...

无线网络因为无线空中接口质量完全不能保证，传输每个包都会有ACK，但是您认为这个ACK是用PHY芯片来做的？有线网络为了提高传输效率，压根在底层就没有重传机制的设定，CRC错物理层是不管的，数据链路层报错直接丢弃，要不要重传是TCP传输层的事，传音频压根就用没有重传机制的UDP。如果您认为是PHY芯片负责重传，那你我讨论今天先放下，我没看过USB PHY的资料，但是经验告诉我PHY是绝对不会认得CRC的，你我各自找USB PHY的资料去。如果不是PHY做的那么XMOS已经明确了它不做CRC校验。你还非要争么？

cruelfox

DAC支持文件本身数据格式的情况下，播放软件就不该再滤波了吧。

夜惊风

        USB PHY是数据接口啊，负责传输协调，纠错是软件的事情，纠错重传不是PHY的任务。

        另外USB界面使用的协议是UAC1和UAC2，本身遵守USB传输协议的标准，USB界面使用的芯片一般内存都很小，误码重传的结果不是爆音就是静音，打包传输出错的概率很小，但也会有出错的时候，只要数据不断流就很难发现。

      

黑袍雷斯林

qq1653304183 发表于 2017-2-26 07:33
抱歉我读书少，没看错的话，这段说的是 USB Audio Class 1.0 吧？

臭名昭著的USB Audio Class 1.0早都 ...

那是负反馈那玩意，我还真比你熟，你把asio buff设小，放一首歌，让他时不时爆音。你能听出重传吗？就用xmos 2.0方案。。不要讲纯理论。
特别是是要求锁定精度极高的界面，经常锁定了，但是仍然时不时爆音。音频是实时流的，绝对没时间重传。

qq1653304183

黑袍雷斯林 发表于 2017-2-26 12:04
那是负反馈那玩意，我还真比你熟，你把asio buff设小，放一首歌，让他时不时爆音。你能听出重传吗？就用x ...

呵呵，那么为什么 asio buffer 调大了就不会爆音了呢？

搞不懂你是想让音质好还是想让音质差，为什么就你要把asio buffer往小了调？
因为Jitter么？别逗了，大家好多都是做技术的，不要用这么逗比的理由糊弄。

“为什么 asio buffer 调大了就不会爆音”，答案我不说，我留给你说，看你的态度。
如果无法沟通，我也不再回这一帖，没意思，就这样。

黑袍雷斯林

qq1653304183 发表于 2017-2-26 14:44
呵呵，那么为什么 asio buffer 调大了就不会爆音了呢？

搞不懂你是想让音质好还是想让音质差，为什么 ...

调大，也不是完全不会，只是爆音少，你调的特别大，你确定你能听下去。调的越大，延迟越大，特别是对于录音而言，是不可接受的。最关键的是，现在usb界面的接受端都没有能把一首歌缓存完的能力。
而且，我举这个例子，是说明没有重传，出错直接爆音。

qq1653304183

黑袍雷斯林 发表于 2017-2-26 14:55
调大，也不是完全不会，只是爆音少，你调的特别大，你确定你能听下去。调的越大，延迟越大，特别是对于录 ...

哦，是吗？

难道“调大缓冲区会减少爆音”本身不就证明了出错重传机制的存在吗？
何况缓冲区调大（过了一定门限，比如大约15ms的时间长度）后爆音完全消失，听几天都遇不到一次爆音，用的还是打印机线。

缓存区大了真的是话筒录音的问题吗？难道不是实时乐器监听的问题吗？何况15ms的延迟对于乐器录音算个事儿吗？

抱歉我看不到任何沟通的态度，这是最后一贴，完毕。

HHYYTT

buffer小而产生的爆音，两个原因，1是音频流速率不稳定，忽快忽慢，或者有断流，换句话说就是超级Jitter；2是传输有错包。buffer是个水池，相当于打点滴时的那个小罐，使供给界面的音频流协调，也是FIFO。

黑袍雷斯林

qq1653304183 发表于 2017-2-26 15:44
哦，是吗？

难道“调大缓冲区会减少爆音”本身不就证明了出错重传机制的存在吗？

你这逻辑就是混乱的。。不爆音就是重传了？  我传输的数据没错，也不会爆音。15ms不是事，那就没必要用asio了，ks ds输出一样了。

andygaof

qq1653304183 发表于 2017-2-26 15:44
哦，是吗？

难道“调大缓冲区会减少爆音”本身不就证明了出错重传机制的存在吗？

兄弟，你还是多看看文档，ASIO的buffer是这样的。里面有两个参数，一个是buffer大小，一个是延迟时间。这两个指标可以分别设定。延迟时间是从你送信号过来，多久之后DAC开始播放，这个指标用于回放可以设定的比较大，但是用于录音尤其是混音是不可以超过2ms的，否则会造成各个音轨之间的不同步。你把Lyra2设定成4ms，录音结果都不正确。第二个是buffer的大小，这个是缓存的内容。你要知道USB传输是时快时慢的，我没有仔细看过USB的文档，但是我相信应该有个流控的机制，否则没法做buffer。所以buffer大一点之后，并不是重传，而是DA芯片要数据，buffer里面通常就有。buffer小的时候DAC爆音，我认为是buffer空了造成的，DA没取到数据。你可以做一个测试，用比较小的buffer，用大小不一的音频文件，你会发现采样率和位深比较大的源文件更容易爆音，所以这个不是重传导致的，因为我个人不认为USB传输会有很高的误码率，铜线近距离传输数字信号如果误码率高，这是不可思议的，我相信您也应该认可这个观点。

你延迟时间设定比较长，也会起到类似的作用。所以你理解buffer大了就重传是不对的。任何的CRC奇偶校验，ACK控制通常是软件，至少应该是FPGA的工作，少数万年不变的可以固化在ASIC里面，例如以太网MAC层的CRC校验，这个已经不可能有什么变化了，所以才是ASIC/NP芯片去搞。而ACK这种属于协议级别的东西，尤其是带有Windows属性的ACK响应，通常情况下都是软件完成的，少数会写在NP的微码里，作在FPGA里面的都不多，一旦要做在硬件里，例如网络分析设备，网络安全设备，只要性能要求的高一点，这个设备都要大几十万，上百万。作为民用设备，尤其是小批量的民用设备，显然是采用CPU加软件才是可能的解决方案。我想如果只是HiFi使用，芯片厂家开个模，做在芯片里，成本可能都收不回。

前两天有点生气，说话有点过分，自己修行不到位，跟您道个歉。

163zhengping

andygaof 发表于 2017-2-27 23:31
兄弟，你还是多看看文档，ASIO的buffer是这样的。里面有两个参数，一个是buffer大小，一个是延迟时间。这 ...

楼主客气了，为你的人品点赞。希望大家讨论都不伤和气。

curado

qq1653304183 发表于 2017-2-25 22:25
呵呵，外行人不要以为看了两篇pdf就懂了原理了。
内行人一眼就知道的东西，外行人看多少篇pdf都不可能理 ...

我就呵呵了，每次趴骨文实验室出几篇初看貌似高大上的技术文章，HIFI新手们都被虎的一愣一愣的，结果都被论坛内行专家识破并指出是外行人在瞎忽悠，实验室的技术实力堪忧啊


反观绿坛真是藏龙卧虎之地啊，我看出来了，凤仙、东老邪等都是技术实力超高的强人

aarwwefdds

qq1653304183 发表于 2017-2-25 20:39
看过我不得不说一句。
楼主，别看XMOS里没有出错重传的机制，那是因为出错重传这件事是USB接口模块自己 ...

来自NXP员工
https://community.nxp.com/thread/101792  Carlos Neri的回复
解释了Feedback Endpoint的作用，这玩意主要就是告诉Host要发多少Sample填自己的buffer而已（也就是UAC标准中的Rate Feedback），除此之外并没有什么“应答/重传作用”在里面。另外他们的USB Endpoint都是Isochronous类 自身有CRC检测机制但不带重传机制（不像传U盘的Bulk类） 甚至某些严重带宽不足的情况下Isochronous数据包是定义为可以被丢弃的

根据文档 UAC1或者2都没有重传机制，无论是自适应也好异步也罢，UAC标准的制定者显然认为保持音频资料实时性比错误重传更重要（在实时性要求下重传是不靠谱的）。

事实上在正常/正确使用的情况下USB误码概率是非常非常低的，USB自身的抗干扰特性使得在短距离内想出错都很困难（只要是按标准做了）。如果真的出错 基本上后果就是静音/爆音。实际应用中因为每个人PC/产品质量都不一样，这问题不算太罕见，绿坛有个例子：
http://www.erji.net/forum.php?mo ... 4313&extra=page%3D1
我有个朋友也是机线出现爆音问题，换线解决了。这个就属于机线不合格的

当然了 取决于芯片/驱动实现，错的太多可能会通过其他类型的Endpoint（例如control）通知Host端使得播放中断 。

个人认为 标准制定者不是傻x 不过现实的可能性是无穷的。事情没有那么简单 但也没有很多玄学爱好者想的那么复杂

qy680ty

顶一个！

其实不同的软件播放器，对声音有不同的处理倾向，就是为了适配不同的解码-放大器-扬声器，以达到某套系统一个听感上的舒适，有时候改善幅度之大，会让人感觉仿佛是音质上的巨大提升，这种情况也是有的。。。

163zhengping

aarwwefdds 发表于 2017-4-15 06:33
来自NXP员工
https://community.nxp.com/thread/101792  Carlos Neri的回复
解释了Feedback Endpoint的 ...

虽然我不是专门搞技术的，但我并不完全赞同这个观点，如果传输是允许错误的，正如你前面所讲，无论是PC、接口、线材、驱动等等都可能产生误差导致数据错误，虽然这个错误的概率极低，但毫无疑问什么时候产生错误，产生错误的概率有多大根本不可控。
就算MP3软件对无损音频数据进行有损压缩，无论固定码率还是可变码率，最起码它也得有个规则可以遵守，也绝不是对数据可以随便抛弃和保留的对吧。
前面解释过同步传输和异步传输只是传输模式的不同，并不代表异步就可以出错，否则那个厂家也不敢开发这样的传输芯片，原因就在于它是不可控的，虽然概率很低恐怕也不行，这不符合高保真音频数据传输的目的（本来就是为更好传输而开发）。至于如何异步传输还要保证数据传输的准确性，技术上是怎么做到的，这恐怕是芯片厂家的商业技术机密，它绝对不会完完全全公诸于众，一定有所保留，否则别的芯片厂家完全可以按照这一技术原理进行技术复制和技术开发，因为这一关键技术的保留，恐怕很多人真的没有完全搞懂这个异步传输的工作原理，这恐怕是造成误解的真正原因，但从常识上讲应该不会这样，这只是个人理解。

qq1653304183

163zhengping 发表于 2017-4-15 21:54
虽然我不是专门搞技术的，但我并不完全赞同这个观点，如果传输是允许错误的，正如你前面所讲，无论是PC、 ...

因为你不是搞技术的，所以你说的完全就是YY

163zhengping

qq1653304183 发表于 2017-4-16 00:02
因为你不是搞技术的，所以你说的完全就是YY

搞技术YY的多了！技术的东西谁敢保证绝对正确，否则技术就没有发展了，只要稍懂技术的人都不会这样说。现实中见过许多的砖家，钻到已经背离常识的程度却不自知，固执的坚持自己的理论，把一切的探讨和与自己不同的观点都视为另类并加以排斥，手中有权的甚至对别人进行打击，这样的专家实则是害人害己，我们要警惕的就是这样的专家。

aarwwefdds

163zhengping 发表于 2017-4-15 21:54
虽然我不是专门搞技术的，但我并不完全赞同这个观点，如果传输是允许错误的，正如你前面所讲，无论是PC、 ...

我再说一遍 对于声卡 实时性要求远大于正确性要求。不管是什么声卡 本质上都是需要同步的 即使它的同步方式是“ASYNC”——一个数据传输Endpoint+一个Rate反馈Endpoint组成的同步系统。除非厂家自己写传输协议而不遵守UAC 否则就没有任何重传。也确实有厂商是自己写协议用Bulk来传的

UAC是个公开标准 相关档案是公开的 正常情况下厂家都要按此标准来开发 否则根据这个标准写的通用驱动程序就无法兼容你生产的声卡（看开源驱动代码也确实发现某些厂家的奇葩实现导致需要各种workaround...）。看不到厂家的驱动代码没关系 你可以去查Linux的UAC驱动实现 Linux是开源的
可在这里找到相关的源代码：http://lxr.free-electrons.com/source/sound/usb
这里是比较重要的两个部分 可以看到Linux内核是如何对待不同的同步方式以及如何决定给USB界面的数据大小。以及最重要的是 没有重传机制
http://lxr.free-electrons.com/source/sound/usb/pcm.c
http://lxr.free-electrons.com/source/sound/usb/endpoint.c

UAC本身也并不是专门为了高保真而做的标准 而它的高保真回放模式——也就是异步模式 只是其标准的一部分。在开源驱动实现中也可以明显的看到 “异步”只是作为整个USB Audio系统的一部分存在 并非什么特殊存在的玩意

你提到的MP3有损压缩，很有意思的是，MP3编码过程中可以丢哪些音频数据还真的是随意的，是由你使用的MP3编码器决定的，只要编码器最后出来的数据符合MP3标准就行。而如果不是应用了心理声学的LAME编码器的存在，MP3早就进入历史了。

MP3会丢失20K以上的高频也不过是LAME编码器应用了一个LPF而已 实际上你愿意的话这个LPF可以关 但是就使得留给20K频率以下的编码空间变的更少了