这是在网络上找到比较好关于usb音频传输的文章,本人只是整理!!原作者:我代表广大人民

首先,为什么要去找和整理这篇文章!?起源是在一个qq群里面想和一位q友交流。。

不想特别针对人,只想对事,所以,没有把人名展示出来!

好吧!我们开始去看看网上的专家是怎么说的。
我们思考一个问题,为何 usb 音频可能出现失真,但是 usb 硬盘却不会出现考入内容出错?区别在何方?
USB协议(协议,请对比TCP/IP协议思考)中定义了4种传输机制:1控制传输(control),2块传输(buck),3中断传输(interrupt),4同步传输(isochronous)。
1控制传输适用于低俗,高速以及全速设备。适用于少量传输,不能保证传输速率,但是保证数据的一致性。主要用于usb主机与其接驳设备之间的通信。 

2块传输类型 支持打印机,扫描仪,数码相机等外设,这些外设与主机间传输的数据量大,USB在满足带宽的情况下才进行该类型的数据传输。 

3中断传输类型 支持像游戏手柄,鼠标和键盘等输入设备,传输量小,无周期性,但对响应时间敏感,要求马上响应。 

4同步传输类型 支持有周期性,有限的时延和带宽且数据传输速率不变的外设与主机间的数据传输。该类型要求数据的及时性,但是无差错校验,因此不能保证正确的数据传输,用于计算机-电话集成系统,音频系统,DVD等设备。(这就是问题的根源!)
一个usb存储设备在工作:块数据传输<-其实很像火车进站调度 
当我们从电脑(usb主机)向u盘拷贝(usb设备)电影的时候(单向) 
Usb主机对设备发出out令牌(token),设备接收令牌。(进站申请) 
Usb主机对设备发出数据包。(缓慢进站)
此时如果令牌数据损坏,那么设备拒绝接收数据包。(假消息,直接让列车绕道,不停) 
如果设备缓存已满,设备反馈NAK讯息,主机暂停发送信息。(临时停车等待进站) 
如果设备缓存空,数据成功接收,设备反馈ACK讯息到主机说明数据接收成功。(进站后广播) 
一个USB影音设备工作:同步传输<-无良抄实验报告大学生 
Usb主机对设备发出out令牌(token),设备接收令牌。(随手拿来别人的实验报告) 
Usb主机对设备发出数据包。(不管那麽多了,开抄)
没有然后了,也就是说,如果数据过早发出,usb的缓存已满,那么将会出现不接收错误。(基友实验报告没写完)或者数据出现错误,不会反馈给主机,照常接收。(抄错实验报告)因为同步传输是周期性的接收和发送,所以一旦出现周期时间不准确的错误,那么就是数据损坏!
总结一下,只要usb传输没使用类似u盘使用的块传输模式,数据丢失很难避免,而且极度依赖前段转盘的优秀程度。去死吧“同步传输”! 
USB传输分类: 
前序 
很多人认为usb传输的音频最多是16bit 44.1Khz的CD级别的音频。其实不然。 
Lets get down to fundamentals! 
说道传输,必须要将的一个参数就是带宽(bandwidth)。 
举例来说,要想传输2声道的cd音质,所需要的带宽是: 
2 channel * 16 bit * 44100 Hz sample rate=1411200 bit/s=1.4112 Mb/s=0.1764 MB/s 
而usb2.0的带宽是480Mbps=480Mb/s=60MB/s 
即便是DSD 5.1声道 6声道2.8224Mhz 1bit的音频: 
6 channel * 1 bit * 2822400 Hz sample rate=16934400bit/s=16.9344Mb/s=2.1168 MB/s 
也是毫无压力的,不然1080p高清需要用光纤去传输了哈!
usb音频只要不改变isochronous的机制,就绝对无法避免数据丢失损坏。为何要用isochronous机制呢?这是一个历史问题。我们熟悉的spdif接口,AES/EBU接口都是基于isochronous的。即,传递的信号包含了时钟讯息。信息是有电压摆的时刻相关的。如果我们的硬盘数据传输用的是这种机制的话,估计拷贝一个电影能变成电子书了吧(笑)。为何spdif不是一个很好的接口,这个等我专门讲下jitter的时候再说。
既然我们打算将usb音频按照u盘一样的模式进行传输,那么意味着我们缺少了时钟信号。如何添加这个时钟信号,将是决定hifi度的最终影响因素。请耐心观看下下段将会解答。
既然是接收设备,那么根据其处理能力,带宽将会不同,举例来说,有usb3.0和usb2.0硬盘盒,区别,就在那颗usb处理芯片上,跟硬盘类型毫无关系。 
我们可以简单理解,一个高速处理芯片能力强在其处理速度,如同cpu。 
比如我们常见的TI PCM2704 芯片,这个芯片的能力上限就是16bit 48Khz,最渣渣的设备都用这个。 
稍微好点的TAS1020,可以处理24bit 96Khz,例如MF的vlink1 2代
常见的24bit 192Khz的芯片是Tenor TE8802,例如谷津 C11,KingRex UC192 
现在为了能够处理更大带宽,必须使用单片机,例如成熟的XMOS解决方案V-LINK192,stello U3都是这个,包括musiland的md11 md30的usb部分
其实这些芯片,都算是块传输,而不上一篇文章中提到的同步传输。他们接收的原始数据是一样的,但是区别就在于时钟信号添加的优劣。 
再添加时钟信号的时候有3种方式:1同步(synchronous),2适应(adaptive),2异步(asynchronous) 
同步的时钟信号就是从usb主机(电脑)那边接收时钟,然后加入处理。这个信号经过垃圾导线和接口的传输(外加上本来素质很差),其恶劣程度可想而知。雪上加霜的是,该信号是5Mhz的,当dac芯片接收的时候,还需要强行进行44.1Khz的转换,非整数倍转换带来的就是严重的失真! 
适应是通过一个比较电路,让芯片内置的时钟和usb时钟进行同步,然后加入处理。效果可想而知不会很好,因为依旧依赖usb主机的时钟信号。
异步,这个是最终的解决方案,芯片完全用自己独立的时钟添加处理。非常完美,无懈可击!
如果因此大家说只要是异步usb就都一个素质了? 
错! 
看好了,独立的时钟。最后还是要有一颗时钟的,而这颗时钟的好坏,直接影响时钟信号的精确。某些恶劣厂商直接用了usb芯片自带的晶振作为时钟,实在是偷工减料!某fiio就是说你! 
我们看一下各位厂商是如何处理的:
Stello u3,用了xmos 异步方案,很好但是那3颗廉价的垃圾晶振你如何向我们解释下?想钱想疯了? 
一颗优秀的TCXO晶振并不难找,可是价格,呵呵,不小心就一百多美刀,不是良心厂谁会为了素质牺牲下油水呢? 
但是如此一来真心没有low jitter的高素质数字界面了吗?如果能one box,请问为何一定要分体呢?多一个接口多一份失真! 
由此看来,我们得到了一个重要的结果,一个优秀的USB DAC,可以通吃前段(只要其处理速度可以搞定realtime streaming,那么就没有问题)。Jitter的问题在usb接收电路部分,完美的解决了数据传输带来的损失。而且这个时候,因为没有时钟信号的影响,对咸菜的要求可以说没有。只要那根usb线能够用于移动硬盘设备,那么同样能够用于PCHIFI。
大家想,如果DAC内部有一足够大的cache的话是不是能从根本解决USB传输音频失真的问题呢?
上面有说。现在就是用一个缓存来解决的。缓存不是问题,是加入重生的干净的low jitter时钟信号,这是一个难题。而且缓存不是越大越好,够用就行,看芯片处理能力。大家想想cpu的l2 cache才多大?!
另外有些朋友,可能会有这样的想发:
第一,USB传输线,即使是最差的同步传输,误码率也是很低的。基本可以忽略。

第二,关于晶振的部分,很多时候晶振只要性能参数够就行了,光看参数不能说明什么的。USB传输的频率还不是特别高,晶振的要求不需要那么严格。晶振本身的目的是参与混频,实现频率的搬移,只要没有导致基带的相关带宽被展开太严重,是没有多少问题的。
第一点,作者比较同意。但是如果是同步传输的话就不一定(当然那种已经没有了),同步传输的usb和spdif性质上是一样的,只不过编码不同那就要所谓的吃咸菜了。请参考同轴线的品质。
至于第二点,完全的错了。大家说的这个这个是基于和usb主机同步频率的时候。在异步usb传输,时钟信号起到引导数据进入后端设备的缓存中,然后后端设备重新编码,加入时钟信号。
可能大家还没有 没有明白audio jitter的原理。在数据处理和音频dac转换,这是2个概念。永远在数字层面上处理,是不会过多依赖时钟精度,只要在阈值内就好,不出错。但是dac转换的时候牵扯到一中失真,叫做time based error(不知道专业中文术语),在音频专业方面叫jitter。
下面是在网上找到关于jitter的简单介绍:
其实对Jitter这个词用在数字音频领域我们应该给它做一个限定。Jitter在任何数字传输中肯定都是存在的,但是当数字传输使用复杂的协议进行维护的时候,Jitter其实对原始数据完整性是没有影响的,就像你在线听歌,网络不稳定造成时断时续,但是你如果在听的时候将这个音频文件保留下来,那么它和原始的声音文件是没有任何区别的,不会少个0也不会多个1,这是因为网络协议维护了数字传输的通道,传错了它会重新传,Jitter(假设这里造成的原因是Jitter)厉害那就多传几次,传到对了为止,当然重传是要花费时间的,当缓冲不够时,声音就会断了。

同样,USB传输数据的时候也会重传,如果是“数据”信号,肯定是不会出错的。就像你用USB线将数据拷贝到移动硬盘,肯定是不会出错的,因为出错了它会重传。但是,很不幸的是USB对待音频传输和数据传输是使用不同的模式。

我认真研究了USB Spec关于音频传输的定义,USB组织为音频传输专门定义了一个Audio Class,使用的端点类型为“同步音频端点”(isochronous audio endpoints),而对应这个端点类型的专门有一个Isochronous Transfers的传输模式,这个传输模式的特点是“低延时,错误容忍,不重传”。大家看到这里应该明白了吧,在使用音频类型传输的时候USB是允许出错的,呵呵,所以这里就有了数字信号防干扰的需求。注意,是防干扰,远远达不到模拟信号要求的那种对信号的细微影响,毕竟数字信号只有0和1两个电平,容限是非常宽的,电平差个10%也没有什么问题。所以,大家买线的时候一定要购买有良好屏蔽的USB线,屏蔽层很重要,但线心材质就真的没必要追求了。

另外再说说USB的同步和异步传输。USB 音频使用同步传输的时候确实是跟Jitter相关的,因为USB协议会发送一个SOF(起始帧start of frame)同步每个采样包,而接受端(比如USB DAC芯片)需要根据这个起始帧来同步,也就是说传输的同步信号是从USB主机传过来的,这就跟时基的相关性很大,如果Jitter过大,数据接收就错了,USB协议允许的Jitter为正负1个音频采样率。也就是说音频数据的采样率越高对Jitter的要求就越高。异步传输的模式不需要从USB传输信号中提取同步信号,当它获取到相应的传输比特率后,由接收端产生时基信号。因此对Jitter有更好的容忍性。

最后说一下光纤接口,光纤接口最早好像是由飞利浦制定的,正式应该叫S/PDIF接口,其实包括光纤和Cable两种传输材质。光纤因为对电子干扰免疫,因此有相当的优势。S/PDIF因为主要用作音频设备,所以传输协议比较简单,因此也是无纠错的,所以Jitter对其影响较大。

上面 说的很精简,但是有几点容易误导的补充下。光纤接口同轴接口统称spdif接口,数据流包含时钟信号。鉴于大部分dac设备没有良好pll线路对时钟信号进行重新处理。同样Isochronous Transfers的传输模式可以理解为何spdif一样,方便感谢认识。
其次是对于usb异步传输方面,解释过于笼统。既然要笼统的说,那么不如简单思维。异步传输就等于把数据像u盘传输一样输送给dac,然后再dac部分重新组装时钟信号。至于容忍度,主要看添加信号的优劣程度。
  “音频数据的采样率越高对Jitter的要求就越高”这个怎么看都有电问题,感觉还是不合适。更加合适是,音频数据流量越大对jitter要求比较高,因为缓存大小是一定的,如果频繁出错,那么可以出现中断播放的情况。
说道tcxo突然想到一点
c4 陶瓷贴片tcxo
c4 陶瓷贴片tcxo 2颗 用于asrc 1颗用于dac
男人801的 陶瓷贴片tcxo
如果,加个 铷原子模块,会有帮助吗?
铷原子中仅仅是准确accuracy,可以几百万年差1 2 秒。但是我们现在讨论的问题是精确precision,也就是说,每一次报时每一次信号都和应该的差距很小。在精确这方面来说,铷钟和温补晶振tcxo区别很小,尤其是当我们见到的所谓铷原子钟是封装好的形式。进行频率调整的电路设计不好,会增大不准确性。
看到这里。可能有些朋友,已经有基本想法:
一个优秀的USB DAC,可以通吃前段(只要其处理速度可以搞定realtime streaming,那么就没有问题)。Jitter的问题在usb接收电路部分,完美的解决了数据传输带来的损失。而且这个时候,因为没有时钟信号的影响,对咸菜的要求可以说没有。只要那根usb线能够用于移动硬盘设备,那么同样能够用于PCHIFI
可能,大家会有些问题:
Jitter的问题在于数字输出与采集的过程吧?这么说采集部分的usb线不用太好也行?比如搞了个界面那需要接usb线到电脑的这根只要起到传输作用就ok了?另外数字界面的供电比如电源线之类是不是会对jitter产生影响?还有不同的供电方式肯定也有关系咯?
如果说结果的话就是usb咸菜,电源线没有影响。供电设计会有影响,但是这是每个厂家的问题,我们无法选择。
rigidsystem的人给作者回信了,说他们是同步传输的异步usb,但是有错误跟踪能力(反正软件上可以显示传输错误大小,buffer调的过小以后可以明显看出错误出现的频繁)如果是iso的话,咸菜论还是成立的。125us一波数据,加上电脑本身有100上下的延迟,后果就是有可能在几个us的窗口需要传递完数据
USBPAL uses isochronous transfer mode, but asynchronous clocking, e.g. the clock is not dependent on the isochronous bus timing.
The advantage of isochronous transfer mode are: Guaranteed bandwidth and thus lower minimal latency.
Resilience to high latency hosts has little to do with the transfer mode (bulk, or iso), but mostly with the buffer space allocated on the device and the PC. Both methods have the ability to catch up for missed packets. However, with iso transfer you are guaranteed to get a transfer “slot” every 125us, while with bulk this is not guaranteed and differs from host to host. Many host controller ICs give a preference to a single device on the bus for about a 1ms when transferring bulk data and do not poll the other devices, in order to achieve more impressive throughput numbers on benchmarks. Every host controller we know, is consistent in providing a SOF packet every 125us and thus a regular transfer for iso traffic.
The real problem arises within the OS. Some drivers block the kernel for more than 100ms. In this data from the host controller will not be read by the OS and the buffer will over (or under)flow. The only solution for this, is to replace such drivers with better behaving ones. Typical candidates are the ACPI (both bios and kernel drivers) and WLAN. But again this is the same for bulk and iso.
其实,在网上有很多像跟我qq聊天的高手一样,到最后:

可是,你的结论本来是有问题的呢!!
同样感谢你,没有你,我不会找到这个文章!!

from: http://blog.sina.com.cn/s/blog_6ad1b97b0102v11c.html

usb音频传输的优劣相关推荐

  1. linux soundwire usb,soundwire server(无线音频传输软件)

    soundwire server是款不错的无线音频传输软件:该软件主要是在电脑端运行,可以将安卓设备转变成为无线耳机,无线扬声器,这样就会对用户的声音体验加强:也支持将电脑上面的所有音乐.音频等传输到 ...

  2. STM32F105 实现USB BULK传输

    基于STM32F105 实现USB-BULK传输 由于项目需要,需要USB来传输,之前试的HID模式是已经调通,HID基于中断传输,一毫秒侦测一次,每次的传输量为64字节,一般传输量小的可以采用这种模 ...

  3. STM32 USB音频麦克风实现

    STM32 USB音频麦克风实现 调试工具 资料书籍 音频描述符中的简称及分类 接口描述符 STM32配置 实现部分 如何使用 测试正弦音频 测试工程 USB缓冲区设置 H7的HAL库USB问题 参考 ...

  4. USB声卡驱动(二):USB音频设备描述符

    USB声卡驱动(二)USB音频设备描述符 本篇笔记,分两部分,第一部分,是基本知识的记录.第二部分是一个实际的例子. 一.基本知识 一个音频设备(Audio Device)含有多个音频功能(Audio ...

  5. MS2109 HDMI转USB 高清视频传输方案

    MS2109  HDMI转USB 高清视频传输方案 MS2109是一款高清视频传采集晶片,内部集成USB2.0控制器和数据收发模块,HDMIRX模块和音视频处理模块.MS2109可以将HDMI接口输出 ...

  6. 基于MT7688AN模块开发板WiFi路由方案无线音频传输WiFi音箱测试

    无线路由解决方案无损WiFi音频传输测试 基于MT7688AN模块开发板WiFi路由方案无线音频传输WiFi音箱测试 L107物联网路由器模块是基于联发科MT7688或MT7628芯片组.该模块只需要 ...

  7. uvc音频传输协议_蓝牙中的三种音频编码:Apt-X、SBC、AAC,请问分别有什么区别?...

    Apt-X在理论上声音保留的细节会更多,但需要购买对应的使用授权:SBC是A2DP蓝牙音频传输协议强制规定的编码格式,音质比MP3差:ACC是杜比实验室为音乐社区提供的技术,音质比SBC好.详细介绍如 ...

  8. A2DP和AVRCP蓝牙音频传输协议

    1.A2DP全名是Advenced Audio Distribution Profile蓝牙音频传输模型拹定.A2DP 规定了使用蓝牙非同步传输信道方式,传输高质量音乐文件数据的拹议堆栈软件和使用方法 ...

  9. 台湾SSS鑫创SSS1700替代Cmedia CM6533 24bit 96KHZ USB音频编解码芯片

    台湾鑫创在2021年推出一款芯片SSS1700可以替代兼容CM6533,不管在音质和兼容性方面都优于Cmedia CM6533,且SSS1700外围电路较简单易设计,芯片成本比Cmedia CM653 ...

最新文章

  1. 第一次上计算机课日记500,第一次上网课作文500字
  2. Stata 17 for Win 最新中文附详细安装教程
  3. 实践:使用FLANN.LSH进行检索
  4. 用 Visual Studio Code 在 macOS 上创建首个 ASP.NET Core 应用程序
  5. 【2018.3.24】模拟赛之五-ssl1864 得分【dp,贪心】
  6. [js] document.domain的作用是什么?它有什么限制?
  7. 使用c# openfiledialog谨记的事情
  8. (四)训练用于口罩检测的YOLOv5模型
  9. 简单查询(1.普通查询2.条件查询3.模糊查询4.排序查询5.统计查询(聚合函数)6.分组查询7.分页查询)...
  10. mysql hive 安装 配置_hive 安装配置部署与测试
  11. cmd设置mysql初始密码_windows下mysql初始密码设置
  12. ECMAScript 6细说转码的常见的几种方案
  13. 冒泡排序(Java)(完整代码)
  14. 微信开放平台与微信公众平台的支付关系
  15. 希腊呼吁欧委会增加欧洲网络与信息安全管理局预算
  16. 会议论文投稿到接收流程【手里有粮心中不慌】
  17. 什么是5G技术-认识5G
  18. 厦门大学计算机系录取分数线贵州,贵州省多少名可以进厦门大学?附厦门大学近三年录取分数线...
  19. 狗生活在陆地上 java,第四晚,生活在陆地上的鱼
  20. H5后台读写CAD文件

热门文章

  1. 短视频变现难,奖励看广告的用户会不会是一个好办法?
  2. CV17 HOG特征提取算法
  3. 通过Intent.ACTION_NEW_OUTGOING_CALL拦截电话拨号
  4. 前端常用代码片段(四)
  5. java 实型常量_Java常量(七)
  6. Uos窗管开发IDE介绍.VSCode
  7. The requested URL /lastid was not found on this server.
  8. 信号分选c语言,一种新的雷达信号分选方法
  9. 科普一下 什么是脚本 我来做一个简单解释
  10. CentOS 6 nagios安装与监控