Re: [心得] 數位不就0與1怎麼可能(略

[NerVGear (Phantom)]

先說我不是專業的

不過我會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                                               
───────────────────────────────────────
推 goldman0204: 孫中山看精子往上游?
→ goldman0204: 靠杯 打錯 腦子是想小魚逆游?打出精子= =
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.34.7.111 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Headphone/M.1652200272.A.5AD.html
推 icekiba: 那CD轉盤怎麼解釋（在線等
你想講什麼就直接講題目就好 不然也可以發一篇討論
推 icekiba: 我是問問題好嗎…
要問問題就把題目條件講清楚啊==
→ icekiba: 所以不知道丟過去的數位訊號不同所以影響了聲音 對吧?
→ icekiba: 轉盤就是問…不同轉盤的差異也是這樣嗎? 跟電腦的差異也
→ icekiba: 是這樣嗎?
第一段可以說是 因為最終還是會經過系統層處理
然後你可能不知道這個系統層他做了什麼處理然後才把東西丟給DAC
至於我想你想說的是光碟機? 光碟機只是負責把光碟上的資料讀出來然後餵給後面系統
跟你從硬碟讀資料出來是一樣的 只要沒有資料錯誤東西都會一樣
理論上並不會存在光碟機不同音質有差之說
畢竟光碟機就是一堆bit的載體而已,這東西是絕對的
硬要說真的有差可能就不同廠牌的光碟機資料錯誤容忍度有差吧

至於你說電腦的差別是指什麼?
→ icekiba: 你的意思是光碟機會有讀取錯誤的時候?
→ icekiba: 我的問題就是CD轉盤丟給Dac的資料跟你電腦丟給Dac的資料
→ icekiba: 不是一樣嗎?
→ icekiba: 你說的系統層造成差異 導致數位訊號有改變 那不同CD轉盤
→ icekiba: 也是一樣的原理嗎?
→ icekiba: CD轉盤…這不是電腦裡面的光碟機
→ NerVGear: 有讀錯的可能 不過應該有糾錯的機制 如果錯太多應該就
→ NerVGear: 直接資料毀損了
→ icekiba: 你電腦播放已經rip好的CD 跟 用CD轉盤播放 『同一塊』CD
→ icekiba:  裡面的資料不是一樣嗎?
→ icekiba: 這不就是常常講的疑問嗎 讀取錯誤早就爆音了…
→ NerVGear: 那裡的CD轉盤是指？
→ icekiba: 衍生問題 所以你讀取錯誤那邊影響聲音?? 應該不是吧
→ icekiba: https://i.imgur.com/pVkG70D.jpg
→ icekiba: CDt CD轉盤 … 沒人在用了嗎
→ NerVGear: 那是這個的話就是所謂的系統層的問題啊 光碟機把資料讀
→ NerVGear: 出來會送進它裡面的不管是SoC的還啥處理 出來的數位訊
→ NerVGear: 號本來就有可能有差異
→ dzwei: 嚴格說起來，現代的轉盤要塞個小小的linux不是問題
→ NerVGear: 可以分解成幾步 資料->系統處理->DAC
→ dzwei: 不見得是bare-metal的開發方式
→ icekiba: 追問 換線會影響數位訊號嗎?
→ NerVGear: 你說的影響是指？ 如果是會讓0變成1的那種本身前提就不
→ NerVGear: 對了
→ NerVGear: 不是的話只要線能正確傳遞資料流那就不會影響
推 bh2142: Linux現在的音效架構超級雜的
→ jhs1213: 要解MQA要bit perfect 那還會有不同撥放os/程式差異嗎?
→ yys310: MQA bit perfect? 感覺好衝突的一句話
→ jhs1213: 跟他自己格式輸出後的bit perfect，並非跟原音源
推 wj12240522: 如果OS沒差的話索尼新金磚特地弄客製化安卓系統幹嘛
推 vericool: Windows預設的話OS是會對音訊動手腳的，因為不同程式之
→ vericool: 間要混音才能一起輸出，而且根據輸出的取樣率會做升頻
→ vericool: 或降頻，然後Windows的升降頻寫很爛，macOS的升降頻演
→ vericool: 算法就好很多。
推 xoy: 從上個世紀的Windows 98開始OS跟軟體要做到Bit Perfect都不
首先你要確定是否是Bit Perfect
→ xoy: 難，在這個前提下聲音的差異早就不是資料在邏輯面被改變了，
→ xoy: 另外資料傳輸造成邏輯面的錯誤通常就直接爆音了
→ icekiba: 沒錯啊 不是改變資料的邏輯面 不然就爆音了
→ icekiba: 所以是改變了什麼? 一直以來的疑問
實際怎麼處理的可以去看Linux在這方面怎麼做的
原始碼都公開在網路上了
推 Taniwha: 推推，學到很多
推 djboy: Linux 應該不算「黑盒子」啦，都是open source。
我這邊提的黑盒子只有Windows
→ djboy: CD讀資料的正確性，在音響版我有文章，裡面有參考資料。
→ djboy: www.ptt.cc/bbs/Audiophile/M.1574415229.A.D0E.html
推 Taniwha: 我想問個問題，都是同樣的歌，格式都一樣，照理來說還原
→ Taniwha: 成類比的結果應該都一樣，頂多是某些細節有些比較好有解
→ Taniwha: 出，有些忽略沒解到，可以這樣說嗎？
→ Taniwha: 不然同一格式的歌曲，因為某些原因聽起來不一樣，很怪
→ Taniwha: 不過都是數位訊號，只有01我真的很困惑資料失真的機率是
→ Taniwha: 多高？以現在的技術而言應該很低吧？會高到影響聽感？
→ justagame: 格式一樣只保證歌的數位檔案傳到另一個地方不變
→ justagame: 轉類比的時候每台機器都不同
→ Taniwha: 類比我可以理解，我現在不理解的是數位，我上面的例子只
推 kwpttw: 不就是jitter嗎？老話題永遠討論不完
→ Taniwha: 有把數位訊源換掉而已，為什麼差別這麼大？OS或是驅動不
不就說數位處理中間那層不一樣了
你有確定你Windows上跟RPi上跑的都在DSD底下?
如果你設定都對才有接下來討論的價值 不然光前提就不一樣了
→ justagame: 有幾種常見的說法 1.jitter 2.emi 3.共地(例如usb)
→ Taniwha: 同，可是數位檔案結果解出來差異會這麼大到影響聽感？
→ justagame: 都是隱藏在數位01抽象下面的東西
理論上數位影響類比是有可能
有可能是機器內部不管是DAC還啥的濾波隔離沒做好的
數位訊號散出來的諧波去干擾到類比的訊號
推 djboy: Tan網友，你要認真討論的話，原文第一個推文就在問你：
→ djboy: 「是否有通過ABX盲測 12/16」？
→ djboy: 只有通過這個盲測，才進入科學的範圍。
推 lwecloud: Windows是有exclusive mode，理論上不會被混音
→ lwecloud: 但還有driver這層，UAA問題一堆...微軟一向不重視audio
→ lwecloud: 另外share mode還會加入dither，所以從開頭就被加料了
只能說一個大型系統有太多東西可以搞鬼了
推 icekiba: 所以我說拿Dac來盲測看看是不是有差異阿XD 就拿D90跟D90
→ icekiba: Se來測就好
你這命題又不同了阿
現在是討論系統的影響
不應該是比Windows vs Linux?
應該設備都一樣單純電腦灌Windows or Linux吧
推 icekiba: 我是回答樓上某樓
→ icekiba: 你要測試Windows 是否與 Linux 有顯著差異 透過盲測沒錯
→ icekiba: 阿 請去執行吧
欸不是 這不是該是原Po要去確認去做的嗎 怎麼會是我XD
→ icekiba: 原po應該沒有要寫論文
這樣就寫論文喔? 不至於吧
前面不就說要些把設定搞對了 前提都對才有討論的價值
說真的你想討論整個數位系統可以再開一篇討論啦 不要模糊焦點
推 yys310: 一路都在糢糊焦點XD
推 icekiba: 誰反串
推 chiyoda: abx盲測16中12,一針見血，推
推 xoy: 原Po用Roon沒開DSP就是Bit Perfect，這個前提早就是確定的了
推 xoy: Bit Perfect的條件下OS跟軟體的架構還是有可能影響聲音，但
→ xoy: 是這跟資料有沒有被改就無關了，Jitter跟同步非同步傳輸有影
→ xoy: 響，電氣電磁雜訊也可能有影響
我看Roon的說明頁看起來是不一定耶?
https://help.roonlabs.com/portal/en/kb/articles/audio-setup-basics
檢查一下兩邊設定是否相同就可以快速排除阿
搞不好是有什麼問題有設定跳掉
推 xoy: 另外播放程式只是Call API這個誤會就大了
這樣說的確不好啦 撥放器有可能會做一些處理再把資料丟給系統
→ icekiba: 資料不會被改變吧 所以都是其他的原因影響 像是這篇講的
→ icekiba: OS處理層導致改變
推 chiyoda: 不是還有exclusive mode 要開嗎
推 xoy: 原Po的做法是拿樹苺派當Roon Bridge，Roon Server還是原來的
→ xoy: 那一台PC，Roon的資料流是不是Bit Perfect看Signal Path就知
→ xoy: 道了
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.
推 xoy: 我只能猜你沒用過，RoPieee的Roon Bridge接USB DAC沒什麼設
→ xoy: 定，就是Bit Perfect的方式，Roon預設就是這樣而已，除非故
→ xoy: 意SSH進去亂搞
推 xoy: Roon設計上本來就有考量到不同OS可能的干擾，這是基本功，要
→ xoy: 檢查也很簡單，要刻意讓OS的機制如Mixer改變資料也不是不行
→ xoy: ，只是我看不出來原Po有故意做這件事
確實是沒用過 所以我只是在雲整體架構
那其實可以反過來說 Windows上的設置正確嗎? 如果RoPieee上面的東西都是不能動的
我光看Roon介紹的頁面就一堆東西可以設定了
PC上有開Exclusive mode嗎? 還是Roon預設就會開?
而且你終究會接到Driver層的 我看他所用的DAC在Windows還會需要特別裝驅動

除非是像MQA這種的 他是原始資料直接丟給DAC解
不過MQA也有很多種運作模式,也不一定
https://tinyurl.com/yfk7vmdj
→ jhs1213: USB接DAC 應該也排除jitter不同的問題?
→ elhazard01: 某些狀況下USB協定即時傳輸速度優先於正確性。這時線
→ elhazard01: 材造成的影響才會出來（眼圖張開程度）
推 icekiba: 討論線材 模糊焦點喔
→ dunhillli: 再次開戰
推 sam352306: 置板凳
推 pcjustin: 塔塔開
※ 編輯: NerVGear (114.34.7.111 臺灣), 05/11/2022 15:57:01
※ 編輯: NerVGear (114.34.7.111 臺灣), 05/11/2022 16:03:40
推 Bencrie: 一般人用的系統沒在跟你直接用 libasound 的啦
→ Bencrie: userspace 那邊都嘛還要經過 sound server (libpulse)
→ Bencrie: app > libpulse > libasound/plugins > kernel ALSA
→ Bencrie: 新的或未來的會慢慢改成 pipewire 但是幹一樣的事情
推 dzwei: 真的很用心開發的 比方說roon on Linux 應該會以ALAS為底層
→ dzwei: 上層的東西再自己寫
→ dzwei: https://i.imgur.com/Ewg9mIx.png
→ dzwei: 這是roon server在arch的相依套件
→ dzwei: 如果要保證低latency的話 除了基於ALSA手刻上層之外
→ dzwei: 連kernel都要用realtime的 jack好像有realtime的conf
→ dzwei: 可以打開 這是jack強調他low latency的原因
推 Bencrie: 那是改 limits.conf 讓 jackd 的 thread 可以跑在 rt
→ Bencrie: scheduler 上。這個操作沒有一定要 kernel rt patchset