Using Ardour 8.1.0 on Manjaro Linux with latest 6.6.5 Kernel.
CPU is a 8 Core (16 threads) Ryzen 9 7940 HS with Radeon 780M Graphics and 16GB Ram.
If I don’t run Ardour my battery shows about 20 hours remaining.
If I run Ardour in standard Configuration with no plugins, instruments etc. the battery drops to 5 hours remaining.
Htop showing 0% CPU usage. CPU governor in performance, or powersave mode (doesn’t make much difference).
I found out that this is not an Ardour issue.
The issue occurs if the Audio System is initialized. It even occurs if I start pavucontrol, or Audacity. I tried different Kernels, no change. Maybe an pulseaudio issue? Should I try pipewire?
Any layer of software that configures audio hardware to wake up the CPU very frequently (based on the buffer size) will drain your battery.
This is why most consumer/desktop apps tend to use extremely large buffers (sometimes on the order of a second of audio.
Pro-audio/music creation apps, because of the need for low-latency during some parts of the process, configure the audio hardware to wake the CPU every few 10’s or hundreds of milliseconds. This will cause battery drain, even on modern Apple platforms.
The layers of other software won’t affect this very much.
For what you consider “normal”, CPUs hardly do anything and just sleep these days.
You can check with tools such as i7z or s-tui or powertop.
Here under “normal” operation (web browser, music player, mail client, few text editors), the CPU uses a very low clocks-speed, and 75% of the time sleeps without clock (C1 state), and 5% of the time cores are completely powered off (C6 state). There’s nothing to compute.
Now while Ardour’s engine is running. Ardour needs the CPU every few ms (buffersize/samplerate, here 512/48kHz = 10ms) to process audio. There is not enough time for the CPU to be powered off between those process cycles.
Also the CPU clock-freq is much higher (since Ardour does in fact need the CPU to process audio).
s-tui shows power-consumption going up from 4 Watts to around 30Watts.
It is worse when compiling Ardour (or anything really). The CPU will be in constant use. Battery time here reduces from 20 hours to 2 hours when I compile Ardour or the Linux kernel or anything really. I would expect running games to have a similar impact, but I have no first hand experience and many use the GPU more than the CPU these days.
–
PS. I did not manage to get screenshots synced so that all 4 percentages add up to 400%.
And I found by checking with my old Acer Laptop with Intel 4 Core Celeron CPU and 4GB Ram that the issue nearly does not exist when starting/running Ardour. There is a remaining battery of 11 Hours shown before and 10 Hours after starting Ardour.
So that seems to be an AMD APU Kernel/Driver issue, or Audio Codec Issue.
Asus Laptop/Hardware is quiet new (May 2023), so maybe it is not yet fully supported in Linux.
Audio:
Device-1: AMD Rembrandt Radeon High Definition Audio driver: snd_hda_intel
Device-2: AMD ACP/ACP3X/ACP6x Audio Coprocessor driver: snd_pci_ps
Device-3: AMD Family 17h/19h HD Audio driver: snd_hda_intel
Device-4: Alesis io|2 driver: snd-usb-audio type: USB
API: ALSA v: k6.6.5-2-MANJARO status: kernel-api
Server-1: PipeWire v: 1.0.0 status: active
This has absolutely nothing to do with your hardware.
The high CPU usage and battery drain of pavucontrol went away if I untick “show volume meters” in pavucontrol Configuration.
Same issue there. The volume meter reads audio periodically (likely at least every 40ms ~ 25fps, usually ever more frequently) which prevents the CPU from powering off.
If I deactivate input device in Audio/Midi Setup the battery drain is far less heavy.
So why is the input device active if I don’t record anything?
It seems to make more sense to me that the input device gets only activated if a track is set to record. Isn’t there a setting in Ardour to change this?
The typical case is input device and output device are the same physical device, so effectively no additional CPU work keeping the input active.
Do you have a separate input and output device? In that case there is an additional resampling program (or thread in Ardour) which must run at the same timescale as the main audio driver, but asynchronously, which can have the effect of making the CPU perform work twice as frequently.
Because you could do live signal processing, or start recording at any time.
As opposed to casual desktop audio where it is entirely feasible to suspend a device, the same is not true for pro-audio. Alignment will change and the only way to keep latency constant is to keep the devices running. There may also be audible clicks when enabling the device.
This is why historically there were two sound-servers on Linux: pulseaudio (consumer audio, low power usage) and JACK (pro audio, constant load). The same is true on Windows with ASIO (and to some extent also macOS)
Also keep in mind power is cheap compared to audio production cost.
I checked the power consumption on Power Supply:
If I start Ardour, or Qjackctl the power consumption raises up from 0 to 12.5 W.
But if I start Audacity there is no additional power raise until I start recording.
And that is the behaviour I would have expected. (So what does Audacity different?)
So as a workaround I could deacticate the input in Ardour until I start recording, or working with my Laptop on power supply.
