Re: [LAU] Kxstudio RT kernel vs low latency

From: Russell Hanaghan <hanaghan.osaudio@email-addr-hidden>
Date: Tue Jul 29 2014 - 02:29:54 EEST

~ Russell

> On Jul 28, 2014, at 3:22 PM, James Stone <jamesmstone@email-addr-hidden> wrote:
>
>> On Mon, Jul 28, 2014 at 1:00 PM, Joakim Hernberg <jbh@email-addr-hidden> 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.
>

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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Tue Jul 29 04:15:02 2014

This archive was generated by hypermail 2.1.8 : Tue Jul 29 2014 - 04:15:02 EEST