推 elguapo: 我不知道您能否接受我截圖給您的內容，那個是 Roon 創 07/11 21:11
→ elguapo: 辦人寫的。Roon 會綜合 endpoint 回傳的時鐘資料，去比 07/11 21:11
→ elguapo: 對 Roon 本身的系統時鐘的差別，然後建立一個預測模型 07/11 21:11
→ elguapo: ，用這個模型去送信號。這時系統時鐘主宰信號發送，畢 07/11 21:11
→ elguapo: 竟這時的控制權是 Roon，不是 DAC。 07/11 21:11
我截出來的也是 Brian Luczkiewicz | Roon Labs Founder 跟另名員工所言
看完整串應該能理解，系統時鐘應該只跟維持 Buffer 吞吐有關
只要 Buffer 不欠載不溢出＆網路傳輸是正常的，是不會影響音質
推 qo3650: 有人實測一下有沒有差ㄇ 個人看到chart回穩反射性就覺得聲 07/11 21:13
→ qo3650: 音好聽了 07/11 21:13
推 greg7575: 一整篇沒一段是看得懂的，該讓賢了 07/11 21:21
推 elguapo: Endpoint 的接收 buffer 估計也是 software buffer（Roon 07/11 21:24
→ elguapo: Bridge 是至少 layer 3 的軟體）；software buffer 就會 07/11 21:24
→ elguapo: 吃到 endpoint 的系統時鐘。 07/11 21:24
這個真的不重要
處理 Buffer 只要「來的及」，都不是問題
就像原文中也提到 Roon 網路是用 TCP 而不是一般串流常用的 UDP
所以就算封包出現錯誤也只要重傳就好（TCP 特性）
只要在 Buffer 耗盡前重傳成功，就不會出問題
推 greg7575: 緩衝區用完或爆滿是爆音和跳針嗎 07/11 21:25
→ greg7575: 無論如何，跟中原標準時間都沒關係啊 07/11 21:25
#1aMUsw3K (Audiophile) [ptt.cc] Re: [閒聊] PC訊源雜訊解法
https://www.ptt.cc/bbs/Audiophile/M.1683615162.A.0D4.html
可以參考這篇的內容
然後就上面的回答
Roon 默認使用填充／刪除樣本，而非 Async SRC 來解決樣本多或少的狀況
推 elguapo: 我提議的對時對象是立即可用且免費的資源。如果@greg7575 07/11 21:36
→ elguapo: 不想和NTP對時也無妨，只要在自己環境裡面選出一個參考 07/11 21:36
→ elguapo: 時間就能達到一樣目的。 07/11 21:36
推 elguapo: 兩個端點時間同步，對於緩衝的使用率就能更有效率的掌握 07/11 21:38
→ elguapo: ，也算幫助 Roon 所說的不完美那一塊。 07/11 21:38
推 greg7575: 好喔。 07/11 21:39
推 greg7575: 我覺得這舉動沒意義啦，你覺得有意義很好啊 07/11 21:40
→ greg7575: 意思是這個舉動也許限縮到對roon有效而已對吧 07/11 21:43
→ greg7575: 對apple music的有效在哪？ 07/11 21:44
→ greg7575: 擴大解釋到"以電腦為播放"會不會太舒服了 07/11 21:45
推 elguapo: 我只是以白紙黑字的Roon拿來做example。另外我在我的原貼 07/11 21:49
→ elguapo: 也提到macOS的Audio MIDI Setup也有對不同時鐘去re-sampl 07/11 21:49
→ elguapo: ing的機制，只要涉及到取樣率調整的運算，都和系統時間 07/11 21:49
→ elguapo: 直接關係，希望您能理解。 07/11 21:49
→ elguapo: 我的提議不用錢，只要作業系統對時部分調整一下設定就好 07/11 21:51
→ elguapo: ，也不需要這麼排斥。 07/11 21:51
Mac 的 Drift Correction 我上面貼的那篇也有提到
彌補的也只是 Audio device 間的 Audio clock 差異
跟 System clock 無關
就像這頁裏的第一個圖
https://support.apple.com/en-us/HT202000
Clock Source 能選系統時鐘嗎？只有 Audio device 能選不是嗎
→ m9172250: Buffer:當我塑膠？ 07/11 21:51
推 greg7575: 我覺得不對的事我不做啊。我可以排斥吧。 07/11 22:02
→ greg7575: 不能持反對意見要先說啊 07/11 22:03
→ greg7575: 這篇發文貼了一大堆證明你錯了，還不能排斥喔 07/11 22:04
推 elguapo: 請問我那邊有錯？請指正。 07/11 22:07
傳輸介質上使用的時鐘對 DAC 發出的聲音的影響為零，
因為 DAC 所做的所有操作都是從本地內存緩衝區播放。
這句是 Roon 的粗暴說法
推 elguapo: @oswyn 那個clock source selection只是為了系統時鐘resa 07/11 22:09
→ elguapo: mpling運算時的參考；發送的時候仍是軟體在發送。 07/11 22:09
不是，那個 Clock Source 是在選一台 Audio device 來當 Master Clock
其它 Audio device 的 Audio data 會依樣本數偏移來 ASRC
推 greg7575: 像EAC做offset的感覺，對同時播放錄音設備的檔案sync 07/11 22:20
→ greg7575: 跟中原標準時間真的完全沒關係，講到我都覺得煩 07/11 22:21
推 elguapo: 1. 建議看一下 AES67 規範（我是指 AES 文件商店購買的 07/11 22:26
→ elguapo: 那份），針對介質使用 IEEE1588 作時鐘同步的規定。 07/11 22:26
→ elguapo: 2. 不知您有否用過 Audio MIDI Setup 堆積三到四個多聲道 07/11 22:26
→ elguapo: DAC的經驗？我蠻建議您實作一次，去觀察 drift correctio 07/11 22:26
→ elguapo: n 的動作。 07/11 22:26
→ elguapo: 我就次打住，直到您有答案為止。 07/11 22:26
不需要我的回答，人微言輕
建議您直接上 Roon community 發問
看 Brian | Roon Labs Founder 會有何回應
→ m9172250: 不要這麼壞好嗎 07/11 22:33
下次 Roon 改版就內建了
推 chiyoda: 問題其實很簡單,覺得有差的一方測量DAC出來的訊號就好 07/11 23:10
→ chiyoda: 有用對時工具出來的訊號和沒有用的訊號不一樣就能證明了 07/11 23:11
→ chiyoda: 如果有人認為這個量不到,那就請聽得出來的人蒙上眼,讓其 07/11 23:12
→ chiyoda: 他人隨機撥放,10次猜對9次也行,這樣做為的是排除"非聽覺 07/11 23:14
→ chiyoda: 性干擾 07/11 23:14
盲測不科學啦
其實不用測，因為只要感覺對了就是對
有感這種東西是不需要實測跟量化的
推 tienam: 我覺得讓電腦與NTP Server對時,是種樂趣,但音色沒有影響 07/11 23:21
推 dancehotdog: 弱弱的問 那是不是usb hub 只是改善了雜訊或5v 訊號 07/11 23:22
→ dancehotdog: 沒有影響到dac 07/11 23:22
嗯，不好說
但數位厚...
推 chiyoda: "有感"很有可能是"非聽覺性因素"影響阿 07/11 23:30
但有感了，當這個結果是事實
什麼原因造成還很重要嗎
就算是聽覺性因素影響，久了也會膩、麻痺、感情變淡想要換換啊
就像貼了個貼紙、還是點了個燈，看了就覺得好聽那就是有效投資
推 djboy: O大文必推！ 07/11 23:50
推 yys310: 事實 難看就先被噴爛了 07/11 23:56
噓 stupidHNG: 原因是什麼怎麼不重要？不然搞科學是為了什麼？ 07/12 00:21
→ stupidHNG: 安慰劑吃了也有感，吃安慰劑可以治病嗎？ 07/12 00:22
這都能釣出些萌新
推 icekiba: 網內互打 07/12 00:31
→ broskwlin: 聽個音響是要治病嗎... 07/12 00:37
→ broskwlin: 最可能患得的大概是換換病吧 07/12 00:38
推 yys310: 專治換換病 07/12 00:47
推 icekiba: 換音響不如換老婆 07/12 00:49
旁邊坐個志玲姐姐用什麼聽都好聽
你說一切都是幻覺？實際上根本沒差？
沒錯、當然是幻覺
志玲姐姐怎麼可能坐在我家
推 icekiba: 我看是想咪兔 07/12 02:13
推 comipa: 推 不過機翻還是比較難吃XD 還是原文舒服多了 07/12 05:56
推 greg7575: 覺得很煩啊，任何設備計算時間都是用晶振發出的訊號算 07/12 07:08
→ greg7575: 用48MHz的就是累滿48M個抖動定義為一秒 07/12 07:09
→ greg7575: 晶振爛，對設備而言還是累滿48M個抖動為一秒 07/12 07:10
→ greg7575: 這個狀況下，可能48M個抖動跟實際的一秒就有差異 07/12 07:10
→ greg7575: 能顯示時間的程序會去抓48M個抖動來顯示時間的"一秒" 07/12 07:11
→ greg7575: 無論怎麼軟體校正，爛晶振抖出來的一秒就不是一秒 07/12 07:12
→ greg7575: 原原發文的一直覺得軟體校正就能讓爛晶振輸出準確一秒 07/12 07:13
→ greg7575: 從他第一篇就講了，一直堅持他的"理論"。這有什麼辦法 07/12 07:13
→ greg7575: 不過知識有盲區，我覺得很簡單的事不見得所有人能接受 07/12 07:14
推 greg7575: 基本的觀念都錯了，身體本能的排斥很正常吧 07/12 07:17
推 greg7575: 至於DAC的緩衝就是DAC會從資料暫存庫裡拉貨出來 07/12 07:21
→ greg7575: DAC看到音檔是44.1kHz的話就是拉這麼多出來播一秒 07/12 07:23
→ greg7575: apple music暫存直接機八大的給你好幾GB來存 07/12 07:23
→ greg7575: 暫存裝的滿滿的就不用怕串流倉庫不夠播 07/12 07:24
→ greg7575: foobar也能設暫存的量，不過很精細的說那是另一件事 07/12 07:25
→ greg7575: 反正原原po都說他就此打住了，我就這坨一次講完 07/12 07:26
推 greg7575: 就算你去抓中原標準時間回來，爛晶振還是堅持他的一秒 07/12 07:28
→ greg7575: 你的電腦顯示的時間是一回事，爛晶振的抖動方式不會變 07/12 07:29
推 greg7575: 第一篇我就舉LP的例子，你不求轉速穩定 07/12 07:31
→ greg7575: 而是覺得每15秒拉一下碟盤"校時"就好 07/12 07:32
→ greg7575: 殊不知這"校時"一點意義都沒有，轉速一樣不穩音樂照播 07/12 07:33
→ greg7575: 如果你的"校時"有意義，那你的音樂要每15秒跳針一次 07/12 07:33
→ greg7575: 沒聽到跳針的話，表示校時跟dac的clock完全沒關係 07/12 07:34
→ greg7575: 在座各位有誰家的電腦按下校時，音樂會跳針的嗎？ 07/12 07:35
推 greg7575: 戰過很多次了，數位出錯就會爆音。沒爆表示沒差啊 07/12 07:48
→ greg7575: 至於DPC Latency的問題不在這談，更煩 07/12 07:49
推 greg7575: 微軟拔拔在win11取消顯示秒數，cpu去主機板拉晶振算時間 07/12 08:24
→ greg7575: 這件事就完美的解釋了電腦的一秒一秒是怎麼來的。 07/12 08:25
→ greg7575: 你能用軟體改造晶振的抖動次數，跟造物主同等級了 07/12 08:25
推 greg7575: 如同耳機板板友問的，cpu吃的clock從哪來呢？嘻嘻 07/12 08:28
推 elguapo: @greg7575 關於改系統時鐘會造成破音這件事，歡迎來我家 07/12 09:45
→ elguapo: 坐坐，我demo給您看/聽。 07/12 09:45
→ bt092001: 事情很單純，就是serdes 原理而已，決定品質的就是DAC 07/12 10:18
→ bt092001: 跟RX 本地clock性能，其他都只是暫存跟latency 07/12 10:18
這我過去也提過很多遍，聽我說不如聽專家說
但這也並不代表類比電氣特性不會透過介質串到其它設備就是了
不過有時就算專家說也無法憾動燒友不斷嘗試“改進”事物的信念
推 icekiba: 要確定是改進捏 07/12 10:43
有感就好捏
推 icekiba: 你進來了嗎? 我是說訊號 07/12 11:00
推 greg7575: 做任何事都會改變，而這個改變的原因不能亂講。 07/12 11:22
推 greg7575: 撐傘能遮陽，而不是撐傘把太陽變弱 07/12 11:24
推 elguapo: @greg7575 來我家 我 demo 眼見耳聽為憑 07/12 11:33
聽了有感跟要佐證您的假設正確是不同的事
就像上面您提到 Drift Correction 跟系統時間有直接關係
說實作一次，去觀察 drift correction 的動作?
如何觀察到 Drift Correction 跟系統時間有直接關係？
是有什麼設備可以偵測還是反組譯看程式碼？或只是我感覺？
坦白說 Drift Correction 的運作原理網上很多資料，也沒什好辯的
實際上我也用過，但不再用的原因跟 Roon 上面的說法一樣
除非是後製商品賣錢，不然在 Replay 使用開銷太大得之過少不如放給它錯
If it can go wrong, it will.
但這個 Wrong 不太痛也很少發生
就放它很偶爾發生，而不是把沒問題的也全都整一遍
→ m9172250: 直接人工耳啊 07/12 11:38
推 elguapo: 對了 也歡迎 @Oswyn 來我家 我可以demo一些CLOCK_REALTIM 07/12 11:43
→ elguapo: E 對音質的影響。邊操作邊解釋應該更容易溝通。 07/12 11:43
→ m9172250: 大家都能聽到 07/12 11:43
推 greg7575: 錄一段校時會爆音的上來瞧瞧，長知識 07/12 11:44
推 jakkx: 這種不影響就是進步的原動力啊。即使原因可能不是當初認為 07/12 11:49
→ jakkx: 的那一個 07/12 11:49
→ m9172250: 那可以去拜讀一下量子力學 07/12 11:51
推 elguapo: 一邊講解一邊示範效果最大 我是真的希望G大和O大來我家家 07/12 12:03
→ elguapo: 訪 無意引戰 而是把事實呈現給兩位會比在這裡文字描述有 07/12 12:03
→ elguapo: 用的多 07/12 12:03
推 greg7575: 你高興就好 07/12 12:15
推 greg7575: 記得貼去roon論壇嘿。 07/12 12:20
→ lacer: 是否可以把引用跟自己意見區別明顯一點 不然一下翻譯一下自 07/12 12:25
→ lacer: 己論述 也可以用gpt把來源文章摘要 這樣會更棒 07/12 12:25
※ Reference Mark 還不夠清楚嗎:D
推 elguapo: G大不是積極的證明在下是錯的嗎？我同意您來家訪後，您 07/12 12:30
→ elguapo: 來公布家訪細節，包含截圖、照片和對話（要錄音也行）。 07/12 12:30
Roon 原始討論串 system clock 只出現一次
而且後面 Roon 員工一直強調討論中的此 clock 非彼 clock
全文完全沒出現過 Data/Time 相關
依前後文這個 The system clock 也根本跟「真實時間」無關
要怎麼證明校時與音質有直接關聯應該不用家訪
因為就算家訪這兩者間的關聯還是無法以科學論述驗證啊
推 icekiba: 那…我去印紅布條 第一屆音響版版聚 07/12 12:35
推 greg7575: 所以我不去就是我講的都錯的意思嗎？ 07/12 12:38
→ greg7575: 好喔那我不去，我俗辣，你對。 07/12 12:38
→ greg7575: 請繼續開發用軟體改變晶振的能力:) 07/12 12:40
→ greg7575: 我覺得我很友善了。嘻嘻 07/12 12:42
→ lacer: 喔 明白了 看來ptt的格式 比較適合引用摘要 一大段真的不簡 07/12 12:44
→ lacer: 單 如果有QA以外的資料歡迎分享喔 不大想只看Roon的說法 07/12 12:44
我會建議有空要去看原文
推 greg7575: 晶振運作原理都講了，只想要輸贏。那你贏 07/12 12:47
推 jwchen119: 支持家訪，最好可以作雙盲測試 07/12 12:51
推 elguapo: 說到對時後會不會跳針… 依據AES67 的文件，以 48KHz 來 07/12 12:52
→ elguapo: 說，每 24.86 小時會 overflow，若把信號和時間在那時候 07/12 12:52
→ elguapo: 我一直以來都在講系統時間，晶振只是系統時間的參考信號 07/12 12:53
→ elguapo: ，我不知道那邊溝通出問題？ 07/12 12:53
我個人覺得最大的問題在
您看到 Roon 討論串中出現了 system clock 一次
就無限放大 system clock 的可能性
而沒通盤看完、與理解整個討論串中 Roon 試圖解釋的東西
推 elguapo: O大，您前個回覆，更讓我想把您奉為貴賓來接待，讓我仔 07/12 12:57
→ elguapo: 細的和您解釋並示範吧。 07/12 12:57
推 greg7575: 多開幾個程式讓dpc latency牙起來。改變音質很簡單 07/12 13:04
→ greg7575: 不用牙到爆音的程度，負載重就很有感了。 07/12 13:04
→ greg7575: 尤其是nv的驅動，沒事做還可以牙起來 07/12 13:05
→ greg7575: 叫它做點事反而觸發降低latency。魔法驅動值五千 07/12 13:05
→ greg7575: 大師可以略過我，我在跟其它看戲的解釋可能的狀況 07/12 13:06
→ comipa: 也許只是因為一直對時 cpu進不去c-state 07/12 13:09
推 greg7575: cpu運作的鬆緊對音質影響也很大，樓上突破盲點 07/12 13:10
→ greg7575: win11顯示秒數就不能休眠。cpu會一直牙 07/12 13:11
→ m9172250: 我覺得眾多燒友已經很極力 用人可以聽懂的語言去解釋了, 07/12 13:39
→ m9172250: 還有談論的意義嗎 07/12 13:39
→ m9172250: roon那篇原文 連機翻都講到可以如此白話 07/12 13:43
推 greg7575: 無法證明是校時改變音質還是校時軟體改變音質 07/12 13:46
推 greg7575: 任何程式要顯示秒都要叫cpu call晶振 07/12 13:49
基本上寫程式尤其低階 I/F、I/O，沒事不會去用到真實時間
都嗎讀計時器的 count 或用 10ns、100ms 這些相對時間
要知道現在幾點幾分幾秒需要更多換算
真實時間在電腦系統裏是拿來「給人看」的
推 greg7575: 惡靈古堡移植版的fps越高小刀傷害越高 07/12 14:04
→ greg7575: 程式喊了什麼要拆開來看才知道 07/12 14:05
推 Zyar: 支持樓主去家訪 都吵這麼兇了 不如家訪吧 親眼論證一下孰對 07/12 14:38
→ Zyar: 孰錯再分享給大家確切結論 07/12 14:38
→ m9172250: 人工耳不是快速便捷 順便大家都能聽 07/12 14:48
推 chibob: 家訪可以啊 先講好有甚麼儀器可以驗 不然也只是一起舒服 07/12 14:48
推 icekiba: 要看怎麼舒服法 07/12 14:49
推 icekiba: 幾個S 07/12 14:49
推 icekiba: Siltech 07/12 14:49
→ m9172250: 幾個h 07/12 14:51
→ m9172250: Harbeth 07/12 14:51
推 icekiba: 0.3 0.5 還是 1 我說線徑 07/12 14:53
→ yys310: 錄音錄起來每次都不同 人工耳是想要用啥指標來看？ 07/12 14:54
→ m9172250: 沒關係 因為差異性一致 07/12 14:56
→ m9172250: 至少要聽出有無變化即可 不求還原 07/12 14:56
推 chibob: 發散也是差異 收斂也是差異 大膽假設 小心求證 07/12 15:13
推 icekiba: 我有個大膽的想法 07/12 15:15
→ chibob: 快收起你大膽的想法 07/12 15:19
→ m9172250: 我有個大 07/12 15:29
推 icekiba: 大什麼大 07/12 15:36
→ sunyanwen: AES67是fully-synchronized system，沒有drift的問題， 07/12 16:08
→ sunyanwen: VAD只能做PTP Slave，VAD的音頻時鐘只能鎖定在PTP GM上 07/12 16:08
→ sunyanwen: ，因為是burst形式的data，所以只要鎖定還在，音頻就沒 07/12 16:08
→ sunyanwen: 問題，NTP不能加入鎖定，自然是沒有用的 07/12 16:08
→ lacer: 我看過原文才問的 因為這只是Roon的說法 問題是原本的發文 07/12 16:13
→ lacer: 不是只適用RAAT 你們講的不完全一樣也 雞同鴨講了 07/12 16:13
這不是只是 Roon 的說法，只是 Roon 在相關討論中滿完整的梳理了一番
相關內容其實也在本版與友版中分散出現無數次
光我個人就提過很多次相關內容
只是 Roon 做為業界翹楚，說出來更有份量
推 max0427: 原原po的討論口氣很客氣，我也相信他付出努力並無償分享 07/12 16:14
→ max0427: 完全出自好意，值得我這樣的路過鄉民給予感謝。但是即便 07/12 16:14
→ max0427: 認錯很困難，這還是值得追求的美德，因為您真的無法證明 07/12 16:14
→ max0427: 您做的改變對數位音樂播放有益，not@all. 07/12 16:14
推 tienam: 對時就是種樂趣啦,無法改變音色的,但會增加server負擔(X) 07/12 16:25
→ elguapo: @sunyanwen VAD 是 PTP software slave，輸出的封包 time 07/12 16:35
→ elguapo: stamp 是來自系統時鐘。 07/12 16:36
→ sunyanwen: 不需要考慮timestamp的問題，所有設備都頻率鎖定在PTP 07/12 16:51
→ sunyanwen: GM上，playback的buffer+來自PTP GM的locked audio cl 07/12 16:51
→ sunyanwen: ock就可以保證絕對穩定的播放 07/12 16:51
→ bt092001: EPHY LPHY不是完整封包根本認不得，DAC 本體吃的都是re- 07/12 16:53
→ bt092001: sample PLL。當然noise injection 是另一回事要分開看 07/12 16:53
→ elguapo: 意見。或許是我看著 VAD audio clock 上上下下的不太舒服 07/12 17:06
→ elguapo: 吧。其他器材只有 +-1ns 的變化。 07/12 17:06
其實這些「很小的」時間波動，會被 Buffer cover
也就是 Roon 討論中提到的半滿 Buffer，既有庫存、也有空間
所以傳輸過程中的時鐘精度並不十分重要，只要 Buffer 配置得當
→ elguapo: 截圖是經過local NTP 對時後穩定的結果。若純以系統自動 07/12 17:31
→ elguapo: 對時並處於 free clock 狀態的話，瞬時變化會 >100ns。AE 07/12 17:31
→ elguapo: S67 標準 frame buffer 是 1ms。這樣的不穩定我個人認為 07/12 17:31
→ elguapo: 有必要進一步管理。 07/12 17:31
→ elguapo: 補充：VAD 顯示的 audio clock 狀態即是 system clock 07/12 17:33
→ elguapo: 的狀態 07/12 17:33
AES67 有定義精度嗎？若有是多少？若無不就表示不是很重要嗎
1 ms 等於 1,000,000 ns
您是說 100ns 的變化會影響 1ms buffer 的穩定度？
我個人感覺就算是 100μs 都不太會
推 tienam: win11 KB5028185更新,啟用moment 3,工作列讀秒功能回歸. 07/13 00:44
→ tienam: 可以設定工作列讀秒功能,讓CPU不要沉睡. 07/13 00:45
推 Myt33: macOS裝caffeine會不會也有類似的效果？ 07/13 00:52
推 elguapo: 1. AES67 精度規範沿用 AES11 07/13 08:34
→ elguapo: 2. DXD 352800 samples per second，sample 與 sample 07/13 08:34
→ elguapo: 間隔約 2.83us，用這個間隔看 100ns 的 jitter 又會是多 07/13 08:34
→ elguapo: 大的影響？這只是單一聲道，若為12聲道DXD？ 07/13 08:34
但很不幸的是，人耳對時間差並不太靈敏
就像一般評延遲感知是用 10ms，超過明顯能感到有延遲
部分人比較敏感的也不過幾 ms，幾 μs 是不可能更別說到 ns 的差異
就像一個 20 kHz 的聲波走的的時間是 0.05ms or 50μs
人耳分析頻率無法太精細，有點像 FFT 是以一段時間開窗分析窗內的所有頻率
所以幾 ms 內的聲音是分不出前後差異的
推 greg7575: sample跟sample之間沒有間隔。是晶振幫忙決定 07/13 09:07
→ greg7575: 晶振誤差的時基抖動 07/13 09:08
→ greg7575: 有空我會來留幾個字 07/13 09:08
推 greg7575: 晶振的精度決定一切，不是你一直講的中原標準時間。 07/13 09:12
推 greg7575: 心跳決定你是人以及行為，而不是西元民國 07/13 09:30
→ elguapo: A 電腦用 AES67 傳音訊給 B 電腦，請問晶振在哪裡？ 07/13 11:04
→ elguapo: A電腦用Dante傳音訊給B電腦，B電腦再用Ravenna傳給C電腦 07/13 11:55
→ elguapo: ，請問晶振又在哪裡？時鐘要依據誰？ 07/13 11:55
推 greg7575: 經過這幾天的討論，是依據你的感覺。 07/13 11:59
→ elguapo: A 電腦 macOS 跑 NAA 守護程式當作 B 電腦的 HQPlayer in 07/13 12:00
→ elguapo: put，請問晶振在哪裡？時鐘又是誰為主？ 07/13 12:00
→ greg7575: 晶振造時間的本質我講再多次也無法改變你的感覺 07/13 12:00
→ greg7575: 發給外國人教育他們，我是不受教啦。 07/13 12:02
→ greg7575: 晶振在主機板上面，你把它拔了試試能不能開機 07/13 12:02
→ greg7575: 反正你說會依靠源頭時鐘嘛 07/13 12:03
→ greg7575: 留下你覺得有用的那個晶振，其它全拔了齁 07/13 12:03
→ elguapo: 以上三種狀況開大buffer確實就能解決問題，但若環境要求 07/13 12:04
→ elguapo: 要越即時越好，那麼你會怎麼做？ 07/13 12:04
→ elguapo: 電腦主機板的晶振管音訊samples的發送？ 07/13 12:06
推 greg7575: 拔掉啊，你都說晶振沒用。 07/13 12:06
→ m9172250: buffer:很趕嗎 07/13 12:07
→ elguapo: 我只問那三個場景你所謂的晶振在哪裡。你一直說這音訊資 07/13 12:09
→ elguapo: 料是晶振處理就好？ 07/13 12:09
數位電子電路的時間，是用晶振振動次數 count 計數出來的....
沒有晶振，沒有時間，連 CPU 都不會動了
推 greg7575: 那剪掉嘛。尖嘴鉗能搞定的事，找我輸贏幹嘛 07/13 12:14
→ greg7575: 講晶振處理這幾個字就表示你啥也不懂 07/13 12:15
→ greg7575: 音樂檔像一坨文字稿，依讀稿機的速度輸出 07/13 12:17
→ greg7575: 這坨文字無論你用掛號的還是email的都不影響讀稿機 07/13 12:17
→ greg7575: 你的堅持讓我舉例舉到我都快沒想法了 07/13 12:18
→ elguapo: 因為我認為您應該是學有專精，有我不足的知識，來求教的 07/13 12:20
→ elguapo: ，謝謝。 07/13 12:20
推 greg7575: 文字稿本身沒有時間，內容傳輸只要保證正確就好 07/13 12:20
→ greg7575: 你看我沒有很正常啊，我都舉凡人的例子 07/13 12:20
→ greg7575: 不用太抬舉我。嘻嘻 07/13 12:20
→ elguapo: O 大您的回文不就寫了「時間」？ 07/13 12:21
是，因為時間是用晶振算出來的
就像 Roon 的回應，不是不需要時間，而是時間沒這麼關鍵到精度幾 μs
DAC 外的任何時鐘的品質，不需要過度擔心
關鍵確實是一個正常運行的網絡環境
推 greg7575: 人家的時間不是你的中原標準時間 07/13 12:24
→ greg7575: 我會保持隨時出來廢話，你要忍耐 07/13 12:24
→ m9172250: 這是守序中立的晶振 07/13 12:27
推 greg7575: 是不是有人以為晶振裡有小精靈，可以用軟體調整啊 07/13 12:30
→ elguapo: VCXO：當我塑膠 07/13 12:33
就像 Roon 所說的拿去用在 DAC ，適材適所
推 greg7575: 你已經調出ns級的正確，去笑那些晶振廠啊 07/13 12:36
→ greg7575: 自信這種東西用循環論證可以膨脹很快 07/13 12:37
推 greg7575: 你的校時軟體可以修正晶振的誤差，泰褲啦 07/13 12:39
→ elguapo: 留言怎麼會有情緒性反應？是因為我的問題太簡單而損人尊 07/13 12:50
→ elguapo: 嚴嗎？ 07/13 12:50
推 greg7575: 你是不是查了晶振原理之後大徹大悟了 07/13 12:55
→ greg7575: 我句句都在引導你考查真相啊 07/13 12:57
→ greg7575: 你的校時軟體能改變晶振嗎？快回答我 07/13 12:57
推 greg7575: 有問題就問，大家回答。耳機板那邊你也去看看 07/13 13:03
→ elguapo: 我從頭是一直在講「系統時鐘」，是閣下一直在扯晶振，請 07/13 13:08
→ elguapo: 勿不當連結。 07/13 13:08
晶振是系統時鐘的機心，一體兩面
以數位電子與程式設計的觀點，系統時鐘＝晶振＋計數器
校時程式能做的除對時外，是重新計算時間單位需要多少計數
但依 Roon 討論串這段的時間精度並不需要太過計較
另外回到 e大的想法，我會切成兩個獨立議題
一個是一般家用戶，尤其是沒有多區域同步播放需求及AES67 or Dante 多聲道
這個校時無關緊要
有多區域同步播放、AES67 or Dante 多聲道我不熟
但依上面 s大的回應，Protocol 應該有解決同步問題
不需要額外的處理才是
推 greg7575: 可惜我以為你大徹大悟了 07/13 13:26
推 greg7575: 無法用任何校時去改晶振。改顯示時間只是改爽的而已 07/13 13:31
推 greg7575: 偏偏我見識少只能舉通俗的例子。 07/13 13:58
→ greg7575: 讀稿機不會因為晚一兩秒開始唸而改變內容 07/13 13:59
→ greg7575: 語速也不會改變內容，只會改變聽感。 07/13 14:00
→ elguapo: 我誠心邀請O大來我家坐坐，我必奉為上賓，分享同步乙太 07/13 14:00
→ elguapo: 網路和AoIP的一些實作以及performance optimization方法 07/13 14:00
→ elguapo: ，並實作可重複呈現的收系統時鐘影響的音質變化（這真的 07/13 14:00
→ elguapo: 不用AB test，幾個簡單指令現象就會發生）；也或許我的me 07/13 14:00
→ elguapo: thodology有問題，也歡迎指正我的問題盲點。我也同意由您 07/13 14:00
→ elguapo: 來貼家訪後的文章，把您所見所聞都寫出來（包含照片、錄 07/13 14:00
→ elguapo: 音等）。 07/13 14:00
→ greg7575: 追求聽感是計較語速還是計較幾點幾分開始唸呢？ 07/13 14:00
→ greg7575: 他前面就說過了，有改變也不能證明你的理論是對的。 07/13 14:01
→ greg7575: 你的盲點這幾天大家講很清楚而你堅持只要見面輸贏。 07/13 14:01
→ greg7575: 至於你認為我沒學識只會搗亂，我欣然接受。 07/13 14:02
→ elguapo: 因為我講的這些現象要一邊講一邊做才好溝通，為什麼會有 07/13 14:15
→ elguapo: 見面輸贏的錯覺？ 07/13 14:15
→ m9172250: cpu:好啦 我有在做事 不要再敲我了 07/13 14:30
推 greg7575: 原理以及思辯方式都講這麼清楚，還能有什麼嗎？ 07/13 14:45
→ greg7575: 從一開始就沒否定你的行為會影響音質 07/13 14:45
→ greg7575: 我否定的是你對於你的行為的解釋 07/13 14:45
→ greg7575: 有認同你的解釋的人麻煩也出個聲 07/13 14:46
→ m9172250: 既然有差 要表現出來 不能人工耳錄一綠直接丟出來嗎 07/13 14:46
→ greg7575: 不要以為是引戰還是霸凌，我一直想幫你。 07/13 14:46
推 greg7575: 裝忙的cpu程式在耳機板也有人貼 07/13 14:49
推 greg7575: 你的第一篇的立論建立在校時軟體能改變晶振 07/13 15:02
→ greg7575: 這個立論錯誤，後面都不用提。 07/13 15:03
推 greg7575: 找誰家訪都不能改變這個錯誤立論 07/13 15:07
→ elguapo: 請問我文章哪一段敘述是要改變晶振？ 07/13 15:09
→ greg7575: 依有學過計算機原理的人都知道，時基由晶振決定 07/13 15:10
→ greg7575: 你能用校時軟體改變時基，這就是你的超能力 07/13 15:10
→ greg7575: 也許因為你沒有這個觀念才會有這麼多事。 07/13 15:11
→ greg7575: 沒有觀念學就有了，不是什麼人格品德的批評 07/13 15:12
推 kshieh: 校時對AoIP timestamp sync來說是極為重要的「必要之惡」 07/13 15:17
→ kshieh: 。而這裡99%的版友都是用實體訊號線(同軸/光纖/HDMI)直連 07/13 15:17
→ kshieh: ，完全不需要擔心這個因素，也難怪原原po會找不到知音 07/13 15:17
過去 e大的發文中我好像也回應過
AES67、Dante 是很難走入一般家庭中的
一般家庭中就算是透過區網串流，也沒什麼人會碰到需要同步的問題
因為音樂就你丟我收，收到就放
最多 AV 嘴型同步，但這也跟系統時間不太有直接連接
→ greg7575: 找chatgpt家訪，告訴他你的重大發現 07/13 15:17
→ elguapo: 我只問我的原貼哪一句話在說對時是改變晶振，結果你拿cha 07/13 15:21
→ elguapo: tGPT? 07/13 15:21
推 greg7575: 不然你說說你對於電腦的時間定義好嗎？ 07/13 15:25
→ greg7575: 如何在電腦上產生一秒。什麼是時間什麼是時鐘 07/13 15:26
→ greg7575: 請你大方的分享你的定義。謝謝你。越詳細越好 07/13 15:26
推 greg7575: 你的校時軟體能均勻時間就表示你能改變晶振呀 07/13 15:42
→ elguapo: 請摘出我原貼裡面，閣下認為我有表示是用對時工具改變晶 07/13 15:43
→ elguapo: 振的任何文字。有就截圖貼出來，沒有就說沒有。 07/13 15:43
推 icekiba: Steins;Gate 先從香蕉開始吧 07/13 15:45
→ elguapo: 對時是對 CLOCK_REALTIME 校正，您該不會不知道什麼是 CL 07/13 15:48
→ elguapo: OCK_REALTIME 吧？ 07/13 15:48
推 greg7575: 好啦你對。我人生不會再跟你起爭議。我保證 07/13 16:45
推 shaylin3: 現在聽個音樂,知識量要這麼豐富了嗎 07/13 16:48
推 icekiba: 一直都是 07/13 16:52
推 downlevel99: 沒有一個字看得懂的 我覺得可以退坑了 07/13 18:59
推 lee28119: 整串看完的結論是沒有同步需求就不用掛主時鐘 靠AD/DA 07/14 09:46
→ lee28119: 的時鐘就夠了這樣嗎？ 07/14 09:46
異步，就是各自為政，在規範內照自己的步調走
AD/DA 同時有的狀況，一般是在專業錄音或現場直播
可有主時鐘、或 Drift Correction、或用放刪除插入等策略，看選擇
※ 編輯: Oswyn (220.136.195.49 臺灣), 07/14/2023 14:04:31