usb音频传输的优劣
这是在网络上找到比较好关于usb音频传输的文章,本人只是整理!!原作者:我代表广大人民
不想特别针对人,只想对事,所以,没有把人名展示出来!
2块传输类型 支持打印机,扫描仪,数码相机等外设,这些外设与主机间传输的数据量大,USB在满足带宽的情况下才进行该类型的数据传输。
3中断传输类型 支持像游戏手柄,鼠标和键盘等输入设备,传输量小,无周期性,但对响应时间敏感,要求马上响应。
4同步传输类型 支持有周期性,有限的时延和带宽且数据传输速率不变的外设与主机间的数据传输。该类型要求数据的及时性,但是无差错校验,因此不能保证正确的数据传输,用于计算机-电话集成系统,音频系统,DVD等设备。(这就是问题的根源!)
当我们从电脑(usb主机)向u盘拷贝(usb设备)电影的时候(单向)
Usb主机对设备发出out令牌(token),设备接收令牌。(进站申请)
Usb主机对设备发出数据包。(缓慢进站)
如果设备缓存已满,设备反馈NAK讯息,主机暂停发送信息。(临时停车等待进站)
如果设备缓存空,数据成功接收,设备反馈ACK讯息到主机说明数据接收成功。(进站后广播)
Usb主机对设备发出out令牌(token),设备接收令牌。(随手拿来别人的实验报告)
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高清需要用光纤去传输了哈!
我们可以简单理解,一个高速处理芯片能力强在其处理速度,如同cpu。
比如我们常见的TI PCM2704 芯片,这个芯片的能力上限就是16bit 48Khz,最渣渣的设备都用这个。
稍微好点的TAS1020,可以处理24bit 96Khz,例如MF的vlink1 2代
现在为了能够处理更大带宽,必须使用单片机,例如成熟的XMOS解决方案V-LINK192,stello U3都是这个,包括musiland的md11 md30的usb部分
再添加时钟信号的时候有3种方式:1同步(synchronous),2适应(adaptive),2异步(asynchronous)
同步的时钟信号就是从usb主机(电脑)那边接收时钟,然后加入处理。这个信号经过垃圾导线和接口的传输(外加上本来素质很差),其恶劣程度可想而知。雪上加霜的是,该信号是5Mhz的,当dac芯片接收的时候,还需要强行进行44.1Khz的转换,非整数倍转换带来的就是严重的失真!
错!
看好了,独立的时钟。最后还是要有一颗时钟的,而这颗时钟的好坏,直接影响时钟信号的精确。某些恶劣厂商直接用了usb芯片自带的晶振作为时钟,实在是偷工减料!某fiio就是说你!
一颗优秀的TCXO晶振并不难找,可是价格,呵呵,不小心就一百多美刀,不是良心厂谁会为了素质牺牲下油水呢?
第二,关于晶振的部分,很多时候晶振只要性能参数够就行了,光看参数不能说明什么的。USB传输的频率还不是特别高,晶振的要求不需要那么严格。晶振本身的目的是参与混频,实现频率的搬移,只要没有导致基带的相关带宽被展开太严重,是没有多少问题的。
同样,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对其影响较大。
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.
可是,你的结论本来是有问题的呢!!
from: http://blog.sina.com.cn/s/blog_6ad1b97b0102v11c.html
usb音频传输的优劣相关推荐
- linux soundwire usb,soundwire server(无线音频传输软件)
soundwire server是款不错的无线音频传输软件:该软件主要是在电脑端运行,可以将安卓设备转变成为无线耳机,无线扬声器,这样就会对用户的声音体验加强:也支持将电脑上面的所有音乐.音频等传输到 ...
- STM32F105 实现USB BULK传输
基于STM32F105 实现USB-BULK传输 由于项目需要,需要USB来传输,之前试的HID模式是已经调通,HID基于中断传输,一毫秒侦测一次,每次的传输量为64字节,一般传输量小的可以采用这种模 ...
- STM32 USB音频麦克风实现
STM32 USB音频麦克风实现 调试工具 资料书籍 音频描述符中的简称及分类 接口描述符 STM32配置 实现部分 如何使用 测试正弦音频 测试工程 USB缓冲区设置 H7的HAL库USB问题 参考 ...
- USB声卡驱动(二):USB音频设备描述符
USB声卡驱动(二)USB音频设备描述符 本篇笔记,分两部分,第一部分,是基本知识的记录.第二部分是一个实际的例子. 一.基本知识 一个音频设备(Audio Device)含有多个音频功能(Audio ...
- MS2109 HDMI转USB 高清视频传输方案
MS2109 HDMI转USB 高清视频传输方案 MS2109是一款高清视频传采集晶片,内部集成USB2.0控制器和数据收发模块,HDMIRX模块和音视频处理模块.MS2109可以将HDMI接口输出 ...
- 基于MT7688AN模块开发板WiFi路由方案无线音频传输WiFi音箱测试
无线路由解决方案无损WiFi音频传输测试 基于MT7688AN模块开发板WiFi路由方案无线音频传输WiFi音箱测试 L107物联网路由器模块是基于联发科MT7688或MT7628芯片组.该模块只需要 ...
- uvc音频传输协议_蓝牙中的三种音频编码:Apt-X、SBC、AAC,请问分别有什么区别?...
Apt-X在理论上声音保留的细节会更多,但需要购买对应的使用授权:SBC是A2DP蓝牙音频传输协议强制规定的编码格式,音质比MP3差:ACC是杜比实验室为音乐社区提供的技术,音质比SBC好.详细介绍如 ...
- A2DP和AVRCP蓝牙音频传输协议
1.A2DP全名是Advenced Audio Distribution Profile蓝牙音频传输模型拹定.A2DP 规定了使用蓝牙非同步传输信道方式,传输高质量音乐文件数据的拹议堆栈软件和使用方法 ...
- 台湾SSS鑫创SSS1700替代Cmedia CM6533 24bit 96KHZ USB音频编解码芯片
台湾鑫创在2021年推出一款芯片SSS1700可以替代兼容CM6533,不管在音质和兼容性方面都优于Cmedia CM6533,且SSS1700外围电路较简单易设计,芯片成本比Cmedia CM653 ...
最新文章
- 第一次上计算机课日记500,第一次上网课作文500字
- Stata 17 for Win 最新中文附详细安装教程
- 实践:使用FLANN.LSH进行检索
- 用 Visual Studio Code 在 macOS 上创建首个 ASP.NET Core 应用程序
- 【2018.3.24】模拟赛之五-ssl1864 得分【dp,贪心】
- [js] document.domain的作用是什么?它有什么限制?
- 使用c# openfiledialog谨记的事情
- (四)训练用于口罩检测的YOLOv5模型
- 简单查询(1.普通查询2.条件查询3.模糊查询4.排序查询5.统计查询(聚合函数)6.分组查询7.分页查询)...
- mysql hive 安装 配置_hive 安装配置部署与测试
- cmd设置mysql初始密码_windows下mysql初始密码设置
- ECMAScript 6细说转码的常见的几种方案
- 冒泡排序(Java)(完整代码)
- 微信开放平台与微信公众平台的支付关系
- 希腊呼吁欧委会增加欧洲网络与信息安全管理局预算
- 会议论文投稿到接收流程【手里有粮心中不慌】
- 什么是5G技术-认识5G
- 厦门大学计算机系录取分数线贵州,贵州省多少名可以进厦门大学?附厦门大学近三年录取分数线...
- 狗生活在陆地上 java,第四晚,生活在陆地上的鱼
- H5后台读写CAD文件
热门文章
- 短视频变现难,奖励看广告的用户会不会是一个好办法?
- CV17 HOG特征提取算法
- 通过Intent.ACTION_NEW_OUTGOING_CALL拦截电话拨号
- 前端常用代码片段(四)
- java 实型常量_Java常量(七)
- Uos窗管开发IDE介绍.VSCode
- The requested URL /lastid was not found on this server.
- 信号分选c语言,一种新的雷达信号分选方法
- 科普一下 什么是脚本 我来做一个简单解释
- CentOS 6 nagios安装与监控