[pulseaudio-discuss] PulseAudio Painfully Slow
linuxhippy at gmail.com
Mon Jul 14 05:32:11 PDT 2014
Same here: https://bugs.freedesktop.org/show_bug.cgi?id=81288
The pulseaudio-daemon consumes almost half the cycles skype uses for
audio+video+network, and 3 times the cycles the X-Server needs to
display the video.
Considering the (compared to video) low data rates, I never thought
audio can actually be that expensive.
2014-07-14 11:49 GMT+02:00 Alexander E. Patrakov <patrakov at gmail.com>:
> 14.07.2014 14:04, Benny de von Ausfern пишет:
>>> Please add this to the kernel command line to work around the kernel bug:
>> I am not sure if I added the kernel command line properly. The reason is
>> that I am new to EFI bootloader and I'm not really sure how to configure
>> reFind to do that, but I tried.
>> This is the new alsa-info.sh: http://pastebin.com/m1NRTZTh
> I have looked. At least this error (that was in your old log) has
> snd_hda_intel 0000:00:1b.0: Unstable LPIB (131072 >= 8192); disabling LPIB
> delay counting
> So please keep the option.
>>> Second, you have overrides of the model that are unnecessary for your
>>> hardware. 6stack is definitely not applicable to Haswell HDMI. So, remove
>>> all snd-hda-intel module parameters.
>> That load module line was merely intended to set the HDMI as Card#1
>> rather than Card#0, so that ALSA would not pick it by default. Thanks
>> for pointing out, I will remove the 6stack from there (I don't remember
>> why I put it). I did completely remove it from my modprobe.d/alsa.conf
>> though (temporarily).
>> I tested everything again with this configuration. Nothing changed. The
>> slowdown feels and look the same.
> Thanks for the information. This confirms that it is not only about the
> known IOMMU issue.
> As for swapping the two snd-hda-intel cards, the magic module parameter is:
> i.e. it takes a comma-separated list of integers, one for each card. You can
> identify other parameters that take lists of integer or strings by looking
> in your alsa-info dumps.
>> >It is not "with nothing else going on" - there is pavucontrol, which
>> causes PulseAudio to enable the peak meter. And with that, it's
>> perfectly reasonable for PulseAudio to eat 6% of your CPU.
>> Closing pavucontrol SIGNIFICANTLY reduces the slowdown. Well well well,
>> what do you have in that peak meter of doom there? Pulseaudio still
>> slower than ALSA, but it changed from "unplayable" to "playable with
>> moderately lower fps". Still not ideal though.
> That's a breakthrough, because we now know that there are two problems (one
> related to the peak meter of doom and one unrelated), to be profiled
> separately. Profiling instructions will be sent later today, when I return
> from work.
> Alexander E. Patrakov
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
More information about the pulseaudio-discuss