UID181016
威望39
金钱516978
交易诚信度0
主题244
帖子61755
注册时间2005-9-10
最后登录2026-4-4
超级会员
交易诚信度0
注册时间2005-9-10
|
楼主 |
发表于 2023-3-21 06:23
|
显示全部楼层
我们思考一个问题，为何 usb 音频可能出现失真，但是 usb 硬盘却不会出现考入内容出错？区别在何方？
USB协议（协议，请对比TCP/IP协议思考）中定义了4种传输机制：1控制传输（control），2块传输（buck），3中断传输（interrupt），4同步传输（isochronous）。
usb音频传输的优劣
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突然想到一点
usb音频传输的优劣
c4 陶瓷贴片tcxo
usb音频传输的优劣
c4 陶瓷贴片tcxo 2颗 用于asrc 1颗用于dac
usb音频传输的优劣
man801的 陶瓷贴片tcxo
usb音频传输的优劣
如果，加个 铷原子模块，会有帮助吗？
铷原子中仅仅是准确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聊天的高手一样，到最后：
usb音频传输的优劣
可是，你的结论本来是有问题的呢！！
同样感谢你，没有你，我不会找到这个文章！！
from: http://blog.sina.com.cn/s/blog_6ad1b97b0102v11c.html
专栏目录
android双usb麦克风,USB麦克风24bit192K单麦芯片方案-SSS1630
weixin_35914724的博客
659
SSS1630支持24bit/192KHZ采样率，应用USB麦克风方案，单麦克风输入，语音输入转USB方案，性价比高广泛应用于Windows/MAC/AndroidOS X二、SSS1630,3S1630的主要功能特点符合USB规范v2.0全速兼容USB音频设备类规范V1.0支持44.1kH/48 kHZ/96kHz，16位/24位采样率(EEPROM选...
1.USB协议简介
热门推荐
songze_lee
9万+
最近学习usb相关的知识，一直感觉入不了门，看《linux那些事儿之我是usb》，对usb协议也不是很熟悉，没能坚持看下去，直到看了《圈圈教你玩usb》一书，把自己的兴趣立马提了起来，大牛圈圈用51单片机实现了usb鼠标键盘等设备，让人非常佩服，51单片机自己还是很熟悉，大学玩了四年单片机，单片机来实现立马感觉亲切了许多，决定先从单片机入手学，后面再看linux那些事儿之我是us...............
主流无线音频传输方案
最新发布
weixin_43582118的博客
616
文档介绍了无线音频传输方案的分类，介绍了AC7016C在无线音频方案的应用、参数和原理
USB Audio Class （UAC）音频解读规范
程序手艺人 - 嵌入式音频技术之旅
4097
USB音频非常流行，原因之一是USBAudio是USB标准的一部分，因此原生模式驱动程序可用于所有流程的操作系统(WinLinuxMac)。USB音频是一种灵活的解决方案，因为任何PC都提供USB接口。
四、音频如何从USB输入输出
future_sky_word的博客
4590
USB接口进行音频的输入输出
Android开启usb音频输出,Android手机开发人员选项->选择USB配置->音频源，如何使用？...
weixin_28788593的博客
3320
更多帖子此版本的专家点: 24553GitHub绑定GitHub第三方帐户获取鸿华2018年12月，大版移动开发专家的月度排名第一2018年11月，大版移动开发专家的月度排名第一2018年10月，移动开发大版本中的第一个专家月度排名2018年3月，大型移动开发专家月度排名第一2018年1月，大版本移动开发专家的月度排名第一2017年12月，移动开发大版本专家的第一个月排名2017年11月，移动开发...
我来说说究竟什么是“USB异步传输” (Asynchronous USB)吧
chinaunixj的专栏
1万+
讨论贴： http://www.erji.net/read.php?tid=767228&fpage=0&toread=&page=1 参考资料： http://www.usbdacs.com/Concept/Concept.html A: 废话不多说，直奔主题吧。 对于USB音频传输，有一个规范，叫做“标准USB音频规范”。这个规范有什么用处和好处？ 它的用处就在于，实现了
usb audio（2）--异步传输方式描述符说明
xjq163的专栏
4034
很多人都以为usb audio 1.0不支持异步，如XMOS的驱动，都是是usb audio 2.0的版本，其实usb audio 1.0中已经支持了反馈。现有的操作系统中，win10以前都只支持USB audio 1.0，并且windows下的usb audio 1.0都不支持异步方式。Linux 支持 usb audio 1.0与2.0，支持1.0，2.0下的异步方式。这里讲的异步方式的实现主要
基于WinUSB的异步方式bulk传输的稳定性问题
zhuangwf的专栏
1018
某项目中，设备与PC之间通过USB Bulk模式进行数据传输，PC端的APP跑在Win10上，跟设备通信这部分原本是基于libusb开发的，运行稳定。后来考虑到PC端APP只有for Windows一个版本，使用libusb的意义不大（libusb最大的好处是跨平台），因此打算去掉libusb，直接基于微软WinUSB实现与设备通信（在Windows上libusb缺省也是基于WinUSB实现的）。 libusb中用于bulk通信的API函数libusb_bulk_transfer有一个timeout参数，
USB声卡噪音问题，USB声卡中文名设置，基于STM32F411
Fairchild_1947的博客
1583
解决基于STM32的声卡的杂音，噪音问题。显示USB设备名称为中文。
音频属性详解(涉及采样率、通道数、位数、比特率、帧等)
郎涯技术
4万+
音频属性详解，包括采样率、通道数、采样位数、比特率、帧、周期、交错与非交错模式的存值方式等。
USB声卡之时钟模式分析
Eric
1546
USB音频声卡采用isochronous “等时传输模式”（或者同步传输、实时传输），能保证实时传输数据，允许一定误码率，出错不重传。 等时传输模式 实时传输，即 PC端发出多少速率的数据，USB接收端（USB声卡）就得接收多少速率。 比如电脑发送44.1KHZ的，声卡就固定接收44.1KHZ。 关于时钟同步 电脑内有一个晶振，可分频出一个44.1KHZ，进行音乐播放。 USB声卡自己得有一个晶振才能工作，它也可分频出一个44.1KHZ，供给I2S信号或DAC。 问题来了，晶振是有误差的，这两个44.1.
USB传输方式
格物致知的专栏 [音视频编解码 网络协议 计算机视觉 计算机图形学 图像理解 语音识别 机器学习 模拟电路 传感器]
415
针对设备对系统资源需求的不同，在USB规范中规定了4种不同的数据传输方式：(1)等时传输(Isochronous Transfer)方式。该方式用来连接需要连续传输，且对数据的正确性要求不高而对时间极为敏感的外部设备，如麦克风、音箱以及电话等。等时传输方式以固定的传输速率，连续不断地在主机与USB设备之间传输数据，在传送数据发生错误时，USB并不处理这些错误，而是继续传送新的数据。(2)中
钰群USB3.0音视频信号采集
浩瀚之水的专栏
430
EJ产品介绍 EJ511是钰群eEver一颗将RGB和I2S音视频信号转换为UAC/UVC格式的采集芯片，它采用USB3.1 GEN1的速率进行视频捕获，最高可支持1080P60fps全高清视频采集。 当EJ511连接到USB2.0平台时，它可支持MJPEG压缩，对数据流进行带宽限制，从而保证高视频质量的捕获采集。 EJ511可以记录各种来源的原始内容，，如智能设备，摄像机，机顶盒，DVD/BD播放器和游戏机。EJ511使用OS本机的UVC/UAC驱动程序，并与Windows、Mac OS、Linux操
Linux USB驱动分析(一)----USB2.0协议分析
DREAMER
4022
原文地址：http://blog.chinaunix.net/uid-25445243-id-4040449.html
USB audio同步问题及Jitter分析
zhaoshuzhaoshu的专栏
3050
Usb audio目前已经有三个版本: 1.0,2.0,3.0 。1.0版本虽然出现的最早，但仍然在大多数产品上使用，如TI 的 PCM系列usb audio芯片，基本上都是1.0的版本。 这里有一点需要明确，usb audio的版本并不是对应usb的版本。 1. 同步传输 usb支持的四种传输机制： 控制传输，中断传输，块传输，同步传输，其中同步传输适用于实时性要求比较高且对数据误差有一定容...
android设置USB音频采样率,使用libusb在UCG102上设置采样率
weixin_39902608的博客
525
我正在使用libusb与UCG102(Guitar Link)USB设备通信，并且在使用同步控制请求设置采样率时获得-9(LIBUSB_ERROR_PIPE，这意味着不支持参数) . 以下是LIBUSB记录的基本请求详细信息，您无法看到实际采样率，因为它按照规范在3字节缓冲区中：03-02 14:33:13.173: I/LIBUSB(9480): bmRequestType=22, bReque...
USB开发---最高采样率USB Audio的描述符支持DSD 1536K
代码行者-音频技术开发
1566
USB开发—最高采样率USB Audio的描述符支持DSD 1536K 一、背景 前段时间根据客户要求，做一个HIFI级的USB Audio声卡设备。支持ASIO驱动。采样率达到USB2.0所能支持的最高采样率1536K。 采样率范围44.1k - 1536k。同时支持DSD跟Dop模式，采样率范围DSD64 - DSD1024。支持24bit跟16bit的采样深度。客户那边是用Fpga解码的。具体我这边也没有参与。USB Audio是我这边设计的。也花了不少的时间。下面将描述符分享出来供大家参考学习。有不
CS201 USB TYPEC音频控制芯片|TYPEC拓展坞音频芯片|CS201参数特性
qq1659747718的博客
437
CS201是一款USB TYPEC音频控制方案芯片，主要用于USB Type-C拓展坞，USB Type-C 耳机、USB耳机、USB音响、USB麦克风等产品，实现USB 接口产品的音频是输入或者音频信号输出播放。
浅谈 USB Audio（3）------ 多采样率设计
weixin_38426553的博客
1520
USB Audio 多采样率设计，1.0和2.0是有很大的区别，本章将浅谈两种标准的设计方法。 1.USB Audio 1.0 标准设计： 首先 |
|
楼主: 老浦东
[复制链接]
京公网安备 11010602010207号
( 京ICP证041102号，京ICP备09075138号-9 )
狗仔卡
发表于 2023-3-16 23:47
发表于 2023-3-17 14:52
