Replace J-S J-7508 Speaker amplifier again

忘記哪來的喇叭，好像是我哥給的，時間已經不可考

最初給我的時候應該是圖片中的擴大器異常，已經忘記是不過電還是音量控制有問題啥的

（剛才查這顆喇叭發現可能是通病，有一些文章有提到長時間使用後，音量的可變電阻可能會不正常）

我已經忘了當初檢修的過程，或是有沒有修了

最後我放棄那個擴大器，直接用另外買的功放板直接推喇叭
（擴大器當初應該就丟了）

從銅柱跟可變電阻的鏽斑看得出已經有歷史的痕跡了...
J-7508配的變壓器是傳統變壓器，加上功率比較大的緣故，整顆變壓器又大又重
所以另外背了一個7815的LDO，這樣我就可以直接用交換式變壓器供電

前一段時間，忘記多久以前，功放開始有點問題，左右聲道有時後會某個聲道沒聲音或比較小聲，或兩個都沒聲音
重新轉一轉接頭、或是調一調音量會有改善

最近又開始居家上班，我開始注意到右聲道音量相較於左聲道音量小聲很多
勉強可以接受，但總是有點不自在

拉一拉扭一扭音量旋鈕後有機會改善，推測應該是音量旋鈕這顆可變電阻問題

這顆是B5K 6pin 的可變電阻，我手邊沒有適合的材料...

於是我找出蠻久以前淘寶買來玩的Class-D功放板 PAM8403

2017年的時候，買來組成一個小的放大器，供電採用現成的DC-DC buck模組

這樣就可以吃比較寬的電壓輸入

但實際測試後發現會有一個noise，推測是DC-DC buck造成的
是可以直接改5v輸入，只要用usb adapter供電

但usb adapter有時候供電品質其實也好不到哪去

所以做好的放大器就擱置了...

這一次受不了舊的放大器，所以拿這顆出來改造

當初懷疑是電源造成底噪的部份

所以這次我沿用原來的DC-DC buck，將輸出電壓調高到7.2v

在輸出端再串一個從高職時期零件盒挖出來的7805

不直接從外部給到7805主要還是考慮7805的耐壓沒那麼高，加上LDO的效率不好，壓降越大、電流越大，LDO發熱越高

氧化非常嚴重的7805，接腳打磨過了，焊電容上去還是焊半天
可能磨的不夠，也有可能烙鐵太弱，或是銲錫不對Orz

加上7805之後，實際測試看看，沒有聽到奇怪的噪音了

表現還算挺不錯的，起碼以我這個木耳來說，我聽不出啥差異XDDDD

至於功率
最初這組喇叭似乎是15W rms x2
換第一組功放板換成7W x2
換第二組PAM8403只剩下3W x2
越換越小了XDDDD

老一輩的觀念是，功放的功率要夠大才推的動單體
實際上不會真的聽到這麼大聲

但功率夠大，推對應的單體聲音才會漂亮

以前學放大器的時候，Class A表現最好，但效率最差

Class D因為是透過PWM的方式去推喇叭，當時課本教的是說這種方式最差，但沒有深入說明

現在的話，我知道PWM如果沒處理好，訊號傳遞到單體上可能就會很悲劇

但現在Class D普及的程度，現在技術已經比早年要好很多了

因為我是木耳，老實說音響發燒友的世界、那些聽起來很抽象的名詞我不是很懂

以第一組功放板來說，他的功放IC是TDA7266，Class-AB 放大IC

從Datasheet可以看得出來

這是7W x2的功放IC，但THD表現最好的低點落在0.5W~2W，3W-4W之後THD就會一路飆上去

所以老一輩說的話也是有些道理

而第二組功放板的功放IC是PAM8403，Class-D 放大IC，3W x2

從Datasheet可以看到，以4ohm、5v舉例，THD一路下降，2w算是最低點，2w之後開始往上飆
所以在正常使用情境，不特別拉高音量輸出的情況下

單單比THD，第二組功放不見得比第一組差到哪去

我自己使用上來說，表現算是相當不錯了:)

替這顆喇叭留個紀錄，順便紀錄一下擴大器的演進歷程

Linux mint crash frequently with AMD CPU/GPU

自從換了Asrock Deskmini A300 + AMD 2400G之後

很常碰到系統hang住的狀況

可能是Hang住，隔了一下子畫面綠屏，再隔一下子系統自動重啟

也可能就單純hang住，系統還活著，可以從其他機器ssh連回這台機器，登入後看dmesg或journalctl，看看是什麼原因

也可能hang住，系統就死了

當發生問題時，觀察dmesg或journalctl，常可以看到amdgpu的異常訊息，例如下面這樣的訊息

（不是固定一種類型，可能會有幾種訊息）

Oct 14 23:23:17 A300 kernel: amdgpu 0000:38:00.0: [mmhub0] retry page fault (src_id:0 ring:0 vmid:4 pasid:32769, for process Xorg pid 897 thread Xorg:cs0 pid 963)

Oct 14 23:23:17 A300 kernel: amdgpu 0000:38:00.0:   in page starting at address 0x00008001016e0000 from client 18

Oct 14 23:23:17 A300 kernel: amdgpu 0000:38:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00440051

Oct 14 23:23:17 A300 kernel: amdgpu 0000:38:00.0:          MORE_FAULTS: 0x1

Oct 14 23:23:17 A300 kernel: amdgpu 0000:38:00.0:          WALKER_ERROR: 0x0

Oct 14 23:23:17 A300 kernel: amdgpu 0000:38:00.0:          PERMISSION_FAULTS: 0x5

Oct 14 23:23:17 A300 kernel: amdgpu 0000:38:00.0:          MAPPING_ERROR: 0x0

Oct 14 23:23:17 A300 kernel: amdgpu 0000:38:00.0:          RW: 0x1

或是

Oct 12 23:33:19 A300 kernel: amdgpu 0000:38:00.0:          RW: 0x1

Oct 12 23:33:19 A300 kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, signaled seq=328615, emitted seq=328617

Oct 12 23:33:19 A300 kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Xorg pid 949 thread Xorg:cs0 pid 960

Oct 12 23:33:19 A300 kernel: amdgpu 0000:38:00.0: GPU reset begin!

Oct 12 23:33:19 A300 kernel: amdgpu 0000:38:00.0: GPU reset succeeded, trying to resume

從網路上找到的資料可以發現，發生問題的Kernel版本，從4.19一直到5.x都有發生

所以應該是跟Kernel無關

比較具體的分析，大多是說Linux調整CPU的C-state時，可能會踩到CPU的Bug或啥的

所以

有的文章建議在BIOS內修改C-State相關設定

但我在A300的BIOS內找不到相關的設定，所以這個方法我沒辦法測試

有的文章建議 Write "high" into /sys/class/drm/card0/device/power_dpm_force_level

去避免GPU進入省電模式啥的，但這個我調整了還是碰到Crash

有的文章建議在kernel cmdline參數加上idle=nomwait amdgpu.noretry=0，避免kernel頻繁重啟gpu，具體原因是啥我不清楚

這個方式最初我有調整過，但後來一段時間後又復發，因此我不太確定這個作法到底有沒有效

最近我找到這兩篇文章
https://community.amd.com/t5/graphics/solved-random-reboots-and-crashes-ryzen-and-amd-gpu-under-linux/td-p/441637
https://bugzilla.kernel.org/show_bug.cgi?id=206903#c135

文章建議在kernel cmdline加上amdgpu.ppfeaturemask=0xffffbffd
讓kernel禁用特定電源管理功能
詳細的bitmask定義在kernel.org那篇文章中有介紹

我的kernel版本，目前是5.4.0-91-generic
修改ppfeaturemask後，到目前大概接近三個星期，當機的機率有明顯改善

所以來寫一下作法跟來源，留個紀錄

修改/etc/default/grub，加上紅字的ppfeaturemask參數

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash amdgpu.ppfeaturemask=0xffffbffd"

編輯之後， sudo update-grub 更新grub conf

update-grub會重建一次所有grub的設置，把預設參數帶進去

接著重新啟動系統，進入系統後，cat /proc/cmdline觀察當下kernel的參數

確認參數已經生效，修改就完成了

最後就是放上一包乖乖，希望他可以順順利利(crossfinger)