把一个文件完全拷贝到解码器本地缓存再开始播放，就现在的技术来说，这个应该不难做到，咋就没有一家解码器 ...
不就是数播么？声音也没见得好啊{:1_121:} 激光鼠 发表于 2015-5-16 15:16 static/image/common/back.gif
不就是数播么？声音也没见得好啊
所以声音好听与否，跟是否异步，jitter大小没有必然联系。 激光鼠 发表于 2015-5-16 15:16 static/image/common/back.gif
不就是数播么？声音也没见得好啊
举个例子，罗技touch，缓存时间大概有20秒，把网线拔了，还能继续播放20秒，如果说前段的jitter会通过网线影响后端，进而影响声音，理论上拔了网线，前端已经完全没影响了，声音理应比没拔网线前更好，实际听下来并不是这样。 fanco 发表于 2015-3-20 21:23 static/image/common/back.gif
异步技术只是解决了时钟问题，但是usb音频传输数据时用的是同步传输（没有重传机制），而拷贝文件用的是批量 ...
usb音频传输有几种方式，异步一般都是采用“块”的方式，是有校验和重传机制的。 中泽洋造 发表于 2015-5-16 00:23 static/image/common/back.gif
不同咸菜的绝缘层有不同的性质，会导致不同频率的波传输速度完全不一样，输出的波形肯定跟原波形有不同，完 ...
数字通讯不似模拟通讯，对波形的容忍度很大，况且还从协议层面作了校验和纠错机制，保证100%的数据完整性。 华兄 发表于 2015-5-17 11:06 static/image/common/back.gif
举个例子，罗技touch，缓存时间大概有20秒，把网线拔了，还能继续播放20秒，如果说前段的jitter会通过网线 ...
拔掉网线以后，后台服务会不断尝试去恢复下载数据，这个动作对声音的影响，应该更大。你的听感正说明了这一点。
要比较的话，还是如白版所说：把整个文件下载到本地缓存里 华兄 发表于 2015-5-16 10:21 static/image/common/back.gif
把一个文件完全拷贝到解码器本地缓存再开始播放，就现在的技术来说，这个应该不难做到，咋就没有一家解码器 ...
有啊，很早naim有个解码器，只支持wav格式（后来好像支持了flac），就是你说的这种。内置了个存储设备，copy音乐进去后再进行解码播放，号称usb 0jitter。。。废话，他的usb只是做copy数据传输之用=-=
楼上说的对，这就是个数播。。 华兄 发表于 2015-5-17 11:06
举个例子，罗技touch，缓存时间大概有20秒，把网线拔了，还能继续播放20秒，如果说前段的jitter会通过网线 ...
电脑与逻技touch之间就是普通的网络传输，通信是有校验机制的，传输的信号是 bit perfect，数据到touch缓存后还要由touch内的CUP处理和播放。所以TOUCH之前的各个环节是不存在jitter一说的。但touch处理后不论是通过同轴还是USB(要用插件才能将USB口作为输出用），到解码器的数据不再具有校验机制，这就是为什么同轴线和USB线会影响声音的原因。异步USB虽然可以避免传输的时基误差，但由于没有校验机制，USB线本身造成的信号误差是无法避免的。 fanco 发表于 2015-3-20 21:23
异步技术只是解决了时钟问题，但是usb音频传输数据时用的是同步传输（没有重传机制），而拷贝文件用的是批 ...
文章失效了，可以再发一遍吗？ 本帖最后由 qpwu2011 于 2018-7-28 10:01 编辑
华兄 发表于 2015-5-17 11:06
举个例子，罗技touch，缓存时间大概有20秒，把网线拔了，还能继续播放20秒，如果说前段的jitter会通过网 ...
你的看法值得思考。但我想补充看法，就数播而言，数据传送工作分两部分，第一部分是从NAS等存储介质取得数据，这部分工作分段完成，有些设备每段长达数分钟，这时是不依赖数据线的（如网线）；第二部分是数播到解码器的传送，最常用的是USB线，这部分的工作原理，我不是十分清楚，是同步还是异步？如果同步工作，数据线影响就大了。
页:
1
[2]
