12 Jun
2011
12 Jun
'11
9:40 a.m.
Hi all--
I'm wondering if anyone else has experienced this:
I'm considering purchasing PianoTeq, but I wanted to try the demo. It seems
to work better with just the alsa driver than it does with jack, a reversal
of the usual situation.
I tested this several times by playing fast glissandi on the default piano
preset. Each time, my little EEE-PC netbook under jack choked with xruns and
a brief silence while PianoTeq 'reset' itself, but Alsa alone chugged away
with no xruns unless there was an extreme amount of load....
I'm wondering if anyone can comment on this. It seems odd, especially since
the jack developers claim jack adds no latency by itself to the picture in
any situation---so, do we have a situation where the code is better written
for the alsa driver than for jackd? It seems we do, in this case....
Best,
AKJ
--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org
12 Jun
12 Jun
11:36 a.m.
On 06/12/2011 09:40 AM, Aaron Krister Johnson wrote:
Hi all--
I'm wondering if anyone else has experienced this:
I'm considering purchasing PianoTeq, but I wanted to try the demo. It
seems to work better with just the alsa driver than it does with jack, a
reversal of the usual situation.
I tested this several times by playing fast glissandi on the default
piano preset. Each time, my little EEE-PC netbook under jack choked with
xruns and a brief silence while PianoTeq 'reset' itself, but Alsa alone
chugged away with no xruns unless there was an extreme amount of load....
I'm wondering if anyone can comment on this. It seems odd, especially
since the jack developers claim jack adds no latency by itself to the
picture in any situation---so, do we have a situation where the code is
better written for the alsa driver than for jackd? It seems we do, in
this case....
Which Jack version? Which kernel? Which OS?
Using Pianoteq myself, runs like a charm, with JACK, but it asks for
pretty some CPU...
\r
6:45 p.m.
Hi, I realized that this would be pertinent info this morning, thanks for
reminding me...
I'm on Arch Linux, and I used both kernels 2.6.33-rt and the standard
2.6.32-LTS (long-term support) with the same results....
It's Jack 0.118.0-2 and also 0.120.2-1 that were problematic for me. They
also caused weird behavior with fluidsynth-1.1.3--with my M-Audio KeyRig 49
USB keyboard, there were HUGE (.5 seconds!!!) midi delays.
I installed jack2-svn today and the fluidsynth issue is now gone. And,
although the PianoTeq xruns are much better, they are still slightly more
apparent than with Alsa alone.
I don't know what happened, but, being pragmatic, one has to just find
versions that work....yikes!
AKJ
On Sun, Jun 12, 2011 at 4:36 AM, rosea.grammostola <
rosea.grammostola(a)gmail.com> wrote:
Which Jack version? Which kernel? Which OS?
Using Pianoteq myself, runs like a charm, with JACK,
but it asks for pretty
some CPU...
\r
On 06/12/2011 09:40 AM, Aaron Krister Johnson wrote:
--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org
Hi all--
I'm wondering if anyone else has experienced this:
I'm considering purchasing PianoTeq, but I wanted to try the demo. It
seems to work better with just the alsa driver than it does with jack, a
reversal of the usual situation.
I tested this several times by playing fast glissandi on the default
piano preset. Each time, my little EEE-PC netbook under jack choked with
xruns and a brief silence while PianoTeq 'reset' itself, but Alsa alone
chugged away with no xruns unless there was an extreme amount of load....
I'm wondering if anyone can comment on this. It seems odd, especially
since the jack developers claim jack adds no latency by itself to the
picture in any situation---so, do we have a situation where the code is
better written for the alsa driver than for jackd? It seems we do, in
this case....
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
10:21 p.m.
On Sun, Jun 12, 2011 at 12:45 PM, Aaron Krister Johnson
<aaron(a)akjmusic.com> wrote:
Hi, I realized that this would be pertinent info this
morning, thanks for
reminding me...
I'm on Arch Linux, and I used both kernels 2.6.33-rt and the standard
2.6.32-LTS (long-term support) with the same results....
It's Jack 0.118.0-2 and also 0.120.2-1 that were problematic for me. They
also caused weird behavior with fluidsynth-1.1.3--with my M-Audio KeyRig 49
USB keyboard, there were HUGE (.5 seconds!!!) midi delays.
I installed jack2-svn today and the fluidsynth issue is now gone. And,
although the PianoTeq xruns are much better, they are still slightly more
apparent than with Alsa alone.
I don't know what happened, but, being pragmatic, one has to just find
versions that work....yikes!
as i was hinting, its not just about versions, but also settings. you
don't know what settings Pianoteq is using when it interfaces with
ALSA directly. you do know what settings JACK is using ...
11:44 a.m.
On Sun, 2011-06-12 at 02:40 -0500, Aaron Krister Johnson wrote:
EEE-PC netbook
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. Thank you distros, kernel-rt's build
with the governor set to 'performance' needs to be corrected. From
perhaps 20 request to Linux audio mailing lists, for around 19 the xrun
issue could be solved by setting CPU frequency scaling to 'performance'.
11:59 a.m.
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
12:15 p.m.
On Sun, 2011-06-12 at 11:59 +0200, Jeremy Jongepier wrote:
On 06/12/2011 11:44 AM, Ralf Mardorf wrote:
Thank you :)
On Debian it's
$ cat /etc/init.d/cpufrequtils
#!/bin/sh
[snip]
GOVERNOR="ondemand"
[snip]
anyway, this is idiocy, hence the default can be set by the kernel. For
the kernel-generic-default-office-non-real-time a distro could chose
'ondemand'. This script is nonsense and only cause that once a month
somebody send a request regarding to xruns when using jackd.
Regards,
Ralf
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 
12:46 p.m.
--- On Sun, 6/12/11, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
Subject: Re: [LAU] Jack vs. Alsa, PianoTeq demo: Alsa wins!
To: linux-audio-user(a)lists.linuxaudio.org
Date: Sunday, June 12, 2011, 6:15 AM
On Sun, 2011-06-12 at 11:59 +0200,
Jeremy Jongepier wrote:
of the
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.
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 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]
anyway, this is idiocy, hence the default can be set
by the
kernel. For
the kernel-generic-default-office-non-real-time a distro
could chose
'ondemand'. This script is nonsense and only cause that
once a month
somebody send a request regarding to xruns when using
jackd.
Regards,
Ralf
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
2:30 p.m.
On Sun, 2011-06-12 at 03:46 -0700, James Warden wrote:
--- On Sun, 6/12/11, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
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
From: Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net>
Subject: Re: [LAU] Jack vs. Alsa, PianoTeq demo: Alsa wins!
To: linux-audio-user(a)lists.linuxaudio.org
Date: Sunday, June 12, 2011, 6:15 AM
On Sun, 2011-06-12 at 11:59 +0200,
Jeremy Jongepier wrote:
of the
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. 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 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]
2:35 p.m.
On Sun, 2011-06-12 at 14:29 +0200, Ralf Mardorf wrote:
On Sun, 2011-06-12 at 03:46 -0700, James Warden
wrote:
PS: What should people read? Why should people read? This isn't a good
OOTB behaviour. It's not relevant for me, because I set up my Debian to
my needs, but I often read about the same issue. For me everything is
ok, but other people have problems and there's no need for those
problems. Even if people are willing to read, thy don't know what to
read.
--- On Sun, 6/12/11, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
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 From: Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net>
Subject: Re: [LAU] Jack vs. Alsa, PianoTeq demo: Alsa wins!
To: linux-audio-user(a)lists.linuxaudio.org
Date: Sunday, June 12, 2011, 6:15 AM
On Sun, 2011-06-12 at 11:59 +0200,
Jeremy Jongepier wrote:
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. 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]
7:08 p.m.
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(a)vger.kernel.org, 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(a)alice-dsl.net>wrote;wrote:
On Sun, 2011-06-12 at 03:46 -0700, James Warden
wrote:
--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org
--- On Sun, 6/12/11, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
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.
From: Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net>
Subject: Re: [LAU] Jack vs. Alsa, PianoTeq demo: Alsa wins!
To: linux-audio-user(a)lists.linuxaudio.org
Date: Sunday, June 12, 2011, 6:15 AM
On Sun, 2011-06-12 at 11:59 +0200,
Jeremy Jongepier wrote:
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, 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]
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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
8:28 p.m.
On Sun, 2011-06-12 at 12:08 -0500, Aaron Krister Johnson wrote:
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.
I suspect a typo since I build Jack2 from svn some time ago
$ jackd -V
jackdmp 1.9.8
And yes, it improved something for me too, compared to older versions of
Jack2. With my current mobo and old sound card Jack1 never worked,
didn't test it with the new sound card. Fortunately several distros
enabled to chose between Jack1 and 2 by packages, so everybody can test
which version fit's better to the hardware, or what ever will cause the
voodoo.
2:15 p.m.
On Sun, Jun 12, 2011 at 9:40 AM, Aaron Krister Johnson
<aaron(a)akjmusic.com> wrote:
<snip>
I'm wondering if anyone can comment on this. It seems odd, especially since
the jack developers claim jack adds no latency by itself to the picture in
any situation---so, do we have a situation where the code is better written
for the alsa driver than for jackd? It seems we do, in this case....
Best,
AKJ
JACK adds no latency but it adds a bit more CPU usage. Nothing too
much to be noticed on fast CPUs but if you are very limited with
resources it is very noticable (on my old EEE704 I can run Pianoteq
with alsa and using Rhody patch almost normally but with JACK it won't
do. On my Core2Duo I can't even see difference in CPU usage between
JACK and alsa).
Cheers!
Igor
3:47 p.m.
On Sun, Jun 12, 2011 at 3:40 AM, Aaron Krister Johnson
<aaron(a)akjmusic.com> wrote:
Hi all--
I'm wondering if anyone else has experienced this:
I'm considering purchasing PianoTeq, but I wanted to try the demo. It seems
to work better with just the alsa driver than it does with jack, a reversal
of the usual situation.
I tested this several times by playing fast glissandi on the default piano
preset. Each time, my little EEE-PC netbook under jack choked with xruns and
a brief silence while PianoTeq 'reset' itself, but Alsa alone chugged away
with no xruns unless there was an extreme amount of load....
I'm wondering if anyone can comment on this. It seems odd, especially since
the jack developers claim jack adds no latency by itself to the picture in
any situation---so, do we have a situation where the code is better written
for the alsa driver than for jackd? It seems we do, in this case....
you should check the latency that it is using with ALSA. Assuming you
use the first audio device on the first sound card:
cat /proc/asound/card0/pcm0p/sub0/hw_params
and then compare that with your JACK settings.
--p
6:49 p.m.
Hi Paul-
I'm not sure if what you're saying matters, since the buffer settings, etc.
were the same between jack and alsa settings in the PianoTeq setup
dialogs....unless I'm missing something, the /proc directory info you are
asking me to compare with jackd settings verify that they were the same.
Best,
AKJ
P.S. Did you get my email ever about jackctl.py? Not the one in the jack
source tree, but my CL utility of the same name that I wrote?
On Sun, Jun 12, 2011 at 8:47 AM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote:
On Sun, Jun 12, 2011 at 3:40 AM, Aaron Krister
Johnson
<aaron(a)akjmusic.com> wrote:
--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org
Hi all--
I'm wondering if anyone else has experienced this:
I'm considering purchasing PianoTeq, but I wanted to try the demo. It
seems
to work better with just the alsa driver than it
does with jack, a
reversal
of the usual situation.
I tested this several times by playing fast glissandi on the default
piano
preset. Each time, my little EEE-PC netbook under
jack choked with xruns
and
a brief silence while PianoTeq 'reset'
itself, but Alsa alone chugged
away
with no xruns unless there was an extreme amount
of load....
I'm wondering if anyone can comment on this. It seems odd, especially
since
the jack developers claim jack adds no latency by
itself to the picture
in
any situation---so, do we have a situation where
the code is better
written
for the alsa driver than for jackd? It seems we
do, in this case....
you should check the latency that it is using with ALSA. Assuming you
use the first audio device on the first sound card:
cat /proc/asound/card0/pcm0p/sub0/hw_params
and then compare that with your JACK settings.
--p
10:23 p.m.
On Sun, Jun 12, 2011 at 12:48 PM, Aaron Krister Johnson
<aaron(a)akjmusic.com> wrote:
Hi Paul-
I'm not sure if what you're saying matters, since the buffer settings, etc.
were the same between jack and alsa settings in the PianoTeq setup
dialogs....unless I'm missing something, the /proc directory info you are
asking me to compare with jackd settings verify that they were the same.
oops, i somehow missed this in the thread. the settings cannot be the
same because PianoTeq doesn't control the JACK settings. just run the
command i mentioned and that will let you see how ALSA gets configured
by PT and then we can compare it with the way JACK does it.
Best,
AKJ
P.S. Did you get my email ever about jackctl.py? Not the one in the jack
source tree, but my CL utility of the same name that I wrote?
yeah, its in the backlog at present. its functionality overlaps quite
a lot of other stuff.
13 Jun
13 Jun
2:31 a.m.
On Sun, Jun 12, 2011 at 3:23 PM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote:
On Sun, Jun 12, 2011 at 12:48 PM, Aaron Krister
Johnson
<aaron(a)akjmusic.com> wrote:
PianoTeq doesn't configure things when jack is running. It just detects and
runs with what jack's setting are. However, the *user* configures things
when Alsa is running. Things like sr, buffer sizes, and periods. I was
comparing apples to apples when I announced my results: for instance, if I
set PT to run Alsa @ 256 samples and 2 buffers per period, I also ran jackd
with those setting before starting PT.
I'd love your insight into what could have been going on; things seem quite
a bit better with jack2 (jackdmp-1.9.7) on my system---and, like I said, all
of a sudden weird MIDI stuff that was happening in fluidsynth is now solved,
too....I think the fluidsynth thing was actually related to a new codebase
in FS since 1.1.2 where they merged the scheduling of MIDI and audio being
handled by the same thread, IIRC...could be that the way jack1 in the
version I was running was structured caused some unforeseen voodoo.
Hi Paul-
I'm not sure if what you're saying matters, since the buffer settings,
etc.
were the same between jack and alsa settings in
the PianoTeq setup
dialogs....unless I'm missing something, the /proc directory info you are
asking me to compare with jackd settings verify that they were the same.
oops, i somehow missed this in the thread. the settings cannot be the
same because PianoTeq doesn't control the JACK settings. just run the
command i mentioned and that will let you see how ALSA gets configured
by PT and then we can compare it with the way JACK does it.
P.S. Did you get my email ever about jackctl.py? Not
the one in the jack
Hmmm....like what, Qjackctl? That's a GUI, this is CL. And the CL tools that
currently come with jack do the trick, but with needless typing and lack of
ease---that's what my-front end solves. What other CL tools for making jack
connections in an *easy* way are there?
AKJ
--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org
source tree, but my CL utility of the same name
that I wrote?
yeah, its in the backlog at present. its functionality overlaps quite
a lot of other stuff.
3:02 a.m.
On Sun, Jun 12, 2011 at 8:30 PM, Aaron Krister Johnson
<aaron(a)akjmusic.com> wrote:
well, JACK Session springs to mind. this should be taken up on the
jack mailing list rather than here.
PianoTeq doesn't configure things when jack is
running. It just detects and
runs with what jack's setting are. However, the *user* configures things
when Alsa is running. Things like sr, buffer sizes, and periods. I was
comparing apples to apples when I announced my results: for instance, if I
set PT to run Alsa @ 256 samples and 2 buffers per period, I also ran jackd
with those setting before starting PT.
I'd love your insight into what could have been going on; things seem quite
a bit better with jack2 (jackdmp-1.9.7) on my system---and, like I said, all
would it be so hard to just run that very simple command i asked
about? you have absolutely no guarantee that the parameters presented
by Pianoteq translate directly into ALSA driver parameters, though
they probably do. i gave you a very, very simple way to make sure of
this but we still seem to be arguing about whether to run it or not.
JACK requires context switching out of the program woken by the device
driver (jackd) to the client (pianoteq) and back again. This tends to
expose just any weakness in your system setup that relates to process
scheduling. When an app (pianoteq) deals directly with ALSA, this
context switching is avoided. Its very cheap computationally
(relatively speaking), but it is subject to system-induced snafus.
yeah, its in
the backlog at present. its functionality overlaps quite
a lot of other stuff.
Hmmm....like what, Qjackctl? That's a GUI, this is CL. And the CL tools that
currently come with jack do the trick, but with needless typing and lack of
ease---that's what my-front end solves. What other CL tools for making jack
connections in an *easy* way are there?
9:06 a.m.
Hi Paul,
On Sun, Jun 12, 2011 at 8:02 PM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote:
that
I'd don't know about JACK Session. Is it
http://sourceforge.net/projects/jacksm/ ? If so, that's also a GUI.
http://ardour.org/a3_features_jack_session_support is the first Google link
that I get for the search term "JACK Session" and it looks like something
built into things like QJackctl...are you saying it's actually a CL tool as
well?
AKJ
--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org
On Sun, Jun 12, 2011 at 8:30 PM, Aaron Krister
Johnson
<aaron(a)akjmusic.com> wrote:
I'm kind of pressed for time with several projects at the moment. Sorry I
didn't do this earlier. When I get the chance, I'll reinstall the older
version of jack1 and run the tests again with the output of that command.
We'll see, but I'm pretty sure there's no reason that Alsa would arbitrarily
change the buffer settings and such that PianoTeq requests in their config
dialog.
<snip>
PianoTeq doesn't configure things when jack
is running. It just detects
and
runs with what jack's setting are. However,
the *user* configures things
when Alsa is running. Things like sr, buffer sizes, and periods. I was
comparing apples to apples when I announced my results: for instance, if
I
set PT to run Alsa @ 256 samples and 2 buffers
per period, I also ran
jackd
with those setting before starting PT.
I'd love your insight into what could have been going on; things seem
quite
a bit better with jack2 (jackdmp-1.9.7) on my
system---and, like I said,
all
would it be so hard to just run that very simple command i asked
about? you have absolutely no guarantee that the parameters presented
by Pianoteq translate directly into ALSA driver parameters, though
they probably do. i gave you a very, very simple way to make sure of
this but we still seem to be arguing about whether to run it or not.
yeah, its
in the backlog at present. its functionality overlaps quite
a lot of other stuff.
Hmmm....like what, Qjackctl? That's a GUI, this is CL. And the CL tools currently come with jack do the trick, but with
needless typing and lack
of
ease---that's what my-front end solves. What
other CL tools for making
jack
connections in an *easy* way are there?
well, JACK Session springs to mind. this should be taken up on the
jack mailing list rather than here.
11:54 a.m.
On 06/13/2011 09:06 AM, Aaron Krister Johnson wrote:
You don't need to [re]install jack1.
Paul is interested in the ALSA settings when running PianoTeq with ALSA
- not JACK. Fire-up PT with ALSA and run
cat /proc/asound/card0/pcm0p/sub0/hw_params
(Or 'card1' depending on the interface you're using or just all:
for file in /proc/asound/card*/pcm*/sub*/hw_params; do \
echo "---- $file"; cat $file; done
)
And the jackd parameters (no difference between jack1/2). e.g.
'-p 1024 -n 2 -r 48000'
(You can get those from qjackctl setup or (unless you use jack2+dbus)
with 'ps axw | grep jackd')
Thanks,
robin
Hi Paul,
On Sun, Jun 12, 2011 at 8:02 PM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote:
[SNIP]
would it be so
hard to just run that very simple command i asked
about? you have absolutely no guarantee that the parameters presented
by Pianoteq translate directly into ALSA driver parameters, though
they probably do. i gave you a very, very simple way to make sure of
this but we still seem to be arguing about whether to run it or not.
I'm kind of pressed for time with several projects at the moment. Sorry I
didn't do this earlier. When I get the chance, I'll reinstall the older
version of jack1 and run the tests again with the output of that command.
9:08 a.m.
On Sun, Jun 12, 2011 at 8:02 PM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote:
On Sun, Jun 12, 2011 at 8:30 PM, Aaron Krister
Johnson
<aaron(a)akjmusic.com> wrote:
Will do, although I'm not on that mailing list, and have enough mailing
lists to follow, so if you don't want to discuss it here, I guess I'll just
not discuss it... :)
AKJ
--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org
Hmmm....like what, Qjackctl? That's a GUI,
this is CL. And the CL tools
that
currently come with jack do the trick, but with
needless typing and lack
of
ease---that's what my-front end solves. What
other CL tools for making
jack
connections in an *easy* way are there?
well, JACK Session springs to mind. this should be taken up on the
jack mailing list rather than here.
12 Jun
12 Jun
11:08 p.m.
On 06/12/2011 03:47 PM, Paul Davis wrote:
you should check the latency that it is using with
ALSA. Assuming you
use the first audio device on the first sound card:
cat /proc/asound/card0/pcm0p/sub0/hw_params
and then compare that with your JACK settings.
That was one really, really cool command! Very useful, thanks!
--
Atte
http://atte.dk http://modlys.dk
14 Jun
14 Jun
9:11 a.m.
Hey all,
So the continuing saga is this: still no luck getting Pianoteq with JACK to
equal or spank with superiority the performance of PianoTeq w/ALSA alone on
my system.....
I found the following information: the info from the /proc/asound output
that Paul asked me to check out confirmed that at comparable settings, JACK
choked where ALSA smoked. I had ALSA down to a period of 64 and 3
periods/buffer (hardware bufsize of 192) at a sample rate of 48000. The same
setting of jackd ('jackd -dalsa -dhw:0,0 -r48000 -p64 -n3 -S') didn't agree
with Pianoteq....
So...here's my dilemma. I have a live show coming up where I'd prefer to use
the superior harpsichord sound of Pianoteq, but I don't want to risk a
lock-up or xruns or worse in a live concert. So I would have to use
ALSA...BUT....I also need to switch to playing a live kalimba through some
Csound effects right after playing a harpsichord, and Pianoteq under ALSA
will not stand for another app opening and sharing the soundcard like JACK
will allow (ALSA will block I/O).
So what can I do?
Best,
AKJ
On Sun, Jun 12, 2011 at 2:40 AM, Aaron Krister Johnson
<aaron(a)akjmusic.com>wrote;wrote:
Hi all--
I'm wondering if anyone else has experienced this:
I'm considering purchasing PianoTeq, but I wanted to try the demo. It seems
to work better with just the alsa driver than it does with jack, a reversal
of the usual situation.
I tested this several times by playing fast glissandi on the default piano
preset. Each time, my little EEE-PC netbook under jack choked with xruns and
a brief silence while PianoTeq 'reset' itself, but Alsa alone chugged away
with no xruns unless there was an extreme amount of load....
I'm wondering if anyone can comment on this. It seems odd, especially since
the jack developers claim jack adds no latency by itself to the picture in
any situation---so, do we have a situation where the code is better written
for the alsa driver than for jackd? It seems we do, in this case....
Best,
AKJ
--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org
--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org
9:28 a.m.
On 06/14/2011 09:11 AM, Aaron Krister Johnson wrote:
Hey all,
So the continuing saga is this: still no luck getting Pianoteq with JACK to
equal or spank with superiority the performance of PianoTeq w/ALSA alone on
my system.....
I found the following information: the info from the /proc/asound output
that Paul asked me to check out confirmed that at comparable settings, JACK
choked where ALSA smoked. I had ALSA down to a period of 64 and 3
periods/buffer (hardware bufsize of 192) at a sample rate of 48000. The same
setting of jackd ('jackd -dalsa -dhw:0,0 -r48000 -p64 -n3 -S') didn't agree
with Pianoteq....
So...here's my dilemma. I have a live show coming up where I'd prefer to use
the superior harpsichord sound of Pianoteq, but I don't want to risk a
lock-up or xruns or worse in a live concert. So I would have to use
ALSA...BUT....I also need to switch to playing a live kalimba through some
Csound effects right after playing a harpsichord, and Pianoteq under ALSA
will not stand for another app opening and sharing the soundcard like JACK
will allow (ALSA will block I/O).
So what can I do?
Best,
AKJ
Hello Aaron,
Might have missed something but what kind of soundcard are you using?
And why the -S option?
Best,
Jeremy
9:36 a.m.
Hi Jeremy,
I've got a USB soundcard that I'm using for my "pro" interface: a
Lexicon
Lambda. Works well OOTB with the sound_usb_audio module. Capable of sr
48000.
AKJ
On Tue, Jun 14, 2011 at 2:28 AM, Jeremy Jongepier <jeremy(a)autostatic.com>wrote;wrote:
On 06/14/2011 09:11 AM, Aaron Krister Johnson wrote:
--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org
Hey all,
So the continuing saga is this: still no luck getting Pianoteq with JACK
to
equal or spank with superiority the performance
of PianoTeq w/ALSA alone
on
my system.....
I found the following information: the info from the /proc/asound output
that Paul asked me to check out confirmed that at comparable settings,
JACK
choked where ALSA smoked. I had ALSA down to a
period of 64 and 3
periods/buffer (hardware bufsize of 192) at a sample rate of 48000. The
same
setting of jackd ('jackd -dalsa -dhw:0,0
-r48000 -p64 -n3 -S') didn't
agree
with Pianoteq....
So...here's my dilemma. I have a live show coming up where I'd prefer to
use
the superior harpsichord sound of Pianoteq, but I
don't want to risk a
lock-up or xruns or worse in a live concert. So I would have to use
ALSA...BUT....I also need to switch to playing a live kalimba through
some
Csound effects right after playing a harpsichord,
and Pianoteq under ALSA
will not stand for another app opening and sharing the soundcard like
JACK
will allow (ALSA will block I/O).
So what can I do?
Best,
AKJ
Hello Aaron,
Might have missed something but what kind of soundcard are you using?
And why the -S option?
Best,
Jeremy
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
10 a.m.
On 06/14/2011 09:36 AM, Aaron Krister Johnson wrote:
Hi Jeremy,
I've got a USB soundcard that I'm using for my "pro" interface: a
Lexicon
Lambda. Works well OOTB with the sound_usb_audio module. Capable of sr
48000.
AKJ
Hello Aaron,
Thanks, but then why the -S option for the ALSA driver? You don't need
to force this card to use 16-bit samples afaik.
Best,
Jeremy
1:14 p.m.
On Tuesday 14 June 2011, Aaron Krister Johnson wrote:
So...here's my dilemma. I have a live show coming
up where I'd prefer to
use the superior harpsichord sound of Pianoteq, but I don't want to risk a
lock-up or xruns or worse in a live concert. So I would have to use
ALSA...BUT....I also need to switch to playing a live kalimba through some
Csound effects right after playing a harpsichord, and Pianoteq under ALSA
will not stand for another app opening and sharing the soundcard like JACK
will allow (ALSA will block I/O).
So what can I do?
Best,
AKJ
Hi Aaron,
I have reduced the "internal sample rate" inside PianoTeq's Options->Perf
dialog and it helped a lot according performance. I can choose e.g. 29400 Hz
or 22050 Hz there and I can not really hear the difference in sound quality
(maybe my old ears?!).
By that I can play PianoTeq and B4 Organ at the same time with no problems on
my LG X120 (Atom CPU N270 @ 1.6 GHz) through Jack. (To be honest, I'm
using -p128 as buffer size)
Gerhard
1:30 p.m.
On Tue, Jun 14, 2011 at 3:11 AM, Aaron Krister Johnson
<aaron(a)akjmusic.com> wrote:
Hey all,
So the continuing saga is this: still no luck getting Pianoteq with JACK to
equal or spank with superiority the performance of PianoTeq w/ALSA alone on
my system.....
I found the following information: the info from the /proc/asound output
that Paul asked me to check out confirmed that at comparable settings, JACK
choked where ALSA smoked. I had ALSA down to a period of 64 and 3
periods/buffer (hardware bufsize of 192) at a sample rate of 48000. The same
setting of jackd ('jackd -dalsa -dhw:0,0 -r48000 -p64 -n3 -S') didn't agree
with Pianoteq....
So...here's my dilemma. I have a live show coming up where I'd prefer to use
the superior harpsichord sound of Pianoteq, but I don't want to risk a
lock-up or xruns or worse in a live concert. So I would have to use
ALSA...BUT....I also need to switch to playing a live kalimba through some
Csound effects right after playing a harpsichord, and Pianoteq under ALSA
will not stand for another app opening and sharing the soundcard like JACK
will allow (ALSA will block I/O).
So what can I do?
only all the usual deeply unpleasant, deeply technical stuff related
to figuring out sources of scheduling latency on your system. as i
mentioned previously, JACK requires that your system can context
switch efficiently and without delay. lots of people (including me)
have systems that have issues with this. its caused by a tangled
thicket of interactions between the motherboard, the PCI bus, the
kernel and some userspace stuff. there is no magic bullet that will
fix a given system.
case in point: i dramatically improved things on my system yesterday
by switching from the open source nouveau driver for my nvidia card to
the proprietary one. i can now run JACK down at -p 64 -n 2 and
dragging windows around or moving the mouse back and forth across the
boundary between two monitors no longer causes gaps in the audio
(which it used to be able to do even without xruns, suggesting PCI bus
issues). but still, after 12 hours of the new system, i still have 654
xruns. this is on a very, very powerful 6-core system but without an
RT kernel.
--p
2:43 p.m.
On Tue, 2011-06-14 at 07:30 -0400, Paul Davis wrote:
i dramatically improved things on my system yesterday
by switching from the open source nouveau driver for my nvidia card to
the proprietary one.
I never use nouveau on my machine. I use nv instead. Some minutes ago I
installed an outdated proprietary from the debian repositories, because
it works, I might install current nvidia later.
Nouveau seems to be less good, at least on my machine rt patched kernels
sometimes didn't work. Now I'm at 2.6.39.1. Can't say anything about
this kernel, since I didn't use it to make music.
Not OT!
I guess a computer needs to be tailor-made to be reliable for
professional studios and to use it on stage.
My computer isn't tailor-made and I suspect most computers aren't
tailor-made, regarding to audio reliability.
15 Jun
15 Jun
10:31 a.m.
Paul Davis wrote:
On Tue, Jun 14, 2011 at 3:11 AM, Aaron Krister
Johnson
<aaron(a)akjmusic.com> wrote:
I can second that one which improved things on my laptop. Sad
as it may
be the binary drivers seem to deliver better general system performance
than the nouveau ones.
Another one I experienced (again working with intensive Pd stuff) was to
ensure that all "CPU scaling" stuff was set to maximum performance and
nothing automatic is going on (such as "Ondemand" et sim.) both CPU-wise
*and* graphics card GPU-wise (this can e.g. be controlled in the
nvidia-panel for the proprietary drivers).
All this, of course, after taking care of the 'usual' real-time
settings. This not only on the jack/audio side: e.g. even if jack is
running realtime with bleeding edge low latency your software may not be
playing well rt (I experienced this with Pure Data were an explicit -rt
command line switch is needed to get smooth rt performance).
Anyway good luck :)
Lorenzo.
Hey all,
So the continuing saga is this: still no luck getting Pianoteq with JACK to
equal or spank with superiority the performance of PianoTeq w/ALSA alone on
my system.....[...]
So...here's my dilemma. I have a live show coming up where I'd prefer to use
the superior harpsichord sound of Pianoteq, but I don't want to risk a
lock-up or xruns or worse in a live concert. So I would have to use
ALSA...BUT....I also need to switch to playing a live kalimba through some
Csound effects right after playing a harpsichord, and Pianoteq under ALSA
will not stand for another app opening and sharing the soundcard like JACK
will allow (ALSA will block I/O).
So what can I do?
only all the usual deeply unpleasant, deeply technical stuff
related
to figuring out sources of scheduling latency on your system. as i
mentioned previously, JACK requires that your system can context
switch efficiently and without delay. lots of people (including me)
have systems that have issues with this. its caused by a tangled
thicket of interactions between the motherboard, the PCI bus, the
kernel and some userspace stuff. there is no magic bullet that will
fix a given system.
case in point: i dramatically improved things on my system yesterday
by switching from the open source nouveau driver for my nvidia card to
the proprietary one. i can now run JACK down at -p 64 -n 2 and
dragging windows around or moving the mouse back and forth across the
boundary between two monitors no longer causes gaps in the audio
(which it used to be able to do even without xruns, suggesting PCI bus
issues). but still, after 12 hours of the new system, i still have 654
xruns. this is on a very, very powerful 6-core system but without an
RT kernel.
--p
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
10:52 a.m.
On Wed, 15 Jun 2011 10:30:19 +0200
Lorenzo Sutton <lsutton(a)libero.it> wrote:
Paul Davis wrote:
Hi, could you tell me exactly where I find these settings in
"nvidia-settings"? I read it some time ago, I think in the Archwiki, to
do what you're saying, but I couldn't find the relevant menu/setting. I
have version 270.41.19 BTW
cheers
renato
On Tue, Jun 14, 2011 at 3:11 AM, Aaron Krister
Johnson
<aaron(a)akjmusic.com> wrote:
case in point: i dramatically improved things on my system yesterday
by switching from the open source nouveau driver for my nvidia card
to the proprietary one.
I can second that one which improved things on my laptop.
Sad as it
may be the binary drivers seem to deliver better general system
performance than the nouveau ones.
Another one I experienced (again working with intensive Pd stuff) was
to ensure that all "CPU scaling" stuff was set to maximum performance
and nothing automatic is going on (such as "Ondemand" et sim.) both
CPU-wise *and* graphics card GPU-wise (this can e.g. be controlled in
the nvidia-panel for the proprietary drivers).
16 Jun
16 Jun
11:19 a.m.
Lorenzo Sutton wrote:
All this, of course, after taking care of the
'usual' real-time
settings. This not only on the jack/audio side: e.g. even if jack is
running realtime with bleeding edge low latency your software may not be
playing well rt (I experienced this with Pure Data were an explicit -rt
command line switch is needed to get smooth rt performance).
On my music laptop, with RT kernel, Zyn has problems with low latencies
that don't bother Yoshimi one bit. So sometimes it is a software problem.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
14 Jun
14 Jun
1:44 p.m.
On Tue, 2011-06-14 at 02:11 -0500, Aaron Krister Johnson wrote:
Hey all,
So the continuing saga is this: still no luck getting Pianoteq with
JACK to equal or spank with superiority the performance of PianoTeq
w/ALSA alone on my system.....
I found the following information: the info from the /proc/asound
output that Paul asked me to check out confirmed that at comparable
settings, JACK choked where ALSA smoked. I had ALSA down to a period
of 64 and 3 periods/buffer (hardware bufsize of 192) at a sample rate
of 48000. The same setting of jackd ('jackd -dalsa -dhw:0,0 -r48000
-p64 -n3 -S') didn't agree with Pianoteq....
So...here's my dilemma. I have a live show coming up where I'd prefer
to use the superior harpsichord sound of Pianoteq, but I don't want to
risk a lock-up or xruns or worse in a live concert. So I would have to
use ALSA...BUT....I also need to switch to playing a live kalimba
through some Csound effects right after playing a harpsichord, and
Pianoteq under ALSA will not stand for another app opening and sharing
the soundcard like JACK will allow (ALSA will block I/O).
So what can I do?
You won't use a non-tailor-made non-super-computer for
- recording an orchestra, when you need to pay the studio hall, the
recording van, the orchestra, the catering etc.
- even when you do an amateur live performance
A complete studio in the box could cost less than 1000,- EUR. What do
you think, why people still buy stand-alone-devices that provide just
e.g. some piano instruments for much more than 1000,- EUR?
If Pianoteq is the only problematic thing on your machine, regarding to
a live performance, than you've got good luck.
Sorry, no help, but try to see it that way, you should be lucky to have
such a reliable machine.
2 Cents,
Ralf
19 Jun
19 Jun
10:46 p.m.
Hi all,
I just wanted to report that I finally have joy regarding the
Pianoteq/JACK issues I've been plagued by!
What worked for me is disabling 'CPU overload detection' (in
Pianoteq). I had already disabled 'multicore' in the same 'Performance
dialog', and just to be extra sure, I took all of my WIFI connections
offline, as well as unloading the drivers for wireless all together
while I played (in this case, it was 'ndiswrapper'). I don't think it
was causing a problem, but every extra thing that eats CPU or memory
that I don't need while playing doesn't hurt to take offline.
Just FYI, for anyone who can find the information useful, my setup:
* ASUS EEEPC 1000HE
* Lexicon Lambda outboard USB sound interface, IRQ made RT priority
with 'chrt -p 99 XXXX', XXXX being the process ID of the IRQ handling
the USB sound interface, found with 'cat /proc/interrupts' and 'lsusb'
* Arch Linux, which I recommend over Ubuntu anyday for minimalists who
want to squeeze every last drop of bloat (and thus benefit
performance) out of their boxes.
* output of 'uname -a' : Linux myhost 2.6.33-rt #1 SMP PREEMPT RT Sat
Aug 7 09:40:44 UTC 2010 i686 Intel(R) Atom(TM) CPU N280 @ 1.66GHz
GenuineIntel GNU/Linux
* output of 'jackd -V': jackd version 0.120.2 tmpdir /dev/shm protocol 24
* jackd command: 'jackd -dalsa -r44100 -p128 -n3'
I've heard that many USB interfaces seem to need 3 soft buffer periods
per hardware buffer periods ('-n3' in the jackd command above). I knew
this already, and that wasn't my issue, but I'm just saying this to
other folks who may have problems with outboard USB sound interfaces,
that I've found it to be true in the case of the Lexicon Lambda: it
would choke and bleed xruns on things like '-p256 -n2' but I got as
low as '-p64 -n3', no problem! In this case, since I'm prepping for a
live situation, I'm doubling everything from the lowest possible
latency setting by default for insurance ('-p128' instead of '-p64')
because I can't afford a hard lock or crash in the show....
Thanks again!
AKJ
On Sun, Jun 12, 2011 at 2:40 AM, Aaron Krister Johnson
<aaron(a)akjmusic.com> wrote:
Hi all--
I'm wondering if anyone else has experienced this:
I'm considering purchasing PianoTeq, but I wanted to try the demo. It seems
to work better with just the alsa driver than it does with jack, a reversal
of the usual situation.
I tested this several times by playing fast glissandi on the default piano
preset. Each time, my little EEE-PC netbook under jack choked with xruns and
a brief silence while PianoTeq 'reset' itself, but Alsa alone chugged away
with no xruns unless there was an extreme amount of load....
I'm wondering if anyone can comment on this. It seems odd, especially since
the jack developers claim jack adds no latency by itself to the picture in
any situation---so, do we have a situation where the code is better written
for the alsa driver than for jackd? It seems we do, in this case....
Best,
AKJ
--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org
--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org
20 Jun
20 Jun
8:15 a.m.
Aaron Krister Johnson wrote:
Hi all,
I just wanted to report that I finally have joy regarding the
Pianoteq/JACK issues I've been plagued by!
What worked for me is disabling 'CPU overload detection' (in
Pianoteq). I had already disabled 'multicore' in the same 'Performance
dialog', and just to be extra sure, I took all of my WIFI connections
offline, as well as unloading the drivers for wireless all together
while I played (in this case, it was 'ndiswrapper'). I don't think it
was causing a problem, but every extra thing that eats CPU or memory
that I don't need while playing doesn't hurt to take offline.
I've heard that wireless drivers can cause many xruns because they
periodically rescan for available wireless connections (even if the
wireless card's external antenna is turned off). When their scan takes
much time, apparently, and they hog things while doing it.
Just FYI, for anyone who can find the information
useful, my setup:
* ASUS EEEPC 1000HE
* Lexicon Lambda outboard USB sound interface, IRQ made RT priority
with 'chrt -p 99 XXXX', XXXX being the process ID of the IRQ handling
the USB sound interface, found with 'cat /proc/interrupts' and 'lsusb'
* Arch Linux, which I recommend over Ubuntu anyday for minimalists who
want to squeeze every last drop of bloat (and thus benefit
performance) out of their boxes.
* output of 'uname -a' : Linux myhost 2.6.33-rt #1 SMP PREEMPT RT Sat
Aug 7 09:40:44 UTC 2010 i686 Intel(R) Atom(TM) CPU N280 @ 1.66GHz
GenuineIntel GNU/Linux
* output of 'jackd -V': jackd version 0.120.2 tmpdir /dev/shm protocol 24
* jackd command: 'jackd -dalsa -r44100 -p128 -n3'
I've heard that many USB interfaces seem to need 3 soft buffer periods
per hardware buffer periods ('-n3' in the jackd command above). I knew
this already, and that wasn't my issue, but I'm just saying this to
other folks who may have problems with outboard USB sound interfaces,
I have to use -n3 with my UCA202.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
4894
days inactive
4902
days old
linux-audio-user@lists.linuxaudio.org
34 comments
13 participants
participants (13)
-
Aaron Krister Johnson -
Atte André Jensen -
david -
Gerhard Zintel -
Igor Brkic -
James Warden -
Jeremy Jongepier -
Lorenzo Sutton -
Paul Davis -
Ralf Mardorf -
Renato -
Robin Gareus -
rosea.grammostola