先說我不是專業的
不過我會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

孫中山看精子往上游?靠杯 打錯 腦子是想小魚逆游?打出精子= =

那CD轉盤怎麼解釋（在線等我是問問題好嗎…所以不知道丟過去的數位訊號不同所以影響了聲音 對吧?轉盤就是問…不同轉盤的差異也是這樣嗎? 跟電腦的差異也是這樣嗎?你的意思是光碟機會有讀取錯誤的時候?我的問題就是CD轉盤丟給Dac的資料跟你電腦丟給Dac的資料不是一樣嗎?你說的系統層造成差異 導致數位訊號有改變 那不同CD轉盤也是一樣的原理嗎?CD轉盤…這不是電腦裡面的光碟機

有讀錯的可能 不過應該有糾錯的機制 如果錯太多應該就直接資料毀損了

你電腦播放已經rip好的CD 跟 用CD轉盤播放 『同一塊』CD裡面的資料不是一樣嗎?這不就是常常講的疑問嗎 讀取錯誤早就爆音了…

那裡的CD轉盤是指？

衍生問題 所以你讀取錯誤那邊影響聲音?? 應該不是吧https://i.imgur.com/pVkG70D.jpgCDt CD轉盤 … 沒人在用了嗎

那是這個的話就是所謂的系統層的問題啊 光碟機把資料讀出來會送進它裡面的不管是SoC的還啥處理 出來的數位訊號本來就有可能有差異

嚴格說起來，現代的轉盤要塞個小小的linux不是問題

可以分解成幾步 資料->系統處理->DAC

不見得是bare-metal的開發方式

追問 換線會影響數位訊號嗎?

你說的影響是指？ 如果是會讓0變成1的那種本身前提就不對了不是的話只要線能正確傳遞資料流那就不會影響

Linux現在的音效架構超級雜的

要解MQA要bit perfect 那還會有不同撥放os/程式差異嗎?

MQA bit perfect? 感覺好衝突的一句話

跟他自己格式輸出後的bit perfect，並非跟原音源

如果OS沒差的話索尼新金磚特地弄客製化安卓系統幹嘛

Windows預設的話OS是會對音訊動手腳的，因為不同程式之間要混音才能一起輸出，而且根據輸出的取樣率會做升頻或降頻，然後Windows的升降頻寫很爛，macOS的升降頻演算法就好很多。

從上個世紀的Windows 98開始OS跟軟體要做到Bit Perfect都不難，在這個前提下聲音的差異早就不是資料在邏輯面被改變了，另外資料傳輸造成邏輯面的錯誤通常就直接爆音了

沒錯啊 不是改變資料的邏輯面 不然就爆音了所以是改變了什麼? 一直以來的疑問

推推，學到很多

Linux 應該不算「黑盒子」啦，都是open source。CD讀資料的正確性，在音響版我有文章，裡面有參考資料。www.ptt.cc/bbs/Audiophile/M.1574415229.A.D0E.html

我想問個問題，都是同樣的歌，格式都一樣，照理來說還原成類比的結果應該都一樣，頂多是某些細節有些比較好有解出，有些忽略沒解到，可以這樣說嗎？不然同一格式的歌曲，因為某些原因聽起來不一樣，很怪不過都是數位訊號，只有01我真的很困惑資料失真的機率是多高？以現在的技術而言應該很低吧？會高到影響聽感？

格式一樣只保證歌的數位檔案傳到另一個地方不變轉類比的時候每台機器都不同

類比我可以理解，我現在不理解的是數位，我上面的例子只

不就是jitter嗎？老話題永遠討論不完

有把數位訊源換掉而已，為什麼差別這麼大？OS或是驅動不

有幾種常見的說法 1.jitter 2.emi 3.共地(例如usb)

同，可是數位檔案結果解出來差異會這麼大到影響聽感？

都是隱藏在數位01抽象下面的東西

Tan網友，你要認真討論的話，原文第一個推文就在問你：「是否有通過ABX盲測 12/16」？只有通過這個盲測，才進入科學的範圍。

Windows是有exclusive mode，理論上不會被混音但還有driver這層，UAA問題一堆...微軟一向不重視audio另外share mode還會加入dither，所以從開頭就被加料了

所以我說拿Dac來盲測看看是不是有差異阿XD 就拿D90跟D90Se來測就好我是回答樓上某樓你要測試Windows 是否與 Linux 有顯著差異 透過盲測沒錯阿 請去執行吧原po應該沒有要寫論文

一路都在糢糊焦點XD

誰反串

abx盲測16中12,一針見血，推

原Po用Roon沒開DSP就是Bit Perfect，這個前提早就是確定的了Bit Perfect的條件下OS跟軟體的架構還是有可能影響聲音，但是這跟資料有沒有被改就無關了，Jitter跟同步非同步傳輸有影響，電氣電磁雜訊也可能有影響另外播放程式只是Call API這個誤會就大了

資料不會被改變吧 所以都是其他的原因影響 像是這篇講的OS處理層導致改變

不是還有exclusive mode 要開嗎

原Po的做法是拿樹苺派當Roon Bridge，Roon Server還是原來的那一台PC，Roon的資料流是不是Bit Perfect看Signal Path就知道了我只能猜你沒用過，RoPieee的Roon Bridge接USB DAC沒什麼設定，就是Bit Perfect的方式，Roon預設就是這樣而已，除非故意SSH進去亂搞Roon設計上本來就有考量到不同OS可能的干擾，這是基本功，要檢查也很簡單，要刻意讓OS的機制如Mixer改變資料也不是不行，只是我看不出來原Po有故意做這件事

USB接DAC 應該也排除jitter不同的問題?

某些狀況下USB協定即時傳輸速度優先於正確性。這時線材造成的影響才會出來（眼圖張開程度）

討論線材 模糊焦點喔

再次開戰

置板凳

塔塔開

一般人用的系統沒在跟你直接用 libasound 的啦userspace 那邊都嘛還要經過 sound server (libpulse)app > libpulse > libasound/plugins > kernel ALSA新的或未來的會慢慢改成 pipewire 但是幹一樣的事情

真的很用心開發的 比方說roon on Linux 應該會以ALAS為底層上層的東西再自己寫https://i.imgur.com/Ewg9mIx.png這是roon server在arch的相依套件如果要保證低latency的話 除了基於ALSA手刻上層之外連kernel都要用realtime的 jack好像有realtime的conf可以打開 這是jack強調他low latency的原因

那是改 limits.conf 讓 jackd 的 thread 可以跑在 rtscheduler 上。這個操作沒有一定要 kernel rt patchset