Audio buzzing on 4.14.9-1

What about in /etc/default/tlp ?

# Enable audio power saving for Intel HDA, AC97 devices (timeout in secs).
# A value of 0 disables, >=1 enables power saving.
SOUND_POWER_SAVE_ON_AC=0
SOUND_POWER_SAVE_ON_BAT=1

They already have these settings. Besides, this is a desktop not a laptop, so battery specific settings should have no influence.

You can use systemd to pass a cmd during startup to set it automatically to 0. You can do some similar as I did for idling my harddrive.

I understand that. But, I'd rather find the cause of the problem rather than just hide it.

I can't confirm it yet, but I think this a bug within TLP. I didn't notice it earlier but on the 4.14 kernel, TLP is starting up in battery mode. TLP also ignores any kernel/.conf parameters (perhaps this should be added to the wiki alongside the note for pm-utils). I have a desktop PC, there is no battery mode, however I do have a wireless keyboard and mouse which may be causing the confusion. For now, I've set SOUND_POWER_SAVE_ON_BAT=0 in the tlp config and filed a bug report.

So with this the buzz is gone? Also on a Desktop System?

@jonathon: any regressions added with our new defaults?

TLP still starts up in battery mode, but with that setting the buzz is gone.

I have a feeling a driver change between 4.9 and 4.14, and they way TLP queries the drivers, may be at fault here. The TLP defaults are exactly the same for both kernels.

Nope. The three changes do not enable more power saving, quite the opposite.

@twifty: since you're the only one reported the issue ever, I doubt is is wide spread. The defaults for TLP are:

# Enable audio power saving for Intel HDA, AC97 devices (timeout in secs).
# A value of 0 disables, >=1 enables power saving.
SOUND_POWER_SAVE_ON_AC=0
SOUND_POWER_SAVE_ON_BAT=1 

However, I still don't get why now the BAT option is used on desktops ...

This sounds like a hardware issue.

I also doubt there are many people using my combination of hardware and kernel. Like I said, my keyboard and mouse are wireless battery powered. These are the only batteries associated with and reported by my system. They use a Logitech unifying receiver with which I had driver issues on Ubuntu last year. Under Manjaro, on the 4.9 kernel, TLP would always run in AC mode, since my upgrade to 4.14 however, it has started using the battery profile. This must be a communication problem between the kernel/driver and TLP. Nothing on my system has changed other than the kernel and it's associated files.

When my sound card has no power, electrical interference causes a the speakers to buzz. It's probably my cheap set of speakers and amp with poorly insulated wires. I have known about the buzz during POST for a long time. As soon as the OS, any OS, loads its drivers and supplies power to the card the buzzing stops.

While yes, it's a hardware issue, a correct driver fixes the issue.

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...

Forum kindly sponsored by