29 Jul
2014
29 Jul
'14
1:30 a.m.
~ Russell
On Jul 28, 2014, at 3:22 PM, James Stone
<jamesmstone(a)gmail.com> wrote:
Great follow on discussion from you guys!
I have many hiding spots to probe as it were. I do want to ask about older bios laptops
tho. Running intel dual core 1.6ghz... So the application of these (ACPI? APM?) are handed
off to OS software layer? Kernel module or whatever? If so (pls correct where I'm off)
how to use equivalent control of settings from CL or tools? Given the sig change of stable
state that Jame's refers to, it would be helpful to document this stuff somewhere
under the "realtime Linux audio tweaks". The 32/2 with stability over USB2 would
be a big deal in my case. I've not been able to come within screaming distance of that
result.
2 of those referred to were AMD related? What are the intel equivalent power management
services?
If all of this stuff is elsewhere in archives related and I'm missing it from sheer
ignorance, would somebody pls point me there?
I just dug the VAIO out of the gig rig so I can look at the FW TI chip and it's
operating limitations.
To elaborate on the end game (I hope) for this laptop... I have many occasions where a
flexible, compact, simple, yet functionally powerful recording rig is useful. {I'm
talking only for small stuff... < 12 live channels.}
SKB 6RU housing Filtered pwr. dist., Echo AudioFire12, laptop tray. Laptop rolls out, hit
the power button and it boots up Linux (with all the above issues sorted & tuned)...
Automagically opens each app needed (gkrellm, Ardour / Mixbus, FFADO mixer, Jack at
reasonable speed, session manager, etc. Simplest way into most live sources is via the
channel insert. Up to 12 insert cables / pairs with interface set to hardware monitoring.
You get the general idea! Dehydrated Live Linux Audio... Just add water! :)
I would hope to be able to run 6 - 8 channels of recording comfortably and 12 when
necessary with appropriate performance adjustments to not overheat the laptop.
There you have it. Sorry for burble.
Regards,
R
On Mon, Jul 28, 2014 at 1:00 PM, Joakim Hernberg
<jbh(a)alchemy.lu> wrote:
I think this is due to running cyclictest as root, as it then
opens /dev/cpu_dma_latency and writes 0 into it. This has the
effect of disabling cpu powersaving. The cpu will no longer use P or C
states and runs full out. The result is that it finishes processing
the audio threads faster, thus lowering the DSP load shown in qjackctl
(which is a measure of how much of the available time until the
deadline did the audio processing take). The documentation is in
Documentation/power/pm_qos_interface.txt Note that it's not enough
to just write a value to it, the file needs to be kept open too, once
it's closed the cpu goes back to it's normal powersaving.
Thanks for this hint!
I played around with adding
processor.max_cstate=0 idle=halt to the boot parameters, which had
the same effect as running cyclictest with /dev/cpu_dma_latency = 0..
I then removed this and had a poke around in the bios, and found that
the main culprits for the xruns were C6 mode, and "AMD Power Now".
Disabling these, and I now have an xrun-free experience with
frames/period = 32/2 with pulseaudio/jack on my Scarlett 2i4, which is
pretty amazing for a USB device IMO!
There was also CPD mode and CState Pmin, which I disabled initially,
but these don't seem to have any impact on xruns on my system. Cstate
pmin seems to affect the reported DSP load - but otherwise doesn't
affect xruns - so I think it's safe to keep on (and maybe is saving
some power??). CPD mode doesn't seem to have any impact at all.