發表文章

升級電腦

圖片
 組了一台新電腦特此紀錄一下 整台用原價屋線上系統組直接運送至家中 Intel i5-13600KF 微星 B760 TOMAHAWK WIFI 威剛 XPG S70BLADE 1TB 利民 Burst Assassin 120 ARGB 技嘉 RTX3060 GAMING OC 12G 聯力 LANCOOL 216 RGB  全漢 HYDRO G PRO 750W 1. 降壓 剛買來滿功耗(~200w)直接撞功耗牆(cpu throttling),後來一直就在想換掉CPU散熱器,後來看了以下影片降壓可以穩跑5G功耗約為150w左右溫度最高溫只有80度。 https://www.youtube.com/watch?v=quQ_VOwweHE 2. 加裝RGB燈 看了對岸組裝以下機殼的風格,我想也來加個燈來玩玩 https://www.chiphell.com/thread-2467150-1-1.html https://www.zfrontier.com/app/flow/OQBZNOyz0nQo https://zhuanlan.zhihu.com/p/587216739 本來也想把後面的14cm風扇換成RGB,但是風量實在很大也就不浪費這個寶貴的內建風扇。 3. 升級顯卡(主要是用來AI繪圖上) 技嘉 RTX3060 GAMING OC 12G 升級成 微星 GeForce RTX 4080 16GB GAMING X TRIO,選 微星顯卡主要是比其技嘉靜音和便宜,整機都是微星裝置燈光控制也比較方便, RTX3060  能算但是有些圖算很久有些算不出來,為什麼不上4090? Power的瓦數不夠也不太想買卡王。 4. 再加裝一片SSD

實時PCM轉換DSD實作

自從我開始開發XAMP2之後,基本上算是很頻繁的更新,直到今年開始竟然有人開始提了issule, [SUGGESTION] Add PCM to DSD "resampling" 喔... 有這功能的撥放器都要收費耶~ 思前想後都覺得有難度(雖然之前有想挑戰看看), 後來那位外過仁兄提供了一個不錯的參考專案 PCM-DSD_Converter 接著我就著手開始 首先要想一下這個Converter要放在DSP哪邊呢? 因為Converter所以一定是最後輸出要處理的,所以必須要換掉最終寫出的資料的SampleWriter。  在PCM-DSD_Converter源碼中,作者先把音源split兩個聲道,再把這兩個聲道採樣成目標SampleRate,再把這兩個聲道各為做Delta-Sigma輸出為0和1的資料,最後合併兩聲道的資料輸出DSD檔案。 優化 處理各聲道firfilter都跑一次FFT轉換 作者為了加速轉換速度還使用OpenMP和FFTW,雖然使用了OpenMP進行平行化(各聲道)處理,但是每次都要重新初始化FFTW(firfilter)相關資料,要實時轉換的話就不能這樣做了太費時了。  檔案當作緩衝區 Split各聲道各一個檔案,Delta-Sigma輸出各聲道一個檔案,轉換工具的話倒是可以如此處理,如果要考慮實時轉換,在記憶體上操作會比較有效率一點。 實作 Split各聲道為double格式 因為XAMP早已透過3rd lib(BASS)已經檔案來源轉換為float格式。 OpenMP 或是 FFTW OpenMP有平台相依的問題,改用XAMP內建的thread pool處理,FFTW也早已在XAMP使用了。 輸出DOP或是Native DSD格式 因為只是個PCM轉換為DSD的工具,我們必須要還要將資料轉換為DOP或是Native DSD格式。 這是這個轉換過程比較花時間的過程。目前XAMP已經支援DOP格式撥放,以下是DOP轉換過程: PCM(float) -> INT (24/32)格式 -> 音效卡 從DSD檔案到PCM(float)這段過程,均由3rd lib(BASS)做到,但是要從Delta-Sigma輸出到PCM(float)過程倒是頭一次。 Delta-Sigma(1bit) -> 合併8bit為1...

使用spdlog的時候win32平台如何加速編譯?

有在使用C++寫Logger的開發者一定對 spdlog 不陌生,header only而且寫入logger速度也不慢,但是...在win32平台會引入windows.h這個肥大的header檔案,對於大型專案相當不友好,在加上spdlog中使用了不少template,勢必使用的時候就要include進來。 好家在的是...我們在操作上使用的spdlog::logger是個class,所以我們可以在header做forward declaration,可是spdlog::logger每個寫入Log的函數都是template,要使用的時候還是要直接include,所以一個spdlog::logger包裝類就油然而生。 // forward declaration namespace spdlog { class logger; namespace sinks { class sink; } } #define DECLARE_LOG_ARG_API(Name, Level) \ template \ void Log##Name(Args &&args) {\ Log(Level, nullptr, 0, nullptr, "{}", std::forward (args));\ }\ template \ void Log##Name(std::string_view s, Args &&...args) {\ Log(Level, nullptr, 0, nullptr, s, std::forward (args)...);\ }\ template \ void Log##Name(const char* filename, int32_t line, const char* func, std::string_view s, Args &&...args) {\ Log(Level, filename, line, func, s, std::forward (args)...);\ } class Logger { public: explicit Logger(const st...

該如何包裝"Handle"類型的資源?

在C++的世界裡,我認為RAII是普世的認知,所以會將資源包裝起來。 #include struct HandleTraits final { static HANDLE invalid() noexcept; static void close(HANDLE value) noexcept; }; using WinHandle = UniqueHandle ; 這方法看似乎很完美,但是include一個巨大的windows.h,這會導致整個專案編譯時間過長。 目前我已知的兩種解決方式: 將你使用到Windows.h的類型複製到你的實作檔(.cpp)。 使用LoadLibrary載入你要的函數(這樣的方式也只有函數的部分而已)。 使用void*替代任何HANDLE類型,然後在使用的時候強制轉型。

坑阿~ HttpWebRequest

              // 這是早期C#請求HttpRequest的寫法 HttpWebRequest request = (HttpWebRequest)WebRequest.Create(uri); // 現在C#開發者都轉為HttpClient了 static readonly HttpClient client = new HttpClient(); HttpClient有Task base語法糖等等,讓開發者比較相當方便使用非同步請求,但是... 硬要說缺點就是整個函數都需要改為Async宣告,有些老舊的程式無法支援Async宣告,除了語法糖之外,非同步請求關係底層OS的I/O模型,非同步請求可以大大降低CPU資源,那能不能混用呢(呼叫一個非同步API使用同步等待)?其實是可以的...改用古老的BeginXXX, EndXXX var result = request.BeginGetResponse((a) => { }, null); using (Stream reqStream = request.EndGetRequestStream(result)) {} 聽起來是不是很讚,老程式有回春的一天。 但是有一個天大的巨坑,HttpWebRequest timeout屬性就不能用了。 request.Timeout = timeout; 至於解法就給有緣人看看吧~ 解法

[心血來潮的介紹] 在我心中滿分自動筆 STAEDTLER 925 25

圖片
就以他的外觀來說,他的確沒有他的兄弟925 85這麼有菱有角,但是一個自動筆所有的部分都不馬虎。 初眼一看就是滿滿工業風格,但又會被他那筆身銀色透露出他的輕盈所吸引,在看他那個前端的咬花,似乎又有點玫瑰漂亮但又帶刺感覺。 喔~~ 不,這個凸起但不刺手的感覺,原來只是他批在馬甲美麗裝飾。 如果當作打底稿的用筆,就是要用這種握姿試用他。 刷刷兩聲之後你只會感受筆的前端與紙磨擦感,什麼低重心功能都是商人的噱頭,底稿用筆需要的平衡感如同鉛筆一般。 與其他的妖豔賤貨不同,夾筆片的長度剛好落在你的食指之間,你在揮灑的時候長度太長恨不得拆掉他。

XAMP開發秘話01 音效輸出篇

圖片
有用過Foobar 2000的人因該多多少少聽過或用過WASAPI 輸出,這讓許多人認識到Windows也可以跟發燒搭的上邊。Windows 經歷多個過版本的演進之後,從早期waveOut和DirectSound 至WDM driver 的 Kernel Stream並到Windows Vista之後的WASAPI,低延遲與多種場景使用是Windows 改善的重點。 低延遲(等於原音重現):也許很多人認為低延遲對於撥放沒有幫助。低延遲其實考驗OS從用戶模式到 Mixer到音效卡時間,這之間如果資料經歷某些DSP處理,可能就沒辦法這麼快到達音效卡。 多種場景使用:低延遲代表的是對電量與系統負載越高,這對需要長時間使用時間的設備卻是一種負擔。 發燒友都知道Foobar 2000有一種特殊的獨佔WASAPI 輸出模式,可以讓系統所有音效都失效,如果有不知道的人還以為系統出現問題了~ Push 與 Event 傻傻分不清楚? 在Foobar 2000中獨佔WASAPI 輸出模式就是Event模式,另外一個Push 就是所謂共享模式。 接下來我們來細細描述一些細節。 Event模式如同它的名字一樣它需要等待某個系統發生事件之後,才能夠將聲音資料拷貝至系統提供的緩衝區,當然你不能夠讓你的撥放軟體去等待這個事件,需要讓某個服務該事件執行序(Thread)去等待,否則等待的期間你的撥放軟體無法接受用戶輸入的訊息。這個也是絕大部分的撥放器的音效輸出所做的事情。 這個等待事件執行序如同系統其他執行序相同,都需要經過排入系統調度器中,低延遲意味著需要更高的優先權,優先進出系統調度器中來保證低延遲。 大部的撥放器WASAPI輸出:一個執行序 + 調高系統對此執行序優先級(MCSS)。 窺探早期的foo_asio原始碼即可得知道,Foobar 2000為了改善舊版Windows對於系統負載變高之後導致提高執行序優先級失效的問題,採取子行程(Child Process)的方式並利用IPC進行通訊,這無疑的導致系統呼叫變多導致系統負擔變大。 XAMP 採用的Windows提供Microsoft Media Foundation 多序池,改善了傳統的做法中一個執行序需與系統搶資源的窘境。 除了輸出優化之外,還需要...