Hi, 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. Regards, Clemens 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: >>> intel_iommu=igfx_off >> >> >> 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 > disappeared: > > 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: > index=1,0 > > 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. >> HOWEVER... >> 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 > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
