[閒聊] LINUX優化之播放器修改篇

看板Headphone作者 (就是一隻毛貓)時間9年前 (2015/05/01 17:29), 9年前編輯推噓25(25推 0噓 8→)
留言33則, 24人參與, 最新討論串1/1
當整個系統被砍到只剩下5個程序在動 播放時總共只吃 30M+buffer 的記憶體 CPU就算降頻 還是只吃最多10% (當然不包括解碼) 你會發現自己真是糟蹋現代 HTPC 的超強計算能力.....XD ------------------------------------------------------- 以下本文 我現在的系統是以 RME MADIFX 這難搞的傢伙為主體 為了讓他發出正常的聲音，必須配合他怪異的播放資料排列方法 例如 大部分的音效硬體支援： SND-PCM-ACCESS-MMAP-INTERLEAVED |L R|L R|L R|L R|L R|L R|L R|L R|L R|L R|L R|L R|L R| （多聲道用同一個 buffer） RME 出的怪胎們： SND-PCM-ACCESS-MMAP-COMPLEX L|L|L|L|L|L|L|L|L|L|L|L| R|R|R|R|R|R|R|R|R|R|R|R| (每聲道各一條buffer) ---- 每條線分隔一個frame 等於一個sample ---- 其實背後的原因也很簡單，因為 MADIFX 號稱有 196 個聲道 如果是用 INTERLEAVED 進行存取，會非常沒有效率 唯有用 COMPLEX 才可以好好管理各聲道 而在命名傳統上，ID 裡有 COMPLEX 的東西都特別難搞（？ 所以目前綜觀 LINUX 的軟體，真的就只有 JACK 這個軟體支援 COMPLEX 存取 這表示，在 LINUX 要讓 RME 的聲卡唱歌，非得透過 JACK 這一關不可 因此我的系統也需要用下面的流程將音樂檔轉成 MADIFX 支援的音訊格式 MPD -> MPD JACK plugin -> JACK -> ALSA -> MADIFX driver 在這流程裡，JACK 做的唯一事情就是將 INTERLEAVED 轉為 COMPLEX 格式 雖然 JACK 號稱極輕量，我看他的原始碼還是包含大包大包處理視覺輸出的東西 這些多餘的東西就佔了一個環節，我覺得非常的不方便 於是就手癢了好幾個月，想要把 JACK 這一層整合到 MPD 裡..... (幾個月後....) 前天，我發現我精簡後的 MADIFX driver 精簡過頭了 他的 buffer 大小沒辦法塞下 192000Hz 的昇頻後資料，只能最高用 48000Hz 播放 JACK 知道這一點後，他就一聲不吭的忽略我的設定，直接用 48000Hz 播放了.... 所以我2個月以來，都自以為在聽 192000Hz 的聲音，其實只是 48000Hz .... 虧我還以為 HTPC 效能變好高，撥 192000Hz 都不吃效能 Orz Orz Orz .... .... 一下子就修好 driver 後，一怒之下就打算把 JACK 整坨逐出我的系統了！ 因為之前有花時間研究累積的 JACK 和 COMPLEX 的播放架構， 所以就只用了 2X 小時就完成所有的移植工作（？ MADIFX 在最後一個晚上的聲音變化： 單聲道雜訊 -> 單聲道低音雜訊 -> 單聲道畢卡索音訊 -> 雙聲道畢卡索音訊 -> 雙聲道正常音訊 x0.9 倍速 -> 正常發聲 這實在是一個值得感動的流程，但是實際上只是延長我的睡眠起始時間到早上六點而已 ..... 現在我的播放流程變成： MPD -> MPD MADIFX plugin -> ALSA -> MADIFX driver 我簡單的測試一下拔掉 JACK 前後的聲音差別： 優點： 韻味變好了，其他解析音場之類的就不仔細測了，總之是有過之而無不及 因為是自己動手改，音樂聽感有超強大的情感加成 減少了 JACK 的環節，少了4個可調參數 CPU 用量再減半 缺點 沒有 JACK 這一個環節，多了 8 -> ∞ 個可調參數（暈 塞資料進 buffer 的方法，我是用 Pulling 而不是用 Callback，超欠改 簡單說一下塞 buffer 的方法中，Pulling 和 Callback 的差別： Pulling: (一小時後) 播放器: 你孤單嗎？ Buffer: 不會耶！ (一小時後) 播放器: 你寂寞嗎？ Buffer: 有一點寂寞，但還不是太寂寞... (一個半小時後) 播放器: 我來晚拉~ 你覺得冷嗎？ Buffer: ----30分鐘前凍死了---- Callback: (一段時間後，手機響起) Buffer: 我孤單 >////< 播放器: 我來ㄌ！ (一段時間後，手機響起) Buffer: 我寂寞 >////< 播放器: 我來ㄌ！ (一段時間後，手機響起) Buffer: 我覺得冷 >////< 播放器: 我來ㄌ！ 總之，Callback 是一個非常有效率的方法，可以讓 buffer 及時填充資料 Pulling 對時間精度要求極高，而且浪費 CPU 資源，這應該是我下一步會改的地方 另外，以前和友人談到音訊編碼的格式問題， 因為 MADIFX 原生支援 32bits 整數 PCM 編碼以及 32bits 浮點數 PCM 編碼輸入 想說就趁這次大改 MPD 的機會測試一下兩者的差別 發現用整數 PCM 編碼播放的情況下，動態消失，細節變的模糊 浮點數 PCM 編碼就沒有上述的問題，JACK 的輸出也是以浮點數編碼為優先 但是理論上他們的資訊量應該是差不多的 問題可能出在 MADIFX 對浮點數的支援較好，或是解碼器的品質問題 但是這方面我就沒有深究了 最後， 希望我是全宇宙第一個改 MPD 原生支援 MADIFX 輸出的人，哈！ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 140.114.212.97 ※ 文章網址: https://www.ptt.cc/bbs/Headphone/M.1430472551.A.A15.html ※ 編輯: selnec (140.114.212.97), 05/01/2015 17:29:58
推
05/01 17:46, , 1F
看不懂也要推！
05/01 17:46, 1F
推
05/01 17:47, , 2F
看不懂推 等下GG大跑回來說已經完成更好的方法(?
05/01 17:47, 2F
他看不起還在地球上的人拉 XD
推
05/01 17:51, , 3F
真的看不懂，但真想聽看看
05/01 17:51, 3F
推
05/01 17:58, , 4F
雖不明 但覺厲!
05/01 17:58, 4F
推
05/01 18:18, , 5F
XDDDDD callback那邊超好笑
05/01 18:18, 5F
推
05/01 18:38, , 6F
看不懂還是推....
05/01 18:38, 6F
推
05/01 18:40, , 7F
看不懂，反正我用deadbeef+alsa（取消再取様）輸出就
05/01 18:40, 7F
→
05/01 18:40, , 8F
對了
05/01 18:40, 8F
推
05/01 18:40, , 9F
推！不過我也看不懂…
05/01 18:40, 9F
推
05/01 19:11, , 10F
快推 不然別人會以為我看不懂
05/01 19:11, 10F
抱歉拉 一定是不夠簡明易瞭的關係 (′‧ω‧‵) ※ 編輯: selnec (114.41.26.243), 05/01/2015 19:41:16
推
05/01 19:59, , 11F
114推 雖然我一個字都看不懂
05/01 19:59, 11F
→
05/01 20:05, , 12F
114路過推，不過我真的看不懂(茶
05/01 20:05, 12F
推
05/01 20:18, , 13F
推 看不懂
05/01 20:18, 13F
推
05/01 20:55, , 14F
是不會寫L系統好威好強狂勝m家好嗎？
05/01 20:55, 14F
推
05/01 21:16, , 15F
只能大推強者我室友了
05/01 21:16, 15F
推
05/01 21:42, , 16F
大推，什麼都看不懂www
05/01 21:42, 16F
推
05/01 22:35, , 17F
每個字都看得懂 但組再一起就
05/01 22:35, 17F
推
05/01 22:38, , 18F
求翻譯蒟蒻
05/01 22:38, 18F
好 以後都把英文翻成中文! ※ 編輯: selnec (114.41.26.243), 05/01/2015 22:46:05
推
05/01 23:01, , 19F
狂推 不過我還是整數派
05/01 23:01, 19F
推
05/01 23:09, , 20F
太強大了！
05/01 23:09, 20F
推
05/01 23:30, , 21F
反正沒在跑其他東西的話也不用改掉pulling了吧XD
05/01 23:30, 21F
同一個核心還有一個 madifx 的interrupt thread 在跑耶... 雖然我也覺得影響不大就是
推
05/01 23:34, , 22F
話說你cal back解釋好新潮
05/01 23:34, 22F
→
05/01 23:39, , 23F
純好奇，怎麼不用raspberry pi取代HTPC (?
05/01 23:39, 23F
不能換 RAM,單核,不能插pcie,效能太低 而且聲音...... ※ 編輯: selnec (114.41.26.243), 05/01/2015 23:59:35
推
05/02 00:21, , 24F
RPi聲音連CB都打不過
05/02 00:21, 24F
推
05/02 00:22, , 25F
等等，翻譯成中文還是看不懂啊
05/02 00:22, 25F
vvvvvvvvvvvvvvvvv第一個找到盲點的人vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
→
05/02 00:54, , 26F
所以你聽兩個月了都沒發覺192000Hz和48000Hz有什麼差別
05/02 00:54, 26F
→
05/02 00:54, , 27F
那幹嘛還用得那麼麻煩阿...
05/02 00:54, 27F
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 我有一段時間聲音突然和我熟悉的不一樣 而且居然還找不到問題點 就在這個狀態下 還帶到原音去和那裏的器材PK 我真是羞愧阿 Orz ※ 編輯: selnec (114.41.26.243), 05/02/2015 01:04:07
推
05/02 01:14, , 28F
是一種恍然大悟的fu嗎
05/02 01:14, 28F
→
05/02 01:21, , 29F
樓上突破盲腸
05/02 01:21, 29F
推
05/03 00:33, , 30F
有打算放到GitHub上面嗎 xXD
05/03 00:33, 30F
我加的這個模組只適用在我自己的設定說… 如果用mpd+rme聲卡的用戶變多我再考慮XD
→
05/03 00:35, , 31F
另外想問 解碼結果都是正確的前提 為何優(簡)化過較好聽
05/03 00:35, 31F
→
05/03 00:35, , 32F
是因為對頻率的解析更精准？
05/03 00:35, 32F
數位就是(ry 我想是因為 cpu loading/memory access latency/cpu affinity/ irq latency/caching/buffering之類的微調在系統優化到一定程度之後, 對機器訊號輸出的影響會越來越大 我實測上也真的會有差異… ※ 編輯: selnec (114.41.26.243), 05/03/2015 04:35:29
推
05/04 11:37, , 33F
白白龍喜寫程式的，完全看不懂... Orz
05/04 11:37, 33F
‣ 更多 selnec 的文章
文章代碼(AID): #1LGqTdeL (Headphone)