Robin Gareus | 14 Dec 00:47 2010

jack frequency scaling daemon

Hi *,

Following up on the discussion with Fernando, on the issue with
CPU-frequency scaling and JACK:

On a multi-core systems the system-load may still be too low for a CPU
governor to react (and increase CPU speed) while DSP load is already at
the limit, causing x-runs.

While it's a no-brainer for old-timers to disable CPU freq scaling
before starting serious work. I think this should be handled better.

Thought, said, done: Say hello to 'jackfreqd'. A daemon based on
powernowd that reads JACK-DSP-load (and optionally also CPU utilization)
and takes control over CPU-freq scaling.

There's a bit of magic in there so that it can launched as as root
(during system startup) and later on discover & connect to a JACK
instance - started by any user on the system. Otherwise it's very
straight forward:

jackfreqd changes frequency by a sawtooth function: The system
immediately jumps to the highest frequency whenever max(DSP-load,
CPU-load) exceeds a given threshold ("high water mark"). As soon as the
load drops below the "low water mark" the CPU speed is decreased by one
step.

There are a few more details. If you're interested: just ask.
For usage-information: read the man page, or run `jackfreqd -h`

(Continue reading)

Ralf Mardorf | 14 Dec 00:59 2010
Picon

Re: jack frequency scaling daemon

On Tue, 2010-12-14 at 00:47 +0100, Robin Gareus wrote:
> Hi *,
> 
> Following up on the discussion with Fernando, on the issue with
> CPU-frequency scaling and JACK:
> 
> On a multi-core systems the system-load may still be too low for a CPU
> governor to react (and increase CPU speed) while DSP load is already at
> the limit, causing x-runs.
> 
> While it's a no-brainer for old-timers to disable CPU freq scaling
> before starting serious work. I think this should be handled better.
> 
> Thought, said, done: Say hello to 'jackfreqd'. A daemon based on
> powernowd that reads JACK-DSP-load (and optionally also CPU utilization)
> and takes control over CPU-freq scaling.
> 
> There's a bit of magic in there so that it can launched as as root
> (during system startup) and later on discover & connect to a JACK
> instance - started by any user on the system. Otherwise it's very
> straight forward:
> 
> jackfreqd changes frequency by a sawtooth function: The system
> immediately jumps to the highest frequency whenever max(DSP-load,
> CPU-load) exceeds a given threshold ("high water mark"). As soon as the
> load drops below the "low water mark" the CPU speed is decreased by one
> step.
> 
> There are a few more details. If you're interested: just ask.
> For usage-information: read the man page, or run `jackfreqd -h`
(Continue reading)

Gabriel Beddingfield | 14 Dec 01:08 2010
Picon

Re: jack frequency scaling daemon

On Mon, Dec 13, 2010 at 5:47 PM, Robin Gareus <robin <at> gareus.org> wrote:
> Thought, said, done: Say hello to 'jackfreqd'. A daemon based on
> powernowd that reads JACK-DSP-load (and optionally also CPU utilization)
> and takes control over CPU-freq scaling.

Sweet!  I'll give it a spin tonight!

-gabriel
Paul Davis | 14 Dec 03:10 2010

Re: jack frequency scaling daemon

On Mon, Dec 13, 2010 at 6:47 PM, Robin Gareus <robin <at> gareus.org> wrote:
> Hi *,
>
> Following up on the discussion with Fernando, on the issue with
> CPU-frequency scaling and JACK:

this sounds wonderful, but the curmudgeon in me suggests that
eventually this should be part of the jack server. what do you think?
starting new programs to manage an existing program that has all the
information seems almost as cumbersome as:

> While it's a no-brainer for old-timers to disable CPU freq scaling
> before starting serious work. I think this should be handled better.

great idea though!
Ralf Mardorf | 14 Dec 03:17 2010
Picon

Re: jack frequency scaling daemon

On Mon, 2010-12-13 at 21:10 -0500, Paul Davis wrote:
> this should be part of the jack server.

Yes, please add it :). As a user I welcome every facility. Ralf
Gabriel M. Beddingfield | 14 Dec 03:48 2010
Picon

Re: jack frequency scaling daemon

On Monday, December 13, 2010 08:10:26 pm Paul Davis wrote:
> > CPU-frequency scaling and JACK:
> this sounds wonderful, but the curmudgeon in me suggests
> that eventually this should be part of the jack server.
> what do you think? starting new programs to manage an
> existing program that has all the

Don't you (usually) need to be root to change the CPU 
frequency?

-gabriel
Ralf Mardorf | 14 Dec 03:51 2010
Picon

Re: jack frequency scaling daemon

On Mon, 2010-12-13 at 20:48 -0600, Gabriel M. Beddingfield wrote:
> On Monday, December 13, 2010 08:10:26 pm Paul Davis wrote:
> > > CPU-frequency scaling and JACK:
> > this sounds wonderful, but the curmudgeon in me suggests
> > that eventually this should be part of the jack server.
> > what do you think? starting new programs to manage an
> > existing program that has all the
> 
> Don't you (usually) need to be root to change the CPU 
> frequency?
> 
> -gabriel

No, this isn't needed, regarding to a security policy or by setting up
an evil flag for the permissions, as I did for my 64 Studio ;).
Ralf Mardorf | 14 Dec 04:00 2010
Picon

Re: jack frequency scaling daemon

On Mon, 2010-12-13 at 20:48 -0600, Gabriel M. Beddingfield wrote:
> Don't you (usually) need to be root to change the CPU 
> frequency?

PS:

IMHO the SUID-bit isn't evil on an audio workstation, but I don't want
to discuss this again :D.
Robin Gareus | 14 Dec 03:50 2010

Re: jack frequency scaling daemon


On Dec 14, 2010, at 3:10 AM, Paul Davis wrote:

> On Mon, Dec 13, 2010 at 6:47 PM, Robin Gareus <robin <at> gareus.org> wrote:
>> Hi *,
>> 
>> Following up on the discussion with Fernando, on the issue with
>> CPU-frequency scaling and JACK:
> 
> this sounds wonderful, but the curmudgeon in me suggests that
> eventually this should be part of the jack server. what do you think?

maybe. As far as packaging goes maybe not: 
It conflicts with cpudyn, cpufreqd and powernowd and probably others.

The [inofficial] debian package of jackfreqd is marked as 
  Enhances: jackd1| jackd1-firewire, jackd2 | jackd2-firewire
which is a reverse "Suggests" and conflicts with other CPU governor
packages. resolving these on runtime (diable other freq daemons) is much 
more tricky.

Another issue why not to enable it by default is that not all setups 
run without x-runs when using freq. scaling (e.g PCI bus power saving,
C1E, EIST,..).

but as long as the user can disable it in the jack server:  sure go ahead.

> starting new programs to manage an existing program that has all the
> information seems almost as cumbersome as:
> 
(Continue reading)

Paul Davis | 14 Dec 03:54 2010

Re: jack frequency scaling daemon

On Mon, Dec 13, 2010 at 9:50 PM, Robin Gareus <robin <at> gareus.org> wrote:

> On that note: how often is JACK DSP load updated? is that done
> every cycle or is there some averaging going on?

its computed every cycle and fed into a crude low-pass filter to smooth it out.
Robin Gareus | 14 Dec 04:09 2010

Re: jack frequency scaling daemon


On Dec 14, 2010, at 3:54 AM, Paul Davis wrote:

> On Mon, Dec 13, 2010 at 9:50 PM, Robin Gareus <robin <at> gareus.org> wrote:
> 
>> On that note: how often is JACK DSP load updated? is that done
>> every cycle or is there some averaging going on?
> 
> its computed every cycle and fed into a crude low-pass filter to smooth it out.

Thanks. that's much faster than me reading the source :)

I have a few ideas on how to improve the algorithm - trade off
power-saving, fan-noise, overheating of cheap laptops...  vs.
performance.

currently an update is triggered by periodically polling JACK DSP-load
and additional checks are done on jack-graph changes.
I'm thinking of lowering the periodic update period after each
graph-change for a few cycles in order to have jackfreqd react more 
quickly and /work-around/ the low-pass filter.

There's also ideas floating around to dynamically adjust the threshold levels,
and support different modes of scaling..

But before digging deeper into it I'd like to know about issues this in the wild.
I have jackfreqd running on two test machine so far without x-run or problem.
but that does not mean much.

If it turns out to work fine we can have a look on how to merge it into jackd, but as 
(Continue reading)

torbenh | 14 Dec 14:02 2010
Picon
Picon

Re: jack frequency scaling daemon

On Tue, Dec 14, 2010 at 04:09:34AM +0100, Robin Gareus wrote:
> 
> On Dec 14, 2010, at 3:54 AM, Paul Davis wrote:
> 
> > On Mon, Dec 13, 2010 at 9:50 PM, Robin Gareus <robin <at> gareus.org> wrote:
> > 
> >> On that note: how often is JACK DSP load updated? is that done
> >> every cycle or is there some averaging going on?
> > 
> > its computed every cycle and fed into a crude low-pass filter to smooth it out.
> 
> Thanks. that's much faster than me reading the source :)
> 
> I have a few ideas on how to improve the algorithm - trade off
> power-saving, fan-noise, overheating of cheap laptops...  vs.
> performance.
> 
> currently an update is triggered by periodically polling JACK DSP-load
> and additional checks are done on jack-graph changes.
> I'm thinking of lowering the periodic update period after each
> graph-change for a few cycles in order to have jackfreqd react more 
> quickly and /work-around/ the low-pass filter.
> 
> There's also ideas floating around to dynamically adjust the threshold levels,
> and support different modes of scaling..
> 
> But before digging deeper into it I'd like to know about issues this in the wild.
> I have jackfreqd running on two test machine so far without x-run or problem.
> but that does not mean much.
> 
(Continue reading)

Robin Gareus | 14 Dec 14:42 2010

Re: jack frequency scaling daemon

On 12/14/2010 02:02 PM, torbenh wrote:

> i am trying to move forward with control api quickly now.
> i have wrapped controlapi in python, and already run jack1 from within a
> python shell.
> 
> i am currently working on the pulseaudio reservation code.
> when that is working, i can have a look at integrating it.

"Integrate the feature" is indeed a better term than merging.

> i am not sure, if i really like the daemon component be this
> non-standard. are we sure, that the existing scaling daemons cant be
> used for this ?

No I'm not sure. The number of available methods and API's to change CPU
freq on Linux seems to dwarf the number of available sound-APIs ;-)

e.g the gnome-cpufreq applet supports:
 - sysfs
 - libcpufreq
 - procfs
 - service (DBus)
and that list does not include ACPI and APM methods, most of which are
wrapped by libcpufreq. AFAICT every distro and desktop-environement also
has a different preferences on which to use by default.

If the goal is not to safe as much power as possible but to just detect
"start/end of major audio session". It could be done by sending a dbus
command -> 'max performance' on start and 'resume default govenor' at
(Continue reading)

torbenh | 14 Dec 17:16 2010
Picon
Picon

Re: jack frequency scaling daemon

On Tue, Dec 14, 2010 at 02:42:45PM +0100, Robin Gareus wrote:
> On 12/14/2010 02:02 PM, torbenh wrote:
> 
> > i am trying to move forward with control api quickly now.
> > i have wrapped controlapi in python, and already run jack1 from within a
> > python shell.
> > 
> > i am currently working on the pulseaudio reservation code.
> > when that is working, i can have a look at integrating it.
> 
> "Integrate the feature" is indeed a better term than merging.
> 
> > i am not sure, if i really like the daemon component be this
> > non-standard. are we sure, that the existing scaling daemons cant be
> > used for this ?
> 
> No I'm not sure. The number of available methods and API's to change CPU
> freq on Linux seems to dwarf the number of available sound-APIs ;-)
> 
> e.g the gnome-cpufreq applet supports:
>  - sysfs
>  - libcpufreq
>  - procfs
>  - service (DBus)
> and that list does not include ACPI and APM methods, most of which are
> wrapped by libcpufreq. AFAICT every distro and desktop-environement also
> has a different preferences on which to use by default.

libcpufreq doesnt help with the privilege problem.
however, i would prefer a deamon running as root.
(Continue reading)

Robin Gareus | 14 Dec 18:22 2010

Re: jack frequency scaling daemon

Hi Torben,

On 12/14/2010 05:16 PM, torbenh wrote:
> On Tue, Dec 14, 2010 at 02:42:45PM +0100, Robin Gareus wrote:
>
> however, i would prefer a deamon running as root.
> and then having the jackd executable connect to this daemon
> and requesting frequency changes.

The issue with that approach might be latency of that connection.
until the daemon reacts, some x-runs may already have occurred. That's
why I'm currently using jack_set_graph_order_callback() to trigger updates.

but heck, using some more conservative thresholds and assuming that DSP
load does not jump too much, this is the cleanest solution.

> would be nice if this connection would be via dbus, because this is what
> the python layer is mainly about.... 
> glue libjackserver with some dbus mumbo jumbo...

dbus is supposed to be low-latency, but I have no idea what low means
numerically in that context.

I suggest to offer a simple fallback solution (f.i a socket) for systems
that do not have dbus.

What do you think?

robin
(Continue reading)

torbenh | 15 Dec 13:23 2010
Picon
Picon

Re: jack frequency scaling daemon

On Tue, Dec 14, 2010 at 06:22:58PM +0100, Robin Gareus wrote:
> Hi Torben,
> 
> On 12/14/2010 05:16 PM, torbenh wrote:
> > On Tue, Dec 14, 2010 at 02:42:45PM +0100, Robin Gareus wrote:
> >
> > however, i would prefer a deamon running as root.
> > and then having the jackd executable connect to this daemon
> > and requesting frequency changes.
> 
> The issue with that approach might be latency of that connection.
> until the daemon reacts, some x-runs may already have occurred. That's
> why I'm currently using jack_set_graph_order_callback() to trigger updates.

yeah. thats correct.
dbus has some form of synchronous method invocations.
and GraphOrderCallback is not RT. (it might be slow on jack1 though)
however the slowest part is probably the python glue here.

basically we can prevent the graph reordering from taking effect until
the cpufreq was increased.

> 
> but heck, using some more conservative thresholds and assuming that DSP
> load does not jump too much, this is the cleanest solution.
> 
> > would be nice if this connection would be via dbus, because this is what
> > the python layer is mainly about.... 
> > glue libjackserver with some dbus mumbo jumbo...
> 
(Continue reading)

Fernando Lopez-Lezcano | 15 Dec 05:31 2010
Picon

Re: jack frequency scaling daemon

On 12/13/2010 06:50 PM, Robin Gareus wrote:
>
> On Dec 14, 2010, at 3:10 AM, Paul Davis wrote:
>
>> On Mon, Dec 13, 2010 at 6:47 PM, Robin Gareus<robin <at> gareus.org>  wrote:
>>> Hi *,
>>>
>>> Following up on the discussion with Fernando, on the issue with
>>> CPU-frequency scaling and JACK:
>>
>> this sounds wonderful, but the curmudgeon in me suggests that
>> eventually this should be part of the jack server. what do you think?
>
> maybe. As far as packaging goes maybe not:
> It conflicts with cpudyn, cpufreqd and powernowd and probably others.
>
> The [inofficial] debian package of jackfreqd is marked as
>    Enhances: jackd1| jackd1-firewire, jackd2 | jackd2-firewire
> which is a reverse "Suggests" and conflicts with other CPU governor
> packages. resolving these on runtime (diable other freq daemons) is much
> more tricky.

Ah, this is something I missed, if it replaces the other standard 
daemons then that would be a problem (for me). I want everything :-)

Actually, it would be ideal for my usual workload (as suggested 
elsewhere in this thread), if jackd would tell the cpu usage daemon 
"please run as fast as possible" when starting, and then "return to your 
scheduled governor" when it is done. That would be perfect. It would not 
be optimal, but that is what I actually do every time I use jack for 
(Continue reading)

Robin Gareus | 15 Dec 13:22 2010

Re: jack frequency scaling daemon

On 12/15/2010 05:31 AM, Fernando Lopez-Lezcano wrote:
> On 12/13/2010 06:50 PM, Robin Gareus wrote:
>>
>> On Dec 14, 2010, at 3:10 AM, Paul Davis wrote:
>>
>>> On Mon, Dec 13, 2010 at 6:47 PM, Robin Gareus<robin <at> gareus.org>  wrote:
>>>> Hi *,
>>>>
>>>> Following up on the discussion with Fernando, on the issue with
>>>> CPU-frequency scaling and JACK:
>>>
>>> this sounds wonderful, but the curmudgeon in me suggests that
>>> eventually this should be part of the jack server. what do you think?
>>
>> maybe. As far as packaging goes maybe not:
>> It conflicts with cpudyn, cpufreqd and powernowd and probably others.
>>
>> The [inofficial] debian package of jackfreqd is marked as
>>    Enhances: jackd1| jackd1-firewire, jackd2 | jackd2-firewire
>> which is a reverse "Suggests" and conflicts with other CPU governor
>> packages. resolving these on runtime (diable other freq daemons) is much
>> more tricky.
> 
> Ah, this is something I missed, if it replaces the other standard
> daemons then that would be a problem (for me). I want everything :-)

I'll leave it to packagers to sort it out. The debian package that comes
with the source is basically just for my own convenience and for
inspiring real packagers.

(Continue reading)

torbenh | 15 Dec 13:26 2010
Picon
Picon

Re: jack frequency scaling daemon

On Tue, Dec 14, 2010 at 08:31:14PM -0800, Fernando Lopez-Lezcano wrote:
> On 12/13/2010 06:50 PM, Robin Gareus wrote:
> >
> >On Dec 14, 2010, at 3:10 AM, Paul Davis wrote:
> >
> >>On Mon, Dec 13, 2010 at 6:47 PM, Robin Gareus<robin <at> gareus.org>  wrote:
> >>>Hi *,
> >>>
> >>>Following up on the discussion with Fernando, on the issue with
> >>>CPU-frequency scaling and JACK:
> >>
> >>this sounds wonderful, but the curmudgeon in me suggests that
> >>eventually this should be part of the jack server. what do you think?
> >
> >maybe. As far as packaging goes maybe not:
> >It conflicts with cpudyn, cpufreqd and powernowd and probably others.
> >
> >The [inofficial] debian package of jackfreqd is marked as
> >   Enhances: jackd1| jackd1-firewire, jackd2 | jackd2-firewire
> >which is a reverse "Suggests" and conflicts with other CPU governor
> >packages. resolving these on runtime (diable other freq daemons) is much
> >more tricky.
> 
> Ah, this is something I missed, if it replaces the other standard
> daemons then that would be a problem (for me). I want everything :-)
> 
> Actually, it would be ideal for my usual workload (as suggested
> elsewhere in this thread), if jackd would tell the cpu usage daemon
> "please run as fast as possible" when starting, and then "return to
> your scheduled governor" when it is done. That would be perfect. It
(Continue reading)

Fernando Lopez-Lezcano | 15 Dec 18:49 2010
Picon

Re: jack frequency scaling daemon

On 12/15/2010 04:26 AM, torbenh wrote:
> On Tue, Dec 14, 2010 at 08:31:14PM -0800, Fernando Lopez-Lezcano wrote:
>> On 12/13/2010 06:50 PM, Robin Gareus wrote:
>>> On Dec 14, 2010, at 3:10 AM, Paul Davis wrote:
>>>
>>>> On Mon, Dec 13, 2010 at 6:47 PM, Robin Gareus<robin <at> gareus.org>   wrote:
>>>>> Hi *,
>>>>>
>>>>> Following up on the discussion with Fernando, on the issue with
>>>>> CPU-frequency scaling and JACK:
>>>> this sounds wonderful, but the curmudgeon in me suggests that
>>>> eventually this should be part of the jack server. what do you think?
>>> maybe. As far as packaging goes maybe not:
>>> It conflicts with cpudyn, cpufreqd and powernowd and probably others.
>>>
>>> The [inofficial] debian package of jackfreqd is marked as
>>>    Enhances: jackd1| jackd1-firewire, jackd2 | jackd2-firewire
>>> which is a reverse "Suggests" and conflicts with other CPU governor
>>> packages. resolving these on runtime (diable other freq daemons) is much
>>> more tricky.
>> Ah, this is something I missed, if it replaces the other standard
>> daemons then that would be a problem (for me). I want everything :-)
>>
>> Actually, it would be ideal for my usual workload (as suggested
>> elsewhere in this thread), if jackd would tell the cpu usage daemon
>> "please run as fast as possible" when starting, and then "return to
>> your scheduled governor" when it is done. That would be perfect. It
>> would not be optimal, but that is what I actually do every time I
>> use jack for something that should not fail.
> how do you tell this to which daemon ?
(Continue reading)

Gabriel M. Beddingfield | 14 Dec 06:54 2010
Picon

Re: jack frequency scaling daemon


Hi Robin,

On Monday, December 13, 2010 05:47:37 pm Robin Gareus wrote:
> There's a bit of magic in there so that it can launched
> as as root (during system startup) and later on discover
> & connect to a JACK instance - started by any user on
> the system. Otherwise it's very straight forward:

This voodoo is creating problems for me.  :-)

My setup:

   - jack 1.9.5, configured for jackdbus (only).
   - qjackctl 0.3.6 configured for dbus
   - kernel 2.6.35.3 SMP PREEMPT
   - N450 Atom processor

CASE 1: jackfreqd first
=======================

0. JACK is not running, no apps are open except
   a terminal.

1. Start `sudo jackfreqd -w -P`
     Found 2 scalable units:  -- 1 'CPU' per scalable unit
       cpu0: 1000Mhz - 1667Mhz (3 steps)
       cpu1: 1000Mhz - 1667Mhz (3 steps)
     Cannot connect to server socket err = No such file or directory
     Cannot connect to server socket
(Continue reading)

Robin Gareus | 14 Dec 11:46 2010

Re: jack frequency scaling daemon

Hi Gabriel,

Thanks for giving it a go.
This is very much appreciated esp. since your system is orthogonal to my
test-systems: I use linux-2.6.33.7-rt29 (i686, x86_64) | (jack1,
jack2-NOT-only-dbus) here.

On 12/14/2010 06:54 AM, Gabriel M. Beddingfield wrote:
> 
> Hi Robin,
> 
> On Monday, December 13, 2010 05:47:37 pm Robin Gareus wrote:
>> There's a bit of magic in there so that it can launched
>> as as root (during system startup) and later on discover
>> & connect to a JACK instance - started by any user on
>> the system. Otherwise it's very straight forward:
> 
> This voodoo is creating problems for me.  :-)

Nah, the problem is: it ain't real voodoo yet. Looks like we need to
turn from magic to black-magic.

> My setup:
> 
>    - jack 1.9.5, configured for jackdbus (only).

Dbus only?! Could you please send me the output of
 `ps axwu | grep jack`
after launching jackd.

(Continue reading)

Gabriel M. Beddingfield | 14 Dec 14:34 2010
Picon

Re: jack frequency scaling daemon

On Tuesday, December 14, 2010 04:46:05 am you wrote:
> 
> Dbus only?! Could you please send me the output of
>  `ps axwu | grep jack`
> after launching jackd.

Yes, dbus ony!  Why??  See [1].

$ jack_control start
$ jack_control status
--- status
started
$ ps axwu | grep jack
gabriel    818  5.0  8.7 103504 ?     SLs1 0:20  0:00 /usr/bin/jackdbus auto

> Does it by any chance have any SELINUX features enabled?
> 
>   grep SELINUX /boot/config-2.6.35.3

$ grep SELINUX /boot/config-2.6.35.3-12.1-netbook
# CONFIG_DEFAULT_SECURITY_SELINUX is not set
$

>  cd /tmp
>  git clone git://rg42.org/jackfreqd
>  cd jackfreqd
>  git checkout -b test 35de120
>  make
>  # START jackd
>  sudo ./jackfreqd
(Continue reading)

Robin Gareus | 14 Dec 16:00 2010

Re: jack frequency scaling daemon

On 12/14/2010 02:34 PM, Gabriel M. Beddingfield wrote:

>>  cd /tmp
>>  git clone git://rg42.org/jackfreqd
>>  cd jackfreqd
>>  git checkout -b test 35de120
>>  make
>>  # START jackd
>>  sudo ./jackfreqd
> 
> This works!  And I confirmed that it's fiddling with the processor frequency.

That version should also work with '-w -P' then. Could you please try
these two tests:

1) start jack, start 'jackfreqd -w -v -v -v -v', stop jack, start jack
-> see if it reconnects: there should be a "connected to JACKd" and
"dsp load >= 0.0" messages

2) killall jackd; start 'jackfreqd -w -v -v', start jack..
-> see if it connects to jackd, message:"jackd: uid:1000 gid:1000" or
similar.

The problem with this old version is that jackfreqd will terminate on
suspend/resume. (jackfreqd drops its root priv after opening the sysfs
interface. The file-descriptors for the sysfs CPU scaling will be
invalidated on resume and jackfreqd can not re-open them.)

On the downside I can not reproduce your problem (I'm using debian's
jack2 which has both jackd and jackdbus).
(Continue reading)

Gabriel M. Beddingfield | 14 Dec 16:07 2010
Picon

Re: jack frequency scaling daemon


On Tue, 14 Dec 2010, Robin Gareus wrote:

> On the downside I can not reproduce your problem (I'm using debian's
> jack2 which has both jackd and jackdbus).

I wonder if Rui (QJackCtl) is mucking this up!  :-p

I'll give this stuff a go in a few hours.

-gabriel
Robin Gareus | 14 Dec 16:15 2010

Re: jack frequency scaling daemon

On 12/14/2010 04:07 PM, Gabriel M. Beddingfield wrote:
> 
> 
> On Tue, 14 Dec 2010, Robin Gareus wrote:
> 
>> On the downside I can not reproduce your problem (I'm using debian's
>> jack2 which has both jackd and jackdbus).
> 
> I wonder if Rui (QJackCtl) is mucking this up!  :-p

I can't imagine how he could do that.

> I'll give this stuff a go in a few hours.
> 
> -gabriel
Gabriel M. Beddingfield | 14 Dec 16:25 2010
Picon

Re: jack frequency scaling daemon


On Tue, 14 Dec 2010, Robin Gareus wrote:

>> I wonder if Rui (QJackCtl) is mucking this up!  :-p
>
> I can't imagine how he could do that.

Voo-doo!! :-)

I dunno.  I shoulda kept my mouth shut until I've tried some 
things.

But the thought was this:  It "feels" like a race condition. 
Meanwhile, we have two programs (jackfreqd and qjackctl) 
constantly monitoring jack for connections and stuff.  And 
for some reason, new clients can't seem to connect.

-gabriel
Gabriel M. Beddingfield | 14 Dec 20:13 2010
Picon

Re: jack frequency scaling daemon


Hi Robin,

On Tue, 14 Dec 2010, Robin Gareus wrote:

> On 12/14/2010 02:34 PM, Gabriel M. Beddingfield wrote:
>
>>>  cd /tmp
>>>  git clone git://rg42.org/jackfreqd
>>>  cd jackfreqd
>>>  git checkout -b test 35de120
>>>  make
>>>  # START jackd
>>>  sudo ./jackfreqd
>>
>> This works!  And I confirmed that it's fiddling with the processor frequency.
>
> That version should also work with '-w -P' then. Could you please try
> these two tests:
>
> 1) start jack, start 'jackfreqd -w -v -v -v -v', stop jack, start jack
> -> see if it reconnects: there should be a "connected to JACKd" and
> "dsp load >= 0.0" messages

With 35de120 this works as expected, no defects to mention.

>
> 2) killall jackd; start 'jackfreqd -w -v -v', start jack..
> -> see if it connects to jackd, message:"jackd: uid:1000 gid:1000" or
> similar.
(Continue reading)

Robin Gareus | 15 Dec 00:57 2010

Re: jack frequency scaling daemon

On 12/14/2010 08:13 PM, Gabriel M. Beddingfield wrote:
[..]
> 
> As discussed on IRC, this appears to me like there's a race condition
> somewhere -- possibly in the jack server.

I've cleaned up the patch a bit: jackfreqd v0.1.1 (aka 5132451) is out.
Could you try that?

It is still not clear to me what the actual cause of the problem was. -
a bug that can be fixed by adding basically a no-op line is kind of
suspicious.

Race-condition: I don't know even know who's racing! jackfreqd is a
non-threaded application, that fails to connect to jack if it does
  setuid(..); jack_client_open(..);
but works if with
  setuid(..); int noop=1; jack_client_open(..);

Wouldn't it be for the fact that there are no "-O?" compiler
optimizations, I'd hazard a guess at them. Maybe it's a weird memory or
segmentation issue?! but valgrind does not show anything unusual either.
I also can not reproduce this problem. I just tried the versions that do
not work for you on a netbook with also an Atom CPU (but running
64studio/Ubuntu), no problems here.

Anyway, time to move on: Given recent discussion with Torben and Paul:
this implementation may not be around for too long before the feature is
being integrated into JACKd.

(Continue reading)

Gabriel M. Beddingfield | 15 Dec 04:58 2010
Picon

Re: jack frequency scaling daemon

On Tuesday, December 14, 2010 05:57:56 pm you wrote:
> On 12/14/2010 08:13 PM, Gabriel M. Beddingfield wrote:
> [..]
> 
> > As discussed on IRC, this appears to me like there's a
> > race condition somewhere -- possibly in the jack
> > server.
> 
> I've cleaned up the patch a bit: jackfreqd v0.1.1 (aka
> 5132451) is out. Could you try that?

This works for me... but I think I found why it wasn't 
working before...

> Race-condition: I don't know even know who's racing!
> jackfreqd is a non-threaded application, that fails to
> connect to jack if it does setuid(..);
> jack_client_open(..);
> but works if with
>   setuid(..); int noop=1; jack_client_open(..);

jackfreqd *is* a threaded application because you call 
jack_client_open().  On my machine, I show that jackfreqd 
typically has 3 threads (the main thread, and 2 jack 
threads).

Remember when I got these error messages:

   Connect: can't connect named fifo name = \ 
      /dev/shm/jack_fifo.0_default_qjackctl \
(Continue reading)

Robin Gareus | 15 Dec 13:33 2010

Re: jack frequency scaling daemon

Hi Gabriel,

On 12/15/2010 04:58 AM, Gabriel M. Beddingfield wrote:
> On Tuesday, December 14, 2010 05:57:56 pm you wrote:
>> On 12/14/2010 08:13 PM, Gabriel M. Beddingfield wrote:
>> [..]
>>
>>> As discussed on IRC, this appears to me like there's a
>>> race condition somewhere -- possibly in the jack
>>> server.
>>
>> I've cleaned up the patch a bit: jackfreqd v0.1.1 (aka
>> 5132451) is out. Could you try that?
> 
> This works for me... but I think I found why it wasn't 
> working before...
> 
>> Race-condition: I don't know even know who's racing!
>> jackfreqd is a non-threaded application, that fails to
>> connect to jack if it does setuid(..);
>> jack_client_open(..);
>> but works if with
>>   setuid(..); int noop=1; jack_client_open(..);
> 
> jackfreqd *is* a threaded application because you call 
> jack_client_open().  On my machine, I show that jackfreqd 
> typically has 3 threads (the main thread, and 2 jack 
> threads).

yes, but it's only threaded _after_ calling jack_client_open().
(Continue reading)

Adrian Knoth | 14 Dec 16:27 2010
Picon

Re: jack frequency scaling daemon

On 12/14/10 00:47, Robin Gareus wrote:

> Hi *,

Hi!

> On a multi-core systems the system-load may still be too low for a CPU
> governor to react (and increase CPU speed) while DSP load is already at
> the limit, causing x-runs.

Have we already profound knowledge about this "may still be [..] for a
governor"?

Last time I read the blog of the kernel guy who's doing the governors,
his statement was pretty clear: go for "ondemand" and forget about
everything else.

I don't even have a userspace CPU daemon installed.

I never checked, but if you're saying that (over-)loading a single core
won't trigger a frequency step-up, then it's a bug in the kernel and
should be fixed there.

I'm not convinced that adding another daemon and another tweak to the
equation is what we really want. After all, it's just audio, and both,
Win and OSX can do it with vanilla kernels, without fiddling around with
magic values in even more magic config files and the lot.

I've been using some 200+ tracks projects with tons of virtual
instruments on those platforms in the post production, and I'm using a
(Continue reading)

Gabriel M. Beddingfield | 14 Dec 16:29 2010
Picon

Re: jack frequency scaling daemon


On Tue, 14 Dec 2010, Adrian Knoth wrote:

> Long story short: please *prove* that the ondemand scheduler has the
> shortcomings you try to address. Until then, I simply don't believe we
> need another tool to make our single virtual instrument work. ;)

I've proven it.  Will post details later.

-gabriel
Robin Gareus | 14 Dec 16:35 2010

Re: jack frequency scaling daemon

On 12/14/2010 04:29 PM, Gabriel M. Beddingfield wrote:
> 
> 
> On Tue, 14 Dec 2010, Adrian Knoth wrote:
> 
>> Long story short: please *prove* that the ondemand scheduler has the
>> shortcomings you try to address. Until then, I simply don't believe we
>> need another tool to make our single virtual instrument work. ;)
> 
> I've proven it.  Will post details later.

So has Fernando. see the "jmess vs. jack 1.9.6, lots of connections"
thread just a few days back.

An excerpt of some additional off-list communication can be read at
http://rg42.org/oss/jackfreqd/start#discussion_with_fernando

In short: The problem is that  "On a multi-core systems the system-load
may still be too low for a CPU governor to react (and increase CPU
speed) while DSP load is already at the limit, causing x-runs."

The git-head of jackfreqd includes a patched version of jacktest.c
called "busyjack" which allows to go to specified DSP-load. I've used
that to reproduce Fernando's issue.

ciao,
robin
Ralf Mardorf | 14 Dec 16:34 2010
Picon

Re: jack frequency scaling daemon

On Tue, 2010-12-14 at 16:27 +0100, Adrian Knoth wrote:
> Last time I read the blog of the kernel guy who's doing the governors,
> his statement was pretty clear: go for "ondemand" and forget about
> everything else.

When using some soft synth on Linux I need to switch to performance,
otherwise there are audible glitches on my machine. Btw. ondemand
doesn't save much consumption on my machine, I anyway prefer it for
non-audio productions.
Gabriel M. Beddingfield | 14 Dec 16:49 2010
Picon

Re: jack frequency scaling daemon


On Tue, 14 Dec 2010, Ralf Mardorf wrote:

> On Tue, 2010-12-14 at 16:27 +0100, Adrian Knoth wrote:
>> Last time I read the blog of the kernel guy who's doing the governors,
>> his statement was pretty clear: go for "ondemand" and forget about
>> everything else.
>
> When using some soft synth on Linux I need to switch to performance,
> otherwise there are audible glitches on my machine. Btw. ondemand
> doesn't save much consumption on my machine, I anyway prefer it for
> non-audio productions.

I agree.

On an atom I measured about 1W difference (about 10%) 
between top speed (1667MHz) and low speed (1000MHz).

Meanwhile the screen brightness accounts for 3-4W (about 
35%).

But I really would like to save the 1W when not doing audio.

-gabriel
Ralf Mardorf | 14 Dec 17:08 2010
Picon

Re: jack frequency scaling daemon

On Tue, 2010-12-14 at 09:49 -0600, Gabriel M. Beddingfield wrote:
> But I really would like to save the 1W when not doing audio.
Correct, 1,000 people or 10,0000 people might save 1W 24/7 and video
productions or surfing the web is ok with ondemand on my Model: 15.107.2
"AMD Athlon(tm) X2 Dual Core Processor BE-2350".
Robin Gareus | 14 Dec 16:44 2010

Re: jack frequency scaling daemon

On 12/14/2010 04:27 PM, Adrian Knoth wrote:
> On 12/14/10 00:47, Robin Gareus wrote:
> 
>> Hi *,
> 
> Hi!
> 
>> On a multi-core systems the system-load may still be too low for a CPU
>> governor to react (and increase CPU speed) while DSP load is already at
>> the limit, causing x-runs.
> 
> Have we already profound knowledge about this "may still be [..] for a
> governor"?
> 
> Last time I read the blog of the kernel guy who's doing the governors,
> his statement was pretty clear: go for "ondemand" and forget about
> everything else.

That's what I've been doing successfully for quite a while. The issue
with high DSP load but low CPU load is quite an edge-case, but it
becomes much more prominent with increasing number of CPU cores/threads.

> I don't even have a userspace CPU daemon installed.
> 
> I never checked, but if you're saying that (over-)loading a single core
> won't trigger a frequency step-up, then it's a bug in the kernel and
> should be fixed there.

It may not be overloading a single core. the DSP load may be distributed
among the cores.
(Continue reading)


Gmane