2022年5月6日 星期五

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,第二組功放不見得比第一組差到哪去

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

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


2022年1月1日 星期六

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)

Replace J-S J-7508 Speaker amplifier again

忘記哪來的喇叭,好像是我哥給的,時間已經不可考 最初給我的時候應該是圖片中的擴大器異常,已經忘記是不過電還是音量控制有問題啥的 (剛才查這顆喇叭發現可能是通病,有一些文章有提到長時間使用後,音量的可變電阻可能會不正常) 我已經忘了當初檢修的過程,或是有沒有修了 最後我放棄那個擴大...