PTT數位生活區 / Audiophile (電腦喇叭 音響系統)

[心得] S/PDIF (TOSLINK) 二三四

看板Audiophile (電腦喇叭 音響系統)作者 (Oswyn)時間3年前 (2020/06/26 20:52), 3年前編輯推噓12(12推 0噓 15→)
留言27則, 4人參與, 3年前最新討論串1/1
AES3 和 S/PDIF(coaxial & fiber) 在硬體(傳輸媒介/電平)上有差異外，通訊協定使 用 Biphase-mark Code 將時鐘與數據信號一起編碼只有 channel status 代表的意義 不相同 AES3 主要使用在專業設備，而 S/PDIF 用於消費性產品 AES3 當時已有 24-bit 的應用。但 S/PDIF 推出時 Audio data 只使用 20 bit，主要 是 CD 的 44.1 kHz/16-bit 及 DAT(Digital Audio Tape) 的 48 kHz/20-bit 受限於頻寬多聲道需使用 Dolby Digital or DTS 這類壓縮格式。立體聲不論格式一律 以 32-bit 的 Sub-frame 來傳送 Audio sample data 0 3 4 7 8 27 28 29 30 31 Preamble Auxiliary LSB 20-bit audio sample word MSB V U C P sample bits ※ Validity bit、User data bit、Channel status bit、Parity bit |M| |W| |B| |W| |M| |W| |X| Channel_1 |Y| Channel_2 |Z| Channel_1 |Y| Channel_2 |X| Channel_1 |Y|... | | | | |<Sub-frame 1>|<Sub-frame 2>| |<------- Frame 191 ------->|<------- Frame 0 ------->|<------- Frame 1... <<<------- Block ---------->|<---------- Block --------------------------->>> 兩個 Sub-frame(channel) 組成一個 Frame(立體聲)，192 個 Frames 組成一個 Block bit 0~3 的 Preamble 以違反 Biphase-mark Code 的方式編碼所以接收側可以識別 並依前一個 bit（上一組 Sub-frame 的 Parity bit）是零或一的不同有 3*2 六組固 定編碼，用來同步時間與識別各 Block、Frame、Sub-frame 的開頭 AES3 使用 Z Y X 為代號；S/PDIF 使用 B W M 但其實是一樣的東西 Audio sample word 的 20-bit 加 Auxiliary sample bits 的 4-bit 可擴展為 24-bit 都是低位至高位。Audio Data 的 MSB 一律對齊至第 27-bit 傳送方沒使用到的低位 bit 填充零，接收方無法用的低位 bit 就丟棄 I2S 也是無用填零或丟棄但其 bit 順序是 MSB->LSB，剛好跟 LSB->MSB 的 S/PDIF 用 FIFO 的方式交換 Audio data 不論傳送或接收方是 16-bit 20-bit 24-bit 都能在此框架下交換 標準的 AES3 & S/PDIF Sub-frame 長度永遠是 32-bit，所以 Audio data 最高 24-bit 近年有支援 32-bit Audio data 的硬體，將上述的 4+20 擴充到 8+24，Sub-frame 成 為了 40-bit；所以硬體不認得 40-bit 結構的就無法傳送或接收 32-bit Audio data 另外、為由於訊號包含了時鐘，所以傳送單聲道時還是得傳送兩個 Channel，資料存於 Ch1、Ch2 資料填充零 一個 Block 中有 192*2ch 的 Sub-Frame 兩個 Channel 的各自 Sub-frame 的第 30 bit Channel status bit 加起來各有 192-bit 或以 8-bit 一組組成 24 bytes 來表示 Channel status data 主要是儲存 Audio sample 的 bit-depth、Audio channel 數、Sampling frequency、 Time code、Pre-emphasis 等資料 Parity bit 不計 Preamble、只檢查 bit 4~30。但共計 27-bit 的同位位元檢查強度 如果體質好 BER 低就有用，如果體質差根本是做健康的就是了 ※ 標準的 Data rate 的計算＝Sampling frequency * 32-bit * 2 channel 44.1 kHz * 32-bit * 2ch = 2.8224 Mbit/s 48 kHz * 32-bit * 2ch = 3.072 Mbit/s 96 kHz * 32-bit * 2ch = 6.144 Mbit/s 192 kHz * 32-bit * 2ch = 12.288 Mbit/s 特殊的 40-bit Data rate＝Sampling frequency * 40-bit * 2 channel ※ 所以除了非標準的 32-bit Audio data 不論是傳送 16、20、24-bit 的 Audio data 基本上不會引發錯誤。只差在如果送出高 bit-depth data 至只能處理低 bit-depth 的硬體時會發生資料截斷(丟棄) 由於 S/PDIF 是單向傳輸所以使用者得自行處理這類問題 且由於是單向傳輸、無法重送，Parity bit 要檢查 27-bit 的資料 基本上表示這是一個脆弱的 Protocol -- 人間五十年、化天のうちを比ぶれば、夢幻の如くなり ^,,,^ 一度生を享け、滅せぬもののあるべきか (ミ‵ω′)\m/ NOBUMETAL DEATH!!(乂'ω') -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.129.0.51 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Audiophile/M.1593175951.A.798.html
推
06/26 22:09, 3年前 , 1F
推！
06/26 22:09, 1F
→
06/26 22:10, 3年前 , 2F
感覺起來，古早時代，因為傳輸速度不佳+網路差，所以只要
06/26 22:10, 2F
→
06/26 22:11, 3年前 , 3F
AUDIO多採用不同程度的 「不確認 或 不重傳」策略。不過看
06/26 22:11, 3F
→
06/26 22:11, 3年前 , 4F
起來好像也沒有造成什麼大礙就是。
06/26 22:11, 4F
推
06/26 22:13, 3年前 , 5F
很多問題 只是我們大多會碰到的都是家電產品等級
06/26 22:13, 5F
不確認或不重傳主要是因為即時性，要能重傳就會加大延遲(buffer) 這在 Audio/Video streaming 是個問題 而且很複雜，像 S/PDIF Frame 也沒序號，要重傳要傳哪段 對 RT i/f output 方來說我的 Audio streaming 上線還在跑(因為是 RT) 對 i/f input 方來說我在等 output 重傳時手上有可能沒東西可播了 所以不如就將錯就錯不重傳最單純 S/PDIF or USB Audio Class 2.0 在跑 RT Streaming audio 時都沒重傳 這跟網路 OLG、Video streaming、Music streaming 都是用 UDP 一樣 像 S/PDIF 的訊號跟時鐘是綁一起的 Biphase-mark Code 一個 bit 要兩個 clock 一個 Audio frame 要 64-bit(128 clocks) 是固定的，也沒得插重傳資料
推
06/26 22:26, 3年前 , 6F
搞到影音不同步就糗了 這在當時吵很大 HDMI 剛出來也是
06/26 22:26, 6F
補充個 RME Audio 員工提供的如何(試)聽什麼是有問題的 TOSLINK cable 非常緩慢的把光纖從插槽拔出來 就是稍微讓光纖跟接收器有點距離但又沒完全斷開，讓耦合度變差就能模擬有問題的光 纖的聽感XD RME Audio 員工表示 ADI-2 DAC 使用的 receiver 頻寬為 25 Mbit/s 不需要玻璃光纖ww 他們家測過 ADI-2 Pro 以 192 kHz 用標準的 10m Plastic Optical Fiber (POF) 輸 出至 repeater 再從另一個 10m POF 到 DAC (這個 DAC 應該是指 ADI-2 DAC) Works flawlessly. 所以不需要不需要超級昂貴的 solutions 嗯、德國標準 不過要小心標準的光纖是需要 polished (clear cut) surface
推
06/27 07:47, 3年前 , 7F
我對於 RME 的講法遲疑 我還是用好一點的好 不過最近沒錢連
06/27 07:47, 7F
→
06/27 07:47, 3年前 , 8F
擴都不夠燒 更別說燒喇叭跟 DAC (死)
06/27 07:47, 8F
我想 RME 的說法應該是建立在他們用料好也就是體質佳 25 Mbit/s 是 192 kHz 需求的兩倍所以能容忍更多的抖動也不會有問題 所以只需要"標準"的普通光纖就能工作正常 前提是只要資料傳輸完美，數據抖動在異步模式不會影響輸出音質吧
推
06/27 09:23, 3年前 , 9F
異步模式真的可以少很多問題
06/27 09:23, 9F
推
06/27 10:05, 3年前 , 10F
請問您的意思是說我換玻璃光纖有可能改善聲音嗎？
06/27 10:05, 10F
改善聲音嗎？我個人無法做出這種保證，可以肯定的只有 如果目前的光纖不良或硬體的體質比較差，換用更好的光纖會提升傳輸的品質 訊號的抖動也會有改善 但在異步模式下數據抖動已經被 Buffer 隔離 這會不會影響聲音兩派看法嚴重對立，RME 的看法就是偏向不會的一方 當然、如果 DAC 是工作在同步模式，我想使用更好的光纖會大大減少採樣抖動 Clock 的正確性會提升是有正面的影響
推
06/27 10:18, 3年前 , 11F
長知識！ 德國貨 的品質，真的不是蓋的。
06/27 10:18, 11F
推
06/27 10:48, 3年前 , 12F
異步模式 能否解決抖動的問題，是有正確答案。只是台灣做
06/27 10:48, 12F
→
06/27 10:49, 3年前 , 13F
AUDIO DAC IC的公司(人)太少了。而和音響有關的專業公司，
06/27 10:49, 13F
→
06/27 10:50, 3年前 , 14F
好像只有 驊迅(C-MEIDA)一家。只要問的到這家的RD，就會有
06/27 10:50, 14F
→
06/27 10:50, 3年前 , 15F
正確答案了。
06/27 10:50, 15F
更上游的 ASIO / WASAPI buffer size 都有人堅稱會影響聽感了 DAC 必定會有兩個迴路，輸入的數位與輸出的類比 兩者間的隔離好壞影響很大 看似數位迴數的部分一定不會影響到類比端實在很難說
推
06/27 11:00, 3年前 , 16F
Usher CD-1 USB 就是用 C 家產品不予置評 某友人就是設計者
06/27 11:00, 16F
※ 編輯: Oswyn (220.129.0.51 臺灣), 06/27/2020 11:28:40
推
06/27 14:25, 3年前 , 17F
如果只是想討論「數位資訊與clock 對 類比輸出波型」的差異
06/27 14:25, 17F
→
06/27 14:26, 3年前 , 18F
那驊迅應該是足以回覆的。尤其是經歷過 同步=>非同步的架構
06/27 14:26, 18F
→
06/27 14:26, 3年前 , 19F
轉換，當時他們內部應該早就驗過有報告，而且經過市場驗證
06/27 14:26, 19F
→
06/27 14:27, 3年前 , 20F
同時，萬一數位資料有誤時，會不會像CDP一樣自動補差，這個
06/27 14:27, 20F
→
06/27 14:27, 3年前 , 21F
也可以順便討論一下。
06/27 14:27, 21F
推
06/30 08:33, 3年前 , 22F
學習了，推！
06/30 08:33, 22F
推
06/30 09:04, 3年前 , 23F
有個小小的問題，那個 S/PDIF 傳輸至 I2S
06/30 09:04, 23F
→
06/30 09:04, 3年前 , 24F
的那個位元顛倒的音訊資料交換方式，
06/30 09:04, 24F
→
06/30 09:04, 3年前 , 25F
若以 bit-wise 觀點來看，是否比較像 FILO 而不是 FIFO?
06/30 09:04, 25F
→
06/30 09:04, 3年前 , 26F
雖然若以 subframe 以上的觀點來看，的確是 FIFO 沒錯。
06/30 09:04, 26F
→
06/30 09:04, 3年前 , 27F
不過也有可能實際硬體實作不需用到 FIFO，直接寫死電路
06/30 09:04, 27F
‣ 更多 Oswyn 的文章
文章代碼(AID): #1UzU-FUO (Audiophile)
Audiophile 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 Oswyn 的文章
文章代碼(AID): #1UzU-FUO (Audiophile)