Re: Jack vs. Alsa, PianoTeq demo: Alsa wins!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



FYI, according to cpufreq-info, I'm only configured for the "performance" governor.....so I think the issue goes back to the jack version I was using. For whatever reason, I need to stay away from 0.118 and 0.120 and move to jack2-svn (which is a moving target, but for now, it's fine). After installing jack2-svn on Arch this morning, 'jackd -V' says that it's 'jackdmp 1.9.7', so that's what's working for me much better at the moment.

Best,
AKJ

cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@xxxxxxxxxxxxxxx, please.
analyzing CPU 0:
 driver: acpi-cpufreq
 CPUs which run at the same hardware frequency: 0
 CPUs which need to have their frequency coordinated by software: 0
 maximum transition latency: 10.0 us.
 hardware limits: 1000 MHz - 1.67 GHz
 available frequency steps: 1.67 GHz, 1.33 GHz, 1000 MHz
 available cpufreq governors: performance
 current policy: frequency should be within 1000 MHz and 1.67 GHz.
         The governor "performance" may decide which speed to use
         within this range.
 current CPU frequency is 1.67 GHz.
analyzing CPU 1:
 driver: acpi-cpufreq
 CPUs which run at the same hardware frequency: 1
 CPUs which need to have their frequency coordinated by software: 1
 maximum transition latency: 10.0 us.
 hardware limits: 1000 MHz - 1.67 GHz
 available frequency steps: 1.67 GHz, 1.33 GHz, 1000 MHz
 available cpufreq governors: performance
 current policy: frequency should be within 1000 MHz and 1.67 GHz.
         The governor "performance" may decide which speed to use
         within this range.
 current CPU frequency is 1.67 GHz.

On Sun, Jun 12, 2011 at 7:29 AM, Ralf Mardorf <ralf.mardorf@xxxxxxxxxxxxx> wrote:
On Sun, 2011-06-12 at 03:46 -0700, James Warden wrote:
>
> --- On Sun, 6/12/11, Ralf Mardorf <ralf.mardorf@xxxxxxxxxxxxx> wrote:
>
> > From: Ralf Mardorf <ralf.mardorf@xxxxxxxxxxxxx>
> > Subject: Re: Jack vs. Alsa, PianoTeq demo: Alsa wins!
> > To: linux-audio-user@xxxxxxxxxxxxxxxxxxxx
> > Date: Sunday, June 12, 2011, 6:15 AM
> > On Sun, 2011-06-12 at 11:59 +0200,
> > Jeremy Jongepier wrote:
> > > On 06/12/2011 11:44 AM, Ralf Mardorf wrote:
> > > > What CPU frequency scaling? Is it set to
> > performance? There's a new
> > > > nuisance for GNOME desktops on Ubuntu and Debian,
> > they ignore the
> > > > kernel's default CPU frequency scaling, they
> > switch from 'performance'
> > > > to 'ondemand' for GNOME sessions.
> > >
> > > apt-file search ondemand | grep init.d
> > > initscripts: /etc/init.d/ondemand
> > >
> > > So at least on Ubuntu the ondemand init script is part
> > of the
> > > initscripts package and has nothing to do with Gnome.
> > >
> > > Best,
> > >
> > > Jeremy
> >
> >
> > Thank you :)
> >
> > On Debian it's
> >
> > $ cat /etc/init.d/cpufrequtils
> > #!/bin/sh
> > [snip]
> > GOVERNOR="ondemand"
> > [snip]
> >
>
>
> from the same script of debian:
>
> <snip>
> if [ -f /etc/default/cpufrequtils ] ; then
> Â Â Â Â . /etc/default/cpufrequtils
> fi
>
> # if not enabled then exit gracefully
> [ "$ENABLE" = "true" ] || exit 0
>
> if [ -n "$MAX_SPEED" ] && [ $MAX_SPEED != "0" ] ; then
> Â Â Â Â CPUFREQ_OPTIONS="$CPUFREQ_OPTIONS --max $MAX_SPEED"
> fi
>
> if [ -n "$MIN_SPEED" ] && [ $MIN_SPEED != "0" ] ; then
> Â Â Â Â CPUFREQ_OPTIONS="$CPUFREQ_OPTIONS --min $MIN_SPEED"
> fi
>
> if [ -n "$GOVERNOR" ] ; then
> Â Â Â Â CPUFREQ_OPTIONS="$CPUFREQ_OPTIONS --governor $GOVERNOR"
> fi
> </snip>
>
> The debian way is to have a default config in the directory /etc/default, which cpufrequtils is sourcing if it exists (see script snippet above). So either you make one if you don't have one or get informed before calling such config scheme "idiocy". I don't want to be too hard in my critics but you seem to be a little too noisy too fast. Make sure you RTFM before posting such judgemental comments on distros.
>
> J.

But I wish to have the opportunity to chose the frequency scaling e.g.
by the GNOME panel, just the default should be the kernel's default. I
don't understand what the script is good for. IMO it only cause pain.
This script and the behaviour it cause is for a default Debian install
and IMO this is idiocy. A default can be set by the kernel
configuration, what's bad with this? The most often cause for xruns for
the last month I read about, was a bad CPU frequency scaling.

I'm curios about the cause of "Jack vs. Alsa, PianoTeq demo: Alsa
wins!".

I experienced that as soon as jackd is involved, even if a media player
was ok with ALSA, I got xruns causing audible glitches, already without
CPU load, while there were never xruns or audible glitches as soon as
the CPU frequency scaling is set to performance, even for heavy resource
hungry audio productions. There might be two xruns when I start a
session, but no additional for the next 48 hours.

Regards,

Ralf

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user



--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user

[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux