作者NerVGear (Phantom)
看板Headphone
标题Re: [心得] 数位不就0与1怎麽可能(略
时间Wed May 11 00:31:06 2022
先说我不是专业的
不过我会Google
Google之後可以看到其实一个OS对音效都有相应的架构
Windows
https://tinyurl.com/3fc6j7hs
Linux ALSA
https://wiki.st.com/stm32mpu/wiki/ALSA_overview
所以很多东西并不是你看到的这麽简单
不同的OS对音效会做的相对应处理都不一样
所谓的拨放程式也只是Call api把档案读出来经过处理後再请求系统处理而已
当然细项实作我不知道,除了Linux,Windows在这方面就一个黑盒子
你也不知道实际出来的数位讯号丢给DAC的数位讯号长什麽样子
不过真要量应该是可以量?
以上,如果有做这方面Driver还是设计的可以出来科普XD
--
作者 NerVGear (Phantom) 看板 Gossiping
标题 [问卦] 有没有记得最熟课文的八卦
时间 Thu Apr 9 17:16:15 2015
───────────────────────────────────────
1F：推 goldman0204: 孙中山看精子往上游?04/09 17:16
2F：→ goldman0204: 靠杯 打错 脑子是想小鱼逆游?打出精子= = 04/09 17:17
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.34.7.111 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Headphone/M.1652200272.A.5AD.html
3F：推 icekiba: 那CD转盘怎麽解释（在线等 05/11 00:38
你想讲什麽就直接讲题目就好 不然也可以发一篇讨论
4F：推 icekiba: 我是问问题好吗… 05/11 00:42
要问问题就把题目条件讲清楚啊==
5F：→ icekiba: 所以不知道丢过去的数位讯号不同所以影响了声音 对吧? 05/11 00:47
6F：→ icekiba: 转盘就是问…不同转盘的差异也是这样吗? 跟电脑的差异也 05/11 00:47
7F：→ icekiba: 是这样吗? 05/11 00:47
第一段可以说是 因为最终还是会经过系统层处理
然後你可能不知道这个系统层他做了什麽处理然後才把东西丢给DAC
至於我想你想说的是光碟机? 光碟机只是负责把光碟上的资料读出来然後喂给後面系统
跟你从硬碟读资料出来是一样的 只要没有资料错误东西都会一样
理论上并不会存在光碟机不同音质有差之说
毕竟光碟机就是一堆bit的载体而已,这东西是绝对的
硬要说真的有差可能就不同厂牌的光碟机资料错误容忍度有差吧
至於你说电脑的差别是指什麽?
8F：→ icekiba: 你的意思是光碟机会有读取错误的时候? 05/11 00:59
9F：→ icekiba: 我的问题就是CD转盘丢给Dac的资料跟你电脑丢给Dac的资料 05/11 01:00
10F：→ icekiba: 不是一样吗? 05/11 01:00
11F：→ icekiba: 你说的系统层造成差异 导致数位讯号有改变 那不同CD转盘 05/11 01:01
12F：→ icekiba: 也是一样的原理吗? 05/11 01:01
13F：→ icekiba: CD转盘…这不是电脑里面的光碟机 05/11 01:02
14F：→ NerVGear: 有读错的可能 不过应该有纠错的机制 如果错太多应该就 05/11 01:02
15F：→ NerVGear: 直接资料毁损了 05/11 01:02
16F：→ icekiba: 你电脑播放已经rip好的CD 跟 用CD转盘播放 『同一块』CD 05/11 01:03
17F：→ icekiba: 里面的资料不是一样吗? 05/11 01:03
18F：→ icekiba: 这不就是常常讲的疑问吗 读取错误早就爆音了… 05/11 01:04
19F：→ NerVGear: 那里的CD转盘是指？ 05/11 01:04
20F：→ icekiba: 衍生问题 所以你读取错误那边影响声音?? 应该不是吧 05/11 01:04
22F：→ icekiba: CDt CD转盘 … 没人在用了吗 05/11 01:06
23F：→ NerVGear: 那是这个的话就是所谓的系统层的问题啊 光碟机把资料读 05/11 01:09
24F：→ NerVGear: 出来会送进它里面的不管是SoC的还啥处理 出来的数位讯 05/11 01:09
25F：→ NerVGear: 号本来就有可能有差异 05/11 01:09
26F：→ dzwei: 严格说起来，现代的转盘要塞个小小的linux不是问题 05/11 01:10
27F：→ NerVGear: 可以分解成几步 资料->系统处理->DAC 05/11 01:11
28F：→ dzwei: 不见得是bare-metal的开发方式 05/11 01:11
29F：→ icekiba: 追问 换线会影响数位讯号吗? 05/11 01:14
30F：→ NerVGear: 你说的影响是指？ 如果是会让0变成1的那种本身前提就不 05/11 01:21
31F：→ NerVGear: 对了 05/11 01:21
32F：→ NerVGear: 不是的话只要线能正确传递资料流那就不会影响 05/11 01:22
33F：推 bh2142: Linux现在的音效架构超级杂的 05/11 01:58
34F：→ jhs1213: 要解MQA要bit perfect 那还会有不同拨放os/程式差异吗? 05/11 02:00
35F：→ yys310: MQA bit perfect? 感觉好冲突的一句话 05/11 02:05
36F：→ jhs1213: 跟他自己格式输出後的bit perfect，并非跟原音源 05/11 02:36
37F：推 wj12240522: 如果OS没差的话索尼新金砖特地弄客制化安卓系统干嘛 05/11 04:09
38F：推 vericool: Windows预设的话OS是会对音讯动手脚的，因为不同程式之 05/11 04:55
39F：→ vericool: 间要混音才能一起输出，而且根据输出的取样率会做升频 05/11 04:55
40F：→ vericool: 或降频，然後Windows的升降频写很烂，macOS的升降频演 05/11 04:55
41F：→ vericool: 算法就好很多。 05/11 04:55
42F：推 xoy: 从上个世纪的Windows 98开始OS跟软体要做到Bit Perfect都不 05/11 07:17
首先你要确定是否是Bit Perfect
43F：→ xoy: 难，在这个前提下声音的差异早就不是资料在逻辑面被改变了， 05/11 07:17
44F：→ xoy: 另外资料传输造成逻辑面的错误通常就直接爆音了 05/11 07:17
45F：→ icekiba: 没错啊 不是改变资料的逻辑面 不然就爆音了 05/11 08:30
46F：→ icekiba: 所以是改变了什麽? 一直以来的疑问 05/11 08:31
实际怎麽处理的可以去看Linux在这方面怎麽做的
原始码都公开在网路上了
47F：推 Taniwha: 推推，学到很多 05/11 08:50
48F：推 djboy: Linux 应该不算「黑盒子」啦，都是open source。 05/11 08:55
我这边提的黑盒子只有Windows
49F：→ djboy: CD读资料的正确性，在音响版我有文章，里面有参考资料。 05/11 08:57
50F：→ djboy: webptt.com/cn.aspx?n=bbs/Audiophile/M.1574415229.A.D0E.html 05/11 08:58
51F：推 Taniwha: 我想问个问题，都是同样的歌，格式都一样，照理来说还原 05/11 09:00
52F：→ Taniwha: 成类比的结果应该都一样，顶多是某些细节有些比较好有解 05/11 09:01
53F：→ Taniwha: 出，有些忽略没解到，可以这样说吗？ 05/11 09:01
54F：→ Taniwha: 不然同一格式的歌曲，因为某些原因听起来不一样，很怪 05/11 09:01
55F：→ Taniwha: 不过都是数位讯号，只有01我真的很困惑资料失真的机率是 05/11 09:02
56F：→ Taniwha: 多高？以现在的技术而言应该很低吧？会高到影响听感？ 05/11 09:03
57F：→ justagame: 格式一样只保证歌的数位档案传到另一个地方不变 05/11 09:03
58F：→ justagame: 转类比的时候每台机器都不同 05/11 09:03
59F：→ Taniwha: 类比我可以理解，我现在不理解的是数位，我上面的例子只 05/11 09:04
60F：推 kwpttw: 不就是jitter吗？老话题永远讨论不完 05/11 09:05
61F：→ Taniwha: 有把数位讯源换掉而已，为什麽差别这麽大？OS或是驱动不 05/11 09:05
不就说数位处理中间那层不一样了
你有确定你Windows上跟RPi上跑的都在DSD底下?
如果你设定都对才有接下来讨论的价值 不然光前提就不一样了
62F：→ justagame: 有几种常见的说法 1.jitter 2.emi 3.共地(例如usb) 05/11 09:05
63F：→ Taniwha: 同，可是数位档案结果解出来差异会这麽大到影响听感？ 05/11 09:06
64F：→ justagame: 都是隐藏在数位01抽象下面的东西 05/11 09:06
理论上数位影响类比是有可能
有可能是机器内部不管是DAC还啥的滤波隔离没做好的
数位讯号散出来的谐波去干扰到类比的讯号
65F：推 djboy: Tan网友，你要认真讨论的话，原文第一个推文就在问你： 05/11 09:19
66F：→ djboy: 「是否有通过ABX盲测 12/16」？ 05/11 09:19
67F：→ djboy: 只有通过这个盲测，才进入科学的范围。 05/11 09:19
68F：推 lwecloud: Windows是有exclusive mode，理论上不会被混音 05/11 09:25
69F：→ lwecloud: 但还有driver这层，UAA问题一堆...微软一向不重视audio 05/11 09:26
70F：→ lwecloud: 另外share mode还会加入dither，所以从开头就被加料了 05/11 09:27
只能说一个大型系统有太多东西可以搞鬼了
71F：推 icekiba: 所以我说拿Dac来盲测看看是不是有差异阿XD 就拿D90跟D90 05/11 09:45
72F：→ icekiba: Se来测就好 05/11 09:45
你这命题又不同了阿
现在是讨论系统的影响
不应该是比Windows vs Linux?
应该设备都一样单纯电脑灌Windows or Linux吧
73F：推 icekiba: 我是回答楼上某楼 05/11 09:57
74F：→ icekiba: 你要测试Windows 是否与 Linux 有显着差异 透过盲测没错 05/11 10:00
75F：→ icekiba: 阿 请去执行吧 05/11 10:00
欸不是 这不是该是原Po要去确认去做的吗 怎麽会是我XD
76F：→ icekiba: 原po应该没有要写论文 05/11 10:09
这样就写论文喔? 不至於吧
前面不就说要些把设定搞对了 前提都对才有讨论的价值
说真的你想讨论整个数位系统可以再开一篇讨论啦 不要模糊焦点
77F：推 yys310: 一路都在馍糊焦点XD 05/11 10:17
78F：推 icekiba: 谁反串 05/11 10:20
79F：推 chiyoda: abx盲测16中12,一针见血，推 05/11 10:30
80F：推 xoy: 原Po用Roon没开DSP就是Bit Perfect，这个前提早就是确定的了 05/11 10:32
81F：推 xoy: Bit Perfect的条件下OS跟软体的架构还是有可能影响声音，但 05/11 10:36
82F：→ xoy: 是这跟资料有没有被改就无关了，Jitter跟同步非同步传输有影 05/11 10:36
83F：→ xoy: 响，电气电磁杂讯也可能有影响 05/11 10:36
我看Roon的说明页看起来是不一定耶?
https://help.roonlabs.com/portal/en/kb/articles/audio-setup-basics
检查一下两边设定是否相同就可以快速排除阿
搞不好是有什麽问题有设定跳掉
84F：推 xoy: 另外播放程式只是Call API这个误会就大了 05/11 10:42
这样说的确不好啦 拨放器有可能会做一些处理再把资料丢给系统
85F：→ icekiba: 资料不会被改变吧 所以都是其他的原因影响 像是这篇讲的 05/11 10:42
86F：→ icekiba: OS处理层导致改变 05/11 10:42
87F：推 chiyoda: 不是还有exclusive mode 要开吗 05/11 10:55
88F：推 xoy: 原Po的做法是拿树苺派当Roon Bridge，Roon Server还是原来的 05/11 11:48
89F：→ xoy: 那一台PC，Roon的资料流是不是Bit Perfect看Signal Path就知 05/11 11:48
90F：→ xoy: 道了 05/11 11:48
Roon的Bridge也是分开设定的阿
Server只是提供音档,但实际怎麽送到DAC是看Local的装置设定
Once you've installed Roon Bridge, you’ll need to configure your device’s
audio outputs. Start by opening Roon on your Windows or OS X computer, or
Roon Remote on your iOS or Android device.
In Settings, click the Audio tab -- in the Networked section, you should be
able to see the list of audio devices discovered by Roon Bridge. Enable the
device (or devices) you want to use. More detailed instructions about setting
up your DAC can be found here.
91F：推 xoy: 我只能猜你没用过，RoPieee的Roon Bridge接USB DAC没什麽设 05/11 12:21
92F：→ xoy: 定，就是Bit Perfect的方式，Roon预设就是这样而已，除非故 05/11 12:21
93F：→ xoy: 意SSH进去乱搞 05/11 12:21
94F：推 xoy: Roon设计上本来就有考量到不同OS可能的干扰，这是基本功，要 05/11 12:36
95F：→ xoy: 检查也很简单，要刻意让OS的机制如Mixer改变资料也不是不行 05/11 12:36
96F：→ xoy: ，只是我看不出来原Po有故意做这件事 05/11 12:36
确实是没用过 所以我只是在云整体架构
那其实可以反过来说 Windows上的设置正确吗? 如果RoPieee上面的东西都是不能动的
我光看Roon介绍的页面就一堆东西可以设定了
PC上有开Exclusive mode吗? 还是Roon预设就会开?
而且你终究会接到Driver层的 我看他所用的DAC在Windows还会需要特别装驱动
除非是像MQA这种的 他是原始资料直接丢给DAC解
不过MQA也有很多种运作模式,也不一定
https://tinyurl.com/yfk7vmdj
97F：→ jhs1213: USB接DAC 应该也排除jitter不同的问题? 05/11 12:50
98F：→ elhazard01: 某些状况下USB协定即时传输速度优先於正确性。这时线 05/11 13:52
99F：→ elhazard01: 材造成的影响才会出来（眼图张开程度） 05/11 13:52
100F：推 icekiba: 讨论线材 模糊焦点喔 05/11 13:58
101F：→ dunhillli: 再次开战 05/11 15:07
102F：推 sam352306: 置板凳 05/11 15:13
103F：推 pcjustin: 塔塔开 05/11 15:29
※ 编辑: NerVGear (114.34.7.111 台湾), 05/11/2022 15:57:01
※ 编辑: NerVGear (114.34.7.111 台湾), 05/11/2022 16:03:40
104F：推 Bencrie: 一般人用的系统没在跟你直接用 libasound 的啦 05/13 00:26
105F：→ Bencrie: userspace 那边都嘛还要经过 sound server (libpulse) 05/13 00:26
106F：→ Bencrie: app > libpulse > libasound/plugins > kernel ALSA 05/13 00:28
107F：→ Bencrie: 新的或未来的会慢慢改成 pipewire 但是干一样的事情 05/13 00:29
108F：推 dzwei: 真的很用心开发的 比方说roon on Linux 应该会以ALAS为底层 05/13 00:41
109F：→ dzwei: 上层的东西再自己写 05/13 00:42
111F：→ dzwei: 这是roon server在arch的相依套件 05/13 00:43
112F：→ dzwei: 如果要保证低latency的话 除了基於ALSA手刻上层之外 05/13 00:45
113F：→ dzwei: 连kernel都要用realtime的 jack好像有realtime的conf 05/13 00:45
114F：→ dzwei: 可以打开 这是jack强调他low latency的原因 05/13 00:46
115F：推 Bencrie: 那是改 limits.conf 让 jackd 的 thread 可以跑在 rt 05/13 01:00
116F：→ Bencrie: scheduler 上。这个操作没有一定要 kernel rt patchset 05/13 01:01