[介紹&討論] PC端UPnP串流和本地音樂撥放器(CAS Player): TuneBrowser(Windows)

Updated: 2024110301, 針對WASAPI API的Source of channel count說明
Updated: 2024110302, DSD-PCM Conversion說明

由於v5.6.0版本已正式發佈, 本篇將介紹關於Windows系統的TuneBrowser的基本使用, 這個是我長年以來使用的CAS Player. 這是極少數CAS Players裡能提供出色的播放功能. 尤其在複雜的定製化功能部份以及細緻的UPnP Renderer設定.
加上該作者通常願意聽取使用者的意見.
https://tunebrowser.tikisoft.net/summary/

這款軟體並不是完全免費, 他有一些限制:


不過, 他價格並不高, 相當便宜. 並且license授權較寬鬆:
One license allows up to 4 PCs per residence.
本篇只是做為基本的介紹和持續更進它的變化. TuneBrowser比較偏向Music Library的管理, 因此對於有大量本地端音樂庫管理來說是相當適合. 最新的版本: v5.6.0已經發佈, 做了大量的改進. 尤其是UPnP功能部份.

可以關注長年來的改進部分(由於是日文顯示, 可以使用網站提供的google translation):
https://tunebrowser.tikisoft.net/change-log/
該軟體只提供日文和英文版本, 這邊需要特別注意! 對於特別注重UPnP renderer來執行音樂撥放的使用者來說, TuneBrowser目前提供非常出色的UPnP機能(就我所知目前極少數CAS Players中, UPnP功能部份做得相當強大, 這是由於使用者的持續反饋).

在Windows CAS Players大多對於UPnP renderer這部分支持普遍都不完善, 包括Foobar2000的UPnP plugin(Peter是免費提供, 不能要求太多). TuneBrowser在這部分做了極大的強化, 包括Nested UPnP Tree stack, 這意味著它提供了對特殊廠牌設備的特別優化, 例如Denon的HEOS.

本篇只會就音樂撥放這部份來介紹:
1. WASAPI&ASIO API
2. UPnP Renderer Support
Music Library管理和視覺效果以及複雜的訂製化UI不會做太多琢磨.
(其實這部分很多值得說明, 只是往後看看要不要持續更新)

作為日本作者Tiki開發的TuneBrowser目前提供以下功能:

1. 支持 DSD、FLAC、TTA、MP3、AAC、ALAC、Ogg Vorbis、WavPack、Wave、AIFF、APE、WMA、Opus 格式。可以輕鬆管理和播放這些文件。
2. 支持 WASAPI 的排他模式/共享模式，以及 ASIO 播放。
3. 從版本 5.2 開始，也可以向外部 UPnP Renderer 發送播放指令（並不保證所有 UPnP Renderer 都能正常運作）。
4. 全面利用 DirectX（Direct2D），實現了動態且高速（並且稍有趣味）的畫面繪製。
5. 使用了完全原創的播放引擎。
6. 內部結構採用 C++ 的模板及 CRTP，實現了低 CPU 負載。例如，音量控制根據是否需要增益調整有不同的處理方式，如果不需要增益調整，則不會進行多餘的運算和判斷；而進行增益調整時則以 32 位元處理。
7. 可以根據多種條件，例如藝術家、作曲家、演奏家、曲名等進行聯想搜索。不僅是搖滾、爵士樂，經過考慮也能充分管理古典音樂。
8. 支持所有格式（包括 DSD）無縫播放。
9. 支持 VST3 插件。
10. 支持通過 OpenHome 使用智能手機/平板進行操作，可使用 Linn Kazoo 等控制器。
11. 支持 Last.fm 的 Scrobble 功能。
12. 通過“RAMDecode”功能，能夠在無需磁碟存取的情況下，直接在記憶體（RAM）中進行解碼和播放。
13. 完全支持 Unicode。
14. 除非明確進行標籤編輯操作，否則不會修改原文件。
15. 在頻譜顯示中，設計上考慮了讓演奏中的音樂「可見」。當沉浸於音樂中時，過一段時間後，畫面上會開始一些小互動（當然已考慮到不影響音質）。希望您能享受其中的樂趣。

這邊做一些重點解釋進行補充:

1. 支持大量普遍的音樂格式支援, 這包括高位元的浮點格式支持. 例如少見的64-bit wave format.
2. 強大出色的UPnP Renderer管理機能, 支持複雜的Nested UPnP Tree stack. 對於DENON的HEOS架構特別優化(該廠有借他設備測試過).
3. 注意的是他不支持帶DLNA tag的設備, 因為該作者對過度商業化的協議較為反感. 基於UPnP擴展的DLNA協議, 作者並不願意提供支持. 要特別注意, 比方說目前Silent Angel(202411)的MIT串流器尚未支持不帶DLNA tag的UPnP(未來的release會支持).
4. GUI是以.NET框架開發, 採用D2D API. 這是一個簡化的D3D, 意味著他建構在D3D API的高層次stack上. 比起單純的GDI圖形加速(例如bitmap搬移), 較為充分利用GPU資源,
5. 全面的DSD格式支援. 特別注意UPnP renderer部分, 普遍DAC無法解碼DST這種壓縮格式的DSD. 當然, 我不是很確定目前基於高性能FPGA, 例如Xilinx Artix®-7,或著複雜的CPLD電路結構是否能夠處理. 就我目前的測試, Tesla G3的Auralic Vega作為UPnP Renderer沒辦法對這個這個壓縮DSD解碼. UPnP renderer並不知道是否為壓縮格式, 他只知道送來的MIME. 對此, 作者在這部分重寫的UPnP處理邏輯, 對於特殊的音樂格式提供額外處理.
6. RAMDecode不是RAM Disk, 他是本地端解碼器進行解碼的一個過程, 這意味著當啟動RAMDecode會提供解碼過程中, 將音樂檔案加載到系統記憶體. 這有助於撥放過程中的優化, 不論是WASAPI或著ASIO. 該功能不支持UPnP Renderer, 因為UPnP是基於遠程HTTP呼叫.
7. 關於上面的第15項, 是基於播放中呈現的視覺效果. 這是得益於通過D2D API使用GPU的實現.

WASAPI&ASIO API
在WASAPI和ASIO API的支持, 作者做了很多改進, 得益於使用者的相關反饋.

對於細節不清楚的, 可以按照預設值使用. 這邊要特別注意的是DSD格式音樂撥放這部分.
有鑑於到目前為止微軟提供的WASAPI API到現在沒有提供DSD NATIVE(* 詳情可查詢微軟MSDN的核心音訊 API文件). 因此只能使用DoP, WASAPI API對於DoP支持非常良好. 如果本地端支援DSD格式的DAC沒有提供特製的ASIO驅動程式, 僅支持UAC 2.0協議. 請在WASAPI設定打開DoP, 如下畫面所示:

支援DSD NATIVE並且提供專屬ASIO驅動程式的DAC設備則可以按照預設值.
使用者可以從如下畫面進行設備的切換撥放:

這邊設備切換部分的區域稱為Player View. 對於本地端撥放追求Hi-Fi SQ, 您可以通過DDC或著USB Isolator串接外部DAC進行撥放. (聽不聽的差異, 這就是個人主觀的問題).
有些設定細節可能需要相關開發經驗或著基礎知識, 這需要查詢微軟MSDN文件. 完全不熟悉的使用者可以按照預設值.


在WASAPI API的通用設定或著專屬設定下的WASAPI settings(2)有一個Source of channel count. 顧名思義, 獲取設備端的聲道數量資訊. WASAPI的Exclusive(獨佔)或Shared(共享)會影響這個設定項目. 我們可以根據上圖的API stack參考.

1. EndpointVolume: 會使用Core Audio API stack下的EndpointVolume API, 基於IAudioEndpointVolume::GetChannelCount方法呼叫取得音訊數據流中輸入或離開音訊端點裝置的通道數.
2. PhysicalSpeakers: 通過PKEY_AudioEndpoint_PhysicalSpeakers屬性獲取遮罩碼(mask). 遮罩碼會定義實體聲道數量.
3. MixFormat: 通過系統混音器(mixer), 使用特定的結構(struct)取得相關的聲道數資訊. Exclusive模式下沒有作用. 因為他會繞過mixer.

通常按照預設值即可, 因為TuneBrowser預設的WASAPI是啟用Exclusive, 他會繞過mixer. 會由應用程式來取得端點設備的存取權並且獨佔, 因此通過TuneBrowser本身來決定.

RAMDecode
這是本地端撥放的功能獲益之一, 請注意! 他不是RAM Disk, 而是基於解碼過程中的一個加載流程.
需要啟動他, 如下畫面所示:


關於他的功能細節部分, 是終端設備的系統記憶體大小決定. 如果有32GB RAM以上的記憶體空間, 您可以適度的調整. 例如關於多執行緒的併發載入數量或著最常設定的加載記憶體尺寸.
再次需要強調的是, UPnP Renderer不支持該功能. 這是因為UPnP是基於網路協議的遠程HTTP呼叫, 並不是本地端解碼的一個過程. 作者沒有打算提供內建RAM Disk的支援.

SoX Resampler
Resampler是目前絕大部分CAS Players具備的基本功能, TuneBrowser使用的是SoX. 並且提供比較靈活的設置.


DSD-PCM Conversion
該項目從title就可以看出他是針對DSD即時轉碼成PCM(on-the-fly)的設定, 一般情況下按照預設值即可

** DSD-PCM transcoding不會使用SoX來操作, 而是基於Maxim V.Anisiutkin授權的SACD中的libdsd2pcm組件.
** 增益(Gain)功能對UPnP Renderer的DSD-PCM transcoding(ProxyStream)有效

UPnP Renderer Support
對於Hi-Fi SQ較嚴苛需求的使用者, 這無疑是一個最好的選擇. 這邊特別注意廠商支援UPnP stack的完善程度. 諸如Auralic從2014年開始把UPnP stack徹底drop掉, 導致UPnP renderer功能完全異常.
請注意, 目前不支持基於OpenHome, a.k.a ohNet API,的UPnP擴展作為renderer.
(* 將設備端(target device)視為OpenHome player)


從v5.3.0之後的版本開始, UPnP renderer支持做了大規模的改進. 直至目前的v5.6.0, 提供相當豐富的UPnP功能, 這是極少數Windows作業系統CAS Players能夠做到的, 當然! 這是充分基於使用者的持續反饋.
TuneBrowser對於DENON和Marantz的HEOS提供的UPnP做了特別優化, 這是由於前幾年廠商有提供設備給作者測試.
在技術細節上, 良好的UPnP renderer支持至少必須要提供如下幾個API呼叫:

因此良好的UPnP支援與實作顯然特別重要, 例如WiiM提供了極為良好的UPnP renderer實作.
ifi-audio也提供實作, 有鑑於目前的DIDL-lite metadata bug一直無法獲得解決, 暫時不能說他是良好支持. 可以說他可以提供支持, 但是播放過程中. seekbar(timebar)功能會異常.

對檔案格式的識別, 通過UPnP renderer設備呼叫由於是基於遠程HTTP呼叫, 因此通常都是通過從設備端取得MIME清單來識別相容性, 如下圖:

上圖設備為Holo Audio RED串流器, 它提供極為豐富的MIME清單以獲取絕大部分音樂檔案編碼格式支持.
** [Quick Guide] 如何檢查串流機能夠支援的音訊格式
https://www.mobile01.com/topicdetail.php?f=348&t=6879186

接下來, 如果要啟動UPnP renderer功能. 按照如下畫面啟用相關功能:

當啟動這些功能後, TuneBrowser便會定期掃描本地端網路是否存在相關的支援設備. UPnP是基於Multicast發送, 請注意! 必須要同一個網段, 除非您具備相關網路經驗並且設備支援相關的Multicast routing才有機會能夠處理跨網段的支援.

掃描取得後的設備便會加載到device list, 如下畫面所示:

在這之後的操作都將會是Unicast操作, TuneBrowser在UPnP renderer實作上提供了DIDL-lite metadata和訂閱/通知機制. 在TuneBrowser對於UPnP renderer有一個特別重要的核心引擎: ProxyStream.

ProxyStream通常做為一個代理端, 通常用於UPnP renderer設備無法支持特定的音樂格式後便會啟動這個核心引擎. 作者在後期的版本做了大量的改進.
當不支持的音樂格式, 啟動ProxyStream後. 便會進行Transcoding的操作, 這個操作是on-the-fly(即時). 該操作會將該音樂檔案進行轉碼成PCM後封裝在FLAC, 提供給UPnP Renderer進行相容性撥放. 在這個時候, 您會看到從Player View畫面的Transcoding status會呈現”WPRX”.

動態Transcoding變化, 這是作者提供的一個改進. ProxyStream會依照類似本地端的DSD DoP播放依樣. 當遇到DSD格式音樂播放, DSD64會以88.2k, DSD128會以176.4k等往下類推轉碼.

另外可以從UPnP Status View去查看相關資訊, 如下為WiiM Pro Plus設備:

從上圖可以看到ProxyStream已經被啟動, 顯示為”WavProxy”. 另外也可以看到該設備能夠支持的音樂格式, UPnP協議會以MIME來識別. 這點請特別注意!

當您的UPnP renderer設備針對當前播放的音樂格式提供支持, 例如flac. 這時候便會不會啟動ProxyStream引擎. 他在Player View將會呈現如下資訊:

這時候, UPnP renderer設備會取得的是原生的音樂檔案內容(通過HTTP呼叫).

豐富的UPnP Renderer特徵, TuneBrowser目前實作了一些其他播放軟體所沒有的一些功能, 這些功能通常都是為了增強對UPnP Renderer設備端的相容性:

這邊將只會重點介紹幾個功能. 首先來看Added MIME types項目.
最初這個項目是針對DENON&Marantz的HEOS特製的, 來看一個示例如下:

可以注意到他MIME清單並沒有關於DSD格式的支持. 但是實質上, HEOS的UPnP支援DSD格式. 通過Added MIME types項目可以強制壓入額外的MIME.

試圖播放DSD64格式檔案呈現資訊如下:

這邊注意到幾個資訊:

1. 當前播放的是DSD64
2. ProxyStream資訊顯示Normal. 這代表沒有啟動ProxyStream核心引擎.
3. MIME清單被額外壓入”audio/dff”和”audio/dsf”的DSD格式

從這三個資訊便可以得知, 當前的UPnP renderer設備已經原生播放DSD格式檔案.
PS: WiiM設備沒辦法額外壓入DSD格式, 強制壓入將會提示播放錯誤. WiiM在這部分尚未提供良好的支持, 縱使他的DAC晶片支持DSD解碼. WiiM在DSD格式播放的方式比較特殊, 發送的AVTransportURI命令塞入的metadata也是特製的, 僅能通過他的App播放. TuneBrowser作者不太可能會為了這個廠牌的設備進行另外的特製化. 要注意的是! 即使WiiM在app播放DSD應該都是經過transcoding. 就我所知沒有DSD NATIVE.
** DoPE支持? 作者從未考慮過DoPE(DSD over PCM Ethernet)的支持, 因為目前並不廣泛使用.

Excluded Encoder types項目是當初針對普遍DAC不支持DST編碼的DSD所設計的. 前面提到UPnP renderer設備只會通過MIME獲取得知的檔案類型, 那麼會可能有一個情況:
1. 送出去的檔案副檔名為DFF
2. DFF封裝的是DST編碼
最終結果會造成UPnP renderer設備可能不會有任何回應(MIME: audio/dff). 並且播放無法成功. Excluded Encoder types最初就是針對這個問題進行解決.

預設值為”DFF/DST”. 在這個情況下, DST編碼格式檔案便會先使用ProxyStream進行Transcoding再送到UPnP renderer設備端. 這保證了額外的相容性. 當然! 您也可以填入其他音樂編碼格式, 例如”FLAC”等, 前提是如果有特殊需要. 否則, 一般保持預設值即可.

“Sample rate limit”和”Bit depth limit”是兩個額外的特殊項目, 尤其”Bit depth limit”在某些UPnP renderer設備是有效的, 以下展示一個案例. 當”Bit depth limit”按照預設值為0.

這是一個少見的情況. 當播放的音樂格式為32-bit. 根據上圖的設備為Denon Home 350, 該設備不支援32-bit的bit depth. 在這個情況下, ”Bit depth limit”就會有用處了, 將其設置為24後. 再次播放:

從上圖可以看出, 這時候已經成功播放了! 因為他會先啟動ProxyStream進行轉碼.

“Sample rate limit”和”Bit depth limit”同樣也是用於增強UPnP renderer設備端的相容性, 預設值為0. 當然特定需要的時候, 便可使用.
在v5.5.3開始後, 作者Tiki重寫的UPnP renderer絕大部分的處理邏輯來改進對UPnP renderer的支持.

以上是在本篇介紹TuneBrowser的播放核心的部分, WASAPI&ASIO API和UPnP Renderer Support.

在本地串流協議上, 有NAA, Diretta, Scream等. 不過這些協議目前只有特定CAS Players支持, 例如ROON支持NAA, 這也是大多Hi-Fi設備認證最多的. 但是從廣義上來說, 大宗依然以UPnP或著DLNA協議為主.
往後也許可能會持續更新內容, 以上!

謝謝惠顧…