Audio buzzing on 4.14.9-1

It sounds more like when the chip is powered the buzzing stops.

This is a fairly common thing with cheaper hardware. For example, many cheap tablets have the exact same thing - a buzzing sound from the speaker(s) unless power is applied to the audio chip, normally due to internal interference.

I've had the same thing with unshielded desktop Harmon Kardon speakers (production year ~1998 or so) which buzzed when there was any electrical interference nearby (e.g. a wifi signal). That's not fixable in software.

You should be able to disable power saving on the chip and keep it active to work around the issue (e.g. check /etc/default/tlp and disable all audio-related power saving); it's not a real solution though.

That's exactly what I said above :slight_smile: .

Only the 4.9 kernel, power saving was always disabled. On 4.14, for some reason my desktop PC thinks it's a laptop running on a battery (It probably picked up a disease after plugging in my wife's iPhone). Due to the default TLP options, power saving is always enabled for battery power.

1 Like

34

Not really the solution you were hoping for but this cheap piece of hardware will get rid of the buzzing. It is a ground loop isolation device.

I'm planning a new Ryzen build next year. At the same time, or even before, I'll probably update my speakers. But, if I have the same problem I'll certainly look out for one of these. Thanks.

Just an update. I've confirmed that TLP is at fault here. It's detecting the batteries of my two peripheral devices by scanning the contents of /sys/class/power_supply. Since it detects devices powered by battery and no devices powered by mains, it is incorrectly thinking the system is battery powered. The detection loop is here if anybody wants to look at this.

On kernel 4.9, my /sys/class/power_supply directory is empty, but on 4.14 it is populated with my Logitech wireless mouse and keyboard. I'm guessing many other TLP users, with wireless peripherals, may also be affected by this bug. Though, in most cases, many people may not even realize their desktop PC's are running in battery mode.

The owner of TLP is less than helpful. He told me to file a bug report against the kernel. I do not believe this is a kernel bug.

3 Likes

Just to clarify, on my desktop that location has only a link named hidpp_battery_0 and points to ../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.2/0003:046D:C52B.0003/0003:046D:1025.0005/power_supply/hidpp_battery_0

The directory contains links to each of your devices. You can read up more about it here. If your desktop PC contains a power supply which can report its status, the kernel may have a link to it here. Otherwise, most links will be to battery powered devices including the main battery in laptops/notepads.

I don't have such a power supply to confirm this myself, though I do believe some of the higher end PSUs (Corsair RM750X etc) do have this feature.

Just out of curiosity, do you have any battery powered devices?

Thanks for the info, yes I have a logitech wireless mouse and its vitals seem to be listed in the linked folder as individual files. There is also a couple more links and folders etc...

You might want to check the output of tlp-stat to see which mode it's running in. In all honesty though, battery mode will only affect things like a HDD spin up time.

I appear to be on AC.
[lee@Z77M ~]$ sudo tlp-stat
[sudo] password for lee:
--- TLP 1.0 --------------------------------------------

+++ Configured Settings: /etc/default/tlp
TLP_ENABLE=1
TLP_DEFAULT_MODE=AC
TLP_PERSISTENT_DEFAULT=0
DISK_IDLE_SECS_ON_AC=0
DISK_IDLE_SECS_ON_BAT=2
MAX_LOST_WORK_SECS_ON_AC=15
MAX_LOST_WORK_SECS_ON_BAT=60
CPU_HWP_ON_AC=balance_performance
CPU_HWP_ON_BAT=balance_power
SCHED_POWERSAVE_ON_AC=0
SCHED_POWERSAVE_ON_BAT=1
NMI_WATCHDOG=0
ENERGY_PERF_POLICY_ON_AC=performance
ENERGY_PERF_POLICY_ON_BAT=powersave
DISK_DEVICES="sda sdb"
DISK_APM_LEVEL_ON_AC="254 254"
DISK_APM_LEVEL_ON_BAT="128 128"
SATA_LINKPWR_ON_AC=max_performance
SATA_LINKPWR_ON_BAT=min_power
AHCI_RUNTIME_PM_TIMEOUT=15
PCIE_ASPM_ON_AC=performance
PCIE_ASPM_ON_BAT=powersave
RADEON_POWER_PROFILE_ON_AC=high
RADEON_POWER_PROFILE_ON_BAT=low
RADEON_DPM_STATE_ON_AC=performance
RADEON_DPM_STATE_ON_BAT=battery
RADEON_DPM_PERF_LEVEL_ON_AC=auto
RADEON_DPM_PERF_LEVEL_ON_BAT=auto
WIFI_PWR_ON_AC=off
WIFI_PWR_ON_BAT=on
WOL_DISABLE=Y
SOUND_POWER_SAVE_ON_AC=0
SOUND_POWER_SAVE_ON_BAT=1
SOUND_POWER_SAVE_CONTROLLER=Y
BAY_POWEROFF_ON_AC=0
BAY_POWEROFF_ON_BAT=0
BAY_DEVICE="sr0"
RUNTIME_PM_ON_AC=on
RUNTIME_PM_ON_BAT=auto
USB_AUTOSUSPEND=1
USB_BLACKLIST_BTUSB=0
USB_BLACKLIST_PHONE=0
USB_BLACKLIST_WWAN=1
RESTORE_DEVICE_STATE_ON_STARTUP=0

Wow, you can get a ton of information from that command.

You've only listed your setting above. Mine contains these lines:

+++ TLP Status
State          = enabled
Last run       = 07:57:40 PM,     12 sec(s) ago
Mode           = AC
Power source   = battery

It still thinks it's being powered by battery, but I forced it use AC.

TLP_DEFAULT_MODE=AC
TLP_PERSISTENT_DEFAULT=1

You are right. :laughing:

+++ TLP Status
State          = enabled
Last run       = 06:52:20 AM,     11 sec(s) ago
Mode           = battery
Power source   = battery

I will try that setting and see if it changes anything.

Yep, you are also running in battery mode. Edit /etc/default/tlp then run tlp start to implement the changes. (Just to save others from searching how).

1 Like

This is a great find and explains all sorts of "random" (odd and/or non-reproducible) issues some desktop users have had relating to power management.

I'm not sure this is a kernel issue as the battery-powered devices are simply reporting their battery stats - this will happen for ADP-connected bluetooth devices too, and that's a feature, not a bug.

I'd consider this a TLP issue - TLP should be determining the device type before acting on the information. However, I'm neither the TLP developer nor a kernel developer. :slight_smile:

As I may have mentioned earlier, I'm not content with just hiding a problem, I want to know what is causing it.

To anybody else experiencing this problem, I have filed a bug report with TLP. It would be a great help to get this fixed if you also mention, on that bug report, that you have the same issue.

1 Like

I feel like I should point out that I too have the same situation as you but my speakers never buzzed or did anything strange.

They did go into power saving mode as indicated by an led so I would then need to tap the volume key to "wake them up".

Issue is fixed in 1.1 beta, in the AUR.

1 Like

I'll have to have alook through the code and see if I can cherry-pick this patch for the Manjaro package. There may have been other changes which this relies on, and if so I don't want to pull a beta version into the repos just yet... although, if it works well and fixes these issues... :thinking:

@jonathon. Here you go ...

Forum kindly sponsored by