7 May
2017
7 May
'17
3:22 a.m.
On Sun, 07 May 2017 08:35:22 +0200, David Kastrup wrote:
You not necessarily need to chose "performance", you could also chose
another fixed frequency, lower than full speed. Sometimes it makes a
difference if CPU speed doesn't vary.
On Sun, 07 May 2017 08:42:20 +0200, David Kastrup wrote:
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
writes:
Hi,
yes, it's a PCIe card mounted to a Tower's mobo.
[rocketmouse@archlinux ~]$ grep RTIRQ_NAME_LIST
/etc/conf.d/rtirq |
grep -v "#" RTIRQ_NAME_LIST="usb snd_hdsp snd_ice1"
You probably have a PCI (or express) card rather than a Cardbus one? cat
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
Perhaps setting it to performance helps to reduce xruns
I seem to remember that CPU switching speed with the Penryn is supposed
to be close enough, but I admit that if it were instantaneous it would
be indistinguishable from a power-saving halt state but full speed
otherwise. I think I had the system on performance for a while but it
did not make a noticeable difference with regard to xruns.
I'll keep it in mind. Well, there is irq/16-snd_hdsp after all once I plug
the Cardbus card
in (it's usually out in the morning since the computer doesn't wake up
successfully from suspend otherwise). And it's prioritized well enough
once I _rerun_ /etc/init.d/rtirq. Otherwise it sticks at the bottom.
Restarting or stop and start etc. ...
rtirq {[re]start|stop|reset|status|force-reload}
... doesn't work always. In my experiences it's better to reboot.
If you continue optimisation regarding real-time audio, consider to do
this at LAU, https://lists.linuxaudio.org/listinfo/linux-audio-user ,
since jack-devel might not be the right mailing list and apart from
this on LAU usually is more traffic, so much likely more people could
give you hints.
Regards,
Ralf