You are not logged in.
Pages: 1
Topic closed
I've noticed that when playing games, PulseAudio uses a less than insignificant amount of CPU time and this doesn't seem to have any real valid reason. It's 0% when idle (as expected) but if a game is playing audio, it can be between 2 and 50%, depending on the game. Running Factorio for example causes Pulse to use 15-20% CPU time which is almost as much as the game itself.
The interesting thing here is that the resampling codec doesn't seem to play much of a part in the resource usage here. I normally use soxr-mq which should be very low, but I've also tried various speex-float options too. Even with options like "avoid-resampling" set to yes with only a single sound source playing still results in a less-than-insignificant amount of CPU time being used by Pulse. This also happens whether I set a default-sample-rate and format or not. The only change I've found which reduced the CPU usage at all was adding tsched=0 which lowered the CPU usage in the example Factorio from 20% to 16%. The codec *should* be moot though given that resampling is turned off or shouldn't be getting used here.
The obvious fix would be to just not use Pulse and use pure ALSA which works fine and doesn't incur any CPU hit at all (and sound is just fine) - I'm using HDMI audio so I don't need any of the fancy features that Pulse provides. The only concern there is that in future some applications may become Pulse only (e.g. as Firefox already has).
Pulse isn't throwing any critical errors or mentioning underruns at all in the systemd log.
So, does anyone know what may be causing this, if it isn't the resampler codec? (especially given that it shouldn't even be resampling at all in this instance).
== Versions ==========
Kernel 4.20.0-g9ffc59d57228
pulseaudio-git v12.0.252.g2eb8ec93a (happens with the normal package too)
== Hardware =========
Intel i5-8259U
Intel Iris Plus 655 (audio is output over HDMI to a monitor)
Offline
Output of
pulseaudio --dump-conf
pacmd list-sinks
pacmd list-sink-inputs
during this situation.
FWIW ALSA "not" incurring any CPU hit, doesn't necessarily have to be true as it is potentially offloaded to a kernel process which isn't showing up in normal user space cpu reporting tools.
Offline
"top" does show kernel threads, e.g. rcu_par_gp, kworker/0:0H-kblockd, mm_percpu_wq, etc so I would expect something to show up in there if ALSA was eating CPU time as a kernel thread, but that's just a guess.
pulseaudio --dump-conf
### Read from configuration file: /etc/pulse/daemon.conf ###
daemonize = no
fail = yes
high-priority = yes
nice-level = -11
realtime-scheduling = yes
realtime-priority = 5
allow-module-loading = yes
allow-exit = yes
use-pid-file = yes
system-instance = no
local-server-type = user
cpu-limit = no
enable-shm = yes
flat-volumes = yes
lock-memory = no
exit-idle-time = 0
scache-idle-time = 20
dl-search-path = /usr/lib/pulse-12.0/modules
default-script-file = /etc/pulse/default.pa
load-default-script-file = yes
log-target =
log-level = debug
resample-method = soxr-mq
avoid-resampling = yes
enable-remixing = no
remixing-use-all-sink-channels = no
enable-lfe-remixing = no
lfe-crossover-freq = 0
default-sample-format = s16le
default-sample-rate = 44100
alternate-sample-rate = 48000
default-sample-channels = 2
default-channel-map = front-left,front-right
default-fragments = 4
default-fragment-size-msec = 25
enable-deferred-volume = yes
deferred-volume-safety-margin-usec = 8000
deferred-volume-extra-delay-usec = 0
shm-size-bytes = 0
log-meta = no
log-time = no
log-backtrace = 0
rlimit-fsize = -1
rlimit-data = -1
rlimit-stack = -1
rlimit-core = -1
rlimit-rss = -1
rlimit-as = -1
rlimit-nproc = -1
rlimit-nofile = 256
rlimit-memlock = -1
rlimit-locks = -1
rlimit-sigpending = -1
rlimit-msgqueue = -1
rlimit-nice = 31
rlimit-rtprio = 9
rlimit-rttime = 200000
pacmd list-sinks
1 sink(s) available.
* index: 0
name: <alsa_output.hw_0_7>
driver: <module-alsa-sink.c>
flags: HARDWARE DECIBEL_VOLUME LATENCY FLAT_VOLUME
state: SUSPENDED
suspend cause: IDLE
priority: 9030
volume: front-left: 65536 / 100% / 0.00 dB, front-right: 65536 / 100% / 0.00 dB
balance 0.00
base volume: 65536 / 100% / 0.00 dB
volume steps: 65537
muted: no
current latency: 0.00 ms
max request: 0 KiB
max rewind: 0 KiB
monitor source: 0
sample spec: s16le 2ch 44100Hz
channel map: front-left,front-right
Stereo
used by: 0
linked by: 0
fixed latency: 371.52 ms
module: 4
properties:
alsa.resolution_bits = "16"
device.api = "alsa"
device.class = "sound"
alsa.class = "generic"
alsa.subclass = "generic-mix"
alsa.name = "HDMI 1"
alsa.id = "HDMI 1"
alsa.subdevice = "0"
alsa.subdevice_name = "subdevice #0"
alsa.device = "7"
alsa.card = "0"
alsa.card_name = "HDA Intel PCH"
alsa.long_card_name = "HDA Intel PCH at 0xd0b20000 irq 143"
alsa.driver_name = "snd_hda_intel"
device.bus_path = "pci-0000:00:1f.3"
sysfs.path = "/devices/pci0000:00/0000:00:1f.3/sound/card0"
device.bus = "pci"
device.vendor.id = "8086"
device.vendor.name = "Intel Corporation"
device.product.id = "9dc8"
device.form_factor = "internal"
device.string = "hw:0,7"
device.buffering.buffer_size = "65536"
device.buffering.fragment_size = "8192"
device.access_mode = "mmap"
device.description = "Built-in Audio"
device.icon_name = "audio-card-pci"
pacmd list-sink-inputs
0 sink input(s) available.
Offline
During active playback of a problematic source, ideally. However something that's immediately noticable is that this is a manually added ALSA sink as opposed to a proper autodetected card. Using a manual alsa-sink usually throws a lot of the intelligence and benefits of pulseaudio out of the window for a statically configured construct, which might not have access to all of the properties that usually are associated with a proper ALSA sink. What happens if you remove/comment that manual definition and use a module-udev-detect detected card instead?
Offline
It was an auto-added sink originally. It's been manually specified now as part of earlier fault-finding and to narrow down any potential other interfering issues (or modules). Behaviour is the same regardless of whether I'm using the card via module-udev-detect or not.
Offline
Either way can you repost those during the problematic situation?
Offline
Ok, I've reverted back to UDEV auto-detect for the devices. Pulseaudio CPU usage is 17-27%.
pacmd list-sinks
1 sink(s) available.
* index: 0
name: <alsa_output.pci-0000_00_1f.3.hdmi-stereo-extra1>
driver: <module-alsa-card.c>
flags: HARDWARE DECIBEL_VOLUME LATENCY FLAT_VOLUME DYNAMIC_LATENCY
state: RUNNING
suspend cause: (none)
priority: 9030
volume: front-left: 65536 / 100% / 0.00 dB, front-right: 65536 / 100% / 0.00 dB
balance 0.00
base volume: 65536 / 100% / 0.00 dB
volume steps: 65537
muted: no
current latency: 5.75 ms
max request: 0 KiB
max rewind: 0 KiB
monitor source: 0
sample spec: s16le 2ch 44100Hz
channel map: front-left,front-right
Stereo
used by: 1
linked by: 1
configured latency: 4.99 ms; range is 0.50 .. 2000.00 ms
card: 0 <alsa_card.pci-0000_00_1f.3>
module: 5
properties:
alsa.resolution_bits = "16"
device.api = "alsa"
device.class = "sound"
alsa.class = "generic"
alsa.subclass = "generic-mix"
alsa.name = "HDMI 1"
alsa.id = "HDMI 1"
alsa.subdevice = "0"
alsa.subdevice_name = "subdevice #0"
alsa.device = "7"
alsa.card = "0"
alsa.card_name = "HDA Intel PCH"
alsa.long_card_name = "HDA Intel PCH at 0xd0b20000 irq 143"
alsa.driver_name = "snd_hda_intel"
device.bus_path = "pci-0000:00:1f.3"
sysfs.path = "/devices/pci0000:00/0000:00:1f.3/sound/card0"
device.bus = "pci"
device.vendor.id = "8086"
device.vendor.name = "Intel Corporation"
device.product.id = "9dc8"
device.form_factor = "internal"
device.string = "hdmi:0,1"
device.buffering.buffer_size = "352800"
device.buffering.fragment_size = "176400"
device.access_mode = "mmap+timer"
device.profile.name = "hdmi-stereo-extra1"
device.profile.description = "Digital Stereo (HDMI 2)"
device.description = "Built-in Audio Digital Stereo (HDMI 2)"
alsa.mixer_name = "Realtek ALC233"
alsa.components = "HDA:10ec0235,80862074,00100002 HDA:8086280b,80860101,00100000"
module-udev-detect.discovered = "1"
device.icon_name = "audio-card-pci"
ports:
hdmi-output-1: HDMI / DisplayPort 2 (priority 5800, latency offset 0 usec, available: yes)
properties:
device.icon_name = "video-display"
device.product.name = "HC09FH"
active port: <hdmi-output-1>
pacmd list-sink-inputs
1 sink input(s) available.
index: 0
driver: <protocol-native.c>
flags:
state: RUNNING
sink: 0 <alsa_output.pci-0000_00_1f.3.hdmi-stereo-extra1>
volume: front-left: 65536 / 100% / 0.00 dB, front-right: 65536 / 100% / 0.00 dB
balance 0.00
muted: no
current latency: 17.46 ms
requested latency: 4.99 ms
sample spec: s16le 2ch 44100Hz
channel map: front-left,front-right
Stereo
resample method: (null)
module: 12
client: 3 <ALSA plug-in [factorio]>
properties:
media.name = "ALSA Playback"
application.name = "ALSA plug-in [factorio]"
native-protocol.peer = "UNIX socket client"
native-protocol.version = "33"
application.process.id = "753"
application.process.user = "enverex"
application.process.host = "tiger"
application.process.binary = "factorio"
application.language = "C"
window.x11.display = ":0"
application.process.machine_id = "2aaeeb9893fe4e38af8fb1070d719356"
application.process.session_id = "1"
module-stream-restore.id = "sink-input-by-application-name:ALSA plug-in [factorio]"
Offline
So this isn't using native pulseaudio but the alsa-plugin bridge. That did see quite a few regressions with alsa-plugins 1.1.7 FWIW you might want to try behaviour with a downgraded {,lib32-}alsa-{lib,plugins} to 1.1.6
Offline
Downgraded alsa-lib and alsa-plugins (the game is 64bit so no need for lib32) to their most recent 1.6 versions and restarted, same behaviour though. Pulse hovers around 20% CPU usage.
Offline
No PulseAudio daemon running, or not running as session daemon.
Thats the output of `pacmd list-sinks` for me.
Offline
Please don't necrobump topics in order to hijack them with a problem that's irrelevant to the original thread: https://wiki.archlinux.org/index.php/Co … _hijacking
If you want help open your own thread and include more information, like what you do to start the session.
Closing.
Offline
Pages: 1
Topic closed