玩ES9016过程之三，384K和ESS的ASRC

定音鼓 · 发表于 2012-7-6 19:18

本帖最后由定音鼓于 2012-7-7 02:34 编辑

今天试验看看ES9016是否可以解384K码。
用IIS信号接入ES9016，傻瓜方式果然方便，啥都不用设置，接上384K信号直接出声，但有削波现象发生，调整比特长度以及BYPASS FIR滤波器都没有改变削波结果。
用0db信号测试，将384K信号音量降低-12db才与44-192K时候一致，这+12db哪里来的？不得其解。
再次试图解决CM6631（ASUS固件）和个别CD机声音断续问题。
CD机其实没有问题，是因为前天频率显示没做好，因为频率显示变化以为是有问题。
给CM6631换晶振，加强滤波，问题还是有。
更详细的情况如下：
播放或者切换44.1、88.2和176.4这三种频率，声音经过1分钟趋于稳定，不再断续。因为以前做过字时钟同步方案，测试过PLL，同步确实需要一个几到几十秒钟稳定过程。所以不足为奇。
但是48、96和192K却始终稳定不来，声音始终断续。
再来说ESS ASRC，之气鄙视过ESS还用ASRC，不过仔细看他们的介绍，说他们的ASRC与传统的ASRC不同
ESS原话如下：
The algorithm to do this is ESS's patented “Asynchronous Sample Rate Convertor” and is not the same as the previously known techniques
根据上述情况看他们的ASRC确实与以往不同。CM6631（ASUS固件）接CS8416的PLL方式和接AD1896的ASRC方式，都很正常，而用ESS的却出现状况。
想想看，抖动分几种，这里只说相位抖动和周期抖动，显然ESS的ASRC解决的是相位抖动，而对周期抖动无能为力，这就对了，如果连周期抖动都解决了那只能是传统的异步重新采用。
传统CD机，时钟是固定的，所以，周期抖动不明显，但自适应方式的USB传输，如果时钟用简单的PLL时钟，那周期抖动在所难免。

这里说明两个问题：
1.ESS的ASRC与众不同；
2.自适应USB...接受楼下朋友的批评，改下说法：“不使用本地时钟的异步USB方式是真正的异步吗？这种异步好在哪里？起到什么作用？”

玩ES9016过程之二，SARBE是照妖镜？妖怪是jitter!
http://bbs.hifidiy.net/viewthread.php?tid=661373

定音鼓 · 发表于 2012-7-6 19:20

384K解码有待继续试验

59401 · 发表于 2012-7-6 22:01

本帖最后由 59401 于 2012-7-6 22:05 编辑

看来兄弟对于CM6631的工作模式还是耿耿于怀啊。

以下是用工具查看到的华硕0109固件的USB描述符的输出端点信息，其实我也不全懂，但看到“Synchronization Type: Asynchronous”显示字样还是能理解到不少的。

--------------------------

59401 · 发表于 2012-7-6 22:06

这里再次警示大众，下结论要严谨才行。

lszyc · 发表于 2012-7-6 22:56

USB音频传输的水还是很深的，这个帖子可能还有点参考价值：“http://www.erji.net/read.php?tid ... ;toread=&page=1”。

59401 · 发表于 2012-7-6 23:22

USB音频传输的水还是很深的，这个帖子可能还有点参考价值：“”。
lszyc 发表于 2012-7-6 22:56

既然遵循UAC，那应该以协议为依据，异步还是自适应，读USB描述符我觉得应该比以某现象为依据来做推断更严谨。

raisechina · 发表于 2012-7-6 23:57

我大概知道声音断续啥问题，可能是音源有样频率不准的问题，比如CD是44.1KHZ，而却输成了44.105KHZ了，这5HZ如果是一直固定的话，并不产生JITTER，而只能说采样频率不准，不准则导致声音断续，所以做异步重采样才能解决问题

raisechina · 发表于 2012-7-7 00:14

简单的说，可能就是把44.1005KHZ的输入采样，没有异步，而锁相环锁成了44.100KHZ了，这5KHZ导致声音断续

定音鼓 · 发表于 2012-7-7 01:33

这里再次警示大众，下结论要严谨才行。
59401 发表于 2012-7-6 22:06

呵呵，警示什么？我不管什么异步到底是什么？但是，不使用本地时钟的USB叫异步，我还是坚持，那不是真正的异步

定音鼓 · 发表于 2012-7-7 02:08

简单的说，可能就是把44.1005KHZ的输入采样，没有异步，而锁相环锁成了44.100KHZ了，这5KHZ导致声音断续
raisechina 发表于 2012-7-7 00:14

你没仔细看我写的开发过程，前面提到乐之邦频率偏差很大，但没有断断续续现象。
测试频率不是常规音频是否有断续情况发生很简单，马上测试.
用本地时钟的USB的方案，88，2K音频使用22.5792M本地时钟，LRCLK是88.2K，换成16.9344M，这时LRCLK变成66.XXK，声音变慢了，但没有间断发生。
使用本地时钟工作方式，电脑端播放器将根据USB接收端的本地时钟同步工作，比如上面的试验，用foobar播放，用手机秒表大概测量下，实际30秒钟的时间音乐被拖慢到40秒。这就对了，这就是我们追求的完美jitter free，这里没有像CD机那样只能按一种固定频率输出给你数据，你想jitter free只能重新采用，否则别想！

定音鼓 · 发表于 2012-7-7 02:27

看来兄弟对于CM6631的工作模式还是耿耿于怀啊。
59401 发表于 2012-7-6 22:01

呵呵，还真没耿耿于怀，CM6631是什么方式，爱谁谁，能解192K，谁关心什么方式。
CM6631很好，成本低，没有不用的道理。
耿耿于怀的是帮别人开发怕最后因为这个扯皮耽误时间，结果就是耽误收益，哈。

Jeff_Zhu · 发表于 2012-7-7 09:29

本帖最后由 Jeff_Zhu 于 2012-7-7 09:30 编辑

1，那个USB枚举的descriptor说明了传输方式的确是异步的。
2，只不过那个固件是用芯片自带的PLL产生的异步时钟。
3，异步USB的好处就是可以隔绝前端传输的jitter而用本地时钟重整所有的数据
4，所以，前端的jitter被消除了，但由于自身的PLL性能不佳，反而重整出来的jitter很大
5，这有点象钢铁的回炉重造，扔一块废铁进去，然后用铁水重铸一个。但如果重铸的模具有很大问题，有可能重铸出来的还不如扔进去的那块废铁。
6，我们千辛万苦就是追求那个重铸的机会，结果毁在了模具手上，太冤了。
7，CM6631还是不错的，只不过个人认为不能用那个asus的固件了，还是公版的固件好

卡西利亚斯 · 发表于 2012-7-7 10:01

为什么那么久还没有源代码,有就好了.........

不过嘿嘿,哈哈,还是有办法的~

swing · 发表于 2012-7-7 10:39

回复 13# 卡西利亚斯

难道大侠已经修成一个一个字节改HEX的高深本领？

卡西利亚斯 · 发表于 2012-7-7 10:56

回复卡西利亚斯

难道大侠已经修成一个一个字节改HEX的高深本领？
swing 发表于 2012-7-7 10:39

参考 PCHIFI区的那个帖子

symbianer · 发表于 2012-7-7 14:49

回复 15# 卡西利亚斯

能不能贴个链接上来，我搜索不到。我用ultraedit打开都是一对数字

59401 · 发表于 2012-7-7 16:22

呵呵，警示什么？我不管什么异步到底是什么？但是，不使用本地时钟的USB叫异步，我还是坚持，那不是真 ...
定音鼓发表于 2012-7-7 01:33

遵循UAC协议，异步就是异步，自适应就是自适应，这是概念，论坛这么多人看着，不能误导人家吧。
如果ASUS固件下性能不好，那也只是他做得不好，你测试出来了，那就存在。
你可以坚持一个你认为可以很好解决音频时钟性能的工作方式，但是也不能凭想象推翻一个协议里的定义吧。

卡西利亚斯 · 发表于 2012-7-7 18:02

回复卡西利亚斯

能不能贴个链接上来，我搜索不到。我用ultraedit打开都是一对数字
symbianer 发表于 2012-7-7 14:49

http://bbs.hifidiy.net/viewthrea ... p;highlight=01%2BUS

定音鼓 · 发表于 2012-7-7 18:45

回复卡西利亚斯

难道大侠已经修成一个一个字节改HEX的高深本领？
swing 发表于 2012-7-7 10:39

黑盒子能改啥，最多把华硕改成别的名字再改checksum，其他无任何资料只能干瞪眼。

卡西利亚斯 · 发表于 2012-7-7 19:47

黑盒子能改啥，最多把华硕改成别的名字再改checksum，其他无任何资料只能干瞪眼。
定音鼓发表于 2012-7-7 18:45

其实只要有枚举的信息就行了.............可以用STM32F2/4或者AT32UC3A来仿制一个.

[DAC] 玩ES9016过程之三，384K和ESS的ASRC