最好用的還是Clock Wave APP , 因為可以模擬BPC 中國商丘、JJY 日本九州、WWVB 美國科林斯堡、MSF 英國安托爾坎布裏亞邵、DCF77 德國曼福林根, 這些時區。 ... <看更多>
「電波對時 軟體」的推薦目錄：
- 關於電波對時 軟體 在 [心得] 運用Chrony 對時工具提升音訊品質- 看板Audiophile 的評價
- 關於電波對時 軟體 在 電波錶電波校時強制接收 的評價
- 關於電波對時 軟體 在 電波時鐘校正app的蘋果、安卓和微軟相關APP，MOBILE01 的評價
- 關於電波對時 軟體 在 【電波錶對時APP】SEIKO精工LUKIA 1B22機芯電波訊號接收 的評價
- 關於電波對時 軟體 在 星辰電波錶對時app的問題包括PTT、Dcard、Mobile01 的評價
- 關於電波對時 軟體 在 星辰電波錶對時app的問題包括PTT、Dcard、Mobile01 的評價
- 關於電波對時 軟體 在 星辰電波錶對時app的問題包括PTT、Dcard、Mobile01 的評價
- 關於電波對時 軟體 在 [新聞] 擺脫「電線人」！中醫大附醫與廣達合作- 看板Stock 的評價
電波對時 軟體 在 【電波錶對時APP】SEIKO精工LUKIA 1B22機芯電波訊號接收 的推薦與評價
精工#SEIKO # 電波 錶# 電波 校正帶您一起認識 電波 手錶！ 電波 錶是一種能接收“標準時間無線電訊號”並自動顯示正確時間與日期的手錶。 ... <看更多>
電波對時 軟體 在 星辰電波錶對時app的問題包括PTT、Dcard、Mobile01 的推薦與評價
另外網站citizen 錶的電波對時請教- Mobile01也說明：Android的只有日本JJY的電波模擬APP， IOS的才有全世界五局的電波模擬APP。 ... <看更多>
電波對時 軟體 在 星辰電波錶對時app的問題包括PTT、Dcard、Mobile01 的推薦與評價
另外網站citizen 錶的電波對時請教- Mobile01也說明：Android的只有日本JJY的電波模擬APP， IOS的才有全世界五局的電波模擬APP。 ... <看更多>
電波對時 軟體 在 星辰電波錶對時app的問題包括PTT、Dcard、Mobile01 的推薦與評價
另外網站citizen 錶的電波對時請教- Mobile01也說明：Android的只有日本JJY的電波模擬APP， IOS的才有全世界五局的電波模擬APP。 ... <看更多>
電波對時 軟體 在 [新聞] 擺脫「電線人」！中醫大附醫與廣達合作- 看板Stock 的推薦與評價
36歲的張先生睡眠時鼾聲雷動，睡眠長期無法持續，也造成家人無法安睡， ... 又需要病人一整晚配戴多種生理感測器：包括腦波圖、眼動電波圖、 下巴肌電 ... ... <看更多>
電波對時 軟體 在 [心得] 運用Chrony 對時工具提升音訊品質- 看板Audiophile 的推薦與評價
「紊亂的電腦系統時鐘，經過對時調節（realtime clock）到接近 AES11 Grade 2
的精度，進而增進電腦音訊品質。」
自從開始使用 Ravenna/AES67 AoIP 之後，對於時間的準確度也越來越要求；不久
前收了一張具備 GPS 接收器的 Intel E810-XXVDA4TGG1 網路卡，作為我的 AES67
的主時鐘，並將開箱文貼到 audiophilestyle 網站：
https://tinyurl.com/3p8ccjv2
本來想在 ptt 補充一下中文的部分，但後來發現有更值得討論的內容，遂決定先來
寫關於電腦作業系統時鐘的校對問題。
以 48000Hz 取樣率的音樂來說好了，相信很多燒友應該會認為是 48000Hz 的「
載波」在傳遞音訊。若有讀過 AES3 以及 AES67 的規範，其實音訊的傳遞是「每秒
傳送 48000 個取樣值」，若切更細一點，以 AES67 來說，數位音訊是每 1ms 傳送
48 個取樣值到目的地。
「若系統時鐘不穩定，充滿 jitter 而且偏移嚴重，那麼這個 1ms 還會是 1ms 嗎？」
這是我開始自己建構 AES67 主時鐘的時候不斷思考的問題。
成功的將 Intel E810 設定為我的 AES67 主時鐘之後，也嘗試將這張網卡當成我的
HQPlayer Embedded 伺服器的主鐘，機制是：
1. 依據 GPS 1PPS 信號 rising edge 擷取 GPS 模組解出的 NMEA 訊息 ->
2. 把 NMEA 更新至網卡上的 PTP hardware clock ->
3. 運用 PTP hardware clock 去同步系統時鐘 CLOCK_REALTIME 以及 AES67 的器材。
經過這樣的對時，HQPe 主機的時間精度可以達 +-10ns 範圍！個人發現 HQPe PCM
的升頻變好聽很多，毛躁感降低不少，慢慢的也懶得升頻 DSD 了。
後來再進一步將我的 Fitlet3 NAA 用光纖掛上 E810 的其中一個 SFP28 port，
用同個 PTP hardware clock，傳送 layer 2 的 802.1AS gPTP 的對時資料給
Fitlet3。
Fitlet3 的 CLOCK_REALTIME 雖然沒有很好，但精度還是能摧到 +-30ns，與 HQPe
server 同步後的聽感是，空間的殘響尾韻更顯著且又長了一點！
沒想到電腦主機正時之後的音訊品質，其改善幅度大到可以複製給來訪的朋友分辨，
所以乾脆愛屋及烏，把沒有辦法做 PTP 對時的電腦用 NTP 伺服器對時看看，結果
也是能得到很大的幫助！
我的 Atmos music 有 98% 是來自 Apple Music，將來源 Mac Mini M1 電腦用
本地端的 NTP server 做密集對時之後可達 <+-10us，Apple Music Atmos
定位精確度提升，尤其聽大編制的交響樂或大合唱，混亂感降低很多。
因此我想在這篇文章先介紹 Chrony 這個工具給諸君試看看。
Chrony 在 Linux 是家喻戶曉的對時工具，可以手動選擇離自己家最近的 NTP
伺服器，也能手動改動對時的次數頻率。
macOS 已經有 GUI 版，解壓縮立刻能執行：
https://whatroute.net/chronycontrol.html
第一次執行 ChronyControl 會提醒您將系統的自動對時關閉，畢竟兩個對時軟體
同時執行會打架，造成時鐘更紊亂。
Chrony 的介面很容易閱讀，跟 Linux 的 chronyc 一模一樣：
由於預設的伺服器通常比較「遠」（延遲較高），以個人經驗來說，最近的 NTP
伺服器理當是本地端的，其次是 ISP 提供的（但 ISP 提供的 NTP 伺服器階層可能
只到 Stratum 2）；最好的 NTP 伺服器當是國家提供的，是直接和原子鐘對時的
Stratum 1 等級。
我國設立的 NTP 伺服器是這幾個：
tock.stdtime.gov.tw
watch.stdtime.gov.tw
time.stdtime.gov.tw
clock.stdtime.gov.tw
tick.stdtime.gov.tw
可以用編輯的方式將這些伺服器鍵入 Chrony 的設定檔（按下 ChronyControl 視窗
左上角齒輪就會出現文字編輯器）：
按下右下角 Check Syntax 按鈕之後，只要文法沒錯誤，就能繼續按最右邊的
Install Config。
這樣 Chrony 就開始抓可用的 NTP 伺服器，並且選擇誤差最小的那個為主要對時
對象。
由於系統時鐘很快就會歪掉，所以若要長時間保持在 AES11 Grade 2 +-10ppm
（+-10us），那麼就必須要增加對時頻率；為了避免被 NTP server 視為惡意行為
（過度的 polling 可能會被判斷為 DDoS），個人建議對時頻率別太緊密，大約
10~30s 範圍都能接受。
若觀察到有理想的 NTP server 在附近，那麼就能在 Chrony 設定檔指定該台伺服
器對時的頻率，寫上：
server watch.stdtime.gov.tw minpoll 4 maxpoll 4 prefer
這段設定的意思是將 watch.stdtime.gov.tw 這台 NTP 伺服器當成我的最愛，然後
每 16 秒向她送出對時申請。
ChronyControl 有繪圖功能，按下視窗上緣的 Live Tracking 按鈕，可以觀察開始
對時之後系統時鐘的修正狀態：
主要看橘色的線，是代表系統時間均值，以截圖來看，我的 MBP13" 經過對時可以
達到並穩定在 AES11 Grade 2 +-10ppm 的要求了。
由於我對 Windows 作業系統工具不是很熟，增加對時頻率的方法可能要請版上高人
補完了... Orz
希望這個 Linux or macOS 系統設定的變動能為「以電腦為主要播放器材」的版友
帶來助益 :-)
「對時，是為了要有：一致的一秒長度、一致的一秒起點以及一致的曆日」。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.163.96.60 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Audiophile/M.1688994586.A.585.html
※ elguapo:轉錄至看板 Headphone 07/10 21:15
※ 編輯: elguapo (118.163.96.60 臺灣), 07/10/2023 22:11:10
※ 編輯: elguapo (118.163.96.60 臺灣), 07/10/2023 22:18:41
IME 在 free clock 狀態是無法滿足條件的。
正時後就有機會能符合這些要求。
※ 編輯: elguapo (118.163.96.60 臺灣), 07/10/2023 22:52:51
，令時鐘維持在理想的誤差範圍內。
時鐘資訊，把封包放到最正確時間的點去處理。
我的 case 只是因為網卡夠格當 PTP 主時鐘，因此借用 PHC 直接對系統正時。
若是其他 case 倒是有獨立的 PTP 主時鐘，同樣是用網路方式對全域對時。
都不一樣又會有什麼情況？其中一台總是慢 100ms、其中一台總是在 +-50ms 之間跳動，
這會無妨嗎？
是time-sensitive）時打上timestamp，讓處理端能把封包正確時序恢復。
恢復 free clock 再聽，就知道有沒有不一樣了。
先聽正時原因是對時對到正時並穩定需要一些時間，而破壞正時卻非常容易。
的 Ravenna driver 都只是 software slave mode，不會用到網卡的 PHC，故無法借
AES67 的時鐘資訊對電腦系統對時，電腦在這邊仍是 free clock state。
因此仍是需要另一個對時方式去將電腦正時。
※ 編輯: elguapo (118.163.96.60 臺灣), 07/11/2023 07:47:47
會買一張來用。
我貼這篇文也是很怕「晶振」和「時鐘」被混淆，尤其兩個英文都是 clock...
晶振，是數位電子的心臟，也可以作為一秒的參考來源（例如 10MHz ref signal）。
時鐘，是提供年月日時分秒的東西，時鐘的一秒長度定義，可以來自原子震盪頻率、
也可以來自晶振提供的 10MHz ref signal、也可以用來自衛星的 1PPS，甚或是電腦
自己用 looping 來算時間。
晶振，不會提供時間的起點，更不會去算閏秒。
時鐘，是時間起點的依據，UTC 時間也會根據 TAI 原子鐘算閏秒。
電腦的排程，例如每天早上六點叫起床，是依據「系統時鐘」來做，而不是晶振。
同樣的，電腦要每秒送出 48000 個數據，也是依據電腦自己的系統時鐘來做。
對於 DAC 的時鐘和電腦系統時鐘到底有沒有關係？我個人認為有關。
一般 USB DAC 會藉由 USB 控制晶片回傳 DAC 時鐘頻率給電腦，若電腦和 DAC 時鐘
有些落差，那麼電腦會採取 resampling 方式去符合 DAC 的頻率再把資料發送出去。
這點可從 macOS 的 Audio MIDI Setup 得證。
而這個 resampling 的過程，仍是吃電腦的系統時鐘來做；若電腦的系統時鐘不精確，
該如何保證 resampling 的品質？
※ 編輯: elguapo (118.163.96.60 臺灣), 07/11/2023 12:17:09
我們稱的 48000Hz 音訊，在 AES67 的定義，指的是「每秒 48000 個 samples」，
是離散的資料。換算每 1ms 送 48 個 samples，或是每 0.125ms 送 6 個 samples。
這裡無涉晶振，只和系統時間準確度有關（同時包含一秒的長度和一秒的起點）。
音訊均為數位且為即時系統，請問這樣的場景如何 close loop?
會歪很嚴重。
說個小故事：
我曾經買了一套軟體，授權是線上授權由中央伺服器控管。
結果使用三個月後我發現我買的軟體竟然授權失效@@，寫信給原作也找不出原因（
換了好幾個 license 也無法啟動）。
後來原作寫信給授權管理中心，他們只問我的電腦有沒有上網，我說我的電腦 24h
都在網路上怎麼可能沒連網（笑）。
結果授權中心也是為了我的問題花了好幾天功夫，才找到線索上次授權查詢的
時間戳記和授權伺服器的時間沒對上，造成授權失效。
後來我才發現原來我的電腦時鐘已經和隨便一台 NTP 差了大概 5min 吧。
三個月歪掉 5min... 後來我都乖乖的沒事就檢查一下 NTP 服務是否正常，電腦對時
有沒有對正，避免同樣的糗事發生。
System clock 確實有在 loop 內
https://tinyurl.com/39w2b2we
※ 編輯: elguapo (118.163.96.60 臺灣), 07/11/2023 14:31:59
※ 編輯: elguapo (118.163.96.60 臺灣), 07/11/2023 14:43:30
Roon 的 RAAT 確是用系統時鐘在調節音訊的發送。
... <看更多>