Parent comment likely refers to kernel CPU time accounted for in the generating process. If an application passes an audio sample to PulseAudio, it is charged for (at most) a memory copy and one or two syscalls, while PulseAudio is charged for the time spent in the kernel driver.

Pulseaudio burning CPU during silence is usually due to an application holding open a channel that is either really playing silence or is keeping the Pulseaudio machinery awake. You could blame the apps, but IMHO that is definitely a Pulseaudio problem